[openstack-dev] [oslo.messaging] status of rabbitmq heartbeat support

Doug Hellmann doug at doughellmann.com
Mon Nov 17 19:39:04 UTC 2014

On Nov 17, 2014, at 12:54 PM, Mehdi Abaakouk <sileht at sileht.net> wrote:

> Signed PGP part
> Hi,
> Many peoples want to have heartbeat support into the rabbit driver of
> oslo.messaging (https://launchpad.net/bugs/856764)
> We have different approaches to add this feature:
> - Putting all the heartbeat logic into the rabbitmq driver.
> (https://review.openstack.org/#/c/126330/)
>    But the patch use a python thread to do the work, and don't care about
> which oslo.messaging executor is used.
>    But this patch is also the only already written patch that add
> heartbeat for all kind of connections and that works.
> - Like we quickly talk at the summit, we can make the oslo.messaging
> executor responsible to trigger the
>    heartbeat method of the driver
> (https://review.openstack.org/#/c/132979/,
> https://review.openstack.org/#/c/134542/)
>    At the first glance, this sound good, but the executor is only used
> for the server side of oslo.messaging.
>    And for the client side, this doesn't solve the issue.
> Or just an other thought:
> - Moving the executor setup/start/stop from the
> "MessageHandlingServer" object to the "Transport" object (note: 1
> transport instance == 1 driver instance),
>    the 'transport' become responsible to register 'tasks' into the
> 'executor'
>    and tasks will be 'polling and dispatch' (one for each
> rpc/notification server created like we have now) and a background task
> for the driver (the heartbeat in this case)
>    So when we setup a new transport, it's will automatically schedule the
> work to do on the underlying driver without the need to know if this is
> client or server things.
>    This will help a driver to do background tasks within also messaging
> (I known that AMQP1.0 driver have the same kind of needs,
>    currently done with a python thread into the driver too)
>    This looks a bigger work.

I like the idea of fixing this in the transport. I wonder if we can combine option 1 and 3 so the transport starts a heartbeat thread? That seems like it would take less rewriting, although I do like the design changes you propose in option 3.


> So I think if we want a quick resolution of the heartbeat issue,
> we need to land the first solution when it's ready
> (https://review.openstack.org/#/c/126330/)
> Otherwise any thoughts/comments are welcome.
> Regards,
> --
> Mehdi Abaakouk
> mail: sileht at sileht.net
> irc: sileht
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list