view release on metacpan or  search on metacpan

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

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

      <field name = "delivery-tag" domain = "delivery-tag" />
      <field name = "redelivered" domain = "redelivered" />
      <field name = "exchange" domain = "exchange-name">
        <doc>
          Specifies the name of the exchange that the message was originally published to.
          If empty, the message was published to the default exchange.
        </doc>
      </field>

      <field name = "routing-key" domain = "shortstr" label = "Message routing key">
        <doc>Specifies the routing key name specified when the message was published.</doc>
      </field>

      <field name = "message-count" domain = "message-count" />
    </method>

    <method name = "get-empty" synchronous = "1" index = "72"
      label = "indicate no messages available">
      <doc>
        This method tells the client that the queue has no messages available for the
        client.
      </doc>
      <chassis name = "client" implement = "MAY" />
      <!-- Deprecated: "cluster-id", must be empty -->
      <field name = "reserved-1" type = "shortstr" reserved = "1" />
    </method>

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

    <method name = "ack" index = "80" label = "acknowledge one or more messages">
      <doc>
        When sent by the client, this method acknowledges one or more
        messages delivered via the Deliver or Get-Ok methods.

        When sent by server, this method acknowledges one or more
        messages published with the Publish method on a channel in
        confirm mode.

        The acknowledgement can be for a single message or a set of
        messages up to and including a specific message.
      </doc>

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

      <field name = "delivery-tag" domain = "delivery-tag" />
      <field name = "multiple" domain = "bit" label = "acknowledge multiple messages">
        <doc>
          If set to 1, the delivery tag is treated as "up to and
          including", so that multiple messages can be acknowledged
          with a single method. If set to zero, the delivery tag
          refers to a single message. If the multiple field is 1, and
          the delivery tag is zero, this indicates acknowledgement of
          all outstanding messages.
        </doc>
        <rule name = "exists" on-failure = "precondition-failed">
          <doc>
            A message MUST not be acknowledged more than once.  The
            receiving peer MUST validate that a non-zero delivery-tag
            refers to a delivered message, and raise a channel
            exception if this is not the case. On a transacted
            channel, this check MUST be done immediately and not
            delayed until a Tx.Commit.
          </doc>
          <doc type = "scenario">
            TODO.
          </doc>
        </rule>
      </field>
    </method>

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

    <method name = "reject" index = "90" label = "reject an incoming message">
      <doc>
        This method allows a client to reject a message. It can be used to interrupt and
        cancel large incoming messages, or return untreatable messages to their original
        queue.
      </doc>

      <rule name = "01">
        <doc>
          The server SHOULD be capable of accepting and process the Reject method while
          sending message content with a Deliver or Get-Ok method. I.e. the server should
          read and process incoming methods while sending output frames. To cancel a
          partially-send content, the server sends a content body frame of size 1 (i.e.
          with no data except the frame-end octet).
        </doc>
      </rule>

      <rule name = "02">
        <doc>
          The server SHOULD interpret this method as meaning that the client is unable to
          process the message at this time.
        </doc>
        <doc type = "scenario">
          TODO.
        </doc>
      </rule>

      <rule name = "03">
        <doc>
          The client MUST NOT use this method as a means of selecting messages to process.
        </doc>
        <doc type = "scenario">
          TODO.
        </doc>
      </rule>

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

      <field name = "delivery-tag" domain = "delivery-tag" />

      <field name = "requeue" domain = "bit" label = "requeue the message">
        <doc>
          If requeue is true, the server will attempt to requeue the message.  If requeue
          is false or the requeue  attempt fails the messages are discarded or dead-lettered.
        </doc>

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

        confirm mode of unhandled messages.  If a publisher receives this method, it
        probably needs to republish the offending messages.
      </doc>

      <rule name = "01">
        <doc>
          The server SHOULD be capable of accepting and processing the Nack method while
          sending message content with a Deliver or Get-Ok method. I.e. the server should
          read and process incoming methods while sending output frames. To cancel a
          partially-send content, the server sends a content body frame of size 1 (i.e.
          with no data except the frame-end octet).
        </doc>
      </rule>

      <rule name = "02">
        <doc>
          The server SHOULD interpret this method as meaning that the client is unable to
          process the message at this time.
        </doc>
        <doc type = "scenario">
          TODO.
        </doc>
      </rule>

      <rule name = "03">
        <doc>
          The client MUST NOT use this method as a means of selecting messages to process.
        </doc>
        <doc type = "scenario">
          TODO.
        </doc>
      </rule>

      <rule name = "04">
        <doc>
          A client publishing messages to a channel in confirm mode SHOULD be capable of accepting
          and somehow handling the Nack method.
        </doc>
        <doc type = "scenario">
          TODO
        </doc>
      </rule>

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

      <field name = "delivery-tag" domain = "delivery-tag" />

      <field name = "multiple" domain = "bit" label = "reject multiple messages">
        <doc>
          If set to 1, the delivery tag is treated as "up to and
          including", so that multiple messages can be rejected
          with a single method. If set to zero, the delivery tag
          refers to a single message. If the multiple field is 1, and
          the delivery tag is zero, this indicates rejection of
          all outstanding messages.
        </doc>
        <rule name = "exists" on-failure = "precondition-failed">
          <doc>
            A message MUST not be rejected more than once.  The
            receiving peer MUST validate that a non-zero delivery-tag
            refers to an unacknowledged, delivered message, and
            raise a channel exception if this is not the case.
          </doc>
          <doc type = "scenario">
            TODO.
          </doc>
        </rule>
      </field>

      <field name = "requeue" domain = "bit" label = "requeue the message">
        <doc>
          If requeue is true, the server will attempt to requeue the message.  If requeue
          is false or the requeue  attempt fails the messages are discarded or dead-lettered.
          Clients receiving the Nack methods should ignore this flag.
        </doc>

        <rule name = "01">
          <doc>
            The server MUST NOT deliver the message to the same client within the
            context of the current channel. The recommended strategy is to attempt to
            deliver the message to an alternative consumer, and if that is not possible,
            to move the message to a dead-letter queue. The server MAY use more
            sophisticated tracking to hold the message on the queue and redeliver it to
            the same client at a later stage.
          </doc>
          <doc type = "scenario">
            TODO.
          </doc>
        </rule>
      </field>
    </method>

  </class>

  <!-- ==  TX  =============================================================== -->

  <class name = "tx" handler = "channel" index = "90" label = "work with transactions">
    <doc>
      The Tx class allows publish and ack operations to be batched into atomic
      units of work.  The intention is that all publish and ack requests issued
      within a transaction will complete successfully or none of them will.
      Servers SHOULD implement atomic transactions at least where all publish
      or ack requests affect a single queue.  Transactions that cover multiple
      queues may be non-atomic, given that queues can be created and destroyed
      asynchronously, and such events do not form part of any transaction.
      Further, the behaviour of transactions with respect to the immediate and
      mandatory flags on Basic.Publish methods is not defined.
    </doc>

    <rule name = "not multiple queues">
      <doc>
      Applications MUST NOT rely on the atomicity of transactions that
      affect more than one queue.
      </doc>
    </rule>
    <rule name = "not immediate">
      <doc>
      Applications MUST NOT rely on the behaviour of transactions that
      include messages published with the immediate option.
      </doc>