view release on metacpan or  search on metacpan

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

  <!-- Frame types -->
  <constant name = "frame-method"     value = "1" />
  <constant name = "frame-header"     value = "2" />
  <constant name = "frame-body"       value = "3" />
  <constant name = "frame-heartbeat"  value = "8" />

  <!-- Protocol constants -->
  <constant name = "frame-min-size"   value = "4096" />
  <constant name = "frame-end"        value = "206" />

  <!-- Reply codes -->
  <constant name = "reply-success" value = "200">
    <doc>
      Indicates that the method completed successfully. This reply code is
      reserved for future use - the current protocol design does not use positive
      confirmation and reply codes are sent only in case of an error.
    </doc>
  </constant>

  <constant name = "content-too-large" value = "311" class = "soft-error">
    <doc>
      The client attempted to transfer content larger than the server could accept
      at the present time. The client may retry at a later time.
    </doc>
  </constant>

  <constant name = "no-consumers" value = "313" class = "soft-error">
    <doc>
      When the exchange cannot deliver to a consumer when the immediate flag is
      set. As a result of pending data on the queue or the absence of any
      consumers of the queue.
    </doc>
  </constant>

  <constant name = "connection-forced" value = "320" class = "hard-error">
    <doc>
      An operator intervened to close the connection for some reason. The client
      may retry at some later date.
    </doc>
  </constant>

  <constant name = "invalid-path" value = "402" class = "hard-error">
    <doc>
      The client tried to work with an unknown virtual host.
    </doc>
  </constant>

  <constant name = "access-refused" value = "403" class = "soft-error">
    <doc>
      The client attempted to work with a server entity to which it has no
      access due to security settings.
    </doc>
  </constant>

  <constant name = "not-found" value = "404" class = "soft-error">
    <doc>
      The client attempted to work with a server entity that does not exist.
    </doc>
  </constant>

  <constant name = "resource-locked" value = "405" class = "soft-error">
    <doc>
      The client attempted to work with a server entity to which it has no
      access because another client is working with it.
    </doc>
  </constant>

  <constant name = "precondition-failed" value = "406" class = "soft-error">
    <doc>
      The client requested a method that was not allowed because some precondition
      failed.
    </doc>
  </constant>

  <constant name = "frame-error" value = "501" class = "hard-error">
    <doc>
      The sender sent a malformed frame that the recipient could not decode.
      This strongly implies a programming error in the sending peer.
    </doc>
  </constant>

  <constant name = "syntax-error" value = "502" class = "hard-error">
    <doc>
      The sender sent a frame that contained illegal values for one or more
      fields. This strongly implies a programming error in the sending peer.
    </doc>
  </constant>

  <constant name = "command-invalid" value = "503" class = "hard-error">
    <doc>
      The client sent an invalid sequence of frames, attempting to perform an
      operation that was considered invalid by the server. This usually implies
      a programming error in the client.
    </doc>
  </constant>

  <constant name = "channel-error" value = "504" class = "hard-error">
    <doc>
      The client attempted to work with a channel that had not been correctly
      opened. This most likely indicates a fault in the client layer.
    </doc>
  </constant>

  <constant name = "unexpected-frame" value = "505" class = "hard-error">
    <doc>
      The peer sent a frame that was not expected, usually in the context of
      a content header and body.  This strongly indicates a fault in the peer's
      content processing.
    </doc>
  </constant>

  <constant name = "resource-error" value = "506" class = "hard-error">
    <doc>
      The server could not complete the method because it lacked sufficient
      resources. This may be due to the client creating too many of some type
      of entity.
    </doc>
  </constant>

  <constant name = "not-allowed" value = "530" class = "hard-error">
    <doc>

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

          </doc>
        </rule>
        <rule name = "equivalent">
          <doc>
            If not set and the queue exists, the server MUST check that the
            existing queue has the same values for durable, exclusive, auto-delete,
            and arguments fields.  The server MUST respond with Declare-Ok if the
            requested queue matches these fields, and MUST raise a channel exception
            if not.
          </doc>
          <doc type = "scenario">
            TODO.
          </doc>
        </rule>
      </field>

      <field name = "durable" domain = "bit" label = "request a durable queue">
        <doc>
          If set when creating a new queue, the queue will be marked as durable. Durable
          queues remain active when a server restarts. Non-durable queues (transient
          queues) are purged if/when a server restarts. Note that durable queues do not
          necessarily hold persistent messages, although it does not make sense to send
          persistent messages to a transient queue.
        </doc>

        <rule name = "persistence">
          <doc>The server MUST recreate the durable queue after a restart.</doc>

          <doc type = "scenario">
            Client declares a durable queue. The server is then restarted. The client
            then attempts to send a message to the queue. The message should be successfully
            delivered.
          </doc>
        </rule>

        <rule name = "types">
          <doc>The server MUST support both durable and transient queues.</doc>
          <doc type = "scenario">
            A client declares two named queues, one durable and one transient.
          </doc>
        </rule>
      </field>

      <field name = "exclusive" domain = "bit" label = "request an exclusive queue">
        <doc>
          Exclusive queues may only be accessed by the current connection, and are
          deleted when that connection closes.  Passive declaration of an exclusive
          queue by other connections are not allowed.
        </doc>

        <rule name = "types">
          <doc>
            The server MUST support both exclusive (private) and non-exclusive (shared)
            queues.
          </doc>
          <doc type = "scenario">
            A client declares two named queues, one exclusive and one non-exclusive.
          </doc>
        </rule>

        <rule name = "exclusive" on-failure = "resource-locked">
          <doc>
            The client MAY NOT attempt to use a queue that was declared as exclusive
            by another still-open connection.
          </doc>
          <doc type = "scenario">
            One client declares an exclusive queue. A second client on a different
            connection attempts to declare, bind, consume, purge, delete, or declare
            a queue of the same name.
          </doc>
        </rule>
      </field>

      <field name = "auto-delete" domain = "bit" label = "auto-delete queue when unused">
        <doc>
          If set, the queue is deleted when all consumers have finished using it.  The last
          consumer can be cancelled either explicitly or because its channel is closed. If
          there was no consumer ever on the queue, it won't be deleted.  Applications can
          explicitly delete auto-delete queues using the Delete method as normal.
        </doc>

        <rule name = "pre-existence">
          <doc>
            The server MUST ignore the auto-delete field if the queue already exists.
          </doc>
          <doc type = "scenario">
            Client declares two named queues, one as auto-delete and one explicit-delete.
            Client then attempts to declare the two queues using the same names again,
            but reversing the value of the auto-delete field in each case. Verify that the
            queues still exist with the original auto-delete flag values.
          </doc>
        </rule>
      </field>

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

      <field name = "arguments" domain = "table" label = "arguments for declaration">
        <doc>
          A set of arguments for the declaration. The syntax and semantics of these
          arguments depends on the server implementation.
        </doc>
      </field>
    </method>

    <method name = "declare-ok" synchronous = "1" index = "11" label = "confirms a queue definition">
      <doc>
        This method confirms a Declare method and confirms the name of the queue, essential
        for automatically-named queues.
      </doc>

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

      <field name = "queue" domain = "queue-name">
        <doc>
          Reports the name of the queue. If the server generated a queue name, this field
          contains that name.
        </doc>
        <assert check = "notnull" />
      </field>

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