Apache
/
activemq-artemis
mirror of https://github.com/apache/activemq-artemis.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

This closes #114 with docs and test fixes

This commit is contained in:
Clebert Suconic 2015-02-25 10:40:18 -05:00
parent e52622cffa 08d29a6905
commit 8f8b09a772
27 changed files with 117 additions and 155 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
activemq-protocols/activemq-stomp-protocol/src/main/java/org/apache/activemq/core/protocol/stomp/StompProtocolManager.java
View File

@ -37,6 +37,7 @@ import org.apache.activemq.api.core.management.ManagementHelper;
import org.apache.activemq.core.journal.IOAsyncTask;
import org.apache.activemq.core.postoffice.BindingType;
import org.apache.activemq.core.remoting.impl.netty.NettyServerConnection;
import org.apache.activemq.core.remoting.impl.netty.TransportConstants;
import org.apache.activemq.core.server.ActiveMQMessageBundle;
import org.apache.activemq.core.server.ActiveMQServer;
import org.apache.activemq.core.server.ActiveMQServerLogger;
@ -112,7 +113,7 @@ class StompProtocolManager implements ProtocolManager, NotificationListener
// Note that STOMP 1.0 has no heartbeat, so if connection ttl is non zero, data must continue to be sent or connection
// will be timed out and closed!
String ttlStr = (String) acceptorUsed.getConfiguration().get("connection-ttl");
String ttlStr = (String) acceptorUsed.getConfiguration().get(TransportConstants.CONNECTION_TTL);
Long ttl = ttlStr == null ? null : Long.valueOf(ttlStr);
if (ttl != null)

10
docs/user-manual/en/aerogear-integration.md
View File

@ -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

22
docs/user-manual/en/client-reconnection.md
View File

@ -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

19
docs/user-manual/en/clusters.md
View File

@ -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.

12
docs/user-manual/en/configuring-transports.md
View File

@ -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,

11
docs/user-manual/en/connection-ttl.md
View File

@ -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

4
docs/user-manual/en/duplicate-detection.md
View File

@ -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();

2
docs/user-manual/en/embedding-activemq.md
View File

@ -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()));

7
docs/user-manual/en/examples.md
View File

@ -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
=================

22
docs/user-manual/en/flow-control.md
View File

@ -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
docs/user-manual/en/graceful-shutdown.md
View File

@ -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.

28
docs/user-manual/en/ha.md
View File

@ -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

2
docs/user-manual/en/intercepting-operations.md
View File

@ -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;
}
```

6
docs/user-manual/en/interoperability.md
View File

@ -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.

6
docs/user-manual/en/jms-bridge.md
View File

@ -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.

16
docs/user-manual/en/large-messages.md
View File

@ -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

6
docs/user-manual/en/message-grouping.md
View File

@ -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

2
docs/user-manual/en/paging.md
View File

@ -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.

5
docs/user-manual/en/pre-acknowledge.md
View File

@ -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.

5
docs/user-manual/en/preface.md
View File

@ -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) .

10
docs/user-manual/en/send-guarantees.md
View File

@ -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.

3
docs/user-manual/en/slow-consumers.md
View File

@ -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

2
docs/user-manual/en/spring-integration.md
View File

@ -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"/>

15
docs/user-manual/en/thread-pooling.md
View File

@ -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

10
docs/user-manual/en/undelivered-messages.md
View File

@ -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.

34
docs/user-manual/en/using-jms.md
View File

@ -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.

4
docs/user-manual/en/vertx-integration.md
View File

@ -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: