axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Labath (JIRA)" <axis-...@ws.apache.org>
Subject [jira] Commented: (AXIS-2422) Problem using compression with Axis 1.3
Date Mon, 13 Nov 2006 19:06:37 GMT
    [ 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


Mime
View raw message