3rd-Party .NET assembly interfering with HTTP calls in the same application instance

[LLindenbauer]

Dear all!

I have here a setup where I have to manage one third-party-device over a USB-Serial adapter chip and one remote computer exposing a web API. The USB/Serial-device is supported by its own .NET assembly. Both the device and the remote computer have to be periodically queried for data.

After noticing frequent timeouts from both interfaces, I have narrowed it down: When only of the device or the web API is queried, there is practically no connetion loss (except for some spikes on the network for the remote host). However, when both are queried simultaneusly in parallel loops, typically only one of the requests comes through, with the other one failing - a generic exception being thrown inside the .NET Assembly or Error 56 from the HTTP Get VI, respectively.

This only happens when the assembly and the the HTTP request are activcated from the same program. A time analysis even shows some ripple effect, where one HTTP request can make several queries on the assembly fail in a stochastic manner, for about two seconds after the HTTP request is done and closed.

When using separate executables for each query, everything seems to be fine, and it may be necessary to use that as a solution. However, if anyone has seen this before, It would be nice to not have to manage yet another interface.

Best regards.

[Kyle97330 · Accepted solution]

Could you see if you can put the subVIs doing each operation into separate execution systems and see if that has the same effect as multiple executables?

[LLindenbauer]

Thanks, that sounds promising. I cannot try it yet (the application builder stopped working since this morning), but will report back once I can test it.

[LLindenbauer]

This was a fundamental part of the solution. As it turns out, the .NET assembly was very sensitive to the thread it executed in, but the HTTP VIs had no problem.

The second part was re-using the HTTP client, not opening and closing a reference for each iteration. That also showed that both the HTTP and .NET call were blocking each other, when in the same thread. There may habe been some blocking system call with an aggressive timeout (the HTTP Get was failing with a timeout error long before the timeout set on the input).