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 Fri, 06 Jan 2017 22:11:49 GMT
On 06/01/2017 21:50, David Oswell wrote:
> I've somehow gotten the build for tcnative working here (more shocked I
> finally got openssl to build!)
> There seems to be a slight difference in how the shutdown occurs. When the
> APR_EGENERAL is returned its due to falling through the SSL_ERROR_SYSCALL
> block in sslnetwork.c:ssl_socket_recv,
> This seems to be due to a difference in the value returned by;
> sslnetwork.c:324 :                                rv =
> apr_get_netos_error();
> on the bad case (quick socket close), rv is (730053) which
> on a good disconnect case (slower socket close) rv is (730054)
> I suspect a check with APR_STATUS_IS_ECONNABORTED(rv) might be needed to
> capture this scenario (WSAECONNABORTED), however I'm not sure how else this
> status might occur, and if any of those cases should not flag it as closed
> - although reading on WSAECONNABORTED it sounds like this is a close case.
> Not sure if it's an exception case or just normal EOF though.

Thanks. That is really useful information.

I've been trying to re-create the original issue that led to this odd
'treat an error as eagain' code but without success. I have found a
couple of other bugs (now fixed) so it wasn't a complete waste of time.

When I added this hack I was fairly sure I was missing something and it
is looking increasingly like this code was fixing a symptom rather than
the root cause. Given that I can't re-create the original problem, I'm
leaning towards removing the special handling for EGENERAL and letting
it trigger a close.

If you remove the
else if (-result == Status.APR_EGENERAL && isSecure()) {

block, does that fix the problem you are seeing?


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

View raw message