I think invoking HttpClient from the AWT event thread is key, as it prevents further interaction by the user with the application, and thus the garbage collector never gets invoked. Based on this theory, it turns out that I can work around the bug in my code by putting in a call to System.gc() immediately before "connectionPool.wait(timeToWait)". Granted, this doesn't fix the problem in my application's code, but it does potentially solve a serious issue for naive (or careless) users of HttpClient.
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.
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.
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.
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.
Mike
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
