[ http://issues.apache.org/jira/browse/AXIS-2422?page=comments#action_12449448 ] Tim Labath commented on AXIS-2422: ----------------------------------
I think it would be good to get this or some other fix for this issue into CommonsHTTPSender. I spent a few hours debugging and tracking down this same issue unnecessarily because I didn't think to check for bugs here... Calling releaseConnectionOnCloseStream.close(); just before releaseConnectionOnCloseStream goes out of scope will also release the connection back to the pool and seems like a reasonable thing to do. > Problem using compression with Axis 1.3 > --------------------------------------- > > Key: AXIS-2422 > URL: http://issues.apache.org/jira/browse/AXIS-2422 > Project: Apache Axis > Issue Type: Bug > Environment: Windows XP, JDK 1.5.0_06 > Reporter: Marius Danciu > Attachments: CommonsHTTPSender.java > > > Hello, > I'm using Axis 1.3 release and it looks like there is a problem when using > compression. First, let me describe the scenario that I'm using: > 1. I'm using axis to interact with SalesForce > (http://www.salesforce.com/developer/) > 2. I'm using compression (by setting HTTPConstants.MC_GZIP_REQUEST and > HTTPConstants.COMPRESSION_GZIP to true) > 3. I'm sending Authentication request tu URL1 (compressed) and sforce is > providing the response NON-compressed. After this, HTTP connection is > returned correctlyy to connection pool. > 4. SForce is providing a new URL (URL2) for the subsequent HTTP requests > within the context of this session. > 5. Now, I'm sending the nex t SOAP request (a query for example). After > receiving the response (this time SForce sent it compressed) I noticed that > the connection is NOT returned to connection pool. > 6. I'm sending another SOAP request and response is received correctly, b ut > the HTTP connection is NOT returned to the connection pool again (response > was aagin compressed). > 7. Attempting to send another request will block the client since there are > no connections left in the connection pool and the client will wait until a > connection will eventually be returned to the pool. (default number of > connections per host is 2) > After debugging a bit Commons Http Client code, it seems that > GZIPInputStream doesn't really work very well with AutoCloseInputStream. What > I mean is that AutoCloseInputStream monitors when end of stream is reached > (read value == -1) and will automatically cause the connection to be returned > to connection pool. When using GZIPInputStr eam this does not happen. > AutoCloseInputStream is not "notified" (never reads -1) when GZIPInputStream > reached the end of stream. > Thank you, > Marius -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
