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.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
