You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Sandeep Tamhankar (JIRA)" <ji...@apache.org> on 2012/05/02 18:24:50 UTC
[jira] [Commented] (HTTPCORE-298) SSLIOSession state can get out of
sync with underlying IOSession state
[ https://issues.apache.org/jira/browse/HTTPCORE-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13266674#comment-13266674 ]
Sandeep Tamhankar commented on HTTPCORE-298:
--------------------------------------------
Yes, I agree... and I was hoping that you'd have an epiphany based on my description! ;)
I don't have a reproducible case, so I tried to track the sessions in AbstractIOReactor.sessions just walking through code. My guess is that there's some sort of abnormal termination of the connection that causes the IOSession to be added to AbstractIOReactor.closedSessions.
We're talking about a load situation here; maybe a socket connect timeout or read timeout? I see that queueClosedSession has many callers and the code path that leads to the call is always from a CancelledKeyException... except in processNewChannels, where the IOSession is created with a close callback to call queueClosedSession.
I'm new to this code-base, so I'm hoping you can deduce the core issue from here.
> SSLIOSession state can get out of sync with underlying IOSession state
> ----------------------------------------------------------------------
>
> Key: HTTPCORE-298
> URL: https://issues.apache.org/jira/browse/HTTPCORE-298
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.1.4
> Environment: observed on Ubuntu 10.0.4, but I think it could happen anywhere
> Reporter: Sandeep Tamhankar
> Fix For: 4.2.1
>
>
> Under heavy load, I've observed my application call SSLIOSession.isClosed() to decide if the connection can be reused for a pending outbound request. It returns false. However, the underlying IOSessionImpl is actually closed. I believe that AbstractIOReactor also holds a reference to that underlying IOSession and it can be independently closed from that end.
> My proposed fix is simple (and very non-invasive, but possibly not correct in that I don't have the SSLIOSession update its state upon discovering that the underlying IOSession is closed): update SSLIOSession.isClosed as followed:
> public boolean isClosed() {
> return this.status >= CLOSING || this.session.isClosed();
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org