Stopping connectors early in the shutdown process

[brian.stansberry]

(Related to http://jira.jboss.com/jira/browse/JBAS-4735)

When the work was done to delay starting the Tomcat connectors until a START_NOTIFICATION_TYPE JMX notification was received from ServerImplMBean, why wasn't STOP_NOTIFICATION_TYPE also handled, to allow early shutdown of the connectors?

Do the connectors cleanly handle having their stop() method invoked while they are servicing requests; i.e allow requests to complete but disallow new requests?

[starksm64]

I thought it was done as part of the service shutdown, before undeployment. I'll have to pull down the 4.2.1 code to my laptop to check, but I don't see this in head.

Yes, the connectors due wait for inflight requests before shutting down.

[brian.stansberry]

I don't see anything in Branch_4_2 code either to indicate the connectors are being shutdown early. Anyway, if I do a simple startup/shutdown of JBoss I can see in the console log some webapps get undeployed before the connectors are paused/stopped.

I've been experimenting with stopping the connectors based on the JMX notification. One thing I'm seeing is if you invoke stop() on the connectors during the notification callback, Tomcat logs errors during stopService as it tries to stop them again. If I just call pause() on the connectors instead of stop() I don't have that problem, but AFAICT that means a client with a keep-alive connection will still be able to make requests.

Dominik, I'll create that simple NotificationListener sar I mentioned on our call today and send it to you. That will let you experiment with this on a standard 4.2.x.

[dimitris]

It seems that stopping of the connectors in JBossWeb.java is done implicitly by stopping the tomcat server.

I guess we would have to ask Remy to modify tomcat to not try to stop, stopped services/mbeans.

[brian.stansberry]

Either don't call Connector.stop() twice (needs new API to know if started), or reduce the logging level on the message it emits if stop() is called if already stopped.

From looking at the how the various TC protocols work, I don't see how calling Connector.stop() will prevent keepalive requests on existing sockets either. Both pause() and stop() deal with accepting sockets off the server socket and handing them off to be handled; AFAICT they don't impact what happens with existing connections.

pause() -- pause the thread the accepts sockets off the server socket. Not good for shutdown as it basically means connection requests will pile up on the socket rather than promptly failing over.

stop() -- pause() plus close the server socket.

This for sure needs Remy's input.