On the other hand, if you send a heartbeat down your pubsub channels,
you can implement timeouts on the client side without much difficulty.
Then again, I advocate for not using pubsub at all, and instead
advocate using polling itself unless you absolutely must get as close
to real-time performance as possible.
Regards,
- Josiah
> --
> You received this message because you are subscribed to the Google Groups
> "Redis DB" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/redis-db/-/E86RdkMxC2AJ.
> To post to this group, send email to redi...@googlegroups.com.
> To unsubscribe from this group, send email to
> redis-db+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/redis-db?hl=en.
>
If everyone polls, then on such a situation, some people slow down,
but the system is still available, because no one can poll more than
they receive.
If you are using Redis pubsub as a point-to-point messaging setup,
it's probably not an issue unless you are moving many millions of
messages per day. We ran into a shoddy network card/switch in EC2
leading to memory growth and a crash on a master. For us, it happened
pretty fast because of our volume of writes (which was good for us).
In pubsub, you may see slow memory growth over time, or never see it
(except that you have things completing on one side, but not being
reported on the other), or you may not even get your requested timeout
response (if your feature request is accepted and implemented) from
Redis.
Regards,
- Josiah
> --
> You received this message because you are subscribed to the Google Groups
> "Redis DB" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/redis-db/-/ohiZXmeClQYJ.
the blocking list functions support a timeout parameter, but pubsub listen does not - this would seem to be necessary for implementing things like longpolling. Is anyone else missing this functionality or is it just me?
m