Thanks for the comprehensive response (as always) Sebb. > The default TTL is -1, for the reasons stated in the bug report. > This means the cached value will be kept for the life of the JVM.
Sun is wrong in their reasoning here (and frustratingly so) - if they wanted to cache DNS properly, they should have cached entries only for their TTL duration. Even browsers don't cache forever by default! --------------------- >From http://en.wikipedia.org/wiki/Domain_name_system#Broken_resolvers As a final level of complexity, some applications (such as web-browsers) also have their own DNS cache, in order to reduce the use of the DNS resolver library itself. This practice can add extra difficulty when debugging DNS issues, as it obscures the freshness of data, and/or what data comes from which cache. These caches typically use very short caching times - of the order of one minute. Internet Explorer offers a notable exception: recent versions cache DNS records for half an hour.[1] --------------------- Do you think it's worth a Bugzilla feature request for JMeter allow the user to override Java's default DNS-caching behaviour in a user-setting at the beginning of the test? This will enable it to work properly (as a browser would) in DNS round-robin load balancing scenario. A probable precedent for this (I think) is that JMeter overrides this property too: ---------------------- http.maxConnections (default: 5) If HTTP keep-alive is enabled, this value is the number of idle connections that will be simultaneously kept alive, per-destination. ---------------------- Kind regards, Sonam Chauhan -- Corporate Express Australia Ltd. Phone: +61-2-93350725, Email: [EMAIL PROTECTED] -----Original Message----- From: sebb [mailto:[EMAIL PROTECTED] Sent: Thursday, 25 October 2007 10:07 PM To: JMeter Users List Subject: Re: DNS round robin and JVM DNS lookup caching The Sun Java document is at: http://java.sun.com/j2se/1.4.2/docs/guide/net/properties.html which says you can change networkaddress.cache.ttl in java.security or sun.net.inetaddr.ttl on the command-line. These need to be defined at startup - or at least before DNS is first used. So you cannot change the TTL without restarting, but you can set it to a low enough value (try 0) such that DNS queries are not cached for too long. The default TTL is -1, for the reasons stated in the bug report. This means the cached value will be kept for the life of the JVM. I think non-Java applications also cache DNS results; I'm not sure if this is done in the language library or the OS itself. Nor do I know if Java is subject to caching of DNS entries by the OS. If you want to sure of using the correct DNS entries, you could perhaps try using CSV Dataset with a file of IP addresses. However this probably won't work for virtual hosts, as they normally require the host name (and I'm not sure you can override this via the header manager). On 25/10/2007, Sonam Chauhan <[EMAIL PROTECTED]> wrote: > Hi - > > > > I've got to load test a clustered application server. > > > > External users of the application (whom JMeter must simulate) access it > through a hardware load balancer. > > > > However, internal access goes through DNS Round Robin load balancing > (implemented in Active Directory). This means that each DNS request to > resolve a hostname will resolve to a different primary IP address. > > > > I understand that the JVM caches DNS lookups forever by default. This > article implies that a JMeter load test accessing a cluster through the > DNS Round Robin above, will only load test 1 node in the cluster as it > caches the first name resolution it does: > > http://www.rgagnon.com/javadetails/java-0445.html > > Once an application has performed network access (i.e. urlconnection, > parsing of xml document with external references, etc), the DNS settings > get cached so any subsequent operation will use the old settings even if > the real settings have changed. To reset everything, you have to restart > the server since the default setting JVM setting is to cache forever. > > > Is this true? How does this impact JMeter testing? I found this related > bug on the Sun website. > > > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6376406 > > > > > > Kind regards, > > Sonam Chauhan > > -- > > Corporate Express Australia Ltd. > > Phone: +61-2-93350725, Email: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
