From 5618f848c533039ac0dbdcced2ba762850c201bd Mon Sep 17 00:00:00 2001 From: Tomas Doran Date: Thu, 16 Feb 2012 10:43:34 +0000 Subject: [PATCH 1/9] Does not require MX::AttributeHelpers any longer --- Makefile.PL | 1 - 1 file changed, 1 deletion(-) diff --git a/Makefile.PL b/Makefile.PL index cb91605..1f1e599 100644 --- a/Makefile.PL +++ b/Makefile.PL @@ -4,7 +4,6 @@ name 'Net-RabbitFoot'; all_from 'lib/Net/RabbitFoot.pm'; requires 'Moose'; -requires 'MooseX::AttributeHelpers'; requires 'MooseX::App::Cmd'; requires 'MooseX::ConfigFromFile'; requires 'Config::Any'; From 9029a8b4d7bd4601c1234b02404d11b2fb76f0a8 Mon Sep 17 00:00:00 2001 From: Tomas Doran Date: Thu, 16 Feb 2012 10:45:17 +0000 Subject: [PATCH 2/9] Ignore MYMETA files --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index e2a4cfe..5a5ef1b 100644 --- a/.gitignore +++ b/.gitignore @@ -1,3 +1,4 @@ +MYMETA.* cover_db META.yml Makefile From 45ec1130d67757338fb3eaf2e10b1fc939dc6753 Mon Sep 17 00:00:00 2001 From: Tomas Doran Date: Tue, 21 Aug 2012 17:16:18 +0200 Subject: [PATCH 3/9] Fix things that are in idle handlers --- lib/Net/RabbitFoot/Cmd/Role/Command.pm | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/lib/Net/RabbitFoot/Cmd/Role/Command.pm b/lib/Net/RabbitFoot/Cmd/Role/Command.pm index e36e750..9e03d94 100644 --- a/lib/Net/RabbitFoot/Cmd/Role/Command.pm +++ b/lib/Net/RabbitFoot/Cmd/Role/Command.pm @@ -4,6 +4,7 @@ use FindBin; use Net::RabbitFoot; use Moose::Role; +use Carp qw/ confess /; requires qw(_run); has spec => ( @@ -123,9 +124,10 @@ sub execute { (map {$_ => $self->$_} qw(host port user pass vhost)), timeout => 5, on_close => sub { + my $reply = shift; my $w; $w = AnyEvent->idle(cb => sub { undef $w; - $self->_close(shift); + $self->_close($reply); $rf_closed->send; }); }, @@ -134,9 +136,10 @@ sub execute { my $ch_closed = AnyEvent->condvar; my $ch = $rf->open_channel( on_close => sub { + my $reply = shift; my $w; $w = AnyEvent->idle(cb => sub { undef $w; - $self->_close(shift); + $self->_close($reply); $ch_closed->send; $rf->close; }); @@ -153,8 +156,9 @@ sub execute { } sub _close { - my $self = shift; - my $method_frame = shift->method_frame; + my ($self, $reply) = @_; + confess "No reply" unless $reply; + my $method_frame = $reply->method_frame; print $method_frame->reply_code, ' ', $method_frame->reply_text, "\n"; return; } From a6ffdd57bbca996c9496adc0d2ab5deeffdeb284 Mon Sep 17 00:00:00 2001 From: Tomas Doran Date: Sat, 1 Sep 2012 15:10:37 +0100 Subject: [PATCH 4/9] No longer depend on JSON::XS --- Makefile.PL | 1 - xt/04_coro.t | 2 +- xt/05_multi_channel.t | 2 +- 3 files changed, 2 insertions(+), 3 deletions(-) diff --git a/Makefile.PL b/Makefile.PL index 1f1e599..bdf132b 100644 --- a/Makefile.PL +++ b/Makefile.PL @@ -7,7 +7,6 @@ requires 'Moose'; requires 'MooseX::App::Cmd'; requires 'MooseX::ConfigFromFile'; requires 'Config::Any'; -requires 'JSON::XS'; requires 'List::MoreUtils'; requires 'AnyEvent::RabbitMQ' => '1.03'; requires 'Coro'; diff --git a/xt/04_coro.t b/xt/04_coro.t index 5fa4f75..5f7fd52 100644 --- a/xt/04_coro.t +++ b/xt/04_coro.t @@ -2,7 +2,7 @@ use Test::More; use Test::Exception; use FindBin; -use JSON::XS; +use JSON qw/ decode_json /; use version; my %server = ( diff --git a/xt/05_multi_channel.t b/xt/05_multi_channel.t index 639e3a2..08c7243 100644 --- a/xt/05_multi_channel.t +++ b/xt/05_multi_channel.t @@ -2,7 +2,7 @@ use Test::More; use Test::Exception; use FindBin; -use JSON::XS; +use JSON qw/ decode_json /; my $json_text; open my $fh, '<', $FindBin::Bin . '/../config.json' or die $!; From 9b8cf08f8ad9a1ae4e76fa65a8509ce0ad93f966 Mon Sep 17 00:00:00 2001 From: Chip Salzenberg Date: Mon, 17 Sep 2012 17:14:44 -0700 Subject: [PATCH 5/9] remove useless extra copy of AMQP spec --- share/fixed_amqp0-8.xml | 3951 --------------------------------------- 1 file changed, 3951 deletions(-) delete mode 100644 share/fixed_amqp0-8.xml diff --git a/share/fixed_amqp0-8.xml b/share/fixed_amqp0-8.xml deleted file mode 100644 index 7d844b1..0000000 --- a/share/fixed_amqp0-8.xml +++ /dev/null @@ -1,3951 +0,0 @@ - - - - - - AMQ Protocol 0.80 - - - - - - - - - - - - - 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. - - - 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 or cluster. - - - The client attempted to work with a server entity to which it has - no 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 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. - - - - access ticket granted by server - - An access ticket granted by the server for a certain set of access - rights within a specific realm. Access tickets are valid within the - channel where they were created, and expire when the channel closes. - - - - - - consumer tag - - Identifier for the consumer, valid within the current connection. - - - The consumer tag is valid only within the channel from which the - consumer was created. I.e. a client MUST NOT create a consumer in - one channel and then use it in another. - - - - server-assigned delivery tag - - The server-assigned and channel-specific delivery tag - - - The delivery tag is valid only within the channel from which the - message was received. I.e. a client MUST NOT receive a message on - one channel 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". - - - - exchange name - - 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. - - - - -list of known hosts - -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. - - -The server MAY leave this field empty if it knows of no other -hosts than itself. - - - - - no acknowledgement needed - - If this field is set the server does not expect acknowledgments - 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. - - - - do not deliver own messages - - If the no-local field is set the server will not send messages to - the client 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 properties SHOULD contain these fields: -"product", giving the name of the peer product, "version", giving -the name of the peer version, "platform", giving the name of the -operating system, "copyright", if appropriate, and "information", -giving other general information. - - - - queue name - - The queue name identifies the queue within the vhost. Queue - names may consist of any mixture of digits, letters, and - underscores. - - - - - message is being redelivered - - 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. - - - The client MUST NOT rely on the redelivered field but MUST 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 channels. - - - -reply code from server - - The reply code. The AMQ reply codes are defined in AMQ RFC 011. - - - - -localised reply text - - The localised reply text. This text can be logged as an aid to - resolving issues. - - - - - - work with socket connections - - 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 - - - - - - start connection negotiation - - 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 client cannot handle the protocol version suggested by the - server it MUST close the socket connection. - - - The server MUST provide a protocol version that is lower than or - equal to that requested by the client in the protocol header. If - the server cannot support the specified protocol it MUST NOT send - this method, but MUST close the socket connection. - - - - - protocol major version - - The protocol major version that the server agrees to use, which - cannot be higher than the client's major version. - - - - protocol major version - - The protocol minor version that the server agrees to use, which - cannot be higher than the client's minor version. - - - - server properties - - - available security mechanisms - - A list of the security mechanisms that the server supports, delimited - by spaces. Currently ASL supports these mechanisms: PLAIN. - - - - - - available message locales - - 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. - - - All servers MUST support at least the en_US locale. - - - - - - select security mechanism and locale - - This method selects a SASL security mechanism. ASL uses SASL - (RFC2222) to negotiate authentication and encryption. - - - - client properties - - - selected security mechanism - - 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. - - - The mechanism field MUST contain one of the security mechanisms - proposed by the server in the Start method. If it doesn't, the - server MUST close the socket. - - - - - security response data - - A block of opaque data passed to the security mechanism. The contents - of this data are defined by the SASL security mechanism. For the - PLAIN security mechanism this is defined as a field table holding - two fields, LOGIN and PASSWORD. - - - - - selected message locale - - A single message local selected by the client, which must be one - of those specified by the server. - - - - - - - security mechanism challenge - - 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. - - - - - security challenge data - - Challenge information, a block of opaque binary data passed to - the security mechanism. - - - - - - security mechanism response - - This method attempts to authenticate, passing a block of SASL data - for the security mechanism at the server side. - - - - security response data - - A block of opaque data passed to the security mechanism. The contents - of this data are defined by the SASL security mechanism. - - - - - - - propose connection tuning parameters - - This method proposes a set of connection configuration values - to the client. The client can accept and/or adjust these. - - - - - proposed maximum channels - - 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. - - - - proposed maximum frame size - - 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 4096 octets large. The minimum non-zero value for - the frame-max field is 4096. - - - - desired heartbeat delay - - The delay, in seconds, of the connection heartbeat that the server - wants. Zero means the server does not want a heartbeat. - - - - - negotiate connection tuning parameters - - This method sends the client's connection tuning parameters to the - server. Certain fields are negotiated, others provide capability - information. - - - - negotiated maximum channels - - The maximum total number of channels that the client will use - per connection. May not be higher than the value specified by - the server. - - - The server MAY ignore the channel-max value or MAY use it for - tuning its resource allocation. - - - - - - negotiated maximum frame size - - 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 4096 octets large. The minimum non-zero value for - the frame-max field is 4096. - - - - desired heartbeat delay - - The delay, in seconds, of the connection heartbeat that the client - wants. Zero means the client does not want a heartbeat. - - - - - - open connection to virtual host - - 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 client MUST open the context before doing any work on the - connection. - - - - - - virtual host name - - - 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 server MAY configure arbitrary limits per virtual host, such - as the number of each type of entity that may be used, per - connection and/or in total. - - - - required capabilities - - The client may specify a number of capability names, delimited by - spaces. The server can use this string to how to process the - client's connection request. - - - - insist on connecting to server - - In a configuration with multiple load-sharing 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 SHOULD accept - the client connection unless it is technically unable to do so. - - - - - signal that the connection is ready - - This method signals to the client that the connection is ready for - use. - - - - - - asks the client to use a different server - - 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. - - - - server to connect to - - 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. - - - - - - - - request a connection close - - 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. - - - The peer sending this method MAY use a counter or timeout to - detect failure of the other peer to respond correctly with - the Close-OK method. - - - When a server receives the Close method from a client it MUST - delete all server-side resources associated with the client's - context. A client CANNOT reconnect to a context after sending - or receiving a Close method. - - - - - - - - failing method class - - When the close is provoked by a method exception, this is the - class of the method. - - - - failing method ID - - When the close is provoked by a method exception, this is the - ID of the method. - - - - - confirm a connection close - - 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. - - - - - - - - work with channels - - The channel class provides methods for a client to establish a virtual - connection - a channel - to a server and for both peers to operate the - virtual connection thereafter. - - - channel = open-channel *use-channel close-channel - open-channel = C:OPEN S:OPEN-OK - use-channel = C:FLOW S:FLOW-OK - / S:FLOW C:FLOW-OK - / S:ALERT - / functional-class - close-channel = C:CLOSE S:CLOSE-OK - / S:CLOSE C:CLOSE-OK - - - - - - open a channel for use - - This method opens a virtual connection (a channel). - - - This method MUST NOT be called when the channel is already open. - - - - - out-of-band settings - - Configures out-of-band transfers on this channel. The syntax and - meaning of this field will be formally defined at a later date. - - - - - - signal that the channel is ready - - This method signals to the client that the channel is ready for use. - - - - - - enable/disable flow from peer - - 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 oveflowing 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 request to - stop sending content should finish sending the current content, if - any, and then wait until it receives a Flow restart method. - - - When a new channel is opened, it 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 data in multiple 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 exchangeing 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. - - - - - - start/stop content frames - - If 1, the peer starts sending content frames. If 0, the peer - stops sending content frames. - - - - - confirm a flow method - - Confirms to the peer that a flow command was received and processed. - - - - - current flow setting - - 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. - - - - - - send a non-fatal warning message - - This method allows the server to send a non-fatal warning to the - client. This is used for methods that are normally asynchronous - and thus do not have confirmations, and for which the server may - detect errors that need to be reported. Fatal errors are handled - as channel or connection exceptions; non-fatal errors are sent - through this method. - - - - - - detailed information for warning - - A set of fields that provide more information about the - problem. The meaning of these fields are defined on a - per-reply-code basis (TO BE DEFINED). - - - - - - request a channel close - - 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 - Channel.Close-OK MUST be discarded. - - - The peer sending this method MAY use a counter or timeout to detect - failure of the other peer to respond correctly with Channel.Close-OK.. - - - - - - - - failing method class - - When the close is provoked by a method exception, this is the - class of the method. - - - - failing method ID - - When the close is provoked by a method exception, this is the - ID of the method. - - - - - confirm a channel close - - This method confirms a Channel.Close method and tells the recipient - that it is safe to release resources for the channel and close the - socket. - - - A peer that detects a socket closure without having received a - Channel.Close-Ok handshake method SHOULD log the error. - - - - - - - - work with access tickets - - 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 - - - - - - request an access ticket - - 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-channel resource. - - - The realm name MUST start with either "/data" (for application - resources) or "/admin" (for server administration resources). - If the realm starts with any other path, the server MUST raise - a connection exception with reply code 403 (access refused). - - - The server MUST implement the /data realm and MAY implement the - /admin realm. The mapping of resources to realms is not - defined in the protocol - this is a server-side configuration - issue. - - - - - name of requested realm - - If the specified realm is not known to the server, the server - must raise a channel exception with reply code 402 (invalid - path). - - - - request exclusive access - - Request exclusive access to the realm. If the server cannot grant - this - because there are other active tickets for the realm - it - raises a channel exception. - - - - request passive access - - 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 active access - - Request message active access to the specified access realm. - Acvtive access lets a client get create and delete resources in - the realm. - - - - request write access - - Request write access to the specified access realm. Write access - lets a client publish messages to all exchanges in the realm. - - - - request read access - - Request read access to the specified access realm. Read access - lets a client consume messages from queues in the realm. - - - - - grant access to server resources - - This method provides the client with an access ticket. The access - ticket is valid within the current channel and for the lifespan of - the channel. - - - The client MUST NOT use access tickets except within the same - channel as originally granted. - - - The server MUST isolate access tickets per channel and treat an - attempt by a client to mix these as a connection exception. - - - - - - - - work with exchanges - - Exchanges match and distribute messages across queues. Exchanges can be - configured in the server or created at runtime. - - - exchange = C:DECLARE S:DECLARE-OK - / C:DELETE S:DELETE-OK - - - - - amq_exchange_19 - The server MUST implement the direct and fanout exchange types, and - predeclare the corresponding exchanges named amq.direct and amq.fanout - in each virtual host. The server MUST also predeclare a direct - exchange to act as the default exchange for content Publish methods - and for default queue bindings. - - - amq_exchange_20 - The server SHOULD implement the topic exchange type, and predeclare - the corresponding exchange named amq.topic in each virtual host. - - - amq_exchange_21 - The server MAY implement the system exchange type, and predeclare the - corresponding exchanges named amq.system in each virtual host. If the - client attempts to bind a queue to the system exchange, the server - MUST raise a connection exception with reply code 507 (not allowed). - - - amq_exchange_22 - The default exchange MUST be defined as internal, and be inaccessible - to the client except by specifying an empty exchange name in a content - Publish method. That is, the server MUST NOT let clients make explicit - bindings to this exchange. - - - - declare exchange, create if needed - - 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. - - - amq_exchange_23 - The server SHOULD support a minimum of 16 exchanges per virtual host - and ideally, impose no limit except as defined by available resources. - - - - - - 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. - - - - - amq_exchange_15 - Exchange names starting with "amq." are reserved for predeclared - and standardised exchanges. If the client attempts to create an - exchange starting with "amq.", the server MUST raise a channel - exception with reply code 403 (access refused). - - - - - exchange type - - 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. - - - amq_exchange_16 - If the exchange already exists with a different type, the server - MUST raise a connection exception with a reply code 507 (not allowed). - - - amq_exchange_18 - If the server does not support the requested exchange type it MUST - raise a connection exception with a reply code 503 (command invalid). - - - - - do not create exchange - - 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. - - - amq_exchange_05 - If set, and the exchange does not already exist, the server MUST - raise a channel exception with reply code 404 (not found). - - - - request a durable exchange - - 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. - - - amq_exchange_24 - The server MUST support both durable and transient exchanges. - - - The server MUST ignore the durable field if the exchange already - exists. - - - - auto-delete when unused - - If set, the exchange is deleted when all queues have finished - using it. - - - amq_exchange_02 - The server SHOULD allow for a reasonable delay between the point - when it determines that an exchange is not being used (or no longer - used), and the point when it deletes the exchange. At the least it - must allow a client to create an exchange and then bind a queue to - it, with a small but non-zero delay between these two actions. - - - amq_exchange_25 - The server MUST ignore the auto-delete field if the exchange already - exists. - - - - create internal exchange - - If set, the exchange may not be used directly by publishers, but - only when bound to other exchanges. Internal exchanges are used to - construct wiring that is not visible to applications. - - - - - do not send a reply method - - 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. - - - - - arguments for declaration - - 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. - - - - - confirms an exchange declaration - - This method confirms a Declare method and confirms the name of the - exchange, essential for automatically-named exchanges. - - - - - - delete an exchange - - 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. - - - - - amq_exchange_11 - The exchange MUST exist. Attempting to delete a non-existing exchange - causes a channel exception. - - - - - delete only if unused - - 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. - - - amq_exchange_12 - If set, the server SHOULD delete the exchange but only if it has - no queue bindings. - - - amq_exchange_13 - If set, the server SHOULD raise a channel exception if the exchange is in - use. - - - - - do not send a reply method - - 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. - - - - - - confirm deletion of an exchange - - This method confirms the deletion of an exchange. - - - - - - - work with queues - - - 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 S:DECLARE-OK - / C:BIND S:BIND-OK - / C:PURGE S:PURGE-OK - / C:DELETE S:DELETE-OK - - - - - amq_queue_33 - A server MUST allow any content class to be sent to any queue, in any - mix, and queue and delivery these content classes independently. Note - that all methods that fetch content off queues are specific to a given - content class. - - - - declare queue, create if needed - - 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. - - - amq_queue_34 - The server MUST create a default binding for a newly-created queue - to the default exchange, which is an exchange of type 'direct'. - - - amq_queue_35 - The server SHOULD support a minimum of 256 queues per virtual host - and ideally, impose no limit except as defined by available resources. - - - - - - 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 provides a valid access ticket giving "active" access - to the realm in which the queue exists or will be created, or - "passive" access if the if-exists flag is set. - - - - - amq_queue_10 - The queue name MAY be empty, in which case the server MUST create - a new queue with a unique generated name and return this to the - client in the Declare-Ok method. - - - amq_queue_32 - Queue names starting with "amq." are reserved for predeclared and - standardised server queues. If the queue name starts with "amq." - and the passive option is zero, the server MUST raise a connection - exception with reply code 403 (access refused). - - - - - do not create queue - - If set, the server will not create the queue. The client can use - this to check whether a queue exists without modifying the server - state. - - - amq_queue_05 - If set, and the queue does not already exist, the server MUST - respond with a reply code 404 (not found) and raise a channel - exception. - - - - request a durable queue - - 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. - - - amq_queue_03 - The server MUST recreate the durable queue after a restart. - - - amq_queue_36 - The server MUST support both durable and transient queues. - - - amq_queue_37 - The server MUST ignore the durable field if the queue already - exists. - - - - request an exclusive queue - - Exclusive queues may only be consumed from by the current connection. - Setting the 'exclusive' flag always implies 'auto-delete'. - - - amq_queue_38 - The server MUST support both exclusive (private) and non-exclusive - (shared) queues. - - - amq_queue_04 - The server MUST raise a channel exception if 'exclusive' is specified - and the queue already exists and is owned by a different connection. - - - - auto-delete queue when unused - - If set, the queue is deleted when all 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. - - - amq_queue_02 - The server SHOULD allow for a reasonable delay between the point - when it determines that a queue is not being used (or no longer - used), and the point when it deletes the queue. At the least it - must allow a client to create a queue and then create a consumer - to read from it, with a small but non-zero delay between these - two actions. The server should equally allow for clients that may - be disconnected prematurely, and wish to re-consume from the same - queue without losing messages. We would recommend a configurable - timeout, with a suitable default value being one minute. - - - amq_queue_31 - The server MUST ignore the auto-delete field if the queue already - exists. - - - - do not send a reply method - - 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. - - - - - arguments for declaration - - 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. - - - - - confirms a queue definition - - This method confirms a Declare method and confirms the name of the - queue, essential for automatically-named queues. - - - - - Reports the name of the queue. If the server generated a queue - name, this field contains that name. - - - - - number of messages in queue - - Reports the number of messages in the queue, which will be zero - for newly-created queues. - - - - number of consumers - - Reports the number of active consumers for the queue. Note that - consumers can suspend activity (Channel.Flow) in which case they - do not appear in this count. - - - - - - bind queue to an exchange - - 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 dest exchange - and subscription queues are bound to a dest_wild exchange. - - - amq_queue_25 - 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. - - - amq_queue_39 - If a bind fails, the server MUST raise a connection exception. - - - amq_queue_12 - The server MUST NOT allow a durable queue to bind to a transient - exchange. If the client attempts this the server MUST raise a - channel exception. - - - amq_queue_13 - Bindings for durable queues are automatically durable and the - server SHOULD restore such bindings after a server restart. - - - amq_queue_17 - If the client attempts to an exchange that was declared as internal, - the server MUST raise a connection exception with reply code 530 - (not allowed). - - - amq_queue_40 - The server SHOULD support at least 4 bindings per queue, and - ideally, impose no limit except as defined by available resources. - - - - - - 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 channel, 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). - - - 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 bind to. - - amq_queue_14 - If the exchange does not exist the server MUST raise a channel - exception with reply code 404 (not found). - - - - message routing key - - 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 routing key is empty and the queue - name is empty, the routing key will be the current queue for the - channel, which is the last declared queue. - - - - - do not send a reply method - - 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. - - - - - arguments for binding - - A set of arguments for the binding. The syntax and semantics of - these arguments depends on the exchange class. - - - - - confirm bind successful - - This method confirms that the bind was successful. - - - - - - - unbind a queue from an exchange - 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. - - - - The name of the exchange to unbind from. - - - - routing key of binding - Specifies the routing key of the binding to unbind. - - - - arguments of binding - Specifies the arguments of the binding to unbind. - - - - - confirm unbind successful - This method confirms that the unbind was successful. - - - - - - purge a queue - - This method removes all messages from a queue. It does not cancel - consumers. Purged messages are deleted without any formal "undo" - mechanism. - - - amq_queue_15 - A call to purge MUST result in an empty queue. - - - amq_queue_41 - On transacted channels the server MUST not purge messages that have - already been sent to a client but not yet acknowledged. - - - amq_queue_42 - 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 access ticket must be for the access realm that holds the - queue. - - - 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 channel, 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 - causes a channel exception. - - - - - do not send a reply method - - 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. - - - - - confirms a queue purge - - This method confirms the purge of a queue. - - - - number of messages purged - - Reports the number of messages purged. - - - - - - delete a queue - - 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. - - - amq_queue_43 - 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 channel, 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 delete a non-existing queue - causes a channel exception. - - - - - delete only if unused - - 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. - - - amq_queue_29 - amq_queue_30 - The server MUST respect the if-unused flag when deleting a queue. - - - - delete only if empty - amq_queue_27 - - If set, the server will only delete the queue if it has no - messages. If the queue is not empty the server raises a channel - exception. - - - - do not send a reply method - - 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. - - - - - - confirm deletion of a queue - - This method confirms the deletion of a queue. - - - - number of messages purged - - Reports the number of messages purged. - - - - - - - work with basic content - - The Basic class provides methods that support an industry-standard - messaging model. - - - - basic = C:QOS S:QOS-OK - / C:CONSUME S:CONSUME-OK - / C:CANCEL S:CANCEL-OK - / 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. - - - The server MUST NOT discard a persistent basic message in case of a - queue overflow. The server MAY use the Channel.Flow method to slow - or stop a basic message publisher when necessary. - - - The server MAY overflow non-persistent basic messages to persistent - storage and 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. The server MAY implement up to 10 priority levels. - - - The server MUST deliver messages of the same priority in order - irrespective of their individual persistence. - - - The server MUST support both automatic and explicit acknowledgements - on Basic content. - - - - - - MIME content type - - - MIME content encoding - - - Message header field table - - - Non-persistent (1) or persistent (2) - - - The message priority, 0 to 9 - - - The application correlation identifier - - - The destination to reply to - - - Message expiration specification - - - The application message identifier - - - The message timestamp - - - The message type name - - - The creating user id - - - The creating application id - - - Intra-cluster routing identifier - - - - - - - specify quality of service - - This method requests a specific quality of service. The QoS can - be specified for the current channel or for all channels 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. - - - - - - prefetch window in octets - - 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 - down the channel. 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. - - - - - prefetch window in messages - - 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 channel 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. - - - - - apply to entire connection - - By default the QoS settings apply to the current channel only. If - this field is set, they are applied to the entire connection. - - - - - - confirm the requested qos - - 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. - - - - - - - - start a queue consumer - - 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 channel 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. - - - - - - Specifies the name of the queue to consume from. If the queue name - is null, refers to the current queue for the channel, 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 access - - 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 403 (access refused). - - - - - do not send a reply method - - 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. - - - - - - confirm a new consumer - - 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. - - - - - - - - - end a queue consumer - - 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 - abitrary number of messages in between sending the cancel method - and receiving the cancel-ok reply. - - - If the queue no longer exists when the client sends a cancel command, - or the consumer has been cancelled for other reasons, this command - has no effect. - - - - - - - - do not send a reply method - - 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. - - - - - - confirm a cancelled consumer - - This method confirms that the cancellation was completed. - - - - - - - - - - - publish a message - - 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 "write" - access rights to the access realm for the exchange. - - - - - - 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). - - - - - Message routing key - - Specifies the routing key for the message. The routing key is - used for routing messages depending on the exchange configuration. - - - - - indicate mandatory routing - - 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. - - - - - request immediate delivery - - 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. - - - - - - return a failed message - - 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. - - - - - Message routing key - - Specifies the routing key name specified when the message was - published. - - - - - - - - - notify the client of a consumer message - - 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. - - - - - Message routing key - - Specifies the routing key name specified when the message was - published. - - - - - - - - - direct access to a queue - - 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. - - - - - - Specifies the name of the queue to consume from. If the queue name - is null, refers to the current queue for the channel, 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). - - - - - - - - provide client with a message - - 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. - - - - - Message routing key - - Specifies the routing key name specified when the message was - published. - - - - - number of messages pending - - 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. - - - - - - - indicate no messages available - - This method tells the client that the queue has no messages - available for the client. - - - - - Cluster id - - For use by cluster applications, should not be used by - client applications. - - - - - - - - acknowledge one or more messages - - 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. - - - - - - acknowledge multiple messages - - 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 mesages. - - - 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. - - - - - - - - reject an incoming message - - 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 process the Reject - method while sending message content with a Deliver or Get-Ok - method. I.e. the server should read and process incoming methods - while sending output frames. To cancel a partially-send content, - the server sends a content body frame of size 1 (i.e. with no data - except the frame-end octet). - - - 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. - - - - - - - requeue the message - - 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 channel. The recommended strategy is - to attempt to deliver the message to an alternative consumer, and - if that is not possible, to move the message to a dead-letter - queue. The server MAY use more sophisticated tracking to hold - the message on the queue and redeliver it to the same client at - a later stage. - - - - - - redeliver unacknowledged messages. This method is only allowed on non-transacted channels. - - This method asks the broker to redeliver all unacknowledged messages on a - specifieid channel. Zero or more messages may be redelivered. - - - - - requeue the message - - 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 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 channel. - - - - - - - - - - work with file content - - 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 channel 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 S:CANCEL-OK - / 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 Channel.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. - - - - - - MIME content type - - - MIME content encoding - - - Message header field table - - - The message priority, 0 to 9 - - - The destination to reply to - - - The application message identifier - - - The message filename - - - The message timestamp - - - Intra-cluster routing identifier - - - - - - - specify quality of service - - This method requests a specific quality of service. The QoS can - be specified for the current channel or for all channels 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. - - - - - - prefetch window in octets - - 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 - down the channel. 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. - - - - - prefetch window in messages - - 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 channel 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. - - - - - apply to entire connection - - By default the QoS settings apply to the current channel only. If - this field is set, they are applied to the entire connection. - - - - - - confirm the requested qos - - 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. - - - - - - - - start a queue consumer - - 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 channel 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. - - - - - - Specifies the name of the queue to consume from. If the queue name - is null, refers to the current queue for the channel, 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 access - - 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). - - - - - do not send a reply method - - 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. - - - - - - confirm a new consumer - - 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. - - - - - - - - - end a queue consumer - - 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. - - - - - - - - do not send a reply method - - 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. - - - - - - confirm a cancelled consumer - - This method confirms that the cancellation was completed. - - - - - - - - - - - request to start staging - - 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. - - - - - - - staging identifier - - 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.). - - - - - message content size - - 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. - - - - - - confirm staging ready - - 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. - - - - - - - already staged amount - - 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. - - - - - - - - stage message content - - This method stages the message, sending the message content to the - recipient from the octet offset specified in the Open-Ok method. - - - - - - - - - - publish a message - - 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 "write" - access rights to the access realm for the exchange. - - - - - - 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. - - - - - Message routing key - - Specifies the routing key for the message. The routing key is - used for routing messages depending on the exchange configuration. - - - - - indicate mandatory routing - - 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. - - - - - request immediate delivery - - 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. - - - - - staging identifier - - 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. - - - - - - return a failed message - - 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. - - - - - Message routing key - - Specifies the routing key name specified when the message was - published. - - - - - - - - - notify the client of a consumer message - - 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. - - - - - Message routing key - - Specifies the routing key name specified when the message was - published. - - - - - staging identifier - - 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. - - - - - - - - - acknowledge one or more messages - - 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. - - - - - - acknowledge multiple messages - - 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 mesages. - - - 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. - - - - - - - - - reject an incoming message - - 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. - - - - - - - requeue the message - - 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 channel. The recommended strategy is - to attempt to deliver the message to an alternative consumer, and - if that is not possible, to move the message to a dead-letter - queue. The server MAY use more sophisticated tracking to hold - the message on the queue and redeliver it to the same client at - a later stage. - - - - - - - - - work with streaming content - - - 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 unacknowleged 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 S:CANCEL-OK - / 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. - - - - - - - MIME content type - - - MIME content encoding - - - Message header field table - - - The message priority, 0 to 9 - - - The message timestamp - - - - - - - specify quality of service - - This method requests a specific quality of service. The QoS can - be specified for the current channel or for all channels 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. - - - - - - prefetch window in octets - - 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 - down the channel. 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. - - - - - prefetch window in messages - - 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 channel and connection level) allow it. - - - - - transfer rate in octets/second - - 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. - - - - - apply to entire connection - - By default the QoS settings apply to the current channel only. If - this field is set, they are applied to the entire connection. - - - - - - confirm the requested qos - - 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. - - - - - - - - start a queue consumer - - 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 channel 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 channels 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. - - - - - - Specifies the name of the queue to consume from. If the queue name - is null, refers to the current queue for the channel, 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 access - - 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). - - - - - do not send a reply method - - 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. - - - - - - - confirm a new consumer - - 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. - - - - - - - - end a queue consumer - - This method cancels a consumer. Since message delivery is - asynchronous the client may continue to receive messages for - a short while after canceling a consumer. It may process or - discard these as appropriate. - - - - - - - - do not send a reply method - - 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. - - - - - - confirm a cancelled consumer - - This method confirms that the cancellation was completed. - - - - - - - - - - - publish a message - - 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 "write" - access rights to the access realm for the exchange. - - - - - - 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. - - - - - Message routing key - - Specifies the routing key for the message. The routing key is - used for routing messages depending on the exchange configuration. - - - - - indicate mandatory routing - - 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. - - - - - request immediate delivery - - 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. - - - - - - return a failed message - - 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. - - - - - Message routing key - - Specifies the routing key name specified when the message was - published. - - - - - - - - - notify the client of a consumer message - - 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 channel can start many consumers on different - queues. - - - - - - - - - work with standard transactions - - - 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. - - - 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. - - - tx = C:SELECT S:SELECT-OK - / C:COMMIT S:COMMIT-OK - / C:ROLLBACK S:ROLLBACK-OK - - - - - -select standard transaction mode - - This method sets the channel to use standard transactions. The - client must use this method at least once on a channel before - using the Commit or Rollback methods. - - - - - -confirm transaction mode - - This method confirms to the client that the channel was successfully - set to use standard transactions. - - - - - -commit the current transaction - - This method commits all messages published and acknowledged in - the current transaction. A new transaction starts immediately - after a commit. - - - - - -confirm a successful commit - - This method confirms to the client that the commit succeeded. - Note that if a commit fails, the server raises a channel exception. - - - - - -abandon the current transaction - - This method abandons all messages published and acknowledged in - the current transaction. A new transaction starts immediately - after a rollback. - - - - - -confirm a successful rollback - - This method confirms to the client that the rollback succeeded. - Note that if an rollback fails, the server raises a channel exception. - - - - - - - work with distributed transactions - - - Distributed transactions provide so-called "2-phase commit". The - AMQP distributed transaction model supports the X-Open XA - architecture and other distributed transaction implementations. - The Dtx class assumes that the server has a private communications - channel (not AMQP) to a distributed transaction coordinator. - - - dtx = C:SELECT S:SELECT-OK - C:START S:START-OK - - - - - -select standard transaction mode - - This method sets the channel to use distributed transactions. The - client must use this method at least once on a channel before - using the Start method. - - - - - -confirm transaction mode - - This method confirms to the client that the channel was successfully - set to use distributed transactions. - - - - - - start a new distributed transaction - - This method starts a new distributed transaction. This must be - the first method on a new channel that uses the distributed - transaction mode, before any methods that publish or consume - messages. - - - - - transaction identifier - - The distributed transaction key. This identifies the transaction - so that the AMQP server can coordinate with the distributed - transaction coordinator. - - - - - - confirm the start of a new distributed transaction - - This method confirms to the client that the transaction started. - Note that if a start fails, the server raises a channel exception. - - - - - - - methods for protocol tunneling. - - - 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 - - - - - Message header field table - - - The identity of the tunnelling proxy - - - The name or type of the message being tunnelled - - - The message durability indicator - - - The message broadcast mode - - - - sends a tunnelled method - - 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. - - - - meta data for the tunnelled block - - This field table holds arbitrary meta-data that the sender needs - to pass to the recipient. - - - - - - - test functional primitives of the implementation - - - The test class provides methods for a peer to test the basic - operational correctness of another peer. The test methods are - intended to ensure that all peers respect at least the basic - elements of the protocol, such as frame and content organisation - and field types. We assume that a specially-designed peer, a - "monitor client" would perform such tests. - - - test = C:INTEGER S:INTEGER-OK - / S:INTEGER C:INTEGER-OK - / C:STRING S:STRING-OK - / S:STRING C:STRING-OK - / C:TABLE S:TABLE-OK - / S:TABLE C:TABLE-OK - / C:CONTENT S:CONTENT-OK - / S:CONTENT C:CONTENT-OK - - - - - - test integer handling - - This method tests the peer's capability to correctly marshal integer - data. - - - - - - octet test value - - An octet integer test value. - - - - short test value - - A short integer test value. - - - - long test value - - A long integer test value. - - - - long-long test value - - A long long integer test value. - - - - operation to test - - The client must execute this operation on the provided integer - test fields and return the result. - - - return sum of test values - return lowest of test values - return highest of test values - - - - - report integer test result - - This method reports the result of an Integer method. - - - - - result value - - The result of the tested operation. - - - - - - test string handling - - This method tests the peer's capability to correctly marshal string - data. - - - - - - short string test value - - An short string test value. - - - - long string test value - - A long string test value. - - - - operation to test - - The client must execute this operation on the provided string - test fields and return the result. - - - return concatentation of test strings - return shortest of test strings - return longest of test strings - - - - - report string test result - - This method reports the result of a String method. - - - - - result value - - The result of the tested operation. - - - - - - test field table handling - - This method tests the peer's capability to correctly marshal field - table data. - - - - - - field table of test values - - A field table of test values. - - - - operation to test on integers - - The client must execute this operation on the provided field - table integer values and return the result. - - - return sum of numeric field values - return min of numeric field values - return max of numeric field values - - - - operation to test on strings - - The client must execute this operation on the provided field - table string values and return the result. - - - return concatenation of string field values - return shortest of string field values - return longest of string field values - - - - - report table test result - - This method reports the result of a Table method. - - - - - integer result value - - The result of the tested integer operation. - - - - string result value - - The result of the tested string operation. - - - - - - test content handling - - This method tests the peer's capability to correctly marshal content. - - - - - - - report content test result - - This method reports the result of a Content method. It contains the - content checksum and echoes the original content as provided. - - - - - content hash - - The 32-bit checksum of the content, calculated by adding the - content into a 32-bit accumulator. - - - - - From 194dcd7eb9eb5bfe9d33d4e511b23f4dcc94d344 Mon Sep 17 00:00:00 2001 From: Chip Salzenberg Date: Mon, 17 Sep 2012 17:15:41 -0700 Subject: [PATCH 6/9] add confirm method to Channel --- lib/Net/RabbitFoot/Channel.pm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/Net/RabbitFoot/Channel.pm b/lib/Net/RabbitFoot/Channel.pm index f2fc6f1..5c54762 100644 --- a/lib/Net/RabbitFoot/Channel.pm +++ b/lib/Net/RabbitFoot/Channel.pm @@ -15,7 +15,7 @@ BEGIN { close declare_exchange delete_exchange declare_queue bind_queue unbind_queue purge_queue delete_queue - consume cancel get qos + consume cancel get qos confirm select_tx commit_tx rollback_tx )) { no strict 'refs'; From 9ef43ebc8bbc25f1cb9993972aed999d1fac5ffc Mon Sep 17 00:00:00 2001 From: Chip Salzenberg Date: Mon, 17 Sep 2012 17:15:51 -0700 Subject: [PATCH 7/9] document just a little --- lib/Net/RabbitFoot.pm | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/lib/Net/RabbitFoot.pm b/lib/Net/RabbitFoot.pm index 2931530..d99f099 100644 --- a/lib/Net/RabbitFoot.pm +++ b/lib/Net/RabbitFoot.pm @@ -75,6 +75,7 @@ Net::RabbitFoot - An Asynchronous and multi channel Perl AMQP client. =head1 SYNOPSIS use Net::RabbitFoot; + use Coro; my $rf = Net::RabbitFoot->new()->load_xml_spec()->connect( host => 'localhost', @@ -85,9 +86,22 @@ Net::RabbitFoot - An Asynchronous and multi channel Perl AMQP client. timeout => 1, ); - my $ch = $rf->open_channel(); + my $ch = $rf->open_channel(on_return => sub { warn "message went nowhere: ".Dumper(shift) }); $ch->declare_exchange(exchange => 'test_exchange'); + $ch->publish(...); # same params as AnyEvent::RabbitMQ + + # confirm mode for 0.9 + $ch->confirm; + + my $returned; + $ch->publish(..., # normal publish params + mandatory => 1, # if it goes nowhere, return it + on_ack => rouse_cb, + on_return => sub { $returned = shift }); + rouse_wait; # wait for ack + die "the message went nowhere" if $returned; + =head1 DESCRIPTION Net::RabbitFoot is an AMQP(Advanced Message Queuing Protocol) client library, that is intended to allow you to interact with AMQP-compliant message brokers/servers such as RabbitMQ in an asynchronous fashion. @@ -99,8 +113,13 @@ You can use Net::RabbitFoot to - * Set QoS * Publish, consume, get, ack and recover messages * Select, commit and rollback transactions + * Set publish confirm mode and get callbacks on publish ack and return (AMQP 0.9) + +Net::RabbitFoot is known to work with RabbitMQ versions 2.3.1 through 2.7.1 and versions 0-8 and 0-9-1 of the AMQP specification. + +=head1 BUGS -Net::RabbitFoot is known to work with RabbitMQ versions 2.3.1 and version 0-8 of the AMQP specification. +Documentation would be nice. =head1 AUTHOR From 89be88c52ef5e44080ea4a4f7b158966477994e6 Mon Sep 17 00:00:00 2001 From: Chip Salzenberg Date: Mon, 17 Sep 2012 17:16:45 -0700 Subject: [PATCH 8/9] finish removing useless extra copy of AMQP spec --- Makefile.PL | 1 - 1 file changed, 1 deletion(-) diff --git a/Makefile.PL b/Makefile.PL index bdf132b..1a2b1bf 100644 --- a/Makefile.PL +++ b/Makefile.PL @@ -14,7 +14,6 @@ requires 'Coro::AnyEvent'; tests 't/*.t'; author_tests 'xt'; -install_share; build_requires 'Test::More'; build_requires 'Test::Exception'; From a8e0f0b85f5c706b7d90818dd56df714efa9f229 Mon Sep 17 00:00:00 2001 From: Chip Salzenberg Date: Mon, 17 Sep 2012 17:24:22 -0700 Subject: [PATCH 9/9] adapt tests to on_return requirements - channel vs. publish vs. confirm --- xt/04_coro.t | 20 +++++++++++++------- xt/05_multi_channel.t | 3 +-- 2 files changed, 14 insertions(+), 9 deletions(-) diff --git a/xt/04_coro.t b/xt/04_coro.t index 5f7fd52..054ae3c 100644 --- a/xt/04_coro.t +++ b/xt/04_coro.t @@ -52,7 +52,12 @@ lives_ok sub { }, 'connect'; my $ch; -lives_ok sub {$ch = $rf->open_channel();}, 'open channel'; +lives_ok sub { + $ch = $rf->open_channel(on_return => unblock_sub { + my $response = shift; + my $error_message = 'on_return_channel: ' . Dumper($response); + die $error_message; + },)}, 'open channel'; lives_ok sub { $ch->declare_exchange(exchange => 'test_x'); @@ -272,17 +277,18 @@ lives_ok sub { }, 'close'; sub publish { - my ($ch, $message,) = @_; + my ($ch, $message, $confirm) = @_; $ch->publish( exchange => 'test_x', routing_key => 'test_r', body => $message, - on_return => unblock_sub { - my $response = shift; - my $error_message = 'on_return: ' . Dumper($response); - die $error_message; - }, + !$confirm ? () : + ( on_return => unblock_sub { + my $response = shift; + my $error_message = 'on_return_publish: ' . Dumper($response); + die $error_message; + } ), ); return; diff --git a/xt/05_multi_channel.t b/xt/05_multi_channel.t index 08c7243..3883893 100644 --- a/xt/05_multi_channel.t +++ b/xt/05_multi_channel.t @@ -40,7 +40,7 @@ my $done = 0; my @queues = map { my $queue = 'test_q' . $_; - my $ch = $rf->open_channel(); + my $ch = $rf->open_channel(on_return => unblock_sub {die Dumper(@_);}); isa_ok($ch, 'Net::RabbitFoot::Channel'); $ch->declare_queue(queue => $queue); @@ -81,7 +81,6 @@ sub publish { routing_key => $queue, body => $message, mandatory => 1, - on_return => unblock_sub {die Dumper(@_);}, ); return;