Callback hooks for established connection, channel, etc. #7

foresto opened this Issue Jul 21, 2011 · 4 comments


None yet
2 participants

foresto commented Jul 21, 2011

Following best practices, I want my daemon to indicate that it's ready for work only after all of its communication channels are ready. It seems that haigha schedules connections (and possibly channel setup?) to happen asynchronously, which is great, but it makes it very difficult to know when connections, channels, and queues are fully established. To that end, how about some more callback hooks?

EDIT: This would also be useful for programs that start up with data to publish to a queue, but have to wait for the message broker (which might be started later) to become available.


awestendorf commented Jul 22, 2011

It's possible to queue a lot of actions in the same loop as the Connection object is created, and haigha will correctly manage asynchronous and synchronous frames.

I do plan to add many new callbacks in the 0.3 series. Do you have any specific requests?

foresto commented Jul 25, 2011

Right now, my daemon is doing calling Connection(), channel(), exchange.declare(), queue.declare(), queue.bind(), and basic.consume(), all in the same pass through the event loop. It might soon call basic.publish() as well. Presumably, haigha is queuing events to execute all those actions sequentially while my code moves on to other things. It would be helpful to get a callback when haigha finishes everything I asked it to do, effectively notifying my code that the message bus is fully up and running. Something like an all_queued_actions_done_cb() would be ideal.


awestendorf commented Jul 26, 2011

It is queuing, and there are a few cases where callbacks are supported. For now, look for a cb= kwarg in a method to determine if it supports callbacks. I've identified a few places that need callbacks and I'll be sure to take these into account.

This release cycle will also include documentation on using all of these features, as well as on internals of haigha and what can be assumed when using it.


awestendorf commented Apr 27, 2012

The remaining feature requests are now in master and will go out with todays release.

  • Connection takes optional open_cb= argument
  • Channel has add_open_listener for notifications when open-ok is received from the broker
  • Added optional cb= argument to basic.consume for notification when the consumer is registered

As noted, the rest of the protocol commands that support callbacks can be found by looking for cb= kwargs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment