Re: what happens to messages in a redis pub/sub queue when redis reconnects?

[Marc Gravell]

If you mean at the redis server - if the client wasn't connected when it was published, then the message *is gone* - it no longer exists. It is a "broadcast to anyone who is listening" system, not a guaranteed delivery system. If you want that, consider using a queue - but note that even that could have issues if you pop something and your connection or client dies while it is in flight. Another option would be a set/sorted-set, since you can issue an explicit remove on the set once you know it is processed. There have been recent discussions about more reliability features in pub/sub: https://github.com/antirez/redis/issues/1089

Marc

On 10 May 2013 12:13, sofia cardita <sofiac...@gmail.com> wrote:

Hi,

Using the node-redis client I'm seeing redis reconnecting on average each 5 min. What happens to the messages it already has received but has not sent yet? Are they resent later on reconnect or are they discarded?

Thanks :)

Sofia

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.
To post to this group, send email to redi...@googlegroups.com.
Visit this group at http://groups.google.com/group/redis-db?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Regards,

Marc

[Wolfgang Richter]

It sounds like he was more interested in messages sent and queued in memory by the redis-client (libhiredis ?).

--

Wolf

Wolf

[Wolfgang Richter]

She* (sorry!), and I'd answer, but I don't know the answer to this question:

What does redis-client do when it reconnects?  Completely new context losing previously queued operations (if sending them asynchronously?)?

--

Wolf

--
Wolf

[Josiah Carlson]

There are 7 layers of interfaces between your client sending data and what happens on the wire/over the air (though some of those layers have been effectively merged). Generally speaking, the client may batch up commands, but the moment that it sends it via the underlying send/write socket call and it gets buffered by the operating system, it is sent as far as most application-level protocols are concerned. Depending on your operating system, there may be system calls you can make to determine how much of the data you've sent has been acknowledged by the recipient, but that is a nasty violation of separation of concerns and layering.

If you are concerned about making sure that your data gets published, then subscribe to those channels that you are publishing on, then publish on them. If you don't get the message via subscription that you expect, then re-send.

That said, I'd be willing to wager that you are over-thinking your issue. The only clients that should be publishing or subscribing to Redis are clients that are on the same lan/vlan. Unless you are having hardware issues or your network is at capacity, intermittent connection issues should be rare (as in once every week or two). Heck, I will typically leave SSH connections open between development workstations at home and at the office, and those will usually stay open for 1-2 weeks over the internet without issue.

 - Josiah

On Fri, May 10, 2013 at 5:00 AM, sofia cardita <sofiac...@gmail.com> wrote:

I was reading about the tcp protocol and from what i could understand if a receiver has not acknowledged the message in x time, the sender should automatically resend x times until it gets an acknowledgment. So the question was if redis had not sent the message yet (maybe it keeps a buffer of n messages and sends them all together or maybe this might be implemented in some clients and not others - do you know?) and meanwhile lost a subscriber, it it would retry sending when the subscriber came back online in a given n milliseconds. 

The RETAIN command might be interesting though if it gets implemented.

Sofia