unresponsive sequential post requests - libURL problem?

Terry Judd tsj at unimelb.edu.au
Thu Mar 1 15:31:50 EST 2012


On 02/03/2012, at 4:10 AM, "Andre Garzia" <andre at andregarzia.com> wrote:

> Folks,
> 
> This is from the "wild crazy and potentially stupid ideas" department:
> 
> 1 - have you tried lowering the timeout interval, this way, your calls
> should fail faster and you would be able to recover more easily. Better
> retry until it work than to be locked into a timeout loop.
> 
Interesting idea. Might be a bit frustrating though if the return time is consistently more than the timeout interval. It's set at 5000 ms at the moment, which I thought was relatively short - yet despite all my problems I never seem to see the timeout message being fired.

> 2 - Are you executing these calls in a repeat loop? Are all calls inside a
> single handler such as:
> 
> on docalls
>  ...
>  put url
>  ...
>  put url
>  ...
> end docalls

All calls are within a single handler. I only have a couple of routines that involve sequential calls and they are the most apt to fail. I use send in time constructs to make the second calls and while that certainly helps it doesn't guarantee against failure. Repeated calling of handlers that contain a single call also can cause problems.
> 
> if they are all in the body of the same handler sequentially or inside a
> repeat loop, would you consider using a recursion with "send .. in time".
> In my experience, socket stuff does not like to be inside a loop or
> sequential. Sockets love recursion though and they have fun changing
> contexts. In RevHTTPd, I had some http code in a loop than would fail every
> now and then. I think it was Kee that patched it with an asynchronous model
> where calls would trigger callbacks and work like a waterfall. Then it
> stopped failing.
> 
I think if I was using load URL and had access to callbacks then I wouldn't have a problem. Unfortunately I need to use POST, so all I can do is wait until it returns something.

Terry...

> Cheers
> andre
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
> 





More information about the use-livecode mailing list