RFC Title
To be Reviewed By: October 26, 2020
Authors: Dale Emery
Status: Draft Draft | Discussion | Active | Dropped | Superseded
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 implicitlyindirectly, 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's files, 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.
...
Optionally (TBD): These methods can ensure that the returned path is canonical (as defined by the java.io.File
documentation)absolute and normalized, and that it refers to an existing directory.
...
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.
Backwards Compatibility and Upgrade Path
Will the regular rolling upgrade process work with these changes?
By default, if the new geode.working-dir
property is not set, Geode will behave as it currently does. Users who do not set this property will experience no change.
If the user specifies a geode.working-dir
other than the JVM's working directory, I do not know how the effect on backward compatibility, the rolling upgrade process would be affected.
How do the proposed changes impact backwards-compatibility? Are message or file formats changing?
By default, if the new geode.working-dir
property is not set, Geode will behave as it currently does. Users who do not set this property will experience no change.
If the user specifies a geode.working-dir
other than the JVM's working directory, I do not know how the backwards-compatibility would be affected.
Is there a need for a deprecation process to provide an upgrade path to users who will need to adjust their applications?
I believe that the only necessary change is to our documentation, so that if
Prior Art
What would be the alternatives to the proposed solution? What would happen if we don’t solve the problem? Why should this proposal be preferred?
FAQ
Answers to questions you’ve commonly been asked after requesting comments for this proposal.
Errata
, and any shell scripts provided by either Geode or the user is TBD.
Prior Art
None known.
FAQ
None yet.
Errata
None yet.What are minor adjustments that had to be made to the proposal since it was approved?