Ask HN: What is the best way to implement a listener for web applications?

[Kirvy]

I am wondering what is the best way to implement a listener for a web application? And how do large apps do this?

I can imagine a web application, e.g. php or ruby etc, that is linked to a typical database, e.g. mysql. The job queue is stored in the DB and another separate backend process polls this job queue - doing sql Selects Upon detecting a new job, the backend then starts a resource intensive process, e.g. launch a virtual server, uploads file, start crunching data.

I guess polling is fine if it is not so urgent or the db is small.

But for faster response, is there a good way to implement a listener? It simply accepts the job from the web application, stores a copy in the DB and starts the resource intensive part. The whole idea is to skip the polling of the database.

Java has some useful classes but what about other web languages? Or am I approaching this in the wrong way? What are your experience in implementing this? Thanks

[madhouse]

What I did a while ago - which isn't the best way, it's quite crude, but works - is to have the webapp touch a file on the filesystem, which is watched with inotify (or whatever similar feature your OS has), and whenever the file is touched, the backend processor wakes up and starts crunching the new entries in the queue.

Perhaps it might even be possible to construct such a trigger in your database that would wake up an external application - I haven't looked into that possibility yet.

[malyk]

You could add a simple http server to your worker app that is pinged when something needs to happen. You could even make it respond to different requests for different tasks it has to do.

[mrphoebs]

You could implement an AMQP, based messaging system, with call backs, instead of polling.