Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've got Tomcat 7.0.12 using APR and OpenSSL. Everything appears to be working just fine, but I'm seeing some NullPointerException stack traces showing up in the logs. As far as I can tell, it appears to be happening whenever a client connects, initiates the TLS handshake, receives the server's certificate and then immediately closes the TCP connection without proceeding with the key exchange.

I'm using a self-signed certificate, so this happens (for example) whenever the browser doesn't trust the certificate and must ask the user to verify it. The client obviously doesn't care since it's the one that disconnected.

DEBUG ["http-apr-443"-exec-3] Handshake failed: error:00000000:lib(0):func(0):reason(0)
ERROR ["http-apr-443"-exec-3] org.apache.coyote.http11.Http11AprProtocol: Error reading request, ignored
    at org.apache.coyote.http11.Http11AprProcessor.process(
    at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$ Source)
    at Source)

If the client doesn't disconnect after receiving the certificate from the server, and instead proceeds with the handshake, everything works as expected with no errors in the logs. Perhaps it's just cosmetic, but perhaps I've done something wrong.

The connector is configured thusly (more or less copied from an example somewhere):


Edit to add, FWIW, I just noticed there's a similar stack trace ending up in catalina.out at the same time:

Exception in thread ""http-apr-443"-exec-3" java.lang.NullPointerException
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$ Source)
    at Source)
share|improve this question

This is a red herring; its catching the exception from the connection handler and dumping a trace. Its cryptic errors like this that cause me to suggest using mod_jk for forwarding requests to the AJP connector on Tomcat.

share|improve this answer
Or better still, mod_proxy_ajp. – EJP Jul 12 '12 at 4:32
Personally, I found mod_jk significantly easier to manage, but you're right--mod_proxy (which will use mod_proxy_ajp when using ajp13 as a protocol)--is another alternative. :) – Andrew M. Jul 12 '12 at 21:19

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.