hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandeep Tamhankar (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCORE-298) SSLIOSession state can get out of sync with underlying IOSession state
Date Wed, 02 May 2012 16:24:50 GMT

    [ 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

View raw message