Hi all Please comment on SLING-3915 [1]:
> I was involved with a customer report indicating that the ControlListener > would not work. The customer issued a stop command upon which the system > should have shut down. This seems to not have been the case so the customer > tried to issue stop again. This time, though the connection to the control > port could be opened but the command was not answered. > > Looking at the situation it looks like the first command issues the shutdown. > But this caused a deadlock. The server side socket was terminating and the > control thread was waiting for sling to shutdown. While waiting for the > shutdown the control thread could of course not accept new commands, even > though TCP/IP connections were being setup. > > To prevent such situations I am proposing an extension to the Launchpad > ControlListener which listens on a TCP/IP control port for status and stop > commands: > > * Calling stop starts a separate thread to shutdown Sling asynchronously to > the ControlListener thread. After having issued a stop command the > ControlListener will reply "STOPPING" to the status command > * Adding a new "threads" command to have the ControlListener print a thread > dump similar to the JDK jstack command. This includes all threads as well as > dumping potential deadlocks. A new Unit test contains two Thread classes > which provoke deadlocks to show how the thread dumper reports deadlocks. Regards Felix [1] https://issues.apache.org/jira/browse/SLING-3915
