AlejandroRivera/embedded-rabbitmq

RabbitMQ process not being destroyed upon JVM exit

Opened this issue · 1 comments

bitx1 commented

Running Windows 7, Sun JDK 1.8, OTP 19.3

I noticed that as part of the RabbitMqCommand class, commands are executed using zeroturnaround's zt-exec ProcessExecutor w/ the destroyOnExit option. Under the hood, zt-exec uses normal java lang's ProcessBuilder, Process, and system shutdown hooks that call the destroy() method against the RabbitMQ Processes. Apparently on my machine at the least, Process.destroy() does not work -- thus leaving the RabbitMQ process still running. The following snippet proves my case....

public static void main(String[] args) throws Exception {
     // start rabbit-mq
     String dir = "C:/path/to/temp/rabbitmq_server-3.6.9/sbin";
     StartedProcess startedProcess = new ProcessExecutor()
          .directory(new File(dir))
          .command(dir + "/rabbitmq-server.bat")
          .start();
     Thread.sleep(15000);  //sleep enough time to ensure it is up

     // attempt to destroy
     System.out.println("DESTROYING....");
     startedProcess.getProcess().destroy();
}

Erl process still exists in the Windows Task Manager after my application exits normally.

Trying to stop RabbitMQ thru EmbeddedRabbitMq.close() works on Windows though. However, trying to use EmbeddedRabbitMq.close() in a system shutdownhook thread does NOT work.... which is where I would want to place it in since I only want to stop it upon JVM exit. I have not done further digging but I would not be surprised if this issue may be tied to (1) EmbeddedRabbitMq.close() itself invokes the destroyOnExit() option (while in a shutdown hook) OR (2) zt-exec destroyer implementation removes and re-adds the destoryer listener.

Workaround Options:
(1) Users: Override ProcessExecutorFactory to return a ProcessExecutor that ignores the destroyOnExit option. Register a shutdown hook that calls .stop()
(2) Library: Remove "destroyOnExit" option and replace it with registering a shutdown hook higher-up in the start() flow which will call the .stop() method. (Make this option configurable with a flag.)

Hi again @bitx1. Thanks for this report. Unfortunately, I don't have a Windows machine that i can use to test (and feel a bit lazy about spinning up a VM). Also I'm not sure when i'll have enough time to devote to this issue to get a fix out.

In other words, please feel free to submit a PR if you're interested in seeing this addressed quickly.