On 04/12/2016 20:09, Christopher Schultz wrote: > All, > > On 12/1/16 6:07 PM, Christopher Schultz wrote: >> All, > >> On 12/1/16 5:59 PM, Christopher Schultz wrote: >>> All, > >>> I'm trying to use JMX to do things with Tomcat Connectors and >>> ProtocolHandlers. Specifically, I'd like to re-load the keystore >>> (really certificate) used for an HTTPs connection. > >>> I'm currently using Tomcat 8.0.30 for my testing. > >>> 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 seems that calling the pause()/resume() or stop()/start() on >>> the ProtocolHandler have no effect on resetting the >>> SSLServerSockeyFactory, which is what would be required to >>> achieve my goals (update a certificate for a running Tomcat >>> instance). You need new code to do this if you want to handle it smoothly. Failing that, you need to trigger bind(). Which means: bindOnInit=false start() stop() change TLS config stop() * drop existing connections, new connections fail here * this is generally a Bad Thing (tm) start() new TLS config available >>> I suspect I'll have to call init(). When I do this without >>> specifying bindOnInit=false awful things happen. First, calling >>> init() gets me an error on stdout that the address is already in >>> use, and then it's basically not possible to restart the >>> ProtocolHandler after that point: it's dead as far as I can >>> tell, because you can't call start() or resume() without getting >>> a whole bunch of errors. You can't just call nay method you like. You have to respect the standard Lifecycle state transitions even though Endpoint doesn't enforce them (the Interface and supporting base classes are not visible to the package. >>> Does that sound like a problem to anyone? I would think that >>> failure to call init() would leave the ProtocolHandler in an >>> uninitialized state, but I'm wondering if trying to >>> RE-initialize the ProtocolHandler should be something that won't >>> damage a previously-initialized component. When trying to script >>> these types of connections, having a non-destructive init() might >>> be useful. This is not a problem. >>> So, I set bindOnInit="false" which is documented[1] to unbind on >>> "stop". When calling stop(), the port continues to be bound by >>> Tomcat. Calling stop() and then start() throws a BindException. >>> :( Destroying the ProtocolHandler also leaves the port still >>> bound, and also (unsurprisingly) destroys the ProtocolHandler. That sounds like a possible problem but we have unit tests that explicitly test this behaves as expected (TestXxxEndpoint) so a Tomcat bug looks unlikely. >>> Stopping the Connector also does not release the port. :( Calling >>> stop() and then start() also throws a BindException. > >>> At this point, I think I'm stuck. Is there a bug here? > >>> I'm going to upgrade to 8.0.latest and repeat my tests, just in >>> case. > >> I updated to 8.0.39 and noticed that I had moved my keystore out >> of the way temporarily and so the connector was failing at some >> point looking for that. I'll be repeating my tests with more >> attention to detail, but what I think I've noticed is that there >> are certain errors which can occur that cause the Connector to get >> itself into a bad state. > >> Specifically, I think that problems with the crypto setup cause >> the connector to bind to the port, then fail and not unbind. Any >> later attempt to re-start the Connector fails because the port is >> still bound. > >> I think the connector should catch (some?) exceptions and unbind >> the port in those cases when bindOnInit=false. > > Any comments on whether or not these items should be considered bugs? > Specifically, uncaught exceptions which can prevent the connector from > coming back up again? If you find a sequence where start-up fails due to bad config and puts the connector in a start where it can't be started once the config has been fixed then that is probably a bug but likely only a minor one. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
