[dancer-users] How can a fork+system() Dancer app not create zombie processes?

[Zahir Lalani]

Agree with Andrew

We use Gearman and it works very well. The advantage is that you scale your asynch backend independently of your main application, and it allows you main app to be far more responsive rather waste time doing things that can be done asynch

Z

From: dancer-users [mailto:dancer-users-bounces at dancer.pm] On Behalf Of Andrew Solomon
Sent: 29 June 2017 11:27
To: Perl Dancer users mailing list <dancer-users at dancer.pm>
Subject: Re: [dancer-users] How can a fork+system() Dancer app not create zombie processes?

Hi Nathan

It might be helpful to address this problem through a separation of concerns. You've got the Dancer app's job which is to serve web pages. Then there's another job - to send emails - and from this viewpoint it makes sense to implement that as a separate piece of software.

On a large scale this can be done using a queuing service where the Dancer app puts a message onto the message queue (managed by a broker like RabbitMQ or ActiveMQ....) and your email sending software pulls the message off the queue and sends the email.

On a smaller scale I've done this without a message broker by treating a table in a database as a message queue - the Dancer app writes a line to the table with details of the message to send. A separate script - a daemon based on this https://metacpan.org/pod/Daemon::Control checks for any new records in the table, sends the appropriate message and marks the row as 'sent'.

There's more than one way to skin a cat so that's just another approach to consider. Good luck!

Andrew



On 29 Jun 2017 06:56, "Nathan Bailey" <web at polynate.net<mailto:web at polynate.net>> wrote:
Hi all,
   I want to send my Dancer2 TT page as an email and continue to generate a normal web response.

This forking discussion seems like an excellent approach.

I have:
1. Created a fork in 'hook before_layout_render' (based on a 'var want_email = 1;').
2. The parent continues to serve the webpage (as normal, after undef'ing want_email), the grandchild sends the email (in 'hook after_layout_render')

(I'm doing this in before_layout_render so I can change the layout (app->template_engine->layout('email');) to a lighter, more email-friendly layout)

An additional benefit of this approach is that the email is sent asynchronously, since Gmail-dispatched emails seem to take 2-3s to send.

This all works well and I am grateful for this discussion and Andy's example code, but I am unclear about the guard, per below.
I understand what it is intended to do, but if I put:
   my $guard = guard { info "I'm dying"; POSIX::_exit(0); };
in my code, the code immediately prints the "I'm dying" and exits.

Am I missing something in how to use Guard properly?

BTW, if someone has a better pattern for emailing a page, I'd welcome it.

cheers,
Nathan

On 3 April 2017 at 21:21, Andrew Beverley <andy at andybev.com<mailto:andy at andybev.com>> wrote:
On Mon, 3 Apr 2017 13:22:16 +0300 Shlomi Fish wrote:
> like "guard"s

You should consider a guard, to ensure that nothing in the grandchild
causes it to hang around. For example, if there is an exception which
is then caught before the _exit(), you can end up with the grandchild
hanging around serving web requests to nobody ;-)

_______________________________________________
dancer-users mailing list
dancer-users at dancer.pm<mailto:dancer-users at dancer.pm>
http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.preshweb.co.uk/pipermail/dancer-users/attachments/20170629/288ee378/attachment.html>