activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From clebertsuco...@apache.org
Subject [3/5] activemq-6 git commit: documentation review fixes
Date Fri, 12 Dec 2014 16:32:50 GMT
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).
 
 ![ActiveMQ ha-shared-store.png](images/ha-shared-store.png)
 
-### 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
 
 ![ActiveMQ ha-colocated.png](images/ha-colocated.png)
 
-### 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


Mime
View raw message