On Mon, Oct 28, 2024 at 11:41 AM Lucian Jurj <lj...@neverfailgroup.com> wrote: > > > > Looking at "https-openssl-nio-9727" connector (ignoring "http-nio-9728") I > > see > > > 24-Oct-2024 12:27:14.109 INFO [main] > > org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler > > ["https-openssl-nio-9727"] > > 24-Oct-2024 12:27:14.156 SEVERE [main] > > org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to > > initialize component [Connector["https-openssl-nio-9727"]] > > org.apache.catalina.LifecycleException: Protocol handler > > initialization failed > ... > > 24-Oct-2024 12:27:45.864 INFO [main] > > org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler > > ["https-openssl-nio-9727"] > > 24-Oct-2024 12:27:50.868 INFO [main] > > org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler > > ["https-openssl-nio-9727"] > > > Thus failed init(), followed by stop() and start(). There is no attempt to > > re-run init(). > > > Looking at org.apache.catalina.util.LifecycleBase, I think that init() > > results in LifecycleState.FAILED state, and that there is a bug in the > > start() method. > > > In case of FAILED state the LifecycleState.start() method calls stop() and > > goes further to starting. The current issue demonstrates that this > > behaviour is wrong. > > > Maybe make separate error states, INIT_FAILED (aka not initialized), > > START_FAILED (not started). Starting a non-initialized component is a bad > > idea. > > > Automatically re-initializing a connector may not work as intended, as > > there exist configurations where init() is called with different privileges > > than start(). (See "Downgrading user" in > > https://commons.apache.org/proper/commons-daemon/jsvc.html > > > Thank you, Konstantin for your analysis and feedback. This confirms what > we've experiencing. > > > The lifecycle you're using could use some double checking, and that's > > probably the best way to resolve this. We'll examine the Tomcat > > behavior to see if there is a way to improve the robustness, of > > course. > > Re: Rémy's initial (above) recommendation: > - our app code already performs a hbws connector bounce when hitting the > keystore not found at first start. Then the keystore is found after the > restart. > But with the refactored tomcat behavior the "https-openssl-nio-9727" > connector does not re-initialize itself. > Is there a way for our code to call the connector re-init()? > > Our application hbws logs: > _____________________ > [2024-10-24 12:27:40,005] INFO > 27896[main](com.neverfail.webservices.NFWebServicesServlet) - INIT> hbws > servlet > [2024-10-24 12:27:40,005] INFO > 27896[main](com.neverfail.webservices.tools.Configurator) - KeyStore was not > found > [2024-10-24 12:27:45,833] WARN > 33724[main](com.neverfail.webservices.NFWebServicesServlet) - About to bounce > servlet to apply new KeyStore. NFKeystore was just created, servlet should be > bounced > [2024-10-24 12:27:45,848] INFO > 33739[main](com.neverfail.webservices.hbconnection.HBConnectionFacade) - > Using groupType:BINARY > [2024-10-24 12:27:45,864] INFO > 33755[main](com.neverfail.webservices.hbconnection.HBConnectionFacade) - > bounceConnector() About to bounce Tomcat connector... > [2024-10-24 12:27:45,864] INFO > 33755[main](com.neverfail.webservices.hbconnection.HBConnectionFacade) - > bounceConnector() Invoking stop on Catalina:type=Connector,port=9727 > [2024-10-24 12:27:50,868] INFO > 38759[main](com.neverfail.webservices.hbconnection.HBConnectionFacade) - > bounceConnector() Invoking start on Catalina:type=Connector,port=9727 > [2024-10-24 12:27:50,915] INFO > 38806[main](com.neverfail.webservices.tools.Configurator) - KeyStore was found
Ok, so the idea is that init() has to be successful or the component will never become started later on. Connectors are a bit special though. You can use bindOnInit to do the socket bind and TLS start either in init (you don't want it to fail, and you want the server to start accepting asap) or start (which allows stopping and restarting later, new attempts after a failure, and so on). I don't know what the best default behavior after getting into a "failed init" state should be for a component. Right now after destroy, it is not possible to go back and simply call init again. I have the impression this is the most reasonable behavior. Rémy > Thank you, > /LJ --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
