The configuration of ActiveMQ is so slick, we decided to take a similar approach with ActiveMQ-CPP. All configuration is achieved via URI-encoded parameters, either on the connection or destinations. Through the URIs, you can configure virtually every facet of your ActiveMQ-CPP client. The tables below show the comprehensive set of parameters.
Connection URI Parameters
This first example uses a standard TCP based transport.
cf = new ActiveMQConnectionFactory(
For a more reliable connection use the Failover Transport and configure in alternate locations to connect to.
cf = new ActiveMQConnectionFactory(
Uses TCP/IP Sockets to connect to the broker.
Uses OpenSSL to secure TCP/IP sockets. (Since v3.2.0)
Composite of other Transports, when a Transport connection fails, the Failover Transport connects to the next Transport in the list or retries the connection to the failed broker URI.
The number of bytes in the buffered input stream's buffer
The number of bytes in the buffered output stream's buffer
Socket SOLinger value
Socket SOKeepAlive value
Socket receive buffer. If -1, use OS default.
Socket send buffer. If -1, use OS default.
Socket connection timeout in microseconds. If -1, use OS default. (Since ActiveMQ-CPP 2.2)
Sets the Socket level TCP_NODELAY option
General Transport Options
If true, enables tracing of incoming and outgoing transport commands
If true, enables tracing of raw network IO (in hex)
If true, enables asynchronous sending of messages. *WARNING: Using this could result in a loss of data if messages are pending and the client is shut down or crashes.* (Deprecated Since ActiveMQ-CPP 2.2.2 has no effect as of this release, use connection.useAsyncSend instead)
Milliseconds to wait for responses from the broker. (Removed as of ActiveMQ-CPP 2.2.1, use connection.sendTimeout instead)
Failover Transport Options
How long to wait if the initial attempt to connect to the broker fails.
Maximum time that the transport waits before trying to connect to the Broker again.
Should the delay between connection attempt grow on each try up to the max reconnect delay
Max number of times to attempt to reconnect before failing the transport, default is forever (0).
Max number of times to attempt to reconnect before failing the transport, default is forever (0). Only applies during the initial attempt to connect, after one successful connection the maxReconnectAttempts flag applies from then on. (Since v3.2.0)
Should the transport attempt to connect to the listed Broker URI's in Random order.
Should the Failover transport maintain hot backups.
If enabled, how many hot backup connections are made.
If a send is blocked waiting on a failed connection to reconnect how long should it wait before failing the send, default is forever (-1).
Maximum number of redelivery attempts. (Removed in v3.2.0, see instead Connection Redelivery Policy)
Time to wait on Message Sends for a Response, default value of zero indicates to wait forever. Waiting forever allows the broker to have flow control over messages coming from this client if it is a fast producer or there is no consumer such that the broker would run out of memory if it did not slow down the producer. Does not affect Stomp clients as the sends are ack'd by the broker. (Since ActiveMQ-CPP 2.2.1)
The ProducerWindowSize is the maximum number of bytes in memory that a producer will transmit to a broker before waiting for acknowledgement messages from the broker that it has accepted the previously sent messages. In other words, this how you configure the producer flow control window that is used for async sends where the client is responsible for managing memory usage. The default value of 0 means no flow control at the client. See also Producer Flow Control. This option only affects Openwire clients as Stomp does not have a means of notifying the clients of accepted messages asynchronously. (Since ActiveMQ-CPP 2.2.2)
The amount of time to wait for a response from the broker when shutting down. Normally we want a response to indicate that the client has been disconnected cleanly, but we don't want to wait forever, however if you do, set this to zero. (Since ActiveMQ-CPP 2.2.1)
Forces the use of Async Sends which adds a massive performance boost; but means that the send() method will return immediately whether the message has been sent or not which could lead to message loss. Normally only Persistant messages that are not part of a transaction are sent synchronously, using this options forces those messages to also be async. (Since ActiveMQ-CPP 2.2.2)
Forces all messages that are sent to be sent synchronously overriding any usage of the useAsyncSend flag. This can reduce performance in some cases since the only messages we normally send synchronously are Persistent messages not sent in a transaction. This options guarantees that no send will return until the broker has acknowledge receipt of the message. (Since ActiveMQ-CPP 2.2.2)
Should outgoing messages have their body portion compressed using the ZLib compression algorithms (Since v3.2.0)
Should the broker dispatch messages asynchronously to the consumer, this causes all consumers from this Connection to use this setting. (Since v3.2.0)
Connection Policy Options
As of version 3.2.0 the Connection object supports policies that control various aspects its behaviour and of the Consumer objects it creates.
Max prefetch for Durable Topics
Max prefetch for a Queue Browser
Max prefetch for a Queue or Temp Queue
Max prefetch for a Topic or Temp Topic
Used to extend the redelivery window when the _useExponentialBackOff option is enabled.
Percentage of randomness to add to redelivery backoff to keep multiple consumers in a rollback from redelivering at the same time.
Amount of time to wait before starting redeliveries, in milliseconds.
Maximum number of time to attempt a redelivery before giving up and NAck'ing the message.
Should the Random avoidance percentage be added into the redelivery delay.
Should redeliveries be slowed on each cycle.
Wire Format Protocol Options
Selects the wire format to use. Out of the box, can be either stomp or openwire.
Should the stack trace of exception that occur on the broker be sent to the client? Only used by openwire protocol.
Should commonly repeated values be cached so that less marshalling occurs? Only used by openwire protocol.
Does not affect the wire format, but provides a hint to the peer that TCP nodelay should be enabled on the communications Socket. Only used by openwire protocol.
Should serialized messages include a payload length prefix? Only used by openwire protocol.
Should wire size be optimized over CPU usage? Only used by the openwire protocol.
The maximum inactivity duration (before which the socket is considered dead) in milliseconds. On some platforms it can take a long time for a socket to appear to die, so we allow the broker to kill connections if they are inactive for a period of time. Use by some transports to enable a keep alive heart beat feature. Set to a value <= 0 to disable inactivity monitoring.
The initial delay in starting the maximum inactivity checks (and, yes, the word 'Inital' is supposed to be misspelled like that)
Destination URI Parameters
d = session->createTopic("com.foo?consumer.prefetchSize=2000&consumer.noLocal=true");
The number of message the consumer will prefetch.
Use to control if messages are dropped if a slow consumer situation exists.
Same as the noLocal flag on a Topic consumer. Exposed here so that it can be used with a queue.
Should the broker dispatch messages asynchronously to the consumer.
Is this a Retroactive Consumer.
JMS Selector used with the consumer.
Is this an Exclusive Consumer.
Allows you to configure a Consumer Priority.
Enables an optimised acknowledgement mode where messages are acknowledged in batches rather than individually. Alternatively, you could use Session.DUPS_OK_ACKNOWLEDGE acknowledgement mode for the consumers which can often be faster. WARNING enabling this issue could cause some issues with auto-acknowledgement on reconnection
Sets whether or not retroactive consumers are enabled. Retroactive consumers allow non-durable topic subscribers to receive old messages that were published before the non-durable subscriber started.