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
> is WSAECONNABORTED - APR_STATUS_IS_ECONNABORTED
> on a good disconnect case (slower socket close) rv is (730054)
> = WSAECONNRESET - APR_STATUS_IS_ECONNRESET
>
> 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?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
