On Nov 17, 2014, at 12:54 PM, Mehdi Abaakouk <[email protected]> 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: [email protected] > irc: sileht > > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
