[zeromq-dev] last message lost in pipeline
Justin Karneges
justin at affinix.com
Wed Jan 27 19:01:47 CET 2016
It would be cool if libzmq, during shutdown, would write as much to the
socket as it can before quitting. This way, small messages could live in
the operating system's send buffer and survive after the process
terminates. Of course if messages are too large, or there are too many
messages, then those might be lost.
On Wed, Jan 27, 2016, at 06:28 AM, Tomaz Beltram wrote:
> 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 <tomaz.beltram at topit.si> 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
> >> zeromq-dev at lists.zeromq.org
> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
More information about the zeromq-dev
mailing list