We moved to Redis.io!

Note: small typo on 'UBSCRIBE first second'.

Awesome, you're adding new features quicker than us client library maintainers can keep up - all good.

Any chance of providing better support for normal message queues, specifically: ZREVPOPLPUSH - 'POP highest priority message from Priority Queue and PUSH into worker queue (List)' LREMLPUSH - 'REM from worker queue and PUSH into a) success -> 'out/processed queue' b) failure -> 'dlq' http://groups.google.com/group/redis-db/msg/81c2df6924c88a5b

Unfortunately these aren't possible with MULTI/EXEC as I need to operate on the POP'd value in the transaction.

This is potentially awesome for real-time COMET apps!

What happens if the client disconnects without calling unsubscribe, does redis server unsubscribe this client?

wow, you really implemented this in a few hours?? quite impressive.

Also, if i'm getting this thing right, a client needs to keep its connection open to redis-server for receiving the published messages, right?

That would be fine for event-driven clients, but for other clients i think this would consume a lot of resources to scale to a big number of users. For this scenario, would you think it's a good idea to give to each subscriber a token id, which it could be used to get new messages (stored in a buffer) published while this subscriber were disconnected?

Denis, got your point, the idea is that priority queues can already be implemented mixing sorted sets and lists in many different ways, so the sorted sets will not probably implement blocking operations or alike.

Thanks for the suggestion!

Diego, yep once a client closes the connection all its classes are automatically unsubscribed. About taking the connection open, this is how the Pub/Sub pattern is implemented, you can connect 5000 clients and it will work well, no probs ;) When the problem should be addressed without persistent connections, lists are the way to go. This messaging model is really designed for persistent connections, but what I tried to do is designing it to make it suitable for bot event-driven and blocking clients. Why it is resource intensive for blocking clients? A client can just issue the subscribe and waiting for messages in a blocking way. Given that every client can listen to many classes of messages a single connection can be used for a lot of notifications of different kinds.

@Tim: I need to be fast! As 1 april is feature freeze day :)

@antirez Is the addReplyLong(c,receivers); in publishCommand intentional? It's not mentioned in the documentation. If so, should it be a fourth element of the multi-bulk response? Seems like it could throw off some clients.

@tristanzdunn: yep it's better to mention that the PUBLISH command reports the number of clients that got the message indeed, but I can't see how this can lead to a bug or problem with clients. Thanks for noticing that it's not documented!

@antirez Oh, I see my mistake. I was confused because I was publishing on the same client that I was subscribing on, making it appear to be two responses from one command. Thanks for adding the documentation.

@tristanzdunn: ah got it, but then you don't have latest mater release maybe? As the new one should not allow other commands when you are listening to at least one class of messages.

Why was 'class' chosen over 'channel'?

@antirez would be awesome to use "channel" instead of "class" :) it's definitely what would be expected, and if you're going to use e.g. javascript internally to redis then that's a reserved keyword

Yep I understand that "channel" makes just more sense, but for some reason the right terminology of pub/sub is class... Don't know why. For a time I wanted to conform and I did the wrong thing? ;)

Just read it as "classes of messages" and I think it starts making sense.

No you are right, I read better the wikipedia entry and I'm going to replace all the "classes" with "channels" in the documentation and inside the code itself.

Wouldn't it make sense to tie up commands to messages sent on channels? If it is just messages published / subscribed, is there a correlation to the data stored on redis? Isn't it a completely independent pubsub framework inside redis?

For example, Say there are only SUBSCRIBE / UNSUBSCRIBE commands and no PUBLISH.. and messages can be published by any client by adding an optional list of channel names at the end of each command..

Eg: SET key value channel1 channel2

This will automatically publish messages to any client who is listening on channel1 and channel2. This way, there is no need to  issue 2  commands: SET and PUBLISH.. And there is a tighter coupling with redis' core functionality.

Further, this could be implemented as an extension using hooks to execute custom code before / after any command execution. (Opened a feature request for this at: http://code.google.com/p/redis/issues/detail?id=222 ). This way, the core of redis is unchanged.

Thoughts?

I assume the PUBLISH command only returns once the subscribers have been informed?

what is the intention of PSUBSCRIBE?

is there any Perl/java client which supports publish/subscribe. I didn't find one.Please point it to me

How is replies to other Redis commands interleaved with the push messages as a result from a subscribe?

Assume that we're subscribing to "fruits", then for instance send a SUNION. If at the same time someone publish "banana" to channel fruits", which will be sent first to the client: SUNION result or the newly pushed message?

Is there some way to hold of the Redis server?

Firstly, I'm having a great time with Redis, it works great.

I have a comment about psubscribe and punsubscribe though: I think you should mention in your docs that if you call psubscribe() which subscribes you to two channels (eg "c1", and "c2"), if you call punsubscribe without a pattern argument it will only unsubscribe you to one of the channels!

To unsubscribe fully you need to pass back in the original pattern you submitted to psubscribe

Not sure if this is intented, but probably would be worth including in the docs.

I guess it's a V2-only feature ?

> redis-cli subscribe chan1 Unknown command 'subscribe'

I'm using redis 1.2.6. It should appear somewhere in the doc Thanks

@philippe: added a note stating that this commands are available starting from Redis 2.0.0. Thanks.

I'm trying wrapping pub/sub functions using a php class. When a client subscribes a channel "c1", how could it receive the published messages once a publish operation is executed by another client? I've tried the method of polling to fetch the message from the response, however, I want to know whether there is another better way to achieve this? Thanks a lot.

In a replicated configuration, does PUB/SUB work where you have publishers attached to the master and subscribers attached to the slave?

howto limit subscribers? is there a method.

use case: rather than 'chat' analogy think 2 or more player game, where only a limited number of identified subscribers can publish messages, but anyone can subscribe.

More than likely my query relates to a separate implementation, not pub/sub but pointer would be appreciated

how can i subscribe the issue that some pattern keys are inserted or updated?

The link to Peter Noordhuis' example is broken; this should be a fair substitution: http://rediscookbook.org/pubsub_for_synchronous_communication.html

有中文就好了