You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The QBLPUSH and QBRPUSH commands would allow blocking until some timeout is met and receiving all messages related to that eventID. This would be achieved by listening on the QueueChannelNameKey(queueName, eventID) redis subscription channel. QREM would need to be modified to allow passing in a result string of data that publishes to that same channel.
So would the client be listening on that redis channel? Or were you just saying it should do that internally?
I would think QBLPUSH and QBRPUSH would return either nil or whatever data is passed back by the QREM call (and nil on timeout). We also might think about renaming QREM, since it's job isn't really to remove items from the queue, but more to acknowledge that they've been consumed correctly and shouldn't be given out again, and sending back a result string to a "remove"-type command would be really strange.
As with #7 maybe we could just make this part of the QLPUSH and QRPUSH commands? Something like:
The QBLPUSH and QBRPUSH commands would allow blocking until some timeout is met and receiving all messages related to that
eventID
. This would be achieved by listening on theQueueChannelNameKey(queueName, eventID)
redis subscription channel. QREM would need to be modified to allow passing in a result string of data that publishes to that same channel.The text was updated successfully, but these errors were encountered: