Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

P|UNSUBSCRIBE command ( with no args ) #714

Closed
rootslab opened this Issue · 2 comments

2 participants

@rootslab

If I send a P|UNSUBSCRIBE command without arguments ( and without previously having subscribed to any channel ), the Redis Server doesn't reply anything ( no data ).

I would expect a multibuk reply like :

telnet> unsubscribe 
*3
$11
unsubscribe
$-1
:0

instead I get :

telnet> unsubscribe
<---- NO REPLY!---->
ping
+PONG

I think it's a bug (every command needs a reply), or is it the correct behaviour?
In the latter case, how a Redis client could be able to maintain the queue synchronization between commands issued and replies received?

@rootslab

I think that something like this, could be added in the logic of
pubsubUnsubscribeAllChannels / pubsubUnsubscribeAllPatterns functions.
https://github.com/antirez/redis/blob/unstable/src/pubsub.c#L153

..
while ( .. ) {
..
}
if (notify && (count == 0)) {
    addReply(c,shared.mbulkhdr[3]);
    addReply(c,shared.unsubscribebulk);
    addReply(c,shared.nullbulk);
    addReplyLongLong(c,0);
}
..
@antirez antirez referenced this issue from a commit
@antirez UNSUBSCRIBE and PUNSUBSCRIBE: always provide a reply.
UNSUBSCRIBE and PUNSUBSCRIBE commands are designed to mass-unsubscribe
the client respectively all the channels and patters if called without
arguments.

However when these functions are called without arguments, but there are
no channels or patters we are subscribed to, the old behavior was to
don't reply at all.

This behavior is broken, as every command should always reply.
Also it is possible that we are no longer subscribed to a channels but we
are subscribed to patters or the other way around, and the client should
be notified with the correct number of subscriptions.

Also it is not pretty that sometimes we did not receive a reply at all
in a redis-cli session from these commands, blocking redis-cli trying
to read the reply.

This fixes issue #714.
742e580
@antirez antirez referenced this issue from a commit
@antirez UNSUBSCRIBE and PUNSUBSCRIBE: always provide a reply.
UNSUBSCRIBE and PUNSUBSCRIBE commands are designed to mass-unsubscribe
the client respectively all the channels and patters if called without
arguments.

However when these functions are called without arguments, but there are
no channels or patters we are subscribed to, the old behavior was to
don't reply at all.

This behavior is broken, as every command should always reply.
Also it is possible that we are no longer subscribed to a channels but we
are subscribed to patters or the other way around, and the client should
be notified with the correct number of subscriptions.

Also it is not pretty that sometimes we did not receive a reply at all
in a redis-cli session from these commands, blocking redis-cli trying
to read the reply.

This fixes issue #714.
3ff75e5
@antirez antirez referenced this issue from a commit
@antirez UNSUBSCRIBE and PUNSUBSCRIBE: always provide a reply.
UNSUBSCRIBE and PUNSUBSCRIBE commands are designed to mass-unsubscribe
the client respectively all the channels and patters if called without
arguments.

However when these functions are called without arguments, but there are
no channels or patters we are subscribed to, the old behavior was to
don't reply at all.

This behavior is broken, as every command should always reply.
Also it is possible that we are no longer subscribed to a channels but we
are subscribed to patters or the other way around, and the client should
be notified with the correct number of subscriptions.

Also it is not pretty that sometimes we did not receive a reply at all
in a redis-cli session from these commands, blocking redis-cli trying
to read the reply.

This fixes issue #714.
2039f1a
@antirez
Owner

Indeed this is a bug, fixed now. Thanks. More info in the commit message.

@antirez antirez closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.