On 01/03/2012, at 09:13 PM, Dave Cragg wrote: Hi Dave - thanks for your input - I really appreciate it - inline comments below...
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. In most cases I am using flags but there are a couple of routines that involve multiple requests and send in time constructs - the socket testing method seems to work better in these instances. 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. Yes, I've been doing that for a while and the results in the log field are typically fine. The odd thing is that the socketError and socketTimeout messages don't seem to fire at all - which fits with your 'stuck in a loop' idea (and my experience). Manually interrupting the script usually does the trick but what I really want to do is to find out how to force the script to exit by itself gracefully. As you've probably guessed, the libURL stuff is out of my league. Terry... Dave _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com<mailto:use-livecode@lists.runrev.com> Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode Dr Terry Judd Senior Lecturer in Medical Education Medical Eduction Unit Faculty of Medicine, Dentistry & Health Sciences The University of Melbourne _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
