On 12/03/2010 11:31 AM, Michael Ludwig wrote:
Moin Jordan,
Jordan Michaels schrieb am 03.12.2010 um 10:39 (-0800):
Would any of you be able to point me to some documentation on how
the JVM handles DNS resolving? I'm hoping there are JVM settings
that can be tweaked to help force the JVM to fail over to the
secondary resolver.
I'm using version 1.6 JVM.
Networking Properties
http://download.oracle.com/javase/6/docs/technotes/guides/net/properties.html#nct
networkaddress.cache.ttl
[…] A value of -1 indicates "cache forever". The default behavior
is to cache forever when a security manager is installed, and to
cache for an implementation specific period of time, when a
security manager is not installed.
So have you installed a security manager?
Wondering myself what the default value is?
sun.net.inetaddr.ttl
This is a sun private system property which corresponds to
networkaddress.cache.ttl. It takes the same value and has the
same meaning, but can be set as a command-line option. However,
the preferred way is to use the security property mentioned
above.
Still wondering. So is the "implementation specific period of time"
the value taken from the OS?
The Tomcat and JVM installs are very close to vanilla installs. We've
added a few classes to Tomcat and changed the JVM settings a little
(java_opts) but nothing that would effect any of these settings here.
The weird thing is that you'd think if caching was on, the site wouldn't
immediately die when the resolver died, but that's what's happening.
When you hit the site when the resolver is dead, it just hangs... a
white screen with no errors... like it's just waiting.
It's what makes me think that the...
sun.net.client.defaultConnectTimeout (default: -1)
sun.net.client.defaultReadTimeout (default: -1)
settings are involved somehow... I just don't know if those settings are
used for DNS requests as well as the HTTP and FTP connections.
You can still SSH to the OS (CentOS 5) and the OS does what it's
supposed to, so the JVM isn't doing it through the OS, that's for sure.
-Jordan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org