-
Notifications
You must be signed in to change notification settings - Fork 11
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
Consider supporting Redis Streams as a true queue source #33
Comments
I’ll look into it. Yeah, this definitely predates redis streams. |
No promises though on timeliness as I’m no longer using this at my day job. @TyBarthel maybe you guys could get this on a sprint? |
That part is extremely important. Thanks for pointing this out @oising |
@turowicz I'd be more than willing to accept pull requests too. ;) |
@berdon I've had a look at the code and perhaps will. Up for my team to decide if we are going to go with Redis or something else. |
@turowicz - I'm not super familiar with redis stream behavior either, but perhaps a hybrid approach with pubsub could be implemented. When a new value is pushed into a LIST, a companion pubsub event could be used to notify waiting data. Update: Actually, it seems there is more than enough functionality to have quite a robust implementation:
|
Yes, it still requires a channel in order to keep things async. Because of that complication this solution may not be feasible for us. |
From looking at the source, it seems this provider is based on simple pub-sub and the queueing of data happens in memory, in the provider itself. I guess this is because this provider was born before redis 5.0 (where streams/lists were added) - it would add resilience and more flexibility if we could use native redis streams as a provider.
https://redis.io/topics/streams-intro
Have you looked at this already?
The text was updated successfully, but these errors were encountered: