You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Current »

To be Reviewed By: October 26, 2020

Authors: Dale Emery

Status: Draft | Discussion | Active | Dropped | Superseded

Superseded by: N/A

Related: N/A

Problem

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 the JVM’s working directory indirectly, either by using relative paths or by resolving paths against “.”  or “” .

Resolving files against the JVM’s working directory makes it impossible to test many Geode features in parallel outside of a container.

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

None identified.

Solution

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

Instead of accessing the property directly, Geode code will get the working directory from a new WorkingDirectory  class, by calling static methods that return the working directory as a java.nio.file.Path  or a java.io.File. To maintain Geode’s current behavior, these methods return the value of user.dir  if geode.working-dir  is not set.

Optionally (TBD): These methods can ensure that the returned path is canonical (as defined by the java.io.File  documentation) and that it refers to an existing directory.

Changes and Additions to Public Interfaces

This proposal adds a new public system property: geode.working-dir .

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

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, 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

None yet.

Errata

None yet.

  • No labels