You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Scott Willey (JIRA)" <ji...@apache.org> on 2009/05/14 01:02:45 UTC
[jira] Created: (HTTPCORE-196) Long receive time for chunked ssl
response
Long receive time for chunked ssl response
------------------------------------------
Key: HTTPCORE-196
URL: https://issues.apache.org/jira/browse/HTTPCORE-196
Project: HttpComponents HttpCore
Issue Type: Bug
Affects Versions: 4.0
Environment: MacOSX (Leopard) / Tomcat / Eclipse
Reporter: Scott Willey
Fix For: Future
Processing a chunked SSL response of 221 characters, I found I was waiting over three seconds for the entire response to be read. Upon investigation, this appears to be happening because the decrypt method in SSLIOSession does not decrypt everything in the encrypted buffer at one go. Because of this, portions of my response didn't get processed via the processing of the events, but rather via the BaseIOReactor's validate method which means I experienced multiple select interval timeouts prior to the message being fully processed. In reviewing the java nio documentation for the unwrap method of the sslEngine, the comments in the javadoc state: "This method will attempt to consume one complete SSL/TLS network packet". It appears that one time through the decrypt method decrypted small packets with almost no data in them, leaving encrypted data waiting. As an experiment, I changed the code in isAppInputReady in SSLIOSession to call decrypt in a loop until everything in the en
crypted buffer was processed and bingo the response processed in under 5ms.
Unfortunately, I do not have a "sharable" test case as the server side for this case is inside a corporate filrewall. In theory this should be reproducable with any server over an SSL connection getting a chunked response.
I have a current "patch" for this issue as follows in SSLIOSession.isAppInputReady, but I will feel much more comfortable with and "official" patch
public synchronized boolean isAppInputReady() throws IOException {
int bytesRead = receiveEncryptedData();
if (bytesRead == -1) {
//changed per https://issues.apache.org/jira/browse/HTTPCORE-193
// this.status = CLOSED;
this.endOfStream = true;
//end change
}
doHandshake();
//MODIFICATION
//Doing a single decrypt call does not always completely decrypt available
//data (data read above in receiveEncryptedData). The documentation for
//sslEngine states that the unwrap method (used in decrypt method)
//
// "This method will attempt to consume one complete SSL/TLS network packet"
//
//Presumedly, when there are multiple network packets, we only decode one
//at a time, so multiple calls to decrypt may be necessary to decrypt all
//we have. If we do not, we will not process all data available and we
//will fail to process incoming responses in a timely way. This may cause
//data to be processed only during calls to validation at the reactor level,
//which is done once every selectInterval (default value: 1 sec)
//original
//decryptData();
//change:
int priorPos = 0;
while(this.inEncrypted.position() > 0 && this.inEncrypted.position() != priorPos){
priorPos = this.inEncrypted.position();
decryptData();
}
//MODIFICATION END
// Some decrypted data is available or at the end of stream
return this.inPlain.position() > 0 || this.status != ACTIVE;
}
--
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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Resolved: (HTTPCORE-196) Long receive time for chunked ssl
response
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski resolved HTTPCORE-196.
----------------------------------------
Resolution: Fixed
Committed patch to SVN trunk and 4.0.x branch
The snapshot builds can be found here
https://repository.apache.org/content/repositories/snapshots/org/apache/httpcomponents/
Oleg
> Long receive time for chunked ssl response
> ------------------------------------------
>
> Key: HTTPCORE-196
> URL: https://issues.apache.org/jira/browse/HTTPCORE-196
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.0
> Environment: MacOSX (Leopard) / Tomcat / Eclipse
> Reporter: Scott Willey
> Fix For: 4.1
>
> Attachments: httpcore-196.patch
>
>
> Processing a chunked SSL response of 221 characters, I found I was waiting over three seconds for the entire response to be read. Upon investigation, this appears to be happening because the decrypt method in SSLIOSession does not decrypt everything in the encrypted buffer at one go. Because of this, portions of my response didn't get processed via the processing of the events, but rather via the BaseIOReactor's validate method which means I experienced multiple select interval timeouts prior to the message being fully processed. In reviewing the java nio documentation for the unwrap method of the sslEngine, the comments in the javadoc state: "This method will attempt to consume one complete SSL/TLS network packet". It appears that one time through the decrypt method decrypted small packets with almost no data in them, leaving encrypted data waiting. As an experiment, I changed the code in isAppInputReady in SSLIOSession to call decrypt in a loop until everything in the en
> crypted buffer was processed and bingo the response processed in under 5ms.
> Unfortunately, I do not have a "sharable" test case as the server side for this case is inside a corporate filrewall. In theory this should be reproducable with any server over an SSL connection getting a chunked response.
> I have a current "patch" for this issue as follows in SSLIOSession.isAppInputReady, but I will feel much more comfortable with and "official" patch
> public synchronized boolean isAppInputReady() throws IOException {
> int bytesRead = receiveEncryptedData();
> if (bytesRead == -1) {
> //changed per https://issues.apache.org/jira/browse/HTTPCORE-193
> // this.status = CLOSED;
> this.endOfStream = true;
> //end change
> }
> doHandshake();
>
> //MODIFICATION
> //Doing a single decrypt call does not always completely decrypt available
> //data (data read above in receiveEncryptedData). The documentation for
> //sslEngine states that the unwrap method (used in decrypt method)
> //
> // "This method will attempt to consume one complete SSL/TLS network packet"
> //
> //Presumedly, when there are multiple network packets, we only decode one
> //at a time, so multiple calls to decrypt may be necessary to decrypt all
> //we have. If we do not, we will not process all data available and we
> //will fail to process incoming responses in a timely way. This may cause
> //data to be processed only during calls to validation at the reactor level,
> //which is done once every selectInterval (default value: 1 sec)
>
> //original
> //decryptData();
>
> //change:
> int priorPos = 0;
> while(this.inEncrypted.position() > 0 && this.inEncrypted.position() != priorPos){
> priorPos = this.inEncrypted.position();
> decryptData();
> }
> //MODIFICATION END
>
> // Some decrypted data is available or at the end of stream
> return this.inPlain.position() > 0 || this.status != ACTIVE;
> }
--
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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Updated: (HTTPCORE-196) Long receive time for chunked ssl
response
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski updated HTTPCORE-196:
---------------------------------------
Component/s: HttpCore NIO
Fix Version/s: (was: Future)
4.1
> Long receive time for chunked ssl response
> ------------------------------------------
>
> Key: HTTPCORE-196
> URL: https://issues.apache.org/jira/browse/HTTPCORE-196
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.0
> Environment: MacOSX (Leopard) / Tomcat / Eclipse
> Reporter: Scott Willey
> Fix For: 4.1
>
>
> Processing a chunked SSL response of 221 characters, I found I was waiting over three seconds for the entire response to be read. Upon investigation, this appears to be happening because the decrypt method in SSLIOSession does not decrypt everything in the encrypted buffer at one go. Because of this, portions of my response didn't get processed via the processing of the events, but rather via the BaseIOReactor's validate method which means I experienced multiple select interval timeouts prior to the message being fully processed. In reviewing the java nio documentation for the unwrap method of the sslEngine, the comments in the javadoc state: "This method will attempt to consume one complete SSL/TLS network packet". It appears that one time through the decrypt method decrypted small packets with almost no data in them, leaving encrypted data waiting. As an experiment, I changed the code in isAppInputReady in SSLIOSession to call decrypt in a loop until everything in the en
> crypted buffer was processed and bingo the response processed in under 5ms.
> Unfortunately, I do not have a "sharable" test case as the server side for this case is inside a corporate filrewall. In theory this should be reproducable with any server over an SSL connection getting a chunked response.
> I have a current "patch" for this issue as follows in SSLIOSession.isAppInputReady, but I will feel much more comfortable with and "official" patch
> public synchronized boolean isAppInputReady() throws IOException {
> int bytesRead = receiveEncryptedData();
> if (bytesRead == -1) {
> //changed per https://issues.apache.org/jira/browse/HTTPCORE-193
> // this.status = CLOSED;
> this.endOfStream = true;
> //end change
> }
> doHandshake();
>
> //MODIFICATION
> //Doing a single decrypt call does not always completely decrypt available
> //data (data read above in receiveEncryptedData). The documentation for
> //sslEngine states that the unwrap method (used in decrypt method)
> //
> // "This method will attempt to consume one complete SSL/TLS network packet"
> //
> //Presumedly, when there are multiple network packets, we only decode one
> //at a time, so multiple calls to decrypt may be necessary to decrypt all
> //we have. If we do not, we will not process all data available and we
> //will fail to process incoming responses in a timely way. This may cause
> //data to be processed only during calls to validation at the reactor level,
> //which is done once every selectInterval (default value: 1 sec)
>
> //original
> //decryptData();
>
> //change:
> int priorPos = 0;
> while(this.inEncrypted.position() > 0 && this.inEncrypted.position() != priorPos){
> priorPos = this.inEncrypted.position();
> decryptData();
> }
> //MODIFICATION END
>
> // Some decrypted data is available or at the end of stream
> return this.inPlain.position() > 0 || this.status != ACTIVE;
> }
--
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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [jira] Updated: (HTTPCORE-196) Long receive time for chunked
ssl response
Posted by Scott Willey <sw...@soasta.com>.
Thanks!
On 5/15/09 9:20 AM, "Oleg Kalnichevski" <ol...@apache.org> wrote:
On Fri, May 15, 2009 at 12:17:11PM -0400, Scott Willey wrote:
> Oleg,
>
> Sorry for being such a noodle, but I didn't see where the svn access was. Can you point me in the right direction?
>
> Thanks
>
> Scott
>
Hi Scott
I think this should get you started
http://hc.apache.org/httpcomponents-core/source-repository.html
Oleg
>
> On 5/14/09 2:12 AM, "Oleg Kalnichevski (JIRA)" <ji...@apache.org> wrote:
>
>
>
> [ https://issues.apache.org/jira/browse/HTTPCORE-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Oleg Kalnichevski updated HTTPCORE-196:
> ---------------------------------------
>
> Attachment: httpcore-196.patch
>
> There are test cases for chunk coded messages transmitted over SSL encrypted connections in the HttpCore NIO test suite. So, I am not sure this issue is easily reproducible. I suspect this may be a fairly uncommon fringe case. Therefore, it would be helpful to understand the problem a bit better. Could you please provide me with some details regarding the server side setup: OS, web server, SSL library used?
>
> Anyways, please try out the attached patch and let me know if it fixes the problem for you. Please note the patch is against SVN trunk, so you will have to pull the latest code from the SVN repository, apply the patch and compile the source.
>
> Oleg
>
> > Long receive time for chunked ssl response
> > ------------------------------------------
> >
> > Key: HTTPCORE-196
> > URL: https://issues.apache.org/jira/browse/HTTPCORE-196
> > Project: HttpComponents HttpCore
> > Issue Type: Bug
> > Components: HttpCore NIO
> > Affects Versions: 4.0
> > Environment: MacOSX (Leopard) / Tomcat / Eclipse
> > Reporter: Scott Willey
> > Fix For: 4.1
> >
> > Attachments: httpcore-196.patch
> >
> >
> > Processing a chunked SSL response of 221 characters, I found I was waiting over three seconds for the entire response to be read. Upon investigation, this appears to be happening because the decrypt method in SSLIOSession does not decrypt everything in the encrypted buffer at one go. Because of this, portions of my response didn't get processed via the processing of the events, but rather via the BaseIOReactor's validate method which means I experienced multiple select interval timeouts prior to the message being fully processed. In reviewing the java nio documentation for the unwrap method of the sslEngine, the comments in the javadoc state: "This method will attempt to consume one complete SSL/TLS network packet". It appears that one time through the decrypt method decrypted small packets with almost no data in them, leaving encrypted data waiting. As an experiment, I changed the code in isAppInputReady in SSLIOSession to call decrypt in a loop until everything in the en
> > crypted buffer was processed and bingo the response processed in under 5ms.
> > Unfortunately, I do not have a "sharable" test case as the server side for this case is inside a corporate filrewall. In theory this should be reproducable with any server over an SSL connection getting a chunked response.
> > I have a current "patch" for this issue as follows in SSLIOSession.isAppInputReady, but I will feel much more comfortable with and "official" patch
> > public synchronized boolean isAppInputReady() throws IOException {
> > int bytesRead = receiveEncryptedData();
> > if (bytesRead == -1) {
> > //changed per https://issues.apache.org/jira/browse/HTTPCORE-193
> > // this.status = CLOSED;
> > this.endOfStream = true;
> > //end change
> > }
> > doHandshake();
> >
> > //MODIFICATION
> > //Doing a single decrypt call does not always completely decrypt available
> > //data (data read above in receiveEncryptedData). The documentation for
> > //sslEngine states that the unwrap method (used in decrypt method)
> > //
> > // "This method will attempt to consume one complete SSL/TLS network packet"
> > //
> > //Presumedly, when there are multiple network packets, we only decode one
> > //at a time, so multiple calls to decrypt may be necessary to decrypt all
> > //we have. If we do not, we will not process all data available and we
> > //will fail to process incoming responses in a timely way. This may cause
> > //data to be processed only during calls to validation at the reactor level,
> > //which is done once every selectInterval (default value: 1 sec)
> >
> > //original
> > //decryptData();
> >
> > //change:
> > int priorPos = 0;
> > while(this.inEncrypted.position() > 0 && this.inEncrypted.position() != priorPos){
> > priorPos = this.inEncrypted.position();
> > decryptData();
> > }
> > //MODIFICATION END
> >
> > // Some decrypted data is available or at the end of stream
> > return this.inPlain.position() > 0 || this.status != ACTIVE;
> > }
>
> --
> 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: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [jira] Updated: (HTTPCORE-196) Long receive time for chunked
ssl response
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, May 15, 2009 at 12:17:11PM -0400, Scott Willey wrote:
> Oleg,
>
> Sorry for being such a noodle, but I didn't see where the svn access was. Can you point me in the right direction?
>
> Thanks
>
> Scott
>
Hi Scott
I think this should get you started
http://hc.apache.org/httpcomponents-core/source-repository.html
Oleg
>
> On 5/14/09 2:12 AM, "Oleg Kalnichevski (JIRA)" <ji...@apache.org> wrote:
>
>
>
> [ https://issues.apache.org/jira/browse/HTTPCORE-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Oleg Kalnichevski updated HTTPCORE-196:
> ---------------------------------------
>
> Attachment: httpcore-196.patch
>
> There are test cases for chunk coded messages transmitted over SSL encrypted connections in the HttpCore NIO test suite. So, I am not sure this issue is easily reproducible. I suspect this may be a fairly uncommon fringe case. Therefore, it would be helpful to understand the problem a bit better. Could you please provide me with some details regarding the server side setup: OS, web server, SSL library used?
>
> Anyways, please try out the attached patch and let me know if it fixes the problem for you. Please note the patch is against SVN trunk, so you will have to pull the latest code from the SVN repository, apply the patch and compile the source.
>
> Oleg
>
> > Long receive time for chunked ssl response
> > ------------------------------------------
> >
> > Key: HTTPCORE-196
> > URL: https://issues.apache.org/jira/browse/HTTPCORE-196
> > Project: HttpComponents HttpCore
> > Issue Type: Bug
> > Components: HttpCore NIO
> > Affects Versions: 4.0
> > Environment: MacOSX (Leopard) / Tomcat / Eclipse
> > Reporter: Scott Willey
> > Fix For: 4.1
> >
> > Attachments: httpcore-196.patch
> >
> >
> > Processing a chunked SSL response of 221 characters, I found I was waiting over three seconds for the entire response to be read. Upon investigation, this appears to be happening because the decrypt method in SSLIOSession does not decrypt everything in the encrypted buffer at one go. Because of this, portions of my response didn't get processed via the processing of the events, but rather via the BaseIOReactor's validate method which means I experienced multiple select interval timeouts prior to the message being fully processed. In reviewing the java nio documentation for the unwrap method of the sslEngine, the comments in the javadoc state: "This method will attempt to consume one complete SSL/TLS network packet". It appears that one time through the decrypt method decrypted small packets with almost no data in them, leaving encrypted data waiting. As an experiment, I changed the code in isAppInputReady in SSLIOSession to call decrypt in a loop until everything in the en
> > crypted buffer was processed and bingo the response processed in under 5ms.
> > Unfortunately, I do not have a "sharable" test case as the server side for this case is inside a corporate filrewall. In theory this should be reproducable with any server over an SSL connection getting a chunked response.
> > I have a current "patch" for this issue as follows in SSLIOSession.isAppInputReady, but I will feel much more comfortable with and "official" patch
> > public synchronized boolean isAppInputReady() throws IOException {
> > int bytesRead = receiveEncryptedData();
> > if (bytesRead == -1) {
> > //changed per https://issues.apache.org/jira/browse/HTTPCORE-193
> > // this.status = CLOSED;
> > this.endOfStream = true;
> > //end change
> > }
> > doHandshake();
> >
> > //MODIFICATION
> > //Doing a single decrypt call does not always completely decrypt available
> > //data (data read above in receiveEncryptedData). The documentation for
> > //sslEngine states that the unwrap method (used in decrypt method)
> > //
> > // "This method will attempt to consume one complete SSL/TLS network packet"
> > //
> > //Presumedly, when there are multiple network packets, we only decode one
> > //at a time, so multiple calls to decrypt may be necessary to decrypt all
> > //we have. If we do not, we will not process all data available and we
> > //will fail to process incoming responses in a timely way. This may cause
> > //data to be processed only during calls to validation at the reactor level,
> > //which is done once every selectInterval (default value: 1 sec)
> >
> > //original
> > //decryptData();
> >
> > //change:
> > int priorPos = 0;
> > while(this.inEncrypted.position() > 0 && this.inEncrypted.position() != priorPos){
> > priorPos = this.inEncrypted.position();
> > decryptData();
> > }
> > //MODIFICATION END
> >
> > // Some decrypted data is available or at the end of stream
> > return this.inPlain.position() > 0 || this.status != ACTIVE;
> > }
>
> --
> 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: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [jira] Updated: (HTTPCORE-196) Long receive time for chunked
ssl response
Posted by Scott Willey <sw...@soasta.com>.
Oleg,
Sorry for being such a noodle, but I didn't see where the svn access was. Can you point me in the right direction?
Thanks
Scott
On 5/14/09 2:12 AM, "Oleg Kalnichevski (JIRA)" <ji...@apache.org> wrote:
[ https://issues.apache.org/jira/browse/HTTPCORE-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski updated HTTPCORE-196:
---------------------------------------
Attachment: httpcore-196.patch
There are test cases for chunk coded messages transmitted over SSL encrypted connections in the HttpCore NIO test suite. So, I am not sure this issue is easily reproducible. I suspect this may be a fairly uncommon fringe case. Therefore, it would be helpful to understand the problem a bit better. Could you please provide me with some details regarding the server side setup: OS, web server, SSL library used?
Anyways, please try out the attached patch and let me know if it fixes the problem for you. Please note the patch is against SVN trunk, so you will have to pull the latest code from the SVN repository, apply the patch and compile the source.
Oleg
> Long receive time for chunked ssl response
> ------------------------------------------
>
> Key: HTTPCORE-196
> URL: https://issues.apache.org/jira/browse/HTTPCORE-196
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.0
> Environment: MacOSX (Leopard) / Tomcat / Eclipse
> Reporter: Scott Willey
> Fix For: 4.1
>
> Attachments: httpcore-196.patch
>
>
> Processing a chunked SSL response of 221 characters, I found I was waiting over three seconds for the entire response to be read. Upon investigation, this appears to be happening because the decrypt method in SSLIOSession does not decrypt everything in the encrypted buffer at one go. Because of this, portions of my response didn't get processed via the processing of the events, but rather via the BaseIOReactor's validate method which means I experienced multiple select interval timeouts prior to the message being fully processed. In reviewing the java nio documentation for the unwrap method of the sslEngine, the comments in the javadoc state: "This method will attempt to consume one complete SSL/TLS network packet". It appears that one time through the decrypt method decrypted small packets with almost no data in them, leaving encrypted data waiting. As an experiment, I changed the code in isAppInputReady in SSLIOSession to call decrypt in a loop until everything in the en
> crypted buffer was processed and bingo the response processed in under 5ms.
> Unfortunately, I do not have a "sharable" test case as the server side for this case is inside a corporate filrewall. In theory this should be reproducable with any server over an SSL connection getting a chunked response.
> I have a current "patch" for this issue as follows in SSLIOSession.isAppInputReady, but I will feel much more comfortable with and "official" patch
> public synchronized boolean isAppInputReady() throws IOException {
> int bytesRead = receiveEncryptedData();
> if (bytesRead == -1) {
> //changed per https://issues.apache.org/jira/browse/HTTPCORE-193
> // this.status = CLOSED;
> this.endOfStream = true;
> //end change
> }
> doHandshake();
>
> //MODIFICATION
> //Doing a single decrypt call does not always completely decrypt available
> //data (data read above in receiveEncryptedData). The documentation for
> //sslEngine states that the unwrap method (used in decrypt method)
> //
> // "This method will attempt to consume one complete SSL/TLS network packet"
> //
> //Presumedly, when there are multiple network packets, we only decode one
> //at a time, so multiple calls to decrypt may be necessary to decrypt all
> //we have. If we do not, we will not process all data available and we
> //will fail to process incoming responses in a timely way. This may cause
> //data to be processed only during calls to validation at the reactor level,
> //which is done once every selectInterval (default value: 1 sec)
>
> //original
> //decryptData();
>
> //change:
> int priorPos = 0;
> while(this.inEncrypted.position() > 0 && this.inEncrypted.position() != priorPos){
> priorPos = this.inEncrypted.position();
> decryptData();
> }
> //MODIFICATION END
>
> // Some decrypted data is available or at the end of stream
> return this.inPlain.position() > 0 || this.status != ACTIVE;
> }
--
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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [jira] Updated: (HTTPCORE-196) Long receive time for chunked
ssl response
Posted by Scott Willey <sw...@soasta.com>.
OK, I will gather that information.
On 5/14/09 2:12 AM, "Oleg Kalnichevski (JIRA)" <ji...@apache.org> wrote:
[ https://issues.apache.org/jira/browse/HTTPCORE-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski updated HTTPCORE-196:
---------------------------------------
Attachment: httpcore-196.patch
There are test cases for chunk coded messages transmitted over SSL encrypted connections in the HttpCore NIO test suite. So, I am not sure this issue is easily reproducible. I suspect this may be a fairly uncommon fringe case. Therefore, it would be helpful to understand the problem a bit better. Could you please provide me with some details regarding the server side setup: OS, web server, SSL library used?
Anyways, please try out the attached patch and let me know if it fixes the problem for you. Please note the patch is against SVN trunk, so you will have to pull the latest code from the SVN repository, apply the patch and compile the source.
Oleg
> Long receive time for chunked ssl response
> ------------------------------------------
>
> Key: HTTPCORE-196
> URL: https://issues.apache.org/jira/browse/HTTPCORE-196
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.0
> Environment: MacOSX (Leopard) / Tomcat / Eclipse
> Reporter: Scott Willey
> Fix For: 4.1
>
> Attachments: httpcore-196.patch
>
>
> Processing a chunked SSL response of 221 characters, I found I was waiting over three seconds for the entire response to be read. Upon investigation, this appears to be happening because the decrypt method in SSLIOSession does not decrypt everything in the encrypted buffer at one go. Because of this, portions of my response didn't get processed via the processing of the events, but rather via the BaseIOReactor's validate method which means I experienced multiple select interval timeouts prior to the message being fully processed. In reviewing the java nio documentation for the unwrap method of the sslEngine, the comments in the javadoc state: "This method will attempt to consume one complete SSL/TLS network packet". It appears that one time through the decrypt method decrypted small packets with almost no data in them, leaving encrypted data waiting. As an experiment, I changed the code in isAppInputReady in SSLIOSession to call decrypt in a loop until everything in the en
> crypted buffer was processed and bingo the response processed in under 5ms.
> Unfortunately, I do not have a "sharable" test case as the server side for this case is inside a corporate filrewall. In theory this should be reproducable with any server over an SSL connection getting a chunked response.
> I have a current "patch" for this issue as follows in SSLIOSession.isAppInputReady, but I will feel much more comfortable with and "official" patch
> public synchronized boolean isAppInputReady() throws IOException {
> int bytesRead = receiveEncryptedData();
> if (bytesRead == -1) {
> //changed per https://issues.apache.org/jira/browse/HTTPCORE-193
> // this.status = CLOSED;
> this.endOfStream = true;
> //end change
> }
> doHandshake();
>
> //MODIFICATION
> //Doing a single decrypt call does not always completely decrypt available
> //data (data read above in receiveEncryptedData). The documentation for
> //sslEngine states that the unwrap method (used in decrypt method)
> //
> // "This method will attempt to consume one complete SSL/TLS network packet"
> //
> //Presumedly, when there are multiple network packets, we only decode one
> //at a time, so multiple calls to decrypt may be necessary to decrypt all
> //we have. If we do not, we will not process all data available and we
> //will fail to process incoming responses in a timely way. This may cause
> //data to be processed only during calls to validation at the reactor level,
> //which is done once every selectInterval (default value: 1 sec)
>
> //original
> //decryptData();
>
> //change:
> int priorPos = 0;
> while(this.inEncrypted.position() > 0 && this.inEncrypted.position() != priorPos){
> priorPos = this.inEncrypted.position();
> decryptData();
> }
> //MODIFICATION END
>
> // Some decrypted data is available or at the end of stream
> return this.inPlain.position() > 0 || this.status != ACTIVE;
> }
--
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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Updated: (HTTPCORE-196) Long receive time for chunked ssl
response
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski updated HTTPCORE-196:
---------------------------------------
Attachment: httpcore-196.patch
There are test cases for chunk coded messages transmitted over SSL encrypted connections in the HttpCore NIO test suite. So, I am not sure this issue is easily reproducible. I suspect this may be a fairly uncommon fringe case. Therefore, it would be helpful to understand the problem a bit better. Could you please provide me with some details regarding the server side setup: OS, web server, SSL library used?
Anyways, please try out the attached patch and let me know if it fixes the problem for you. Please note the patch is against SVN trunk, so you will have to pull the latest code from the SVN repository, apply the patch and compile the source.
Oleg
> Long receive time for chunked ssl response
> ------------------------------------------
>
> Key: HTTPCORE-196
> URL: https://issues.apache.org/jira/browse/HTTPCORE-196
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.0
> Environment: MacOSX (Leopard) / Tomcat / Eclipse
> Reporter: Scott Willey
> Fix For: 4.1
>
> Attachments: httpcore-196.patch
>
>
> Processing a chunked SSL response of 221 characters, I found I was waiting over three seconds for the entire response to be read. Upon investigation, this appears to be happening because the decrypt method in SSLIOSession does not decrypt everything in the encrypted buffer at one go. Because of this, portions of my response didn't get processed via the processing of the events, but rather via the BaseIOReactor's validate method which means I experienced multiple select interval timeouts prior to the message being fully processed. In reviewing the java nio documentation for the unwrap method of the sslEngine, the comments in the javadoc state: "This method will attempt to consume one complete SSL/TLS network packet". It appears that one time through the decrypt method decrypted small packets with almost no data in them, leaving encrypted data waiting. As an experiment, I changed the code in isAppInputReady in SSLIOSession to call decrypt in a loop until everything in the en
> crypted buffer was processed and bingo the response processed in under 5ms.
> Unfortunately, I do not have a "sharable" test case as the server side for this case is inside a corporate filrewall. In theory this should be reproducable with any server over an SSL connection getting a chunked response.
> I have a current "patch" for this issue as follows in SSLIOSession.isAppInputReady, but I will feel much more comfortable with and "official" patch
> public synchronized boolean isAppInputReady() throws IOException {
> int bytesRead = receiveEncryptedData();
> if (bytesRead == -1) {
> //changed per https://issues.apache.org/jira/browse/HTTPCORE-193
> // this.status = CLOSED;
> this.endOfStream = true;
> //end change
> }
> doHandshake();
>
> //MODIFICATION
> //Doing a single decrypt call does not always completely decrypt available
> //data (data read above in receiveEncryptedData). The documentation for
> //sslEngine states that the unwrap method (used in decrypt method)
> //
> // "This method will attempt to consume one complete SSL/TLS network packet"
> //
> //Presumedly, when there are multiple network packets, we only decode one
> //at a time, so multiple calls to decrypt may be necessary to decrypt all
> //we have. If we do not, we will not process all data available and we
> //will fail to process incoming responses in a timely way. This may cause
> //data to be processed only during calls to validation at the reactor level,
> //which is done once every selectInterval (default value: 1 sec)
>
> //original
> //decryptData();
>
> //change:
> int priorPos = 0;
> while(this.inEncrypted.position() > 0 && this.inEncrypted.position() != priorPos){
> priorPos = this.inEncrypted.position();
> decryptData();
> }
> //MODIFICATION END
>
> // Some decrypted data is available or at the end of stream
> return this.inPlain.position() > 0 || this.status != ACTIVE;
> }
--
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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org