tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Connector bindOnInit=false not behaving as expected
Date Mon, 05 Dec 2016 23:03:56 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Mark,

On 12/4/16 3:24 PM, Mark Thomas wrote:
>>>> It looks like the ProtocolHandler is really the place where
>>>> the TLS configuration is taking effect, and not the
>>>> Connector, so I'm largely ignoring the Connector for now. Is
>>>> that the right choice to make, here?
> 
> It depends. What you actually need to do is swap out the
> SSLContext. This is in the SSLHostConfigCertificate.

It looks like the only place the SSLContext is actually set is from
Nio(2?)Endpoint.bind(). So that means that, with the current Tomcat
implementation, changing the SSLContext means an unbind() followed by
a bind(). Do I have that correct?

This would be for JSSE only... for OpenSSL/APR, I suspect it will be
the same thing, but any change would have to take both into account.

What I'd really like to be able to do is replace the SSLContext
without dropping any in-flight requests, while new requests wait to be
serviced until the new configuration was available. Something like this:

1. Stop processing incoming connections (e.g. still accept(), but
don't handshake, yet... or at least stay bound to the port, but don't
yet accept() and allow the TCP stack backlog to queue incoming
connections)

2. Load the new TLS configuration

3. Resume accepting connections with the updated TLS configuration

4. Requests accepted before step #1 continue to use the configuration
effective at the time

I'm not sure how all that squares with that JSSE is willing to do.
Once the TLS handshake occurs, presumably it means that the connection
will continue to be valid until it's closed. If a connection as
mentioned in #4 above is long-running, the old SSLContext etc. will be
GC'd after the connection finally closes. If that assumption is not
correct, I don't think any of the above is even possible.

What probably is possible is pausing all incoming connections, waiting
X ms for them to complete, then unbind(), then bind(). Client
observation would be that the service seems to stall, then fail.
Presumably, immediately re-trying would connect and get the new
configuration.

How difficult do you think it would be to implement such a "graceful"
shutdown of the connector? It would be the same as "stop" except that
it would first allow all in-flight requests to complete (with some
reasonable timeout... say, as specified by a parameter to a
gracefulShutdown(int) call?) and then, in the case of the
bindOnInit="false", it would unbind().

That would allow a JMX client to say "shut down gracefully", waiting
for an OK response (which would indicate that the connector had in
fact shut down), then immediately request a "start" and the connector
would come back up. At this point, I'd probably argue that we should
add a "restart gracefully" to the list of JMX-callable actions which
just does both of those calls on the server without a second HTTP
roundtrip from the JMX client.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYRfJcAAoJEBzwKT+lPKRYYz4P/RiXs43l3pCXS5RmivlhaIg2
QSTq2Og50I8+qK6wuhpABp0VvwOI29JQ0M+Bg2jSMM7sFRpnH+Z6brPOKArMwrYz
fBRgg0HfwFJQqAFk+wdXfoSNkbvHtsvZIhrrPcJGth9Tr/BHwDXHcmCKmScTCg93
ynyw6AWDzZ8SxU1YpKHYhBXb1Zbz4KDGcxBLDcRs6S4qmnNeu2JQfn7xQNImPZg0
yToctnzzH/SRG2rEoySyKMY+jpynreMw9jUOmdygJaGh1r3dv00yivu08Dv9/8MI
yiQCq678sa0U5pUKTZtvhb00ZszmCZ56dJTC0u51nSTWOkrj+AmaBjmWIR1CUdMO
qO2PhRsL/EnYDeEYORcLuJ1oa+J3GcxplgsU0PX09vVN+7TF7F3h0oUH34PvMyIJ
hrLQv958nMevodkeDEgW5/nVV8WctXXUbSgKG4IFufwPh3paMmqsO+9ea8/vnXWN
iAnijwgRun2Cwl2CrjPDu9isN5zoLQTlyYJnw+tOE4JYFjCpLVJ8ykTeRQs/fSDD
qEuMIAT3+MrNTIMN8c5zBoGxTIouWRuXDetpSlaVm2Ln1R4TghdkBf+D4RdBiMhV
ED08VnzghwbuG6VpdbFTjTThj5qEb+SLiQmM7rf9WF36s7Gatl4z1FyTJn7gtj2+
Uvwqqd0kXA/XFnpmttHA
=qvTT
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message