It would appear Google Groups ate my reply; thus, this resend.  Sorry if this is a dup for anyone.<br><div class="gmail_quote">--------------------<br><br>
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div class="im">
    On 5/29/2012 6:21 AM, Tony Garnock-Jones wrote:
    </div><blockquote type="cite"><div class="im">On 28 May 2012 19:12, Reverend Chip <span dir="ltr">&lt;<a href="mailto:rev.chip@gmail.com" target="_blank">rev.chip@gmail.com</a>&gt;</span> wrote:<br>
      </div><div class="gmail_quote"><div class="im">
        <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div>That&#39;s very funny.</div>
           If you&#39;re serious, then I can&#39;t take you seriously.<br>
        </blockquote>
        <div><br>
        </div>
        </div><div>I suspect you&#39;re just being rude....</div></div></blockquote>
    <br>
    I explained a scenario, as produced by the current flow control
    code, that is ridiculous on its face: That growing queues are fine,
    until consumers appear, at which point growing queues are not fine. 
    That&#39;s a paradoxical result that at the very least should prompt
    reevaluation of the flow control algorithm.  To ask what the
    practical bad results are in my specific case is ridiculous
    misdirection.<br>
    <br>
    Either growing queues (up to disk and memory limits) are acceptable
    -- my position, and the position of RMQ without consumers -- or
    growing queues are not acceptable -- the position of RMQ with
    consumers.  This paradox is quite simple to write and to read.  The
    behavior of the current code is absurd, as anyone can see if they
    were to choose to look.<br>
    <br>
    So no, I was not being rude, specifically.  But I did ridicule your
    comment, which well deserved it.  Per Thomas Jefferson: &quot;Ridicule is
    the only weapon which can be used against unintelligible
    propositions. Ideas must be distinct before reason can act upon
    them.&quot;<br>
    <br>
    PS: You may not have thought about the further wrinkle that the
    queues do not accept new messages until they are EMPTY.  Which is
    doubly ridiculous.<div><div class="h5"><br>
    <br>
    <br>
    <blockquote type="cite">
      <div class="gmail_quote">
        <div>, but since it&#39;s also possible that the message you&#39;re
          replying to didn&#39;t get through to you in its entirety (because
          of broken &quot;From&quot; quoting at some stage in the mail delivery
          pipeline), I&#39;ll reproduce the rest of what I wrote here in
          case it helps advance the discussion:</div>
        <div> </div>
      </div>
      <div>&gt;From one point of view, any time consumers exist
        but are not keeping up with offered traffic is a good time to
        throttle the producers. Perhaps call this the &quot;steady state&quot;
        point of view - I&#39;m unsure if it has a better name already.</div>
      <div><br>
      </div>
      <div>&gt;From another point of view - call this the
        &quot;bursty&quot; point of view, perhaps - the growth of queues is
        perfectly acceptable, whether consumers exist at the time or
        not.</div>
      <div>
        <br>
      </div>
      <div>ISTM Rabbit makes a guess about whether the
        application is &quot;steady state&quot; or &quot;bursty&quot;, choosing &quot;steady
        state&quot; all the time. Rabbit team, is this the case? Is there a
        way of configuring the flow control to permit unbounded queue
        growth to support the &quot;bursty&quot; case? Or do I have the wrong end
        of the stick entirely?</div>
      <div>
        <div> </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
          <div>1. A client is publishing 1.5K/sec to each of four
            exchanges, each of which has a queue.</div>
          <div>2. There are no consumers.  Therefore the queue is
            growing.</div>
          <div>3. RMQ does not stop this.  &quot;Flow control&quot; does not
            trigger.</div>
          <div>4. The consumers appear to begin to tear down the
            backlog.</div>
          <div>
            5. RMQ per-connection flow control suddenly decides that now
            there are some consumers, now it has a reason to throttle
            the sender.</div>
          <div>6. If the consumers had not shown up, the producer would
            not have been blocked.</div>
        </blockquote>
        <div><br>
        </div>
      </div>
      <div>7. The consumers drain some of the messages from the
        queues.</div>
      <div>8. The producers are unblocked.</div>
      <div>9. Profit!!!</div>
      <div><br>
      </div>
      <div>Regards,</div>
      <div>  Tony</div>
      -- <br>
      Tony Garnock-Jones<br>
      <a href="mailto:tonygarnockjones@gmail.com" target="_blank">tonygarnockjones@gmail.com</a><br>
      <a href="http://homepages.kcbbs.gen.nz/tonyg/" target="_blank">http://homepages.kcbbs.gen.nz/tonyg/</a><br>
    </blockquote>
    <br>
  </div></div></div>

</div><br>