Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Date: Thu, 15 Nov 2012 21:53:13 +0000 (UTC)
From: "Gary Gregory (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Message-ID: <1263820914.121185.1353016393162.JavaMail.jiratomcat@arcas>
In-Reply-To: <469107921.119906.1352998092906.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (HTTPCORE-322) SSLIOSession infinite loop after
 alert during handshake
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HTTPCORE-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13498373#comment-13498373 ] 

Gary Gregory commented on HTTPCORE-322:
---------------------------------------

The idea is to be able to create a reproducible @Test test case that is not dependent on timing. But this does seem like a lot of work...

Gary
                
> SSLIOSession infinite loop after alert during handshake
> -------------------------------------------------------
>
>                 Key: HTTPCORE-322
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-322
>             Project: HttpComponents HttpCore
>          Issue Type: Bug
>          Components: HttpCore NIO
>            Reporter: Paul Donohue
>            Priority: Critical
>
> I have an application using httpcore-nio that occasionally gets stuck in an infinite loop in SSLIOSession:
> "I/O dispatcher 1" prio=10 tid=0x00002aaab82da000 nid=0x5448 runnable [0x000000004271c000]
>    java.lang.Thread.State: RUNNABLE
>         at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:767)
>         - locked <0x00000000a4f03420> (a sun.security.ssl.SSLEngineImpl)
>         at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:719)
>         - locked <0x00000000a51faaa0> (a java.lang.Object)
>         at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
>         at org.apache.http.nio.reactor.ssl.SSLIOSession.doUnwrap(SSLIOSession.java:228)
>         at org.apache.http.nio.reactor.ssl.SSLIOSession.decryptData(SSLIOSession.java:348)
>         at org.apache.http.nio.reactor.ssl.SSLIOSession.isAppInputReady(SSLIOSession.java:371)
>         - locked <0x00000000a4f03498> (a org.apache.http.nio.reactor.ssl.SSLIOSession)
>         at org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady(AbstractIODispatch.java:118)
>         at org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:160)
>         at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:342)
>         at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:320)
>         at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:280)
>         at org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:106)
>         at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:604)
>         at java.lang.Thread.run(Thread.java:636)
> In the above example, I was able to determine that this behavior was caused by a client sending a ClientHello that resumed an established session, immediately followed by a CloseNotify Alert.  This sequence only sometimes triggers the infinite loop, so the problem appears to be timing related.  I get the feeling that there are other sequences that may trigger this, but I don't have any other concrete examples at the moment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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