[Dancer-users] Problem with WWW::Mechanize in Dancer

[Flavio Poletti]

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 at 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 at 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 at perldancer.org
>> http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
>>
>
>
> _______________________________________________
> Dancer-users mailing list
> Dancer-users at perldancer.org
> http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.backup-manager.org/pipermail/dancer-users/attachments/20110408/40b77199/attachment-0001.htm>