Thanks Sebb. I'll put in a enhancement request. Regarding this:
> > 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. > > I could not find where this is overridden in JMeter. I was speculating and just assumed it was overridden. I may have misunderstood the meaning of this setting, but is this the total number of HTTP connections between JMeter and a server (when HTTP Keep-Alive is enabled as in HTTP 1.1)? Since JMeter is emulating many clients, shouldn't this setting be disobeyed? For instance, suppose JMeter emulates 10 concurrent clients (10 threads) simultaneously executing a slow webservice - would 5 connections be made first, and the latter connections be made as the first batch finishes? Kind regards, Sonam Chauhan -- Corporate Express Australia Ltd. Phone: +61-2-93350725, Email: [EMAIL PROTECTED] -----Original Message----- From: sebb [mailto:[EMAIL PROTECTED] Sent: Friday, 26 October 2007 10:00 PM To: JMeter Users List Subject: Re: DNS round robin and JVM DNS lookup caching On 26/10/2007, Sonam Chauhan <[EMAIL PROTECTED]> wrote: > 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! There is no reasoning stated in the java.properties file - they just assert that it is necessary to permanently cache any DNS results when there is a security manager. They are deliberately overriding the TTL. It's not clear why this protects against DNS spoofing - the first DNS result may be spoofed - but it does mean that the IP address cannot change once obtained, which may be important for some unstated reasons. > --------------------- > 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. You can already do this for Sun JVMs - just define sun.net.inetaddr.ttl on the command-line or in system.properties. But I suppose it would be possible for JMeter to treat the property networkaddress.cache.ttl specially, and set it as per the bug description. BTW, the file java.security seems to have the default as: security.overridePropertiesFile=true which means that the property java.security.properties can be used to append to/override the java.security file; this might make it unnecessary to special-case the TTL property. But it would be simpler for the user if it could be defined in the JMeter system.properties file, so feel free to create an enhancement request. > 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. I could not find where this is overridden in JMeter. > ---------------------- > > 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] > > --------------------------------------------------------------------- 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]
