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

Stats: Add JVM dns cache expiration config to JvmInfo #36372

Open
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@spinscale
Member

spinscale commented Dec 7, 2018

The java security manager disables the DNS cache by default and never
expires any DNS entry. The default behaviour without the security
manager is 30 seconds.

In dynamic environment DNS entries can change, which means, that an
Elasticsearch instance requires a restart to pick up new settings.

Right now, there is no visibility to find out, if/how the configuration
for DNS expiration is set.

This adds this info to the JvmInfo class. Either the setting is shown or
it is marked as 'unlimited'

Stats: Add JVM dns cache expiration config to JvmInfo
The java security manager disables the DNS cache by default and never
expires any DNS entry. The default behaviour without the security
manager is 30 seconds.

In dynamic environment DNS entries can change, which means, that an
Elasticsearch instance requires a restart to pick up new settings.

Right now, there is no visibility to find out, if/how the configuration
for DNS expiration is set.

This adds this info to the JvmInfo class. Either the setting is shown or
it is marked as 'unlimited'
@elasticmachine

This comment has been minimized.

elasticmachine commented Dec 7, 2018

@spinscale

This comment has been minimized.

Member

spinscale commented Dec 7, 2018

Testing is a bit hard as it requires JVM config changes. I tested this by setting the following in $JAVA_HOME/conf/security/java.security

networkaddress.cache.ttl=30

one more thing we could think about as well is to configure this setting in Elasticsearch using java.security.Security.setProperty("networkaddress.cache.ttl" , "30"); and thus restore the original behaviour or make this available as a setting, so that users do not have to change their JVM configuration.

@@ -36,6 +37,15 @@ public void testUseG1GC() {
}
}
public void testDnsTtl() {
String propertyValue = System.getProperty("networkaddress.cache.ttl");

This comment has been minimized.

@jakelandis

jakelandis Dec 7, 2018

Contributor

As you mention in the comment... I think it is safe to grab the property here, set it to the the desired value, test it, then set it back to the original value in a finally block. Assuming we don't execute any of the unit tests within the same JVM concurrently (I don't think we do, but not 100%).

@spinscale spinscale added WIP stalled and removed WIP labels Dec 11, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment