Hi, Gerald: First I would like to clarify your problem: 1. We want to exchange the request to a new server seamlessly according to workload balancing. 2. The behavior of DNS caching prevent us from that. 3. You would like to get the support from classlib, that is to enjoy the DNS caching as well as the response to server switching.
Since Harmony would like to be a compatible classlib with RI's, we have to comply with RI's behavior with RI's. But it is possible to customize harmony's classlib if you conform with apache license. So my suggestion is here: (1) Expose the method which clears the DNS cache in InetAddress to public.(If you would like to maintain the interface of java public API, wrap it in an implementation class and expose it as public.) (2) On the socket side, if you use your socket implementation, in the connection method, if the connection fails, clear the DNS cache by the method exposed before and retry it. If you are interested, I think, we might talk about it in detail. On 4/11/07, Tim Ellison <[EMAIL PROTECTED]> wrote:
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... > 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 > 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
-- Leo Li China Software Development Lab, IBM
