view release on metacpan or  search on metacpan

share/fixed_amqp0-8.xml  view on Meta::CPAN

      unbind a queue from an exchange
      <doc>This method unbinds a queue from an exchange.</doc>
      <rule implement="MUST">
        If a unbind fails, the server MUST raise a connection exception.
      </rule>
      <chassis name="server" implement="MUST"/>
      <response name="unbind-ok"/>

      <field name="ticket" domain="access ticket">
        <doc>
          The client provides a valid access ticket giving "active"
          access rights to the queue's access realm.
        </doc>
      </field>

      <field name="queue" domain="queue name">
        <doc>Specifies the name of the queue to unbind.</doc>
      </field>

      <field name="exchange" domain="exchange name">
        <doc>The name of the exchange to unbind from.</doc>
      </field>

      <field name="routing key" type="shortstr">
        routing key of binding
        <doc>Specifies the routing key of the binding to unbind.</doc>
      </field>

      <field name="arguments" type="table">
        arguments of binding
        <doc>Specifies the arguments of the binding to unbind.</doc>
      </field>
    </method>

    <method name="unbind-ok" synchronous="1" index="51">
      confirm unbind successful
      <doc>This method confirms that the unbind was successful.</doc>
      <chassis name="client" implement="MUST"/>
    </method>

    <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
    <method name="purge" synchronous="1" index="30">
  purge a queue
  <doc>
    This method removes all messages from a queue.  It does not cancel
    consumers.  Purged messages are deleted without any formal "undo"
    mechanism.
  </doc>
      <rule implement="MUST">
        <test>amq_queue_15</test>
    A call to purge MUST result in an empty queue.
  </rule>
      <rule implement="MUST">
        <test>amq_queue_41</test>
    On transacted channels the server MUST not purge messages that have
    already been sent to a client but not yet acknowledged.
  </rule>
      <rule implement="MAY">
        <test>amq_queue_42</test>
    The server MAY implement a purge queue or log that allows system
    administrators to recover accidentally-purged messages.  The server
    SHOULD NOT keep purged messages in the same storage spaces as the
    live messages since the volumes of purged messages may get very
    large.
  </rule>
      <chassis name="server" implement="MUST"/>
      <response name="purge-ok"/>
      <field name="ticket" domain="access ticket">
        <doc>
      The access ticket must be for the access realm that holds the
      queue.
    </doc>
        <rule implement="MUST">
      The client MUST provide a valid access ticket giving "read" access
      rights to the queue's access realm.  Note that purging a queue is
      equivalent to reading all messages and discarding them.
    </rule>
      </field>
  <field name = "queue" domain = "queue name">
    <doc>
      Specifies the name of the queue to purge.  If the queue name is
      empty, refers to the current queue for the channel, which is
      the last declared queue.
    </doc>
    <doc name = "rule">
      If the client did not previously declare a queue, and the queue
      name in this method is empty, the server MUST raise a connection
      exception with reply code 530 (not allowed).
    </doc>
    <doc name = "rule" test = "amq_queue_16">
      The queue must exist. Attempting to purge a non-existing queue
      causes a channel exception.
    </doc>
  </field>

  <field name = "nowait" type = "bit">
    do not send a reply method
    <doc>
    If set, the server will not respond to the method. The client should
    not wait for a reply method.  If the server could not complete the
    method it will raise a channel or connection exception.
    </doc>
  </field>
    </method>
    <method name="purge-ok" synchronous="1" index="31">
  confirms a queue purge
  <doc>
    This method confirms the purge of a queue.
  </doc>
      <chassis name="client" implement="MUST"/>
      <field name="message count" type="long">
    number of messages purged
    <doc>
      Reports the number of messages purged.
    </doc>
      </field>
    </method>
    <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
    <method name="delete" synchronous="1" index="40">
  delete a queue
  <doc>

share/fixed_amqp0-8.xml  view on Meta::CPAN

  <doc>
    This method requests permission to start staging a message.  Staging
    means sending the message into a temporary area at the recipient end
    and then delivering the message by referring to this temporary area.
    Staging is how the protocol handles partial file transfers - if a
    message is partially staged and the connection breaks, the next time
    the sender starts to stage it, it can restart from where it left off.
  </doc>
  <response name = "open-ok" />
  <chassis name = "server" implement = "MUST" />
  <chassis name = "client" implement = "MUST" />
  
  <field name = "identifier" type = "shortstr">
    staging identifier
    <doc>
      This is the staging identifier. This is an arbitrary string chosen
      by the sender.  For staging to work correctly the sender must use
      the same staging identifier when staging the same message a second
      time after recovery from a failure.  A good choice for the staging
      identifier would be the SHA1 hash of the message properties data
      (including the original filename, revised time, etc.).
    </doc>
  </field>

  <field name = "content size" type = "longlong">
    message content size
    <doc>
      The size of the content in octets.  The recipient may use this
      information to allocate or check available space in advance, to
      avoid "disk full" errors during staging of very large messages.
    </doc>
    <doc name = "rule">
      The sender MUST accurately fill the content-size field.
      Zero-length content is permitted.
    </doc>
  </field>
</method>

<method name = "open-ok" synchronous = "1" index = "41">
  confirm staging ready
  <doc>
    This method confirms that the recipient is ready to accept staged
    data.  If the message was already partially-staged at a previous
    time the recipient will report the number of octets already staged.
  </doc>
  <response name = "stage" />
  <chassis name = "server" implement = "MUST" />
  <chassis name = "client" implement = "MUST" />
  
  <field name = "staged size" type = "longlong">
    already staged amount
    <doc>
      The amount of previously-staged content in octets.  For a new
      message this will be zero.
    </doc>
    <doc name = "rule">
      The sender MUST start sending data from this octet offset in the
      message, counting from zero.
    </doc>
    <doc name = "rule">
      The recipient MAY decide how long to hold partially-staged content
      and MAY implement staging by always discarding partially-staged
      content.  However if it uses the file content type it MUST support
      the staging methods.
    </doc>
  </field>
</method>

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

<method name = "stage" content = "1" index = "50">
  stage message content
  <doc>
    This method stages the message, sending the message content to the
    recipient from the octet offset specified in the Open-Ok method.
  </doc>
  <chassis name = "server" implement = "MUST" />
  <chassis name = "client" implement = "MUST" />
</method>


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

<method name = "publish" index = "60">
  publish a message
  <doc>
    This method publishes a staged file message to a specific exchange.
    The file message will be routed to queues as defined by the exchange
    configuration and distributed to any active consumers when the
    transaction, if any, is committed.
  </doc>
  <chassis name = "server" implement = "MUST" />

  <field name = "ticket" domain = "access ticket">
    <doc name = "rule">
      The client MUST provide a valid access ticket giving "write"
      access rights to the access realm for the exchange.
    </doc>
  </field>

  <field name = "exchange" domain = "exchange name">
    <doc>
      Specifies the name of the exchange to publish to.  The exchange
      name can be empty, meaning the default exchange.  If the exchange
      name is specified, and that exchange does not exist, the server
      will raise a channel exception.
    </doc>
    <doc name = "rule">
      The server MUST accept a blank exchange name to mean the default
      exchange.
    </doc>
    <doc name = "rule">
      If the exchange was declared as an internal exchange, the server
      MUST respond with a reply code 403 (access refused) and raise a
      channel exception.
    </doc>
    <doc name = "rule">
      The exchange MAY refuse file content in which case it MUST respond
      with a reply code 540 (not implemented) and raise a channel
      exception.
    </doc>