Return-Path: Delivered-To: apmail-hc-dev-archive@www.apache.org Received: (qmail 56753 invoked from network); 18 Apr 2010 10:47:37 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 18 Apr 2010 10:47:37 -0000 Received: (qmail 66041 invoked by uid 500); 18 Apr 2010 10:47:37 -0000 Delivered-To: apmail-hc-dev-archive@hc.apache.org Received: (qmail 65864 invoked by uid 500); 18 Apr 2010 10:47:35 -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 65856 invoked by uid 99); 18 Apr 2010 10:47:34 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 18 Apr 2010 10:47:34 +0000 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [92.42.190.144] (HELO ok2cons2.nine.ch) (92.42.190.144) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 18 Apr 2010 10:47:25 +0000 Received: from [192.168.1.102] (178-83-227-183.dclient.hispeed.ch [178.83.227.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ok2cons2.nine.ch (Postfix) with ESMTPSA id 9BA094BA2A2 for ; Sun, 18 Apr 2010 12:47:04 +0200 (CEST) Subject: Re: Closing the persisted server connections on IOReactor pause From: Oleg Kalnichevski To: HttpComponents Project In-Reply-To: References: <1270557153.22212.8.camel@ubuntu> <1271499955.2404.30.camel@ubuntu> Content-Type: text/plain; charset="UTF-8" Date: Sun, 18 Apr 2010 12:47:00 +0200 Message-ID: <1271587620.2363.19.camel@ubuntu> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On Sun, 2010-04-18 at 08:00 +0530, Ruwan Linton wrote: > Hi Oleg, > > > > Hi Ruwan > > > > You have got to be very careful here. HTTP connection objects are not > > thread safe! One can easily run into a race condition when interacting > > with connection objects from any other but an I/O dispatch thread. > > > > I have already encountered the above issue, and had a look at the > NhttpConnection class JavaDoc and realized this. > > > > > > So, Here is the recommended way of going about this problem. You should > > signal the intention to terminate the connection by setting a special > > attribute in the session context or changing the state of the shared > > connection state object and let the connection shut down itself, when it > > is done processing the actual message. > > > Thanks a lot for this valuable input, I was thinking how I can proceed with > my limited knowledge on httpcore. Really appreciate this help. > > > > If the persistent connection is > > idle, you may need to active it by using the IOControl interface. > > > > May be I didn't get this part, could you please tell me how to check whether > the connection is idle or not? > Hi Ruwan There is simply no reliable way to test that. By the time you are done checking, the connection may finish message processing and become idle. So, what you should do it to update the connection state (for instance, in this particular case, by setting a termination request flag), activate the connection by requesting output processing with IOControl#requestOutput and let the connection react to the changed state. Hope this helps Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org