You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Avanish Kant <AK...@manh.com> on 2016/09/19 09:54:52 UTC

Tomcat 8.5.5: SecureNioChannel.handshake throws NullPointerException during server startup

When Tomcat 8.5.5 got released recently, I was working on upgrading my existing app from Tomcat 8.5.4 to 8.5.5.

It seems that server startup goes through fine with message (INFO: Server startup in 16323 ms) printed at the end, and
I am even able to access the application fine.

My only concern is that I see following NullPointerException logged right after successful startup message.
Please note that this exception is thrown even before I make an attempt to access the application from browser.

Sep 19, 2016 2:30:26 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 16323 ms
Sep 19, 2016 2:30:26 PM org.apache.tomcat.util.net.NioEndpoint$SocketProcessor doRun
SEVERE: java.lang.NullPointerException
        at org.apache.tomcat.util.net.SecureNioChannel.handshake(SecureNioChannel.java:182)
        at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1387)
        at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
        at java.lang.Thread.run(Thread.java:745)


Following is the connector configuration I am using. The same connector configuration when used with version 8.5.4 does not throw this error.

    <Connector port="${appserver.httpssoap.port}" protocol="org.apache.coyote.http11.Http11NioProtocol"
        proxyPort="${appserver.httpssoap.port}" proxyName="${ucl.external.hostname}"
        SSLEnabled="true" scheme="https" secure="true"
        compression="512" compressableMimeType="text/html,text/xml,text/css,text/plain,text/javascript,application/javascript"
        server="Manhattan Associates">
        <SSLHostConfig certificateVerification="optional" truststoreFile="${catalina.base}/conf/mip-trustcerts.jks" truststorePassword="idpkeys"
            ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256,SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,SSL_ECDH_RSA_WITH_AES_128_CBC_SHA256,SSL_DHE_RSA_WITH_AES_128_CBC_SHA256,SSL_DHE_DSS_WITH_AES_128_CBC_SHA256,SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA,SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA,SSL_ECDH_RSA_WITH_AES_128_CBC_SHA,SSL_DHE_RSA_WITH_AES_128_CBC_SHA,SSL_DHE_DSS_WITH_AES_128_CBC_SHA"
            protocols="TLSv1.2" >
            <Certificate certificateKeystoreFile="${catalina.base}/conf/mip-keys.jks" certificateKeystorePassword="idpkeys"
                certificateKeyAlias="mip" type="RSA" />
        </SSLHostConfig>
    </Connector>

I see the following mentioned in release notes for 8.5.5, but not sure if what exactly has changed and that requires any changes to my connector configuration.

  *   Correct regressions in TLS handshake and server certificate handling.

Extra bit of information that may help:
One change that I did try is to change "Http11NioProtocol" to "Http11Nio2Protocol" just to see how it goes and noticed that this Exception is not thrown for NIO2.

I am suspecting that I have hit some bug with "Http11NioProtocol" and appreciate any kind of help/tips you can provide.

Thanks,
Avanish


Re: Tomcat 8.5.5: SecureNioChannel.handshake throws NullPointerException during server startup

Posted by Rémy Maucherat <re...@apache.org>.
2016-09-19 11:54 GMT+02:00 Avanish Kant <AK...@manh.com>:

> Extra bit of information that may help:
> One change that I did try is to change "Http11NioProtocol" to
> "Http11Nio2Protocol" just to see how it goes and noticed that this
> Exception is not thrown for NIO2.
>
> I am suspecting that I have hit some bug with "Http11NioProtocol" and
> appreciate any kind of help/tips you can provide.
>
> The problem was fixed and it will be in the next build, 8.5.6. NIO2
doesn't have the problem since the IO read EOF result didn't have any
special handling (so it was fatal).

Rémy