Keyspace Set notifications

[ivan kostov]

Hi all,

I'm trying to get the Set notifications running and I have noticed, that a set notification does not containt the actual data. This is bad for my application, because my application code wants to have the actual value. So I have to wait for notifications and when a notification arives, I have to mannualy get the new value.

What I mean is:

kostov@vm:~/$ redis-cli SUBSCRIBE __keyspace@0__:testkey

Reading messages... (press Ctrl-C to quit)

1) "subscribe"

2) "__keyspace@0__:testkey"

3) (integer) 1

and when I issue:

kostov@vm:~/$ redis-cli -p 6380 set testkey testval

OK

I get the following 

1) "message"

2) "__keyspace@0__:testkey"

3) "set"

and what I want to have is 

1) "message"

2) "__keyspace@0__:testkey"

3) "set"

4) "testval"

Is there any way to configure the redis server in a such way ? 

Thanks a lot,

Ivan

[Itamar Haber]

Hi Ivan,

Nope - notifications do not nor cannot be configured to include the data itself. If you think about the current limits of 0.5GB per value and up to 2^32 elements in a data structure, the reasoning becomes evident.

What you could easily do instead is create a channel and send to it any updates that you're interested in (e.g. after SADDing, do PUBLISH mychannel set:testval).

--
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 https://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.

--

Itamar Haber | Chief Developer Advocate
Redis Watch Newsletter | &&(curat||edit||janit||)
Redis Labs | ~ of Redis

Mobile: +972 (54) 567 9692
Email: ita...@redislabs.com
Twitter: @itamarhaber
Skype: itamar.haber

Blog  |  Twitter  |  LinkedIn

[ivan kostov]

Hi Itamar,

thank you for the fast response. It's a honor for me to speak to a major Redis force :)

 

However I still have 2 questions:

1) - if I have to implement notification on an extra channel - why is the __keyspace@0__ good for ? I was happy to see that redis automaticaly notifies me for key changes, but as I said notification is not enough. 

2) - as far as I undersood the semantic of the subscription channels, if I publish on a channel whithout subscribers, there is no extra overhead. So if the user subscribes for set commands on a key that is 0.5 GB, he has to take the performance impact on count. But he will receive receive the notification and the data in an atomic way.

So the other question is, if I implement this to be a configurable behaviour, do I have any chances for my change to be accepted ? :)

[ivan kostov]

for example 

notify-keyspace-events

s - set commands only

S - set commands with the actual value

[Itamar Haber]

Major Redis force? Now you've made me blush - thanks ;)

WRT 1 - it is good for it does, which is broadcasting the events. The event tells what happened and to which key, but the data itself isn't a part of it. It is quite possible that this behavior isn't what you're looking for, so perhaps notifications are not the right approach to your current challenge. Since you've mentioned atomicity, also keep in mind that PubSub does not guarantee delivery and that means you could "lose" notifications - I don't know if that's important in your use case or not.

WRT 2 - I'm not the one deciding on what gets accepted and what doesn't, but specifically on this topic, have you seen this previous discussion - https://github.com/antirez/redis/issues/1876?

[ivan kostov]

Wel.. Chief Developer Advocate is a major force to me ;)

thanks again for your reply. From the post which you mentionet it is clear what you mean. I will think of an own channel which sends the data as well.

My use case is pretty trivial. 

I have two processes ( written in c++ or nodejs ) which shall communicate via data sets in Redis. The challenge is to implement the whole system without polling. So pub-sub sounds like a solution to me. However I was not aware that PubSub is not reliable. As far as I got it it is a normal TCP socket and if there is an active subscription, the notification will be delivered. The notifications however are not presisted - which means, that a client not running at the time of notification, it will not receive it later - if this is what you mean with "not reliable" this is perfeclty fine. 

Please confirm this

thanks in advance,

Ivan

--
You received this message because you are subscribed to a topic in the Google Groups "Redis DB" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/redis-db/pOdc8zBxB08/unsubscribe.
To unsubscribe from this group and all its topics, send an email to redis-db+u...@googlegroups.com.

[Itamar Haber]

Exactly :)

[ivan kostov]

So Redis is in this case reliable ? 

Please say "yes" one more time ;)

[Itamar Haber]

Since you're are "perfectly fine" with this, yes.