You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Asankha C. Perera (JIRA)" <ji...@apache.org> on 2009/03/18 03:37:50 UTC
[jira] Created: (HTTPCORE-193) A Connection close could cause an
SSLIOSession to be incorrectly considered as closed in some environments
A Connection close could cause an SSLIOSession to be incorrectly considered as closed in some environments
----------------------------------------------------------------------------------------------------------
Key: HTTPCORE-193
URL: https://issues.apache.org/jira/browse/HTTPCORE-193
Project: HttpComponents HttpCore
Issue Type: Bug
Components: HttpCore NIO
Affects Versions: 4.0
Environment: This has been seen by an Apache Synapse user, as well as by me on the Hudon build machine
SunOS hudson.zones.apache.org 5.10 Generic_137112-02 i86pc i386 i86pc
This is not seen on my Linux box, Linux asankha 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008
x86_64 GNU/Linux
Reporter: Asankha C. Perera
Assignee: Asankha C. Perera
Fix For: 4.1
Attachments: HTTPCORE-193.patch
This could be seen on the SunOS machine Hudson, and also if a breakpoint is placed at the line receiveEncryptedData() in SSLIOSession:isAppInputReady() to delay its execution slightly
It seems like the following lines are the cause of the problem:
int bytesRead = receiveEncryptedData();
if (bytesRead == -1) {
this.status = CLOSED;
}
The Channel not having any more bytes does not indicate a close, since there still could be unencrypted data. Just removing the lines that mark the session as closed seems to fix the issue - but should be reviewed.
--
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] Commented: (HTTPCORE-193) A Connection close could cause an
SSLIOSession to be incorrectly considered as closed in some environments
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683033#action_12683033 ]
Sebb commented on HTTPCORE-193:
-------------------------------
Sorry, you're right (*) - I'd tried to apply the patch in my head instead of actually doing it and checking the references to the variable.
It would be a slight waste to make it volatile.
(*) Actually there are some non-synch public methods - e.g. close(), isClosed(), getStatus(), but they access a volatile var.
channel() returns a final so that's OK.
> A Connection close could cause an SSLIOSession to be incorrectly considered as closed in some environments
> ----------------------------------------------------------------------------------------------------------
>
> Key: HTTPCORE-193
> URL: https://issues.apache.org/jira/browse/HTTPCORE-193
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.0
> Environment: This has been seen by an Apache Synapse user, as well as by me on the Hudon build machine
> SunOS hudson.zones.apache.org 5.10 Generic_137112-02 i86pc i386 i86pc
> This is not seen on my Linux box, Linux asankha 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008
> x86_64 GNU/Linux
> Reporter: Asankha C. Perera
> Assignee: Asankha C. Perera
> Fix For: 4.1
>
> Attachments: HTTPCORE-193.patch, HTTPCORE-193.patch, linux.log, solaris.log
>
>
> This could be seen on the SunOS machine Hudson, and also if a breakpoint is placed at the line receiveEncryptedData() in SSLIOSession:isAppInputReady() to delay its execution slightly
> It seems like the following lines are the cause of the problem:
> int bytesRead = receiveEncryptedData();
> if (bytesRead == -1) {
> this.status = CLOSED;
> }
> The Channel not having any more bytes does not indicate a close, since there still could be unencrypted data. Just removing the lines that mark the session as closed seems to fix the issue - but should be reviewed.
--
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] Commented: (HTTPCORE-193) A Connection close could cause an
SSLIOSession to be incorrectly considered as closed in some environments
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683029#action_12683029 ]
Sebb commented on HTTPCORE-193:
-------------------------------
I think
private boolean endOfStream;
should probably be
private volatile boolean endOfStream;
It looks like the variable is referenced from a non-synch public method
> A Connection close could cause an SSLIOSession to be incorrectly considered as closed in some environments
> ----------------------------------------------------------------------------------------------------------
>
> Key: HTTPCORE-193
> URL: https://issues.apache.org/jira/browse/HTTPCORE-193
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.0
> Environment: This has been seen by an Apache Synapse user, as well as by me on the Hudon build machine
> SunOS hudson.zones.apache.org 5.10 Generic_137112-02 i86pc i386 i86pc
> This is not seen on my Linux box, Linux asankha 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008
> x86_64 GNU/Linux
> Reporter: Asankha C. Perera
> Assignee: Asankha C. Perera
> Fix For: 4.1
>
> Attachments: HTTPCORE-193.patch, HTTPCORE-193.patch, linux.log, solaris.log
>
>
> This could be seen on the SunOS machine Hudson, and also if a breakpoint is placed at the line receiveEncryptedData() in SSLIOSession:isAppInputReady() to delay its execution slightly
> It seems like the following lines are the cause of the problem:
> int bytesRead = receiveEncryptedData();
> if (bytesRead == -1) {
> this.status = CLOSED;
> }
> The Channel not having any more bytes does not indicate a close, since there still could be unencrypted data. Just removing the lines that mark the session as closed seems to fix the issue - but should be reviewed.
--
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] Commented: (HTTPCORE-193) A Connection close could cause an
SSLIOSession to be incorrectly considered as closed in some environments
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12682995#action_12682995 ]
Oleg Kalnichevski commented on HTTPCORE-193:
--------------------------------------------
Asankha,
How exactly does the problem manifest itself?
Usually if a channel does not have any input it should return 0, not -1. -1 is meant to indicate end-of-stream, which means the channel has been closed by the peer. Does SSLIOSession fail to correctly process data still remaining in the input buffer?
My concern is if we remove the check altogether SSLIOSession will no longer be able to handle situations when a connection is terminated forcibly by closing the socket without proper SSL handshaking, which is not that uncommon.
Oleg
> A Connection close could cause an SSLIOSession to be incorrectly considered as closed in some environments
> ----------------------------------------------------------------------------------------------------------
>
> Key: HTTPCORE-193
> URL: https://issues.apache.org/jira/browse/HTTPCORE-193
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.0
> Environment: This has been seen by an Apache Synapse user, as well as by me on the Hudon build machine
> SunOS hudson.zones.apache.org 5.10 Generic_137112-02 i86pc i386 i86pc
> This is not seen on my Linux box, Linux asankha 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008
> x86_64 GNU/Linux
> Reporter: Asankha C. Perera
> Assignee: Asankha C. Perera
> Fix For: 4.1
>
> Attachments: HTTPCORE-193.patch
>
>
> This could be seen on the SunOS machine Hudson, and also if a breakpoint is placed at the line receiveEncryptedData() in SSLIOSession:isAppInputReady() to delay its execution slightly
> It seems like the following lines are the cause of the problem:
> int bytesRead = receiveEncryptedData();
> if (bytesRead == -1) {
> this.status = CLOSED;
> }
> The Channel not having any more bytes does not indicate a close, since there still could be unencrypted data. Just removing the lines that mark the session as closed seems to fix the issue - but should be reviewed.
--
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] Commented: (HTTPCORE-193) A Connection close could cause an
SSLIOSession to be incorrectly considered as closed in some environments
Posted by "Asankha C. Perera (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683003#action_12683003 ]
Asankha C. Perera commented on HTTPCORE-193:
--------------------------------------------
Hi Oleg
This happens with SSL and when a "Connection: close" response is received. Additionally, in Linux you will not notice this, unless you put a fake breakpoint at the line receiveEncryptedData() in SSLIOSession:isAppInputReady() to delay. But this occurs normally / and intermittently on the Hudson machine running SunOS.
Since the channel has been closed by the peer, it returns -1, but the SSLIOSession has unencrypted data as can be seen below, and this seems to be a case of the SSLIOSession failing to correctly process data in the buffers.
2009-03-17 02:31:36,929 [-] [https-Sender I/O dispatcher-1] DEBUG SSLIOSession I/O session sslclient-2 [interested ops: [r]; ready ops: [r]][SSL handshake status: NOT_HANDSHAKING][469][0][0][0]: 141 bytes read
2009-03-17 02:31:36,937 [-] [https-Sender I/O dispatcher-1] DEBUG SSLIOSession I/O session sslclient-2 [interested ops: [r]; ready ops: [r]][SSL handshake status: NOT_HANDSHAKING][469][0][0][0]: 0 bytes read
[Raw read (bb)]: length = 26
0000: 17 03 01 00 15 F1 BB 57 48 D7 17 49 29 2F 28 8D .......WH..I)/(.
0010: A5 AC 6D 1E F8 8A F7 C9 C7 70 ..m......p
Padded plaintext after DECRYPTION: len = 21
0000: 31 35 65 0D 0A C7 B4 7D 2D DC AD D1 86 99 F3 BB 15e.....-.......
0010: 0B C0 24 95 23 ..$.#
2009-03-17 02:31:36,938 [-] [https-Sender I/O dispatcher-1] DEBUG SSLIOSession I/O session sslclient-2 [interested ops: [r]; ready ops: [r]][SSL handshake status: NOT_HANDSHAKING][443][0][0][0]: 5 bytes read
2009-03-17 02:31:36,988 [-] [https-Sender I/O dispatcher-1] DEBUG SSLIOSession I/O session sslclient-2 [invalid][SSL handshake status: NOT_HANDSHAKING][443][0][0][0]: Shutdown
2009-03-17 02:31:36,989 [-] [HttpClientWorker-1] WARN ClientWorker Unexpected response received. HTTP response code : 200 HTTP status : OK exception : com.ctc.wstx.exc.WstxEOFException: Unexpected EOF in prolog
at [row,col {unknown-source}]: [1,0]
The channel closure is correctly processed by the rest of the logic, and I think the channel alone returning -1 cannot be always/fully assumed to indicate the end of the SSLIOSession
thanks
asankha
> A Connection close could cause an SSLIOSession to be incorrectly considered as closed in some environments
> ----------------------------------------------------------------------------------------------------------
>
> Key: HTTPCORE-193
> URL: https://issues.apache.org/jira/browse/HTTPCORE-193
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.0
> Environment: This has been seen by an Apache Synapse user, as well as by me on the Hudon build machine
> SunOS hudson.zones.apache.org 5.10 Generic_137112-02 i86pc i386 i86pc
> This is not seen on my Linux box, Linux asankha 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008
> x86_64 GNU/Linux
> Reporter: Asankha C. Perera
> Assignee: Asankha C. Perera
> Fix For: 4.1
>
> Attachments: HTTPCORE-193.patch, linux.log, solaris.log
>
>
> This could be seen on the SunOS machine Hudson, and also if a breakpoint is placed at the line receiveEncryptedData() in SSLIOSession:isAppInputReady() to delay its execution slightly
> It seems like the following lines are the cause of the problem:
> int bytesRead = receiveEncryptedData();
> if (bytesRead == -1) {
> this.status = CLOSED;
> }
> The Channel not having any more bytes does not indicate a close, since there still could be unencrypted data. Just removing the lines that mark the session as closed seems to fix the issue - but should be reviewed.
--
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] Commented: (HTTPCORE-193) A Connection close could cause an
SSLIOSession to be incorrectly considered as closed in some environments
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683031#action_12683031 ]
Oleg Kalnichevski commented on HTTPCORE-193:
--------------------------------------------
All public methods of SSLIOSession are synchronized, so access to the variable should always be protected by the instance mutex. However, there is no harm making the variable volatile.
Oleg
> A Connection close could cause an SSLIOSession to be incorrectly considered as closed in some environments
> ----------------------------------------------------------------------------------------------------------
>
> Key: HTTPCORE-193
> URL: https://issues.apache.org/jira/browse/HTTPCORE-193
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.0
> Environment: This has been seen by an Apache Synapse user, as well as by me on the Hudon build machine
> SunOS hudson.zones.apache.org 5.10 Generic_137112-02 i86pc i386 i86pc
> This is not seen on my Linux box, Linux asankha 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008
> x86_64 GNU/Linux
> Reporter: Asankha C. Perera
> Assignee: Asankha C. Perera
> Fix For: 4.1
>
> Attachments: HTTPCORE-193.patch, HTTPCORE-193.patch, linux.log, solaris.log
>
>
> This could be seen on the SunOS machine Hudson, and also if a breakpoint is placed at the line receiveEncryptedData() in SSLIOSession:isAppInputReady() to delay its execution slightly
> It seems like the following lines are the cause of the problem:
> int bytesRead = receiveEncryptedData();
> if (bytesRead == -1) {
> this.status = CLOSED;
> }
> The Channel not having any more bytes does not indicate a close, since there still could be unencrypted data. Just removing the lines that mark the session as closed seems to fix the issue - but should be reviewed.
--
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-193) A Connection close could cause an
SSLIOSession to be incorrectly considered as closed in some environments
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski updated HTTPCORE-193:
---------------------------------------
Attachment: HTTPCORE-193.patch
Asankha,
Could you please test a slightly different patch? Please let me know if that fixes the problem for you.
Oleg
> A Connection close could cause an SSLIOSession to be incorrectly considered as closed in some environments
> ----------------------------------------------------------------------------------------------------------
>
> Key: HTTPCORE-193
> URL: https://issues.apache.org/jira/browse/HTTPCORE-193
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.0
> Environment: This has been seen by an Apache Synapse user, as well as by me on the Hudon build machine
> SunOS hudson.zones.apache.org 5.10 Generic_137112-02 i86pc i386 i86pc
> This is not seen on my Linux box, Linux asankha 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008
> x86_64 GNU/Linux
> Reporter: Asankha C. Perera
> Assignee: Asankha C. Perera
> Fix For: 4.1
>
> Attachments: HTTPCORE-193.patch, HTTPCORE-193.patch, linux.log, solaris.log
>
>
> This could be seen on the SunOS machine Hudson, and also if a breakpoint is placed at the line receiveEncryptedData() in SSLIOSession:isAppInputReady() to delay its execution slightly
> It seems like the following lines are the cause of the problem:
> int bytesRead = receiveEncryptedData();
> if (bytesRead == -1) {
> this.status = CLOSED;
> }
> The Channel not having any more bytes does not indicate a close, since there still could be unencrypted data. Just removing the lines that mark the session as closed seems to fix the issue - but should be reviewed.
--
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-193) A Connection close could cause an
SSLIOSession to be incorrectly considered as closed in some environments
Posted by "Asankha C. Perera (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Asankha C. Perera updated HTTPCORE-193:
---------------------------------------
Attachment: HTTPCORE-193.patch
Hi Oleg
Would you be able to review this one?
thanks
asankha
> A Connection close could cause an SSLIOSession to be incorrectly considered as closed in some environments
> ----------------------------------------------------------------------------------------------------------
>
> Key: HTTPCORE-193
> URL: https://issues.apache.org/jira/browse/HTTPCORE-193
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.0
> Environment: This has been seen by an Apache Synapse user, as well as by me on the Hudon build machine
> SunOS hudson.zones.apache.org 5.10 Generic_137112-02 i86pc i386 i86pc
> This is not seen on my Linux box, Linux asankha 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008
> x86_64 GNU/Linux
> Reporter: Asankha C. Perera
> Assignee: Asankha C. Perera
> Fix For: 4.1
>
> Attachments: HTTPCORE-193.patch
>
>
> This could be seen on the SunOS machine Hudson, and also if a breakpoint is placed at the line receiveEncryptedData() in SSLIOSession:isAppInputReady() to delay its execution slightly
> It seems like the following lines are the cause of the problem:
> int bytesRead = receiveEncryptedData();
> if (bytesRead == -1) {
> this.status = CLOSED;
> }
> The Channel not having any more bytes does not indicate a close, since there still could be unencrypted data. Just removing the lines that mark the session as closed seems to fix the issue - but should be reviewed.
--
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-193) A Connection close could cause an
SSLIOSession to be incorrectly considered as closed in some environments
Posted by "Asankha C. Perera (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Asankha C. Perera updated HTTPCORE-193:
---------------------------------------
Attachment: linux.log
solaris.log
Logs for Solaris and Linux (normal / successful case)
> A Connection close could cause an SSLIOSession to be incorrectly considered as closed in some environments
> ----------------------------------------------------------------------------------------------------------
>
> Key: HTTPCORE-193
> URL: https://issues.apache.org/jira/browse/HTTPCORE-193
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.0
> Environment: This has been seen by an Apache Synapse user, as well as by me on the Hudon build machine
> SunOS hudson.zones.apache.org 5.10 Generic_137112-02 i86pc i386 i86pc
> This is not seen on my Linux box, Linux asankha 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008
> x86_64 GNU/Linux
> Reporter: Asankha C. Perera
> Assignee: Asankha C. Perera
> Fix For: 4.1
>
> Attachments: HTTPCORE-193.patch, linux.log, solaris.log
>
>
> This could be seen on the SunOS machine Hudson, and also if a breakpoint is placed at the line receiveEncryptedData() in SSLIOSession:isAppInputReady() to delay its execution slightly
> It seems like the following lines are the cause of the problem:
> int bytesRead = receiveEncryptedData();
> if (bytesRead == -1) {
> this.status = CLOSED;
> }
> The Channel not having any more bytes does not indicate a close, since there still could be unencrypted data. Just removing the lines that mark the session as closed seems to fix the issue - but should be reviewed.
--
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] Commented: (HTTPCORE-193) A Connection close could cause an
SSLIOSession to be incorrectly considered as closed in some environments
Posted by "Asankha C. Perera (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683292#action_12683292 ]
Asankha C. Perera commented on HTTPCORE-193:
--------------------------------------------
Hi Oleg
This patch works fine for me on Hudson and for the user on the real environment. Will check it in.
Many thanks
asankha
> A Connection close could cause an SSLIOSession to be incorrectly considered as closed in some environments
> ----------------------------------------------------------------------------------------------------------
>
> Key: HTTPCORE-193
> URL: https://issues.apache.org/jira/browse/HTTPCORE-193
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.0
> Environment: This has been seen by an Apache Synapse user, as well as by me on the Hudon build machine
> SunOS hudson.zones.apache.org 5.10 Generic_137112-02 i86pc i386 i86pc
> This is not seen on my Linux box, Linux asankha 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008
> x86_64 GNU/Linux
> Reporter: Asankha C. Perera
> Assignee: Asankha C. Perera
> Fix For: 4.1
>
> Attachments: HTTPCORE-193.patch, HTTPCORE-193.patch, linux.log, solaris.log
>
>
> This could be seen on the SunOS machine Hudson, and also if a breakpoint is placed at the line receiveEncryptedData() in SSLIOSession:isAppInputReady() to delay its execution slightly
> It seems like the following lines are the cause of the problem:
> int bytesRead = receiveEncryptedData();
> if (bytesRead == -1) {
> this.status = CLOSED;
> }
> The Channel not having any more bytes does not indicate a close, since there still could be unencrypted data. Just removing the lines that mark the session as closed seems to fix the issue - but should be reviewed.
--
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] Commented: (HTTPCORE-193) A Connection close could cause an
SSLIOSession to be incorrectly considered as closed in some environments
Posted by "Asankha C. Perera (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683037#action_12683037 ]
Asankha C. Perera commented on HTTPCORE-193:
--------------------------------------------
Thanks Oleg and Sebb for your valued input. I have requested the user to test again with the patch provided by Oleg against the real endpoint. I should know the results by tomorrow and I will update again
regards
asankha
> A Connection close could cause an SSLIOSession to be incorrectly considered as closed in some environments
> ----------------------------------------------------------------------------------------------------------
>
> Key: HTTPCORE-193
> URL: https://issues.apache.org/jira/browse/HTTPCORE-193
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.0
> Environment: This has been seen by an Apache Synapse user, as well as by me on the Hudon build machine
> SunOS hudson.zones.apache.org 5.10 Generic_137112-02 i86pc i386 i86pc
> This is not seen on my Linux box, Linux asankha 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008
> x86_64 GNU/Linux
> Reporter: Asankha C. Perera
> Assignee: Asankha C. Perera
> Fix For: 4.1
>
> Attachments: HTTPCORE-193.patch, HTTPCORE-193.patch, linux.log, solaris.log
>
>
> This could be seen on the SunOS machine Hudson, and also if a breakpoint is placed at the line receiveEncryptedData() in SSLIOSession:isAppInputReady() to delay its execution slightly
> It seems like the following lines are the cause of the problem:
> int bytesRead = receiveEncryptedData();
> if (bytesRead == -1) {
> this.status = CLOSED;
> }
> The Channel not having any more bytes does not indicate a close, since there still could be unencrypted data. Just removing the lines that mark the session as closed seems to fix the issue - but should be reviewed.
--
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-193) A Connection close could cause an
SSLIOSession to be incorrectly considered as closed in some environments
Posted by "Asankha C. Perera (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Asankha C. Perera resolved HTTPCORE-193.
----------------------------------------
Resolution: Fixed
Thanks Oleg for improving the patch
> A Connection close could cause an SSLIOSession to be incorrectly considered as closed in some environments
> ----------------------------------------------------------------------------------------------------------
>
> Key: HTTPCORE-193
> URL: https://issues.apache.org/jira/browse/HTTPCORE-193
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.0
> Environment: This has been seen by an Apache Synapse user, as well as by me on the Hudon build machine
> SunOS hudson.zones.apache.org 5.10 Generic_137112-02 i86pc i386 i86pc
> This is not seen on my Linux box, Linux asankha 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008
> x86_64 GNU/Linux
> Reporter: Asankha C. Perera
> Assignee: Asankha C. Perera
> Fix For: 4.1
>
> Attachments: HTTPCORE-193.patch, HTTPCORE-193.patch, linux.log, solaris.log
>
>
> This could be seen on the SunOS machine Hudson, and also if a breakpoint is placed at the line receiveEncryptedData() in SSLIOSession:isAppInputReady() to delay its execution slightly
> It seems like the following lines are the cause of the problem:
> int bytesRead = receiveEncryptedData();
> if (bytesRead == -1) {
> this.status = CLOSED;
> }
> The Channel not having any more bytes does not indicate a close, since there still could be unencrypted data. Just removing the lines that mark the session as closed seems to fix the issue - but should be reviewed.
--
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