AnyEvent-RabbitMQ

 view release on metacpan or  search on metacpan

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

    port = "5672" comment = "AMQ Protocol version 0-9-1">
  <!--
      ======================================================
      ==       CONSTANTS
      ======================================================
  -->
  <!-- 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

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

            standardised exchanges. The client MAY declare an exchange starting with
            "amq." if the passive option is set, or the exchange already exists.
          </doc>
          <doc type = "scenario">
            The client attempts to declare a non-existing exchange starting with
            "amq." and with the passive option set to zero.
          </doc>
        </rule>
        <rule name = "syntax" on-failure = "precondition-failed">
          <doc>
            The exchange name consists of a non-empty sequence of these characters:
            letters, digits, hyphen, underscore, period, or colon.
          </doc>
          <doc type = "scenario">
            The client attempts to declare an exchange with an illegal name.
          </doc>
        </rule>
        <assert check = "notnull" />
      </field>

      <field name = "type" domain = "shortstr" label = "exchange type">
        <doc>
          Each exchange belongs to one of a set of exchange types implemented by the
          server. The exchange types define the functionality of the exchange - i.e. how
          messages are routed through it. It is not valid or meaningful to attempt to
          change the type of an existing exchange.
        </doc>
        <rule name = "typed" on-failure = "not-allowed">
          <doc>
            Exchanges cannot be redeclared with different types.  The client MUST not
            attempt to redeclare an existing exchange with a different type than used
            in the original Exchange.Declare method.
          </doc>
          <doc type = "scenario">
            TODO.
          </doc>
        </rule>
        <rule name = "support" on-failure = "command-invalid">
          <doc>
            The client MUST NOT attempt to declare an exchange with a type that the
            server does not support.
          </doc>
          <doc type = "scenario">
            TODO.
          </doc>
        </rule>
      </field>

      <field name = "passive" domain = "bit" label = "do not create exchange">
        <doc>
          If set, the server will reply with Declare-Ok if the exchange already
          exists with the same name, and raise an error if not.  The client can
          use this to check whether an exchange exists without modifying the
          server state. When set, all other method fields except name and no-wait
          are ignored.  A declare with both passive and no-wait has no effect.
          Arguments are compared for semantic equivalence.
        </doc>
        <rule name = "not-found">
          <doc>
            If set, and the exchange does not already exist, the server MUST
            raise a channel exception with reply code 404 (not found).
          </doc>
          <doc type = "scenario">
            TODO.
          </doc>
        </rule>
        <rule name = "equivalent">
          <doc>
            If not set and the exchange exists, the server MUST check that the
            existing exchange has the same values for type, durable, and arguments
            fields.  The server MUST respond with Declare-Ok if the requested
            exchange 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 exchange">
        <doc>
          If set when creating a new exchange, the exchange will be marked as durable.
          Durable exchanges remain active when a server restarts. Non-durable exchanges
          (transient exchanges) are purged if/when a server restarts.
        </doc>
        <rule name = "support">
          <doc>
            The server MUST support both durable and transient exchanges.
          </doc>
          <doc type = "scenario">
            TODO.
          </doc>
        </rule>
      </field>

      <field name = "auto-delete" domain = "bit" label = "auto-delete when unused">
        <doc>
          If set, the exchange is deleted when all queues have
          finished using it.
        </doc>
        <rule name = "amq_exchange_02">
          <doc>
            The server SHOULD allow for a reasonable delay between the
            point when it determines that an exchange is not being
            used (or no longer used), and the point when it deletes
            the exchange.  At the least it must allow a client to
            create an exchange and then bind a queue to it, with a
            small but non-zero delay between these two actions.
          </doc>
        </rule>
        <rule name = "amq_exchange_25">
          <doc>
            The server MUST ignore the auto-delete field if the
            exchange already exists.
          </doc>
        </rule>
      </field>

      <field name = "internal" domain = "bit" label = "create internal exchange">
        <doc>



( run in 1.064 second using v1.01-cache-2.11-cpan-39bf76dae61 )