Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 55355 invoked from network); 13 Apr 2007 02:58:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 13 Apr 2007 02:58:26 -0000 Received: (qmail 92943 invoked by uid 500); 13 Apr 2007 02:58:27 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 92905 invoked by uid 500); 13 Apr 2007 02:58:26 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 92896 invoked by uid 99); 13 Apr 2007 02:58:26 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Apr 2007 19:58:26 -0700 X-ASF-Spam-Status: No, hits=2.3 required=10.0 tests=HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of liyilei1979@gmail.com designates 209.85.134.186 as permitted sender) Received: from [209.85.134.186] (HELO mu-out-0910.google.com) (209.85.134.186) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Apr 2007 19:58:19 -0700 Received: by mu-out-0910.google.com with SMTP id w1so811160mue for ; Thu, 12 Apr 2007 19:57:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=kxgL9QBN2/NXtsZMYQ9Q0RnFaje9cTXExOxxVyTKvsJfJuliFpanYSOad8aVjsHVB8tk+l9nKhmlulKS7stBZmbdpqXkQBomBSpmQl/kMVb6ks7r4aX+lmm2EvBhdK1HfylWIEQ5y/OL0OPFENT4RaVVnHaEBQjJ6vq4sUzVaHY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=OgAXc6EHrFvKlA4pV/y7w8HQbiLWni4ZP+H7dbX4bg4A818HIMzy7Ue5aXDZdeS2QLOC3hSg5QP3+8doj5yW9y4tkUKASsDUsYddxKK9DyUI/cQK7MU+zCCB04pYdDFGIDu9jHxn44S+0b+557F2WUZPij/zFAoidmvt+REDSPk= Received: by 10.82.153.5 with SMTP id a5mr3527321bue.1176433076594; Thu, 12 Apr 2007 19:57:56 -0700 (PDT) Received: by 10.82.183.4 with HTTP; Thu, 12 Apr 2007 19:57:56 -0700 (PDT) Message-ID: Date: Fri, 13 Apr 2007 10:57:56 +0800 From: "Leo Li" To: dev@harmony.apache.org Subject: Re: [classlib][xnet] Problem using SSLSocketImpl behind load balancer In-Reply-To: <005001c77d2f$d6509a50$0eab2fa6@mcilink.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_27361_30862141.1176433076547" References: <005001c77d2f$d6509a50$0eab2fa6@mcilink.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_27361_30862141.1176433076547 Content-Type: multipart/alternative; boundary="----=_Part_27362_15600475.1176433076547" ------=_Part_27362_15600475.1176433076547 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Gerald: The harmony build system adopts an incremental compiling, thus if the InetAddress is removed, the build will still succeed since it regards that no new/modification has occurred. Actually the deploy still contains the InetAddress class if you look at the luni.jar built from it. But if you clean the system, build system will complain about compiling errors. The class is needed by several core classes, such as socket. So if you do not need the DNS caching, the solution is simple: Just remove the caching mechanism in the InetAddress class. If you would like, you can try the patch in attachment, which can be applied on the luni module at revision 528316. (It is just a customization on classlib for your case, not for Harmony classlib itself.) Besides, you can also remove the return NagativeCache if necessary in your case. On 4/13/07, Gerald Jerome wrote: > > Hi Leo, the first two clarifications appear correct, but I'm not sure DNS > caching is important as all our connections are created up front when the > app starts and held in a pool (vector) - the Broker servers up connections > out of a connection pool as they are requested. If a connection is > unusable > say when the host fails or is taken down, the app attempts to recreate > another SSLSocket connection. It has been tested and found to be > reasonably > fault tolerant, except we have this problem in production where a load > balancing or redirector exists between the client(s) and hosts. > Interestingly, I deleted the InetAddress class from the luni library and > noticed no compilation errors and the app connects and is able to > communicate just fine. So it appears either the caching never takes place > or only if InetAddress is available, I don't know. > > Regards, > > Gerald Jerome > > > > -----Original Message----- > From: Leo Li [mailto:liyilei1979@gmail.com] > Sent: Tuesday, April 10, 2007 11:05 PM > To: dev@harmony.apache.org > Subject: Re: [classlib][xnet] Problem using SSLSocketImpl behind load > balancer > > 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 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.ttlproperties. > > > > > 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 > > > -- Leo Li China Software Development Lab, IBM ------=_Part_27362_15600475.1176433076547 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi, Gerald:
     The harmony build system adopts an incremental compiling, thus if the InetAddress is removed, the build will still succeed since it regards that no new/modification has occurred. Actually the deploy still contains the InetAddress class if you look at the luni.jar built from it. But if you clean the system, build system will complain about compiling errors. The class is needed by several core classes, such as socket.
     So if you do not need the DNS caching, the solution is simple: Just remove the caching mechanism in the InetAddress class.
     If you would like, you can try the patch in attachment, which can be applied on the luni module at revision 528316. (It is just a customization on classlib for your case, not for Harmony classlib itself.)
     Besides, you can also remove the return NagativeCache if necessary in your case.

 
On 4/13/07, Gerald Jerome <gerald.jerome@verizonbusiness.com> wrote:
Hi Leo, the first two clarifications appear correct, but I'm not sure DNS
caching is important as all our connections are created up front when the
app starts and held in a pool (vector) - the Broker servers up connections
out of a connection pool as they are requested.  If a connection is unusable
say when the host fails or is taken down, the app attempts to recreate
another SSLSocket connection.  It has been tested and found to be reasonably
fault tolerant, except we have this problem in production where a load
balancing or redirector exists between the client(s) and hosts.
Interestingly, I deleted the InetAddress class from the luni library and
noticed no compilation errors and the app connects and is able to
communicate just fine.  So it appears either the caching never takes place
or only if InetAddress is available, I don't know.

Regards,

Gerald Jerome



-----Original Message-----
From: Leo Li [mailto:liyilei1979@gmail.com ]
Sent: Tuesday, April 10, 2007 11:05 PM
To: dev@harmony.apache.org
Subject: Re: [classlib][xnet] Problem using SSLSocketImpl behind load
balancer

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 <t.p.ellison@gmail.com> 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





--
Leo Li
China Software Development Lab, IBM ------=_Part_27362_15600475.1176433076547-- ------=_Part_27361_30862141.1176433076547--