[openstack-dev] [oslo.messaging] status of rabbitmq heartbeat support
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
> 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.
> 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
> 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
> 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
> Otherwise any thoughts/comments are welcome.
> Mehdi Abaakouk
> mail: sileht at sileht.net
> irc: sileht
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev