hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Johnson" <e...@tibco.com>
Subject Re: Deadlock problem with MultiThreadedHttpConnectionManager
Date Wed, 18 Jun 2003 16:35:14 GMT
Mike,

I think you're roughly agreeing with what I would conclude, but I wasn't 
sure and I wanted to get other's feedback.

Michael Becke wrote:

> Doing something time-consuming from the event thread is a little 
> questionable I think.  It's an easy way to keep a user from using the 
> UI but it causes problems like this.  I would suggest executing the 
> HttpClient call from another thread and popping up a modal dialog.  
> This way the UI is still responsive and you can add a cancel button to 
> stop the HttpClient method if you like.

Unfortunately, I am not directly responsible for the design and 
implementation of the product, and we're not focusing resources 
elsewhere, so dramatic changes like the ones you suggest are not 
possible.  I agree with your point, though, and would change it if I could!

>
>> This leads me to ask two questions:
>> Should we add a call to System.gc() at line 302 of 
>> MultiThreadedHttpConnectionManager?
>
>
> The support for detecting GCed connections is a last resort.  In 
> general it should never be relied on and was mostly just added as a 
> "cool feature".
>
> Doing explicit GCs from within the HttpClient code is definitely a 
> hack.  It can be quite time consuing and there is no guarantee that it 
> will have any effect.  You could certainly add a GC in your code but I 
> think it is not something we want to include in HttpClient.

Yeah, I was leaning that way too, in that the gc() call is a hack.

>
>> Should we ever invoke the "connectionPool.wait()" with a zero value, 
>> or should this always time out?  I think this would be better if it 
>> always timed out, as it is possible, as my scenario shows, to get 
>> into states where the garbage collector never runs, the connections 
>> are never freed, and the application grinds to a halt.
>
>
> Having a zero value is quite valid I think.  There are some cases when 
> you want to wait until a connection is available regardless of how 
> long that takes.  Though 0 is the default value it can certainly be 
> set in your application.  Having the thread timeout doesn't really 
> solve your problem though.  It just lets you know you have a problem.

Letting me know I had a problem would be better than what the 
application does now!  In my case, it would "solve" the problem to the 
extent that the program would not appear to be frozen.

>
> The price of using the MultiThreadedHttpConnectionManager is that 
> connections must be released manually.  It trades off the benefit of 
> connection reuse/management for the burden of connection release.
>
> I think the only real solution in this case is to ensure that 
> connections are released manually.
>
> Also, I am wondering if all of this is happening in the UI thread why 
> are you using the MultiThreadedHttpConnectionManager?  It is really 
> for sharing/reusing connections among various threads.

Of course, there are a variety of reasons for using 
MultiThreadedHttpConnectionManager, if only because the other option is, 
well, too simple.  We do have other threads, they just don't happen to 
get kicked off in the problematic scenario.

Thanks for the feedback.

-Eric.



Mime
View raw message