On 02/03/2012, at 4:10 AM, "Andre Garzia" <[email protected]> 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
> [email protected]
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
> 


_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Reply via email to