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:[email protected]] On Behalf Of Andrew Solomon Sent: 29 June 2017 11:27 To: Perl Dancer users mailing list <[email protected]> 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" <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
_______________________________________________ dancer-users mailing list [email protected] http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
