Take a look at Dancer as a proxy, Mojolicious: Websocket example under hypnotoad, real-time output from Mojolicious WebSockets?

Do these things raise any questions or answer any questions?

Mojo::IOLoop::Delay looks low-level, maybe useful if you're creating a Mojo::UserAgent .... if all you're wanting is to use a Mojo::UserAgent forget about IOLoop::Delay

You connect event handlers (callbacks) to the eventloop, the callbacks do a little work and let other callbacks do their work ... only rule of callbacks is not to block

If feasible, please try to show some of the relevant code snips you have now, perhaps with comments in the areas you feel that could use some performance gains.

No specific code for the non-blocking right now. I'm currently only loading from the database but the release candidate will need to work the application. Each API call can take a few seconds. With bulk changes on the data, I'm trying to limit the wait for the user. I was considering Minion to run the synchronization process as a background job but that won't update the application immediately. My API module is Net::Cisco::ACS, which is based on LWP::UserAgent. As far as I can tell from looking at Mojo::UserAgent, I should not have any issue swapping out the code. My only concern is where I would need to add the IOLoop block? Would my module method need something extra? I'll need to do some more reading on this, I guess :)


Greetz
Beatnik
... I'm belgian but I don't play one on TV.

"I'll need to do some more reading on this, I guess"

Quite probable. From what you're describing, it's a shot in the dark unless one of the monks has experience in exactly what you're dealing with.

After reading more, and with some testing, you should be able to provide code snips that show the issue in action. I can think of a few things off the bat, but I'm afraid they'll be irrelevant and slant this thread sideways for no reason.

For instance... in one of my apps recently using Dancer2, I had to sway from their db plugin so that I could run my db inserts/updates inside of an event outside the main application, so that there was no holdup. That won't work in all cases though, so keep us apprised on what you find when you can get a bit more specific.

Pseudo code would be something like:

sub save
{ my $self = shift;
  my $acs = Net::Cisco::ACS->new("hostname"=>"localhost");
  my $user = Net::Cisco::ACS::User->new("username"=>"foobar");
 $acs->create($user); # Blocking code
 # Calling create will take a few seconds
}

sub list 
{ my $self = shift;
  my $acs = Net::Cisco::ACS->new("hostname" => "localhost");
  my %users = $acs->users; # Blocking code
  # Calling users will take a few seconds
}
[download]

I don't need to call the API at that specific time. My original approach was to flag the record in my local database as 'created' or 'modified' and run a background process to make sure the local database synchronizes all flagged records with the application using the API. The list method would then only read from the database and make adjustments in the database.


Greetz
Beatnik
... I'm belgian but I don't play one on TV.

Perhaps something as simple as forking is all you need. Here's an example that kind of simulates what I think you're trying to do. Essentially, we create an API object with a couple of methods. Instead of calling them directly, we pass the object and the sub we want to call on it to a forking routine from within a local sub (save(), users()), and then let it work in the background while the main script carries on.

At the end of the script, we wait until all forked processes have completed before we exit.

use warnings;
use strict;

package Thing; {
    sub new {
        return bless {}, shift;
    }
    sub users {
        print "in ". __PACKAGE__ . " execing users()\n";
        sleep 2; # simulate long API call
        print "done API users()\n";
    }
    sub save {
        print "in ". __PACKAGE__ . " execing save()\n";
        sleep 2; # simulate long API call
        print "done API save()\n";
    }
}

package main;

use Parallel::ForkManager;

my $max_forks = 10;

my $fork = new Parallel::ForkManager($max_forks);
my $api = Thing->new;

print "doing stuff in main...\n";
print "calling main::save()...\n";

save($api);

print "continuing in main, save() API call isn't blocking\n";

print "calling main::users()...\n";

users($api);

print "finished in main, waiting for forks to finish\n";

$fork->wait_all_children;


sub save {
    my $api = shift;
    fork_api_call($api, 'save');
    print "forked API save...\n";
}
sub users {
    my $api = shift;
    fork_api_call($api, 'users');
    print "forked API users...\n";
}
sub fork_api_call {
    my ($api, $sub) = @_;

    for (0..$max_forks){
        $fork->start and last;
        $api->$sub();
        $fork->finish;
    }
}
[download]

Output:

doing stuff in main...
calling main::save()...
forked API save...
continuing in main, save() API call isn't blocking
calling main::users()...
in Thing execing save()
forked API users...
finished in main, waiting for forks to finish
in Thing execing users()
done API save()
done API users()
[download]