Hello!

On Mon, Nov 05, 2018 at 09:14:33AM -0500, nginxuser2018 wrote:

> I noticed that if I setup a simple scenario where a client is making
> concurrent requests on a server with nginx configured as a reverse proxy and
> SSL traffic termination endpoint, if I trigger a reload with 'nginx -s
> reload' mid requests, often times the client will throw an
> 'javax.net.ssl.SSLException: SSLEngine closed already
> at io.netty.handler.ssl.SslHandler.wrap(...)(Unknown Source)' exception.
>
> I'm using Scala with the Play framework, which uses netty under the hood.
>
> Is there any configuration that could avoid these exceptions being thrown?
>
> I cannot reproduce it using for example using Play to serve HTTPS, so I can
> possibly rule out a problem in the client and think it is a problem with
> nginx?

On Tue, Nov 06, 2018 at 08:49:07AM -0500, nginxuser2018 wrote:

> One setting that I noticed mitigates the problem is to use `lingering_close
> always;` however in our infrastructure this can lead to the build up of
> worker processes (for the duration of the lingering_timeout). What are the
> advantages and drawbacks of using this setting?

Upon configuration reload, nginx will close connections after it
finishes processing already active requests in these connections.
And given that "lingering_close always;" helps, I think there are
two possible cases here:

1. Closing the connection by nginx happens and the wrong time,
right before the next request is received on this connection, so
RST is sent on the connection before the client is able get the
response and the connection close. If this is indeed the case,
using "lingering_close always;" might be the right thing to do -
or, alternatively, lingering close automatic logic might need to
be improved.

2. The client isn't smart enough to check that the connection is
closed before sending the next request, and/or isn't smart enough
to recover from asynchronous close events (a good description can
be found in RFC 2616, "8.1.4 Practical Considerations",
https://tools.ietf.org/html/rfc2616#section-8.1.4). In this case,
a proper fix would be to improve the client.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx