If all connections are released the in use count should definitely not
climb.  I'm guessing you're either doing something quite subtle that
is leaking only a few connections, or you've run into a very strange
problem that no-one else has seen.  Posting a use case that shows the
problem will clear this up pretty quickly.

Mike 

On 6/23/05, Thomas L. Redman <[EMAIL PROTECTED]> wrote:
> I continue to have problems. I now know that for each method I
> create, I do close the connection, I kept a reference count to make
> sure, and it does always seem to come out zero. One thing I have
> noticed though is that if I call
> MultiThreadedHttpConnectionManager.getConnectionsInUse that number
> does climb to the maximum allowable number of connections, regardless
> of calling releaseConnection. Is that as it should be?
> 
> 
> At 4:26 PM -0400 6/18/05, Michael Becke wrote:
> >Hi Thomas,
> >
> >Connections are also auto-released when the full response content has
> >been read.  This would happen when getResponseBody() is called, but
> >not with getResponseBodyAsStream().  My guess is there must be some
> >cases where getResponseBodyAsStream() is called, the response content
> >is not fully read, and releaseConnection is not being called.  If you
> >could post some sample code that exhibits the problem it would help.
> >Also, what version of HttpClient are you using?
> >
> >Mike
> >
> >On 6/18/05, Thomas L. Redman <[EMAIL PROTECTED]> wrote:
> >>  >It sounds like connections are not being released.  Please have a look
> >>  >at <http://jakarta.apache.org/commons/httpclient/3.0/threading.html>
> >>  >for examples of how to use the MultiThreadedHttpConnectionManager.
> >>
> >>  Thanks Michael, that is what I had expected as well, however, I
> >>  releaseConnection in a finally clause, so I don't see how this can be
> >>  the case. I had already read the above docs, and use them as a
> >>  guideline.
> >>
> >>  And here is another interesting twist; If I call
> >>  Method.getResponseBody, I don't see this problem. I only experience
> >>  this problem if I use Method.getResponseBodyAsStream. Which is what I
> >>  need to use incase the stream of data coming in is without end. A
> >>  common robot trap.
> >>
> >>  So, I am wondering about the stream. Should I be closing the input
> >>  stream resulting from a call to getResponseBodyAsStream before I call
> >>  release connection? Or should I not call it at all? Should it matter?
> >>
> >>  Hmmm...
> >>
> >>  >
> >>  >Mike
> >>  >
> >>  >On 6/18/05, Thomas L. Redman <[EMAIL PROTECTED]> wrote:
> >>  >>  I am having difficulty using the MultiThreadedHttpConnectionManager
> >>  >>  to support a multithreaded download environment. I have several
> >>  >>  threads attempting to download URLS simultaneously. At some point, it
> >>  >>  hangs. When I do a thread dump (Ctl-\), I see all my threads are
> >>  >>  blocked as the following stack trace indicates:
> >>  >>
> >>  >>           at java.lang.Object.wait(Native Method)
> >>  >>           - waiting on <0x49bd5f50> (a
> >>  >>
> >>  
> >> >>org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$ConnectionPool)
> >>  >>           at
> >>  >>
> >>  
> >> >>org.apache.commons.httpclient.MultiThreadedHttpConnectionManager.doGetConnection(MultiThreadedHttpConnectionManager.java:461)
> >>  >>           - locked <0x49bd5f50> (a
> >>  >>
> >>  
> >> >>org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$ConnectionPool)
> >>  >>           at
> >>  >>
> >>  
> >> >>org.apache.commons.httpclient.MultiThreadedHttpConnectionManager.getConnection(MultiThreadedHttpConnectionManager.java:365)
> >>  >>           at
> >>  >>
> >>org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:613)
> >>  >>           at
> >>  >>
> >>org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:497)
> >>  >>
> >>  >>  I would surmise from this that I am not releasing my connections
> >>  >>  property. Would this be the problem or are there other things that
> >>  >>  could cause this?
> >>  >>
> >>  >>  ---------------------------------------------------------------------
> >>  >>  To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>  >>  For additional commands, e-mail: [EMAIL PROTECTED]
> >>  >>
> >>  >>
> >>  >
> >>  >---------------------------------------------------------------------
> >>  >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>  >For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >>  ---------------------------------------------------------------------
> >  > To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>  For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to