Reconnects and durability

[kellyelton]

I'm just curious, I can't seem to find any docs. How does this library handle disconnects/reconnecting?

What happens when I lose connection to a publisher for example? Do I need to attach to an event and reconnect, or is there a method that auto reconnects? Is there a max number of times it tries to reconnect, or does it try forever? What's the timeout between reconnects?

Is there message durability(I would imagine not, but I ask just in case), so if I have a subscriber disconnect and the publisher pushes out a message, and the subscriber reconnects, they won't end up getting that message I'd assume? Is there an option for this(I'm comfortable making it myself, I'd just like to know ahead of time so I could take advantage of it).

[buybackoff]

I believe this is documented in the original ZeroMQ guide http://zguide.zeromq.org/php:chapter5#Pros-and-Cons-of-Pub-Sub.

In NetMQ, a subscriber could talk to a publisher (see Somdorons blog for examples), or you could use another socket to talk back to the publisher process. With this back channel, you could add a sequence number to each message and a client could tell if it lost a message and ask the publisher process to resend the missed messages. This or similar pattern is also documented somewhere in the guide.

[somdoron]

So reconnect is happen automatically, with a backoff algorithm.

As @buybackoff said there is not built-in durability.

[JamesWHurst]

For the reconnect behavior - I have added a little bit of XML-documentation within the source that describes this, for SocketOptions properties ReconnectInterval and ReconnectIntervalMax.

[buybackoff]

I have been thinking for a while about optional identities for subscribers and some hook to store undelivered messages to disconnected subscribers (e.g. events on disconnection/reconnection/undelivered messages). Without changing existing API, but opt-in. Kind of persistent subscriptions with persisted queues for disconnected subscribers (with limited time window, Kafka style). @somdoron What do you think, could such things be a NetMQ extension to the original ZMQ API? I mean, is there any vision on what extensions could be added to NetMQ (like subscribers' ability to send a message to publishers) and what should stay in separate forks? Is there a repo like NetMQ.Contrib with experimental stuff like this?

[JamesWHurst]

I was thinking in terms of the same thing. It would be very useful to have the capability to weather a few brief disconnections and not lose messages out of the queue.

[kellyelton]

Yeah. I noticed that I lose messages fairly often. It may be that I'm not configuring things properly, but maybe 1/100 messages just evaporates at some point.

I have a RouterSocket open, and what I'll do is open a new RequestSocket and send the message to the RouterSocket. Then the RouterSocket will send the message to subscribers via a PublisherSocket.

Somewhere along that chain I loose quite a few messages. I also don't do any DontWait options, I noticed that almost never would my messages go anywhere if I did that.

[somdoron]

@buybackoff durability was actually a part of ZeroMQ v2 and was removed in ZeroMQ v3, maybe @hintjens can explain better why is it not a good idea. Anyway I don't think durability should be part of NetMQ, there is patterns to solve that like Clone pattern in the ZeroMQ guide. Also take a look at Malamute project (https://github.com/zeromq/malamute/) currently is not doing durability but I think it is part of the plan.

Anyway I'm working on an article about reliability on PubSub, a time ago I added a welcome message feature to NetMQ and zeromq which can be use to recognize when the connection drop (but not when the watermark is reached).

[JamesWHurst]

This is not something I have deep knowledge of (vis a vis NetMQ), but I would think, that for durability there is some cost, and for applications such as a "ping" type of function, it is not desirable -- but for most applications it (durability) is very important and could stand to be a basic, fundamental part of the capability of a messaging library. So perhaps it could be an option? There is (I suggest) a great utility, in being able to make simple use of our API and yet have instantly a fairly robust, durable connection. I look forward to your article.