You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Tim Labath (JIRA)" <ax...@ws.apache.org> on 2006/11/13 20:06:37 UTC
[jira] Commented: (AXIS-2422) Problem using compression with Axis
1.3
[ 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org