Get HTTP vi not Reentrant?

[mjaspan]

Is it my imagination or is the vi, vi.lib\httpclient\Get.vi, which ships with LV2010SP1 not reentrant?

Followup question, I don't suppose there's any way to make a password-protected vi reentrant?

sigh.

==

Until recently, (see previous topic, Datasocket and 404 error), I was using DataSocket.vi for my http requests. This worked fine with two exceptions.

1) It fails to return the actual http text response when the http header contains an error status (ie 404 or 505 errors).

2) it appears to work 99.5% of the time, with ~0.5% of the time it times out for no apparent reason.

My solution was to switch to using the Get.vi under vi.lib\httpclient\ which ships with LV2010SP1. It works much more reliably and solves the aforementioned two issues ... however ... I recently discovered a subtle bug in my code which I've chased down to an issue with Get.vi. It appears to be blocking other instances of itself - ie it's not reentrant. Since my code relies on parallel loops making simultaneous http requests this creates a new issue for which I'm looking for a solution. The most straight forward thing would seem to try to make Get.vi be reentrant, however it appears that the reentrant checkbox is not accessible (nor any of the VI properties) due to this vi being password protected.

I assume if I purchase the Internet Toolkit, the Get.vi is the same vi, and is probably also still password protected, eh?

anyone with suggestions or thoughts?

thanks,

Martin

[mjaspan]

update.

after further testing, it appears that the vi Get.vi is configured to be reentrant, but does not behave as if it's reentrant. I've confirmed this for LV2010sp1 and LV2011. I'm starting to be concerned that something inside of it is not reentrant.

I've spoken with NI tech support and am awaiting their response.

Again, any suggestions from the peanut gallery gratefully welcomed.

Martin

[MikaelH]

Why not do it the straight forward way, with a HTTP Get.

HTTP_Get.vi

//Mike

[mjaspan]

Awesome idea. It hadn't occurred to me how simple it might be to use the straightforward approach.

I've been experimenting with your suggestion for a few days it appears to solve the primary issue by being non-blocking.

I'm building on the vi you posted to try to improve it slightly. At present, it doesn't seem to know when to stop waiting for characters so each GET takes the full timeout time of 15 seconds. At least that's true for some web sites. For others it terminates quickly which I assume has to do with the server closing the connection. I noticed many web sites provide a ContentLength tag in the header so for those I can terminate once I see that many characters. I'm not sure what the procedure is supposed to be when the ContentLength tag is missing. I'll figure out the standard protocol for terminating a GET, add it to the vi, then post it here.

Thanks!

Martin

[mjaspan]

ShuanR: I'm curious where you found the HTTP_Get.vi you posted. Is it part of a Lavag library? Thanks.

I noticed that some web servers (for example the LabView web service that's built by LV2010 Project Explorer) do not close the http connection and thus the version of HTTP_Get you posted is always left to hang until it times out.

I modified HTTP_Get.vi (see attached) to look for the Content-Length: tag in the header, and if it's there use that information to determine when to close. If it's missing, then just read characters until the connection is closed, as in the orginal version.

I also added a ParseURL.vi for my own sanity.

So far this solution solves my need.

thanks,

Martin

(attached files in LV2011)

HTTP_Get_Modified.vi

ParseURL.vi

Edited May 29, 2012 by mjaspan

[mjaspan]

Further info from NI, including some undocumented details. (Explanation, Solution, Workaround below)

In my previous post I included a solution which is re-entrant. In this post I summarize the usage of the vi's included with the NI Internet Toolkit.

Multiple instances of Get.vi will successfully execute simultaneously only if they have separate handles, previously created by OpenHandle.vi.

The handles must be created in advance - ie a call to OpenHandle.vi is must wait when an instance of Get.vi is executing until Get.vi finishes.

Apparently the non-reentrant behavior of Get.vi I reported in the top post is a result of this issue with OpenHandle.vi. A call to Get.vi without a handle wired in results in Get.vi creating a new handle internally (at least that's my interpretation - debugging this issue has been frustrated by password protection). Since new handles (apparently) may not be done while an instance of Get.vi is executing, one must pre-create a set of handles, or accept the serial performance of the non-reentrant behavior of Get.vi. Explicitly creating handles on the fly with OpenHandle.vi is problematic for the same reasons.

At the end of the support ticket, I requested my NI tech support contact add these details to the documentation (either help files and/or kb), so hopefully others won't have to re-derive this subtle bug.

Martin

[SteveChandler]

I'm building on the vi you posted to try to improve it slightly. At present, it doesn't seem to know when to stop waiting for characters so each GET takes the full timeout time of 15 seconds.

Martin

In the while loop try terminating on a Server Closed Connection error. Check for and clear that error (I think it is error 56)

[Rolf Kalbermatter]

In the while loop try terminating on a Server Closed Connection error. Check for and clear that error (I think it is error 56)

I think you should not only terminate on a Connection Closed by Peer error but just about any possible error except maybe the timeout error, although that is debatable too. And yes you would want to filter the Connection Closed by Peer error after the while loop, since that is a valid way to terminate the connection and not an error in terms of the user of your HTTP Get function.

But error 56 is definitely a timeout error, Connection Closed by Peer is error code 66