[zeromq-dev] Can we customize a behaviour for in-mem queued messages after reconnect?

[artemv zmq]

hi Lindley,

>> The wording suggests that DEALER, at least, does its best to maintain
outgoing queues after a disconnection, but not incoming queues.

I think that's what I need: after diconnection occurs -- clear outgoing
queues  (if corresponding socket option has been set, otherwise fallback to
original behaviour).  The question -- is this valid feature?




2013/12/20 artemv zmq <artemv.zmq at gmail.com>

> I found following in t the "0mq Guide"  under section
> http://zguide.zeromq.org/page:all#Plugging-Sockets-into-the-Topology there's
> point:
>
>
>    - The network connection itself happens in the background, and ØMQ
>    will automatically reconnect if the network connection is broken (e.g., if
>    the peer disappears and then comes back).
>
> This leads me to think that 0mq can distinguish -- what is "connect" and
> what's "reconnect". Am I right?   So, original question remains -- can I
> customize "reconnect" in following way:   "if this is reconnect -- then
> clear in-mem message queue" ?
>
>
>
>
> 2013/12/20 artemv zmq <artemv.zmq at gmail.com>
>
>> Ok.    So what is definition of reconnection then?  I was under
>> impression that 0mq distinguishes terms "connected"  and "reconnected".
>>  Confused.
>>
>>
>> 2013/12/20 Pieter Hintjens <ph at imatix.com>
>>
>>> Messages are not being redelivered. They are being queued on an
>>> outgoing pipe, created when you call connect, and when that pipe is
>>> connected, being delivered. Please read the socket pattern specs, RFC
>>> 28 specifically for DEALER semantics.
>>> _______________________________________________
>>> zeromq-dev mailing list
>>> zeromq-dev at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131220/3ddd6e66/attachment.htm>