package amqp-client-lwt

The localised reply text. This text can be logged as an aid to resolving issues.

Unconstrained.

The reply code. The AMQ reply codes are defined as constants at the start of this formal specification.

The number of messages in the queue, which will be zero for newly-declared queues. This is the number of messages present in the queue, and committed if the channel on which they were published is transacted, that are not waiting acknowledgement.

This table provides a set of peer properties, used for identification, debugging, and general information.

The exchange name is a client-selected string that identifies the exchange for publish methods.

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.

The server-assigned and channel-specific delivery tag

If this field is set the server does not expect acknowledgements for messages. That is, when a message is delivered to the client the server assumes the delivery will succeed and immediately dequeues it. This functionality may increase performance but at the cost of reliability. Messages can get lost if a client dies before they are delivered to the application.

Identifier for the consumer, valid within the current channel.

The queue name identifies the queue within the vhost. In methods where the queue name may be blank, and that has no specific significance, this refers to the 'current' queue for the channel, meaning the last queue that the client declared on the channel. If the client did not declare a queue, and the method needs a queue name, this will result in a 502 (syntax error) channel exception.

This indicates that the message has been previously delivered to this or another client.

If the no-local field is set the server will not send messages to the connection that published them.

The Confirm class allows publishers to put the channel in confirm mode and subsequently be notified when messages have been handled by the broker. The intention is that all messages published on a channel in confirm mode will be acknowledged at some point. By acknowledging a message the broker assumes responsibility for it and indicates that it has done something it deems reasonable with it.

The Tx class allows publish and ack operations to be batched into atomic units of work. The intention is that all publish and ack requests issued within a transaction will complete successfully or none of them will. Servers SHOULD implement atomic transactions at least where all publish or ack requests affect a single queue. Transactions that cover multiple queues may be non-atomic, given that queues can be created and destroyed asynchronously, and such events do not form part of any transaction. Further, the behaviour of transactions with respect to the immediate and mandatory flags on Basic.Publish methods is not defined.

The Basic class provides methods that support an industry-standard messaging model.

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.

Exchanges match and distribute messages across queues. Exchanges can be configured in the server or declared at runtime.

The channel class provides methods for a client to establish a channel to a server and for both peers to operate the channel thereafter.

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.