Changed
ssubscribeaccepts shard channels of several slots in a cluster. The
server requires one slot perSSUBSCRIBE, and the client refused a
cross-slot one withMismatchedKeySlots. A shard subscription is per
channel, so nothing is lost by splitting it: oneSSUBSCRIBEis now sent per
slot, to the master owning it, and the caller is answered once every master
has confirmed.
Fixed
-
A sharded
PubSubStreamspanning several slots is released in a cluster.
A stream may hold shard channels of several slots, added one
PubSubStream::ssubscribeat a time (or, since the change above, in a single
ssubscribe). Itscloseand itsDropthen released them all in one
SUNSUBSCRIBE, which the cluster connection refused before sending it
(MismatchedKeySlots):closefailed,Dropfailed silently, every
subscription stayed on its master, and the next command on theClientcould
stall. ASUNSUBSCRIBEnaming several slots, including one passed to
PubSubStream::sunsubscribe, is now split per slot and sent to the master
owning each one. -
A command the cluster cannot route no longer poisons the connection. A
command refused before being sent — keys spanning several slots where one
is required, or a command the cluster does not support — was refused only
when the network task fed it, after its bookkeeping had been recorded:- a refused
SSUBSCRIBEleft its pending batch at the head of the
subscription queue, so the next subscription on the sameClientwas
matched against it and never answered; - in a pipeline, the commands ahead of the refused one had already been
written, and their replies were handed to the next callers; - the messages queued behind it in the same send batch were not sent until
another message woke the network task, so their callers could wait
forever on an idle client, and the refused message's byte charge was
never released from the send-queue budget.
Such a command is now refused before anything is recorded or written, and a
message whose feed fails for any other reason is failed on its own while
the rest of its batch goes out. - a refused