Yep that would, Originally I had just turned the return 0 to throw an
IOException - which as it would fall through to the else would be the same
effect.
I'll see if a java client would do the same, I'm using a golang
client/console app for testing.
I just tried with wget and see the WSAECONNABORTED status within APR.
It also seems a bit time dependent, might be a case of whether APR is
getting to the socket read before or after the FIN packet coming though ??
On Fri, Jan 6, 2017 at 5:11 PM, Mark Thomas <ma...@apache.org> wrote:
> 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: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
