documentation updates
This commit is contained in:
Andy Taylor
parent
e52622cffa
commit
d415f0d6e2
|
|
@ -22,7 +22,7 @@ configuration:
|
|||
<address-setting match="jms.queue.lastValueQueue">
|
||||
<last-value-queue>true</last-value-queue>
|
||||
</address-setting>
|
||||
|
||||
|
||||
|
||||
Shown are the required params for the connector service and are:
|
||||
|
||||
|
|
@ -74,7 +74,7 @@ message.setStringProperty("AEROGEAR_ALERT", "Hello this is a notification from A
|
|||
|
||||
producer.send(message);
|
||||
```
|
||||
|
||||
|
||||
|
||||
The 'AEROGEAR_ALERT' property will be the alert sent to the mobile
|
||||
device.
|
||||
|
|
@ -91,14 +91,14 @@ ttl of a message you would:
|
|||
``` java
|
||||
message.setIntProperty("AEROGEAR_TTL", 1234);
|
||||
```
|
||||
|
||||
|
||||
|
||||
or if you wanted to set the list of variants you would use:
|
||||
|
||||
``` java
|
||||
message.setStringProperty("AEROGEAR_VARIANTS", "variant1,variant2,variant3");
|
||||
```
|
||||
```
|
||||
```
|
||||
```
|
||||
|
||||
Again refer to the AeroGear documentation for a more in depth view on
|
||||
how to use these settings
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ to the client, and the client can then free up space in the buffer.
|
|||
If you are using JMS and you're using the JMS service on the server to
|
||||
load your JMS connection factory instances into JNDI then this parameter
|
||||
can be configured in the jms configuration using the element
|
||||
`confirmation-window-size` a. If you're using JMS but not using JNDI
|
||||
`confirmationWindowSize` a. If you're using JMS but not using JNDI
|
||||
then you can set these values directly on the
|
||||
`ActiveMQConnectionFactory` instance using the appropriate setter
|
||||
method.
|
||||
|
|
@ -76,12 +76,12 @@ once*delivery guarantees.
|
|||
|
||||
Client reconnection is configured using the following parameters:
|
||||
|
||||
- `retry-interval`. This optional parameter determines the period in
|
||||
- `retryInterval`. This optional parameter determines the period in
|
||||
milliseconds between subsequent reconnection attempts, if the
|
||||
connection to the target server has failed. The default value is
|
||||
`2000` milliseconds.
|
||||
|
||||
- `retry-interval-multiplier`. This optional parameter determines
|
||||
- `retryIntervalMultiplier`. This optional parameter determines
|
||||
determines a multiplier to apply to the time since the last retry to
|
||||
compute the time to the next retry.
|
||||
|
||||
|
|
@ -90,22 +90,22 @@ Client reconnection is configured using the following parameters:
|
|||
|
||||
Let's take an example:
|
||||
|
||||
If we set `retry-interval` to `1000` ms and we set
|
||||
`retry-interval-multiplier` to `2.0`, then, if the first reconnect
|
||||
If we set `retryInterval` to `1000` ms and we set
|
||||
`retryIntervalMultiplier` to `2.0`, then, if the first reconnect
|
||||
attempt fails, we will wait `1000` ms then `2000` ms then `4000` ms
|
||||
between subsequent reconnection attempts.
|
||||
|
||||
The default value is `1.0` meaning each reconnect attempt is spaced
|
||||
at equal intervals.
|
||||
|
||||
- `max-retry-interval`. This optional parameter determines the maximum
|
||||
- `maxRetryInterval`. This optional parameter determines the maximum
|
||||
retry interval that will be used. When setting
|
||||
`retry-interval-multiplier` it would otherwise be possible that
|
||||
`retryIntervalMultiplier` it would otherwise be possible that
|
||||
subsequent retries exponentially increase to ridiculously large
|
||||
values. By setting this parameter you can set an upper limit on that
|
||||
value. The default value is `2000` milliseconds.
|
||||
|
||||
- `reconnect-attempts`. This optional parameter determines the total
|
||||
- `reconnectAttempts`. This optional parameter determines the total
|
||||
number of reconnect attempts to make before giving up and shutting
|
||||
down. A value of `-1` signifies an unlimited number of attempts. The
|
||||
default value is `0`.
|
||||
|
|
@ -115,11 +115,7 @@ JMS connection factory instances then you can specify these parameters
|
|||
in the JNDI context environment in, e.g. `jndi.properties`:
|
||||
|
||||
java.naming.factory.initial = org.apache.activemq.jndi.ActiveMQInitialContextFactory
|
||||
java.naming.provider.url = tcp://localhost:61616
|
||||
connection.ConnectionFactory.retryInterval=1000
|
||||
connection.ConnectionFactory.retryIntervalMultiplier=1.5
|
||||
connection.ConnectionFactory.maxRetryInterval=60000
|
||||
connection.ConnectionFactory.reconnectAttempts=1000
|
||||
connection.ConnectionFactory=tcp://localhost:61616?retryInterval=1000&retryIntervalMultiplier=1.5&maxRetryInterval=60000&reconnectAttempts=1000
|
||||
|
||||
If you're using JMS, but instantiating your JMS connection factory
|
||||
directly, you can specify the parameters using the appropriate setter
|
||||
|
|
|
|||
|
|
@ -7,12 +7,6 @@ together in order to share message processing load. Each active node in
|
|||
the cluster is an active ActiveMQ server which manages its own messages
|
||||
and handles its own connections.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> The *clustered* parameter is deprecated and no longer needed for
|
||||
> setting up a cluster. If your configuration contains this parameter it
|
||||
> will be ignored and a message with the ID `HQ221038` will be logged.
|
||||
|
||||
The cluster is formed by each node declaring *cluster connections* to
|
||||
other nodes in the core configuration file `activemq-configuration.xml`.
|
||||
When a node forms a cluster connection to another node, internally it
|
||||
|
|
@ -365,7 +359,7 @@ group-port from the corresponding `broadcast-group` on the server. Let's
|
|||
take a look at an example:
|
||||
|
||||
java.naming.factory.initial = org.apache.activemq.jndi.ActiveMQInitialContextFactory
|
||||
java.naming.provider.url = udp://231.7.7.7:9876
|
||||
connectionFactory.myConnectionFactory=udp://231.7.7.7:9876
|
||||
|
||||
The element `discovery-group-ref` specifies the name of a discovery
|
||||
group defined in `activemq-configuration.xml`.
|
||||
|
|
@ -469,13 +463,13 @@ JMS connection factory instances then you can specify these parameters
|
|||
in the JNDI context environment in, e.g. `jndi.properties`:
|
||||
|
||||
java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory
|
||||
java.naming.provider.url=tcp://myhost:61616,myhost2:61616
|
||||
connectionFactory.myConnectionFactory=(tcp://myhost:61616,tcp://myhost2:61616)
|
||||
|
||||
The `java.naming.provider.url` contains a list of servers to use for the
|
||||
The `connectionFactory.myConnectionFactory` contains a list of servers to use for the
|
||||
connection factory. When this connection factory used client application
|
||||
and JMS connections are created from it, those connections will be
|
||||
load-balanced across the list of servers defined by the
|
||||
`java.naming.provider.url`.
|
||||
load-balanced across the list of servers defined within the brackets `()`.
|
||||
The brackets are expanded so the same query cab be appended after the last bracket for ease.
|
||||
|
||||
If you're using JMS, but you're not using JNDI to lookup a connection
|
||||
factory - you're instantiating the JMS connection factory directly then
|
||||
|
|
@ -846,8 +840,7 @@ in the JNDI context environment in, e.g. `jndi.properties`, to specify
|
|||
the load balancing policy directly:
|
||||
|
||||
java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory
|
||||
java.naming.provider.url=tcp://localhost:61616
|
||||
connection.ConnectionFactory.loadBalancingPolicyClassName=org.apache.activemq.api.core.client.loadbalance.RandomConnectionLoadBalancingPolicy
|
||||
connection.myConnectionFactory=tcp://localhost:61616?loadBalancingPolicyClassName=org.apache.activemq.api.core.client.loadbalance.RandomConnectionLoadBalancingPolicy
|
||||
|
||||
The above example would instantiate a JMS connection factory that uses
|
||||
the random connection load balancing policy.
|
||||
|
|
|
|||
|
|
@ -1,9 +1,5 @@
|
|||
# Configuring the Transport
|
||||
|
||||
ActiveMQ has a fully pluggable and highly flexible transport layer and
|
||||
defines its own Service Provider Interface (SPI) to make plugging in a
|
||||
new transport provider relatively straightforward.
|
||||
|
||||
In this chapter we'll describe the concepts required for understanding
|
||||
ActiveMQ transports and where and how they're configured.
|
||||
|
||||
|
|
@ -200,7 +196,7 @@ Netty for simple TCP:
|
|||
> The `host` and `port` parameters are only used in the core API, in
|
||||
> XML configuration these are set in the URI host and port.
|
||||
|
||||
- `use-nio`. If this is `true` then Java non blocking NIO will be
|
||||
- `useNio`. If this is `true` then Java non blocking NIO will be
|
||||
used. If set to `false` then old blocking Java IO will be used.
|
||||
|
||||
If you require the server to handle many concurrent connections, we
|
||||
|
|
@ -264,7 +260,7 @@ Netty for simple TCP:
|
|||
`32768` bytes (32KiB).
|
||||
|
||||
- `batchDelay`. Before writing packets to the transport, ActiveMQ can
|
||||
be configured to batch up writes for a maximum of `batch-delay`
|
||||
be configured to batch up writes for a maximum of `batchDelay`
|
||||
milliseconds. This can increase overall throughput for very small
|
||||
messages. It does so at the expense of an increase in average
|
||||
latency for message transfer. The default value for this property is
|
||||
|
|
@ -277,9 +273,9 @@ Netty for simple TCP:
|
|||
small number of consumers, but at the cost of overall throughput and
|
||||
scalability - especially on multi-core machines. If you want the
|
||||
lowest latency and a possible reduction in throughput then you can
|
||||
use the default value for `direct-deliver` (i.e. true). If you are
|
||||
use the default value for `directDeliver` (i.e. true). If you are
|
||||
willing to take some small extra hit on latency but want the highest
|
||||
throughput set `direct-deliver` to `false
|
||||
throughput set `directDeliver` to `false
|
||||
`.
|
||||
|
||||
- `nioRemotingThreads`. When configured to use NIO, ActiveMQ will,
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ try
|
|||
sf = locator.createClientSessionFactory();;
|
||||
|
||||
session = sf.createSession(...);
|
||||
|
||||
|
||||
... do some stuff with the session...
|
||||
}
|
||||
finally
|
||||
|
|
@ -34,7 +34,7 @@ finally
|
|||
{
|
||||
session.close();
|
||||
}
|
||||
|
||||
|
||||
if (sf != null)
|
||||
{
|
||||
sf.close();
|
||||
|
|
@ -99,7 +99,7 @@ If you're using JMS, the connection TTL is defined by the
|
|||
`ConnectionTTL` attribute on a `ActiveMQConnectionFactory` instance, or
|
||||
if you're deploying JMS connection factory instances direct into JNDI on
|
||||
the server side, you can specify it in the xml config, using the
|
||||
parameter `connection-ttl`.
|
||||
parameter `connectionTtl`.
|
||||
|
||||
The default value for connection ttl on an "unreliable" connection (e.g.
|
||||
a Netty connection) is `60000`ms, i.e. 1 minute. The default value for
|
||||
|
|
@ -156,10 +156,7 @@ connection failed and will either initiate failover, or call any
|
|||
using JMS) depending on how it has been configured.
|
||||
|
||||
If you're using JMS it's defined by the `ClientFailureCheckPeriod`
|
||||
attribute on a `ActiveMQConnectionFactory` instance, or if you're
|
||||
deploying JMS connection factory instances direct into JNDI on the
|
||||
server side, you can specify it in the `activemq-jms.xml ` configuration
|
||||
file, using the parameter `client-failure-check-period`.
|
||||
attribute on a `ActiveMQConnectionFactory` instance..
|
||||
|
||||
The default value for client failure check period on an "unreliable"
|
||||
connection (e.g. a Netty connection) is `30000`ms, i.e. 30 seconds. The
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ by generating a UUID.
|
|||
Here's an example of setting the property using the core API:
|
||||
|
||||
``` java
|
||||
...
|
||||
...
|
||||
|
||||
ClientMessage message = session.createMessage(true);
|
||||
|
||||
|
|
@ -87,7 +87,7 @@ message.setStringProperty(HDR_DUPLICATE_DETECTION_ID, myUniqueID);
|
|||
And here's an example using the JMS API:
|
||||
|
||||
``` java
|
||||
...
|
||||
...
|
||||
|
||||
Message jmsMessage = session.createMessage();
|
||||
|
||||
|
|
|
|||
|
|
@ -121,7 +121,7 @@ import org.apache.activemq.core.config.impl.ConfigurationImpl;
|
|||
|
||||
Configuration config = new ConfigurationImpl();
|
||||
HashSet<TransportConfiguration> transports = new HashSet<TransportConfiguration>();
|
||||
|
||||
|
||||
transports.add(new TransportConfiguration(NettyAcceptorFactory.class.getName()));
|
||||
transports.add(new TransportConfiguration(InVMAcceptorFactory.class.getName()));
|
||||
|
||||
|
|
|
|||
|
|
@ -743,13 +743,6 @@ XA Send
|
|||
|
||||
The `xa-send` example shows you how message sending behaves in an XA
|
||||
transaction in ActiveMQ.
|
||||
|
||||
XA with Transaction Manager
|
||||
---------------------------
|
||||
|
||||
The `xa-with-jta` example shows you how to use JTA interfaces to control
|
||||
transactions with ActiveMQ.
|
||||
|
||||
Core API Examples
|
||||
=================
|
||||
|
||||
|
|
|
|||
|
|
@ -29,10 +29,10 @@ considerably reduce performance.
|
|||
|
||||
To prevent this, ActiveMQ pre-fetches messages into a buffer on each
|
||||
consumer. The total maximum size of messages (in bytes) that will be
|
||||
buffered on each consumer is determined by the `consumer-window-size`
|
||||
buffered on each consumer is determined by the `consumerWindowSize`
|
||||
parameter.
|
||||
|
||||
By default, the `consumer-window-size` is set to 1 MiB (1024 \* 1024
|
||||
By default, the `consumerWindowSize` is set to 1 MiB (1024 \* 1024
|
||||
bytes).
|
||||
|
||||
The value can be:
|
||||
|
|
@ -52,7 +52,7 @@ two extremes:
|
|||
Fast consumers can process messages as fast as they consume them (or
|
||||
even faster)
|
||||
|
||||
To allow fast consumers, set the `consumer-window-size` to -1. This
|
||||
To allow fast consumers, set the `consumerWindowSize` to -1. This
|
||||
will allow *unbounded* message buffering on the client side.
|
||||
|
||||
Use this setting with caution: it can overflow the client memory if
|
||||
|
|
@ -73,7 +73,7 @@ thus preventing them being processed by the fast consumer. The fast
|
|||
consumer is therefore sitting idle when it could be processing the
|
||||
other messages.
|
||||
|
||||
To allow slow consumers, set the `consumer-window-size` to 0 (for no
|
||||
To allow slow consumers, set the `consumerWindowSize` to 0 (for no
|
||||
buffer at all). This will prevent the slow consumer from buffering
|
||||
any messages on the client side. Messages will remain on the server
|
||||
side ready to be consumed by other consumers.
|
||||
|
|
@ -83,7 +83,7 @@ multiple consumers on a queue.
|
|||
|
||||
Most of the consumers cannot be clearly identified as fast or slow
|
||||
consumers but are in-between. In that case, setting the value of
|
||||
`consumer-window-size` to optimize performance depends on the messaging
|
||||
`consumerWindowSize` to optimize performance depends on the messaging
|
||||
use case and requires benchmarks to find the optimal value, but a value
|
||||
of 1MiB is fine in most cases.
|
||||
|
||||
|
|
@ -102,8 +102,7 @@ environment, e.g. `jndi.properties`. Here's a simple example using the
|
|||
by default:
|
||||
|
||||
java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory
|
||||
java.naming.provider.url=tcp://localhost:61616
|
||||
connection.ConnectionFactory.consumerWindowSize=0
|
||||
connectionFactory.myConnectionFactory=tcp://localhost:61616?consumerWindowSize=0
|
||||
|
||||
If the connection factory is directly instantiated, the consumer window
|
||||
size is specified by `ActiveMQConnectionFactory.setConsumerWindowSize()`
|
||||
|
|
@ -140,8 +139,7 @@ max rate can be configured in the JNDI context environment, e.g.
|
|||
connection factory which is available in the context by default:
|
||||
|
||||
java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory
|
||||
java.naming.provider.url=tcp://localhost:61616
|
||||
connection.ConnectionFactory.consumerMaxRate=10
|
||||
java.naming.provider.url=tcp://localhost:61616?consumerMaxRate=10
|
||||
|
||||
If the connection factory is directly instantiated, the max rate size
|
||||
can be set via the `ActiveMQConnectionFactory.setConsumerMaxRate(int
|
||||
|
|
@ -194,8 +192,7 @@ e.g. `jndi.properties`. Here's a simple example using the
|
|||
by default:
|
||||
|
||||
java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory
|
||||
java.naming.provider.url=tcp://localhost:61616
|
||||
connection.ConnectionFactory.producerWindowSize=10
|
||||
connectionFactory.myConnectionFactory=tcp://localhost:61616?producerWindowSize=10
|
||||
|
||||
If the connection factory is directly instantiated, the producer window
|
||||
size can be set via the
|
||||
|
|
@ -289,8 +286,7 @@ max rate size can be configured in the JNDI context environment, e.g.
|
|||
connection factory which is available in the context by default:
|
||||
|
||||
java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory
|
||||
java.naming.provider.url=tcp://localhost:61616
|
||||
connection.ConnectionFactory.producerMaxRate=10
|
||||
connectionFactory.myConnectionFactory=tcp://localhost:61616?producerMaxRate=10
|
||||
|
||||
If the connection factory is directly instantiated, the max rate size
|
||||
can be set via the `ActiveMQConnectionFactory.setProducerMaxRate(int
|
||||
|
|
|
|||
|
|
@ -6,8 +6,8 @@ broker can be configured to shutdown *gracefully* using the
|
|||
`graceful-shutdown-enabled` boolean configuration parameter.
|
||||
|
||||
When the `graceful-shutdown-enabled` configuration parameter is `true`
|
||||
and the broker is shutdown it will first prevent any additional clients
|
||||
from connecting and then it will wait for any existing connections to
|
||||
and the broker is shutdown it will first prevent any additional clients
|
||||
from connecting and then it will wait for any existing connections to
|
||||
be terminated by the client before completing the shutdown process. The
|
||||
default value is `false`.
|
||||
|
||||
|
|
@ -18,4 +18,4 @@ gracefully. To deal with this of situation the
|
|||
tells the broker (in milliseconds) how long to wait for all clients to
|
||||
disconnect before forcefully disconnecting the clients and proceeding
|
||||
with the shutdown process. The default value is `-1` which means the
|
||||
broker will wait indefinitely for clients to disconnect.
|
||||
broker will wait indefinitely for clients to disconnect.
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ or
|
|||
<ha-policy>
|
||||
<shared-store/>
|
||||
</ha-policy>
|
||||
|
||||
|
||||
|
||||
As well as these 2 strategies there is also a 3rd called `live-only`.
|
||||
This of course means there will be no Backup Strategy and is the default
|
||||
|
|
@ -72,7 +72,7 @@ backup). This would look something like:
|
|||
<master/>
|
||||
</replication>
|
||||
</ha-policy>
|
||||
|
||||
|
||||
|
||||
or
|
||||
|
||||
|
|
@ -81,7 +81,7 @@ or
|
|||
<slave/>
|
||||
</shared-store/>
|
||||
</ha-policy>
|
||||
|
||||
|
||||
|
||||
or
|
||||
|
||||
|
|
@ -90,7 +90,7 @@ or
|
|||
<colocated/>
|
||||
</replication>
|
||||
</ha-policy>
|
||||
|
||||
|
||||
|
||||
### Data Replication
|
||||
|
||||
|
|
@ -213,7 +213,7 @@ configure the live server in ' `activemq-configuration.xml` to have:
|
|||
...
|
||||
</cluster-connection>
|
||||
</cluster-connections>
|
||||
|
||||
|
||||
|
||||
The backup server must be similarly configured but as a `slave`
|
||||
|
||||
|
|
@ -364,7 +364,7 @@ id via the `ha-policy` configuration in `activemq-configuration.xml`:
|
|||
...
|
||||
</cluster-connection>
|
||||
</cluster-connections>
|
||||
|
||||
|
||||
|
||||
The backup server must also be configured as a backup.
|
||||
|
||||
|
|
@ -373,7 +373,7 @@ The backup server must also be configured as a backup.
|
|||
<slave/>
|
||||
</shared-store>
|
||||
</ha-policy>
|
||||
|
||||
|
||||
|
||||
In order for live - backup groups to operate properly with a shared
|
||||
store, both servers must have configured the location of journal
|
||||
|
|
@ -409,7 +409,7 @@ stop. This configuration would look like:
|
|||
</slave>
|
||||
</shared-store>
|
||||
</ha-policy>
|
||||
|
||||
|
||||
|
||||
The `failback-delay` configures how long the backup must wait after
|
||||
automatically stopping before it restarts. This is to gives the live
|
||||
|
|
@ -581,7 +581,7 @@ so:
|
|||
</colocated>
|
||||
<replication>
|
||||
</ha-policy>
|
||||
|
||||
|
||||
|
||||
the above example is configured to use replication, in this case the
|
||||
`master` and `slave` configurations must match those for normal
|
||||
|
|
@ -619,7 +619,7 @@ adding them to the `ha-policy` configuration like so:
|
|||
</excludes>
|
||||
.........
|
||||
</ha-policy>
|
||||
|
||||
|
||||
|
||||
#### Configuring Directories
|
||||
|
||||
|
|
@ -699,7 +699,7 @@ like:
|
|||
</scale-down>
|
||||
</live-only>
|
||||
</ha-policy>
|
||||
|
||||
|
||||
|
||||
In this instance the server is configured to use a specific connector to
|
||||
scale down, if a connector is not specified then the first INVM
|
||||
|
|
@ -714,7 +714,7 @@ this would look like:
|
|||
</scale-down>
|
||||
</live-only>
|
||||
</ha-policy>
|
||||
|
||||
|
||||
|
||||
#### Scale Down with groups
|
||||
|
||||
|
|
@ -730,7 +730,7 @@ like so:
|
|||
</scale-down>
|
||||
</live-only>
|
||||
</ha-policy>
|
||||
|
||||
|
||||
|
||||
In this scenario only servers that belong to the group `my-group` will
|
||||
be scaled down to
|
||||
|
|
@ -774,7 +774,7 @@ typical configuration would look like:
|
|||
</colocated>
|
||||
</replication>
|
||||
</ha-policy>
|
||||
|
||||
|
||||
|
||||
#### Scale Down and Clients
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ An interceptor must implement the `Interceptor interface`:
|
|||
package org.apache.activemq.api.core.interceptor;
|
||||
|
||||
public interface Interceptor
|
||||
{
|
||||
{
|
||||
boolean intercept(Packet packet, RemotingConnection connection) throws ActiveMQException;
|
||||
}
|
||||
```
|
||||
|
|
|
|||
|
|
@ -95,7 +95,7 @@ seconds.
|
|||
|
||||
#### Using JMS destinations
|
||||
|
||||
As explained in [Mapping JMS Concepts to the Core API](jms-core-mapping.md),
|
||||
As explained in [Mapping JMS Concepts to the Core API](jms-core-mapping.md),
|
||||
JMS destinations are also mapped to ActiveMQ
|
||||
addresses and queues. If you want to use Stomp to send messages to JMS
|
||||
destinations, the Stomp destinations must follow the same convention:
|
||||
|
|
@ -247,7 +247,7 @@ specification. To enable AMQP you must configure a Netty Acceptor to
|
|||
receive AMQP clients, like so:
|
||||
|
||||
<acceptor name="stomp-acceptor">tcp://localhost:5672?protocols=AMQP</acceptor>
|
||||
|
||||
|
||||
|
||||
ActiveMQ will then accept AMQP 1.0 clients on port 5672 which is the
|
||||
default AMQP port.
|
||||
|
|
@ -305,7 +305,7 @@ ActiveMQ JMS client can talk directly to a ActiveMQ server. To enable
|
|||
OpenWire support you must configure a Netty Acceptor, like so:
|
||||
|
||||
<acceptor name="openwire-acceptor">tcp://localhost:61616?protocols=OPENWIRE</acceptor>
|
||||
|
||||
|
||||
|
||||
The ActiveMQ server will then listens on port 61616 for incoming
|
||||
openwire commands. Please note the "protocols" is not mandatory here.
|
||||
|
|
|
|||
|
|
@ -300,9 +300,7 @@ you will have to bear in mind timeout issues.
|
|||
|
||||
### Examples
|
||||
|
||||
Please see ? which shows how to configure and use a JMS Bridge with
|
||||
Please see [the examples chapter](examples.md) which shows how to configure and use a JMS Bridge with
|
||||
JBoss AS to send messages to the source destination and consume them
|
||||
from the target destination.
|
||||
|
||||
Please see ? which shows how to configure and use a JMS Bridge between
|
||||
from the target destination and how to configure and use a JMS Bridge between
|
||||
two standalone ActiveMQ servers.
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ directory.
|
|||
|
||||
Any message larger than a certain size is considered a large message.
|
||||
Large messages will be split up and sent in fragments. This is
|
||||
determined by the parameter `min-large-message-size`
|
||||
determined by the parameter `minLargeMessageSize`
|
||||
|
||||
> **Note**
|
||||
>
|
||||
|
|
@ -56,7 +56,7 @@ determined by the parameter `min-large-message-size`
|
|||
> message data is filled with ASCII characters (which are 1 byte) the
|
||||
> size of the resulting ActiveMQ message would roughly double. This is
|
||||
> important when calculating the size of a "large" message as it may
|
||||
> appear to be less than the `min-large-message-size` before it is sent,
|
||||
> appear to be less than the `minLargeMessageSize` before it is sent,
|
||||
> but it then turns into a "large" message once it is encoded.
|
||||
|
||||
The default value is 100KiB.
|
||||
|
|
@ -86,8 +86,7 @@ environment, e.g. `jndi.properties`. Here's a simple example using the
|
|||
by default:
|
||||
|
||||
java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory
|
||||
java.naming.provider.url=tcp://localhost:61616
|
||||
connection.ConnectionFactory.minLargeMessageSize=250000
|
||||
connectionFactory.myConnectionFactory=tcp://localhost:61616?minLargeMessageSize=250000
|
||||
|
||||
|
||||
If the connection factory is being instantiated directly, the minimum
|
||||
|
|
@ -99,9 +98,9 @@ large message size is specified by
|
|||
You can choose to send large messages in compressed form using `
|
||||
compress-large-messages` attributes.
|
||||
|
||||
#### `compress-large-messages`
|
||||
#### `compressLargeMessages`
|
||||
|
||||
If you specify the boolean property `compress-large-messages` on the
|
||||
If you specify the boolean property `compressLargeMessages` on the
|
||||
`server locator` or `ConnectionFactory` as true, The system will use the
|
||||
ZIP algorithm to compress the message body as the message is transferred
|
||||
to the server's side. Notice that there's no special treatment at the
|
||||
|
|
@ -109,7 +108,7 @@ server's side, all the compressing and uncompressing is done at the
|
|||
client.
|
||||
|
||||
If the compressed size of a large message is below `
|
||||
min-large-message-size`, it is sent to server as regular
|
||||
minLargeMessageSize`, it is sent to server as regular
|
||||
messages. This means that the message won't be written into the server's
|
||||
large-message data directory, thus reducing the disk I/O.
|
||||
|
||||
|
|
@ -122,8 +121,7 @@ e.g. `jndi.properties`. Here's a simple example using the
|
|||
by default:
|
||||
|
||||
java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory
|
||||
java.naming.provider.url=tcp://localhost:61616
|
||||
connection.ConnectionFactory.compressLargeMessages=true
|
||||
connectionFactory.myConnectionFactory=tcp://localhost:61616?compressLargeMessages=true
|
||||
|
||||
## Streaming large messages
|
||||
|
||||
|
|
|
|||
|
|
@ -68,8 +68,7 @@ Here's a simple example using the "ConnectionFactory" connection factory
|
|||
which is available in the context by default
|
||||
|
||||
java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory
|
||||
java.naming.provider.url=tcp://localhost:61616
|
||||
connection.ConnectionFactory.autoGroup=true
|
||||
connectionFactory.myConnectionFactory=tcp://localhost:61616?autoGroup=true
|
||||
|
||||
Alternatively you can set the group id via the connection factory. All
|
||||
messages sent with producers created via this connection factory will
|
||||
|
|
@ -79,8 +78,7 @@ Here's a simple example using the "ConnectionFactory" connection factory
|
|||
which is available in the context by default:
|
||||
|
||||
java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory
|
||||
java.naming.provider.url=tcp://localhost:61616
|
||||
connection.ConnectionFactory.groupID=Group-0
|
||||
connectionFactory.myConnectionFactory=tcp://localhost:61616?roupID=Group-0
|
||||
|
||||
## Example
|
||||
|
||||
|
|
|
|||
|
|
@ -175,4 +175,4 @@ undesirable state.
|
|||
|
||||
## Example
|
||||
|
||||
See the [examples]9examples.md) chapter for an example which shows how to use paging with ActiveMQ.
|
||||
See the [examples](examples.md) chapter for an example which shows how to use paging with ActiveMQ.
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ message on the server but *before* it is delivered to the client. In
|
|||
that case, the message is lost and will not be recovered when the system
|
||||
restart.
|
||||
|
||||
Depending on your messaging case, `pre-acknowledgement` mode can avoid
|
||||
Depending on your messaging case, `preAcknowledgement` mode can avoid
|
||||
extra network traffic and CPU at the cost of coping with message loss.
|
||||
|
||||
An example of a use case for pre-acknowledgement is for stock price
|
||||
|
|
@ -46,8 +46,7 @@ This can be configured in a client's JNDI context environment, e.g.
|
|||
`jndi.properties`, like this:
|
||||
|
||||
java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory
|
||||
java.naming.provider.url=tcp://localhost:61616
|
||||
connection.ConnectionFactory.preAcknowledge=true
|
||||
connection.ConnectionFactory=tcp://localhost:61616?preAcknowledge=true
|
||||
|
||||
Alternatively, to use pre-acknowledgement mode using the JMS API, create
|
||||
a JMS Session with the `ActiveMQSession.PRE_ACKNOWLEDGE` constant.
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Why use ActiveMQ? Here are just a few of the reasons:
|
|||
|
||||
- ActiveMQ is designed with usability in mind.
|
||||
|
||||
- Written in Java. Runs on any platform with a Java 6+ runtime, that's
|
||||
- Written in Java. Runs on any platform with a Java 8+ runtime, that's
|
||||
everything from Windows desktops to IBM mainframes.
|
||||
|
||||
- Amazing performance. Our ground-breaking high performance journal
|
||||
|
|
@ -45,7 +45,4 @@ Why use ActiveMQ? Here are just a few of the reasons:
|
|||
over unreliable connections to form a global network. Configure
|
||||
routing of messages in a highly flexible way.
|
||||
|
||||
- For a full list of features, please see the [features wiki
|
||||
page](todo) .
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -52,10 +52,8 @@ session, only the commit / rollback blocks not every send, or, using
|
|||
ActiveMQ's advanced *asynchronous send acknowledgements feature*
|
||||
described in Asynchronous Send Acknowledgements.
|
||||
|
||||
If you are using JMS and you're using the JMS service on the server to
|
||||
load your JMS connection factory instances into JNDI then these
|
||||
parameters can be configured in `activemq-jms.xml` using the elements
|
||||
`block-on-durable-send` and `block-on-non-durable-send`. If you're using
|
||||
If you are using JMS and JNDI then using the elements
|
||||
`blockOnDurableSend` and `blockOnNonDurableSend`. If you're using
|
||||
JMS but not using JNDI then you can set these values directly on the
|
||||
`ActiveMQConnectionFactory` instance using the appropriate setter
|
||||
methods.
|
||||
|
|
@ -139,7 +137,7 @@ informed at the client side by ActiveMQ calling your handler's
|
|||
to the message that was sent.
|
||||
|
||||
To enable asynchronous send acknowledgements you must make sure
|
||||
`confirmation-window-size` is set to a positive integer value, e.g.
|
||||
`confirmationWindowSize` is set to a positive integer value, e.g.
|
||||
10MiB
|
||||
|
||||
Please see ? for a full working example.
|
||||
Please see [the examples chapter](examples.md) for a full working example.
|
||||
|
|
|
|||
|
|
@ -15,7 +15,8 @@ resources.
|
|||
## Configuration required for detecting slow consumers
|
||||
|
||||
By default the server will not detect slow consumers. If slow consumer
|
||||
detection is desired then see ? for more details.
|
||||
detection is desired then see [queue attributes chapter](queue-attributes.md)
|
||||
for more details.
|
||||
|
||||
The calculation to determine whether or not a consumer is slow only
|
||||
inspects the number of messages a particular consumer has
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ taking advantage of this feature:
|
|||
<bean id="EmbeddedJms" class="org.apache.activemq.integration.spring.SpringJmsBootstrap" init-method="start"/>
|
||||
|
||||
<bean id="listener" class="org.apache.activemq.tests.integration.spring.ExampleListener"/>
|
||||
|
||||
|
||||
<bean id="listenerContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer">
|
||||
<property name="connectionFactory" ref="ConnectionFactory"/>
|
||||
<property name="destination" ref="/queue/exampleQueue"/>
|
||||
|
|
|
|||
|
|
@ -37,8 +37,9 @@ When using new IO (NIO), ActiveMQ will, by default, cap its thread pool
|
|||
at three times the number of cores (or hyper-threads) as reported by `
|
||||
Runtime.getRuntime().availableProcessors()` for processing
|
||||
incoming packets. To override this value, you can set the number of
|
||||
threads by specifying the parameter `nio-remoting-threads` in the
|
||||
transport configuration. See the ? for more information on this.
|
||||
threads by specifying the parameter `nioRemotingThreads` in the
|
||||
transport configuration. See the [configuring transports](configuring-transports.md)
|
||||
for more information on this.
|
||||
|
||||
There are also a small number of other places where threads are used
|
||||
directly, we'll discuss each in turn.
|
||||
|
|
@ -131,7 +132,7 @@ myFactory.setUseGlobalPools(false);
|
|||
|
||||
myFactory.setScheduledThreadPoolMaxSize(10);
|
||||
|
||||
myFactory.setThreadPoolMaxSize(-1);
|
||||
myFactory.setThreadPoolMaxSize(-1);
|
||||
```
|
||||
|
||||
If you're using the JMS API, you can set the same parameters on the
|
||||
|
|
@ -149,12 +150,12 @@ environment, e.g. `jndi.properties`. Here's a simple example using the
|
|||
by default:
|
||||
|
||||
java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory
|
||||
|
||||
|
||||
java.naming.provider.url=tcp://localhost:61616
|
||||
|
||||
|
||||
connection.ConnectionFactory.useGlobalPools=false
|
||||
|
||||
|
||||
connection.ConnectionFactory.scheduledThreadPoolMaxSize=10
|
||||
|
||||
|
||||
connection.ConnectionFactory.threadPoolMaxSize=-1
|
||||
|
||||
|
|
|
|||
|
|
@ -37,13 +37,13 @@ Delayed redelivery is defined in the address-setting configuration:
|
|||
|
||||
<!-- delay redelivery of messages for 5s -->
|
||||
<address-setting match="jms.queue.exampleQueue">
|
||||
<!-- default is 1.0 -->
|
||||
<!-- default is 1.0 -->
|
||||
<redelivery-delay-multiplier>1.5</redelivery-delay-multiplier>
|
||||
<!-- default is 0 (no delay) -->
|
||||
<!-- default is 0 (no delay) -->
|
||||
<redelivery-delay>5000</redelivery-delay>
|
||||
<!-- default is redelivery-delay * 10 -->
|
||||
<max-redelivery-delay>50000</max-redelivery-delay>
|
||||
|
||||
|
||||
</address-setting>
|
||||
|
||||
If a `redelivery-delay` is specified, ActiveMQ will wait this delay
|
||||
|
|
@ -78,7 +78,7 @@ individually for each address.
|
|||
|
||||
### Example
|
||||
|
||||
See ? for an example which shows how delayed redelivery is configured
|
||||
See [the examples chapter](examples.md) for an example which shows how delayed redelivery is configured
|
||||
and used with JMS.
|
||||
|
||||
## Dead Letter Addresses
|
||||
|
|
@ -94,7 +94,7 @@ be perused by the system administrator for action to be taken.
|
|||
|
||||
ActiveMQ's addresses can be assigned a dead letter address. Once the
|
||||
messages have been unsuccessfully delivered for a given number of
|
||||
attempts, they are removed from their queue and sent to the relevant
|
||||
attempts, they are removed from their queue and sent to the relevant
|
||||
dead letter address. These *dead letter* messages can later be consumed
|
||||
from the dead letter address for further inspection.
|
||||
|
||||
|
|
|
|||
|
|
@ -99,15 +99,15 @@ Here is a list of all the supported URL schemes:
|
|||
Most clients won't be connecting to an embedded broker. Clients will
|
||||
most commonly connect across a network a remote broker. Here's a simple
|
||||
example of a client configuring a connection factory to connect to a
|
||||
remote broker running on myhost:61616:
|
||||
remote broker running on myhost:5445:
|
||||
|
||||
java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory
|
||||
connectionFactory.ConnectionFactory=tcp://myhost:61616
|
||||
connectionFactory.ConnectionFactory=tcp://myhost:5445
|
||||
|
||||
In the example above the client is using the `tcp` scheme for the
|
||||
provider URL. A client may also specify multiple comma-delimited
|
||||
host:port combinations in the URL (e.g.
|
||||
`(tcp://remote-host1:61616,remote-host2:61616)`). Whether there is one or
|
||||
`(tcp://remote-host1:5445,remote-host2:5445)`). Whether there is one or
|
||||
many host:port combinations in the URL they are treated as the *initial
|
||||
connector(s)* for the underlying connection.
|
||||
|
||||
|
|
@ -120,7 +120,7 @@ traditional URL query string format (e.g.
|
|||
`scheme://host:port?key1=value1&key2=value2`) to customize the
|
||||
underlying transport mechanism. For example, if a client wanted to
|
||||
connect to a remote server using TCP and SSL it would create a connection
|
||||
factory like so, `tcp://remote-host:61616?ssl-enabled=true`.
|
||||
factory like so, `tcp://remote-host:5445?ssl-enabled=true`.
|
||||
|
||||
All the properties available for the `tcp` scheme are described in [the
|
||||
documentation regarding the Netty
|
||||
|
|
@ -130,7 +130,7 @@ Note if you are using the `tcp` scheme and multiple addresses then a query
|
|||
can be applied to all the url's or just to an individual connector, so where
|
||||
you have
|
||||
|
||||
- `(tcp://remote-host1:61616?httpEnabled=true,remote-host2:61616?httpEnabled=true)?clientID=1234`
|
||||
- `(tcp://remote-host1:5445?httpEnabled=true,remote-host2:5445?httpEnabled=true)?clientID=1234`
|
||||
|
||||
then the `httpEnabled` property is only set on the individual connectors where as the `clientId`
|
||||
is set on the actual connection factory. Any connector specific properties set on the whole
|
||||
|
|
@ -139,18 +139,18 @@ URI will be applied to all the connectors.
|
|||
|
||||
The `udp` scheme supports 4 properties:
|
||||
|
||||
- `local-address` - If you are running with multiple network
|
||||
- `localAddress` - If you are running with multiple network
|
||||
interfaces on the same machine, you may want to specify that the
|
||||
discovery group listens only only a specific interface. To do this
|
||||
you can specify the interface address with this parameter.
|
||||
|
||||
- `local-port` - If you want to specify a local port to which the
|
||||
- `localPort` - If you want to specify a local port to which the
|
||||
datagram socket is bound you can specify it here. Normally you would
|
||||
just use the default value of -1 which signifies that an anonymous
|
||||
port should be used. This parameter is always specified in
|
||||
conjunction with `local-address`.
|
||||
conjunction with `localAddress`.
|
||||
|
||||
- `refresh-timeout` - This is the period the discovery group waits
|
||||
- `refreshTimeout` - This is the period the discovery group waits
|
||||
after receiving the last broadcast from a particular server before
|
||||
removing that servers connector pair entry from its list. You would
|
||||
normally set this to a value significantly higher than the
|
||||
|
|
@ -159,7 +159,7 @@ The `udp` scheme supports 4 properties:
|
|||
broadcasting due to slight differences in timing. This parameter is
|
||||
optional, the default value is 10000 milliseconds (10 seconds).
|
||||
|
||||
- `discovery-initial-wait-timeout` - If the connection factory is used
|
||||
- `discoveryInitialWaitTimeout` - If the connection factory is used
|
||||
immediately after creation then it may not have had enough time to
|
||||
received broadcasts from all the nodes in the cluster. On first
|
||||
usage, the connection factory will make sure it waits this long
|
||||
|
|
@ -174,14 +174,14 @@ that contains the JGroups configuration or it can be
|
|||
`jgroups://channelName?properties=some-jgroups-properties`. In both instance the
|
||||
`channelName` is the name given to the jgroups channel created.
|
||||
|
||||
The `refresh-timeout` and `discovery-initial-wait-timeout` properties
|
||||
The `refreshTimeout` and `discoveryInitialWaitTimeout` properties
|
||||
are supported just like with `udp`.
|
||||
|
||||
The default type for the default connection factory is of type `javax.jms.ConnectionFactory`.
|
||||
This can be changed by setting the type like so
|
||||
|
||||
java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory
|
||||
java.naming.provider.url=tcp://localhost:61616?type=CF
|
||||
java.naming.provider.url=tcp://localhost:5445?type=CF
|
||||
|
||||
In this example it is still set to the default, below shows a list of types that can be set.
|
||||
|
||||
|
|
@ -233,7 +233,7 @@ And if the client wanted to bind this queue to "queues/OrderQueue" then
|
|||
the JNDI properties would be configured like so:
|
||||
|
||||
java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory
|
||||
java.naming.provider.url=tcp://myhost:61616
|
||||
java.naming.provider.url=tcp://myhost:5445
|
||||
queue.queues/OrderQueue=OrderQueue
|
||||
|
||||
It is also possible to look-up JMS destinations which haven't been
|
||||
|
|
@ -256,7 +256,7 @@ initialized using those properties:
|
|||
InitialContext ic = new InitialContext();
|
||||
|
||||
//Now we'll look up the connection factory from which we can create
|
||||
//connections to myhost:61616:
|
||||
//connections to myhost:5445:
|
||||
|
||||
ConnectionFactory cf = (ConnectionFactory)ic.lookup("ConnectionFactory");
|
||||
|
||||
|
|
@ -379,7 +379,7 @@ System.out.println("Got order: " + receivedMessage.getText());
|
|||
|
||||
This represents the client id for a JMS client and is needed for
|
||||
creating durable subscriptions. It is possible to configure this on the
|
||||
connection factory and can be set via the `client-id` element. Any
|
||||
connection factory and can be set via the `clientId` element. Any
|
||||
connection created by this connection factory will have this set as its
|
||||
client id.
|
||||
|
||||
|
|
@ -388,7 +388,7 @@ client id.
|
|||
When the JMS acknowledge mode is set to `DUPS_OK` it is possible to
|
||||
configure the consumer so that it sends acknowledgements in batches
|
||||
rather that one at a time, saving valuable bandwidth. This can be
|
||||
configured via the connection factory via the `dups-ok-batch-size`
|
||||
configured via the connection factory via the `dupsOkBatchSize`
|
||||
element and is set in bytes. The default is 1024 \* 1024 bytes = 1 MiB.
|
||||
|
||||
### Setting The Transaction Batch Size
|
||||
|
|
@ -396,5 +396,5 @@ element and is set in bytes. The default is 1024 \* 1024 bytes = 1 MiB.
|
|||
When receiving messages in a transaction it is possible to configure the
|
||||
consumer to send acknowledgements in batches rather than individually
|
||||
saving valuable bandwidth. This can be configured on the connection
|
||||
factory via the `transaction-batch-size` element and is set in bytes.
|
||||
factory via the `transactionBatchSize` element and is set in bytes.
|
||||
The default is 1024 \* 1024.
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ follows:
|
|||
<param key="queue" value="jms.queue.vertxQueue"/>
|
||||
<param key="vertx-address" value="vertx.in.eventaddress"/>
|
||||
</connector-service>
|
||||
|
||||
|
||||
|
||||
Shown are the required params for the connector service:
|
||||
|
||||
|
|
@ -58,7 +58,7 @@ as follows:
|
|||
<param key="vertx-address" value="vertx.out.eventaddress"/>
|
||||
<param key="publish" value="true"/>
|
||||
</connector-service>
|
||||
|
||||
|
||||
|
||||
Shown are the required params for the connector service:
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue