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