<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 13, 2013 at 11:02 AM, Mark McLoughlin <span dir="ltr"><<a href="mailto:markmc@redhat.com" target="_blank">markmc@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Doug,<br>
<div><div class="h5"><br>
On Mon, 2013-05-13 at 10:43 -0400, Doug Hellmann wrote:<br>
><br>
><br>
><br>
> On Sat, May 11, 2013 at 1:07 PM, Mark McLoughlin <<a href="mailto:markmc@redhat.com">markmc@redhat.com</a>> wrote:<br>
>         On Mon, 2013-04-29 at 11:12 +0100, Mark McLoughlin wrote:<br>
>         > Hey<br>
>         ><br>
>         > I've been working on gathering requirements and design ideas for a<br>
>         > re-design of Oslo's RPC and notifications API. The goals are:<br>
>         ><br>
>         >   1) A simple and easy to understand RPC abstraction which enables<br>
>         >      all of the intra project communication patterns we need for<br>
>         >      OpenStack<br>
>         ><br>
>         >   2) It should be possible to implement the RPC abstraction using a<br>
>         >      variety of messaging transports, not just AMQP or AMQP-like<br>
>         ><br>
>         >   3) It should be a stable API with plenty of room for backwards<br>
>         >      compatible evolution in the future so that we can release it as a<br>
>         >      standalone library<br>
>         ><br>
>         > Here's what I have so far:<br>
>         ><br>
>         >   <a href="https://wiki.openstack.org/wiki/Oslo/Messaging" target="_blank">https://wiki.openstack.org/wiki/Oslo/Messaging</a><br>
><br>
><br>
>         Just a quick status update. We're using this etherpad to coordinate:<br>
><br>
>           <a href="https://etherpad.openstack.org/HavanaOsloMessaging" target="_blank">https://etherpad.openstack.org/HavanaOsloMessaging</a><br>
><br>
>         and this branch:<br>
><br>
>           <a href="https://github.com/markmc/oslo-incubator/commits/messaging" target="_blank">https://github.com/markmc/oslo-incubator/commits/messaging</a><br>
><br>
>         At this point, we've got a pretty solid API design, a working fake<br>
>         driver and some simple test code.<br>
><br>
><br>
> Have you given any thought to how the MessageHandlingServer can listen<br>
> on more than one target? That's an important use case for ceilometer,<br>
> which I didn't address in my earlier changes.<br>
><br>
><br>
> Do we need to support different transports (and drivers), or just<br>
> multiple targets?<br>
<br>
</div></div>I guess I was thinking you'd just create multiple servers, but you<br>
probably really want a single executor and dispatcher pair with multiple<br>
listeners.<br>
<br>
Would something like this work?<br>
<br>
    def start(self):<br>
        if self._executor is not None:<br>
            return<br>
        self._executor = self._executor_cls(self.conf, self.dispatcher)<br>
        self.listen(self.transport, self.target)<br>
        self._executor.start()<br>
<br>
    def listen(self, transport, target):<br>
        self._executor.add_listener(transport._listen(target))<br></blockquote><div><br></div><div style>I am worried there might be a case where the executor will have a hard time adding a listener after it has been started. How would the blocking executor do that, for example?</div>
<div style><br></div><div style>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Mark.<br>
<br>
</blockquote></div><br></div></div>