[ 
https://issues.apache.org/jira/browse/AXIS-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711207#action_12711207
 ] 

Duncan Loveday commented on AXIS-2422:
--------------------------------------

I should have added: The attachment fixes the problem beautifully and thanks 
for providing it.

> Problem using compression with Axis 1.3
> ---------------------------------------
>
>                 Key: AXIS-2422
>                 URL: https://issues.apache.org/jira/browse/AXIS-2422
>             Project: 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.
-
You can reply to this email to add a comment to the issue online.

Reply via email to