tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Connector bindOnInit=false not behaving as expected
Date Mon, 05 Dec 2016 23:03:56 GMT
Hash: SHA256


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

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

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
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message