Hi Mikhail, that is the suggestion that is being proposed, although the mechanics of doing this prolly should conform to http://www.rgagnon.com/javadetails/java-0445.html. I tested the app after deleting InetAddress from the classlib and everything appears normal. So I doubt if any of this will have any effect. What do you think?
Regards, Gerald Jerome -----Original Message----- From: Mikhail Loenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 10, 2007 9:01 PM To: [EMAIL PROTECTED] Subject: Re: [classlib][xnet] Problem using SSLSocketImpl behind load balancer 2007/4/11, Tim Ellison <[EMAIL PROTECTED]>: > Gerald Jerome wrote: > > Hello, we are using the Apache Harmony SSLSocket classes to solve a problem > > we were having with SSL renegotiation. However, recently our production > > admin noticed that our SSL client was not automatically failing over to a > > secondary machine that exists behind a load balancer or redistributor in > > cases where a server goes down (either unexpectedly or for maintenance). We > > are using the Sun JVM and not the Apache Harmony version. He mentions the > > following: > > That sounds like an interesting combination of code, and not something > that I expect can be easily reproduced by the Harmony developers, so > take the following information only as guidance -- I don't know what you > are actually running with... I used this configuration when did some experiments with security-related classes. > > > Our investigation found that once Java based clients (both standalone > > applications, and servlets) have performed the first network access (i.e. > > urlconnection, parsing of xml document with external references, etc) they > > cache DNS settings, so any subsequent client request will use its old DNS > > information even if the real DNS settings have changed. > > > > To reset everything, you have to restart the client application since the > > default JVM setting is to cache forever. > > > > The InetAddress class has a cache to store successful as well as > > unsuccessful host name resolutions. The positive caching is there to guard > > against DNS spoofing attacks. > > Correct, the scenario you describe is almost exactly as described here: > http://www.rgagnon.com/javadetails/java-0445.html Do you mean that Gerald might set networkaddress.cache.ttl = 0 and networkaddress.cache.negative.ttl = 0 and Harmony classlib will change its behavior? Thanks, Mikhail > > > He goes on to discuss how the caching can be disabled. I know your > > SSLSocket implementation uses SSLEngine and does low-level socket based > > communication so I did not think his analysis may fit our situation. > > Furthermore, I am not convinced that we are having this problem but our > > development and test environments do not have a distributor/load balancer in > > front of the actual host machines. > > Hmm, this could really be a shot in the dark then! > > > I know in production we are configured > > to connect to the distributor, not one of the actual hosts. I am wondering > > if you were aware of any caching of DNS information that may be going on > > inside the SSLSocket class and dependant code that we are using using? I > > could not find any references to the InetAddress class mentioned above in > > any of the Harmony source I have. > > If you have the luni.jar then you should have the java.net.InetAddress > class (and java.net.NegativeCache class). They will honour the > networkaddress.cache.ttl and networkaddress.cache.negative.ttl properties. > > > The x-net.jar file that we are using has > > a last modified date of October 28, 2006 8:27:58 PM. The last modified date > > of luni.jar is the same. These are the only two Apache Harmony libraries we > > are using. > > Those sound quite old now, although I don't recall significant > development in x-net since then. > > > Any information you have pertaining to this problem is greatly > > appreciated > > Maybe somebody else will have some insight, but it is really hard to > advise on a problem you are not sure you are having on a runtime > codebase we don't know. > > Regards, > Tim > >
