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