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 NMS.ActiveMQ client. The tables below show the comprehensive set of parameters.
Connection URI Parameters
Using the Generic NMSConnectionFactory class would look as follows:
You can also use the ActiveMQ ConecctionFactory implementation directory:
Uses TCP/IP Sockets to connect to the Broker.
Uses TCP/IP Sockets to connect to the Broker with an added SSL layer.
Uses The Discovery Transport to find a Broker
Uses the Failover Transport to connect and reconnect to one or more Brokers
TCP Transport Options
Log data that is sent across the Transport.
Amount of Data to buffer from the Socket
Amount of Data to buffer before writing to the Socket
Time to wait for more data, zero means wait infinitely
Timeout on sends, 0 means wait forever for completion
Time to wait before a Request Command is considered to have failed
Discovery Transport Options
Failover Transport Options
Prior to NMS.ActiveMQ v1.4.0 the failover transport options did not use the transport.* prefix.
Time that a send operation blocks before failing.
Time in Milliseconds that the transport waits before attempting to reconnect the first time.
The max time in Milliseconds that the transport will wait before attempting to reconnect.
The amount by which the reconnect delay will be multiplied by if useExponentialBackOff is enabled.
Should the delay between connection attempt grow on each try up to the max reconnect delay.
Should the Uri to connect to be chosen at random from the list of available Uris.
Maximum number of time the transport will attempt to reconnect before failing (0 means infinite retries)
Maximum number of time the transport will attempt to reconnect before failing when there has never been a connection made. (0 means infinite retries) (included in NMS.ActiveMQ v1.5.0+)
The delay in milliseconds that the transport waits before attempting a reconnection.
Should the Failover transport maintain hot backups.
If enabled, how many hot backup connections are made.
keep a cache of in-flight messages that will flushed to a broker on reconnect
Number of messages that are cached if trackMessages is enabled.
Update the list of known brokers based on BrokerInfo messages sent to the client.
Connection options can either be set via the connection.* prefix or the nms.* prefix similar to the java client's jms.* prefix settings.
Are message sent Asynchronously.
Should the close command be sent Asynchronously
Causes all messages a Producer sends to be sent Asynchronously.
Copies the Message objects a Producer sends so that the client can reuse Message objects without affecting an in-flight message.
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
Should message bodies be compressed before being sent.
Should message acks be sent asynchronously
Should messages be delivered to the client based on the value of the Message Priority header.
Should the broker dispatch messages asynchronously to the connection's consumers.
Should the client watch for advisory messages from the broker to track the creation and deletion of temporary destinations.
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
The number of message the consumer will prefetch. Removed in v1.7.0 use connection prefetch policy instead.
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.