unresponsive sequential post requests - libURL problem?
dave.cragg at lacscentre.co.uk
Thu Mar 1 05:13:57 EST 2012
On 1 Mar 2012, at 00:51, Terry Judd wrote:
> Hi guys (Dave hopefully you're not too far away) - earlier on I asked about explicitly closing sockets to try and prevent Livecode becoming unresponsive following repeated post (over https) requests. Dave Cragg suggested setting the httpHeaders to "Connection: close header". This helped somewhat in that it allowed me to test for an open socket before the next request was sent (initiated by a user clicking various controls in the interface). If a socket was open then I simply ignored the user's clicks until it was closed again.
I just noticed that you're doing this for https requests. I don't have much experience of https with Livecode, so I guess it's possible that things behave differently with regard to socket messages being sent.
Also, I've never used your method of testing for an open socket to decide whether to process the user's click or not. I've either disabled the user interface until the current request returns or set a flag (script local variable) before sending a request and then unset it when the request returns. However, using "Connection: close" should let your approach work. But I don't know if it's a good approach to create a new secure connection for multiple requests over a short space of time. Perhaps some SSL gurus can pipe in.
> However, it still doesn't solve the underlying problem, and if I do stack up a few requests and Livecode typically becomes unresponsive (waiting for a lengthy period rarely solves the problem) and the only way to 'clear the pipes' is to hit command/control-period a couple of times. The first time generally frees up the cursor again (set to a custom cursor when the request is initiated) while the second time usually triggers an error message along the lines of...
> error: 624,1521,1 (or slight variations on this)
> ...to be returned in the result following the post request.
That's consistent with what I'd expect.
> This (possibly naively) leads me to think that the underlying problem might lie somewhere within libURL, with a handler or function that is reluctant to end. Is this possible?
It's possible. I haven't looked at the most recent versions of libUrl but I guess they work in much the same way as earlier versions. Generally, libUrl sits in a "wait for messages" loop while processing a request. A number of events should kick it out of that wait loop: the request completes nicely, a socketError message is sent, a socketClosed message is sent, or a socketTimeout message is sent. That should cover all eventualities (unless I've forgotten something.) But if those messages aren't being detected for some reason, then libUrl could get stuck in a loop.
Are you able to use libUrlSetLogField to record the request/response to and fro? It might give a hint as to what's going on.
More information about the Use-livecode