-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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 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). > >> 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. > >> 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. > >> 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. > >> 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? - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYRHgQAAoJEBzwKT+lPKRYwzgP/3BlD2DnNa5ZJwpX1Wcl9JXe 3Oj2zgUbv0z9qExmAYfuIYYpyUiIiGoO0oJIo9r4sGjCSeQg/GWv/w9q03YlCKOE U/+t4FH2UZ0W15x27PF1j1TSMna8Heq2Wysqp3ccgyX4E3BGcOxTE6RwE9MQI3+e aduTjtw4Wy34jh426pX4ilSxgagHPDXeqsuvUsbt5nS8FGizK0fMqYvcIfpfpfCx F+BYGKi5ZkafhyrkXyCGzdL8XzpAFDC8Vx2bqQGYAGrsDmP4S7xQwHhMPoG4T0xN bB98jV7MMJTxb+P4Yog+xN1t3MnpsgCtztW6TxVflSc+fm6mPy+9NGgN7D3vLSHw EWZSR9AzuLQwNRI8hqubNoLIXT0ddoG3zZ4CP6YtMbtCN9qIGmby9idCM2mEoarp oBpQL+rvcvQs3qJU9KsVOV3YXjNPsHciXquI8HrvaqwMPaSf3NRHR897OZOwapjX IHV6/8K2yqL2t3UXoOS87O/94cCZb5g/XPA/QZO8ljF6M7rDKE8omR7XcbMoyW9p 4Dm2RSiUm7nqn2Eto7p2fKlQ10iK4bdeQ/6q4nLuMMEQ/Nmh6pRPt9Jgz8A8goTZ k/xSQJg+5Pij/fg76StfkLWULdVSm6tUkW9CPPzqEvdPWZeEOn6KBQ9m4d0S80Ro 9MMGOsmaWRf6TfEkwmkB =Arwu -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
