You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@activemq.apache.org by cl...@apache.org on 2014/12/12 17:32:50 UTC
[3/5] activemq-6 git commit: documentation review fixes
http://git-wip-us.apache.org/repos/asf/activemq-6/blob/b4144013/docs/user-manual/en/embedding-activemq.md
----------------------------------------------------------------------
diff --git a/docs/user-manual/en/embedding-activemq.md b/docs/user-manual/en/embedding-activemq.md
index 0c29d59..1042c07 100644
--- a/docs/user-manual/en/embedding-activemq.md
+++ b/docs/user-manual/en/embedding-activemq.md
@@ -1,5 +1,4 @@
-Embedding ActiveMQ
-==================
+# Embedding ActiveMQ
ActiveMQ is designed as set of simple Plain Old Java Objects (POJOs).
This means ActiveMQ can be instantiated and run in any dependency
@@ -18,60 +17,59 @@ configuration object, instantiate the server, start it, and you have a
ActiveMQ running in your virtual machine. It's as simple and easy as
that.
-Simple Config File Embedding
-============================
+## Simple Config File Embedding
The simplest way to embed ActiveMQ is to use the embedded wrapper
classes and configure ActiveMQ through its configuration files. There
are two different helper classes for this depending on whether your
using the ActiveMQ Core API or JMS.
-Core API Only
--------------
+## Core API Only
For instantiating a core ActiveMQ Server only, the steps are pretty
simple. The example requires that you have defined a configuration file
`activemq-configuration.xml` in your classpath:
- import org.apache.activemq.core.server.embedded.EmbeddedActiveMQ;
+``` java
+import org.apache.activemq.core.server.embedded.EmbeddedActiveMQ;
- ...
+...
- EmbeddedActiveMQ embedded = new EmbeddedActiveMQ();
- embedded.start();
+EmbeddedActiveMQ embedded = new EmbeddedActiveMQ();
+embedded.start();
- ClientSessionFactory nettyFactory = ActiveMQClient.createClientSessionFactory(
- new TransportConfiguration(
- InVMConnectorFactory.class.getName()));
+ClientSessionFactory nettyFactory = ActiveMQClient.createClientSessionFactory(
+ new TransportConfiguration(
+ InVMConnectorFactory.class.getName()));
- ClientSession session = factory.createSession();
+ClientSession session = factory.createSession();
- session.createQueue("example", "example", true);
+session.createQueue("example", "example", true);
- ClientProducer producer = session.createProducer("example");
+ClientProducer producer = session.createProducer("example");
- ClientMessage message = session.createMessage(true);
+ClientMessage message = session.createMessage(true);
- message.getBody().writeString("Hello");
+message.getBody().writeString("Hello");
- producer.send(message);
+producer.send(message);
- session.start();
+session.start();
- ClientConsumer consumer = session.createConsumer("example");
+ClientConsumer consumer = session.createConsumer("example");
- ClientMessage msgReceived = consumer.receive();
+ClientMessage msgReceived = consumer.receive();
- System.out.println("message = " + msgReceived.getBody().readString());
+System.out.println("message = " + msgReceived.getBody().readString());
- session.close();
+session.close();
+```
The `EmbeddedActiveMQ` class has a few additional setter methods that
allow you to specify a different config file name as well as other
properties. See the javadocs for this class for more details.
-JMS API
--------
+## JMS API
JMS embedding is simple as well. This example requires that you have
defined the config files `activemq-configuration.xml`,
@@ -79,18 +77,20 @@ defined the config files `activemq-configuration.xml`,
enabled. Let's also assume that a queue and connection factory has been
defined in the `activemq-jms.xml` config file.
- import org.apache.activemq.jms.server.embedded.EmbeddedJMS;
+``` java
+import org.apache.activemq.jms.server.embedded.EmbeddedJMS;
- ...
+...
- EmbeddedJMS jms = new EmbeddedJMS();
- jms.start();
+EmbeddedJMS jms = new EmbeddedJMS();
+jms.start();
- // This assumes we have configured activemq-jms.xml with the appropriate config information
- ConnectionFactory connectionFactory = jms.lookup("ConnectionFactory");
- Destination destination = jms.lookup("/example/queue");
+// This assumes we have configured activemq-jms.xml with the appropriate config information
+ConnectionFactory connectionFactory = jms.lookup("ConnectionFactory");
+Destination destination = jms.lookup("/example/queue");
- ... regular JMS code ...
+... regular JMS code ...
+```
By default, the `EmbeddedJMS` class will store component entries defined
within your `activemq-jms.xml` file in an internal concurrent hash map.
@@ -99,8 +99,7 @@ If you want to use JNDI, call the `EmbeddedJMS.setContext()` method with
the root JNDI context you want your components bound into. See the
javadocs for this class for more details on other config options.
-POJO instantiation - Embedding Programmatically
-===============================================
+## POJO instantiation - Embedding Programmatically
You can follow this step-by-step guide to programmatically embed the
core, non-JMS ActiveMQ Server instance:
@@ -108,43 +107,49 @@ core, non-JMS ActiveMQ Server instance:
Create the configuration object - this contains configuration
information for a ActiveMQ instance. The setter methods of this class
allow you to programmatically set configuration options as describe in
-the ? section.
+the [Server Configuration](configuration-index.md) section.
The acceptors are configured through `ConfigurationImpl`. Just add the
`NettyAcceptorFactory` on the transports the same way you would through
the main configuration file.
- import org.apache.activemq.core.config.Configuration;
- import org.apache.activemq.core.config.impl.ConfigurationImpl;
+``` java
+import org.apache.activemq.core.config.Configuration;
+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()));
+Configuration config = new ConfigurationImpl();
+HashSet<TransportConfiguration> transports = new HashSet<TransportConfiguration>();
+
+transports.add(new TransportConfiguration(NettyAcceptorFactory.class.getName()));
+transports.add(new TransportConfiguration(InVMAcceptorFactory.class.getName()));
- config.setAcceptorConfigurations(transports);
+config.setAcceptorConfigurations(transports);
+```
You need to instantiate an instance of
`org.apache.activemq.api.core.server.embedded.EmbeddedActiveMQ` and add
the configuration object to it.
- import org.apache.activemq.api.core.server.ActiveMQ;
- import org.apache.activemq.core.server.embedded.EmbeddedActiveMQ;
+``` java
+import org.apache.activemq.api.core.server.ActiveMQ;
+import org.apache.activemq.core.server.embedded.EmbeddedActiveMQ;
- ...
+...
- EmbeddedActiveMQ server = new EmbeddedActiveMQ();
- server.setConfiguration(config);
+EmbeddedActiveMQ server = new EmbeddedActiveMQ();
+server.setConfiguration(config);
- server.start();
+server.start();
+```
You also have the option of instantiating `ActiveMQServerImpl` directly:
- ActiveMQServer server = new ActiveMQServerImpl(config);
- server.start();
+``` java
+ActiveMQServer server = new ActiveMQServerImpl(config);
+server.start();
+```
For JMS POJO instantiation, you work with the EmbeddedJMS class instead
as described earlier. First you define the configuration
@@ -152,35 +157,36 @@ programmatically for your ConnectionFactory and Destination objects,
then set the JmsConfiguration property of the EmbeddedJMS class. Here is
an example of this:
- // Step 1. Create ActiveMQ core configuration, and set the properties accordingly
- Configuration configuration = new ConfigurationImpl();
- configuration.setPersistenceEnabled(false);
- configuration.setSecurityEnabled(false);
- configuration.getAcceptorConfigurations().add(new TransportConfiguration(NettyAcceptorFactory.class.getName()));
+``` java
+// Step 1. Create ActiveMQ core configuration, and set the properties accordingly
+Configuration configuration = new ConfigurationImpl();
+configuration.setPersistenceEnabled(false);
+configuration.setSecurityEnabled(false);
+configuration.getAcceptorConfigurations().add(new TransportConfiguration(NettyAcceptorFactory.class.getName()));
- // Step 2. Create the JMS configuration
- JMSConfiguration jmsConfig = new JMSConfigurationImpl();
+// Step 2. Create the JMS configuration
+JMSConfiguration jmsConfig = new JMSConfigurationImpl();
- // Step 3. Configure the JMS ConnectionFactory
- TransportConfiguration connectorConfig = new TransportConfiguration(NettyConnectorFactory.class.getName());
- ConnectionFactoryConfiguration cfConfig = new ConnectionFactoryConfigurationImpl("cf", connectorConfig, "/cf");
- jmsConfig.getConnectionFactoryConfigurations().add(cfConfig);
+// Step 3. Configure the JMS ConnectionFactory
+TransportConfiguration connectorConfig = new TransportConfiguration(NettyConnectorFactory.class.getName());
+ConnectionFactoryConfiguration cfConfig = new ConnectionFactoryConfigurationImpl("cf", connectorConfig, "/cf");
+jmsConfig.getConnectionFactoryConfigurations().add(cfConfig);
- // Step 4. Configure the JMS Queue
- JMSQueueConfiguration queueConfig = new JMSQueueConfigurationImpl("queue1", null, false, "/queue/queue1");
- jmsConfig.getQueueConfigurations().add(queueConfig);
+// Step 4. Configure the JMS Queue
+JMSQueueConfiguration queueConfig = new JMSQueueConfigurationImpl("queue1", null, false, "/queue/queue1");
+jmsConfig.getQueueConfigurations().add(queueConfig);
- // Step 5. Start the JMS Server using the ActiveMQ core server and the JMS configuration
- EmbeddedJMS jmsServer = new EmbeddedJMS();
- jmsServer.setConfiguration(configuration);
- jmsServer.setJmsConfiguration(jmsConfig);
- jmsServer.start();
+// Step 5. Start the JMS Server using the ActiveMQ core server and the JMS configuration
+EmbeddedJMS jmsServer = new EmbeddedJMS();
+jmsServer.setConfiguration(configuration);
+jmsServer.setJmsConfiguration(jmsConfig);
+jmsServer.start();
+```
Please see ? for an example which shows how to setup and run ActiveMQ
embedded with JMS.
-Dependency Frameworks
-=====================
+## Dependency Frameworks
You may also choose to use a dependency injection framework such as
JBoss Micro Container or Spring Framework. See ? for more details on
@@ -221,5 +227,7 @@ be:
`ActiveMQBootstrapServer` provides an easy encapsulation of JBoss Micro
Container.
- ActiveMQBootstrapServer bootStrap = new ActiveMQBootstrapServer(new String[] {"activemq-beans.xml"});
- bootStrap.run();
+``` java
+ActiveMQBootstrapServer bootStrap = new ActiveMQBootstrapServer(new String[] {"activemq-beans.xml"});
+bootStrap.run();
+```
http://git-wip-us.apache.org/repos/asf/activemq-6/blob/b4144013/docs/user-manual/en/filter-expressions.md
----------------------------------------------------------------------
diff --git a/docs/user-manual/en/filter-expressions.md b/docs/user-manual/en/filter-expressions.md
index c1dfca5..28d4d4d 100644
--- a/docs/user-manual/en/filter-expressions.md
+++ b/docs/user-manual/en/filter-expressions.md
@@ -1,5 +1,4 @@
-Filter Expressions
-==================
+# Filter Expressions
ActiveMQ provides a powerful filter language based on a subset of the
SQL 92 expression syntax.
@@ -17,13 +16,13 @@ Filter expressions are used in several places in ActiveMQ
filter expression will enter the queue.
- Core bridges can be defined with an optional filter expression, only
- matching messages will be bridged (see ?).
+ matching messages will be bridged (see [Core Bridges]9core-bridges.md)).
- Diverts can be defined with an optional filter expression, only
- matching messages will be diverted (see ?).
+ matching messages will be diverted (see [Diverts](diverts.md)).
- Filter are also used programmatically when creating consumers,
- queues and in several places as described in ?.
+ queues and in several places as described in [management](management.md).
There are some differences between JMS selector expressions and ActiveMQ
core filter expressions. Whereas JMS selector expressions operate on a
http://git-wip-us.apache.org/repos/asf/activemq-6/blob/b4144013/docs/user-manual/en/flow-control.md
----------------------------------------------------------------------
diff --git a/docs/user-manual/en/flow-control.md b/docs/user-manual/en/flow-control.md
index bdaac25..bf826bb 100644
--- a/docs/user-manual/en/flow-control.md
+++ b/docs/user-manual/en/flow-control.md
@@ -1,12 +1,10 @@
-Flow Control
-============
+# Flow Control
Flow control is used to limit the flow of data between a client and
server, or a server and another server in order to prevent the client or
server being overwhelmed with data.
-Consumer Flow Control
-=====================
+## Consumer Flow Control
This controls the flow of data between the server and the client as the
client consumes messages. For performance reasons clients normally
@@ -17,8 +15,7 @@ internal buffer, then you could end up with a situation where messages
would keep building up possibly causing out of memory on the client if
they cannot be processed in time.
-Window-Based Flow Control
--------------------------
+## Window-Based Flow Control
By default, ActiveMQ consumers buffer messages from the server in a
client side buffer before the client consumes them. This improves
@@ -51,38 +48,38 @@ Setting the consumer window size can considerably improve performance
depending on the messaging use case. As an example, let's consider the
two extremes:
-Fast consumers
-: Fast consumers can process messages as fast as they consume them (or
- even faster)
+### Fast consumers
+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
- will allow *unbounded* message buffering on the client side.
+To allow fast consumers, set the `consumer-window-size` to -1. This
+will allow *unbounded* message buffering on the client side.
- Use this setting with caution: it can overflow the client memory if
- the consumer is not able to process messages as fast as it receives
- them.
+Use this setting with caution: it can overflow the client memory if
+the consumer is not able to process messages as fast as it receives
+them.
-Slow consumers
-: Slow consumers takes significant time to process each message and it
- is desirable to prevent buffering messages on the client side so
- that they can be delivered to another consumer instead.
+### Slow consumers
+Slow consumers takes significant time to process each message and it
+is desirable to prevent buffering messages on the client side so
+that they can be delivered to another consumer instead.
- Consider a situation where a queue has 2 consumers; 1 of which is
- very slow. Messages are delivered in a round robin fashion to both
- consumers, the fast consumer processes all of its messages very
- quickly until its buffer is empty. At this point there are still
- messages awaiting to be processed in the buffer of the slow consumer
- thus preventing them being processed by the fast consumer. The fast
- consumer is therefore sitting idle when it could be processing the
- other messages.
+Consider a situation where a queue has 2 consumers; 1 of which is
+very slow. Messages are delivered in a round robin fashion to both
+consumers, the fast consumer processes all of its messages very
+quickly until its buffer is empty. At this point there are still
+messages awaiting to be processed in the buffer of the slow consumer
+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
- 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.
+To allow slow consumers, set the `consumer-window-size` 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.
- Setting this to 0 can give deterministic distribution between
- multiple consumers on a queue.
+Setting this to 0 can give deterministic distribution between
+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
@@ -115,8 +112,7 @@ method.
Please see ? for an example which shows how to configure ActiveMQ to
prevent consumer buffering when dealing with slow consumers.
-Rate limited flow control
--------------------------
+## Rate limited flow control
It is also possible to control the *rate* at which a consumer can
consume messages. This is a form of throttling and can be used to make
@@ -162,14 +158,12 @@ can be set via the `ActiveMQConnectionFactory.setConsumerMaxRate(int
Please see ? for an example which shows how to configure ActiveMQ to
prevent consumer buffering when dealing with slow consumers.
-Producer flow control
-=====================
+## Producer flow control
ActiveMQ also can limit the amount of data sent from a client to a
server to prevent the server being overwhelmed.
-Window based flow control
--------------------------
+### Window based flow control
In a similar way to consumer window based flow control, ActiveMQ
producers, by default, can only send messages to an address as long as
@@ -186,12 +180,12 @@ The window size therefore determines the amount of bytes that can be
in-flight at any one time before more need to be requested - this
prevents the remoting connection from getting overloaded.
-### Using Core API
+#### Using Core API
If the ActiveMQ core API is being used, window size can be set via the
`ServerLocator.setProducerWindowSize(int producerWindowSize)` method.
-### Using JMS
+#### Using JMS
If JNDI is used to instantiate and look up the connection factory, the
producer window size can be configured in the JNDI context environment,
@@ -208,7 +202,7 @@ size can be set via the
`ActiveMQConnectionFactory.setProducerWindowSize(int
producerWindowSize)` method.
-### Blocking producer window based flow control
+#### Blocking producer window based flow control
Normally the server will always give the same number of credits as have
been requested. However, it is also possible to set a maximum size on
@@ -234,7 +228,7 @@ but instead pages messages to storage.
To configure an address with a maximum size and tell the server that you
want to block producers for this address if it becomes full, you need to
-define an AddressSettings (?) block for the address and specify
+define an AddressSettings ([Configuring Queues Via Address Settings](queue-attributes.md)) block for the address and specify
`max-size-bytes` and `address-full-policy`
The address block applies to all queues registered to that address. I.e.
@@ -267,8 +261,7 @@ control.
> want this behaviour increase the `max-size-bytes` parameter or change
> the address full message policy.
-Rate limited flow control
--------------------------
+### Rate limited flow control
ActiveMQ also allows the rate a producer can emit message to be limited,
in units of messages per second. By specifying such a rate, ActiveMQ
@@ -282,13 +275,13 @@ control. The default value is `-1`.
Please see the ? for a working example of limiting producer rate.
-### Using Core API
+#### Using Core API
If the ActiveMQ core API is being used the rate can be set via the
`ServerLocator.setProducerMaxRate(int producerMaxRate)` method or
alternatively via some of the `ClientSession.createProducer()` methods.
-### Using JMS
+#### Using JMS
If JNDI is used to instantiate and look up the connection factory, the
max rate size can be configured in the JNDI context environment, e.g.
http://git-wip-us.apache.org/repos/asf/activemq-6/blob/b4144013/docs/user-manual/en/ha.md
----------------------------------------------------------------------
diff --git a/docs/user-manual/en/ha.md b/docs/user-manual/en/ha.md
index a35536c..e2e46b8 100644
--- a/docs/user-manual/en/ha.md
+++ b/docs/user-manual/en/ha.md
@@ -1,5 +1,4 @@
-High Availability and Failover
-==============================
+# High Availability and Failover
We define high availability as the *ability for the system to continue
functioning after failure of one or more of the servers*.
@@ -8,8 +7,7 @@ A part of high availability is *failover* which we define as the
*ability for client connections to migrate from one server to another in
event of server failure so client applications can continue to operate*.
-Live - Backup Groups
-====================
+## Live - Backup Groups
ActiveMQ allows servers to be linked together as *live - backup* groups
where each live server can have 1 or more backup servers. A backup
@@ -28,8 +26,7 @@ become live when the current live server goes down, if the current live
server is configured to allow automatic failback then it will detect the
live server coming back up and automatically stop.
-HA Policies
------------
+### HA Policies
ActiveMQ supports two different strategies for backing up a server
*shared store* and *replication*. Which is configured via the
@@ -95,8 +92,7 @@ or
</ha-policy>
-Data Replication
-----------------
+### Data Replication
Support for network-based data replication was added in version 2.3.
@@ -124,13 +120,13 @@ the connection speed.
Replication will create a copy of the data at the backup. One issue to
be aware of is: in case of a successful fail-over, the backup's data
will be newer than the one at the live's storage. If you configure your
-live server to perform a ? when restarted, it will synchronize its data
+live server to perform a failback to live server when restarted, it will synchronize its data
with the backup's. If both servers are shutdown, the administrator will
have to determine which one has the latest data.
The replicating live and backup pair must be part of a cluster. The
Cluster Connection also defines how backup servers will find the remote
-live servers to pair with. Refer to ? for details on how this is done,
+live servers to pair with. Refer to [Clusters](clusters.md) for details on how this is done,
and how to configure a cluster connection. Notice that:
- Both live and backup servers must be part of the same cluster.
@@ -202,7 +198,7 @@ than half the servers, it will become active, if more than half the
servers also disappeared with the live, the backup will wait and try
reconnecting with the live. This avoids a split brain situation.
-### Configuration
+#### Configuration
To configure the live and backup servers to be a replicating pair,
configure the live server in ' `activemq-configuration.xml` to have:
@@ -228,7 +224,7 @@ The backup server must be similarly configured but as a `slave`
</replication>
</ha-policy>
-### All Replication Configuration
+#### All Replication Configuration
The following table lists all the `ha-policy` configuration elements for
HA strategy Replication for `master`:
@@ -250,8 +246,7 @@ HA strategy Replication for `slave`:
`allow-failback` Whether a server will automatically stop when a another places a request to take over its place. The use case is when the backup has failed over
`failback-delay` delay to wait before fail-back occurs on (failed over live's) restart
-Shared Store
-------------
+### Shared Store
When using a shared store, both live and backup servers share the *same*
entire data directory using a shared file system. This means the paging
@@ -284,7 +279,7 @@ on amount of data).
-### Configuration
+#### Configuration
To configure the live and backup servers to share their store, configure
id via the `ha-policy` configuration in `activemq-configuration.xml`:
@@ -313,7 +308,7 @@ The backup server must also be configured as a backup.
In order for live - backup groups to operate properly with a shared
store, both servers must have configured the location of journal
-directory to point to the *same shared location* (as explained in ?)
+directory to point to the *same shared location* (as explained in [Configuring the message journal](persistence.md))
> **Note**
>
@@ -322,11 +317,10 @@ directory to point to the *same shared location* (as explained in ?)
Also each node, live and backups, will need to have a cluster connection
defined even if not part of a cluster. The Cluster Connection info
defines how backup servers announce there presence to its live server or
-any other nodes in the cluster. Refer to ? for details on how this is
+any other nodes in the cluster. Refer to [Clusters](clusters.md) for details on how this is
done.
-Failing Back to live Server
----------------------------
+### Failing Back to live Server
After a live server has failed and a backup taken has taken over its
duties, you may want to restart the live server and have clients fail
@@ -396,7 +390,7 @@ or `slave` like so:
By default this is set to false, if by some chance you have set this to
false but still want to stop the server normally and cause failover then
-you can do this by using the management API as explained at ?
+you can do this by using the management API as explained at [Management](management.md)
You can also force the running live server to shutdown when the old live
server comes back up allowing the original live server to take over
@@ -411,7 +405,7 @@ automatically by setting the following property in the
</shared-store>
</ha-policy>
-### All Shared Store Configuration
+#### All Shared Store Configuration
The following table lists all the `ha-policy` configuration elements for
HA strategy shared store for `master`:
@@ -419,19 +413,18 @@ HA strategy shared store for `master`:
name Description
------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
`failback-delay` If a backup server is detected as being live, via the lock file, then the live server will wait announce itself as a backup and wait this amount of time (in ms) before starting as a live
- `failover-on-server-shutdown` If set to true then when this server is stopped normally the backup will become live assuming failover. If false then the backup server will remain passive. Note that if false you want failover to occur the you can use the the management API as explained at ?
+ `failover-on-server-shutdown` If set to true then when this server is stopped normally the backup will become live assuming failover. If false then the backup server will remain passive. Note that if false you want failover to occur the you can use the the management API as explained at [Management](management.md)
The following table lists all the `ha-policy` configuration elements for
HA strategy Shared Store for `slave`:
name Description
------------------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
- `failover-on-server-shutdown` In the case of a backup that has become live. then when set to true then when this server is stopped normally the backup will become liveassuming failover. If false then the backup server will remain passive. Note that if false you want failover to occur the you can use the the management API as explained at ?
+ `failover-on-server-shutdown` In the case of a backup that has become live. then when set to true then when this server is stopped normally the backup will become liveassuming failover. If false then the backup server will remain passive. Note that if false you want failover to occur the you can use the the management API as explained at [Management](management.md)
`allow-failback` Whether a server will automatically stop when a another places a request to take over its place. The use case is when the backup has failed over.
`failback-delay` After failover and the slave has become live, this is set on the new live server. When starting If a backup server is detected as being live, via the lock file, then the live server will wait announce itself as a backup and wait this amount of time (in ms) before starting as a live, however this is unlikely since this backup has just stopped anyway. It is also used as the delay after failback before this backup will restart (if `allow-failback` is set to true.
-Colocated Backup Servers
-------------------------
+#### Colocated Backup Servers
It is also possible when running standalone to colocate backup servers
in the same JVM as another live server. Live Servers can be configured
@@ -467,7 +460,7 @@ replication as in the previous chapter. `shared-store` is also supported
-### Configuring Connectors and Acceptors
+#### Configuring Connectors and Acceptors
If the HA Policy is colocated then connectors and acceptors will be
inherited from the live server creating it and offset depending on the
@@ -499,7 +492,7 @@ adding them to the `ha-policy` configuration like so:
</ha-policy>
-### Configuring Directories
+#### Configuring Directories
Directories for the Journal, Large messages and Paging will be set
according to what the HA strategy is. If shared store the the requesting
@@ -517,8 +510,7 @@ The following table lists all the `ha-policy` configuration elements:
`max-backups` Whether or not this live server will accept backup requests from other live servers.
`backup-port-offset` The offset to use for the Connectors and Acceptors when creating a new backup server.
-Scaling Down
-============
+### Scaling Down
An alternative to using Live/Backup groups is to configure scaledown.
when configured for scale down a server can copy all its messages and
@@ -568,8 +560,7 @@ this would look like:
</ha-policy>
-Scale Down with groups
-----------------------
+#### Scale Down with groups
It is also possible to configure servers to only scale down to servers
that belong in the same group. This is done by configuring the group
@@ -588,8 +579,7 @@ like so:
In this scenario only servers that belong to the group `my-group` will
be scaled down to
-Scale Down and Backups
-----------------------
+#### Scale Down and Backups
It is also possible to mix scale down with HA via backup servers. If a
slave is configured to scale down then after failover has occurred,
@@ -630,8 +620,7 @@ typical configuration would look like:
</ha-policy>
-Scale Down and Clients
-----------------------
+#### Scale Down and Clients
When a server is stopping and preparing to scale down it will send a
message to all its clients informing them which server it is scaling
@@ -642,8 +631,7 @@ transactions are there for the client when it reconnects. The normal
reconnect settings apply when the client is reconnecting so these should
be high enough to deal with the time needed to scale down.
-Failover Modes
-==============
+## Failover Modes
ActiveMQ defines two types of client failover:
@@ -654,15 +642,14 @@ ActiveMQ defines two types of client failover:
ActiveMQ also provides 100% transparent automatic reattachment of
connections to the same server (e.g. in case of transient network
problems). This is similar to failover, except it is reconnecting to the
-same server and is discussed in ?
+same server and is discussed in [Client Reconnection and Session Reattachment](client-reconnection.md)
During failover, if the client has consumers on any non persistent or
temporary queues, those queues will be automatically recreated during
failover on the backup node, since the backup node will not have any
knowledge of non persistent queues.
-Automatic Client Failover
--------------------------
+### Automatic Client Failover
ActiveMQ clients can be configured to receive knowledge of all live and
backup servers, so that in event of connection failure at the client -
@@ -673,7 +660,7 @@ thus saving the user from having to hand-code manual reconnection logic.
ActiveMQ clients detect connection failure when it has not received
packets from the server within the time given by
-`client-failure-check-period` as explained in section ?. If the client
+`client-failure-check-period` as explained in section [Detecting Dead Connections](connection-ttl.md). If the client
does not receive data in good time, it will assume the connection has
failed and attempt failover. Also if the socket is closed by the OS,
usually if the server process is killed rather than the machine itself
@@ -683,12 +670,12 @@ ActiveMQ clients can be configured to discover the list of live-backup
server groups in a number of different ways. They can be configured
explicitly or probably the most common way of doing this is to use
*server discovery* for the client to automatically discover the list.
-For full details on how to configure server discovery, please see ?.
+For full details on how to configure server discovery, please see [Clusters](clusters.md).
Alternatively, the clients can explicitly connect to a specific server
-and download the current servers and backups see ?.
+and download the current servers and backups see [Clusters](clusters.md).
To enable automatic client failover, the client must be configured to
-allow non-zero reconnection attempts (as explained in ?).
+allow non-zero reconnection attempts (as explained in [Client Reconnection and Session Reattachment](client-reconnection.md)).
By default failover will only occur after at least one connection has
been made to the live server. In other words, by default, failover will
@@ -697,7 +684,7 @@ server - in this case it will simply retry connecting to the live server
according to the reconnect-attempts property and fail after this number
of attempts.
-### Failing over on the Initial Connection
+#### Failing over on the Initial Connection
Since the client does not learn about the full topology until after the
first connection is made there is a window where it does not know about
@@ -712,7 +699,7 @@ will be thrown.
For examples of automatic failover with transacted and non-transacted
JMS sessions, please see ? and ?.
-### A Note on Server Replication
+#### A Note on Server Replication
ActiveMQ does not replicate full server state between live and backup
servers. When the new session is automatically recreated on the backup
@@ -747,7 +734,7 @@ and only once* delivery, even in the case of failure, by using a
combination of duplicate detection and retrying of transactions. However
this is not 100% transparent to the client code.
-### Handling Blocking Calls During Failover
+#### Handling Blocking Calls During Failover
If the client code is in a blocking call to the server, waiting for a
response to continue its execution, when failover occurs, the new
@@ -767,7 +754,7 @@ throw a `javax.jms.TransactionRolledBackException` (if using JMS), or a
`ActiveMQException` with error code
`ActiveMQException.TRANSACTION_ROLLED_BACK` if using the core API.
-### Handling Failover With Transactions
+#### Handling Failover With Transactions
If the session is transactional and messages have already been sent or
acknowledged in the current transaction, then the server cannot be sure
@@ -816,7 +803,7 @@ live server before failure occurred.
> it does not exist then it is assumed to have been committed although
> the transaction manager may log a warning.
-To remedy this, the client can simply enable duplicate detection (?) in
+To remedy this, the client can simply enable duplicate detection ([Duplicate Message Detection](duplicate-detection.md)) in
the transaction, and retry the transaction operations again after the
call is unblocked. If the transaction had indeed been committed on the
live server successfully before failover, then when the transaction is
@@ -831,17 +818,16 @@ getting sent more than once.
> guarantees for messages can be provided in the case of failure,
> guaranteeing 100% no loss or duplication of messages.
-### Handling Failover With Non Transactional Sessions
+#### Handling Failover With Non Transactional Sessions
If the session is non transactional, messages or acknowledgements can be
lost in the event of failover.
If you wish to provide *once and only once* delivery guarantees for non
transacted sessions too, enabled duplicate detection, and catch unblock
-exceptions as described in ?
+exceptions as described in [Handling Blocking Calls During Failover](ha.md)
-Getting Notified of Connection Failure
---------------------------------------
+### Getting Notified of Connection Failure
JMS provides a standard mechanism for getting notified asynchronously of
connection failure: `java.jms.ExceptionListener`. Please consult the JMS
@@ -867,8 +853,7 @@ following:
: JMSException error codes
-Application-Level Failover
---------------------------
+### Application-Level Failover
In some cases you may not want automatic client failover, and prefer to
handle any connection failure yourself, and code your own manually
http://git-wip-us.apache.org/repos/asf/activemq-6/blob/b4144013/docs/user-manual/en/intercepting-operations.md
----------------------------------------------------------------------
diff --git a/docs/user-manual/en/intercepting-operations.md b/docs/user-manual/en/intercepting-operations.md
index 7d78976..8891299 100644
--- a/docs/user-manual/en/intercepting-operations.md
+++ b/docs/user-manual/en/intercepting-operations.md
@@ -1,5 +1,4 @@
-Intercepting Operations
-=======================
+# Intercepting Operations
ActiveMQ supports *interceptors* to intercept packets entering and
exiting the server. Incoming and outgoing interceptors are be called for
@@ -8,17 +7,18 @@ custom code to be executed, e.g. for auditing packets, filtering or
other reasons. Interceptors can change the packets they intercept. This
makes interceptors powerful, but also potentially dangerous.
-Implementing The Interceptors
-=============================
+## Implementing The Interceptors
An interceptor must implement the `Interceptor interface`:
- package org.apache.activemq.api.core.interceptor;
+``` java
+package org.apache.activemq.api.core.interceptor;
- public interface Interceptor
- {
- boolean intercept(Packet packet, RemotingConnection connection) throws ActiveMQException;
- }
+public interface Interceptor
+{
+ boolean intercept(Packet packet, RemotingConnection connection) throws ActiveMQException;
+}
+```
The returned boolean value is important:
@@ -28,8 +28,7 @@ The returned boolean value is important:
interceptors will be called and the packet will not be processed
further by the server.
-Configuring The Interceptors
-============================
+## Configuring The Interceptors
Both incoming and outgoing interceptors are configured in
`activemq-configuration.xml`:
@@ -47,8 +46,7 @@ Both incoming and outgoing interceptors are configured in
The interceptors classes (and their dependencies) must be added to the
server classpath to be properly instantiated and called.
-Interceptors on the Client Side
-===============================
+## Interceptors on the Client Side
The interceptors can also be run on the client side to intercept packets
either sent by the client to the server or by the server to the client.
@@ -77,8 +75,7 @@ As on the server, the client interceptor classes (and their
dependencies) must be added to the classpath to be properly instantiated
and invoked.
-Example
-=======
+## Example
See ? for an example which shows how to use interceptors to add
properties to a message on the server.
http://git-wip-us.apache.org/repos/asf/activemq-6/blob/b4144013/docs/user-manual/en/interoperability.md
----------------------------------------------------------------------
diff --git a/docs/user-manual/en/interoperability.md b/docs/user-manual/en/interoperability.md
index 58b2257..78d7076 100644
--- a/docs/user-manual/en/interoperability.md
+++ b/docs/user-manual/en/interoperability.md
@@ -1,8 +1,6 @@
-Interoperability
-================
+# Interoperability
-Stomp
-=====
+## Stomp
[Stomp](http://stomp.github.com/) is a text-orientated wire protocol
that allows Stomp clients to communicate with Stomp Brokers. ActiveMQ
@@ -11,8 +9,7 @@ now supports Stomp 1.0, 1.1 and 1.2.
Stomp clients are available for several languages and platforms making
it a good choice for interoperability.
-Native Stomp support
---------------------
+## Native Stomp support
ActiveMQ provides native support for Stomp. To be able to send and
receive Stomp messages, you must configure a `NettyAcceptor` with a
@@ -52,8 +49,7 @@ heartbeat values lower than 500, the server will defaults the value to
500 milliseconds regardless the values of the 'heart-beat' header in the
frame.
-Mapping Stomp destinations to ActiveMQ addresses and queues
------------------------------------------------------------
+### Mapping Stomp destinations to ActiveMQ addresses and queues
Stomp clients deals with *destinations* when sending messages and
subscribing. Destination names are simply strings which are mapped to
@@ -66,8 +62,7 @@ specified destination is mapped to an address. When a Stomp client
subscribes (or unsubscribes) for a destination (using a `SUBSCRIBE` or
`UNSUBSCRIBE` frame), the destination is mapped to a ActiveMQ queue.
-STOMP and connection-ttl
-------------------------
+### STOMP and connection-ttl
Well behaved STOMP clients will always send a DISCONNECT frame before
closing their connections. In this case the server will clear up any
@@ -105,12 +100,12 @@ seconds.
> users can use heart-beats to maintain the life cycle of stomp
> connections.
-Stomp and JMS interoperability
-------------------------------
+### Stomp and JMS interoperability
-### Using JMS destinations
+#### Using JMS destinations
-As explained in ?, JMS destinations are also mapped to ActiveMQ
+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:
@@ -137,7 +132,7 @@ destinations, the Stomp destinations must follow the same convention:
^@
-### Sending and consuming Stomp message from JMS or ActiveMQ Core API
+#### Sending and consuming Stomp message from JMS or ActiveMQ Core API
Stomp is mainly a text-orientated protocol. To make it simpler to
interoperate with JMS and ActiveMQ Core API, our Stomp implementation
@@ -156,7 +151,7 @@ The same logic applies when mapping a JMS message or a Core message to
Stomp. A Stomp client can check the presence of the `content-length`
header to determine the type of the message body (String or bytes).
-### Message IDs for Stomp messages
+#### Message IDs for Stomp messages
When receiving Stomp messages via a JMS consumer or a QueueBrowser, the
messages have no properties like JMSMessageID by default. However this
@@ -183,7 +178,7 @@ long type internal message id prefixed with "`STOMP`", like:
If `stomp-enable-message-id` is not specified in the configuration,
default is `false`.
-### Handling of Large Messages with Stomp
+#### Handling of Large Messages with Stomp
Stomp clients may send very large bodys of frames which can exceed the
size of ActiveMQ server's internal buffer, causing unexpected errors. To
@@ -212,8 +207,7 @@ sending it to stomp clients. The default value of
`stomp-min-large-message-size` is the same as the default value of
[min-large-message-size](#large-messages.core.config).
-Stomp Over Web Sockets
-----------------------
+### Stomp Over Web Sockets
ActiveMQ also support Stomp over [Web
Sockets](http://dev.w3.org/html5/websockets/). Modern web browser which
@@ -242,8 +236,7 @@ The `stomp-websockets` example shows how to configure ActiveMQ server to
have web browsers and Java applications exchanges messages on a JMS
topic.
-StompConnect
-------------
+### StompConnect
[StompConnect](http://stomp.codehaus.org/StompConnect) is a server that
can act as a Stomp broker and proxy the Stomp protocol to the standard
@@ -265,13 +258,11 @@ documentation.
Make sure this file is in the classpath along with the StompConnect jar
and the ActiveMQ jars and simply run `java org.codehaus.stomp.jms.Main`.
-REST
-====
+## REST
-Please see ?
+Please see [Rest Interface](rest.md)
-AMQP
-====
+## AMQP
ActiveMQ supports the [AMQP
1.0](https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=amqp)
@@ -291,15 +282,13 @@ default AMQP port.
There are 2 Stomp examples available see proton-j and proton-ruby which
use the qpid Java and Ruby clients respectively
-AMQP and security
------------------
+### AMQP and security
The ActiveMQ Server accepts AMQP SASL Authentication and will use this
to map onto the underlying session created for the connection so you can
use the normal ActiveMQ security configuration.
-AMQP Links
-----------
+### AMQP Links
An AMQP Link is a uni directional transport for messages between a
source and a target, i.e. a client and the ActiveMQ Broker. A link will
@@ -309,8 +298,7 @@ Message and forwarded to its destination or target. A Receiver will map
onto a ActiveMQ Server Consumer and convert ActiveMQ messages back into
AMQP messages before being delivered.
-AMQP and destinations
----------------------
+### AMQP and destinations
If an AMQP Link is dynamic then a temporary queue will be created and
either the remote source or remote target address will be set to the
@@ -323,8 +311,7 @@ does not exist then an exception will be sent
> For the next version we will add a flag to aut create durable queue
> but for now you will have to add them via the configuration
-AMQP and Coordinations - Handling Transactions
-----------------------------------------------
+### AMQP and Coordinations - Handling Transactions
An AMQP links target can also be a Coordinator, the Coordinator is used
to handle transactions. If a coordinator is used the the underlying
@@ -337,8 +324,7 @@ or committed via the coordinator.
> `amqp:multi-txns-per-ssn`, however in this version ActiveMQ will only
> support single transactions per session
-OpenWire
-========
+## OpenWire
ActiveMQ now supports the
[OpenWire](http://activemq.apache.org/openwire.html) protocol so that an
http://git-wip-us.apache.org/repos/asf/activemq-6/blob/b4144013/docs/user-manual/en/jms-bridge.md
----------------------------------------------------------------------
diff --git a/docs/user-manual/en/jms-bridge.md b/docs/user-manual/en/jms-bridge.md
index 437a177..062d097 100644
--- a/docs/user-manual/en/jms-bridge.md
+++ b/docs/user-manual/en/jms-bridge.md
@@ -1,5 +1,4 @@
-The JMS Bridge
-==============
+# The JMS Bridge
ActiveMQ includes a fully functional JMS message bridge.
@@ -23,7 +22,7 @@ JMS servers, as long as they are JMS 1.1 compliant.
>
> Do not confuse a JMS bridge with a core bridge. A JMS bridge can be
> used to bridge any two JMS 1.1 compliant JMS providers and uses the
-> JMS API. A core bridge (described in ?) is used to bridge any two
+> JMS API. A core bridge (described in [Core Bidges](core-bridges.md)) is used to bridge any two
> ActiveMQ instances and uses the core API. Always use a core bridge if
> you can in preference to a JMS bridge. The core bridge will typically
> provide better performance than a JMS bridge. Also the core bridge can
@@ -183,8 +182,7 @@ server.
</bean>
</deployment>
-JMS Bridge Parameters
-=====================
+## JMS Bridge Parameters
The main bean deployed is the `JMSBridge` bean. The bean is configurable
by the parameters passed to its constructor.
@@ -268,7 +266,7 @@ by the parameters passed to its constructor.
- `ONCE_AND_ONLY_ONCE`
- See ? for a explanation of these modes.
+ See Quality Of Service section for a explanation of these modes.
- Max Batch Size
@@ -333,8 +331,7 @@ look something like this:
<bean name="RealTransactionManager" class="com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionManagerImple"/>
-Source and Target Connection Factories
-======================================
+## Source and Target Connection Factories
The source and target connection factory factories are used to create
the connection factory used to create the connection for the source or
@@ -346,8 +343,7 @@ Application Servers or JMS providers a new implementation may have to be
provided. This can easily be done by implementing the interface
`org.apache.activemq.jms.bridge.ConnectionFactoryFactory`.
-Source and Target Destination Factories
-=======================================
+## Source and Target Destination Factories
Again, similarly, these are used to create or lookup up the
destinations.
@@ -358,14 +354,12 @@ ActiveMQ that looks up the destination using JNDI.
A new implementation can be provided by implementing
`org.apache.activemq.jms.bridge.DestinationFactory` interface.
-Quality Of Service
-==================
+## Quality Of Service
The quality of service modes used by the bridge are described here in
more detail.
-AT\_MOST\_ONCE
---------------
+### AT_MOST_ONCE
With this QoS mode messages will reach the destination from the source
at most once. The messages are consumed from the source and acknowledged
@@ -376,8 +370,7 @@ occur at most once.
This mode is available for both durable and non-durable messages.
-DUPLICATES\_OK
---------------
+### DUPLICATES_OK
With this QoS mode, the messages are consumed from the source and then
acknowledged after they have been successfully sent to the destination.
@@ -388,8 +381,7 @@ after a failure.
This mode is available for both durable and non-durable messages.
-ONCE\_AND\_ONLY\_ONCE
----------------------
+### ONCE_AND_ONLY_ONCE
This QoS mode ensures messages will reach the destination from the
source once and only once. (Sometimes this mode is known as "exactly
@@ -420,8 +412,7 @@ This mode is only available for durable messages.
> this approach is not as watertight as using ONCE\_AND\_ONLY\_ONCE but
> may be a good choice depending on your specific application.
-Time outs and the JMS bridge
-----------------------------
+### Time outs and the JMS bridge
There is a possibility that the target or source server will not be
available at some point in time. If this occurs then the bridge will try
@@ -449,8 +440,7 @@ connection and the second the read timeout for the socket.
If you implement your own factories for looking up JMS resources then
you will have to bear in mind timeout issues.
-Examples
---------
+### Examples
Please see ? which shows how to configure and use a JMS Bridge with
JBoss AS to send messages to the source destination and consume them
http://git-wip-us.apache.org/repos/asf/activemq-6/blob/b4144013/docs/user-manual/en/jms-core-mapping.md
----------------------------------------------------------------------
diff --git a/docs/user-manual/en/jms-core-mapping.md b/docs/user-manual/en/jms-core-mapping.md
index 0be2829..19ff8a4 100644
--- a/docs/user-manual/en/jms-core-mapping.md
+++ b/docs/user-manual/en/jms-core-mapping.md
@@ -1,5 +1,4 @@
-Mapping JMS Concepts to the Core API
-====================================
+# Mapping JMS Concepts to the Core API
This chapter describes how JMS destinations are mapped to ActiveMQ
addresses.
http://git-wip-us.apache.org/repos/asf/activemq-6/blob/b4144013/docs/user-manual/en/large-messages.md
----------------------------------------------------------------------
diff --git a/docs/user-manual/en/large-messages.md b/docs/user-manual/en/large-messages.md
index b04f201..dc459b1 100644
--- a/docs/user-manual/en/large-messages.md
+++ b/docs/user-manual/en/large-messages.md
@@ -1,5 +1,4 @@
-Large Messages
-==============
+# Large Messages
ActiveMQ supports sending and receiving of huge messages, even when the
client and server are running with limited memory. The only realistic
@@ -23,8 +22,7 @@ stream the huge message body to a file on disk or elsewhere. At no time
is the entire message body stored fully in memory, either on the client
or the server.
-Configuring the server
-======================
+## Configuring the server
Large messages are stored on a disk directory on the server side, as
configured on the main configuration file.
@@ -46,8 +44,7 @@ For the best performance we recommend large messages directory is stored
on a different physical volume to the message journal or paging
directory.
-Configuring Parameters
-======================
+## Configuring Parameters
Any message larger than a certain size is considered a large message.
Large messages will be split up and sent in fragments. This is
@@ -64,23 +61,23 @@ determined by the parameter `min-large-message-size`
The default value is 100KiB.
-Using Core API
---------------
+### Using Core API
If the ActiveMQ Core API is used, the minimal large message size is
specified by `ServerLocator.setMinLargeMessageSize`.
- ServerLocator locator = ActiveMQClient.createServerLocatorWithoutHA(new TransportConfiguration(NettyConnectorFactory.class.getName()))
+``` java
+ServerLocator locator = ActiveMQClient.createServerLocatorWithoutHA(new TransportConfiguration(NettyConnectorFactory.class.getName()))
- locator.setMinLargeMessageSize(25 * 1024);
+locator.setMinLargeMessageSize(25 * 1024);
- ClientSessionFactory factory = ActiveMQClient.createClientSessionFactory();
+ClientSessionFactory factory = ActiveMQClient.createClientSessionFactory();
+```
-? will provide more information on how to instantiate the session
+[Configuring the transport directly from the client side](configuring-transports.md) will provide more information on how to instantiate the session
factory.
-Using JMS
----------
+### Using JMS
If JNDI is used to instantiate and look up the connection factory, the
minimum large message size is configured in the JNDI context
@@ -97,13 +94,12 @@ If the connection factory is being instantiated directly, the minimum
large message size is specified by
`ActiveMQConnectionFactory.setMinLargeMessageSize`.
-Compressed Large Messages
--------------------------
+### Compressed Large Messages
You can choose to send large messages in compressed form using `
compress-large-messages` attributes.
-### `compress-large-messages`
+#### `compress-large-messages`
If you specify the boolean property `compress-large-messages` on the
`server locator` or `ConnectionFactory` as true, The system will use the
@@ -129,8 +125,7 @@ by default:
java.naming.provider.url=tcp://localhost:5445
connection.ConnectionFactory.compressLargeMessages=true
-Streaming large messages
-========================
+## Streaming large messages
ActiveMQ supports setting the body of messages using input and output
streams (`java.lang.io`)
@@ -151,8 +146,7 @@ Blobs, `SocketInputStream`, things you recovered from `HTTPRequests`
etc. Anything as long as it implements `java.io.InputStream` for sending
messages or `java.io.OutputStream` for receiving them.
-Streaming over Core API
------------------------
+### Streaming over Core API
The following table shows a list of methods available at `ClientMessage`
which are also available through JMS by the use of object properties.
@@ -167,78 +161,82 @@ which are also available through JMS by the use of object properties.
To set the output stream when receiving a core message:
- ...
- ClientMessage msg = consumer.receive(...);
+``` java
+ClientMessage msg = consumer.receive(...);
- // This will block here until the stream was transferred
- msg.saveOutputStream(someOutputStream);
+// This will block here until the stream was transferred
+msg.saveOutputStream(someOutputStream);
- ClientMessage msg2 = consumer.receive(...);
+ClientMessage msg2 = consumer.receive(...);
- // This will not wait the transfer to finish
- msg.setOutputStream(someOtherOutputStream);
- ...
+// This will not wait the transfer to finish
+msg.setOutputStream(someOtherOutputStream);
+```
Set the input stream when sending a core message:
- ...
- ClientMessage msg = session.createMessage();
- msg.setInputStream(dataInputStream);
- ...
+``` java
+ClientMessage msg = session.createMessage();
+msg.setInputStream(dataInputStream);
+```
Notice also that for messages with more than 2GiB the getBodySize() will
return invalid values since this is an integer (which is also exposed to
the JMS API). On those cases you can use the message property
-\_HQ\_LARGE\_SIZE.
+_HQ_LARGE_SIZE.
-Streaming over JMS
-------------------
+### Streaming over JMS
When using JMS, ActiveMQ maps the streaming methods on the core API (see
-?) by setting object properties . You can use the method
+ClientMessage API table above) by setting object properties . You can use the method
`Message.setObjectProperty` to set the input and output streams.
The `InputStream` can be defined through the JMS Object Property
-JMS\_HQ\_InputStream on messages being sent:
+JMS_HQ_InputStream on messages being sent:
- BytesMessage message = session.createBytesMessage();
+``` java
+BytesMessage message = session.createBytesMessage();
- FileInputStream fileInputStream = new FileInputStream(fileInput);
+FileInputStream fileInputStream = new FileInputStream(fileInput);
- BufferedInputStream bufferedInput = new BufferedInputStream(fileInputStream);
+BufferedInputStream bufferedInput = new BufferedInputStream(fileInputStream);
- message.setObjectProperty("JMS_HQ_InputStream", bufferedInput);
+message.setObjectProperty("JMS_HQ_InputStream", bufferedInput);
- someProducer.send(message);
+someProducer.send(message);
+```
The `OutputStream` can be set through the JMS Object Property
-JMS\_HQ\_SaveStream on messages being received in a blocking way.
-
- BytesMessage messageReceived = (BytesMessage)messageConsumer.receive(120000);
-
- File outputFile = new File("huge_message_received.dat");
-
- FileOutputStream fileOutputStream = new FileOutputStream(outputFile);
-
- BufferedOutputStream bufferedOutput = new BufferedOutputStream(fileOutputStream);
-
- // This will block until the entire content is saved on disk
- messageReceived.setObjectProperty("JMS_HQ_SaveStream", bufferedOutput);
+JMS_HQ_SaveStream on messages being received in a blocking way.
+
+``` java
+BytesMessage messageReceived = (BytesMessage)messageConsumer.receive(120000);
+
+File outputFile = new File("huge_message_received.dat");
+
+FileOutputStream fileOutputStream = new FileOutputStream(outputFile);
+
+BufferedOutputStream bufferedOutput = new BufferedOutputStream(fileOutputStream);
+
+// This will block until the entire content is saved on disk
+messageReceived.setObjectProperty("JMS_HQ_SaveStream", bufferedOutput);
+```
Setting the `OutputStream` could also be done in a non blocking way
-using the property JMS\_HQ\_OutputStream.
+using the property JMS_HQ_OutputStream.
- // This won't wait the stream to finish. You need to keep the consumer active.
- messageReceived.setObjectProperty("JMS_HQ_OutputStream", bufferedOutput);
+``` java
+// This won't wait the stream to finish. You need to keep the consumer active.
+messageReceived.setObjectProperty("JMS_HQ_OutputStream", bufferedOutput);
+```
> **Note**
>
> When using JMS, Streaming large messages are only supported on
> `StreamMessage` and `BytesMessage`.
-Streaming Alternative
-=====================
+## Streaming Alternative
If you choose not to use the `InputStream` or `OutputStream` capability
of ActiveMQ You could still access the data directly in an alternative
@@ -246,30 +244,32 @@ fashion.
On the Core API just get the bytes of the body as you normally would.
- ClientMessage msg = consumer.receive();
-
- byte[] bytes = new byte[1024];
- for (int i = 0 ; i < msg.getBodySize(); i += bytes.length)
- {
- msg.getBody().readBytes(bytes);
- // Whatever you want to do with the bytes
- }
+``` java
+ClientMessage msg = consumer.receive();
+
+byte[] bytes = new byte[1024];
+for (int i = 0 ; i < msg.getBodySize(); i += bytes.length)
+{
+ msg.getBody().readBytes(bytes);
+ // Whatever you want to do with the bytes
+}
+```
If using JMS API, `BytesMessage` and `StreamMessage` also supports it
transparently.
+``` java
+BytesMessage rm = (BytesMessage)cons.receive(10000);
- BytesMessage rm = (BytesMessage)cons.receive(10000);
-
- byte data[] = new byte[1024];
+byte data[] = new byte[1024];
- for (int i = 0; i < rm.getBodyLength(); i += 1024)
- {
- int numberOfBytes = rm.readBytes(data);
- // Do whatever you want with the data
- }
+for (int i = 0; i < rm.getBodyLength(); i += 1024)
+{
+ int numberOfBytes = rm.readBytes(data);
+ // Do whatever you want with the data
+}
+```
-Large message example
-=====================
+## Large message example
Please see ? for an example which shows how large message is configured
and used with JMS.
http://git-wip-us.apache.org/repos/asf/activemq-6/blob/b4144013/docs/user-manual/en/last-value-queues.md
----------------------------------------------------------------------
diff --git a/docs/user-manual/en/last-value-queues.md b/docs/user-manual/en/last-value-queues.md
index eca5eb5..9246e57 100644
--- a/docs/user-manual/en/last-value-queues.md
+++ b/docs/user-manual/en/last-value-queues.md
@@ -1,5 +1,4 @@
-Last-Value Queues
-=================
+# Last-Value Queues
Last-Value queues are special queues which discard any messages when a
newer message with the same value for a well-defined Last-Value property
@@ -9,8 +8,7 @@ last value.
A typical example for Last-Value queue is for stock prices, where you
are only interested by the latest value for a particular stock.
-Configuring Last-Value Queues
-=============================
+## Configuring Last-Value Queues
Last-value queues are defined in the address-setting configuration:
@@ -21,8 +19,7 @@ Last-value queues are defined in the address-setting configuration:
By default, `last-value-queue` is false. Address wildcards can be used
to configure Last-Value queues for a set of addresses (see ?).
-Using Last-Value Property
-=========================
+## Using Last-Value Property
The property name used to identify the last value is `"_HQ_LVQ_NAME"`
(or the constant `Message.HDR_LAST_VALUE_NAME` from the Core API).
@@ -31,25 +28,26 @@ For example, if two messages with the same value for the Last-Value
property are sent to a Last-Value queue, only the latest message will be
kept in the queue:
- // send 1st message with Last-Value property set to STOCK_NAME
- TextMessage message = session.createTextMessage("1st message with Last-Value property set");
- message.setStringProperty("_HQ_LVQ_NAME", "STOCK_NAME");
- producer.send(message);
-
- // send 2nd message with Last-Value property set to STOCK_NAME
- message = session.createTextMessage("2nd message with Last-Value property set");
- message.setStringProperty("_HQ_LVQ_NAME", "STOCK_NAME");
- producer.send(message);
-
- ...
-
- // only the 2nd message will be received: it is the latest with
- // the Last-Value property set
- TextMessage messageReceived = (TextMessage)messageConsumer.receive(5000);
- System.out.format("Received message: %s\n", messageReceived.getText());
-
-Example
-=======
+``` java
+// send 1st message with Last-Value property set to STOCK_NAME
+TextMessage message = session.createTextMessage("1st message with Last-Value property set");
+message.setStringProperty("_HQ_LVQ_NAME", "STOCK_NAME");
+producer.send(message);
+
+// send 2nd message with Last-Value property set to STOCK_NAME
+message = session.createTextMessage("2nd message with Last-Value property set");
+message.setStringProperty("_HQ_LVQ_NAME", "STOCK_NAME");
+producer.send(message);
+
+...
+
+// only the 2nd message will be received: it is the latest with
+// the Last-Value property set
+TextMessage messageReceived = (TextMessage)messageConsumer.receive(5000);
+System.out.format("Received message: %s\n", messageReceived.getText());
+```
+
+## Example
See ? for an example which shows how last value queues are configured
and used with JMS.
http://git-wip-us.apache.org/repos/asf/activemq-6/blob/b4144013/docs/user-manual/en/libaio.md
----------------------------------------------------------------------
diff --git a/docs/user-manual/en/libaio.md b/docs/user-manual/en/libaio.md
index 1e5f9ae..a5ec2d8 100644
--- a/docs/user-manual/en/libaio.md
+++ b/docs/user-manual/en/libaio.md
@@ -1,5 +1,4 @@
-Libaio Native Libraries
-=======================
+# Libaio Native Libraries
ActiveMQ distributes a native library, used as a bridge between ActiveMQ
and Linux libaio.
@@ -10,7 +9,7 @@ processed asynchronously. Some time later the OS will call our code back
when they have been processed.
We use this in our high performance journal if configured to do so,
-please see ?.
+please see [Persistence](persistence.md).
These are the native libraries distributed by ActiveMQ:
@@ -21,16 +20,14 @@ These are the native libraries distributed by ActiveMQ:
When using libaio, ActiveMQ will always try loading these files as long
as they are on the [library path](#using-server.library.path).
-Compiling the native libraries
-==============================
+## Compiling the native libraries
In the case that you are using Linux on a platform other than x86\_32 or
x86\_64 (for example Itanium 64 bits or IBM Power) you may need to
compile the native library, since we do not distribute binaries for
those platforms with the release.
-Install requirements
---------------------
+## Install requirements
> **Note**
>
@@ -76,8 +73,7 @@ Or on Debian systems:
> the version and Linux distribution. (for example gcc-c++ on Fedora
> versus g++ on Debian systems)
-Invoking the compilation
-------------------------
+## Invoking the compilation
In the distribution, in the `native-src` directory, execute the shell
script `bootstrap`. This script will invoke `automake` and `make` what
http://git-wip-us.apache.org/repos/asf/activemq-6/blob/b4144013/docs/user-manual/en/logging.md
----------------------------------------------------------------------
diff --git a/docs/user-manual/en/logging.md b/docs/user-manual/en/logging.md
index 32ef718..e8c6700 100644
--- a/docs/user-manual/en/logging.md
+++ b/docs/user-manual/en/logging.md
@@ -1,5 +1,4 @@
-Logging
-=======
+# Logging
ActiveMQ uses the JBoss Logging framework to do its logging and is
configurable via the `logging.properties` file found in the
@@ -19,8 +18,7 @@ There are 6 loggers available which are as follows:
: Global Configuration Properties
-Logging in a client or with an Embedded server
-==============================================
+## Logging in a client or with an Embedded server
Firstly, if you want to enable logging on the client side you need to
include the JBoss logging jars in your library. If you are using maven
@@ -85,8 +83,7 @@ The following is a typical `logging.properties for a client`
formatter.PATTERN.properties=pattern
formatter.PATTERN.pattern=%d{HH:mm:ss,SSS} %-5p [%c] %s%E%n
-Logging With The JBoss Application Server
-=========================================
+## Logging With The JBoss Application Server
When ActiveMQ is deployed within the JBoss Application Server version
7.x or above then it will still use JBoss Logging, refer to the AS7