Thanks Matthew..<div><br></div><div>In the meantime.. i guess ill make local modifications and plop it in my codebase..</div><div><br></div><div>-Arun<br><br><div class="gmail_quote">On Tue, Jan 25, 2011 at 3:00 AM, Matthew Sackman <span dir="ltr"><<a href="mailto:matthew@rabbitmq.com">matthew@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Howdy,<br>
<div class="im"><br>
On Mon, Jan 24, 2011 at 04:56:55PM -0800, Arun Suresh wrote:<br>
> Ive been playing around with supervisor2 which you guys ship with rabbitmq<br>
> server. The delayed restart is seriously a life saver.<br>
<br>
</div>Glad you like it.<br>
<div class="im"><br>
> The only minor issue ive had with it is:<br>
> Once the process has exceeded MaxT and MaxR, you guys spawn a timer thread<br>
> to restart the process after the specified delay.. During this period, the<br>
> process is actually dead. but supervisor:which_children still returns a<br>
> stale Pid. Any reason why inside the do_restart method, once the restart1<br>
> method returns a {terminate, NState} , state_del_child() is NOT called ?<br>
<br>
</div>From memory, no reason at all, and I think it would be an improvement<br>
for it to do the del_child sooner rather than later and thus not return<br>
the stale pid. Slight complexities with simple_* supervisors possibly -<br>
can't remember - it's been a while since I looked at that code. I'll<br>
take a look and most likely file a bug.<br>
<br>
Best wishes,<br>
<br>
Matthew<br>
_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</blockquote></div><br></div>