I had the same problem with Cowboy recently, really ought to file an issue
to at least fix the docs for that.
For my app I wanted to implement a graceful shutdown that stopped accepting
new connections but allowed existing requests to finish. The waiting part I
implemented by adding a gproc local property to the workers that I wanted
to wait for and then monitoring them.
Looks like this:
https://gist.github.com/2655724
On Thu, May 10, 2012 at 2:53 AM, Paweł Peregud <>wrote:
> I was having fun with supervisors yesterday (Cowboy seems to fail to
> fulfill the promise of not killing request processes after listener
> removal) and I have an example. I've only investigated the case when
> supervisor is killed, so YMMV. Example code is attached. You may modify it
> to check the behavior in your case.
>> Start supervisor tree with exp_sup_sup:start_link(). Execute test with
> exp_sup_sup:test() and exp_sup_sup:test_simple().
>> In case of dying supervisor the answer is "no, it does not".
>> When supervisor dies, your process is killed as via link mechanism, so it
> may leave some unprocessed messages in inbox. To make sure that every
> delivered message is served, you need to add process_flag(trap_exit, true).
> Messages that are sent after the moment when supervisor dies are not
> processed.
>> Best regards,
>> Paul.
>> On May 9, 2012 11:06 AM, "Andy Richards" <>
> wrote:
>>> Hi,
>>>> I can't seem to see any confirmation in the documentation so was
>> wondering if anyone could confirm if messages are still sent to a
>> supervised gen_svr following a shutdown message?
>>>> If so how do I cleanly shutdown my gen_svr without loosing messages? I
>> read in the supervisor child spec that a shutdown can be set to infinity
>> which i hoped would allow me to process the msg's in my mailbox but if I do
>> this will my module continue to receive messages from other processes? Is
>> my approach flawed and if so what other ways are there to cleanly shutting
>> down my gen_svr without loosing messages?
>>>> Many thanks,
>>>> Andy.
>> _______________________________________________
>> erlang-questions mailing list
>>>>http://erlang.org/mailman/listinfo/erlang-questions>>>> _______________________________________________
> erlang-questions mailing list
>>http://erlang.org/mailman/listinfo/erlang-questions>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120510/5c2376bd/attachment.html>