Open Stack

Hi,

On Fri, 2013-05-17 at 14:36 -0400, Eric Windisch wrote:
> Mark: 
> 
> 
> Haven't seen you around IRC for a few days. Just making sure you're
> alive…

You know about timezones, right?

2013-05-17T13:25:18  *** markmc has joined #openstack-dev
2013-05-17T13:59:00  <dhellmann> markmc: is the oslo team meeting today? the agenda is empty.
2013-05-17T13:59:19  <markmc> dhellmann, right, no topics proposed, so no meeting :)
2013-05-17T13:59:28  <dhellmann> cool, thanks :-)
2013-05-17T13:59:37  *** markmc is now known as markymark
2013-05-17T17:41:44  *** markymark has quit IRC
2013-05-17T18:10:05  *** ewindisch has joined #openstack-dev

>  I've been on vacation myself and have only returned a couple days
> ago.
> 
> 
> I've been looking at doing a port of the ZeroMQ driver for the new
> messaging API. I'm running into some troubles and would like to
> discuss.

Cool.

> One immediate question is what calls IncomingMessage.reply()?

The executor:

https://github.com/markmc/oslo-incubator/blob/4beea4a/openstack/common/messaging/_executors/base.py#L33

>  It also isn't clear how the consuming process, upon receiving a
> message from the Listener.poll() knows to send a reply()? Perhaps this
> is always done?  That would seem to leave a lot of messages sent over
> the wire that get ignored or never get consumed?  Perhaps you just
> haven't gotten to this yet in the new API implementation?

The executor pulls a message from the listener, dispatches it and sends
back a reply or exception, if there was either.

> There is much yet to do, mostly cleaning up, stripping out old code,
> polish, and "making it work again". However, the new abstraction has
> already resulted in dropping >10% of the LOC. My branch:
> https://github.com/ewindisch/oslo-incubator/commit/a7a8921030b70be1cb48674d3df43be00e51ffb9

Yeah, you're going to need a ZmqIncomingMessage class which knows how to
send a reply.

Also, why are you spawning a greenthread when sending a cast ?

Other than that, looks like a good start.

One thing I'm thinking about after seeing this "real" driver is that
whatever I/O framework you're using, you'll have one thread/coroutine
that's a server pulling off messages and dispatching them and other
threads/coroutines blocked in call() waiting to pull its reply off the
queue. I think that's what we're doing now with eventlet and the kombu
and qpid drivers at least, but I'm not sure yet there aren't nasty
issues implied for other drivers or I/O frameworks.

Cheers,
Mark.