<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hi,<br>
      <br>
      Why should we create queue in advance?<br>
      <br>
      Let's consider following use cases:<br>
      1) <br>
      * listener starts and creates a queue<br>
      * publishers connect to exchange and start publishing<br>
      <br>
      No need to create a queue in advance here since listener does it
      when it starts<br>
      <br>
      2)<br>
      * publishers create a queue in advance and start publishing<br>
      ....<br>
      <br>
      Creation is not correct since there is no guarantee that someone
      would ever use this queue...<br>
      <br>
      IMHO listener should create a queue and publishers should not care
      about it at all.<br>
      <br>
      What do you think?<br>
      <br>
      On 06/27/2014 05:16 PM, Sandy Walsh wrote:<br>
    </div>
    <blockquote
cite="mid:60A3427EF882A54BA0A1971AE6EF0388A527DFBF@ORD1EXD02.RACKSPACE.CORP"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <div class="moz-cite-prefix">Something to consider is the "create
        the queue in advance" feature is done for notifications, so we
        don't drop important messages on the floor by having an Exchange
        with no associated Queue.<br>
        <br>
        For RPC operations, this may not be required (we assume the
        service is available). If this check is truly a time-sink we
        could ignore that check for rpc calls.
        <br>
        <br>
        -S<br>
        <br>
        <br>
        On 6/10/2014 9:31 AM, Alexei Kornienko wrote:<br>
      </div>
      <blockquote cite="mid:5396F991.9040903@gmail.com" type="cite">
        <div class="moz-cite-prefix">Hi,<br>
          <br>
          Please find some answers inline.<br>
          <br>
          Regards,<br>
          Alexei<br>
          <br>
          On 06/10/2014 03:06 PM, Flavio Percoco wrote:<br>
        </div>
        <blockquote cite="mid:20140610120649.GG20684@redhat.com"
          type="cite">On 10/06/14 15:03 +0400, Dina Belova wrote:
          <br>
          <blockquote type="cite">Hello, stackers! <br>
            <br>
            <br>
            Oslo.messaging is future of how different OpenStack
            components communicate with <br>
            each other, and really I’d love to start discussion about
            how we can make this <br>
            library even better then it’s now and how can we refactor it
            make more <br>
            production-ready. <br>
            <br>
            <br>
            As we all remember, oslo.messaging was initially inspired to
            be created as a <br>
            logical continuation of nova.rpc - as a separated library,
            with lots of <br>
            transports supported, etc. That’s why oslo.messaging
            inherited not only <br>
            advantages of now did the nova.rpc work (and it were lots of
            them), but also <br>
            some architectural decisions that currently sometimes lead
            to the performance <br>
            issues (we met some of them while Ceilometer performance
            testing [1] during the <br>
            Icehouse). <br>
            <br>
            <br>
            For instance, simple testing messaging server (with
            connection pool and <br>
            eventlet) can process 700 messages per second. The same
            functionality <br>
            implemented using plain kombu (without connection pool and
            eventlet)  driver is <br>
            processing ten times more - 7000-8000 messages per second. <br>
            <br>
            <br>
            So we have the following suggestions about how we may make
            this process better <br>
            and quicker (and really I’d love to collect your feedback,
            folks): <br>
            <br>
            <br>
            1) Currently we have main loop running in the Executor
            class, and I guess it’ll <br>
            be much better to move it to the Server class, as it’ll make
            relationship <br>
            between the classes easier and will leave Executor only one
            task - process the <br>
            message and that’s it (in blocking or eventlet mode).
            Moreover, this will make <br>
            further refactoring much easier. <br>
          </blockquote>
          <br>
          To some extent, the executors are part of the server class
          since the <br>
          later is the one actually controlling them. If I understood
          your <br>
          proposal, the server class would implement the event loop,
          which means <br>
          we would have an EventletServer / BlockingServer, right? <br>
          <br>
          If what I said is what you meant, then I disagree. Executors
          keep the <br>
          eventloop isolated from other parts of the library and this is
          really <br>
          important for us. One of the reason is to easily support
          multiple <br>
          python versions - by having different event loops. <br>
          <br>
          Is my assumption correct? Could you elaborate more? <br>
        </blockquote>
        No It's not how we plan it. Server will do the loop and pass
        received message to dispatcher and executor. It means that we
        would still have blocking executor and eventlet executor in the
        same server class. We would just change the implementation part
        to make it more consistent and easier to control.<br>
        <br>
        <blockquote cite="mid:20140610120649.GG20684@redhat.com"
          type="cite"><br>
          <blockquote type="cite"><br>
            2) Some of the drivers implementations (such as impl_rabbit
            and impl_qpid, for <br>
            instance) are full of useless separated classes that in
            reality might be <br>
            included to other ones. There are already some changes
            making the whole <br>
            structure easier [2], and after the 1st issue will be solved
            Dispatcher and <br>
            Listener also will be able to be refactored. <br>
          </blockquote>
          <br>
          This was done on purpose. The idea was to focus on backwards <br>
          compatibility rather than cleaning up/improving the drivers.
          That <br>
          said, sounds like those drivers could user some clean up.
          However, I <br>
          think we should first extend the test suite a bit more before
          hacking <br>
          the existing drivers. <br>
          <br>
          <br>
          <blockquote type="cite"><br>
            3) If we’ll separate RPC functionality and messaging
            functionality it’ll make <br>
            code base clean and easily reused. <br>
          </blockquote>
          <br>
          What do you mean with this? <br>
        </blockquote>
        We mean that current drivers are written with RPC code hardcoded
        inside (ReplyWaiter, etc.). Thats not how messaging library is
        supposed to work. We can move RPC to a separate layer and this
        would be beneficial for both rpc (code will become more clean
        and less error-prone) and core messaging part (we'll be able to
        implement messaging in way that will work much faster).<br>
        <blockquote cite="mid:20140610120649.GG20684@redhat.com"
          type="cite"><br>
          <blockquote type="cite"><br>
            4) Connection pool can be refactored to implement more
            efficient connection <br>
            reusage. <br>
          </blockquote>
          <br>
          Please, elaborate. What changes do you envision? <br>
        </blockquote>
        Currently there is a class that is called ConnectionContext that
        is used to manage pool. Additionaly it can be
        accessed/configured in several other places. If we refactor it a
        little bit it would be much easier to use connections from the
        pool.<br>
        <blockquote cite="mid:20140610120649.GG20684@redhat.com"
          type="cite"><br>
          As Dims suggested, I think filing some specs for this (and
          keeping the <br>
          proposals separate) would help a lot in understanding what the
          exact <br>
          plan is. <br>
          <br>
          Glad to know you're looking forward to help improving
          oslo.messaging. <br>
          <br>
          Thanks, <br>
          Flavio <br>
          <br>
          <blockquote type="cite">Folks, are you ok with such a plan?
            Alexey Kornienko already started some of
            <br>
            this work [2], but really we want to be sure that we chose
            the correct vector <br>
            of development here. <br>
            <br>
            <br>
            Thanks! <br>
            <br>
            <br>
            [1] <a moz-do-not-send="true" class="moz-txt-link-freetext"
              href="https://docs.google.com/document/d/">
              https://docs.google.com/document/d/</a> <br>
            1ARpKiYW2WN94JloG0prNcLjMeom-ySVhe8fvjXG_uRU/edit?usp=sharing
            <br>
            <br>
            [2] <a moz-do-not-send="true" class="moz-txt-link-freetext"
              href="https://review.openstack.org/#/q/">
              https://review.openstack.org/#/q/</a> <br>
            status:open+owner:akornienko+project:openstack/oslo.messaging,n,z
            <br>
            <br>
            <br>
            Best regards, <br>
            <br>
            Dina Belova <br>
            <br>
            Software Engineer <br>
            <br>
            Mirantis Inc. <br>
            <br>
          </blockquote>
          <br>
          <blockquote type="cite">_______________________________________________
            <br>
            OpenStack-dev mailing list <br>
            <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
              href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
            <br>
            <a moz-do-not-send="true" class="moz-txt-link-freetext"
              href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
            <br>
          </blockquote>
          <br>
          <br>
          <br>
          <fieldset class="mimeAttachmentHeader"></fieldset>
          <br>
          <pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
        </blockquote>
        <br>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>