I'm migrating our system that uses LVZMQ to a new computer, but after porting the same code (previously win10, LV2015) to the new machine (win7, LV2018) i'm finding that ZMQ processes that try to use the DEALER connection mode hang, either in send or receive message with timeout.
REP/REQ appears to work without problems, but unfortunately our system requires DEALER in order to send and receive asymmetric messages.
In my dealer, I currently open and bind to a socket, then loop over a receive with timeout to receive incoming messages. When a message is receieved, it triggers a send multi-part reply.
In my requestor, I open and connect to a socket on the same port. On user click, I send a multi-part message, then after some delay, i do a receive-with-timout the reply.
At first, the dealer will loop at the expected rate, checking for messages and timing out as expected. But once a message is sent from the REQ side, the read-with-timout vi just hangs, and never returns.
Alternatively in some cases, it is the REQ send that hangs, never returning from the send-multipart message.
I should note that i'm testing this with dealer DEALER and REQ both opened in different contexts on the same machine. Is that a problem? I see ZMQ says processes aren't thread-safe, but i'm not sure how to control threads in labview. I've tried specifying that the REQ and DEALER sides run on different CPU cores, by enclosing their whole block diagram in a timed while loop and specifying the CPU core, but this doesn't seem to help. Ultimately I end up having to kill labview via task manager. :(
To confirm, the exact same code worked on LV2015? Are both the old and new LV versions 64-bit? How many parts are involved in each message? Does LabVIEW hard crash or just never return from the CLN call? What value of timeout did you use?
There should be no problem using different contexts, it just adds overhead but helps overcome some thread-safety issues. Have you tried the same pattern with the DEALER and REQ in different VIs? What happens when you press the STOP button?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Martijn. Apologies for the noise, it seems like the application had in fact changed from our previously working configuration after all. Somehow the requester connection type in our testing vi had been set to REP as opposed to DEALER. I didn't pick it up as I didn't realise REP:DEALER wouldn't work - I expected that provided we followed the REP message ordering (send/receive, send/receive) this would be fine, but that seems not to be true. After switching to DEALER:DEALER everything works as expected.
Thanks for the prompt reply all the same. :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the update! Glad to know it's not an issue with the library itself, even if it's counter-intuitive how some of the socket types relate to eachother. Good luck with developing your application.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm migrating our system that uses LVZMQ to a new computer, but after porting the same code (previously win10, LV2015) to the new machine (win7, LV2018) i'm finding that ZMQ processes that try to use the DEALER connection mode hang, either in send or receive message with timeout.
REP/REQ appears to work without problems, but unfortunately our system requires DEALER in order to send and receive asymmetric messages.
In my dealer, I currently open and bind to a socket, then loop over a receive with timeout to receive incoming messages. When a message is receieved, it triggers a send multi-part reply.
In my requestor, I open and connect to a socket on the same port. On user click, I send a multi-part message, then after some delay, i do a receive-with-timout the reply.
At first, the dealer will loop at the expected rate, checking for messages and timing out as expected. But once a message is sent from the REQ side, the read-with-timout vi just hangs, and never returns.
Alternatively in some cases, it is the REQ send that hangs, never returning from the send-multipart message.
I should note that i'm testing this with dealer DEALER and REQ both opened in different contexts on the same machine. Is that a problem? I see ZMQ says processes aren't thread-safe, but i'm not sure how to control threads in labview. I've tried specifying that the REQ and DEALER sides run on different CPU cores, by enclosing their whole block diagram in a timed while loop and specifying the CPU core, but this doesn't seem to help. Ultimately I end up having to kill labview via task manager. :(
Recap: Win 7 64 bit, LV2018, labview-zmq-3.5.1.109.vip
Last edit: m 2019-07-10
To confirm, the exact same code worked on LV2015? Are both the old and new LV versions 64-bit? How many parts are involved in each message? Does LabVIEW hard crash or just never return from the CLN call? What value of timeout did you use?
There should be no problem using different contexts, it just adds overhead but helps overcome some thread-safety issues. Have you tried the same pattern with the DEALER and REQ in different VIs? What happens when you press the STOP button?
Hi Martijn. Apologies for the noise, it seems like the application had in fact changed from our previously working configuration after all. Somehow the requester connection type in our testing vi had been set to REP as opposed to DEALER. I didn't pick it up as I didn't realise REP:DEALER wouldn't work - I expected that provided we followed the REP message ordering (send/receive, send/receive) this would be fine, but that seems not to be true. After switching to DEALER:DEALER everything works as expected.
Thanks for the prompt reply all the same. :)
Thanks for the update! Glad to know it's not an issue with the library itself, even if it's counter-intuitive how some of the socket types relate to eachother. Good luck with developing your application.