Lazy Pirate reliable request-subscribe

[Bob Edwards]

Here's a 'reliable' request and reply written in Labview 2010, I'm running in win XP.

https://www.dropbox.com/s/54sbqz92ey7om6g/Multipart%20request%20-%20simple.vi
https://www.dropbox.com/s/fu7anqck5f9jnyi/Multipart%20reply%20-%20simple.vi

I start the reply as a compiled exe. I start the request vi but it silently crashes labview dev system. Are there any obvious design issues please?

I have a beacon system running in publish / subscribe for application discovery, which seems to be more bomb proof, but the above is needed to move data around the applications. I have a central controller which transfers data with slave applications.

Cheers, Bob

(Oops - topic should have read Lazy Pirate request / reply)

[Martijn Jasperse]

Sounds like you've run into an assertion failure. ZMQ sanity checks its internal state using asserts, which terminate the host application if they fail. In non-GUI development this is not an issue, but as you observe, for us it terminates the whole LabVIEW environment with no error message, making debugging extremely difficult.

I'll be releasing an update this week that will trap such errors and produce error details. These errors are not recoverable, but should prevent the RTE from terminating.

Your VIs run fine on my Win7 machine (including compiling to EXE) so it could potentially be an XP issue. At first glance there seems nothing wrong with the VI design; though even if there were it should not crash the RTE.

Which version of ZMQ are you running? You can check with zmq_version.vi. Until recently the package shipped a pre-release version, and upgrading to v3.2.4 release is advisable (get official binaries and copy libzmq-v110_xp-mt-3_2_4.dll to libzmq32.dll)

[Bob Edwards]

labview-zmq-1.5.4.86 was installed on Win XP. Attempting to use the VIs resulted in 'InitializeCriticalSectionEx is not found in kernel32.dll on windows xp'.

So'0MQ 3.2.4 for XP SP3' was installed and a renamed dll inserted into the Labview-zmq addon. I just ran the zmq 'version' vi confirming 3.2.4. OK on your update pending and thanks for the quick response (My project isn't holding anything up, the Excel based test exec. is a 'would like')

Wet and windy in the UK today - so a Sunday afternoon doodling with Labview for me. Like what you've done with zmq and would like to contribute, maybe with some more 'examples' to help other folks, based on my learning steps.

[Martijn Jasperse]

I've uploaded a version of the library with enhanced error handling (v1.6.0) that should trap assertion fails and stop LabVIEW from being terminated. If it detects such an error, it should present a dialog box pointing you to a log file and error 1097 (library error) should propagate through your code. Given that such errors only occur when ZMQ enters an unexpected/undefined state it's the best thing I can think of. Just remember to overwrite the packaged libzmq32.dll - I'll put the XP compat library in the next version.

I'd certainly appreciate contributions; progress on this library generally happens when others try to do something different with it. Certainly tutorials or examples that show others how to get started would be good; my examples are a bit barebones!

[Bob Edwards]

Version 1.6.0 installed
Recompiled 'Multipart reply simple.vi' and started it.
Loaded and ran 'Multipart request simple.vi' in the RTE, checked data was flowing OK
Stopped 'Multipart reply simple' to simulate a slave app failure and observed the queue size increase to the limit in 'Multipart request simple.vi'
At the first attempt by 'Multipart request simple.vi' to close and reconnect, your error message appeared. On clicking OK, the RTE disappeared silently
lvzmq-err.log read: -

Assertion failed: ok (......\src\mailbox.cpp:84)
Assertion failed: nbytes == sizeof (dummy) (......\src\signaler.cpp:223)

It may be linked with connecting the second time. I modified 'Multipart request simple.vi' not to try reconnection. If the stop button pressed, just close and destroy context. The transmit message queue was seen to rise every time 'reply' was stopped. Stopping 'request' was successful and the RTE stayed running.
Any clues there? Cheers Bob

[Martijn Jasperse]

Sorry, I should have seen it earlier, but the problem is that in the request code you're calling "Close Socket" while simultaneously using that same socket for a blocking receive call. This produces undefined behaviour as it deallocates memory currently in use by the blocking call, which the OS strongly disapproves of. To use this paradigm you'd have to use "Destroy Ctx" which unblocks the call reliably, but then requires a new context to be created.

Since it's probably of interest to anyone trying to understand how ZMQ does things, I've ported the Lazy Pirate pattern C code from The Guide, now in the examples/ directory, uploading now.

[Bob Edwards]

Martijn, thank you - now working - I hadn't checked the 0MQ guide and examples closely enough. Request / Reply now work reliably even if one stops and restarts and they shut down without misbehaviour of the development system too. (Although I find one of the apps must be compiled and run as an exe)

The revised, commented code can be found at : -
https://www.dropbox.com/s/fu7anqck5f9jnyi/Multipart%20reply%20-%20simple.vi
https://www.dropbox.com/s/54sbqz92ey7om6g/Multipart%20request%20-%20simple.vi

I'm moving onto the test executive app employing a Router link with one or more slave apps each running a Request link with a string based identity. The idea is to have the slave apps make themselves known to the controller, which can then reply to send out commands to them using the identities. I'll post the try-out shortly.