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