view release on metacpan or  search on metacpan

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

      <field name = "if-empty" domain = "bit" label = "delete only if empty">
        <doc>
          If set, the server will only delete the queue if it has no messages.
        </doc>
        <rule name = "not-empty" on-failure = "precondition-failed">
          <doc>
            The server MUST NOT delete a queue that has messages on it, if the
            if-empty field is true.
          </doc>
          <doc type = "scenario">
            The client declares a queue, binds it and publishes some messages into it,
            then tries to delete it setting if-empty to true.
          </doc>
        </rule>
      </field>

      <field name = "no-wait" domain = "no-wait" />
    </method>

    <method name = "delete-ok" synchronous = "1" index = "41" label = "confirm deletion of a queue">
      <doc>This method confirms the deletion of a queue.</doc>

      <chassis name = "client" implement = "MUST" />

      <field name = "message-count" domain = "message-count">
        <doc>Reports the number of messages deleted.</doc>
      </field>
    </method>
  </class>

  <!-- ==  BASIC  ============================================================ -->

  <class name = "basic" handler = "channel" index = "60" label = "work with basic content">
    <doc>
      The Basic class provides methods that support an industry-standard messaging model.
    </doc>

    <doc type = "grammar">
      basic               = C:QOS S:QOS-OK
                          / C:CONSUME S:CONSUME-OK
                          / C:CANCEL S:CANCEL-OK
                          / C:PUBLISH content
                          / S:RETURN content
                          / S:DELIVER content
                          / C:GET ( S:GET-OK content / S:GET-EMPTY )
                          / C:ACK
                          / S:ACK
                          / C:REJECT
                          / C:NACK
                          / S:NACK
                          / C:RECOVER-ASYNC
                          / C:RECOVER S:RECOVER-OK
    </doc>

    <chassis name = "server" implement = "MUST" />
    <chassis name = "client" implement = "MAY" />

    <rule name = "01">
      <doc>
        The server SHOULD respect the persistent property of basic messages and
        SHOULD make a best-effort to hold persistent basic messages on a reliable
        storage mechanism.
      </doc>
      <doc type = "scenario">
        Send a persistent message to queue, stop server, restart server and then
        verify whether message is still present.  Assumes that queues are durable.
        Persistence without durable queues makes no sense.
      </doc>
    </rule>

    <rule name = "02">
      <doc>
        The server MUST NOT discard a persistent basic message in case of a queue
        overflow.
      </doc>
      <doc type = "scenario">
        Declare a queue overflow situation with persistent messages and verify that
        messages do not get lost (presumably the server will write them to disk).
      </doc>
    </rule>

    <rule name = "03">
      <doc>
        The server MAY use the Channel.Flow method to slow or stop a basic message
        publisher when necessary.
      </doc>
      <doc type = "scenario">
        Declare a queue overflow situation with non-persistent messages and verify
        whether the server responds with Channel.Flow or not. Repeat with persistent
        messages.
      </doc>
    </rule>

    <rule name = "04">
      <doc>
        The server MAY overflow non-persistent basic messages to persistent
        storage.
      </doc>
      <!-- Test scenario: untestable -->
    </rule>

    <rule name = "05">
      <doc>
        The server MAY discard or dead-letter non-persistent basic messages on a
        priority basis if the queue size exceeds some configured limit.
      </doc>
      <!-- Test scenario: untestable -->
    </rule>

    <rule name = "06">
      <doc>
        The server MUST implement at least 2 priority levels for basic messages,
        where priorities 0-4 and 5-9 are treated as two distinct levels.
      </doc>
      <doc type = "scenario">
        Send a number of priority 0 messages to a queue. Send one priority 9
        message.  Consume messages from the queue and verify that the first message
        received was priority 9.
      </doc>
    </rule>