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 <[email protected]> Authored: Wed Feb 25 13:37:19 2015 +0000 Committer: Andy Taylor <[email protected]> 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:
