Open Stack

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.

Doug

> 
> 
> 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