FYI, WWW::Mechanize is (1.66). Dancer is (1.3020). perl, v5.8.8 On Thu, Apr 7, 2011 at 4:41 PM, J. Bobby Lopez <jbl@jbldata.com> wrote:

Upon further investigation, it seems to be an actual problem between WWW::Mechanize and Dancer.

In my stand-alone script, as soon as I "use Dancer;", the script hangs. If I comment out the $browser->get(); for Mechanize, the script will run fine even with Dancer loaded.

Something funky be afoot.

On Thu, Apr 7, 2011 at 3:30 PM, J. Bobby Lopez <jbl@jbldata.com> wrote:

...

Experiencing a problem using WWW::Mechanize in Dancer.

Here's how I'm using it: http://pastebin.jbldata.com/m230ae053

Note that I'm able to use the json_api_call() routine in a stand-alone script without issue; but within Dancer, the application just hangs.

Any thoughts?

Thanks, -Bobby

On Thursday 07 April 2011 22:31:46 Flavio Poletti wrote:

Not sure that I'm reading your snippet correctly, but it seems that your application is trying to call itself.

That does indeed appear to be the case, which seems an odd approach.

Unless you're putting some parallelization mechanism, this will never, ever work: the second request will be served only *after* the initial one is completed, and the initial hangs waiting for a response to the second. I suggest to put a low timeout on $browser to see what's going on.

It ought to work if running the app via e.g. Starman, where multiple processes are forked to handle multiple requests at once, but yes, with the standalone server, it will fail.

Even with parallelization in place this is probably a bad idea and it would be better addressed with some refactoring/modularization.

Indeed. Cheers Dave P -- David Precious ("bigpresh") http://www.preshweb.co.uk/ "Programming is like sex. One mistake and you have to support it for the rest of your life". (Michael Sinz)

If you plan a big decoupling - e.g. putting web services in a machine and the front-end into another - then you might set up two running instances in your development environment. If you don't, why do you need to go for an RPC call to the very same process? Why don't you arrange your code in order to simply call a function instead of performing RPC (with all the associated overhead and problems)? Regarding the simultaneous connections, David indicated one common way - Starman: It ought to work if running the app via e.g. Starman, where multiple

processes

are forked to handle multiple requests at once, but yes, with the standalone server, it will fail. Cheers, Flavio. On Fri, Apr 8, 2011 at 6:01 AM, J. Bobby Lopez <jbl@jbldata.com> wrote:

I guess I thought that I should be able to make a call to another Route within the same application, since WWW::Mechanize is acting like regular client browser.

Other route would have provided the information requested. If we can't do this, then how are we able to handle simultaneous connections to Dancer?

It seems to me that the route should have been able to be processed via requested URL. If I am certainly wrong then please forgive me, and share further detail if you can.

Is the only alternative to run two instances of Dancer? One for the API and one for the UI? Or is it to run a stand-alone CGI script which makes JSON RPC calls to the API, outside of dancer?

Thanks, -Bobby

On Thu, Apr 7, 2011 at 5:41 PM, David Precious <davidp@preshweb.co.uk>wrote:

...

On Thursday 07 April 2011 22:31:46 Flavio Poletti wrote:

...

Not sure that I'm reading your snippet correctly, but it seems that your application is trying to call itself.

That does indeed appear to be the case, which seems an odd approach.

...

Unless you're putting some parallelization mechanism, this will never, ever work: the second request will be served only *after* the initial one is completed, and the initial hangs waiting for a response to the second. I suggest to put a low timeout on $browser to see what's going on.

It ought to work if running the app via e.g. Starman, where multiple processes are forked to handle multiple requests at once, but yes, with the standalone server, it will fail.

...

Even with parallelization in place this is probably a bad idea and it would be better addressed with some refactoring/modularization.

Indeed.

Cheers

Dave P

-- David Precious ("bigpresh") http://www.preshweb.co.uk/

"Programming is like sex. One mistake and you have to support it for the rest of your life". (Michael Sinz) _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users

_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users

The "access_log" part will be renamed soon to "show_startup_info" or something like that. There's a ticket regarding it. On Sun, Apr 10, 2011 at 4:53 PM, sawyer x <xsawyerx@gmail.com> wrote:

Sorry to join the party late!

It is perfectly fine to run tests with Dancer and WWW::Mechanize. Since Dancer is a listener, the easiest way for you to do so (and the way we do it in our core tests) is using Test::TCP. Here is a small example of how to do it. I used Test::WWW::Mechanize to reduce the testing code itself:

#!/usr/bin/perl use strict; use warnings;

use Test::More import => ['!pass']; use Test::TCP; use Test::WWW::Mechanize;

test_tcp( client => sub { my $port = shift; my $mech = Test::WWW::Mechanize->new(); my $main = "http://localhost:$port";

$mech->get_ok("$main/"); $mech->get_ok("$main/hello");

$mech->title_is('Hello world'); },

server => sub { use Dancer;

my $port = shift;

setting access_log => 0; setting port => $port;

get '/' => sub {1};

get '/hello' => sub { return '<html><head><title>Hello world</title></head></html>'; };

start; }, );

done_testing();