tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Connector bindOnInit=false not behaving as expected
Date Tue, 06 Dec 2016 09:17:22 GMT
On 05/12/2016 23:03, Christopher Schultz wrote:
> 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.

It should be as simple as:

1. Construct a new SSLContext

2. Replace the old SSLContext with the new one.

It gets slightly trickier with APR/native as you need to explicitly
clean up the old one and you can't do that until all the connections
using it have closed. JSSE doesn't have that requirement.

> 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().

I think that is the wrong approach. Just leave everything running and
just replace the SSLContext on the fly. With the caveat that APR/native
is a little trickier. We might need to add usage counting or similar.

> 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.

I think what we need is a refreshTLSConfig() method.


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

View raw message