So, to outline my idea: When the user sends a request to the route, let’s call it /long, Dancer would immediately return a page with a little javascript that periodically calls /progress and updates the progress bar. When /progress returns undef, the operation is done and the user gets redirected to the /success route handler.

Since Dancer is not asynchronous by nature, this requires using AnyEvent (see my previous posts). You have to be aware of how AnyEvent works: Just calling a timer which does the long-running operation once will not be sufficient, as the timer execution blocks and Dancer won't handle requests while AnyEvent is in control. Instead, you should cut it into little blocks. In my case, this is easy, since I’m doing HTTP requests and AnyEvent::HTTP handles them just fine.

Alright, let’s dive into the code. I will start with the Dancer part:

package poc;
use Dancer ':syntax';
use AnyEvent;

our $VERSION = '0.1';

set serializer => 'JSON';

        

my %long_ops;

We have just included AnyEvent, set the default serializer to JSON (very convenient in the javascript later) and defined a %long_ops hash.

        
get '/long' => sub {
    session 'progress' => 0;
    session 'progresslimit' => 5;
    $long_ops{foo} = {
        cnt => 0,
        guard => AnyEvent->timer(after => 1, interval => 1, cb => sub {
            my $cnt = $long_ops{foo}->{cnt} + 1;
            $long_ops{foo}->{cnt} = $cnt;
            if ($cnt == 5) {
                undef $long_ops{foo}->{guard};
                session 'progress' => undef;
            } else {
                session 'progress' => $cnt;
                debug "progress is $cnt";
            }
        }
    };
    template 'index';
};

The /long route is where all the magic happens. First we set the 'progress' and 'progresslimit' session variables to 0 and 5, meaning that progress starts at 0 and can reach 5 at max. Afterwards, we initialize our data structure (note that due to this being a proof-of-concept we just use 'foo' instead of a reasonable per-client identifier) with the current status (cnt) and a guard for the AnyEvent timer. As I explained in previous posts, AnyEvent objects fall out of scope if you don’t keep a reference to them.

The timer will be triggered 5 times and all it does is increasing the progress on every iteration. As soon as it reaches 5, it will undef the guard and thereby disable itself.

The route returns the template 'index' at which we will take a look in a second.

get '/progress' => sub {
    {
        progress => session('progress'),
        progresslimit => session('progresslimit')
    }
};

The /progress route returns a hash with the current and maximum progress. Due to the default serializer being set to JSON, Dancer will automatically serialize the hash to JSON.

Now that we have the server side, you can already test it with curl:

$ curl --cookie-jar /tmp/cookies http://localhost:8000/long
$ while [ 1 ] ; do curl -b /tmp/cookies http://localhost:8000/progress; sleep 1; done

Now we just need to do the same in javascript. Of course, we will make use of the bundled jQuery that comes with Dancer, so besides modifying views/index.tt, no other changes are required.

<h1>Long-running request demo</h1>

<div id="progress">Progress not yet initialized</div>

<script type="text/javascript">

function pollProgress() {

    $.getJSON('/progress', function(data) {

        if (data.progress === null) {

            return;

        }

        $('#progress').text('progress: ' + data.progress + ' / ' + data.progresslimit);

        setTimeout(pollProgress, 1000);

    });

}   

    

$(document).ready(function() {

    pollProgress();

});         

</script>

Since this is not a jQuery tutorial, I will cover only briefly what I’m doing here: When the document is loaded, pollProgress() will be called to get the initial progress (current = 0, max = 5). This is done by calling jQuery’s getJSON helper with an appropriate callback function. The callback exits if progress is null (undef in Perl) or otherwise updates the div with id progress and schedules the next call of pollProgress() in one second.

That’s it for now. I think I’m going to make a Dancer::Plugin out of this so that you can use it easily. Comments/Improvements very welcome!

There’s nothing wrong with timers, but if you are using AnyEvent, you usually have to deal with CondVars. There are two things you can do with a CondVar: Either you register a callback which will be called when the CondVar is triggered, or you call recv and it will block until the CondVar is triggered. In a route of your Dancer application, you probably want to block until you got all the data you want to display to your user.

Take the following (made-up) example which uses a CondVar:

get '/' => sub {
    my $cv = AnyEvent->condvar;
    my $timer = AnyEvent->timer(after => 1, cb => sub { $cv->send(1) });
    my $result = $cv->recv;
    template 'foo', { result => $result };
};

You will get a runtime error stating "AnyEvent::CondVar: recursive blocking wait detected". This is because Twiggy also uses a CondVar as exit_guard, to run infinitely long (blocking on a CondVar is an easy way to run the main loop).

The solution is to use a specific eventloop, such as EV, and call EV->loop instead of blocking on a CondVar:

#!/usr/bin/env perl
use strict;
use warnings;
use EV;
use Twiggy::Server;
use Dancer;
use npmd;

my $server = Twiggy::Server->new(

    host => '0.0.0.0',

    port => 5000

);

my $app = sub {

    my $env = shift;

    my $request = Dancer::Request->new( $env );

    Dancer->dance( $request );

};

$server->register_service($app);

EV->loop

That sounds quite nice, but we had to reverse-engineer the protocol. Afterwards, we noticed that only one (!) connection to that device is possible. So our first approach of using a little script to communicate with it was not optimal: It had timing problems because the NPM2000 took a little bit longer to close the TCP connection.

Therefore, I decided to write a little webapp using the excellent Dancer framework which talks to the NPM2000 and provides a nice API to the user(s). It also should keep one TCP connection open all the time to save the overhead of creating a new connection and waiting for old connections to close properly on both sides.

For creating and using said TCP connection I decided to use AnyEvent::Socket. The main issue with this approach is that Dancer doesn’t use the AnyEvent mainloop and thus AnyEvent won’t work at all.

The nice people in #dancer suggested taking a look at Twiggy, an AnyEvent HTTP server for PSGI. It can be easily combined with Dancer and uses AnyEvent. So, to run a Dancer application with Twiggy, use:

cpanm Dancer Twiggy
dancer -a npmd
cd npmd
plackup -s Twiggy bin/app.pl

Now that’s great, we have an AnyEvent-based server running our Dancer application. So, let’s use an AnyEvent timer in lib/npmd.pm:

package npmd;
use Dancer ':syntax';
use AnyEvent;

our $VERSION = '0.1';

my $w; 

get '/' => sub {

        $w = AnyEvent->timer(after => 1, interval => 1, cb => sub {

                debug 'timer msg!';

        });

        template 'index';

};

true;

After the first request to the application in your browser you should see the message 'timer msg' on your terminal every second.

Let’s instead create the timer outside a route, so that it runs all the time:

package npmd;
use Dancer ':syntax';
use AnyEvent;

our $VERSION = '0.1';

my $w = AnyEvent->timer(after => 1, interval => 1, cb => sub {

        debug 'timer msg!';

});

get '/' => sub {

    template 'index';

};

true;

Oops. That won’t work. The code is run, but $w falls out of scope immediately because we are not using it in any handler. This causes AnyEvent to delete the timer. There are two ways to fix this: use 'our $w' instead of 'my $w' or use $w in any of your routes.

So, a working version could look like this:

package npmd;
use Dancer ':syntax';
use AnyEvent;

our $VERSION = '0.1';

our $w;

    $w = AnyEvent->timer(after => 1, interval => 1, cb => sub {

        debug 'timer msg';

    });

get '/' => sub {

    template 'index';

};

true;