I've had no experience of Dancer2's async yet (apart from dancing along at Sawyer's async web-scraping performance at YAPC::EU last month:) so I'll tell you the naive approach I've taken. * send the job off to the queue and respond immediately with a 'waiting page' * the 'waiting page' has this bit of jQuery which is checking with the server if the job is complete function startRefresh() { setTimeout(startRefresh,5000); // remember Javascript isn't waiting for this before continuing... jQuery.post('/json-get-job-status', {}, function(data) { if (data.job_status != 'done') { window.location = 'http://example.com/job_done', } } ); }; window.onload = function () { startRefresh(); }; NOTE: http://mybox/json-get-job-status is being called by the browser without reloading the page Does that address your question, or am I completely off on a tangent? Andrew On Tue, Oct 6, 2015 at 8:54 PM, Amelia Ireland <aireland@lbl.gov> wrote:

Hello again,

What are my options for running a potentially lengthy process using Dancer? I'm adapting old CGI.pm-based code, which uses one of two techniques:

1. the CGI creates a job that it sends to an externally-managed queue; users have a workspace area where they can check to see if their job has finished;

2. the CGI keeps the connection to the browser open while performing the process using a hack involving sending small chunks of data from time to time.

Another common technique (similar to 1 above) is to fork off a child process and have the browser periodically refresh the page, which triggers a check to see if the child process has finished (e.g. by checking for the presence of a results file) and the results can be loaded.

Do Dancer2's delayed / async / non-blocking capabilities offer any additional ways to deal with long-running processes, or maybe a more elegant way to do option 2?

Thank you for any information!

Amelia.

On 2 October 2015 at 10:50, Amelia Ireland <aireland@lbl.gov> wrote:

...

Hello,

I'm very interested in using Dancer2's streaming and async capabilities, and have a number of questions about using Dancer2 asynchronously:

- Does the whole app have to be written to be asynchronous / non-blocking? (I assume so)

- Do all apps running from the same .psgi file have to be non-blocking? E.g. in app.psgi:

builder { mount '/app1' => $nonblocking_app; mount '/app2' => $blocking_app; };

- Are hooks safe to use in a non-blocking Dancer2 app or do they introduce a blocking element?

- When I run the drums example in a browser (Safari), it waits until the entire drum loop has completed and then prints the content. Is that what is expected to happen? I expected the content to be written by the browser as it received it. The docs aren't very clear on what Dancer is actually doing under the hood -- it would be useful to have more explanation of what's going on. I'd be happy to write up something myself, but I don't know what's going on. ;-)

Thanks!

Amelia.

_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users

-- Andrew Solomon Mentor@Geekuni http://geekuni.com/ http://www.linkedin.com/in/asolomon