hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Becke <be...@u.washington.edu>
Subject Re: Memory Leaks when web server hangs
Date Mon, 22 Mar 2004 05:02:21 GMT
Hi Eric,

What exactly do you mean by "thread thrashing"?  Which connection  
manager are you using?

Mike

On Mar 19, 2004, at 1:21 PM, Eric Bloch wrote:

> Hey there,
>
> I create/destroy http clients but always have them use the same  
> connection manager.
>
> Will that cause thread thrashing?
>
> Thanks,
>
> -Eric
>
> Roland Weber wrote:
>
>> Hello Srini,
>>
>> you should *not* create a new HTTP Client for each request!
>> This will also create a new connection manager, and a new
>> cleanup thread. It beats the whole purpose of connection
>> management.
>>
>> You should create *one* HTTP Client object for the lifetime
>> of your application. Then, the connection manager of that
>> client will reuse and free connections as appropriate.
>>
>> best regards,
>>  Roland
>>
>>
>>
>>
>>
>>
>> Srinivas Vemula <srinivas.vemula@mensamind.com>
>> 02.02.2004 11:56
>> Please respond to "Commons HttpClient Project"
>>        To:     Commons HttpClient Project  
>> <commons-httpclient-dev@jakarta.apache.org>
>>        cc:        Subject:        Re: Memory Leaks when web server  
>> hangs
>>
>>
>> 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
>>
>>>
>>>
>>
>>
>
>
> -- 
> Laszlo Systems, Inc.
> 1040 Mariposa Street, SF, CA, USA 94107
>
> voice: 415.241.2721
> fax:   415.865.2914
> email: bloch@laszlosystems.com
> --
>
> Laszlo allows Behr to deliver a breakthrough experience with  
> ColorSmart by BEHR application at http://www.behr.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


Mime
View raw message