Hi Oleg - No worries, I'm just playing around and trying to provide feedback on the beta so whatever your timetable is works for me. I do appreciate your heads-up.
I do have a little more information for whenever you get to it. AbstractHttp1StreamDuplexer.requestShutdown() sets OP_WRITE <https://github.com/apache/httpcomponents-core/blob/44cab548cb4e15d56235aa12eaf0898d028351d0/httpcore5/src/main/java/org/apache/hc/core5/http/impl/nio/AbstractHttp1StreamDuplexer.java#L403> on the session. Selection in SingleCoreIOReactor says the channel is ready to write, but SSLIOSession.isAppOutputReady() returns false because status is CLOSING <https://github.com/apache/httpcomponents-core/blob/44cab548cb4e15d56235aa12eaf0898d028351d0/httpcore5/src/main/java/org/apache/hc/core5/reactor/ssl/SSLIOSession.java#L526> and getHandshakeStatus() is NEED_WRAP <https://github.com/apache/httpcomponents-core/blob/44cab548cb4e15d56235aa12eaf0898d028351d0/httpcore5/src/main/java/org/apache/hc/core5/reactor/ssl/SSLIOSession.java#L527> so the OP_WRITE is not handled and cleared <https://github.com/apache/httpcomponents-core/blob/44cab548cb4e15d56235aa12eaf0898d028351d0/httpcore5/src/main/java/org/apache/hc/core5/reactor/InternalDataChannel.java#L139-L145> . The difference between Conscyprt and the default security provider is that Conscrypt continues to signal OP_WRITE after requestShutdown() and the default provider does not, causing the spin. However, it looks like the actual problem is that with either provider the AbstractHttp1StreamDuplexer.onOutput() shutdown code <https://github.com/apache/httpcomponents-core/blob/44cab548cb4e15d56235aa12eaf0898d028351d0/httpcore5/src/main/java/org/apache/hc/core5/http/impl/nio/AbstractHttp1StreamDuplexer.java#L366-L373> never gets called. In fact, SSLIOSession.close() <https://github.com/apache/httpcomponents-core/blob/44cab548cb4e15d56235aa12eaf0898d028351d0/httpcore5/src/main/java/org/apache/hc/core5/reactor/ssl/SSLIOSession.java#L657> does not appear to be called, from AbstractHttp1StreamDuplexer <https://github.com/apache/httpcomponents-core/blob/44cab548cb4e15d56235aa12eaf0898d028351d0/httpcore5/src/main/java/org/apache/hc/core5/http/impl/nio/AbstractHttp1StreamDuplexer.java#L372> or from anywhere else. I tried hacking SSLIOSession.isAppOutputReady() to test my theory: --- a/httpcore5/src/main/java/org/apache/hc/core5/reactor/ssl/SSLIOSession.java +++ b/httpcore5/src/main/java/org/apache/hc/core5/reactor/ssl/SSLIOSession.java @@ -523,8 +523,9 @@ public boolean isAppOutputReady() throws IOException { this.session.getLock().lock(); try { return (this.appEventMask & SelectionKey.OP_WRITE) > 0 - && this.status == ACTIVE - && this.sslEngine.getHandshakeStatus() == HandshakeStatus.NOT_HANDSHAKING; + && ((this.status == ACTIVE + && this.sslEngine.getHandshakeStatus() == HandshakeStatus.NOT_HANDSHAKING) + || this.status == CLOSING); } finally { this.session.getLock().unlock(); } This is probably not the appropriate fix, but it does call SSLIOSession.close() with both providers and does not spin with Conscrypt. I think the fact that SSLIOSession.close() is never called is enough to qualify this as a bug, so I'll file it on JIRA. Roy On Fri, Sep 13, 2019 at 5:39 AM Oleg Kalnichevski <[email protected]> wrote: > On Thu, 2019-09-12 at 14:24 -0700, Roy Hashimoto wrote: > > In the attached HttpCore 5.0 server program (gist), I'm using > > Conscrypt for the TLS provider. It works, but I noticed that after > > each request the CPU gets pegged to 100% usage. > > > > I'm using org.conscrypt:conscrypt-openjdk-uber:2.2.1 and HttpCore 5.0 > > from source at the HTTPCORE-599 fix. I see the same behavior on macOS > > Mojave and Debian Jessie. I'm using Conscrypt for ALPN on Java 8, > > though the minimal sample program here doesn't enable it. > > > > What I see in the debugger is that SingleCoreIOReactor.doExecute() is > > repeatedly called with this line returning readyCount=1. It looks > > like the selector is set to SelectionKey.OP_WRITE, > > > > Not sure if this is a HttpCore bug or a Conscrypt bug. I looked > > through the Conscrypt issues but nothing caught my attention as > > related. > > > > Roy > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > Roy > > I am a bit tied up with other things at the moment (like trying to not > be a complete failure as a father to a 9 year old daughter) but I will > take a look at this issue next week. Anyway I am in the process of > making substantial changes to the TLS/SSL NIO layer and it likely makes > no sense to deal with issue until thatthe TLS/SSL NIO refactoring is > complete. > > Cheers > > Oleg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
