AMQP

Apache ActiveMQ Artemis supports the AMQP 1.0 specification. By default there are acceptor elements configured to accept AMQP connections on ports 61616 and 5672.

See the general Protocols and Interoperability chapter for details on configuring an acceptor for AMQP.

You can use any AMQP 1.0 compatible clients.

A short list includes:

Examples

We have a few examples as part of the Artemis distribution:

  • .NET:
    • ./examples/protocols/amqp/dotnet
  • ProtonCPP
    • ./examples/protocols/amqp/proton-cpp
    • ./examples/protocols/amqp/proton-clustered-cpp
  • Ruby
    • ./examples/protocols/amqp/proton-ruby
  • Java (Using the qpid JMS Client)
    • ./examples/protocols/amqp/queue
  • Interceptors
    • ./examples/features/standard/interceptor-amqp
    • ./examples/features/standard/broker-plugin

Message Conversions

The broker will not perform any message conversion to any other protocols when sending AMQP and receiving AMQP.

However if you intend your message to be received by an AMQP JMS Client, you must follow the JMS Mapping Conventions. If you send a body type that is not recognized by this specification the conversion between AMQP and any other protocol will make it a Binary Message. Make sure you follow these conventions if you intend to cross protocols or languages. Especially on the message body.

A compatibility setting allows aligning the naming convention of AMQP queues (JMS Durable and Shared Subscriptions) with CORE. For backwards compatibility reasons, you need to explicitly enable this via broker configuration:

  • amqp-use-core-subscription-naming
    • true - use queue naming convention that is aligned with CORE.
    • false (default) - use older naming convention.

Intercepting and changing messages

We don't recommend changing messages at the server's side for a few reasons:

  • AMQP messages are meant to be immutable
  • The message won't be the original message the user sent
  • AMQP has the possibility of signing messages. The signature would be broken.
  • For performance reasons. We try not to re-encode (or even decode) messages.

If regardless these recommendations you still need and want to intercept and change AMQP messages, look at the aforementioned interceptor examples.

AMQP and security

The Apache ActiveMQ Artemis Server accepts the PLAIN, ANONYMOUS, and GSSAPI SASL mechanism. These are implemented on the broker's security infrastructure.

AMQP and destinations

If an AMQP Link is dynamic then a temporary queue will be created and either the remote source or remote target address will be set to the name of the temporary queue. If the Link is not dynamic then the the address of the remote target or source will used for the queue. If this does not exist then it will be auto-created if the settings allow.

AMQP and Multicast Addresses (Topics)

Although AMQP has no notion of "topics" it is still possible to treat AMQP consumers or receivers as subscriptions rather than just consumers on a queue. By default any receiving link that attaches to an address that has only multicast enabled will be treated as a subscription and a corresponding subscription queue will be created. If the Terminus Durability is either UNSETTLED_STATE or CONFIGURATION then the queue will be made durable (similar to a JMS durable subscription) and given a name made up from the container id and the link name, something like my-container-id:my-link-name. If the Terminus Durability is configured as NONE then a volatile multicast queue will be created.

AMQP and Coordinations - Handling Transactions

An AMQP links target can also be a Coordinator. A Coordinator is used to handle transactions. If a coordinator is used then the underlying server session will be transacted and will be either rolled back or committed via the coordinator.

Note:

AMQP allows the use of multiple transactions per session, amqp:multi-txns-per-ssn, however in this version of Apache ActiveMQ Artemis will only support single transactions per session.

AMQP scheduling message delivery

An AMQP message can provide scheduling information that controls the time in the future when the message will be delivered at the earliest. This information is provided by adding a message annotation to the sent message.

There are two different message annotations that can be used to schedule a message for later delivery:

  • x-opt-delivery-time The specified value must be a positive long corresponding to the time the message should be made available for delivery (in milliseconds).

  • x-opt-delivery-delay The specified value must be a positive long corresponding to the amount of milliseconds after the broker receives the given message before it should be made available for delivery.

If both annotations are present in the same message then the broker will prefer the more specific x-opt-delivery-time value.

Configuring AMQP Idle Timeout

It is possible to configure the AMQP Server's IDLE Timeout by setting the property amqpIdleTimeout in milliseconds on the acceptor.

This will make the server to send an AMQP frame open to the client, with your configured timeout / 2.

So, if you configured your AMQP Idle Timeout to be 60000, the server will tell the client to send frames every 30,000 milliseconds.

<acceptor name="amqp">.... ;amqpIdleTimeout=<configured-timeout>; ..... </acceptor>

Disabling Keep alive checks

if you set amqpIdleTimeout=0 that will tell clients to not sending keep alive packets towards the server. On this case you will rely on TCP to determine when the socket needs to be closed.

<acceptor name="amqp">.... ;amqpIdleTimeout=0; ..... </acceptor>

This contains a real example for configuring amqpIdleTimeout:

<acceptor name="amqp">tcp://0.0.0.0:5672?amqpIdleTimeout=0;tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=AMQP;useEpoll=true;amqpCredits=1000;amqpMinCredits=300;directDeliver=false;batchDelay=10</acceptor>

results matching ""

    No results matching ""