view release on metacpan or  search on metacpan

share/fixed_amqp0-9-1.xml  view on Meta::CPAN

    <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

    <method name = "qos" synchronous = "1" index = "10" label = "specify quality of service">
      <doc>
        This method requests a specific quality of service. The QoS can be specified for the
        current channel or for all channels on the connection. The particular properties and
        semantics of a qos method always depend on the content class semantics. Though the
        qos method could in principle apply to both peers, it is currently meaningful only
        for the server.
      </doc>

      <chassis name = "server" implement = "MUST" />
      <response name = "qos-ok" />

      <field name = "prefetch-size" domain = "long" label = "prefetch window in octets">
        <doc>
          The client can request that messages be sent in advance so that when the client
          finishes processing a message, the following message is already held locally,
          rather than needing to be sent down the channel. Prefetching gives a performance
          improvement. This field specifies the prefetch window size in octets. The server
          will send a message in advance if it is equal to or smaller in size than the
          available prefetch size (and also falls into other prefetch limits). May be set
          to zero, meaning "no specific limit", although other prefetch limits may still
          apply. The prefetch-size is ignored if the no-ack option is set.
        </doc>
        <rule name = "01">
          <doc>
            The server MUST ignore this setting when the client is not processing any
            messages - i.e. the prefetch size does not limit the transfer of single
            messages to a client, only the sending in advance of more messages while
            the client still has one or more unacknowledged messages.
          </doc>
          <doc type = "scenario">
            Define a QoS prefetch-size limit and send a single message that exceeds
            that limit.  Verify that the message arrives correctly.
          </doc>
        </rule>
      </field>

      <field name = "prefetch-count" domain = "short" label = "prefetch window in messages">
        <doc>
          Specifies a prefetch window in terms of whole messages. This field may be used
          in combination with the prefetch-size field; a message will only be sent in
          advance if both prefetch windows (and those at the channel and connection level)
          allow it. The prefetch-count is ignored if the no-ack option is set.
        </doc>
        <rule name = "01">
          <doc>
            The server may send less data in advance than allowed by the client's
            specified prefetch windows but it MUST NOT send more.
          </doc>
          <doc type = "scenario">
            Define a QoS prefetch-size limit and a prefetch-count limit greater than
            one.  Send multiple messages that exceed the prefetch size.  Verify that
            no more than one message arrives at once.
          </doc>
        </rule>
      </field>

      <field name = "global" domain = "bit" label = "apply to entire connection">
        <doc>
          By default the QoS settings apply to the current channel only. If this field is
          set, they are applied to the entire connection.
        </doc>
      </field>
    </method>

    <method name = "qos-ok" synchronous = "1" index = "11" label = "confirm the requested qos">
      <doc>
        This method tells the client that the requested QoS levels could be handled by the
        server. The requested QoS applies to all active consumers until a new QoS is
        defined.
      </doc>
      <chassis name = "client" implement = "MUST" />
    </method>

    <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

    <method name = "consume" synchronous = "1" index = "20" label = "start a queue consumer">
      <doc>
        This method asks the server to start a "consumer", which is a transient request for
        messages from a specific queue. Consumers last as long as the channel they were
        declared on, or until the client cancels them.
      </doc>

      <rule name = "01">
        <doc>
          The server SHOULD support at least 16 consumers per queue, and ideally, impose
          no limit except as defined by available resources.
        </doc>
        <doc type = "scenario">
          Declare a queue and create consumers on that queue until the server closes the
          connection. Verify that the number of consumers created was at least sixteen
          and report the total number.
        </doc>
      </rule>

      <chassis name = "server" implement = "MUST" />
      <response name = "consume-ok" />

      <!-- Deprecated: "ticket", must be zero -->
      <field name = "reserved-1" type = "short" reserved = "1" />

      <field name = "queue" domain = "queue-name">
        <doc>Specifies the name of the queue to consume from.</doc>
      </field>

      <field name = "consumer-tag" domain = "consumer-tag">
        <doc>
          Specifies the identifier for the consumer. The consumer tag is local to a
          channel, so two clients can use the same consumer tags. If this field is
          empty the server will generate a unique tag.
        </doc>
        <rule name = "01" on-failure = "not-allowed">
          <doc>
            The client MUST NOT specify a tag that refers to an existing consumer.
          </doc>
          <doc type = "scenario">
            Attempt to create two consumers with the same non-empty tag, on the
            same channel.