3 ms·
You misunderstood the question. I specifically say "background job". I'm using delayed_job / resque already. But if the results of the job is needed client side
by boundlessdreamz 16y ago
You misunderstood the question. I specifically say "background job". I'm using delayed_job / resque already. But if the results of the job is needed client side immediately then I've to poll the server periodically and fetch the results when done.
What I asked was whether these types of jobs can be done without the server blocking. igrigorik's answered that. The queue might still be needed but the polling can happen from inside the server code rather
than from browser (the server will hold a connection from browser, keep polling queue and on success return the response)
- tptacek 16y agoYou're right. It was a noob question. It is a bad idea to hold open an HTTP connection waiting for a long-running job to complete. Good luck with your design, though.
- boundlessdreamz 16y agoWhy would it be a bad idea ? Event servers do not to fall over if there are lot of clients holding http connections open. This is used quite widely. http://en.wikipedia.org/wiki/Push_technology#Long_polling http://en.wikipedia.org/wiki/Push_technology#Long_polling
- tptacek 16y agoLong-polling, in app designs based from the start on long-polling, is a fine thing (or at least, I'll stipulate that). Connections that you hold open while forking off and waiting for a process that will take many seconds to complete is just bad UX. There are better ways to do it. You'll excuse me if after arguing with my response to your one-sentence "noob question: how do I make PDF generation asynchronous from an evented Ruby webserver" I am not chomping at the bit to get into a long architecture debate with you. I meant it: good luck with your design. Sorry I couldn't be more helpful.