-
Notifications
You must be signed in to change notification settings - Fork 2
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
Ready callback #68
Comments
Please let me know if you have interest in a PR for this too @nsweeting. |
@Odaeus Thanks for the suggestion. I'm wondering if you could provide a bit more context on the use case you have where an outside process is needing to interact with a consumer process? This might also be able to get solved in another way. If you look at Line 81 in 021b7e4
GenServer.init/1 callback. Within the context of a supervision tree - this means the producer will block until fully setup and any processes that rely on the producer can be assured it will be ready as long as they are placed after the producer within the tree.
We could provide this option within the consumer as well. I would typically default this |
My main use-case so far is so that integration tests can wait for the consumer to be ready before sending a message. I had a couple of other ideas about it being useful to notify other parts of the system that the consumer was ready. One was that it would notify another part of the system that it can now register the bindings for this queue, but I can achieve the same with our beloved I normally do my best to avoid adding code only for testing but I think anything is better than polling if it can be avoided. I think your |
Yeah - I think adding |
In addition to the
handle_setup
work I found I had trouble with failing tests due to timing issues between sending a message and the consumer being ready to receive. I see that Rabbit's own tests use polling to wait on the state of the consumer GenServer.To improve this I've added an
on_ready
callback: Odaeus@b6abacdI can't open a PR yet as it's built on top of #67. Please let me know if you'd be interested in incorporating it too. I'm not fixed on
on_ready
as a name buthandle_ready
didn't sound quite appropriate.The text was updated successfully, but these errors were encountered: