harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerald Jerome <gerald.jer...@verizonbusiness.com>
Subject RE: [classlib][xnet] Problem using SSLSocketImpl behind load balancer
Date Thu, 12 Apr 2007 18:28:35 GMT
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?


Gerald Jerome

-----Original Message-----
From: Mikhail Loenko [mailto:mloenko@gmail.com] 
Sent: Tuesday, April 10, 2007 9:01 PM
To: dev@harmony.apache.org
Subject: Re: [classlib][xnet] Problem using SSLSocketImpl behind load

2007/4/11, Tim Ellison <t.p.ellison@gmail.com>:
> Gerald Jerome wrote:
> > Hello, we are using the Apache Harmony SSLSocket classes to solve a
> > we were having with SSL renegotiation.  However, recently our production
> > admin noticed that our SSL client was not automatically failing over to
> > secondary machine that exists behind a load balancer or redistributor in
> > cases where a server goes down (either unexpectedly or for maintenance).
> > are using the Sun JVM and not the Apache Harmony version.  He mentions
> > 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
> > urlconnection, parsing of xml document with external references, etc)
> > cache DNS settings, so any subsequent client request will use its old
> > information even if the real DNS settings have changed.
> >
> > To reset everything, you have to restart the client application since
> > 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
> > 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
networkaddress.cache.negative.ttl = 0

and Harmony classlib will change its behavior?


> > 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
> > 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?
> > could not find any references to the InetAddress class mentioned above
> > 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
> > 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

View raw message