On Thu, 2018-04-05 at 08:59 +0200, Gyorgy Szekely wrote:
> Hi all,
> I would like to clarify the effect of the linger setting on inproc
> transports.
> 
> Background:
> I have a message broker that has a stateful routing thread and a
> number of
> front-end threads that manage websocket sessions. The routing and
> websocket
> threads communicate over zmq inproc transport with router-dealer
> sockets
> (respectively). The routing is stateful and must be notified of the
> websocket session closure, this is done with a message
> (websocket->routing). The websocket session closure also closes the
> corresponding zmq dealer socket.
> 
> Question:
> So I have a dealer socket connected to a router over inproc, and I
> close
> this socket immediately after sending a message. I want to be
> confident in
> the following 2 statements:
> - the message before the close never gets dropped
> - the socket close never blocks for a considerable amount of time
> (let's
> say more than 1ms)
> (The router socket is permanent)
> 
> Does libzmq guarantee this? How should I set the linger time?
> 
> The API docs state that inproc transport can run with a thread-less
> context, this made me think that sends on inproc are practically
> synchronous, and by the time send returns, the message is in the
> receiving
> socket's input queue. Is this true?
> 
> Regards,
>   Gyorgy Szekely

You can never guarantee that, simply because they are inherently
conflicting statements. If you set linger to -1 and the other end exits
prematurely then you'll block. If the application is too slow it will
break the block limit.

Most importantly, don't create&destroy sockets continuously. It's an
anti-pattern. It's setup&config code, not optimised critical path.

-- 
Kind regards,
Luca Boccassi

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Reply via email to