From fd4e234dea02bdef1c4db2bea061360de015c8f5 Mon Sep 17 00:00:00 2001 From: Gordon Sim Date: Fri, 21 Sep 2007 15:13:52 +0000 Subject: Moved c++ over to using the same preview file for 0-10 work as java. Removed all channel class related code from broker as a result. Did the same for some python tests I missed earlier. Renamed ChannelAdapter to ChannelHandler. git-svn-id: https://svn.apache.org/repos/asf/incubator/qpid/trunk@578167 13f79535-47bb-0310-9956-ffa450edef68 --- qpid/cpp/configure.ac | 2 +- qpid/cpp/src/Makefile.am | 4 +- qpid/cpp/src/qpid/broker/Connection.h | 4 +- qpid/cpp/src/qpid/broker/ConnectionAdapter.cpp | 103 - qpid/cpp/src/qpid/broker/ConnectionAdapter.h | 89 - qpid/cpp/src/qpid/broker/ConnectionHandler.cpp | 93 + qpid/cpp/src/qpid/broker/ConnectionHandler.h | 70 + qpid/cpp/src/qpid/broker/SemanticHandler.cpp | 1 - qpid/cpp/src/qpid/broker/SessionHandler.cpp | 57 +- qpid/cpp/src/qpid/broker/SessionHandler.h | 21 - qpid/cpp/src/tests/python_tests | 2 +- qpid/python/tests_0-10/alternate-exchange.py | 8 +- qpid/python/tests_0-10/dtx.py | 10 +- qpid/python/tests_0-10/message.py | 4 +- qpid/specs/amqp-transitional.0-10.xml | 7348 ------------------------ qpid/specs/amqp.0-10-preview.xml | 6 +- 16 files changed, 190 insertions(+), 7632 deletions(-) delete mode 100644 qpid/cpp/src/qpid/broker/ConnectionAdapter.cpp delete mode 100644 qpid/cpp/src/qpid/broker/ConnectionAdapter.h create mode 100644 qpid/cpp/src/qpid/broker/ConnectionHandler.cpp create mode 100644 qpid/cpp/src/qpid/broker/ConnectionHandler.h delete mode 100644 qpid/specs/amqp-transitional.0-10.xml diff --git a/qpid/cpp/configure.ac b/qpid/cpp/configure.ac index 7d990b48ac..1a81b8831e 100644 --- a/qpid/cpp/configure.ac +++ b/qpid/cpp/configure.ac @@ -120,7 +120,7 @@ test -n "$RUBY" && generate=yes test -z "$RUBY" && AC_MSG_ERROR([Missing ruby installation (try "yum install ruby").]) specdir=`pwd`/$srcdir/../specs -AMQP_XML=$specdir/amqp-transitional.0-10.xml +AMQP_XML=$specdir/amqp.0-10-preview.xml AC_SUBST(AMQP_XML) ls $AMQP_XML >/dev/null 2>&1 || generate=no diff --git a/qpid/cpp/src/Makefile.am b/qpid/cpp/src/Makefile.am index 7f25c194d4..cf7029dabc 100644 --- a/qpid/cpp/src/Makefile.am +++ b/qpid/cpp/src/Makefile.am @@ -157,7 +157,7 @@ libqpidbroker_la_SOURCES = \ qpid/broker/BrokerExchange.cpp \ qpid/broker/BrokerQueue.cpp \ qpid/broker/Connection.cpp \ - qpid/broker/ConnectionAdapter.cpp \ + qpid/broker/ConnectionHandler.cpp \ qpid/broker/ConnectionFactory.cpp \ qpid/broker/Daemon.cpp \ qpid/broker/DeliverableMessage.cpp \ @@ -268,7 +268,7 @@ nobase_include_HEADERS = \ qpid/broker/BrokerAdapter.h \ qpid/broker/BrokerSingleton.h \ qpid/broker/Connection.h \ - qpid/broker/ConnectionAdapter.h \ + qpid/broker/ConnectionHandler.h \ qpid/broker/ConnectionFactory.h \ qpid/broker/ConnectionToken.h \ qpid/broker/Daemon.h \ diff --git a/qpid/cpp/src/qpid/broker/Connection.h b/qpid/cpp/src/qpid/broker/Connection.h index 94651701dd..2723ac9acc 100644 --- a/qpid/cpp/src/qpid/broker/Connection.h +++ b/qpid/cpp/src/qpid/broker/Connection.h @@ -36,7 +36,7 @@ #include "Broker.h" #include "qpid/Exception.h" #include "Session.h" -#include "ConnectionAdapter.h" +#include "ConnectionHandler.h" #include "SessionHandler.h" #include @@ -95,7 +95,7 @@ class Connection : public sys::ConnectionInputHandler, uint16_t heartbeat; framing::AMQP_ClientProxy::Connection* client; uint64_t stagingThreshold; - ConnectionAdapter adapter; + ConnectionHandler adapter; }; }} diff --git a/qpid/cpp/src/qpid/broker/ConnectionAdapter.cpp b/qpid/cpp/src/qpid/broker/ConnectionAdapter.cpp deleted file mode 100644 index e33aeda8c7..0000000000 --- a/qpid/cpp/src/qpid/broker/ConnectionAdapter.cpp +++ /dev/null @@ -1,103 +0,0 @@ - -/* - * - * Licensed to the Apache Software Foundation (ASF) under one - * or more contributor license agreements. See the NOTICE file - * distributed with this work for additional information - * regarding copyright ownership. The ASF licenses this file - * to you under the Apache License, Version 2.0 (the - * "License"); you may not use this file except in compliance - * with the License. You may obtain a copy of the License at - * - * http://www.apache.org/licenses/LICENSE-2.0 - * - * Unless required by applicable law or agreed to in writing, - * software distributed under the License is distributed on an - * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY - * KIND, either express or implied. See the License for the - * specific language governing permissions and limitations - * under the License. - * - */ - -#include "ConnectionAdapter.h" -#include "Connection.h" -#include "qpid/framing/ConnectionStartBody.h" - -using namespace qpid; -using namespace qpid::broker; -using namespace qpid::framing; - -void ConnectionAdapter::init(const framing::ProtocolInitiation& header) { - FieldTable properties; - string mechanisms("PLAIN"); - string locales("en_US"); - handler->client.start(header.getMajor(), header.getMinor(), properties, mechanisms, locales); -} - -void ConnectionAdapter::close(ReplyCode code, const string& text, ClassId classId, MethodId methodId) -{ - handler->client.close(code, text, classId, methodId); -} - - -framing::AMQP_ServerOperations::ConnectionHandler* ConnectionAdapter::getConnectionHandler() -{ - return handler.get(); -} - -framing::ProtocolVersion ConnectionAdapter::getVersion() const -{ - return handler->connection.getVersion(); -} - -void ConnectionAdapter::handle(framing::AMQFrame& frame) -{ - AMQMethodBody* method=frame.getBody()->getMethod(); - try{ - method->invoke(*this); - }catch(ConnectionException& e){ - handler->client.close(e.code, e.toString(), method->amqpClassId(), method->amqpMethodId()); - }catch(std::exception& e){ - handler->client.close(541/*internal error*/, e.what(), method->amqpClassId(), method->amqpMethodId()); - } -} - -ConnectionAdapter::ConnectionAdapter(Connection& connection) : handler(new Handler(connection)) {} - -ConnectionAdapter::Handler:: Handler(Connection& c) : client(c.getOutput()), connection(c) {} - -void ConnectionAdapter::Handler::startOk(const FieldTable& /*clientProperties*/, - const string& /*mechanism*/, - const string& /*response*/, const string& /*locale*/) -{ - client.tune(framing::CHANNEL_MAX, connection.getFrameMax(), connection.getHeartbeat()); -} - -void ConnectionAdapter::Handler::secureOk(const string& /*response*/){} - -void ConnectionAdapter::Handler::tuneOk(uint16_t /*channelmax*/, - uint32_t framemax, uint16_t heartbeat) -{ - connection.setFrameMax(framemax); - connection.setHeartbeat(heartbeat); -} - -void ConnectionAdapter::Handler::open(const string& /*virtualHost*/, - const string& /*capabilities*/, bool /*insist*/) -{ - string knownhosts; - client.openOk(knownhosts); -} - - -void ConnectionAdapter::Handler::close(uint16_t /*replyCode*/, const string& /*replyText*/, - uint16_t /*classId*/, uint16_t /*methodId*/) -{ - client.closeOk(); - connection.getOutput().close(); -} - -void ConnectionAdapter::Handler::closeOk(){ - connection.getOutput().close(); -} diff --git a/qpid/cpp/src/qpid/broker/ConnectionAdapter.h b/qpid/cpp/src/qpid/broker/ConnectionAdapter.h deleted file mode 100644 index eb96575c9d..0000000000 --- a/qpid/cpp/src/qpid/broker/ConnectionAdapter.h +++ /dev/null @@ -1,89 +0,0 @@ -/* - * - * Licensed to the Apache Software Foundation (ASF) under one - * or more contributor license agreements. See the NOTICE file - * distributed with this work for additional information - * regarding copyright ownership. The ASF licenses this file - * to you under the Apache License, Version 2.0 (the - * "License"); you may not use this file except in compliance - * with the License. You may obtain a copy of the License at - * - * http://www.apache.org/licenses/LICENSE-2.0 - * - * Unless required by applicable law or agreed to in writing, - * software distributed under the License is distributed on an - * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY - * KIND, either express or implied. See the License for the - * specific language governing permissions and limitations - * under the License. - * - */ -#ifndef _ConnectionAdapter_ -#define _ConnectionAdapter_ - -#include -#include "qpid/framing/amqp_types.h" -#include "qpid/framing/AMQFrame.h" -#include "qpid/framing/AMQP_ServerOperations.h" -#include "qpid/framing/AMQP_ClientProxy.h" -#include "qpid/framing/FrameHandler.h" -#include "qpid/framing/ProtocolInitiation.h" -#include "qpid/framing/ProtocolVersion.h" -#include "qpid/Exception.h" - -namespace qpid { -namespace broker { - -class Connection; - -// TODO aconway 2007-09-18: Rename to ConnectionHandler -class ConnectionAdapter : public framing::FrameHandler, public framing::AMQP_ServerOperations -{ - struct Handler : public framing::AMQP_ServerOperations::ConnectionHandler - { - framing::AMQP_ClientProxy::Connection client; - Connection& connection; - - Handler(Connection& connection); - void startOk(const qpid::framing::FieldTable& clientProperties, - const std::string& mechanism, const std::string& response, - const std::string& locale); - void secureOk(const std::string& response); - void tuneOk(uint16_t channelMax, uint32_t frameMax, uint16_t heartbeat); - void open(const std::string& virtualHost, - const std::string& capabilities, bool insist); - void close(uint16_t replyCode, const std::string& replyText, - uint16_t classId, uint16_t methodId); - void closeOk(); - }; - std::auto_ptr handler; - public: - ConnectionAdapter(Connection& connection); - void init(const framing::ProtocolInitiation& header); - void close(framing::ReplyCode code, const std::string& text, framing::ClassId classId, framing::MethodId methodId); - void handle(framing::AMQFrame& frame); - - //AMQP_ServerOperations: - ConnectionHandler* getConnectionHandler(); - ChannelHandler* getChannelHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); } - BasicHandler* getBasicHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); } - ExchangeHandler* getExchangeHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); } - BindingHandler* getBindingHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); } - QueueHandler* getQueueHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); } - TxHandler* getTxHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); } - MessageHandler* getMessageHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); } - AccessHandler* getAccessHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); } - FileHandler* getFileHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); } - StreamHandler* getStreamHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); } - TunnelHandler* getTunnelHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); } - DtxCoordinationHandler* getDtxCoordinationHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); } - DtxDemarcationHandler* getDtxDemarcationHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); } - ExecutionHandler* getExecutionHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); } - SessionHandler* getSessionHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); } - framing::ProtocolVersion getVersion() const; -}; - - -}} - -#endif diff --git a/qpid/cpp/src/qpid/broker/ConnectionHandler.cpp b/qpid/cpp/src/qpid/broker/ConnectionHandler.cpp new file mode 100644 index 0000000000..a769d05470 --- /dev/null +++ b/qpid/cpp/src/qpid/broker/ConnectionHandler.cpp @@ -0,0 +1,93 @@ + +/* + * + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + * + */ + +#include "ConnectionHandler.h" +#include "Connection.h" +#include "qpid/framing/ConnectionStartBody.h" + +using namespace qpid; +using namespace qpid::broker; +using namespace qpid::framing; + +void ConnectionHandler::init(const framing::ProtocolInitiation& header) { + FieldTable properties; + string mechanisms("PLAIN"); + string locales("en_US"); + handler->client.start(header.getMajor(), header.getMinor(), properties, mechanisms, locales); +} + +void ConnectionHandler::close(ReplyCode code, const string& text, ClassId classId, MethodId methodId) +{ + handler->client.close(code, text, classId, methodId); +} + +void ConnectionHandler::handle(framing::AMQFrame& frame) +{ + AMQMethodBody* method=frame.getBody()->getMethod(); + try{ + if (!method->invoke(handler.get())) + throw ConnectionException(503, "Class can't be accessed over channel 0"); + }catch(ConnectionException& e){ + handler->client.close(e.code, e.toString(), method->amqpClassId(), method->amqpMethodId()); + }catch(std::exception& e){ + handler->client.close(541/*internal error*/, e.what(), method->amqpClassId(), method->amqpMethodId()); + } +} + +ConnectionHandler::ConnectionHandler(Connection& connection) : handler(new Handler(connection)) {} + +ConnectionHandler::Handler:: Handler(Connection& c) : client(c.getOutput()), connection(c) {} + +void ConnectionHandler::Handler::startOk(const FieldTable& /*clientProperties*/, + const string& /*mechanism*/, + const string& /*response*/, const string& /*locale*/) +{ + client.tune(framing::CHANNEL_MAX, connection.getFrameMax(), connection.getHeartbeat()); +} + +void ConnectionHandler::Handler::secureOk(const string& /*response*/){} + +void ConnectionHandler::Handler::tuneOk(uint16_t /*channelmax*/, + uint32_t framemax, uint16_t heartbeat) +{ + connection.setFrameMax(framemax); + connection.setHeartbeat(heartbeat); +} + +void ConnectionHandler::Handler::open(const string& /*virtualHost*/, + const string& /*capabilities*/, bool /*insist*/) +{ + string knownhosts; + client.openOk(knownhosts); +} + + +void ConnectionHandler::Handler::close(uint16_t /*replyCode*/, const string& /*replyText*/, + uint16_t /*classId*/, uint16_t /*methodId*/) +{ + client.closeOk(); + connection.getOutput().close(); +} + +void ConnectionHandler::Handler::closeOk(){ + connection.getOutput().close(); +} diff --git a/qpid/cpp/src/qpid/broker/ConnectionHandler.h b/qpid/cpp/src/qpid/broker/ConnectionHandler.h new file mode 100644 index 0000000000..aa8c9366cd --- /dev/null +++ b/qpid/cpp/src/qpid/broker/ConnectionHandler.h @@ -0,0 +1,70 @@ +/* + * + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + * + */ +#ifndef _ConnectionAdapter_ +#define _ConnectionAdapter_ + +#include +#include "qpid/framing/amqp_types.h" +#include "qpid/framing/AMQFrame.h" +#include "qpid/framing/AMQP_ServerOperations.h" +#include "qpid/framing/AMQP_ClientProxy.h" +#include "qpid/framing/FrameHandler.h" +#include "qpid/framing/ProtocolInitiation.h" +#include "qpid/framing/ProtocolVersion.h" +#include "qpid/Exception.h" + +namespace qpid { +namespace broker { + +class Connection; + +// TODO aconway 2007-09-18: Rename to ConnectionHandler +class ConnectionHandler : public framing::FrameHandler +{ + struct Handler : public framing::AMQP_ServerOperations::ConnectionHandler + { + framing::AMQP_ClientProxy::Connection client; + Connection& connection; + + Handler(Connection& connection); + void startOk(const qpid::framing::FieldTable& clientProperties, + const std::string& mechanism, const std::string& response, + const std::string& locale); + void secureOk(const std::string& response); + void tuneOk(uint16_t channelMax, uint32_t frameMax, uint16_t heartbeat); + void open(const std::string& virtualHost, + const std::string& capabilities, bool insist); + void close(uint16_t replyCode, const std::string& replyText, + uint16_t classId, uint16_t methodId); + void closeOk(); + }; + std::auto_ptr handler; + public: + ConnectionHandler(Connection& connection); + void init(const framing::ProtocolInitiation& header); + void close(framing::ReplyCode code, const std::string& text, framing::ClassId classId, framing::MethodId methodId); + void handle(framing::AMQFrame& frame); +}; + + +}} + +#endif diff --git a/qpid/cpp/src/qpid/broker/SemanticHandler.cpp b/qpid/cpp/src/qpid/broker/SemanticHandler.cpp index fc878ca346..f8d76c3b5f 100644 --- a/qpid/cpp/src/qpid/broker/SemanticHandler.cpp +++ b/qpid/cpp/src/qpid/broker/SemanticHandler.cpp @@ -28,7 +28,6 @@ #include "Session.h" #include "qpid/framing/ExecutionCompleteBody.h" #include "qpid/framing/ExecutionResultBody.h" -#include "qpid/framing/ChannelOpenBody.h" #include "qpid/framing/InvocationVisitor.h" #include diff --git a/qpid/cpp/src/qpid/broker/SessionHandler.cpp b/qpid/cpp/src/qpid/broker/SessionHandler.cpp index e7ef6fdb87..01ce88059a 100644 --- a/qpid/cpp/src/qpid/broker/SessionHandler.cpp +++ b/qpid/cpp/src/qpid/broker/SessionHandler.cpp @@ -33,8 +33,7 @@ using namespace std; SessionHandler::SessionHandler(Connection& c, ChannelId ch) : InOutHandler(0, &c.getOutput()), connection(c), channel(ch), proxy(out), - ignoring(false), channelHandler(*this), - useChannelClose(false) {} + ignoring(false) {} SessionHandler::~SessionHandler() {} @@ -52,7 +51,7 @@ void SessionHandler::handleIn(AMQFrame& f) { // AMQMethodBody* m=f.getMethod(); try { - if (m && (m->invoke(this) || m->invoke(&channelHandler))) + if (m && m->invoke(this)) return; else if (session) session->in(f); @@ -62,12 +61,7 @@ void SessionHandler::handleIn(AMQFrame& f) { } catch(const ChannelException& e) { ignoring=true; // Ignore trailing frames sent by client. session.reset(); - // FIXME aconway 2007-09-19: Dual-mode hack. - if (useChannelClose) - getProxy().getChannel().close( - e.code, e.toString(), classId(m), methodId(m)); - else - getProxy().getSession().closed(e.code, e.toString()); + getProxy().getSession().closed(e.code, e.toString()); }catch(const ConnectionException& e){ connection.close(e.code, e.what(), classId(m), methodId(m)); }catch(const std::exception& e){ @@ -98,51 +92,6 @@ void SessionHandler::assertClosed(const char* method) { << getChannel())); } -void SessionHandler::ChannelMethods::open(const string& /*outOfBand*/){ - parent.useChannelClose=true; - parent.assertClosed("open"); - parent.session.reset(new Session(parent, 0)); - parent.getProxy().getChannel().openOk(); -} - -// FIXME aconway 2007-08-31: flow is no longer in the spec. -void SessionHandler::ChannelMethods::flow(bool active){ - parent.session->flow(active); - parent.getProxy().getChannel().flowOk(active); -} - -void SessionHandler::ChannelMethods::flowOk(bool /*active*/){} - -void SessionHandler::ChannelMethods::close(uint16_t replyCode, - const string& replyText, - uint16_t classId, uint16_t methodId) -{ - // FIXME aconway 2007-08-31: Extend constants.h to map codes & ids - // to text names. - QPID_LOG(warning, "Received channel.close("< session; bool ignoring; - ChannelMethods channelHandler; - bool useChannelClose; // FIXME aconway 2007-09-19: remove with channel. }; }} // namespace qpid::broker diff --git a/qpid/cpp/src/tests/python_tests b/qpid/cpp/src/tests/python_tests index 33d60fcf09..d9754ed0fb 100755 --- a/qpid/cpp/src/tests/python_tests +++ b/qpid/cpp/src/tests/python_tests @@ -1,7 +1,7 @@ #!/bin/sh # Run the python tests. if test -d ../../../python ; then - cd ../../../python && ./run-tests -v -s ../specs/amqp-transitional.0-10.xml -I cpp_failing_0-10.txt -b localhost:$QPID_PORT $PYTHON_TESTS + cd ../../../python && ./run-tests -v -s ../specs/amqp.0-10-preview.xml -I cpp_failing_0-10.txt -b localhost:$QPID_PORT $PYTHON_TESTS else echo Warning: python tests not found. fi diff --git a/qpid/python/tests_0-10/alternate-exchange.py b/qpid/python/tests_0-10/alternate-exchange.py index a749d733b0..a857496a48 100644 --- a/qpid/python/tests_0-10/alternate-exchange.py +++ b/qpid/python/tests_0-10/alternate-exchange.py @@ -136,9 +136,9 @@ class AlternateExchangeTests(TestBase): #cleanup: other = self.connect() channel = other.channel(1) - channel.channel_open() + channel.session_open() channel.exchange_delete(exchange="alternate") - channel.channel_close(200, "ok") + channel.session_close() other.close() self.assertConnectionException(530, e.args[0]) @@ -162,10 +162,10 @@ class AlternateExchangeTests(TestBase): #cleanup: other = self.connect() channel = other.channel(1) - channel.channel_open() + channel.session_open() channel.exchange_delete(exchange="e") channel.exchange_delete(exchange="alternate") - channel.channel_close(200, "ok") + channel.session_close() other.close() self.assertConnectionException(530, e.args[0]) diff --git a/qpid/python/tests_0-10/dtx.py b/qpid/python/tests_0-10/dtx.py index 000eddff21..ce6e467e0a 100644 --- a/qpid/python/tests_0-10/dtx.py +++ b/qpid/python/tests_0-10/dtx.py @@ -461,8 +461,11 @@ class DtxTests(TestBase): channel2.dtx_demarcation_select() channel2.dtx_demarcation_start(xid=tx) - channel2.message_get(queue="dummy", destination="dummy") + channel2.message_subscribe(queue="dummy", destination="dummy", confirm_mode=1) + channel2.message_flow(destination="dummy", unit=0, value=1) + channel2.message_flow(destination="dummy", unit=1, value=0xFFFFFFFF) self.client.queue("dummy").get(timeout=1).complete() + channel2.message_cancel(destination="dummy") channel2.message_transfer(content=Content(properties={'routing_key':"dummy"}, body="whatever")) channel2.session_close() @@ -589,8 +592,11 @@ class DtxTests(TestBase): def swap(self, channel, src, dest): #consume from src: - channel.message_get(destination="temp-swap", queue=src) + channel.message_subscribe(destination="temp-swap", queue=src, confirm_mode=1) + channel.message_flow(destination="temp-swap", unit=0, value=1) + channel.message_flow(destination="temp-swap", unit=1, value=0xFFFFFFFF) msg = self.client.queue("temp-swap").get(timeout=1) + channel.message_cancel(destination="temp-swap") msg.complete(); #re-publish to dest diff --git a/qpid/python/tests_0-10/message.py b/qpid/python/tests_0-10/message.py index ba26dda309..b5b058340f 100644 --- a/qpid/python/tests_0-10/message.py +++ b/qpid/python/tests_0-10/message.py @@ -70,7 +70,7 @@ class MessageTests(TestBase): #open new channel and cleanup last consumer: channel = self.client.channel(2) - channel.channel_open() + channel.session_open() #check that an exclusive consumer cannot be created if a consumer already exists: self.subscribe(channel, destination="first", queue="test-queue-2") @@ -93,7 +93,7 @@ class MessageTests(TestBase): self.assertChannelException(404, e.args[0]) channel = self.client.channel(2) - channel.channel_open() + channel.session_open() try: #queue not specified and none previously declared for channel: self.subscribe(channel, queue="", destination="") diff --git a/qpid/specs/amqp-transitional.0-10.xml b/qpid/specs/amqp-transitional.0-10.xml deleted file mode 100644 index da3863f00b..0000000000 --- a/qpid/specs/amqp-transitional.0-10.xml +++ /dev/null @@ -1,7348 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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. - - - - - - The client asked for a specific message that is no longer available. The message was delivered - to another client, or was purged from the queue for some other reason. - - - - - - The client attempted to transfer content larger than the server could accept at the present - time. The client may retry at a later time. - - - - - - When the exchange cannot route the result of a .Publish, most likely due to an invalid routing - key. Only when the mandatory flag is set. - - - - - - 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. - - - - - - An operator intervened to close the connection for some reason. The client may retry at some - later date. - - - - - - The client tried to work with an unknown virtual host. - - - - - - The client attempted to work with a server entity to which it has no access due to security - settings. - - - - - - The client attempted to work with a server entity that does not exist. - - - - - - The client attempted to work with a server entity to which it has no access because another - client is working with it. - - - - - - The client requested a method that was not allowed because some precondition failed. - - - - - - The client sent a malformed frame that the server could not decode. This strongly implies a - programming error in the client. - - - - - - The client sent a frame that contained illegal values for one or more fields. This strongly - implies a programming error in the client. - - - - - - 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. - - - - - - - The client attempted to work with a channel that had not been correctly opened. This most - likely indicates a fault in the client layer. - - - - - - 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. - - - - - - The client tried to work with some entity in a manner that is prohibited by the server, due to - security settings or by some other criteria. - - - - - - The client tried to use functionality that is not implemented in the server. - - - - - - The server could not complete the method because of an internal error. The server may require - intervention by an operator in order to resume normal operations. - - - - - - An invalid or illegal argument was passed to a method, and the operation could not proceed. - - - - - - - - XA return code: Normal execution completion (no error). - - - - - - XA return code: The rollback was caused for an unspecified reason. - - - - - - XA return code: A transaction branch took too long. - - - - - - XA return code: The transaction branch may have been heuristically completed. - - - - - - XA return code: The transaction branch has been heuristically committed. - - - - - - XA return code: The transaction branch has been heuristically rolled back. - - - - - - XA return code: The transaction branch has been heuristically committed and rolled back. - - - - - - XA return code: The transaction branch was read-only and has been committed. - - - - - - - - - - Octet of unspecified encoding - - - - - - 8-bit signed integral value (-128 - 127) - - - - - - 8-bit unsigned integral value (0 - 255) - - - - - - 8-bit representation of single character in the iso-8859-15 character set - - - - - - Boolean value (0 represents false, 1 represents true) - - - - - - - - Two octets of unspecified binary encoding - - - - - - 16-bit signed integral value - - - - - - 16-bit unsigned integral value - - - - - - - - Four octets of unspecified binary encoding - - - - - - 32-bit signed integral value - - - - - - 32-bit unsigned integral value - - - - - - Single precision IEEE 754 32-bit floating point - - - - - - Single unicode character in UTF-32 encoding - - - - - - - - Eight octets of unspecified binary encoding - - - - - - 64-bit signed integral value - - - - - - 64-bit unsigned integral value - - - - - - Double precision IEEE 754 floating point - - - - - - Datetime in POSIX time_t format - - - - - - - - Sixteen octets of unspecified binary encoding - - - - - - UUID as defined by RFC4122 - - - - - - - - Thirty two octets of unspecified binary encoding - - - - - - - - Sixty four octets of unspecified binary encoding - - - - - - - - One hundred and twenty eight octets of unspecified binary encoding - - - - - - - - A sequence of up to 255 octets representing opaque binary data - - - - - - A sequence of up to 255 characters in the iso-8859-15 character set - - - - - - A sequence of unicode characters in the utf8 encoding which is able to be encoded in at most - 255 bytes - - - - - - A sequence of unicode characters in the utf16 encoding which is able to be encoded in at most - 255 bytes - - - - - - A sequence of unicode characters in the utf32 encoding which is able to be encoded in at most - 255 bytes (i.e. of 0-63 utf32 characters) - - - - - - - - A sequence of up to 65535 octets representing opaque binary data - - - - - - A sequence of up to 65535 characters in the iso-8859-15 character set - - - - - - A sequence of unicode characters in the utf8 encoding which is able to be encoded in at most - 65535 bytes - - - - - - A sequence of unicode characters in the utf16 encoding which is able to be encoded in at most - 65535 bytes - - - - - - A sequence of unicode characters in the utf32 encoding which is able to be encoded in at most - 65535 bytes (i.e. of 0-16383 utf32 characters) - - - - - - - - A sequence of up to 4294967295 octets representing opaque binary data - - - - - - A sequence of up to 4294967295 characters in the iso-8859-15 character set - - - - - - A sequence of unicode characters in the utf8 encoding which is able to be encoded in at most - 4294967295 bytes - - - - - - A sequence of unicode characters in the utf16 encoding which is able to be encoded in at most - 4294967295 bytes - - - - - - A sequence of unicode characters in the utf32 encoding which is able to be encoded in at most - 4294967295 bytes (i.e. of 0-1073741823 utf32 characters) - - - - - - A field table following the encoding specification given here - - - - - - A sequence is a series of consecutive type-value pairs; using the same type designators as the - field table - - - - - - An array represents a collection of values of the same type. The array is encoded as a single - octet type designator (using the same system as given here for the field table), followed by a - four-octet unsigned integer which represents the number of elements in the collection, - followed by the encoding of that number of values of the given type - - - - - - - - - - Five octets of unspecified binary encoding - - - - - - Encoded as an octet representing the number of decimal places followed by a signed 4 octet - integer. The 'decimals' octet is not signed - - - - - - - - Eight octets of unspecified binary encoding - - - - - - Encoded as an octet representing the number of decimal places followed by a signed 8 octet - integer. The 'decimals' octet is not signed - - - - - - - - - - The void type - - - - - - - - An access ticket granted by the server for a certain set of access rights within a specific - realm. Access tickets are valid within the session where they were created, and expire when - the session closes. - - - - - - - - - - - - - - - - - - - Identifier for the consumer, valid within the current connection. - - - - - - The server-assigned and session-specific delivery tag - - - - The delivery tag is valid only within the session from which the message was received. i.e. - A client MUST NOT receive a message on one session and then acknowledge it on another. - - - - - The server MUST NOT use a zero value for delivery tags. Zero is reserved for client use, - meaning "all messages so far received". - - - - - - - - The exchange name is a client-selected string that identifies the exchange for publish - methods. Exchange names may consist of any mixture of digits, letters, and underscores. - Exchange names are scoped by the virtual host. - - - - This regular expression checks that all characters are one of a-z (lower case), A-Z (upper - case), 0-9 (any digit) and the underscore character. There may be between 1 and 127 of these - characters. - - - - - - - Specifies the list of equivalent or alternative hosts that the server knows about, which will - normally include the current server itself. Clients can cache this information and use it when - reconnecting to a server after a failure. This field may be empty. - - - - - - Message-id is an optional property of UUID type which uniquly identifies a message within the - message system. The message producer is usually responsible for setting the message-id. Note - that the server may discard a message as a duplicate if the value of the message-id matches - that of a previously received message. - - - - A message MUST be unique within a given server instance. A message SHOULD be globally unique - (i.e. across different systems). - - - - - A message ID is immutable. Once set, a message-id MUST NOT be changed or reassigned, even if - the message is replicated, resent or sent to multiple queues. - - - - - - - If this field is set the server does not expect acknowledgements for messages. That is, when a - message is delivered to the client the server automatically and silently acknowledges it on - behalf of the client. This functionality increases performance but at the cost of reliability. - Messages can get lost if a client dies before it can deliver them to the application. - - - - - - If the no-local field is set the server will not send messages to the connection that - published them. - - - - - - Must start with a slash "/" and continue with path names separated by slashes. A path name - consists of any combination of at least one of [A-Za-z0-9] plus zero or more of [.-_+!=:]. - - - - - - - - - This string provides a set of peer properties, used for identification, debugging, and general - information. - - - - - - The queue name identifies the queue within the vhost. Queue names must have a length of - between 1 and 255 chatacters inclusive, must start with a digit, letter or underscores ('_') - character, and must be otherwise encoded in UTF-8. - - - - This regular expression checks that the first character is one of a-z (lower case), A-Z - (upper case), 0-9 (any digit) and the underscore character. Following may be between 0 and - 254 characters of any value. - - - - - - - This indicates that the message has been previously delivered to this or another client. - - - - The server SHOULD try to signal redelivered messages when it can. When redelivering a - message that was not successfully acknowledged, the server SHOULD deliver it to the original - client if possible. - - - Create a shared queue and publish a message to the queue. Consume the message using explicit - acknowledgements, but do not acknowledge the message. Close the connection, reconnect, and - consume from the queue again. The message should arrive with the redelivered flag set. - - - - - The client MUST NOT rely on the redelivered field but should take it as a hint that the - message may already have been processed. A fully robust client must be able to track - duplicate received messages on non-transacted, and locally-transacted sessions. - - - - - - - Serial number defined in RFC1982 which defines the arithmatic, operators and ranges of such - numbers. - - - - - - The reply code. The AMQ reply codes are defined as constants at the start of this formal - specification. - - - - - - - The localised reply text. This text can be logged as an aid to resolving issues. - - - - - - - - - Duration of an event or process measured in milliseconds. - - - - - - Offset in bytes into a message body. - - - - - - Identifier to be used as a reference to a message body. - - - - - - Specifies the destination to which the message is to be transferred. The destination can be - empty, meaning the default exchange or consumer. - - - - - - Code specifying the reason for a message reject. - - - - The reject code must be one of 0 (generic) or 1 (immediate delivery was attempted but - failed). - - - - - - - String describing the reason for a message transfer rejection. - - - - - - A security token used for authentication, replay prevention, and encrypted message bodies. - - - - - - - - - - - - - Controls whether message transfer needs to be confirmed. - - One of: - - off (0): confirmation is not required, once a message has been transferred in pre-acquire - mode (or once acquire has been sent in no-acquire mode) the message is considered - transferred - - - on (1): an acquired message (whether acquisition was implicit as in pre-acquire mode or - explicit as in no-acquire mode) is not considered transferred until the original - transfer is complete (signaled via execution.complete) - - - - - - Indicates whether a transferred message can be considered as automatically acquired or whether - an explicit request is necessary in order to acquire it. - - One of: - - no-acquire (0): the message must be explicitly acquired - - - pre-acquire (1): the message is acquired when the transfer starts - - - - - - - - - - If set on a message that is not routable the broker can discard it. If not set unroutable - should be handled by reject when confirmation is on or by routing to the - alternate-exchange if defined when confirmation is off. - - - - - - This boolean flag indicates that the message has been previously delivered to this or - another client. - - - - - - Message priority, which can be between 0 and 9. Messages with higher priorities may be - delivered before those with lower priorities. - - - - - - The delivery mode may be non-persistent (1) or persistent (2). A persistent message is one - which must be stored on a persistent medium (usually hard drive) at every stage of - delivery so that it will not be lost in event of failure (other than the medium itself). - This is normally accomplished with some additional overhead. A persistent message may be - delivered more than once if there is uncertainty about the state of its delivery after a - failure and recovery. - - Conversely, a non-persistent message may be lost in event of a failure, but the nature of - the communication is such that an occasional message loss is tolerable. This is the lowest - overhead mode. Non-persistent messages are delivered at most once only. - - - - - - If this is set to a non zero value then a message expiration time will be computed based - on the current time plus this value. Messages that live longer than their expiration time - will be discarded (or dead lettered). - - - - If a message is transferred between brokers before delivery to a final consumer the ttl - should be decremented before peer to peer transfer and both timestamp and expiration - should be cleared. - - - - - - - The timestamp is set by the broker on arrival of the message. - - - - - - The expiration header assigned by the broker. After receiving the message the broker sets - expiration to the sum of the ttl specified in the publish method and the current time. - (ttl=expiration - timestamp) - - - - - - The exchange name is a client-selected string that identifies the exchange for transfer - methods. Exchange names may consist of any mixture of digits, letters, and underscores. - Exchange names are scoped by the virtual host. - - - - - - The value of the key determines to which queue the exchange will send the message. The way - in which keys are used to make this routing decision depends on the type of exchange to - which the message is sent. For example, a direct exchange will route a message to a queue - if that queue is bound to the exchange with an identical key to that of the message. - - - - - - - - - - The length of the message content in bytes. - - - - - - This is a unique identifier for the message that is guaranteed to be unique across - multiple instances, sessions and in time. This allows duplicate messages to be detected. - This may be a UUID. Note that this is usually set by the server when it first receives a - message. - - If a client wishes to identify a message, it should use the correlation-id instead. - - - - - - This is a client-specific id that may be used to mark or identify messages between - clients. The server ignores this field. - - - - - - The destination of any message that is sent in reply to this message. - - - - - - The RFC-2046 MIME type for the message content (such as "text/plain"). This is set by the - originating client. - - - - - - The encoding for character-based message content. This is set by the originating client. - Examples include UTF-8 and ISO-8859-16. - - - - - - The JMS message type. - - - - - - The identity of the user responsible for producing the message. - - - - - - The identity of the client application responsible for producing the message. - - - - - - An identifier that links this message to a distributed transaction. - - - - - - A security token used for authentication, replay prevention, and encrypted message bodies. - - - - - - This is a collection of user-defined headers or properties which may be set by the - producing client and retrieved by the consuming client. Similar to JMS Properties. - - - - - - - - - - An xid uniquely identifies a transaction branch. - - - - - xid contains a format identifier, two length fields and a data field: - - format_id long - - gtrid_length octet - - bqual_length octet - - data gtrid_length + bqual_length - - - 4 1 1 g b - +---+---+---+---+---+---+---+- -+---+---+- -+---+ - | format_id | g | b | txn-id | br-id | - +---+---+---+---+---+---+---+- -+---+---+- -+---+ - 0 4 5 6 6+g 6+g+b - - - format_id: an implementation specific format identifier - - gtrid_length: how many bytes of this form the transaction id - - bqual_length: how many bytes of this form the branch id - - data: a sequence of octets of at most 128 bytes containing the txn id and the - branch id - - Note - The sum of the two lengths must equal the length of the data field. - - - - - - - - - Detached-lifetime is an integer encoded as follows: - - * the maximum representable value means unbounded - the maximum length permitted by the peer - - * otherwise, any other value (including zero) is the number of seconds the session's state - is retained during periods when no channel (or equivalent) is attached to the session - (DetachedLifetimeFinite above). - - - - - - - - - - Identifies a set of commands inside the window of open conversations. - - - - - - Any typed struct whose size width is long. - - - - - - The execution header appears on commands after the class and method id, but prior to method - arguments. - - - - - Indicates that the peer sending the request wants to be notified when this command is - completed. - - - - - - - - - - - - - - - - - - - - Content of a message. It should be considered opaque binary data. The length of the message is - determined from the context of this type (the message length field of the message.transfer - method). - - - - - - Set of pairs of RFC-1982 numbers representing a discontinuous range. Each pair represents a - closed interval within the list. - - For example, the set (1,3), (6,6), (8,9) represents the sequence 1,2,3,6,8,9. - - - - - - - - The connection class provides methods for a client to establish a network connection to a - server, and for both peers to operate the connection thereafter. - - - - connection = open-connection - *use-connection - close-connection - open-connection = C:protocol-header - S:START C:START-OK - *challenge - S:TUNE C:TUNE-OK - C:OPEN S:OPEN-OK | S:REDIRECT - challenge = S:SECURE C:SECURE-OK - use-connection = *channel - close-connection = C:CLOSE S:CLOSE-OK - / S:CLOSE C:CLOSE-OK - - - - - - - - - - This method starts the connection negotiation process by telling the client the protocol - version that the server proposes, along with a list of security mechanisms which the client - can use for authentication. - - - - - If the server cannot support the protocol specified in the protocol header, it MUST close - the socket connection without sending any response method. - - - The client sends a protocol header containing an invalid protocol name. The server must - respond by closing the connection. - - - - - - The server MUST provide a protocol version that is lower than or equal to that requested - by the client in the protocol header. - - - The client requests a protocol version that is higher than any valid implementation, e.g. - 9.0. The server must respond with a current protocol version, e.g. 1.0. - - - - - - If the client cannot handle the protocol version suggested by the server it MUST close the - socket connection. - - - The server sends a protocol version that is lower than any valid implementation, e.g. 0.1. - The client must respond by closing the connection. - - - - - - - - - - The protocol version, major component, as transmitted in the AMQP protocol header. This, - combined with the protocol minor component fully describe the protocol version, which is - written in the format major-minor. Hence, with major=1, minor=3, the protocol version - would be "1-3". - - - - - - The protocol version, minor component, as transmitted in the AMQP protocol header. This, - combined with the protocol major component fully describe the protocol version, which is - written in the format major-minor. Hence, with major=1, minor=3, the protocol version - would be "1-3". - - - - - - - The properties SHOULD contain at least these fields: "host", specifying the server host - name or address, "product", giving the name of the server product, "version", giving the - name of the server version, "platform", giving the name of the operating system, - "copyright", if appropriate, and "information", giving other general information. - - - Client connects to server and inspects the server properties. It checks for the presence - of the required fields. - - - - - - - A list of the security mechanisms that the server supports, delimited by spaces. - - - - - - - A list of the message locales that the server supports, delimited by spaces. The locale - defines the language in which the server will send reply texts. - - - - - The server MUST support at least the en_US locale. - - - Client connects to server and inspects the locales field. It checks for the presence of - the required locale(s). - - - - - - - - - - - - This method selects a SASL security mechanism. - - - - - - - - - The properties SHOULD contain at least these fields: "product", giving the name of the - client product, "version", giving the name of the client version, "platform", giving the - name of the operating system, "copyright", if appropriate, and "information", giving - other general information. - - - - - - - A single security mechanisms selected by the client, which must be one of those specified - by the server. - - - - - The client SHOULD authenticate using the highest-level security profile it can handle - from the list provided by the server. - - - - - - If the mechanism field does not contain one of the security mechanisms proposed by the - server in the Start method, the server MUST close the connection without sending any - further data. - - - Client connects to server and sends an invalid security mechanism. The server must - respond by closing the connection (a socket close, with no connection close - negotiation). - - - - - - - - - A block of opaque data passed to the security mechanism. The contents of this data are - defined by the SASL security mechanism. - - - - - - - A single message locale selected by the client, which must be one of those specified by - the server. - - - - - - - - - - The SASL protocol works by exchanging challenges and responses until both peers have - received sufficient information to authenticate each other. This method challenges the - client to provide more information. - - - - - - - - - Challenge information, a block of opaque binary data passed to the security mechanism. - - - - - - - - - This method attempts to authenticate, passing a block of SASL data for the security - mechanism at the server side. - - - - - - - A block of opaque data passed to the security mechanism. The contents of this data are - defined by the SASL security mechanism. - - - - - - - - - - This method proposes a set of connection configuration values to the client. The client can - accept and/or adjust these. - - - - - - - - - The maximum total number of channels that the server allows per connection. Zero means - that the server does not impose a fixed limit, but the number of allowed channels may be - limited by available server resources. - - - - - - The largest frame size that the server proposes for the connection. The client can - negotiate a lower value. Zero means that the server does not impose any specific limit but - may reject very large frames if it cannot allocate resources for them. - - - - - Until the frame-max has been negotiated, both peers MUST accept frames of up to - frame-min-size octets large, and the minimum negotiated value for frame-max is also - frame-min-size. - - - Client connects to server and sends a large properties field, creating a frame of - frame-min-size octets. The server must accept this frame. - - - - - - - - The delay, in seconds, of the connection heartbeat that the server wants. Zero means the - server does not want a heartbeat. - - - - - - - - - This method sends the client's connection tuning parameters to the server. Certain fields - are negotiated, others provide capability information. - - - - - - - The maximum total number of channels that the client will use per connection. - - - - - If the client specifies a channel max that is higher than the value provided by the - server, the server MUST close the connection without attempting a negotiated close. The - server may report the error in some fashion to assist implementors. - - - - - - - - - - The largest frame size that the client and server will use for the connection. Zero means - that the client does not impose any specific limit but may reject very large frames if it - cannot allocate resources for them. Note that the frame-max limit applies principally to - content frames, where large contents can be broken into frames of arbitrary size. - - - - - Until the frame-max has been negotiated, both peers MUST accept frames of up to - frame-min-size octets large, and the minimum negotiated value for frame-max is also - frame-min-size. - - - - - - If the client specifies a frame max that is higher than the value provided by the - server, the server MUST close the connection without attempting a negotiated close. The - server may report the error in some fashion to assist implementors. - - - - - - - The delay, in seconds, of the connection heartbeat that the client wants. Zero means the - client does not want a heartbeat. - - - - - - - - - This method opens a connection to a virtual host, which is a collection of resources, and - acts to separate multiple application domains within a server. The server may apply - arbitrary limits per virtual host, such as the number of each type of entity that may be - used, per connection and/or in total. - - - - - - - - - - - The name of the virtual host to work with. - - - - - If the server supports multiple virtual hosts, it MUST enforce a full separation of - exchanges, queues, and all associated entities per virtual host. An application, - connected to a specific virtual host, MUST NOT be able to access resources of another - virtual host. - - - - - - The server SHOULD verify that the client has permission to access the specified virtual - host. - - - - - - - - The client can specify zero or more capability names, delimited by spaces. The server can - use this string to how to process the client's connection request. - - - - - - In a configuration with multiple collaborating servers, the server may respond to a - Connection.Open method with a Connection.Redirect. The insist option tells the server that - the client is insisting on a connection to the specified server. - - - - When the client uses the insist option, the server MUST NOT respond with a - Connection.Redirect method. If it cannot accept the client's connection request it - should respond by closing the connection with a suitable reply code. - - - - - - - - - - This method signals to the client that the connection is ready for use. - - - - - - - - - - - - This method redirects the client to another server, based on the requested virtual host - and/or capabilities. - - - - - When getting the Connection.Redirect method, the client SHOULD reconnect to the host - specified, and if that host is not present, to any of the hosts specified in the - known-hosts list. - - - - - - - - Specifies the server to connect to. This is an IP address or a DNS name, optionally - followed by a colon and a port number. If no port number is specified, the client should - use the default port number for the protocol. - - - - - - - - - - - - This method indicates that the sender wants to close the connection. This may be due to - internal conditions (e.g. a forced shut-down) or due to an error handling a specific method, - i.e. an exception. When a close is due to an exception, the sender provides the class and - method id of the method which caused the exception. - - - - - - After sending this method any received method except the Close-OK method MUST be - discarded. - - - - - - - - - - - - - - When the close is provoked by a method exception, this is the class of the method. - - - - - - When the close is provoked by a method exception, this is the ID of the method. - - - - - - - - - This method confirms a Connection.Close method and tells the recipient that it is safe to - release resources for the connection and close the socket. - - - - - A peer that detects a socket closure without having received a Close-Ok handshake method - SHOULD log the error. - - - - - - - - - - - - - - The session class provides methods for a client to establish a session with a server and for - both peers to operate the session thereafter. - - - - session = open-session - *use-session - close-session - open-session = C:OPEN S:ATTACHED - / C:RESUME S:ATTACHED - use-session = C:FLOW S:FLOW-OK - / S:FLOW C:FLOW-OK - close-session = C:SUSPEND S:DETACHED - / C:CLOSE S:CLOSED - / S:CLOSED - / S:CLOSE C:CLOSED - / C:CLOSED - - - - - - - - - - This method opens a session with the server. - - When the responding peer creates the session, it MUST create a new, appropriately-unique - name for the session and return this to the creator with the rest of the session details. - - Note that the timer controlling a session's automatic expiry, if any, counts down - immediately from the moment of its creation, unless simultaneously with that moment a - channel (or equivalent) is attached to the session. For this reason, it is recommended that - network protocol mappings create sessions simultaneously with the creation and attachment of - their channel-equivalents, since a zero lease time is perfectly valid and indicates that the - session should be destroyed as soon as it first finds itself inactive. - - During the period that a channel (or equivalent) is attached to a session, the session has - no deletion timer. Every time a channel is detached from a session such that the session is - left without any attached network-level entities, the timer is created, set to its declared - value and started. - - Note that if the peer decides that the requested detached-lifetime timeout is too long, - either because the replying peer does not support sessions with non-zero requested timeouts, - or because the requested timeout exceeds some peer-specific limitation, it may substitute an - acceptable value for the detached-lifetime parameter in its reply to the creation request. - An exception is not required. - - - - - Whether the detachment is explicit or implicit, as a result of application action or of - application error, the channel (or equivalent) is detached from its session and the - session timer MUST start counting down as defined in session.open. - - - - - - - The client MUST NOT send session.open on a channel that is already associated with a - session. A "channel busy" connection exception will occur if the channel down which the - open request was sent was already attached to a session. - - - Client sends session.open twice down the same channel. - - - - - - - - - - - - The number of seconds the session's state is retained during periods when no channel (or - equivalent) is attached to the session. - - - - - - - - - This method signals to the client that the session is ready for use. - - Once a session.attached is received by the client, everything is in place for normal - transmission of frames. However, depending on the network protocol mapping in use, the - frame-id be undefined until certain control frames have been sent. Please see the specific - details for each protocol mapping. - - If the attached session was freshly created, the session-id here will be a freshly-generated - UUID. - - Note that the actual session detached-lifetime value, as decided by the peer, is returned - using this method. The value returned may not be the same as that requested in the - corresponding session creation request. In particular, a request for an unbounded - detached-lifetime of may be fulfilled by creation of a session with a bounded actual - lifetime parameter. The requesting peer SHOULD take the lifetime value returned as - authoritative for its own session-related record-keeping. - - - - - - - The session identifier (a UUID) used to identify this session. - - - - - - The number of seconds the session's state is retained during periods when no channel (or - equivalent) is attached to the session. - - - - - - - - - This method asks the peer to pause or restart the flow of content data. This is a simple - flow-control mechanism that a peer can use to avoid overflowing its queues or otherwise - finding itself receiving more messages than it can process. Note that this method is not - intended for window control. The peer that receives a disable flow method should finish - sending the current content frame, if any, then pause. - - - - - When a new session is opened, it is active (flow is active). Some applications assume that - sessions are inactive until started. To emulate this behaviour a client MAY open the - session, then pause it. - - - - - - When sending content frames, a peer SHOULD monitor the session for incoming methods and - respond to a Session.Flow as rapidly as possible. - - - - - - A peer MAY use the Session.Flow method to throttle incoming content data for internal - reasons, for example, when exchanging data over a slower connection. - - - - - - The peer that requests a Session.Flow method MAY disconnect and/or ban a peer that does - not respect the request. This is to prevent badly-behaved clients from overwhelming a - broker. - - - - - - - - - - - If true (1), the peer starts sending content frames. If false (0), the peer stops sending - content frames. - - - - - - - - - Confirms to the peer that a flow command was received and processed. - - - - - - - - Confirms the setting of the processed flow method: true (1) means the peer will start - sending or continue to send content frames; false (0) means it will not. - - - - - - - - - Requests that the receiving peer destroy a session, implicitly detaching any attached - channels or channel-equivalents. - - Note that the reply, session.closed, is also used for asynchronous exception notifications. - For normal closure, such as in response to a session.close request, reason code 200 ("ok") - is to be used. - - - - - - - - - - - - - Notifies the receiver that not only has the current channel been detached from its - underlying session, but that the session itself has been destroyed. - - This method confirms a session.close method and tells the recipient that it is safe to - release resources for the channel. - - Note also that for normal closure, reason code 200 ("ok") is to be used. - - - - - - - - The numeric reply code. - - - - - - The localised reply text. - - - - - - - - - Attaches to an already-existing session. - - - - - A "session busy" exception is returned if the session exists, but is not in a condition - where it can accept the requested attachment. Peers receiving this exception may wish to - retain their session state and retry the session.resume operation after a delay. - - - - - - - - - - The session identifier (a UUID) used to identify this session. - - - - - - - - - Indicates the sending peer wishes to detach from this session, but not necessarily to - destroy it. - - - - - - - - - - - - - Signal detachment from the session. - - - - - - - - - - - Signals receipt of all frames such that frame-id <= cumulative-seen-mark, or frame-id is - in the set defined by seen-frame-set. This can be sent spontaneously, or in response to - either session.solicit-ack or session.high-water-mark. - - Note that an encoded acknowledgement frame carried over the TCP network mapping (in the - absence of cross-protocol use of a session) will never have any entries in its - seen-frame-set. - - - - - - - In order to ensure a canonical wire representation, the value cumulative-seen-mark + - 1 must not be covered by the seen-frame-set. - - - - - - - - - The low-water mark for seen frame-ids. All ids below this mark have been seen; above this - mark, there are gaps containing unseen ids (i.e. discontinuous). By definition, the first - frame-id above this mark (if it exists) is an unseen id. - - - - - - This set contains a sequence of discontinuous seen-frame-ids above the low-water mark - (i.e. above the first gap of unseen ids). In some transports where out-of-order delivery - is not possible (such as TCP), this set will always be empty. - - - - - - - - - Carries information about the highest (most recent) frame-id number that the sending peer - has sent through this session so far. - - The receiver should issue a session.ack at the earliest possible opportunity. - - - - - - - - Highest frame-id sent by the sending peer through this session so far. - - - - - - - - - Requests a session.ack from the peer. The peer should issue one at the earliest possible - opportunity. - - - - - - - - - - - - - - The protocol control access to server resources using access tickets. A client must explicitly - request access tickets before doing work. An access ticket grants a client the right to use a - specific set of resources - called a "realm" - in specific ways. - - - - access = C:REQUEST S:REQUEST-OK - - - - - - - - - - This method requests an access ticket for an access realm. The server responds by granting - the access ticket. If the client does not have access rights to the requested realm this - causes a connection exception. Access tickets are a per-session resource. - - - - - - - - - Specifies the name of the realm to which the client is requesting access. The realm is a - configured server-side object that collects a set of resources (exchanges, queues, etc.). - If the session has already requested an access ticket onto this realm, the previous ticket - is destroyed and a new ticket is created with the requested access rights, if allowed. - - - - The client MUST specify a realm that is known to the server. The server makes an - identical response for undefined realms as it does for realms that are defined but - inaccessible to this client. - - - Client specifies an undefined realm. - - - - - - - Request exclusive access to the realm, meaning that this will be the only session that - uses the realm's resources. - - - - The client MUST NOT request exclusive access to a realm that has active access tickets, - unless the same session already had the only access ticket onto that realm. - - - Client opens two sessions and requests exclusive access to the same realm. - - - - - - - Request message passive access to the specified access realm. Passive access lets a client - get information about resources in the realm but not to make any changes to them. - - - - - - Request message active access to the specified access realm. Active access lets a client - get create and delete resources in the realm. - - - - - - Request write access to the specified access realm. Write access lets a client publish - messages to all exchanges in the realm. - - - - - - Request read access to the specified access realm. Read access lets a client consume - messages from queues in the realm. - - - - - - - - - This method provides the client with an access ticket. The access ticket is valid within the - current session and for the lifespan of the session. - - - - - The client MUST NOT use access tickets except within the same session as originally - granted. - - - Client opens two sessions, requests a ticket on one session and then tries to use that - ticket in a second session. - - - - - - - - A valid access ticket to be used for gaining access to the server. - - - - - - - - - - - Exchanges match and distribute messages across queues. Exchanges can be configured in the - server or created at runtime. - - - - exchange = C:DECLARE - / C:DELETE - - - - - The server MUST implement these standard exchange types: fanout, direct. - - - Client attempts to declare an exchange with each of these standard types. - - - - - - The server SHOULD implement these standard exchange types: topic, headers. - - - Client attempts to declare an exchange with each of these standard types. - - - - - - The server MUST, in each virtual host, pre-declare an exchange instance for each standard - exchange type that it implements, where the name of the exchange instance, if defined, is - "amq." followed by the exchange type name. - - The server MUST, in each virtual host, pre-declare at least two direct exchange instances: - one named "amq.direct", the other with no public name that serves as a default exchange for - publish methods (such as message.transfer). - - - Client creates a temporary queue and attempts to bind to each required exchange instance - ("amq.fanout", "amq.direct", "amq.topic", and "amq.headers" if those types are defined). - - - - - - The server MUST pre-declare a direct exchange with no public name to act as the default - exchange for content publish methods (such as message.transfer) and for default queue - bindings. - - - Client checks that the default exchange is active by publishing a message with a suitable - routing key but without specifying the exchange name, then ensuring that the message arrives - in the queue correctly. - - - - - - The default exchange MUST NOT be accessible to the client except by specifying an empty - exchange name in a content publish method (such as message.transfer). That is, the server - must not let clients explicitly bind, unbind, delete, or make any other reference to this - exchange. - - - - - - The server MAY implement other exchange types as wanted. - - - - - - - - - - - This method creates an exchange if it does not already exist, and if the exchange exists, - verifies that it is of the correct and expected class. - - - - - The server SHOULD support a minimum of 16 exchanges per virtual host and ideally, impose - no limit except as defined by available resources. - - - The client creates as many exchanges as it can until the server reports an error; the - number of exchanges successfully created must be at least sixteen. - - - - - - - - When a client defines a new exchange, this belongs to the access realm of the ticket used. - All further work done with that exchange must be done with an access ticket for the same - realm. - - - - - The client MUST provide a valid access ticket giving "active" access to the realm in - which the exchange exists or will be created, or "passive" access if the if-exists flag - is set. - - - Client creates access ticket with wrong access rights and attempts to use in this - method. - - - - - - - - - - Exchange names starting with "amq." are reserved for pre-declared and standardised - exchanges. The client MUST NOT attempt to create an exchange starting with "amq.". - - - - - - The name of the exchange MUST NOT be a blank or empty string. - - - - - - - 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. - - - - - 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. - - - - - - The client MUST NOT attempt to create an exchange with a type that the server does not - support. - - - - - - - - - In the event that a message cannot be routed, this is the name of the exchange to which - the message will be sent. - - - - - If alternate-exchange is not set (its name is an empty string), unroutable messages MUST - be dropped silently. - - - - - - If the alternate-exchange is not empty and if the exchange already exists with a - different alternate-exchange, then the declaration MUST result in a channel error. - - - - - - A message which is being routed to a alternate exchange, MUST NOT be re-routed to a - secondary alternate exchange if it fails to route in the primary alternate exchange. - After such a failure, the message MUST be dropped. This prevents looping. - - - - - - - If set, the server will not create the exchange. The client can use this to check whether - an exchange exists without modifying the server state. - - - - If set, and the exchange does not already exist, the server MUST raise a channel - exception with reply code 404 (not found). - - - - - - - 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. - - - - - The server MUST support both durable and transient exchanges. - - - - - - The server MUST ignore the durable field if the exchange already exists. - - - - - - - If set, the exchange is deleted when all queues have finished using it. - - - - The server MUST ignore the auto-delete field if the exchange already exists. - - - - - - - A set of arguments for the declaration. The syntax and semantics of these arguments - depends on the server implementation. This field is ignored if passive is 1. - - - - - - - - - This method deletes an exchange. When an exchange is deleted all queue bindings on the - exchange are cancelled. - - - - - - - - The client MUST provide a valid access ticket giving "active" access rights to the - exchange's access realm. - - - Client creates access ticket with wrong access rights and attempts to use in this - method. - - - - - - - - The client MUST NOT attempt to delete an exchange that does not exist. - - - - - - The name of the exchange MUST NOT be a blank or empty string. - - - - - - - - - - If set, the server will only delete the exchange if it has no queue bindings. If the - exchange has queue bindings the server does not delete it but raises a channel exception - instead. - - - - - - - - - This method is used to request information on a particular exchange. - - - - - - - - The client MUST provide a valid access ticket giving "passive" access rights to the - exchange's access realm. - - - - - - - The name of the exchange for which information is requested. If not specified explicitly - the default exchange is implied. - - - - - - - This is sent in response to a query request and conveys information on a particular - exchange. - - - - - The type of the exchange. Will be empty if the exchange is not found. - - - - - - The durability of the exchange, i.e. if set the exchange is durable. Will not be set if - the exchange is not found. - - - - - - If set, the exchange for which information was requested is not known. - - - - - - A set of properties of the exchange whose syntax and semantics depends on the server - implementation. Will be empty if the exchange is not found. - - - - - - - - - - - - - Queues store and forward messages. Queues can be configured in the server or created at - runtime. Queues must be attached to at least one exchange in order to receive messages from - publishers. - - - - queue = C:DECLARE - / C:BIND - / C:PURGE - / C:DELETE - / C:QUERY - / C:UNBIND - - - - - A server MUST allow any content class to be sent to any queue, in any mix, and queue and - deliver these content classes independently. Note that all methods that fetch content off - queues are specific to a given content class. - - - Client creates an exchange of each standard type and several queues that it binds to each - exchange. It must then successfully send each of the standard content types to each of the - available queues. - - - - - - - - - - - This method creates or checks a queue. When creating a new queue the client can specify - various properties that control the durability of the queue and its contents, and the level - of sharing for the queue. - - - - - The server MUST create a default binding for a newly-created queue to the default - exchange, which is an exchange of type 'direct' and use the queue name as the routing key. - - - Client creates a new queue, and then without explicitly binding it to an exchange, - attempts to send a message through the default exchange binding, i.e. publish a message to - the empty exchange, with the queue name as routing key. - - - - - - The server SHOULD support a minimum of 256 queues per virtual host and ideally, impose no - limit except as defined by available resources. - - - Client attempts to create as many queues as it can until the server reports an error. The - resulting count must at least be 256. - - - - - - - - When a client defines a new queue, this belongs to the access realm of the ticket used. - All further work done with that queue must be done with an access ticket for the same - realm. - - - - The client MUST provide a valid access ticket giving "active" access to the realm in - which the queue exists or will be created. - - - Client creates access ticket with wrong access rights and attempts to use in this - method. - - - - - - - - Queue names starting with "amq." are reserved for pre-declared and standardised server - queues. A client MUST NOT attempt to declare a queue with a name that starts with "amq." - and the passive option set to zero. - - - A client attempts to create a queue with a name starting with "amq." and with the - passive option set to zero. - - - - - - - If a message is rejected by a queue, then it is sent to the alternate-exchange. A message - may be rejected by a queue for the following reasons: - 1. The queue is deleted when it is not empty; - 2. Immediate delivery of a message is requested, but there are no consumers connected to - the queue. - - - - - If alternate-exchange is not set (its name is an empty string), rejected messages MUST - be dropped silently. - - - - - - If the alternate-exchange is not empty and if the queue already exists with a different - alternate-exchange, then the declaration MUST result in a channel error. - - - - - - The alternate-exchange MUST NOT be deleted while a queue bound to it still exists. Such - an attempt MUST result in a channel exception. - - - - - - - If set, the server will not create the queue. This field allows the client to assert the - presence of a queue without modifying the server state. - - - - - The client MAY ask the server to assert that a queue exists without creating the queue - if not. If the queue does not exist, the server treats this as a failure. - - - Client declares an existing queue with the passive option and expects the command to - succeed. Client then attempts to declare a non-existent queue with the passive option, - and the server must close the channel with the correct reply-code. - - - - - - - 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. - - - - - The server MUST recreate the durable queue after a restart. - - - Client creates a durable queue; server is then restarted. Client then attempts to send - message to the queue. The message should be successfully delivered. - - - - - - The server MUST support both durable and transient queues. - - - A client creates two named queues, one durable and one transient. - - - - - - The server MUST ignore the durable field if the queue already exists. - - - A client creates two named queues, one durable and one transient. The client then - attempts to declare the two queues using the same names again, but reversing the value - of the durable flag in each case. Verify that the queues still exist with the original - durable flag values. - - - - - - - - Exclusive queues can only be used from one connection at a time. Once a connection - declares an exclusive queue, that queue cannot be used by any other connections until the - declaring connection closes. - - - - - The server MUST support both exclusive (private) and non-exclusive (shared) queues. - - - A client creates two named queues, one exclusive and one non-exclusive. - - - - - - If the server receives a declare, bind, consume or get request for a queue that has been - declared as exclusive by an existing client connection, it MUST raise a channel - exception. - - - A client declares an exclusive named queue. A second client on a different connection - attempts to declare a queue of the same name. - - - - - - - If this field is set and the exclusive field is also set, then the queue MUST be deleted - when the connection closes. - - If this field is set and the exclusive field is not set the queue is deleted when all - the consumers have finished using it. 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. - - - - - The server MUST ignore the auto-delete field if the queue already exists. - - - A client creates two named queues, one as auto-delete and one explicit-delete. The - 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. - - - - - - - - A set of arguments for the declaration. The syntax and semantics of these arguments - depends on the server implementation. This field is ignored if passive is 1. - - - - - - - - - This method binds a queue to an exchange. Until a queue is bound it will not receive any - messages. In a classic messaging model, store-and-forward queues are bound to a direct - exchange and subscription queues are bound to a topic exchange. - - - - - A server MUST allow ignore duplicate bindings - that is, two or more bind methods for a - specific queue, with identical arguments - without treating these as an error. - - - A client binds a named queue to an exchange. The client then repeats the bind (with - identical arguments). - - - - - - - If a bind fails, the server MUST raise a connection exception. - - - - - - The server MUST NOT allow a durable queue to bind to a transient exchange. - - - A client creates a transient exchange. The client then declares a named durable queue and - then attempts to bind the transient exchange to the durable queue. - - - - - - Bindings for durable queues are automatically durable and the server SHOULD restore such - bindings after a server restart. - - - A server creates a named durable queue and binds it to a durable exchange. The server is - restarted. The client then attempts to use the queue/exchange combination. - - - - - - If the client attempts to bind to an exchange that was declared as internal, the server - MUST raise a connection exception with reply code 530 (not allowed). - - - A client attempts to bind a named queue to an internal exchange. - - - - - - The server SHOULD support at least 4 bindings per queue, and ideally, impose no limit - except as defined by available resources. - - - A client creates a named queue and attempts to bind it to 4 different non-internal - exchanges. - - - - - - Where more than one binding exists between a particular exchange instance and a particular - queue instance any given message published to that exchange should be delivered to that - queue at most once, regardless of how many distinct bindings match. - - - A client creates a named queue and binds it to the same topic exchange at least three - times using intersecting routing keys (for example, "animals.*", "animals.dogs.*", - "animal.dogs.chihuahua"). Verify that a message matching all the bindings (using previous - example, routing key = "animal.dogs.chihuahua") is delivered once only. - - - - - - - - - The client provides a valid access ticket giving "active" access rights to the queue's - access realm. - - - - - - - Specifies the name of the queue to bind. If the queue name is empty, refers to the current - queue for the session, which is the last declared queue. - - - - - A client MUST NOT be allowed to bind a non-existent and unnamed queue (i.e. empty queue - name) to an exchange. - - - A client attempts to bind with an unnamed (empty) queue name to an exchange. - - - - - - A client MUST NOT be allowed to bind a non-existent queue (i.e. not previously declared) - to an exchange. - - - A client attempts to bind an undeclared queue name to an exchange. - - - - - - - - A client MUST NOT be allowed to bind a queue to a non-existent exchange. - - - A client attempts to bind a named queue to a undeclared exchange. - - - - - - The name of the exchange MUST NOT be a blank or empty string. - - - - - - - Specifies the routing key for the binding. The routing key is used for routing messages - depending on the exchange configuration. Not all exchanges use a routing key - refer to - the specific exchange documentation. If the queue name is empty, the server uses the last - queue declared on the session. If the routing key is also empty, the server uses this - queue name for the routing key as well. If the queue name is provided but the routing key - is empty, the server does the binding with that empty routing key. The meaning of empty - routing keys depends on the exchange implementation. - - - - If a message queue binds to a direct exchange using routing key K and a publisher sends - the exchange a message with routing key R, then the message MUST be passed to the - message queue if K = R. - - - - - - - A set of arguments for the binding. The syntax and semantics of these arguments depends on - the exchange class. - - - - - - - - - This method unbinds a queue from an exchange. - - - - - If a unbind fails, the server MUST raise a connection exception. - - - - - - - - - - The client provides a valid access ticket giving "active" access rights to the queue's - access realm. - - - - - - - Specifies the name of the queue to unbind. - - - - If the queue does not exist the server MUST raise a channel exception with reply code - 404 (not found). - - - - - - - The name of the exchange to unbind from. - - - - - If the exchange does not exist the server MUST raise a channel exception with reply code - 404 (not found). - - - - - - The name of the exchange MUST NOT be a blank or empty string. - - - - - - - Specifies the routing key of the binding to unbind. - - - - - - Specifies the arguments of the binding to unbind. - - - - - - - - - This method removes all messages from a queue. It does not cancel consumers. Purged messages - are deleted without any formal "undo" mechanism. - - - - - A call to purge MUST result in an empty queue. - - - - - - On transacted sessions the server MUST not purge messages that have already been sent to a - client but not yet acknowledged. - - - - - - 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. - - - - - - - - - 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. - - - - - - - Specifies the name of the queue to purge. If the queue name is empty, refers to the - current queue for the session, which is the last declared queue. - - - - - 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). - - - - - - The queue MUST exist. Attempting to purge a non-existing queue MUST cause a channel - exception with reply code 404 (not found). - - - - - - - - - - This method deletes a queue. When a queue is deleted any pending messages are sent to a - dead-letter queue if this is defined in the server configuration, and all consumers on the - queue are cancelled. - - - - - The server SHOULD use a dead-letter queue to hold messages that were pending on a deleted - queue, and MAY provide facilities for a system administrator to move these messages back - to an active queue. - - - - - - - - - The client provides a valid access ticket giving "active" access rights to the queue's - access realm. - - - - - - - Specifies the name of the queue to delete. If the queue name is empty, refers to the - current queue for the session, which is the last declared queue. - - - - - 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). - - - - - - The queue must exist. If the client attempts to delete a non-existing queue the server - MUST raise a channel exception with reply code 404 (not found). - - - - - - - If set, the server will only delete the queue if it has no consumers. If the queue has - consumers the server does does not delete it but raises a channel exception instead. - - - - - The server MUST respect the if-unused flag when deleting a queue. - - - - - - - If set, the server will only delete the queue if it has no messages. - - - - If the queue is not empty the server MUST raise a channel exception with reply code 406 - (precondition failed). - - - - - - - - - - This method requests information about a queue. - - - - - - - - - - - - - This is sent in response to queue.query, and conveys the requested information about a - queue. - - - - - Reports the name of the queue. - - - - - - - - - - - - - - - - - Reports the number of messages in the queue. - - - - - - Reports the number of active consumers for the queue. Note that consumers can suspend - activity (Session.Flow) in which case they do not appear in this count. - - - - - - - - - - - - - [DEPRECATED: replaced by message class.] The Basic class provides methods that support an - industry-standard messaging model. - - - - basic = C:QOS - / C:CONSUME S:CONSUME-OK - / C:CANCEL - / C:PUBLISH content - / S:RETURN content - / S:DELIVER content - / C:GET ( S:GET-OK content / S:GET-EMPTY ) - / C:ACK - / C:REJECT - - - - - 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. - - - 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. - - - - - - The server MUST NOT discard a persistent basic message in case of a queue overflow. - - - Create a queue overflow situation with persistent messages and verify that messages do not - get lost (presumably the server will write them to disk). - - - - - - The server MAY use the Session.Flow method to slow or stop a basic message publisher when - necessary. - - - Create a queue overflow situation with non-persistent messages and verify whether the server - responds with Session.Flow or not. Repeat with persistent messages. - - - - - - The server MAY overflow non-persistent basic messages to persistent storage. - - - - - - - The server MAY discard or dead-letter non-persistent basic messages on a priority basis if - the queue size exceeds some configured limit. - - - - - - - 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. - - - 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. - - - - - - The server MAY implement up to 10 priority levels. - - - Send a number of messages with mixed priorities to a queue, so that all priority values from - 0 to 9 are exercised. A good scenario would be ten messages in low-to-high priority. Consume - from queue and verify how many priority levels emerge. - - - - - - The server MUST deliver messages of the same priority in order irrespective of their - individual persistence. - - - Send a set of messages with the same priority but different persistence settings to a queue. - Consume and verify that messages arrive in same order as originally published. - - - - - - The server MUST support automatic acknowledgements on Basic content, i.e. consumers with the - no-ack field set to FALSE. - - - Create a queue and a consumer using automatic acknowledgements. Publish a set of messages to - the queue. Consume the messages and verify that all messages are received. - - - - - - The server MUST support explicit acknowledgements on Basic content, i.e. consumers with the - no-ack field set to TRUE. - - - Create a queue and a consumer using explicit acknowledgements. Publish a set of messages to - the queue. Consume the messages but acknowledge only half of them. Disconnect and reconnect, - and consume from the queue. Verify that the remaining messages are received. - - - - - - - - - - - - - - - - - - - - - - - - - - - [DEPRECATED: Basic replaced by message class.] This method requests a specific quality of - service. The QoS can be specified for the current session or for all sessions on the - connection. The particular properties and semantics of a qos method always depend on the - content class semantics. Though the qos method could in principle apply to both peers, it is - currently meaningful only for the server. - - - - - - - The client can request that messages be sent in advance so that when the client finishes - processing a message, the following message is already held locally, rather than needing - to be sent within the session. Prefetching gives a performance improvement. This field - specifies the prefetch window size in octets. The server will send a message in advance if - it is equal to or smaller in size than the available prefetch size (and also falls into - other prefetch limits). May be set to zero, meaning "no specific limit", although other - prefetch limits may still apply. The prefetch-size is ignored if the no-ack option is set. - - - - - The server MUST ignore this setting when the client is not processing any messages - - i.e. the prefetch size does not limit the transfer of single messages to a client, only - the sending in advance of more messages while the client still has one or more - unacknowledged messages. - - - Define a QoS prefetch-size limit and send a single message that exceeds that limit. - Verify that the message arrives correctly. - - - - - - - Specifies a prefetch window in terms of whole messages. This field may be used in - combination with the prefetch-size field; a message will only be sent in advance if both - prefetch windows (and those at the session and connection level) allow it. The - prefetch-count is ignored if the no-ack option is set. - - - - - The server may send less data in advance than allowed by the client's specified prefetch - windows but it MUST NOT send more. - - - Define a QoS prefetch-size limit and a prefetch-count limit greater than one. Send - multiple messages that exceed the prefetch size. Verify that no more than one message - arrives at once. - - - - - - - By default the QoS settings apply to the current session only. If this field is set, they - are applied to the entire connection. - - - - - - - - - [DEPRECATED: Basic replaced by message class.] This method asks the server to start a - "consumer", which is a transient request for messages from a specific queue. Consumers last - as long as the session they were created on, or until the client cancels them. - - - - - The server SHOULD support at least 16 consumers per queue, and ideally, impose no limit - except as defined by available resources. - - - Create a queue and create consumers on that queue until the server closes the connection. - Verify that the number of consumers created was at least sixteen and report the total - number. - - - - - - - - - - - The client MUST provide a valid access ticket giving "read" access rights to the realm - for the queue from which the message will be consumed. - - - Attempt to create a consumer with an invalid (non-zero) access ticket. - - - - - - - Specifies the name of the queue to consume from. If the queue name is null, refers to the - current queue for the session, which is the last declared queue. - - - - If the queue name is empty the client MUST have previously declared a queue using this - session. - - - Attempt to create a consumer with an empty queue name and no previously declared queue - on the session. - - - - - - - Specifies the identifier for the consumer. The consumer tag is local to a connection, so - two clients can use the same consumer tags. If this field is empty the server will - generate a unique tag. - - - - - The client MUST NOT specify a tag that refers to an existing consumer. - - - Attempt to create two consumers with the same non-empty tag. - - - - - - The consumer tag is valid only within the session from which the consumer was created. - i.e. A client MUST NOT create a consumer in one session and then use it in another. - - - Attempt to create a consumer in one session, then use in another session, in which - consumers have also been created (to test that the server uses unique consumer tags). - - - - - - - - - - - Request exclusive consumer access, meaning only this consumer can access the queue. - - - - - The client MUST NOT gain exclusive access to a queue that already has active consumers. - - - Open two connections to a server, and in one connection create a shared (non-exclusive) - queue and then consume from the queue. In the second connection attempt to consume from - the same queue using the exclusive option. - - - - - - - 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. - - - - - - A set of arguments for the consume. The syntax and semantics of these arguments depends on - the providers implementation. - - - - - - - - - [DEPRECATED: Basic replaced by message class.] The server provides the client with a - consumer tag, which is used by the client for methods called on the consumer at a later - stage. - - - - - - - Holds the consumer tag specified by the client or provided by the server. - - - - - - - - - [DEPRECATED: Basic replaced by message class.] This method cancels a consumer. This does not - affect already delivered messages, but it does mean the server will not send any more - messages for that consumer. The client may receive an arbitrary number of messages in - between sending the cancel method and receiving notification of the completion of the cancel command. - - - - - If the queue does not exist the server MUST ignore the cancel method, so long as the - consumer tag is valid for that session. - - - - - - - - - - - - - [DEPRECATED: Basic replaced by message class.] This method publishes a message to a specific - exchange. The 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. - - - - - - - - The client MUST provide a valid access ticket giving "passive" access rights to the - realm for the exchange and "write" access rights to the realm for the queue to which the - message will be published. - - - - - - - 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. - - - - - The server MUST accept a blank exchange name to mean the default exchange. - - - - - - If the exchange was declared as an internal exchange, the server MUST raise a channel - exception with a reply code 403 (access refused). - - - - - - The exchange MAY refuse basic content in which case it MUST raise a channel exception - with reply code 540 (not implemented). - - - - - - - Specifies the routing key for the message. The routing key is used for routing messages - depending on the exchange configuration. - - - - - - If the reject-unroutable flag is set, then at the time of publishing the broker - determines if the message will be routed to any queues. If it will not be routed to any - queue then the broker responds with a basic.reject. - - - - - - If this flag is set, and the resulting message is delivered to a queue with no - consumers, the message will not be queued but will instead be routed to the - alternate-exchange for that queue. If no such exchange is defined the message will be - silently dropped. - - - - The server SHOULD implement the immediate flag. - - - - - - - - - - [DEPRECATED: Basic replaced by message class.] This method delivers a message to the client, - via a consumer. In the asynchronous message delivery model, the client starts a consumer - using the Consume method, then the server responds with Deliver methods as and when messages - arrive for that consumer. - - - - - The server SHOULD track the number of times a message has been delivered to clients and - when a message is redelivered a certain number of times - e.g. 5 times - without being - acknowledged, the server SHOULD consider the message to be unprocessable (possibly causing - client applications to abort), and move the message to a dead letter queue. - - - - - - - - - - - - - - Specifies the name of the exchange that the message was originally published to. - - - - - - Specifies the routing key name specified when the message was published. - - - - - - - - - [DEPRECATED: Basic replaced by message class.] This method provides a direct access to the - messages in a queue using a synchronous dialogue that is designed for specific types of - application where synchronous functionality is more important than performance. - - - - - - - - - - - The client MUST provide a valid access ticket giving "read" access rights to the realm - for the queue from which the message will be obtained. - - - - - - - Specifies the name of the queue to consume from. If the queue name is null, refers to the - current queue for the session, which is the last declared queue. - - - - 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). - - - - - - - - - - - - [DEPRECATED: Basic replaced by message class.] This method delivers a message to the client - following a get method. A message delivered by 'get-ok' must be acknowledged unless the - no-ack option was set in the get method. - - - - - - - - - - - Specifies the name of the exchange that the message was originally published to. If empty, - the message was published to the default exchange. - - - - - - Specifies the routing key name specified when the message was published. - - - - - - This field reports the number of messages pending on the queue, excluding the message - being delivered. Note that this figure is indicative, not reliable, and can change - arbitrarily as messages are added to the queue and removed by other clients. - - - - - - - - - [DEPRECATED: Basic replaced by message class.] This method tells the client that the queue - has no messages available for the client. - - - - - - - - For use by cluster applications, should not be used by client applications. - - - - - - - - - [DEPRECATED: Basic replaced by message class.] This method acknowledges one or more messages - delivered via the Deliver or Get-Ok methods. The client can ask to confirm a single message - or a set of messages up to and including a specific message. - - - - - - - - - If set to 1, the delivery tag is treated as "up to and including", so that the client can - acknowledge multiple messages 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, - tells the server to acknowledge all outstanding messages. - - - - - The server MUST validate that a non-zero delivery-tag refers to a delivered message, and - raise a channel exception if this is not the case. - - - - - - - - - - [DEPRECATED: Basic replaced by message class.] 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. - - - - - The server SHOULD be capable of accepting and processing 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). - - - - - - The server SHOULD interpret this method as meaning that the client is unable to process - the message at this time. - - - - - - A client MUST NOT use this method as a means of selecting messages to process. A rejected - message MAY be discarded or dead-lettered, not necessarily passed to another client. - - - - - - - - - - If this field is zero, the message will be discarded. If this bit is 1, the server will - attempt to requeue the message. - - - - - The server MUST NOT deliver the message to the same client within the context of the - current session. 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. - - - - - - - - - - [DEPRECATED: Basic replaced by message class.] This method asks the broker to redeliver all - unacknowledged messages on a specified session. Zero or more messages may be redelivered. - This method is only allowed on non-transacted sessions. - - - - - The server MUST set the redelivered flag on all messages that are resent. - - - - - - The server MUST raise a channel exception if this is called on a transacted session. - - - - - - - - - If this field is zero, the message will be redelivered to the original recipient. If this - bit is 1, the server will attempt to requeue the message, potentially then delivering it - to an alternative subscriber. - - - - - - - - - - - The file class provides methods that support reliable file transfer. File messages have a - specific set of properties that are required for interoperability with file transfer - applications. File messages and acknowledgements are subject to session transactions. Note - that the file class does not provide message browsing methods; these are not compatible with - the staging model. Applications that need browsable file transfer should use Basic content and - the Basic class. - - - - file = C:QOS S:QOS-OK - / C:CONSUME S:CONSUME-OK - / C:CANCEL - / C:OPEN S:OPEN-OK C:STAGE content - / S:OPEN C:OPEN-OK S:STAGE content - / C:PUBLISH - / S:DELIVER - / S:RETURN - / C:ACK - / C:REJECT - - - - - The server MUST make a best-effort to hold file messages on a reliable storage mechanism. - - - - - - - - The server MUST NOT discard a file message in case of a queue overflow. The server MUST use - the Session.Flow method to slow or stop a file message publisher when necessary. - - - - - - The server MUST implement at least 2 priority levels for file messages, where priorities 0-4 - and 5-9 are treated as two distinct levels. The server MAY implement up to 10 priority - levels. - - - - - - The server MUST support both automatic and explicit acknowledgements on file content. - - - - - - - - - - - - - - - - - - - - - - - - This method requests a specific quality of service. The QoS can be specified for the current - session or for all sessions on the connection. The particular properties and semantics of a - qos method always depend on the content class semantics. Though the qos method could in - principle apply to both peers, it is currently meaningful only for the server. - - - - - - - - - The client can request that messages be sent in advance so that when the client finishes - processing a message, the following message is already held locally, rather than needing - to be sent within the session. Prefetching gives a performance improvement. This field - specifies the prefetch window size in octets. May be set to zero, meaning "no specific - limit". Note that other prefetch limits may still apply. The prefetch-size is ignored if - the no-ack option is set. - - - - - - Specifies a prefetch window in terms of whole messages. This is compatible with some file - API implementations. This field may be used in combination with the prefetch-size field; a - message will only be sent in advance if both prefetch windows (and those at the session - and connection level) allow it. The prefetch-count is ignored if the no-ack option is set. - - - - - The server MAY send less data in advance than allowed by the client's specified prefetch - windows but it MUST NOT send more. - - - - - - - By default the QoS settings apply to the current session only. If this field is set, they - are applied to the entire connection. - - - - - - - - - This method tells the client that the requested QoS levels could be handled by the server. - The requested QoS applies to all active consumers until a new QoS is defined. - - - - - - - - - - This method asks the server to start a "consumer", which is a transient request for messages - from a specific queue. Consumers last as long as the session they were created on, or until - the client cancels them. - - - - - The server SHOULD support at least 16 consumers per queue, unless the queue was declared - as private, and ideally, impose no limit except as defined by available resources. - - - - - - - - - - - The client MUST provide a valid access ticket giving "read" access rights to the realm - for the queue from which the message will be consumed. - - - - - - - Specifies the name of the queue to consume from. If the queue name is null, refers to the - current queue for the session, which is the last declared queue. - - - - - 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). - - - - - - - Specifies the identifier for the consumer. The consumer tag is local to a connection, so - two clients can use the same consumer tags. If this field is empty the server will - generate a unique tag. - - - - - The tag MUST NOT refer to an existing consumer. If the client attempts to create two - consumers with the same non-empty tag the server MUST raise a connection exception with - reply code 530 (not allowed). - - - - - - - - - - - Request exclusive consumer access, meaning only this consumer can access the queue. - - - - - If the server cannot grant exclusive access to the queue when asked, - because there are - other consumers active - it MUST raise a channel exception with return code 405 - (resource locked). - - - - - - - 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. - - - - - - A set of filters for the consume. The syntax and semantics of these filters depends on the - providers implementation. - - - - - - - This method provides the client with a consumer tag which it MUST use in methods that work - with the consumer. - - - - - - - Holds the consumer tag specified by the client or provided by the server. - - - - - - - - - This method cancels a consumer. This does not affect already delivered messages, but it does - mean the server will not send any more messages for that consumer. - - - - - - - - - - - - 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. - - - - - - - - - - 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.). - - - - - - 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. - - - - - The sender MUST accurately fill the content-size field. Zero-length content is - permitted. - - - - - - - - - - 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. - - - - - - - - - - The amount of previously-staged content in octets. For a new message this will be zero. - - - - - The sender MUST start sending data from this octet offset in the message, counting from - zero. - - - - - - - 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. - - - - - - - - - - This method stages the message, sending the message content to the recipient from the octet - offset specified in the Open-Ok method. - - - - - - - - - - - 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. - - - - - - - - The client MUST provide a valid access ticket giving "passive" access rights to the - realm for the exchange and "write" access rights to the realm for the queue to which the - message will be published. - - - - - - - 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. - - - - - The server MUST accept a blank exchange name to mean the default exchange. - - - - - - 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. - - - - - - The exchange MAY refuse file content in which case it MUST respond with a reply code 540 - (not implemented) and raise a channel exception. - - - - - - - Specifies the routing key for the message. The routing key is used for routing messages - depending on the exchange configuration. - - - - - - This flag tells the server how to react if the message cannot be routed to a queue. If - this flag is set, the server will return an unroutable message with a Return method. If - this flag is zero, the server silently drops the message. - - - - - The server SHOULD implement the mandatory flag. - - - - - - - This flag tells the server how to react if the message cannot be routed to a queue - consumer immediately. If this flag is set, the server will return an undeliverable message - with a Return method. If this flag is zero, the server will queue the message, but with no - guarantee that it will ever be consumed. - - - - - The server SHOULD implement the immediate flag. - - - - - - - This is the staging identifier of the message to publish. The message must have been - staged. Note that a client can send the Publish method asynchronously without waiting for - staging to finish. - - - - - - - - - This method returns an undeliverable message that was published with the "immediate" flag - set, or an unroutable message published with the "mandatory" flag set. The reply code and - text provide information about the reason that the message was undeliverable. - - - - - - - - - - - Specifies the name of the exchange that the message was originally published to. - - - - - - Specifies the routing key name specified when the message was published. - - - - - - - - - This method delivers a staged file message to the client, via a consumer. In the - asynchronous message delivery model, the client starts a consumer using the Consume method, - then the server responds with Deliver methods as and when messages arrive for that consumer. - - - - - The server SHOULD track the number of times a message has been delivered to clients and - when a message is redelivered a certain number of times - e.g. 5 times - without being - acknowledged, the server SHOULD consider the message to be unprocessable (possibly causing - client applications to abort), and move the message to a dead letter queue. - - - - - - - - - - - - - - Specifies the name of the exchange that the message was originally published to. - - - - - - Specifies the routing key name specified when the message was published. - - - - - - This is the staging identifier of the message to deliver. The message must have been - staged. Note that a server can send the Deliver method asynchronously without waiting for - staging to finish. - - - - - - - - - This method acknowledges one or more messages delivered via the Deliver method. The client - can ask to confirm a single message or a set of messages up to and including a specific - message. - - - - - - - - - If set to 1, the delivery tag is treated as "up to and including", so that the client can - acknowledge multiple messages 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, - tells the server to acknowledge all outstanding messages. - - - - - The server MUST validate that a non-zero delivery-tag refers to an delivered message, - and raise a channel exception if this is not the case. - - - - - - - - - - This method allows a client to reject a message. It can be used to return untreatable - messages to their original queue. Note that file content is staged before delivery, so the - client will not use this method to interrupt delivery of a large message. - - - - - The server SHOULD interpret this method as meaning that the client is unable to process - the message at this time. - - - - - - A client MUST NOT use this method as a means of selecting messages to process. A rejected - message MAY be discarded or dead-lettered, not necessarily passed to another client. - - - - - - - - - - If this field is zero, the message will be discarded. If this bit is 1, the server will - attempt to requeue the message. - - - - - The server MUST NOT deliver the message to the same client within the context of the - current session. 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. - - - - - - - - - - - - The stream class provides methods that support multimedia streaming. The stream class uses the - following semantics: one message is one packet of data; delivery is unacknowledged and - unreliable; the consumer can specify quality of service parameters that the server can try to - adhere to; lower-priority messages may be discarded in favour of high priority messages. - - - - stream = C:QOS S:QOS-OK - / C:CONSUME S:CONSUME-OK - / C:CANCEL - / C:PUBLISH content - / S:RETURN - / S:DELIVER content - - - - - The server SHOULD discard stream messages on a priority basis if the queue size exceeds some - configured limit. - - - - - - The server MUST implement at least 2 priority levels for stream messages, where priorities - 0-4 and 5-9 are treated as two distinct levels. The server MAY implement up to 10 priority - levels. - - - - - - The server MUST implement automatic acknowledgements on stream content. That is, as soon as - a message is delivered to a client via a Deliver method, the server must remove it from the - queue. - - - - - - - - - - - - - - - - - - - This method requests a specific quality of service. The QoS can be specified for the current - session or for all sessions on the connection. The particular properties and semantics of a - qos method always depend on the content class semantics. Though the qos method could in - principle apply to both peers, it is currently meaningful only for the server. - - - - - - - - - The client can request that messages be sent in advance so that when the client finishes - processing a message, the following message is already held locally, rather than needing - to be sent within the session. Prefetching gives a performance improvement. This field - specifies the prefetch window size in octets. May be set to zero, meaning "no specific - limit". Note that other prefetch limits may still apply. - - - - - - Specifies a prefetch window in terms of whole messages. This field may be used in - combination with the prefetch-size field; a message will only be sent in advance if both - prefetch windows (and those at the session and connection level) allow it. - - - - - - Specifies a desired transfer rate in octets per second. This is usually determined by the - application that uses the streaming data. A value of zero means "no limit", i.e. as - rapidly as possible. - - - - - The server MAY ignore the prefetch values and consume rates, depending on the type of - stream and the ability of the server to queue and/or reply it. - - - - - - The server MAY drop low-priority messages in favour of high-priority messages. - - - - - - - By default the QoS settings apply to the current session only. If this field is set, they - are applied to the entire connection. - - - - - - - - - This method tells the client that the requested QoS levels could be handled by the server. - The requested QoS applies to all active consumers until a new QoS is defined. - - - - - - - - - - This method asks the server to start a "consumer", which is a transient request for messages - from a specific queue. Consumers last as long as the session they were created on, or until - the client cancels them. - - - - - The server SHOULD support at least 16 consumers per queue, unless the queue was declared - as private, and ideally, impose no limit except as defined by available resources. - - - - - - Streaming applications SHOULD use different sessions to select different streaming - resolutions. AMQP makes no provision for filtering and/or transforming streams except on - the basis of priority-based selective delivery of individual messages. - - - - - - - - - - - The client MUST provide a valid access ticket giving "read" access rights to the realm - for the queue from which the message will be consumed. - - - - - - - Specifies the name of the queue to consume from. If the queue name is null, refers to the - current queue for the session, which is the last declared queue. - - - - - 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). - - - - - - - Specifies the identifier for the consumer. The consumer tag is local to a connection, so - two clients can use the same consumer tags. If this field is empty the server will - generate a unique tag. - - - - - The tag MUST NOT refer to an existing consumer. If the client attempts to create two - consumers with the same non-empty tag the server MUST raise a connection exception with - reply code 530 (not allowed). - - - - - - - - - Request exclusive consumer access, meaning only this consumer can access the queue. - - - - - If the server cannot grant exclusive access to the queue when asked, - because there are - other consumers active - it MUST raise a channel exception with return code 405 - (resource locked). - - - - - - - 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. - - - - - - A set of filters for the consume. The syntax and semantics of these filters depends on the - providers implementation. - - - - - - - - - This method provides the client with a consumer tag which it may use in methods that work - with the consumer. - - - - - - - Holds the consumer tag specified by the client or provided by the server. - - - - - - - - - This method cancels a consumer. Since message delivery is asynchronous the client may - continue to receive messages for a short while after cancelling a consumer. It may process - or discard these as appropriate. - - - - - - - - - - - - This method publishes a message to a specific exchange. The message will be routed to queues - as defined by the exchange configuration and distributed to any active consumers as - appropriate. - - - - - - - - The client MUST provide a valid access ticket giving "passive" access rights to the - realm for the exchange and "write" access rights to the realm for the queue to which the - message will be published. - - - - - - - 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. - - - - - The server MUST accept a blank exchange name to mean the default exchange. - - - - - - 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. - - - - - - The exchange MAY refuse stream content in which case it MUST respond with a reply code - 540 (not implemented) and raise a channel exception. - - - - - - - Specifies the routing key for the message. The routing key is used for routing messages - depending on the exchange configuration. - - - - - - This flag tells the server how to react if the message cannot be routed to a queue. If - this flag is set, the server will return an unroutable message with a Return method. If - this flag is zero, the server silently drops the message. - - - - - The server SHOULD implement the mandatory flag. - - - - - - - This flag tells the server how to react if the message cannot be routed to a queue - consumer immediately. If this flag is set, the server will return an undeliverable message - with a Return method. If this flag is zero, the server will queue the message, but with no - guarantee that it will ever be consumed. - - - - - The server SHOULD implement the immediate flag. - - - - - - - - - - This method returns an undeliverable message that was published with the "immediate" flag - set, or an unroutable message published with the "mandatory" flag set. The reply code and - text provide information about the reason that the message was undeliverable. - - - - - - - - - - - Specifies the name of the exchange that the message was originally published to. - - - - - - Specifies the routing key name specified when the message was published. - - - - - - - - - This method delivers a message to the client, via a consumer. In the asynchronous message - delivery model, the client starts a consumer using the Consume method, then the server - responds with Deliver methods as and when messages arrive for that consumer. - - - - - - - - - - - Specifies the name of the exchange that the message was originally published to. - - - - - - Specifies the name of the queue that the message came from. Note that a single session can - start many consumers on different queues. - - - - - - - - - - - - Standard transactions provide so-called "1.5 phase commit". We can ensure that work is never - lost, but there is a chance of confirmations being lost, so that messages may be resent. - Applications that use standard transactions must be able to detect and ignore duplicate - messages. - - - - tx = C:SELECT - / C:COMMIT - / C:ROLLBACK - - - - - An client using standard transactions SHOULD be able to track all messages received within a - reasonable period, and thus detect and reject duplicates of the same message. It SHOULD NOT - pass these to the application layer. - - - - - - - - - - - This method sets the session to use standard transactions. The client must use this method - at least once on a session before using the Commit or Rollback methods. - - - - - - - - - This method commits all messages published and acknowledged in the current transaction. A - new transaction starts immediately after a commit. - - - - - - - - - This method abandons all messages published and acknowledged in the current transaction. A - new transaction starts immediately after a rollback. - - - - - - - - - - - - - This class is part of the X-Open XA distributed transaction protocol support. It allows a - session to be selected for use with distributed transactions and the transactional boundaries - for work on that session to be demarcated. - - - - dtx-demarcation = C:SELECT *demarcation - demarcation = C:START C:END - - - - - Access-tickets are propagated with XA association methods with the aim of restricting which - users are allowed to control which transactions. The server MAY restrict transaction - association to a particular identity. - - - - - - Enabling XA transaction support on a session implies that the server MUST manage - transactions demarcated by start-end blocks. That is to say that on this XA-enabled session, - work undergone within transactional blocks is performed on behalf a transaction branch - whereas work performed outside of transactional blocks is NOT transactional. - - - - - - - - - - - - This method sets the session to use distributed transactions. The client must use this - method at least once on a session before using XA demarcation operations. - - - - - - - - - - This method is called when messages should be produced and consumed on behalf a transaction - branch identified by xid. - - - - - If the method is invoked in an improper context (see class grammar) then the server MUST - raise a channel exception with reply code 503 (command invalid) - - - - - - If neither join nor resume is specified is specified and the transaction branch specified - by xid has previously been seen then the server MUST raise a channel exception with reply - code 530 (not allowed). - - - - - - If join and resume are specified then the server MUST raise a channel exception with reply - code 503 (command invalid). - - - - - - - - Access-ticket granted by the server for a specific realm. - - - - - The client MUST provide a valid access ticket giving "active" access rights to all the - realms touched by this transaction. - - - - - - - - - Specifies the xid of the transaction branch to be started. - - - - - If xid is already known by the broker then the server MUST raise a channel exception - with reply code 530 (not allowed). - - - - - - - - - Indicate whether this is joining an already associated xid. Indicate that the start - applies to joining a transaction previously seen. - - - - - If the broker does not support join the server MUST raise a channel exception with reply - code 540 (not implemented). - - - - - - - - - Indicate that the start applies to resuming a suspended transaction branch specified. - - - - - - - - - This confirms to the client that the transaction branch is started or specify the error - condition. - - - - - The value of this field may be one of the following constants: - - xa-ok: Normal execution. - - xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified - reason. - - xa-rbtimeout: The work represented by this transaction branch took too long. - - - - - - - - - - - - - This method is called when the work done on behalf a transaction branch finishes or needs to - be suspended. - - - - - If the method is invoked in an improper context (see class grammar) then the server MUST - raise a channel exception with reply code 503 (command invalid). - - - - - - If suspend and fail are specified then the server MUST raise a channel exception with - reply code 503 (command invalid). - - - - - - If an error occurs in ending the transaction branch then the server MUST raise a channel - exception with reply code 541 (internal error). - - - - - - If neither fail nor suspend are specified then the portion of work has completed - successfully. - - - - - - When a session is closed then the currently associated transaction branches MUST be marked - rollback-only. - - - - - - - - Access-ticket granted by the server for a specific realm. - - - - - The client MUST provide a valid access ticket giving "active" access rights to all the - realms touched by this transaction. - - - - - - - - - Specifies the xid of the transaction branch to be ended. - - - - - The channel MUST be currently associated with the given xid (through an earlier start - call with the same xid). - - - - - - - - - If set, indicates that this portion of work has failed; otherwise this portion of work has - completed successfully. - - - - - An implementation MAY elect to roll a transaction back if this failure notification is - recieved. Should an implementation elect to implement this behaviour, and this bit is - set, then then the transaction branch SHOULD be marked as rollback-only and the end - result SHOULD have the xa-rbrollback status set. - - - - - - - - - Indicates that the transaction branch is temporarily suspended in an incomplete state. - - - - - The transaction context is in a suspended state and must be resumed via the start method - with resume specified. - - - - - - - - - - This method confirms to the client that the transaction branch is ended or specify the - error condition. - - - - - The value of this field may be one of the following constants: - - xa-ok: Normal execution. - - xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified - reason. If an implementation chooses to implement rollback-on-failure behaviour, then - this value should be selected if the dtx-demarcation.end.fail bit was set. - - xa-rbtimeout: The work represented by this transaction branch took too long. - - - - - - - - - - - - - - - - This class is part of the X-Open XA distributed transaction protocol support. It allows the - transaction manager to coordinate transaction outcomes. - - - - dtx-coordination = *coordination - coordination = command - / outcome - / recovery - command = C:SET-TIMEOUT - / C:GET-TIMEOUT - outcome = one-phase-commit - / one-phase-rollback - / two-phase-commit - / two-phase-rollback - one-phase-commit = C:COMMIT - one-phase-rollback = C:ROLLBACK - two-phase-commit = C:PREPARE C:COMMIT - two-phase-rollback = C:PREPARE C:ROLLBACK - recovery = C:RECOVER *recovery-outcome - recovery-outcome = one-phase-commit - / one-phase-rollback - / C:FORGET - - - - - Access-tickets are propagated with XA demarcation methods with the aim of restricting which - users are allowed to control which transactions. The server MAY restrict transaction - coordination to a particular identity. - - - - - - - - - - - Commit the work done on behalf a transaction branch. This method commits the work associated - with xid. Any produced messages are made available and any consumed messages are discarded. - - - - - If an error occurs in committing the transaction branch then the server MUST raise a - channel exception with reply code 541 (internal error) - - - - - - If the method is invoked in an improper context (see class grammar) then the server MUST - raise a channel exception with reply code 503 (command invalid) - - - - - - - - Access-ticket granted by the server for a specific realm. - - - - - The client MUST provide a valid access ticket giving "active" access rights to all the - realms touched by this transaction. - - - - - - - - - Specifies the xid of the transaction branch to be committed. - - - - - If xid is unknown (the transaction branch has not been started or has already been - ended) then the server MUST raise a channel exception with reply code 404 (not found). - - - - - - If this method is called when xid is still associated with a session then the server - MUST raise a channel exception with reply code 503 (command invalid) - - - - - - - - - When set then one-phase commit optimization is used. - - - - - This bit MUST be set if a commit is sent without a preceding prepare. - - - - - - This bit MUST NOT be set if a preceding prepare has been sent. - - - - - - - - - - This confirms to the client that the transaction branch is committed or specify the - error condition. - - - - - The value of this field may be one of the following constants: - - xa-ok: Normal execution - - xa-heurhaz: Due to some failure, the work done on behalf of the specified transaction - branch may have been heuristically completed. - - xa-heurcom: Due to a heuristic decision, the work done on behalf of the specified - transaction branch was committed. - - xa-heurrb: Due to a heuristic decision, the work done on behalf of the specified - transaction branch was rolled back. - - xa-heurmix: Due to a heuristic decision, the work done on behalf of the specified - transaction branch was partially committed and partially rolled back. - - xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified - reason. - - xa-rbtimeout: The work represented by this transaction branch took too long. - - - - - - - - - - - - This method is called to forget about a heuristically completed transaction branch. - - - - - If an error occurs in forgetting the transaction branch then the server MUST raise a - channel exception with reply code 541 (internal error) - - - - - - If the method is invoked in an improper context (see class grammar) then the server MUST - raise a channel exception with reply code 503 (command invalid) - - - - - - - - Access-ticket granted by the server for a specific realm. - - - - - The client MUST provide a valid access ticket giving "active" access rights to all the - realms touched by this transaction. - - - - - - - - - Specifies the xid of the transaction branch to be forgotten. - - - - - If xid is unknown (the transaction branch has not been started or has already been - ended) then the server MUST raise a channel exception with reply code 404 (not found). - - - - - - If this method is called when xid is still associated with a session then the server - MUST raise a channel exception with reply code 503 (command invalid). - - - - - - - - - - - - This method obtains the current transaction timeout value in seconds. If set-timeout was not - used prior to invoking this method, the return value is the default timeout; otherwise, the - value used in the previous set-timeout call is returned. - - - - - If an error occurs in setting the transaction timeout then the server MUST raise a channel - exception with reply code 541 (internal error). - - - - - - - - Specifies the xid of the transaction branch for getting the timeout. - - - - - If xid is unknown (the transaction branch has not been started or has already been - ended) then the server MUST raise a channel exception with reply code 404 (not found). - - - - - - - - - - Returns the value of the timeout last specified through set-timeout. - - - - - The current transaction timeout value in seconds. - - - - - - - - - - - - This method prepares for commitment any message produced or consumed on behalf of xid. - - - - - If an error occurs in preparing the transaction branch then the server MUST raise a - channel exception with reply code 541 (internal error). The specified xid may or may not - have been prepared. - - - - - - If the method is invoked in an improper context (see class grammar) then the server MUST - raise a channel exception with reply code 503 (command invalid) - - - - - - Once this method successfully returns it is guaranteed that the transaction branch may be - either committed or rolled back regardless of failures. - - - - - - The knowledge of xid cannot be erased before commit or rollback complete the branch. - - - - - - - - Access-ticket granted by the server for a specific realm. - - - - - The client MUST provide a valid access ticket giving "active" access rights to all the - realms touched by this transaction. - - - - - - - - - Specifies the xid of the transaction branch that can be prepared. - - - - - If xid is unknown (the transaction branch has not been started or has already been - ended) then the server MUST raise a channel exception with reply code 404 (not found). - - - - - - If this method is called when xid is still associated with a session then the server - MUST raise a channel exception with reply code 503 (command invalid) - - - - - - - - - - This method confirms to the client that the transaction branch is prepared or specify the - error condition. - - - - - The value of this field may be one of the following constants: - - xa-ok: Normal execution. - - xa-rdonly: The transaction branch was read-only and has been committed. - - xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified - reason. - - xa-rbtimeout: The work represented by this transaction branch took too long. - - - - - - - - - - - - - This method is called to obtain a list of transaction branches that are in a prepared or - heuristically completed state. - - - - - If an error occurs in recovering then the server MUST raise a channel exception with reply - code 541 (internal error) - - - - - - If this endscan is used in conjunction with startscan then a single call starts and then - ends a scan. - - - - - - If none of endscan and startscan are set then a recovery scan must already be started - otherwise the server MUST raise a channel exception with reply code 503 (command invalid) - - - - - - - - Access-ticket granted by the server for a specific realm. - - - - - The client MUST provide a valid access ticket giving "active" access rights to all the - realms touched by this transaction. - - - - - - - - - Indicates that recovery scan should start. - - - - - If a recovery scan is already open, the effect is as if the recovery scan were ended and - then restarted. - - - - - - - - - Indicates that the recovery scan should end after returning the xids. - - - - - - - - Returns to the client a table with single item that is a sequence of transaction xids that - are in a prepared or heuristically completed state. - - - - - Table containing the sequence of xids to be recovered (xids that are in a prepared or - heuristically completed state). - - - - - The field table must contain a field called 'xids' of type sequence of longstrs - representing the xids that are in a prepared or heuristically completed state. - - - - - - - - - - - - - - This method rolls back the work associated with xid. Any produced messages are discarded and - any consumed messages are re-enqueued. - - - - - If an error occurs in rolling back the transaction branch then the server MUST raise a - channel exception with reply code 541 (internal error) - - - - - - If the method is invoked in an improper context (see class grammar) then the server MUST - raise a channel exception with reply code 503 (command invalid) - - - - - - - - Access-ticket granted by the server for a specific realm. - - - - - The client MUST provide a valid access ticket giving "active" access rights to all the - realms touched by this transaction. - - - - - - - - - Specifies the xid of the transaction branch that can be rolled back. - - - - - If xid is unknown (the transaction branch has not been started or has already been - ended) then the server MUST raise a channel exception with reply code 404 (not found). - - - - - - If this method is called when xid is still associated with a session then the server - MUST raise a channel exception with reply code 503 (command invalid) - - - - - - - - - - This method confirms to the client that the transaction branch is rolled back or specify the - error condition. - - - - - The value of this field may be one of the following constants: - - xa-ok: Normal execution - - xa-heurhaz: Due to some failure, the work done on behalf of the specified transaction - branch may have been heuristically completed. - - xa-heurcom: Due to a heuristic decision, the work done on behalf of the specified - transaction branch was committed. - - xa-heurrb: Due to a heuristic decision, the work done on behalf of the specified - transaction branch was rolled back. - - xa-heurmix: Due to a heuristic decision, the work done on behalf of the specified - transaction branch was partially committed and partially rolled back. - - xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified - reason. - - xa-rbtimeout: The work represented by this transaction branch took too long. - - - - - - - - - - - - Sets the specified transaction branch timeout value in seconds. - - - - - If an error occurs in setting the transaction timeout then the server MUST raise a channel - exception with reply code 541 (internal error) - - - - - - Once set, this timeout value is effective until this method is reinvoked with a different - value. - - - - - - A value of zero resets the timeout value to the default value. - - - - - - - - Access-ticket granted by the server for a specific realm. - - - - - The client MUST provide a valid access ticket giving "active" access rights to all the - realms touched by this transaction. - - - - - - - - - Specifies the xid of the transaction branch for setting the timeout. - - - - - If xid is unknown (the transaction branch has not been started or has already been - ended) then the server MUST raise a channel exception with reply code 404 (not found). - - - - - - - - - The transaction timeout value in seconds. - - - - - - - - - - - - - The tunnel methods are used to send blocks of binary data - which can be serialised AMQP - methods or other protocol frames - between AMQP peers. - - - - tunnel = C:REQUEST - / S:REQUEST - - - - - - - - - - - - - - - - This method tunnels a block of binary data, which can be an encoded AMQP method or other - data. The binary data is sent as the content for the Tunnel.Request method. - - - - - - - This field table holds arbitrary meta-data that the sender needs to pass to the recipient. - - - - - - - - - - - The message class provides methods that support an industry-standard messaging model. - - - - message = C:QOS - / C:CONSUME - / C:CANCEL - / C:TRANSFER [ S:REJECT ] - / S:TRANSFER [ C:REJECT ] - / C:GET [ S:EMPTY ] - / C:RECOVER - / C:OPEN - / S:OPEN - / C:APPEND - / S:APPEND - / C:CLOSE - / S:CLOSE - / C:CHECKPOINT - / S:CHECKPOINT - / C:RESUME S:OFFSET - / S:RESUME C:OFFSET - - - - - The server SHOULD respect the persistent property of messages and SHOULD make a best-effort - to hold persistent mess ages on a reliable storage mechanism. - - - 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. - - - - - - The server MUST NOT discard a persistent message in case of a queue overflow. - - - Create a queue overflow situation with persistent messages and verify that messages do not - get lost (presumably the server will write them to disk). - - - - - - The server MAY use the Session.Flow method to slow or stop a message publisher when - necessary. - - - Create a queue overflow situation with non-persistent messages and verify whether the server - responds with Session.Flow or not. Repeat with persistent messages. - - - - - - The server MAY overflow non-persistent messages to persistent storage. - - - - - - The server MAY discard or dead-letter non-persistent messages on a priority basis if the - queue size exceeds some configured limit. - - - - - - The server MUST implement at least 2 priority levels for messages, where priorities 0-4 and - 5-9 are treated as two distinct levels. - - - 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. - - - - - - The server MAY implement up to 10 priority levels. - - - Send a number of messages with mixed priorities to a queue, so that all priority values from - 0 to 9 are exercised. A good scenario would be ten messages in low-to-high priority. Consume - from queue and verify how many priority levels emerge. - - - - - - The server MUST deliver messages of the same priority in order irrespective of their - individual persistence. - - - Send a set of messages with the same priority but different persistence settings to a queue. - Consume and verify that messages arrive in same order as originally published. - - - - - - The server MUST support automatic acknowledgements on messages, i.e. consumers with the - no-ack field set to FALSE. - - - Create a queue and a consumer using automatic acknowledgements. Publish a set of messages to - the queue. Consume the messages and verify that all messages are received. - - - - - - The server MUST support explicit acknowledgements on messages, i.e. consumers with the - no-ack field set to TRUE. - - - Create a queue and a consumer using explicit acknowledgements. Publish a set of messages to - the queue. Consume the messages but acknowledge only half of them. Disconnect and reconnect, - and consume from the queue. Verify that the remaining messages are received. - - - - - - - - - - - This method transfers a message between two peers. When a client uses this method to publish - a message to a broker, the destination identifies a specific exchange. The message will then - be routed to queues as defined by the exchange configuration and distributed to any active - subscriptions when the transaction, if any, is committed. - - The client may initiate transfers from the broker by starting a subscription using the - subscribe method and passing in a destination, then the broker responds with transfer - methods to the specified destination as and when messages arrive in the subscribed queue. - - - - - - - - - The client MUST provide a valid access ticket giving "passive" access rights to the - realm for the exchange and "write" access rights to the realm for the queue to which the - message will be published. - - - - - - - Specifies the destination to which the message is to be transferred. The destination can - be empty, meaning the default exchange or subscription. If the destination is specified, - and that exchange or subscription does not exist, the peer must raise a channel exception. - - - - - The server MUST accept a blank destination to mean the default exchange. - - - - - - If the destination refers to an internal exchange, the server MUST raise a channel - exception with a reply code 403 (access refused). - - - - - - A destination MAY refuse message content in which case it MUST raise a channel exception - with reply code 540 (not implemented). - - - - - - - - - - - - - Indicates that the message transfers are un-processable in some way. A message may be - rejected for a number of reasons. A server may reject a message if it is unroutable. A - client may reject a message if it is invalid. - - - - - When a client rejects a message, the server MUST deliver that message to the - alternate-exchange on the queue from which it was delivered. If no alternate-exchange is - defined for that queue the broker MAY discard the message. - - - - - - The recipient MUST have acquired a message in order to reject it. If the message is not - acquired any reject MUST be ignored. - - - - - - - - - - - - - - - - Acquires previously transferred messages for consumption. The acquired ids (if any) are - sent via message.acquired. - - - - - - - - - One of: - - any (0): acquire any available messages for consumption - - all (1): only acquire messages if all are available for consumption - - - - - - - - - Identifies a set of previously transferred messages now available for consumption. - - - - - - - - - - - - Release previously transferred messages that have been acquired for consumption (whether - implicitly or explicitly). Released messages will be available for acquisition by other - consumers. The order of released messages may be lost. - - - - - - - - - - - - - This method asks the server to start a "subscription", which is a transient request for - messages from a specific queue. Subscriptions last as long as the session they were created - on, or until the client cancels them. - - - - - The server SHOULD support at least 16 subscriptions per queue, and ideally, impose no - limit except as defined by available resources. - - - Create a queue and create subscriptions on that queue until the server closes the - connection. Verify that the number of subscriptions created was at least sixteen and - report the total number. - - - - - - - - - The client MUST provide a valid access ticket giving "read" access rights to the realm - for the subscribed queue. - - - Attempt to create a subscription with an invalid (non-zero) access ticket. - - - - - - - Specifies the name of the subscribed queue. - - - - - - Specifies the destination for the subscription. The destination is local to a connection, - so two clients can use the same destination. - - - - - The client MUST NOT specify a destination that refers to an existing subscription. - - - Attempt to create two subscriptions with the same non-empty destination. - - - - - - The destination is valid only within the session from which the subscription was - created. i.e. A client MUST NOT create a subscription in one session and then use it in - another. - - - Attempt to create a subscription in one session, then use in another session, in which - subscriptions have also been created (to test that the server uses unique destinations). - - - - - - - If the no-local field is set the server will not send messages to the connection that - published them. - - - - - - The default confirm-mode for this subscription. - - - - - - The default acquire-mode for this subscription. - - - - - - Request exclusive subscription access, meaning only this subscription can access the queue. - - - - - The client MUST NOT gain exclusive access to a queue that already has active subscriptions. - - - Open two connections to a server, and in one connection create a shared (non-exclusive) - queue and then subscribe to the queue. In the second connection attempt to subscribe to - the same queue using the exclusive option. - - - - - - - A set of filters for the subscription. The syntax and semantics of these filters depends - on the providers implementation. - - - - - - - - - This method cancels a consumer. This does not affect already delivered messages, but it does - mean the server will not send any more messages for that consumer. The client may receive an - arbitrary number of messages in between sending the cancel method and receiving the - notification of completion of the cancel command. - - - - - If the queue does not exist the server MUST ignore the cancel method, so long as the - consumer tag is valid for that session. - - - - - - - - - - - - - This method provides a direct access to the messages in a queue using a synchronous dialogue - that is designed for specific types of application where synchronous functionality is more - important than performance. - - - - - - - - - - The client MUST provide a valid access ticket giving "read" access rights to the realm - for the queue from which the message will be consumed. - - - - - - - Specifies the name of the queue to consume from. If the queue name is null, refers to the - current queue for the session, which is the last declared queue. - - - - 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). - - - - - - - On normal completion of the get request (i.e. a response of ok). A message will be - transferred to the supplied destination. - - - - - - - - - - - This method asks the broker to redeliver all unacknowledged messages on a specified session. - Zero or more messages may be redelivered. This method is only allowed on non-transacted - sessions. - - - - - The server MUST set the redelivered flag on all messages that are resent. - - - - - - The server MUST raise a channel exception if this is called on a transacted session. - - - - - - - - If this field is zero, the message will be redelivered to the original recipient. If this - bit is 1, the server will attempt to requeue the message, potentially then delivering it - to an alternative subscriber. - - - - - - - - - This method creates a reference. A references provides a means to send a message body into a - temporary area at the recipient end and then deliver the message by referring to this - temporary area. This is how the protocol handles large message transfers. - - The scope of a ref is defined to be between calls to open (or resume) and close. Between - these points it is valid for a ref to be used from any content data type, and so the - receiver must hold onto its contents. Should the session be closed when a ref is still in - scope, the receiver may discard its contents (unless it is checkpointed). A ref that is in - scope is considered open. - - - - - - - - - The recipient MUST generate an error if the reference is currently open (in scope). - - - - - - - - - - This method signals the recipient that no more data will be appended to the reference. - - - - - A recipient MUST NOT acknowledge a message until its reference is closed (not in scope). - - - - - - - - - - The recipient MUST generate an error if the reference was not previously open (in - scope). - - - - - - - - - This method appends data to a reference. - - - - - - - - The recipient MUST generate an error if the reference is not open (not in scope). - - - - - - - - - - - - This method provides a means to checkpoint large message transfer. The sender may ask the - recipient to checkpoint the contents of a reference using the supplied identifier. The - sender may then resume the transfer at a later point. It is at the discretion of the - recipient how much data to save with the checkpoint, and the sender MUST honour the offset - returned by the resume method. - - - - - - - - - The recipient MUST generate an error if the reference is not open (not in scope). - - - - - - - This is the checkpoint identifier. This is an arbitrary string chosen by the sender. For - checkpointing to work correctly the sender must use the same checkpoint identifier when - resuming the message. A good choice for the checkpoint identifier would be the SHA1 hash - of the message properties data (including the original filename, revised time, etc.). - - - - - - - - - This method resumes a reference from the last checkpoint. A reference is considered to be - open (in scope) after a resume even though it will not have been opened via the open method - during this session. - - - - - - - - - - - The recipient MUST generate an error if the reference is currently open (in scope). - - - - - - - - - - - - This method requests a specific quality of service. The QoS can be specified for the current - session or for all sessions on the connection. The particular properties and semantics of a - qos method always depend on the content class semantics. Though the qos method could in - principle apply to both peers, it is currently meaningful only for the server. - - - - - - - The client can request that messages be sent in advance so that when the client finishes - processing a message, the following message is already held locally, rather than needing - to be sent within the session. Prefetching gives a performance improvement. This field - specifies the prefetch window size in octets. The server will send a message in advance if - it is equal to or smaller in size than the available prefetch size (and also falls into - other prefetch limits). May be set to zero, meaning "no specific limit", although other - prefetch limits may still apply. The prefetch-size is ignored if the no-ack option is set. - - - - The server MUST ignore this setting when the client is not processing any messages - - i.e. the prefetch size does not limit the transfer of single messages to a client, only - the sending in advance of more messages while the client still has one or more - unacknowledged messages. - - - Define a QoS prefetch-size limit and send a single message that exceeds that limit. - Verify that the message arrives correctly. - - - - - - - Specifies a prefetch window in terms of whole messages. This field may be used in - combination with the prefetch-size field; a message will only be sent in advance if both - prefetch windows (and those at the session and connection level) allow it. The - prefetch-count is ignored if the no-ack option is set. - - - - The server may send less data in advance than allowed by the client's specified prefetch - windows but it MUST NOT send more. - - - Define a QoS prefetch-size limit and a prefetch-count limit greater than one. Send - multiple messages that exceed the prefetch size. Verify that no more than one message - arrives at once. - - - - - - - By default the QoS settings apply to the current session only. If this field is set, they - are applied to the entire connection. - - - - - - - - - Sets the mode of flow control used for a given destination. - - With credit based flow control, the sender of messages continually maintains its current - credit balance with the recipient. The credit balance consists of two values, a message - count, and a byte count. Whenever message data is sent, both counts must be decremented. - If either value reaches zero, the flow of message data must stop. Additional credit is - received via the message.flow method. - - The sender MUST NOT send partial framesets. This means that if there is not enough byte - credit available to send a complete message, the sender must either wait or use chunked - transfer to send the first part of the message data in a complete frameset. - - Window based flow control is identical to credit based flow control, however message - acknowledgment implicitly grants a single unit of message credit, and the size of the - message in byte credits for each acknowledged message. - - - - - The byte count is decremented by the payload size of each transmitted frame with - segment type header or body appearing within a message.transfer command. Note that - the payload size is the frame size less the frame header size (frame-size - 12). - - - - - - Mode switching may only occur if both outstanding credit balances are zero. There are - three ways for a recipient of messages to be sure that the sender 's credit balance is - zero: - - 1) The recipient may send a message.stop command to the sender. When the recipient - receives confirmation of completion for the message.stop command, it knows that the - sender's credit is zero. - - 2) The recipient may perform the same steps described in (1) with the message.flush - command substituted for the message.stop command. - - 3) Immediately after receiving a message.consume, the credit for that destination - defaults to zero. - - - - - - - - - - One of: - - credit (0): choose credit based flow control - - window (1): choose window based flow control - - - - - - - - - This method controls the flow of message data to a given destination. It is used by the - recipient of messages to dynamically match the incoming rate of message flow to its - processing or forwarding capacity. Upon receipt of this method, the sender must add "value" - number of the specified unit to the available credit balance for the specified destination. - A value of (0xFFFFFFFF) indicates an infinite amount of credit. This disables any limit for - the given unit until the credit balance is zeroed with message.stop or message.flush. - - - - - - - - - - - Specifies the unit of credit balance. - - One of: - - message (0) - - byte (1) - - - - - A value of (0xFFFFFFFF) indicates an infinite amount of credit. - - - - - - - - - Forces the sender to exhaust his credit supply. The sender's credit will always be zero when - this method completes. The message does not complete until all the message transfers occur. - - - - - - - - - - - - On receipt of this method, a producer of messages MUST set his credit to zero for the given - destination. This obeys the generic semantics of command completion, i.e. when confirmation - is issued credit MUST be zero and no further messages will be sent until such a time as - further credit is received. - - - - - - - - - - - - - Signals that a queue does not contain any messages; usually sent in response to the get - method. - - - - - - - - - - - Returns the data offset into a reference body; usually sent in response to resume method. - - - - - - - - Offset in bytes into message body data. - - - - - - - - - - - This is a utility class for querying and exchange about its bindings to queues. - - - - - - - - - - This method is used to request information on the bindings to a particular exchange. - - - - - - - - The client MUST provide a valid access ticket giving "passive" access rights to the - exchange's access realm. - - - - - - - The name of the exchange for which binding information is being requested. If not - specified explicitly the default exchange is implied. - - - - - - If populated then determine whether the given queue is bound to the exchange. - - - - - - If populated defines the routing key of the binding of interest, if not populated the - request will ignore the routing key on bindings when searching for a match. - - - - - - If populated defines the arguments of the binding of interest if not populated the request - will ignore the arguments on bindings when searching for a match - - - - - - - This method is used in response to a query and conveys information on the bindings to a - particular exchange. - - - - - If set, the exchange for which information was requested is not known. - - - - - - If set, the queue specified is not known. - - - - - - A bit which if set indicates that no binding was found from the specified exchange to the - specified queue. - - - - - - A bit which if set indicates that no binding was found from the specified exchange with - the specified routing key. - - - - - - A bit which if set indicates that no binding was found from the specified exchange with - the specified arguments. - - - - - - - - - - - - - This class allows for efficiently communicating information about completion of processing. - - - - - - - - - - Requests notification of all currently complete commands. The server should issue an - execution.complete at the earliest possible opportunity. - - - - - - - - - - - Signals completion of all commands such that command-id <= cumulative-execution-mark, or - command-id is in the set defined by ranged-execution-set. This can be sent spontaneously, - in response to a execution.flush, or as requested by use of the sync bit. - - - - - - - In order to ensure a canonical wire representation, the value cumulative-execution-mark + - 1 must not be covered by the ranged-execution-set. - - - - - - - - - The low-water mark for executed command-ids. All ids below this mark have been executed; - above this mark, there are gaps containing unexecuted command ids (i.e. discontinuous). By - definition, the first id above this mark (if it exists) is an unexecuted command-id. - - - - - - This set contains a sequence of discontinuous executed command-ids above the low-water - mark (i.e. above the first gap of unexecuted command ids). - - - - - - - - - This command may be used when it is desirable to send a command that has no effect. This - situation can occur after issuing a number of commands with sync=False. If, after issuing - the commands, a peer wishes to receive confirmation of completion, the peer can do so by - sending an execution.noop command with sync=True. - - - - - - - - - - - This method carries data resulting from the execution of a command. - - - - - - - - - - - - - - Requests notification (via execution.complete) when all commands issued prior to the sync - control are complete. If the recipient of this control has already notified the - sender that said commands are complete, it may safely ignore the control. - - - - - - - - - - - - - - - The channel class provides methods for a client to establish a channel to a - server and for both peers to operate the channel thereafter. - - - - channel = open-channel *use-channel close-channel - open-channel = C:OPEN S:OPEN-OK - / C:RESUME S:OK - use-channel = C:FLOW S:FLOW-OK - / S:FLOW C:FLOW-OK - / S:PING C:OK - / C:PONG S:OK - / C:PING S:OK - / S:PONG C:OK - / functional-class - close-channel = C:CLOSE S:CLOSE-OK - / S:CLOSE C:CLOSE-OK - - - - - - - - - - This method opens a channel to the server. - - - - The client MUST NOT use this method on an already-opened channel. - - - Client opens a channel and then reopens the same channel. - - - - - - - Configures out-of-band transfers on this channel. The syntax and meaning of this - field will be formally defined at a later date. - - - - - - - - This method signals to the client that the channel is ready for use. - - - - - - - - - This method asks the peer to pause or restart the flow of content data. This is a - simple flow-control mechanism that a peer can use to avoid overflowing its queues or - otherwise finding itself receiving more messages than it can process. Note that this - method is not intended for window control. The peer that receives a disable flow - method should finish sending the current content frame, if any, then pause. - - - - - When a new channel is opened, it is active (flow is active). Some applications - assume that channels are inactive until started. To emulate this behaviour a - client MAY open the channel, then pause it. - - - - - - When sending content frames, a peer SHOULD monitor the channel for incoming - methods and respond to a Channel.Flow as rapidly as possible. - - - - - - A peer MAY use the Channel.Flow method to throttle incoming content data for - internal reasons, for example, when exchanging data over a slower connection. - - - - - - The peer that requests a Channel.Flow method MAY disconnect and/or ban a peer - that does not respect the request. This is to prevent badly-behaved clients - from overwhelming a broker. - - - - - - - - - - - If 1, the peer starts sending content frames. If 0, the peer stops sending - content frames. - - - - - - - Confirms to the peer that a flow command was received and processed. - - - - - - Confirms the setting of the processed flow method: 1 means the peer will start - sending or continue to send content frames; 0 means it will not. - - - - - - - - - This method indicates that the sender wants to close the channel. This may be due to - internal conditions (e.g. a forced shut-down) or due to an error handling a specific - method, i.e. an exception. When a close is due to an exception, the sender provides - the class and method id of the method which caused the exception. - - - - - - After sending this method any received method except the Close-OK method MUST - be discarded. - - - - - - - - - - - - - When the close is provoked by a method exception, this is the class of the - method. - - - - - - When the close is provoked by a method exception, this is the ID of the method. - - - - - - - This method confirms a Channel.Close method and tells the recipient that it is safe - to release resources for the channel. - - - - A peer that detects a socket closure without having received a Channel.Close-Ok - handshake method SHOULD log the error. - - - - - - - - diff --git a/qpid/specs/amqp.0-10-preview.xml b/qpid/specs/amqp.0-10-preview.xml index 7d81b29302..a743025f65 100644 --- a/qpid/specs/amqp.0-10-preview.xml +++ b/qpid/specs/amqp.0-10-preview.xml @@ -2068,7 +2068,9 @@ + @@ -6926,7 +6928,7 @@ - + Signals that a queue does not contain any messages; usually sent in response to the get method. @@ -6938,7 +6940,7 @@ - + Returns the data offset into a reference body; usually sent in response to resume method. -- cgit v1.2.1