[
https://issues.apache.org/jira/browse/HTTPCORE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13581779#comment-13581779
]
Scott Stanton commented on HTTPCORE-334:
----------------------------------------
It looks like the culprit is in SSLIOSession.java. When the server doesn't
send any data back to the client, the session ends up in the NEED_UNWRAP state
with the appEventMask indicating a desire to write. updateEventMask ends up
setting both read and write in the event mask despite there being no data in
the handshake write buffer.
I'm not sure why updateEventMask is mixing in the appEventMask during
handshaking. That seems wrong. I have added a patch with a unittest and a
possible fix for this problem. I'm not sure if it is the right approach, but
it passes all of the tests I have tried.
> https request to a non-responsive but alive port results in a busy loop in
> one thread
> -------------------------------------------------------------------------------------
>
> Key: HTTPCORE-334
> URL: https://issues.apache.org/jira/browse/HTTPCORE-334
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.2.4
> Environment: Windows 8 64-bit
> JDK 1.7.0_11
> Reporter: Scott Stanton
> Attachments: HTTPCORE-334.patch
>
>
> Steps to reproduce:
> * Start a process that listens on a socket, accepts the connection, but does
> not read any data
> * In a second processs, establish an https connection
> At this point, one reactor thread will go into a busy loop getting writable
> events but not writing any data. As far as I can tell, this continues
> indefinitely until either the client or the server closes the port. Ideally
> this scenario would result in no cpu overhead as the selector should only be
> waiting for read events if it doesn't have any data to write. Eventually it
> should hit an idle timeout so the client can recover from a non responsive
> server.
> Here is a stack snapshot for the busy thread:
> Agent-003 [RUNNABLE, IN_NATIVE] CPU time: 39s
> com.yourkit.probes.Table.createRow()
> com.yourkit.probes.Table.createRow(int)
> com.yourkit.probes.builtin.Sockets$SocketChannel_write_Probe.onEnter(SocketChannel)
> sun.nio.ch.SocketChannelImpl.write(ByteBuffer)
> org.apache.http.nio.reactor.ssl.SSLIOSession.sendEncryptedData()
> org.apache.http.nio.reactor.ssl.SSLIOSession.outboundTransport()
> org.apache.http.impl.nio.reactor.AbstractIODispatch.outputReady(IOSession)
> org.apache.http.impl.nio.reactor.BaseIOReactor.writable(SelectionKey)
> org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(SelectionKey)
> org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(Set)
> org.apache.http.impl.nio.reactor.AbstractIOReactor.execute()
> org.apache.http.impl.nio.reactor.BaseIOReactor.execute(IOEventDispatch)
> org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run()
> java.lang.Thread.run()
> com.electriccloud.util.EcThread.run()
--
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: [email protected]
For additional commands, e-mail: [email protected]
