112 lines
6.1 KiB
Plaintext
112 lines
6.1 KiB
Plaintext
= OpenWire
|
|
:idprefix:
|
|
:idseparator: -
|
|
|
|
Apache ActiveMQ Artemis supports the http://activemq.apache.org/openwire.html[OpenWire] protocol so that an Apache ActiveMQ "Classic" JMS client can talk directly to an Apache ActiveMQ Artemis server.
|
|
By default there is an `acceptor` configured to accept OpenWire connections on port `61616`.
|
|
|
|
See the general xref:protocols-interoperability.adoc#protocols-and-interoperability[Protocols and Interoperability] chapter for details on configuring an `acceptor` for OpenWire.
|
|
|
|
Refer to the OpenWire xref:examples.adoc[examples] for a look at this functionality in action.
|
|
|
|
== Connection Monitoring
|
|
|
|
OpenWire has a few parameters to control how each connection is monitored, they are:
|
|
|
|
maxInactivityDuration::
|
|
It specifies the time (milliseconds) after which the connection is closed by the broker if no data was received.
|
|
Default value is 30000.
|
|
|
|
maxInactivityDurationInitalDelay::
|
|
It specifies the maximum delay (milliseconds) before inactivity monitoring is started on the connection.
|
|
It can be useful if a broker is under load with many connections being created concurrently.
|
|
Default value is 10000.
|
|
|
|
useInactivityMonitor::
|
|
A value of false disables the InactivityMonitor completely and connections will never time out.
|
|
By default it is enabled.
|
|
On broker side you don't neet set this.
|
|
Instead you can set the connection-ttl to -1.
|
|
|
|
useKeepAlive::
|
|
Indicates whether to send a KeepAliveInfo on an idle connection to prevent it from timing out.
|
|
Enabled by default.
|
|
Disabling the keep alive will still make connections time out if no data was received on the connection for the specified amount of time.
|
|
|
|
Note at the beginning the InactivityMonitor negotiates the appropriate `maxInactivityDuration` and `maxInactivityDurationInitalDelay`.
|
|
The shortest duration is taken for the connection.
|
|
|
|
Fore more details please see http://activemq.apache.org/activemq-inactivitymonitor.html[ActiveMQ InactivityMonitor].
|
|
|
|
== Disable/Enable Advisories
|
|
|
|
By default, advisory topics (http://activemq.apache.org/advisory-message.html[ActiveMQ Advisory]) are created in order to send certain type of advisory messages to listening clients.
|
|
As a result, advisory addresses and queues will be displayed on the management console, along with user deployed addresses and queues.
|
|
This sometimes cause confusion because the advisory objects are internally managed without user being aware of them.
|
|
In addition, users may not want the advisory topics at all (they cause extra resources and performance penalty) and it is convenient to disable them at all from the broker side.
|
|
|
|
The protocol provides two parameters to control advisory behaviors on the broker side.
|
|
|
|
supportAdvisory::
|
|
Indicates whether the broker supports advisory messages.
|
|
If the value is true, advisory addresses/queues will be created.
|
|
If the value is false, no advisory addresses/queues are created.
|
|
Default value is `true`.
|
|
|
|
suppressInternalManagementObjects::
|
|
Indicates whether advisory addresses/queues, if any, will be registered to management service (e.g. JMX registry).
|
|
If set to true, no advisory addresses/queues will be registered.
|
|
If set to false, those are registered and will be displayed on the management console.
|
|
Default value is `true`.
|
|
|
|
The two parameters are configured on an OpenWire `acceptor`, e.g.:
|
|
|
|
[,xml]
|
|
----
|
|
<acceptor name="artemis">tcp://localhost:61616?protocols=OPENWIRE;supportAdvisory=true;suppressInternalManagementObjects=false</acceptor>
|
|
----
|
|
|
|
== OpenWire Destination Cache
|
|
|
|
For improved performance of the broker we keep a cache of recently used destinations, so that when new messages are dispatched to them, we do not have to do a lookup every time.
|
|
By default, this cache holds up to `16` destinations.
|
|
If additional destinations are added they will overwrite older records.
|
|
If you are dealing with a large amount of queues you might want to increase this value, which is done via configuration option: `openWireDestinationCacheSize` set on the OpenWire `acceptor` like this:
|
|
|
|
[,xml]
|
|
----
|
|
<acceptor name="artemis">tcp://localhost:61616?protocols=OPENWIRE;openWireDestinationCacheSize=64</acceptor>
|
|
----
|
|
|
|
This cache has to be set to a power of 2, i.e.: `2`, `16`, `128` and so on.
|
|
|
|
== Virtual Topic Consumer Destination Translation
|
|
|
|
For existing OpenWire consumers of virtual topic destinations it is possible to configure a mapping function that will translate the virtual topic consumer destination into a FQQN address.
|
|
This address will then represents the consumer as a multicast binding to an address representing the virtual topic.
|
|
|
|
The configuration string list property `virtualTopicConsumerWildcards` has parts separated by a `;`.
|
|
The first is the classic style destination filter that identifies the destination as belonging to a virtual topic.
|
|
The second identifies the number of `paths` that identify the consumer queue such that it can be parsed from the destination.
|
|
Any subsequent parts are additional configuration parameters for that mapping.
|
|
|
|
For example, the default virtual topic with consumer prefix of `Consumer.*.`, would require a `virtualTopicConsumerWildcards` filter of `Consumer.*.>;2`.
|
|
As a url parameter this transforms to `Consumer.*.%3E%3B2` when the url significant characters `>;` are escaped with their hex code points.
|
|
In an `acceptor` url it would be:
|
|
|
|
[,xml]
|
|
----
|
|
<acceptor name="artemis">tcp://localhost:61616?protocols=OPENWIRE;virtualTopicConsumerWildcards=Consumer.*.%3E%3B2</acceptor>
|
|
----
|
|
|
|
This will translate `Consumer.A.VirtualTopic.Orders` into a FQQN of `VirtualTopic.Orders::Consumer.A.VirtualTopic.Orders` using the int component `2` of the configuration to identify the consumer queue as the first two paths of the destination.
|
|
`virtualTopicConsumerWildcards` is multi valued using a `,` separator.
|
|
|
|
=== selectorAware
|
|
|
|
The mappings support an optional parameter, `selectorAware` which when true, transfers any selector information from the OpenWire consumer into a queue filter of any auto-created subscription queue.
|
|
|
|
NOTE: the selector/filter is persisted with the queue binding in the normal way, such that it works independent of connected consumers.
|
|
|
|
Please see Virtual Topic Mapping example contained in the OpenWire xref:examples.adoc#examples[examples].
|