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 Marius Danciu <md...@yahoo.com> on 2006/03/05 13:45:33 UTC
Problem using compression with Axis 1.3
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 next 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, but 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 (a parent of Gip) 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 GZIPInputStream this does not happen. AutoCloseInputStream is not "notified" (never reads -1) when GZIPInputStream reached the eand of stream.
The attached modified CommonsHttpSender source with the fix this problem. If you can find another "quick" fix, I would be quite interested in it.
Thank you,
Marius
---------------------------------
Yahoo! Mail
Bring photos to life! New PhotoMail makes sharing a breeze.
Re: Problem using compression with Axis 1.3
Posted by Marius Danciu <md...@yahoo.com>.
Please see https://issues.apache.org/jira/browse/AXIS-2422
Thank you,
Marius
Davanum Srinivas <da...@gmail.com> wrote: can u please log a jira bug?
thx,
dims
On 3/5/06, Marius Danciu wrote:
> 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 next 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 (a parent of Gip) 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 GZIPInputStream
> this does not happen. AutoCloseInputStream is not "notified" (never reads
> -1) when GZIPInputStream reached the eand of stream.
>
> The attached modified CommonsHttpSender source with the fix this problem.
> If you can find another "quick" fi x, I would be quite interested in it.
>
>
> Thank you,
> Marius
>
>
>
> ________________________________
> Yahoo! Mail
> Bring photos to life! New PhotoMail makes sharing a breeze.
>
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
---------------------------------
Yahoo! Mail
Bring photos to life! New PhotoMail makes sharing a breeze.
Re: Problem using compression with Axis 1.3
Posted by Davanum Srinivas <da...@gmail.com>.
can u please log a jira bug?
thx,
dims
On 3/5/06, Marius Danciu <md...@yahoo.com> wrote:
> 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 next 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 (a parent of Gip) 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 GZIPInputStream
> this does not happen. AutoCloseInputStream is not "notified" (never reads
> -1) when GZIPInputStream reached the eand of stream.
>
> The attached modified CommonsHttpSender source with the fix this problem.
> If you can find another "quick" fi x, I would be quite interested in it.
>
>
> Thank you,
> Marius
>
>
>
> ________________________________
> Yahoo! Mail
> Bring photos to life! New PhotoMail makes sharing a breeze.
>
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
Re: Problem using compression with Axis 1.3
Posted by Marius Danciu <md...@yahoo.com>.
Please ignore "(a parent of Gip)" below. It is a typo.
Marius
Marius Danciu <md...@yahoo.com> wrote: 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 next 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 (a parent of Gip) 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 GZIPInputStream this does not happen. AutoCloseInputStream is not "notified" (never reads -1) when GZIPInputStream reached the eand of stream.
The attached modified CommonsHttpSender source with the fix this problem. If you can find another "quick" fi x, I would be quite interested in it.
Thank you,
Marius
---------------------------------
Yahoo! Mail
Bring photos to life! New PhotoMail makes sharing a breeze.
---------------------------------
Yahoo! Mail
Use Photomail to share photos without annoying attachments.