-----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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
