Return-Path: Delivered-To: apmail-hc-dev-archive@www.apache.org Received: (qmail 51209 invoked from network); 1 Nov 2010 19:32:20 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 1 Nov 2010 19:32:20 -0000 Received: (qmail 54440 invoked by uid 500); 1 Nov 2010 19:32:51 -0000 Delivered-To: apmail-hc-dev-archive@hc.apache.org Received: (qmail 54403 invoked by uid 500); 1 Nov 2010 19:32:51 -0000 Mailing-List: contact dev-help@hc.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "HttpComponents Project" Delivered-To: mailing list dev@hc.apache.org Received: (qmail 54395 invoked by uid 99); 1 Nov 2010 19:32:51 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Nov 2010 19:32:51 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of hiranya911@gmail.com designates 209.85.212.51 as permitted sender) Received: from [209.85.212.51] (HELO mail-vw0-f51.google.com) (209.85.212.51) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Nov 2010 19:32:47 +0000 Received: by vws20 with SMTP id 20so4292500vws.10 for ; Mon, 01 Nov 2010 12:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=p0XT59zL+gpdhknVnZ8QwS39sVjrP1CHwfKqyl9HME8=; b=Dl+W4ejLvhp7gInEXgn+TRCYSx4oi54v0k9JdcB2+A64G4reTs+42bosrnsSXKdRDj /ra93h+z/yS3a2Y5sq2TUzb2HPpp0FVlDswG67BkBgoXaMkqgaJjqByfFSHrwaB8cjsW Atcjm+oBCKGS+WkAd8je1flKt01Y5HQwJeQV8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=D19R9F4lI4V7XWcvxPN6uxtE+YHkz66bz9o+kHKYbuEvJkV1N+QoTuxxqweIeiBGmJ P240Tp4deSIzLe9agsGLwkAkWkhXHysVZtrLIGvGiTCxBf2weBGonKFOdi/Ef+qYcuuu u7DqnvnDDheeXQeQNZYuUyIzXNP9Ay+ANcDZs= MIME-Version: 1.0 Received: by 10.224.203.129 with SMTP id fi1mr3341849qab.231.1288639945965; Mon, 01 Nov 2010 12:32:25 -0700 (PDT) Received: by 10.229.24.20 with HTTP; Mon, 1 Nov 2010 12:32:25 -0700 (PDT) In-Reply-To: <30107703.post@talk.nabble.com> References: <1279097087.9094.33.camel@ubuntu> <1280585504.7154.54.camel@ubuntu> <30107703.post@talk.nabble.com> Date: Tue, 2 Nov 2010 01:02:25 +0530 Message-ID: Subject: Re: HttpCore NIO hurt by JDK bug? From: Hiranya Jayathilaka To: HttpComponents Project Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Nov 2, 2010 at 12:48 AM, swatkatz wrote: > > Hello, > > We seem to be experiencing this as well when using NIO. We are using JDK = 1.6 > Update 21. This bug should be fixed in JDK 1.6 build 21. At least that's what all the evidence suggest. We haven't been able to reproduce the issue on this particular JDK version ever. Thanks, Hiranya Any ideas what the workaround/fix is ? > > Regards, > Mohan > > > > olegk wrote: >> >> On Thu, 2010-07-15 at 12:50 -0700, Harold Lee wrote: >>> I've put together a simple HTTP server that resets the connection >>> after sending part of the response back to the client. I'm going to >>> try to recreate the bug (leaking sockets) by making many requests >>> against that server from a Linux box. I'll let you know what I find. >>> >>> Harold >>> >> >> >> >>> On Wed, Jul 14, 2010 at 1:44 AM, Oleg Kalnichevski >>> wrote: >>> > On Tue, 2010-07-13 at 13:32 -0700, Harold Lee wrote: >>> >> Regarding this JDK bug: >>> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=3D6403933 >>> >> >>> >> I think we are experiencing this using HttpCore on Linux with Java >>> >> 1.6. We wind up leaking socket descriptors until the JVM process run= s >>> >> out. We also wind up having to start a new reactor thread, which >>> >> creates a new Selector. The old reactor thread keeps running and the >>> >> thread dump shows it in sun.nio.ch.EPollArrayWrapper.epollWait as >>> >> reported by others in the bug report above. >>> >> >>> > >> >> >> Hi Harold >> >> Did you have any luck reproducing the problem? >> >> I put together a work-around for the bug that causes the epoll spin >> problem [1]. If you are interested in trying it out I will happily share >> it with you. The work-around is pretty ugly, so I want to be sure there >> is no other way of solving the issue. >> >> cheers >> >> Oleg >> >> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=3D6403933 >> >>> > Folks >>> > >>> > Anyone experienced anything like that? The looks pretty old, but ther= e >>> > has been no reports of similar problems with HttpCore NIO. I am using >>> > Linux / JDK 1.6 on a daily basis when hacking on HttpCore but I have >>> not >>> > encountered such a problem yet. >>> > >>> > >>> >> Here's the change that the Glassfish team made to work around this J= DK >>> bug: >>> >> >>> >> >>> http://fisheye5.cenqua.com/browse/glassfish/appserv-http-engine/src/jav= a/com/sun/enterprise/web/connector/grizzly/ByteBufferInputStream.java?r1=3D= 1.8&r2=3D1.9 >>> >> >>> >> From my reading, the Glassfish code is much simpler than the HttpCor= e >>> >> NIO code: they're registering interest for just 1 socket and using >>> >> Selector.select() to wait for data from that socket. For HttpCore NI= O, >>> >> it isn't yet clear to me how we can detect which selector is "trashe= d" >>> >> in order to cancel it and recreate it. >>> >> >>> >> I'm working on a workaround in AbstractMultiworkerIOReactor.java. If >>> >> selector.select returns 0 (setting readyCount to 0) then we don't kn= ow >>> >> whether this bug hit us or we just had a timeout. >>> > >>> > The problem is that it is perfectly valid for a selector to return 0 >>> > ready count. This condition alone is not sufficient to assume the >>> > selector is trashed. >>> > >>> > >>> >> =A0To be safe, I think >>> >> we need to close every registered SelectorKey and then call >>> >> selector.selectNow() to flush them. Then we can create a new >>> >> SelectorKey for each and reregister them. The only way to make it le= ss >>> >> common, I think, is to use a long selectTimeout value so that the od= ds >>> >> of a timeout are low. Ugly, but I hope it will work. >>> >> >>> > >>> > This will unfortunately screw up handling of new / closed channels as >>> > well timeout logic. >>> > >>> > The work-around looks butt ugly and would require tons of fairly >>> complex >>> > code. Is there a way to reproduce the issue with a test scenario, so = we >>> > could look for alternative approaches? >>> > >>> > Cheers >>> > >>> > Oleg >>> > >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org >>> For additional commands, e-mail: dev-help@hc.apache.org >>> >>> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org >> For additional commands, e-mail: dev-help@hc.apache.org >> >> >> > > -- > View this message in context: http://old.nabble.com/HttpCore-NIO-hurt-by-= JDK-bug--tp29155405p30107703.html > Sent from the HttpComponents-Dev mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org > For additional commands, e-mail: dev-help@hc.apache.org > > --=20 Hiranya Jayathilaka Senior Software Engineer; WSO2 Inc.;=A0 http://wso2.org E-mail: hiranya@wso2.com;=A0 Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org