Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

QBLPUSH and QBRPUSH commands #6

Open
mc0 opened this issue Dec 7, 2014 · 1 comment
Open

QBLPUSH and QBRPUSH commands #6

mc0 opened this issue Dec 7, 2014 · 1 comment

Comments

@mc0
Copy link
Owner

mc0 commented Dec 7, 2014

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.

+QBLPUSH queue eventID timeout contents
+QBRPUSH queue eventID timeout contents
@mediocregopher
Copy link
Collaborator

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:

QLPUSH queue eventID contents [BLOCK blockTimeout]

Again, not sure which is the better approach, but it's and idea.

@mc0 mc0 mentioned this issue Mar 24, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants