SSLEngine closed already exception triggered by reload
nginx-forum at forum.nginx.org
Fri Nov 9 17:42:48 UTC 2018
We have tried different settings with 'lingering_close always;' and
'lingering_time', 'lingering_timeout' up to 240s with no success.
Would you be able to confirm whether it is an nginx problem in the lingering
close automatic logic as you mentioned if I provide an example to reproduce
Maxim Dounin Wrote:
> 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
> > 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)'
> > I'm using Scala with the Play framework, which uses netty under the
> > Is there any configuration that could avoid these exceptions being
> > 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
> > nginx?
> On Tue, Nov 06, 2018 at 08:49:07AM -0500, nginxuser2018 wrote:
> > One setting that I noticed mitigates the problem is to use
> > always;` however in our infrastructure this can lead to the build up
> > 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
> nginx mailing list
> nginx at nginx.org
Posted at Nginx Forum: https://forum.nginx.org/read.php?2,281786,281894#msg-281894
More information about the nginx