[
https://issues.apache.org/jira/browse/SLING-3915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated SLING-3915:
-------------------------------------
Attachment: SLING-3915.patch
Proposed patch
> Launchpad ControlListener improvement
> -------------------------------------
>
> Key: SLING-3915
> URL: https://issues.apache.org/jira/browse/SLING-3915
> Project: Sling
> Issue Type: Improvement
> Components: Launchpad
> Affects Versions: Launchpad Base 2.5.2
> Reporter: Felix Meschberger
> Attachments: SLING-3915.patch
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
