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 (JIRA)" <ax...@ws.apache.org> on 2006/03/05 15:22:39 UTC
[jira] Created: (AXIS-2422) Problem using compression with Axis 1.3
Problem using compression with Axis 1.3
---------------------------------------
Key: AXIS-2422
URL: http://issues.apache.org/jira/browse/AXIS-2422
Project: Apache Axis
Type: Bug
Environment: Windows XP, JDK 1.5.0_06
Reporter: Marius Danciu
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
[jira] Commented: (AXIS-2422) Problem using compression with Axis
1.3
Posted by "Pavan Kumar R V R (JIRA)" <ax...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/AXIS-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557156#action_12557156 ]
Pavan Kumar R V R commented on AXIS-2422:
-----------------------------------------
Hi,
What is the ETA on this issue? Though both the suggestions made above seem to work, we are not sure about the side effects of releasing the connection back to the pooler in invoke() method itself. I see the following condition at the end of invoke() method in CommonsHTTPSender. Why do we do this only when "axis.one.way" is TRUE?
if (msgContext.isPropertyTrue("axis.one.way")) {
method.releaseConnection();
}
What are the repercussions of releasing connection if axis.one.way is FALSE?
It would be great if we can get this fix into the soonest forthcoming release of Axis, as this is very crucial for the working of SOAP GZip Compression in Axis per se.
Thanks,
Pavan
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS-2422) Problem using compression with Axis
1.3
Posted by "Tim Labath (JIRA)" <ax...@ws.apache.org>.
[ 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
[jira] Commented: (AXIS-2422) Problem using compression with Axis
1.3
Posted by "Duncan Loveday (JIRA)" <ax...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/AXIS-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711204#action_12711204 ]
Duncan Loveday commented on AXIS-2422:
--------------------------------------
I'm hitting this with Axis 1.4 and commons http client 1.3 - so I guess no fix has been incorporated ? This seems like a pretty serious bug that ought to be addressed.
> 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.
[jira] Updated: (AXIS-2422) Problem using compression with Axis 1.3
Posted by "Marius Danciu (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXIS-2422?page=all ]
Marius Danciu updated AXIS-2422:
--------------------------------
Attachment: CommonsHTTPSender.java
The attched code contains a potential fix. GZIPInputStream is enveloped by an anonimous inputs tream sensitive to end of stream condition. See CommonsHTTPSender#createGZIPConnectionReleasingInputStream(...) method
> Problem using compression with Axis 1.3
> ---------------------------------------
>
> Key: AXIS-2422
> URL: http://issues.apache.org/jira/browse/AXIS-2422
> Project: Apache Axis
> 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
[jira] Commented: (AXIS-2422) Problem using compression with Axis
1.3
Posted by "Duncan Loveday (JIRA)" <ax...@ws.apache.org>.
[ 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.