CODEWITHSUNDEEP
perlasynchronouscatalyst
h3ct0r
h3ct0r

Reputation: 735

Run asynchronous methods in Catalyst Perl

I'm currently using Catalyst, a MVC Perl web framework to develop some applications. I have previously used another frameworks in another languages that allows me to run asynchronous code. Let me put an common example: Right now if I need to send 3 emails, the user makes a request, the server send the 3 emails and it return with the 'ok' message. A good approach will be, the user makes the request, and immediately returns the 'ok, your messages will be sent shortly', and in the back-end the emails are sent asynchronously.

I'm thinking on creating my own task schedule system on a database, with 'method name', 'parameters' and 'run date' as rows of a table, and then use a cron job to call the method defined en 'method name' with the parameters at the specified date.

Maybe I am reinventing the wheel here, but at the moment I didn't find any module or technique that allow me to do this type of asynchronous method invocation.

What would be the recommended way to do asynchronous method invocation in perl? The task does not necessary need to be scheduled.

Upvotes: 1

Views: 1360

Answers (2)

hs2323
hs2323

Reputation: 21

I don't know how useful this would be, but there is a module to run code after the response has been sent, Catalyst::Plugin::RunAfterRequest.

Upvotes: 1

hobbs
hobbs

Reputation: 240521

You are reinventing the wheel. The general pattern here is, send the work somewhere else where it can be done without busying a web process that could be used for user-interactive tasks like drawing a webpage.

In the pure-Perl space there is Gearman, a distributed job-queue system.

You can also use an existing message queue system like RabbitMQ or ActiveMQ, or even Redis; just drop messages onto the queue that say what mail needs to go out and to who, and write workers that pull messages off of the queue and act on them. Most people, at some time, go the route of reinventing the work queue concept using a table in an SQL database; it's not the best idea.

Lastly, you could acknowledge that an email server already is the system you're asking for. It accepts a message, it makes sure there's room on disk for it, it says "OK" as fast as possible, and then it takes care of sending the message to its final destination in the background. It retries as necessary, and it gives you a failure notification if the delivery ultimately doesn't go through. It's pretty close to the perfect message queue. If you run your own mailservers, if you can guarantee they have high availability, and if you're not doing any expensive work to "generate" the emails, then the rest of this advice might be nonsense, and what you should be doing is just sending the messages from within your app. It's "synchronous", but all you're doing is sending the bits to someone else (the mailserver) to act on. It's no more than you would be doing with another approach, except it involves less fragile, homegrown code.

Upvotes: 4

Related Questions