Is SIGINIT the preferred way over SIGTERM to gracefully shutdown Dropwizard?

[Michael Biven]

Between Coda Hale's reply on sticking with SIGINT to shutdown… 

https://groups.google.com/d/msg/dropwizard-user/Q1gDWJctuXQ/82ao7ac0TyAJ 

the copy of Yammers Upstart script that Ryan Kennedy's posted (which I don't see anything telling Upstart to use a different signal than the default SIGTERM)… 

https://groups.google.com/d/msg/dropwizard-user/PPgqS2ZHeFg/OoSq0yWMBwAJ

and when I send a SIGINT to Dropwizard it does nothing, keeps running and takes a SIGTERM to get it to stop. But my understanding is when sending a SIGTERM any running requests would not stop gracefully. 

So three questions… 

Should I expect Dropwizard to shutdown by default when it retrieves a SIGINT? 

If it receives a SIGTERM will any running requests continue to run until they complete, but no additional requests are taken (i.e. graceful shutdown)? 

What is the suggested signal to send for a graceful shutdown ? 

Michael 

[Coda Hale]

They're equivalent:

http://www.oracle.com/technetwork/java/javase/signals-139944.html

1. Yes.

2. Yes.

3. All shutdowns are graceful. For 0.6, the grace is just a sleep before terminating the thread pool. For 0.7, Jetty 9 just waits for all requests to complete.

--
You received this message because you are subscribed to the Google Groups "dropwizard-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dropwizard-us...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Coda Hale
http://codahale.com

[Michael Biven]

I've been working on the assumption that it's an issue with our init script, but SIGINT won't work with a background process. I'm wondering if more people are just using SIGTERM instead of SIGINT. 

   "To facilitate the implementation of the user interface to job  control,

   the operating system maintains the notion of a current terminal process

   group ID.  Members of this process group (processes whose process group

   ID is equal to the current terminal process group ID) receive keyboard-

   generated signals such as SIGINT.  These processes are said  to  be  in

   the  foreground.  Background processes are those whose process group ID

   differs from the terminal's; such processes are immune to keyboard-gen‐

   erated signals."

$ ps x -o  "%p %r %y %x %c "

PID  PGID TTY       TIME COMMAND

1737 1736 ?        00:01:02 java

Michael 

[Michael Biven]

Thank you for clearing that up. I had just missed seeing your reply before sending my last update.

Michael

Coda Hale

May 14, 2013 4:43 PM

They're equivalent:

http://www.oracle.com/technetwork/java/javase/signals-139944.html

1. Yes.

2. Yes.

3. All shutdowns are graceful.�For 0.6, the grace is just a sleep before terminating the thread pool.�For 0.7, Jetty 9 just waits for all requests to complete.

On Tuesday, May 14, 2013, Michael Biven wrote:

--
Coda Hale
http://codahale.com

--
You received this message because you are subscribed to a topic in the Google Groups "dropwizard-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dropwizard-user/ioISsbm1Mh0/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to dropwizard-us...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

�
�

Michael Biven

May 14, 2013 2:57 PM

Between Coda Hale's reply on sticking with SIGINT to shutdown��

https://groups.google.com/d/msg/dropwizard-user/Q1gDWJctuXQ/82ao7ac0TyAJ�

the copy of Yammers Upstart script that Ryan Kennedy's posted (which I don't see anything telling Upstart to use a different signal than the default SIGTERM)��

https://groups.google.com/d/msg/dropwizard-user/PPgqS2ZHeFg/OoSq0yWMBwAJ

and when I send a SIGINT to Dropwizard it does nothing, keeps running and takes a SIGTERM to get it to stop. But my understanding is when sending a SIGTERM any running requests would not stop gracefully.�

So three questions��

Should I expect Dropwizard to shutdown by default when it retrieves a SIGINT?�

If it receives a SIGTERM will any running requests continue to run until they complete, but no additional requests are taken (i.e. graceful shutdown)?�

What is the suggested signal to send for a graceful shutdown ?�

Michael�

--
You received this message because you are subscribed to a topic in the Google Groups "dropwizard-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dropwizard-user/ioISsbm1Mh0/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to dropwizard-us...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

�
�

[Saad Mufti]

Reopening this old thread, because I'm having an issue with shutdown in DW 0.7 . I'm not sure when the issue started because my app was original in 0.6.2 and graceful shutdown was working fine. My app is now on 0.7, and testing on my Mac laptop, I see two different behaviors:

1. When built using Maven from the command line and run from the command line, sending SIGTERM or SIGINT (under no actual HTTP load) appeared to be shutting down the app immediately, I saw no server shutdown messages getting logged in the logfile. Putting a System.err.println in one of my managed objects shows that its stop method is getting called, so looks like shutdown is being done gracefully but there is no evidence of it in the logfile

2. When built and run from Eclipse, the managed object shutdown method is getting called as above, but a log.info statement I put in it does not show up in the logfile. BUT, the normal Jetty shutdown messages do appear in the logfile.

Anyone have an idea what's going on? I'm totally confused.

----

Saad

To unsubscribe from this group and stop receiving emails from it, send an email to dropwizard-user+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Tatu Saloranta]

I observed same problem at work, via Ant build (yeah, don't ask). Ant (et al) typically spawn a new process, and question then is how does that process signal its child process.

So most likely in your case signal being sent to actual DW process is not SIGTERM / SIGINT, but maybe SIGKILL or such, which does not let receiving process do the usual cleanup stuff via shutdown hook.

Although above assumed that you were running it via Maven. But same idea applies regardless: it depends on process that launches service, and its handling of killing/shutting down child process(es).

-+ Tatu +-

To unsubscribe from this group and stop receiving emails from it, send an email to dropwizard-us...@googlegroups.com.

[Saad Mufti]

But in my case, in 1) running from the command line, it was NOT via Maven, I was running it as:

java -jar target/web_api-0.5.jar server config/cl.yml

Within Eclipse I was running it via "Debug As" as a simple Java Application, so I was thinking both should have the same behavior, but they don't. 

And actually putting in debug prints in an application managed object shows that in both cases, it IS shutting down gracefully, just that from command line I see no shutdown messages in my logfile, whereas from Eclipse I see Jetty shutdown messages in the logfile, but not one I log from application's managed objects' stop method.

----

Saad

[Tatu Saloranta]

Ok. Then I agree it is odd, wrt logging. Messages should end up somewhere, even if misconfigured slf4j should notify you on console about misconfiguration? Another potential cause could be flushing (less time between notification & actual shutdown normally; Eclipse may take its time). And last thing on console (on linux) is that if last message was missing ending linefeed, it may not be visible. But that would not be relevant for multi-line output, would only miss the very last one.

-+ Tatu +-

[Saad Mufti]

Aha, thinking about this I vaguely remembered seeing a recent pull request that was related and then went to github.com to confirm. The pull request is

https://github.com/dropwizard/dropwizard/pull/414

and titled "AsyncAppender now flushes log events when the application shuts down" . Sure seems to match my case. The difference between Eclipse and command line must just be timing, Eclipse is slow enough that it gives enough time for more messages to be logged before the app shuts down.

This sure seems like a very useful pull request. Any chance it will accepted anytime soon?

----

Saad