Thanks for this information. I can work around it now that I know its a known issue. I already have another REQ/REP control connection that can handle this case.
On 27. 01. 2016 15:16, Pieter Hintjens wrote: > There are issues using zmq_ctx_destroy where if we wait for messages > to be sent, it can deadlock. Afair we do not wait and thus in some > cases the last message can be lost. > > My advice is to not trust your transport to send the last message in a > stream. Rather, use a handshake to close a connection. If you can't do > this (and over push/pull you can't) then the only other option is to > wait a while before closing the socket. > > > > On Wed, Jan 27, 2016 at 1:58 PM, Tomaz Beltram <[email protected]> wrote: >> Hi, >> >> I am using the pipeline pattern with one PULL socket with zmq_bind() to >> an arbitrary port on the localhost interface (tcp://127.0.0.1:*) and one >> PUSH socket with zmq_connect() to the port that was assigned by the system. >> >> The sender may finish and call zmq_close() and zmq_ctx_destroy() before >> the receiver gets all messages that were sent. This should be OK, since >> according to the documentation zmq_close() should wait for undelivered >> messages to be transferred. >> >> Very rarely I observe that the last message that was sent is never >> received. I was not able to reproduce the issue with a minimum test case >> that I prepared and even in the real application its occurrence is very >> seldom. Still I would like to track it down and avoid if possible. Any >> ideas what I should do differently? >> >> wbr >> Tomaz >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
