hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Srinivas Vemula <srinivas.vem...@mensamind.com>
Subject Re: Memory Leaks when web server hangs
Date Mon, 02 Feb 2004 12:01:33 GMT
Thanks Marcus,
    Are u saying  we should add getMethod.addRequestHeader("Connection", 
"close")  for every request made using HttpClient ? Excuse me if I 
missed your point completely.
srini

Marcus Crafter wrote:

>Hi Srinivas, et al,
>
>Hope all is well.
>
>We've also experienced a similar story here in Oz just the other day. 
>Essentially connections to the webserver were not being released and were 
>consuming sockets on the client (determined via OptimizeIT).
>
>After searching the dev list I found a post by another developer that said
>this was the default behaviour for HTTP 1.1 which HttpClient honoured (ie.
>keep-alive), if the server didn't indicate what the client should do with
>the connection.
>
>When I looked into the headers via a wire trace I saw that indeed the
>server (IIS in this case) didn't send a 'Connection: close' header and after 
>browsing the HttpClient source saw that the connection was kept alive if 
>using HTTP 1.1.
>
>The non-programatic way to fix it was to add a request header to each
>client request saying 'Connection: close'.
>
>After doing this, HttpClient closed all connections after they were
>released and the open socket problem went away.
>
>Hope this helps.
>
>Cheers,
>
>Marcus
>
>On Mon, Feb 02, 2004 at 04:26:39PM +0530, Srinivas Vemula wrote:
>  
>
>>Oleg,
>>  
>>   We are using JDK1.4.1 and connection time out is set to 30Ms and 
>>read time out to 60Ms. We are trying to connect to a IP Camera, and send 
>>a heart beat command to the camera to check for its availability every 
>>30 Secs from the time we find it is un available. If the web server is 
>>down, we feel that HttpClient is not cleaning up failed connections 
>>properly and thats resulting in Memory Leaks at the server side.
>>
>>   The code we use is the standard way of using HttpClient and all the 
>>code is in a method and new HttpClient object is created for every 
>>request. Are there any ways to make sure the connections are all being 
>>purged properly? Are there any precautionary measures or flags we can 
>>set on HttpClient API when communicating with a web server (running on 
>>firm ware) with relatively less RAM and processing power (IpCamera with 
>>built in web server)?
>>
>>Thanks for your time and help.
>>Srini
>>
>>Kalnichevski, Oleg wrote:
>>
>>    
>>
>>>>Mike and Oleg, the stack trace Srini included indicates that HttpClient is
>>>>attempting to create a new timeout thread on every connection - does this
>>>>always occur or is it just one timeout thread per httpclient instance?  It
>>>>would be ideal if we could reduce this to one static thread as starting
>>>>threads is never nice for server side apps.  Not sure how feasible that is
>>>>though.
>>>>  
>>>>
>>>>        
>>>>
>>>Hi Srini,
>>>HttpClient uses an additional controller thread to work around the 
>>>limitation of older (< 1.4) JDKs which do not provide a possibility to set

>>>connect timeout. If you do not really need to control connect timeout (for 
>>>instance, when communicating with an intranet site with good availability) 
>>>simply set connect timeout to. That will prevent HttpClient from spawning 
>>>an additional thread per request.
>>>
>>>Adrian, et al
>>>Another possibility to use reflection to set connect timeout using the 
>>>Socket methods when running in JVM 1.4 or above
>>>
>>>Oleg
>>>
>>>
>>>
>>>-----Original Message-----
>>>From: Adrian Sutton [mailto:adrian@intencha.com]
>>>Sent: Monday, February 02, 2004 09:03
>>>To: Commons HttpClient Project
>>>Subject: Re: Memory Leaks when web server hangs
>>>
>>>
>>>On 2/2/04 2:00 PM, "Srinivas Vemula" <srinivas.vemula@mensamind.com> wrote:
>>>
>>>
>>>
>>>      
>>>
>>>>Hi All,
>>>>    We are seeing thread leaks when having client open connections to a 
>>>>    web
>>>>server that hangs. Has any one seen this happening?? How do we ensure 
>>>>that the
>>>>library correctly closes  socket connections on failures, cleaning up 
>>>>system
>>>>resources, and  threads actually finish in  the timeout period and get 
>>>>freed
>>>>up. Would using MultiThreadedHttpConnectionManager
>>>><file:///D:/silkroad/http-commons/commons-httpclient-2.0-rc3/docs/threading.ht
>>>>ml#MultiThreadedHttpConnectionManager>   be of any help??
>>>>  
>>>>
>>>>        
>>>>
>>>Hi Srini,
>>>If you're using the same HttpClient instance across multiple threads, you
>>>must use the MultiThreadedHttpConnectionManager or you'll run into strange
>>>problems.  If you're using separate HttpClient instances, you may as well
>>>stick with the single threaded (default) connection manager.
>>>
>>>In terms of connections hanging - you probably want to look into the
>>>setConnectionTimeout and setTimeout methods of the HttpClient class.  These
>>>allow you to control how long HttpClient waits when making a connection and
>>>how long it waits for data once the connection is established.  If you have
>>>set either of these to 0 (not sure what the default is, it may be platform
>>>specific) the connection will never timeout which sounds a lot like what
>>>you're seeing.
>>>
>>>Mike and Oleg, the stack trace Srini included indicates that HttpClient is
>>>attempting to create a new timeout thread on every connection - does this
>>>always occur or is it just one timeout thread per httpclient instance?  It
>>>would be ideal if we could reduce this to one static thread as starting
>>>threads is never nice for server side apps.  Not sure how feasible that is
>>>though.
>>>
>>>
>>>
>>>      
>>>
>>>>Srini
>>>>  
>>>>
>>>>        
>>>>
>>>Regards,
>>>
>>>Adrian Sutton.
>>>
>>>----------------------------------------------
>>>Intencha "tomorrow's technology today"
>>>Ph: 38478913 0422236329
>>>Suite 8/29 Oatland Crescent
>>>Holland Park West 4121
>>>Australia QLD
>>>www.intencha.com
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: 
>>>commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: 
>>>commons-httpclient-dev-help@jakarta.apache.org
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: 
>>>commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: 
>>>commons-httpclient-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>      
>>>
>>-- 
>>Srinivas Vemula                          +91 40 23547826- Ext 201
>>Associate Consultant                     +91 40 23541447 (Fax)
>>Mensamind                                +91 98497-42720 (Mobile)        
>>Hyderabad
>>India
>>http://www.mensamind.com
>>
>>DISCLAIMER
>>The information contained in this e-mail is confidential and intended for 
>>the named recipient(s) only. If you are not an intended recipient of this 
>>email you must not copy, distribute or take any further action in reliance 
>>on it. You should delete it and notify the sender immediately.
>>
>>
>>    
>>
>
>  
>

-- 
Srinivas Vemula                          +91 40 23547826- Ext 201
Associate Consultant                     +91 40 23541447 (Fax)
Mensamind                                +91 98497-42720 (Mobile)        
Hyderabad
India
http://www.mensamind.com

DISCLAIMER
The information contained in this e-mail is confidential and intended for the named recipient(s)
only. If you are not an intended recipient of this email you must not copy, distribute or
take any further action in reliance on it. You should delete it and notify the sender immediately.



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message