dashing-rails
dashing-rails copied to clipboard
Redis subscriptions not released when Timeout is raised
It seems as if connection_pool fails to release redis subscriptions. Once Timeout is raised, it every subsequent try will result in Timeout as well.
Steps to reproduce:
- Set redis pool size to something low (like 2 to 5)
- Open a dashboard and spam refresh
- Refresh and you won't see any widgets populated
The problem was that disconnection was not detected.
The solution:
- Adding a heartbeat job
- The trick is: the heartbeat needs its dedicated Redis connection
Hey there!
Can you elaborate a bit more about what is a heartbeat job in your case?
Sure, here it is: http://pastebin.com/hgE1bECD
5s is for development purposes, otherwise it can be longer as well.
All rufus jobs should be set to non-overlapping as well, because the 3s timeout limit allows requests to accumulate, thus using even more redis connections from the pool.
Interesting, so is there something we can do in that repo?
We can. I've since opening the issue changed the logic on my end completely.
Instead of having a subscription for each /events stream, there is now a single subscription pushing to all SSE streams. Seems like a more reasonable approach to me. Or do you any counter arguments?