Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Superseded by: N/A

Related: N/A

Problem

What is this proposal solving? Why

Numerous Geode classes resolve relative file paths against the JVM’s working directory—the value of the user.dir  system property. Some classes do this explicitly, by resolving paths against the value of user.dir . Other classes refer to to the JVM’s working directory implicitly, either by using relative paths or by resolving paths against “.”  or “” .

...

Every Gradle test worker JVM for a given task type (e.g. distributedTest) has the same working directory. When tests run in parallel outside of a container, if multiple tests write to the same file path relative to the JVM’s working directory, those tests all write to the same file. The tests interfere with each other, causing swarms of failures.

Anti-Goals

What is outside the scope of what the proposal is trying to solve?None identified.

Solution

Make Geode resolve relative paths against a configurable path defined by a new geode.working-dir  system property.

...

Any documentation that refers to user.dir will need to refer instead to geode.working-dir .

Any assumptions made by shell scripts that ship with Geode will have to account for this property.

Performance Impact

I expect that the additional cost to resolve paths to a canonical path will be minimal.

...

If the user specifies a geode.working-dir other than the JVM's working directory, the effect on backward compatibility, the rolling upgrade process, and any shell scripts provided by either Geode or the user is TBD.

Prior Art

None known.

FAQ

Answers to questions you’ve commonly been asked after requesting comments for this proposalNone yet.

Errata

None to dateyet.