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.