Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow configuring aeron properties via application.conf #23889

Open
ktoso opened this issue Nov 1, 2017 · 3 comments
Open

Allow configuring aeron properties via application.conf #23889

ktoso opened this issue Nov 1, 2017 · 3 comments
Labels
1 - triaged Tickets that are safe to pick up for contributing in terms of likeliness of being accepted t:remoting:artery

Comments

@ktoso
Copy link
Member

ktoso commented Nov 1, 2017

Some of the aeron settings are likely to be always needed to be tweaked, it's nicer if we can put that configuration in application.conf, pick them up at startup and set the env variables for aeron to pick up (or pass it a config?).

@ktoso
Copy link
Member Author

ktoso commented Nov 1, 2017

The usual things to tweak are: https://github.com/real-logic/aeron/wiki/Performance-Testing#throughput-testing

We could provide some "human readable recommended" values so that we'd aeron.mtu.length=internal-network etc?

@patriknw
Copy link
Member

patriknw commented Nov 1, 2017

sounds good to somehow pass a section of our config to Aeron. I'd like to avoid duplicating/mapping all their settings. Note that some settings are for the client and some for the media driver.
The media driver can be run as a separate process, and then one can use a properties file with the Aeron settings. When we launch the embedded driver we could perhaps do something similar, dumping the config section to a properties file. Have to look into how the media driver is reading those things.

@patriknw patriknw added t:remoting:artery 1 - triaged Tickets that are safe to pick up for contributing in terms of likeliness of being accepted labels Nov 1, 2017
@guidomedina
Copy link
Contributor

I agree with Patrik here, having the shared driver inside Akka IMHO will be the exceptional case because of the amount of shared memory each driver instance requires, if the user still wants the driver inside Akka maybe the right solution is document key recommended options but always point the user to Aeron config section.

As an example one of my projects is running on an Akka cluster of 15 JVMs, 3 JVMs per physical server and each physical server has one dedicated Aeron driver so all Akka nodes are running as client.

On an IDE like IntelliJ is the same, because projects having Akka remote with Artery will require one driver, IMHO it is better that the user know this and make the effort of bringing up his own driver for his own "later" good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1 - triaged Tickets that are safe to pick up for contributing in terms of likeliness of being accepted t:remoting:artery
Projects
None yet
Development

No branches or pull requests

3 participants