axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marius Danciu (JIRA)" <>
Subject [jira] Created: (AXIS-2422) Problem using compression with Axis 1.3
Date Sun, 05 Mar 2006 14:22:39 GMT
Problem using compression with Axis 1.3

         Key: AXIS-2422
     Project: Apache Axis
        Type: Bug
 Environment: Windows XP, JDK 1.5.0_06
    Reporter: Marius Danciu


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 (
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
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,

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message