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
Support callbacks on connection or channel Shutdown and connection Blocking #52
base: master
Are you sure you want to change the base?
Conversation
- add functional test for handleShutdown using scalamock - add a note into the readme for handleShutdown and handleBlocking - optimize imports
Can you explain why do you need this feature? |
9d5fb44
to
531d688
Compare
@mkiedys Sure, This is useful for monitoring and reacting when the connection to rabbit is down. (Logging, counting, prompt a reconnect). A workaround without this functionality, was to manually do a Similar can be said for a blocked connection, it is very useful to me for monitoring. @djamelz mentioned on Gitter advocating for this as well, maybe he can provide context for his motivation as well. |
Yes, i'm currently use it in production (via fork) to ensure the "based on callback" reconnection to rabbit. Combined with a retry mechanism it works very well ! |
Have you looked at supervision strategies? |
Yes, the supervision strategies were considered but found to be not optimal. Here are the two options I see in using supervision strategies and both do not come close to what the attached listeners can accomplish (but please let me know see something I don't). Also worth mentioning a blocked connection (and its blocked listener) is useful to know and not something that stream supervision can portray explicitly.
[A] when we have a fair number of pub/sub streams going into a rabbit connection (imagine having to restart thousands, multiple times until connection re-established so everyone is waiting and backing up). All those clients will have to raise a flag screaming at, say, an Actor to re-establish the connection. I'd rather see that Actor be able to monitor the RabbitMQ connection on it's own via the point above--but even better would be the listener. [B] when the publish frequency is long (e.g. several minutes) and a down'd RabbitMQ connection will only be detected and acted upon when a publish fails. We can be more proactive with listeners to detect the trouble sooner and recover faster. |
- Ensure open RabbitMQ channels are closed in the finalize method.
I have a consulting client that uses this patch and having this merged into an official release would be fantastic! Anything I can do to help make that happen? |
I can help resolve the branch conflicts that arose over the months. |
Ref RabbitMQ Java Client
3.6.1
:ShutdownListener
BlockedListener