System-property based defaults prevent running multiple isolated Aeron stacks in a single JVM

[artem-v]

Description

Key Aeron context classes (e.g. MediaDriver.Context, Aeron.Context, Archive.Context, etc.) read configuration values from JVM system properties during initialization. Because system properties are global, multiple Aeron stacks within the same JVM cannot be configured independently. This limitation is particularly impactful for local development and testing scenarios where multiple Aeron stacks are created within the same JVM.

Examples include:

• Local multi-node testing, where several drivers/archives/clustered services run in one process for faster integration tests.
• Running multiple isolated services in one JVM, such as during local development or lightweight sandbox environments. This can be useful when bootstrapping multiple microservices locally to test interactions or simulate multi-node cluster without launching multiple JVM processes or containers.

As a workaround, Aeron contexts can be configured programmatically, but that requires calling many setters. Using system properties is convenient because property names and values are documented and can be supplied from java.util.Properties objects or configuration files. Without per-context property binding, the only alternatives are manual wiring or reflection-based workarounds.

Proposal/idea/suggestion

Introduce Properties constructor overload for each context class, while keeping the default constructor unchanged. Internally, contexts should delegate property lookup to single configuration source. Example:

public Context()
{
    this(System.getProperties());
}

public Context(Properties properties)
{
    this.config = properties;
}

private String getProperty(String name)
{
    return config.getProperty(name);
}

This would allow users to configure each Context from Properties object (or configuration file) while preserving the existing system property behavior.

[JPWatson]

Hey @artem-v, we have been experimenting with an approach along these lines.
Not sure whether/when it'll make it in, but will keep you updated.

[artem-v]

@JPWatson
Thanks, good to hear this is being explored. I would be happy to test any experimental multi-context, single-JVM setup and provide feedback.

[vitor-tadashi]

Hi @artem-v, Agrona already has helper functions that do what you need — you just need to point them to a different configuration.

Would it make sense to have separate configurations and load the right one when necessary?

loadPropertiesFiles(PropertyAction.REPLACE, filePath);
loadPropertiesFiles(PropertyAction.PRESERVE, filePath);

[artem-v]

Hi @artem-v, Agrona already has helper functions that do what you need — you just need to point them to a different configuration.

Would it make sense to have separate configurations and load the right one when necessary?

loadPropertiesFiles(PropertyAction.REPLACE, filePath);
loadPropertiesFiles(PropertyAction.PRESERVE, filePath);

Hi, thanks for pointing this out, but it is the same "system property" approach - loadPropertiesFiles() under the hood comes down to System.setProperty().
What was was described in the issue - is to have more DI friendly approach, allow clients to pass Properties object to context classes.