tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Tomcat 8.5 - APR 1.2.10 SSL CPU issue ?
Date Thu, 05 Jan 2017 22:30:19 GMT
On 05/01/2017 22:01, David Oswell wrote:
> After some more digging I've been able to further narrow down the problem
> somewhat, but still not able to pin point the exact cause;
> The issue is not load related, but rather seems to be related to the timing
> of the TCP connection being closed.
> Depending on the timing the poller and exec appear to get into a loop -
> drilled thsi down to an error status returned in AprEndpoint - which might
> need to be thrown as an exception rather than return 0 from
> the fillReadBuffer in AprEndpoint.
> Poller thread - AprEndpoint:1573 - Poller(ID 55) wakes ups
> Poller thread - AprEndpoint:1652 - Poller adds socket to timeout
> Poller thread - AprEndpoint:1675 - Poller gets rv = 1
> Poller thread - AprEndpoint:1694 - Poller gets connection (socket
> Id 565911936 )
> Poller thread - AprEndpoint:1731 - Poller processesSocket as socket event
> Poller thread - AbstractEndpoint:903   - executor executes
> AprEndpoint$SocketProcessor (id 63)  -> No exception thrown.
> Exec thread - AprEndpoint:2403 - Socket.recvb result = -20014
> Interesting comment ?  at AprEndpoint:2445 :
>             } else if (-result == Status.APR_EGENERAL && isSecure()) {
>   //Status.APR_EGENERAL=20014
>                 // Not entirely sure why this is necessary. Testing to date
> has not
>                 // identified any issues with this but log it so it can be
> tracked
>                 // if it is suspected of causing issues in the future.
>                 if (log.isDebugEnabled()) {
> log.debug(sm.getString("", getSocket(),
> this));
>                 }
>                 return 0;
> Does this need to throw an exception to get caught higher up as an error?

Oh great. That code.

It originates here:

For the background see this thread:

As far as I could tell, something was happening in the TLS layer that
APR/native was reporting as an error that wasn't really an error.
Therefore, I changed Tomcat to ignore the report of an error and carried on.

What I suspect is happening is that you are seeing a real error that
Tomcat now isn't treating as an error.

I do have a working build environment for tc-native on Windows now so
this is probably worth a re-visit.

I'll put this at the top of my TODO list for after the 9.0.x and 8.5.x
releases I've been meaning to start for the last couple of days.

Given how far you've got with this in a short time, if you wanted to
continue digging that would be great. My suggestion for a way forward
would be:
- enable debug logging for AprEndpoint
- try and recreate the 20014 error with the WebSocket drawing board
  example (as described in the links above)
- trace back into APR/native to figure out a) what is generating that
  20014 error code and b) what it should really be generating.

If you need to build APR/native, the instructions are here:



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message