This closes #78 - doc updates and log manager dep
This commit is contained in:
commit
51793627f9
|
@ -1,7 +1,10 @@
|
|||
# Summary
|
||||
|
||||
* [Introduction](README.md)
|
||||
* [Legal Notice](notice.md)
|
||||
* [Preface](preface.md)
|
||||
* [Project Info](project-info/project-info.md)
|
||||
* [Messaging Concepts](messaging-concepts/messaging-concepts.md)
|
||||
* [Messaging Concepts](messaging-concepts.md)
|
||||
* [Architecture](architecture.md)
|
||||
* [Using the Server](using-server.md)
|
||||
* [Using JMS](using-jms.md)
|
||||
|
@ -50,4 +53,5 @@
|
|||
* [Interoperability](interoperability.md)
|
||||
* [Tools](tools.md)
|
||||
* [Performance Tuning](perf-tuning.md)
|
||||
* [Configuration Reference](configuration-index.md)
|
||||
* [Configuration Reference](configuration-index.md)
|
||||
|
||||
|
|
|
@ -14,7 +14,7 @@ other than the standard JDK classes! This is because we use some of the
|
|||
netty buffer classes internally.
|
||||
|
||||
This allows ActiveMQ to be easily embedded in your own project, or
|
||||
instantiated in any dependency injection framework such as Spring or
|
||||
instantiated in any dependency injection framework such as Spring or
|
||||
Google Guice.
|
||||
|
||||
Each ActiveMQ server has its own ultra high performance persistent
|
||||
|
@ -131,8 +131,8 @@ configuration. It also provides a simple management API for
|
|||
creating and destroying Queues and Topics
|
||||
which can be accessed via JMX or the connection. It is a separate
|
||||
service to the ActiveMQ core server, since the core server is JMS
|
||||
agnostic. If you don't want to deploy any JMS Queue or Topic via
|
||||
server side XML configuration and don't require a JMS management
|
||||
agnostic. If you don't want to deploy any JMS Queue or Topic via
|
||||
server side XML configuration and don't require a JMS management
|
||||
API on the server side then you can disable this service.
|
||||
|
||||
The stand-alone server configuration uses [Airline](https://github.com/airlift/airline)
|
||||
|
|
|
@ -760,4 +760,4 @@ Embedded
|
|||
--------
|
||||
|
||||
The `embedded` example shows how to embed the ActiveMQ server within
|
||||
your own code.
|
||||
your own code.
|
||||
|
|
|
@ -188,16 +188,10 @@ by the parameters passed to its constructor.
|
|||
to register the JMS Bridge MBean (must be unique)
|
||||
|
||||
The "transactionManager" property points to a JTA transaction manager
|
||||
implementation. ActiveMQ doesn't ship with such an implementation, but
|
||||
one is available in the JBoss Community. If you are running ActiveMQ in
|
||||
standalone mode and wish to use a JMS bridge simply download the latest
|
||||
version of JBossTS from http://www.jboss.org/jbosstm/downloads and add
|
||||
it to ActiveMQ's classpath. If you are running ActiveMQ with JBoss AS
|
||||
then you won't need to do this as JBoss AS ships with a JTA transaction
|
||||
manager already. The bean definition for the transaction manager would
|
||||
look something like this:
|
||||
|
||||
<bean name="RealTransactionManager" class="com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionManagerImple"/>
|
||||
implementation and should be set if you need to use the 'ONCE_AND_ONCE_ONLY'
|
||||
Quality of Service. ActiveMQ doesn't ship with such an implementation, but
|
||||
if you are running within an Application Server you can inject the Transaction
|
||||
Manager that is shipped.
|
||||
|
||||
## Source and Target Connection Factories
|
||||
|
||||
|
@ -258,12 +252,8 @@ server instance then this can be achieved by sending and acknowledging
|
|||
the messages in the same local transaction. If the source and
|
||||
destination are on different servers this is achieved by enlisting the
|
||||
sending and consuming sessions in a JTA transaction. The JTA transaction
|
||||
is controlled by JBoss Transactions JTA \* implementation which is a
|
||||
fully recovering transaction manager, thus providing a very high degree
|
||||
of durability. If JTA is required then both supplied connection
|
||||
factories need to be XAConnectionFactory implementations. This is likely
|
||||
to be the slowest mode since it requires extra persistence for the
|
||||
transaction logging.
|
||||
is controlled by a JTA Transaction Manager which will need to be set
|
||||
via the settransactionManager method on the Bridge.
|
||||
|
||||
This mode is only available for durable messages.
|
||||
|
||||
|
|
|
@ -32,7 +32,7 @@ large messages are stored.
|
|||
|
||||
<configuration xmlns="urn:activemq"
|
||||
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
|
||||
xsi:schemaLocation="urn:activemq /schema/activemq-configuration.xsd">
|
||||
xsi:schemaLocation="urn:activemq /schema/activemq-server.xsd">
|
||||
...
|
||||
<large-messages-directory>/data/large-messages</large-messages-directory>
|
||||
...
|
||||
|
@ -88,7 +88,7 @@ by default:
|
|||
java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory
|
||||
java.naming.provider.url=tcp://localhost:5445
|
||||
connection.ConnectionFactory.minLargeMessageSize=250000
|
||||
|
||||
|
||||
|
||||
If the connection factory is being instantiated directly, the minimum
|
||||
large message size is specified by
|
||||
|
@ -113,7 +113,7 @@ If the compressed size of a large message is below `
|
|||
messages. This means that the message won't be written into the server's
|
||||
large-message data directory, thus reducing the disk I/O.
|
||||
|
||||
###
|
||||
###
|
||||
|
||||
If JNDI is used to instantiate and look up the connection factory, large
|
||||
message compression can be configured in the JNDI context environment,
|
||||
|
@ -151,11 +151,38 @@ messages or `java.io.OutputStream` for receiving them.
|
|||
The following table shows a list of methods available at `ClientMessage`
|
||||
which are also available through JMS by the use of object properties.
|
||||
|
||||
Name Description JMS Equivalent Property
|
||||
--------------------------------- ---------------------------------------------------------------------------------------------------------------------------------- -------------------------
|
||||
setBodyInputStream(InputStream) Set the InputStream used to read a message body when sending it. JMS\_HQ\_InputStream
|
||||
setOutputStream(OutputStream) Set the OutputStream that will receive the body of a message. This method does not block. JMS\_HQ\_OutputStream
|
||||
saveOutputStream(OutputStream) Save the body of the message to the `OutputStream`. It will block until the entire content is transferred to the `OutputStream`. JMS\_HQ\_SaveStream
|
||||
<table summary="Server Configuration" border="1">
|
||||
<colgroup>
|
||||
<col/>
|
||||
<col/>
|
||||
<col/>
|
||||
<col/>
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<th>Description</th>
|
||||
<th>JMS Equivalent</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>setBodyInputStream(InputStream)</td>
|
||||
<td>Set the InputStream used to read a message body when sending it.</td>
|
||||
<td>JMS_HQ_InputStream</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>setOutputStream(OutputStream)</td>
|
||||
<td>Set the OutputStream that will receive the body of a message. This method does not block.</td>
|
||||
<td>JMS_HQ_OutputStream</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>saveOutputStream(OutputStream)</td>
|
||||
<td>Save the body of the message to the `OutputStream`. It will block until the entire content is transferred to the `OutputStream`.</td>
|
||||
<td>JMS_HQ_SaveStream</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
: org.apache.activemq.api.core.client.ClientMessage API
|
||||
|
||||
|
@ -166,12 +193,12 @@ ClientMessage msg = consumer.receive(...);
|
|||
|
||||
|
||||
// This will block here until the stream was transferred
|
||||
msg.saveOutputStream(someOutputStream);
|
||||
msg.saveOutputStream(someOutputStream);
|
||||
|
||||
ClientMessage msg2 = consumer.receive(...);
|
||||
|
||||
// This will not wait the transfer to finish
|
||||
msg.setOutputStream(someOtherOutputStream);
|
||||
msg.setOutputStream(someOtherOutputStream);
|
||||
```
|
||||
|
||||
Set the input stream when sending a core message:
|
||||
|
@ -212,13 +239,13 @@ JMS_HQ_SaveStream on messages being received in a blocking way.
|
|||
|
||||
``` java
|
||||
BytesMessage messageReceived = (BytesMessage)messageConsumer.receive(120000);
|
||||
|
||||
|
||||
File outputFile = new File("huge_message_received.dat");
|
||||
|
||||
|
||||
FileOutputStream fileOutputStream = new FileOutputStream(outputFile);
|
||||
|
||||
|
||||
BufferedOutputStream bufferedOutput = new BufferedOutputStream(fileOutputStream);
|
||||
|
||||
|
||||
// This will block until the entire content is saved on disk
|
||||
messageReceived.setObjectProperty("JMS_HQ_SaveStream", bufferedOutput);
|
||||
```
|
||||
|
@ -246,7 +273,7 @@ On the Core API just get the bytes of the body as you normally would.
|
|||
|
||||
``` java
|
||||
ClientMessage msg = consumer.receive();
|
||||
|
||||
|
||||
byte[] bytes = new byte[1024];
|
||||
for (int i = 0 ; i < msg.getBodySize(); i += bytes.length)
|
||||
{
|
||||
|
@ -266,10 +293,10 @@ for (int i = 0; i < rm.getBodyLength(); i += 1024)
|
|||
{
|
||||
int numberOfBytes = rm.readBytes(data);
|
||||
// Do whatever you want with the data
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Large message example
|
||||
|
||||
Please see ? for an example which shows how large message is configured
|
||||
Please see the [examples](examples.md) chapter for an example which shows how large message is configured
|
||||
and used with JMS.
|
||||
|
|
|
@ -34,14 +34,14 @@ TextMessage message = session.createTextMessage("1st message with Last-Value pro
|
|||
message.setStringProperty("_HQ_LVQ_NAME", "STOCK_NAME");
|
||||
producer.send(message);
|
||||
|
||||
// send 2nd message with Last-Value property set to STOCK_NAME
|
||||
// send 2nd message with Last-Value property set to STOCK_NAME
|
||||
message = session.createTextMessage("2nd message with Last-Value property set");
|
||||
message.setStringProperty("_HQ_LVQ_NAME", "STOCK_NAME");
|
||||
producer.send(message);
|
||||
|
||||
|
||||
...
|
||||
|
||||
// only the 2nd message will be received: it is the latest with
|
||||
|
||||
// only the 2nd message will be received: it is the latest with
|
||||
// the Last-Value property set
|
||||
TextMessage messageReceived = (TextMessage)messageConsumer.receive(5000);
|
||||
System.out.format("Received message: %s\n", messageReceived.getText());
|
||||
|
@ -49,5 +49,5 @@ System.out.format("Received message: %s\n", messageReceived.getText());
|
|||
|
||||
## Example
|
||||
|
||||
See ? for an example which shows how last value queues are configured
|
||||
See the [examples](examples.md) chapter for an example which shows how last value queues are configured
|
||||
and used with JMS.
|
||||
|
|
|
@ -79,7 +79,7 @@ In the distribution, in the `native-src` directory, execute the shell
|
|||
script `bootstrap`. This script will invoke `automake` and `make` what
|
||||
will create all the make files and the native library.
|
||||
|
||||
someUser@someBox:/messaging-distribution/native-src$ ./bootstrap
|
||||
someUser@someBox:/messaging-distribution/native-src$ ./bootstrap
|
||||
checking for a BSD-compatible install... /usr/bin/install -c
|
||||
checking whether build environment is sane... yes
|
||||
checking for a thread-safe mkdir -p... /bin/mkdir -p
|
||||
|
|
|
@ -7,14 +7,44 @@ the console and to a file.
|
|||
|
||||
There are 6 loggers available which are as follows:
|
||||
|
||||
Logger Logger Description
|
||||
------------------------------------------- ----------------------------------------------------
|
||||
org.jboss.logging Logs any calls not handled by the ActiveMQ loggers
|
||||
org.apache.activemq.core.server Logs the core server
|
||||
org.apache.activemq.utils Logs utility calls
|
||||
org.apache.activemq.journal Logs Journal calls
|
||||
org.apache.activemq.jms Logs JMS calls
|
||||
org.apache.activemq.integration.bootstrap Logs bootstrap calls
|
||||
<table summary="Loggers" border="1">
|
||||
<colgroup>
|
||||
<col/>
|
||||
<col/>
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Logger</th>
|
||||
<th>Logger Description</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>org.jboss.logging</td>
|
||||
<td>Logs any calls not handled by the ActiveMQ loggers</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>org.apache.activemq.core.server</td>
|
||||
<td>Logs the core server</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>org.apache.activemq.utils</td>
|
||||
<td>Logs utility calls</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>org.apache.activemq.journal</td>
|
||||
<td>Logs Journal calls</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>org.apache.activemq.jms</td>
|
||||
<td>Logs JMS calls</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>org.apache.activemq.integration.bootstrap </td>
|
||||
<td>Logs bootstrap calls</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
: Global Configuration Properties
|
||||
|
||||
|
@ -27,12 +57,12 @@ add the following dependencies.
|
|||
<dependency>
|
||||
<groupId>org.jboss.logmanager</groupId>
|
||||
<artifactId>jboss-logmanager</artifactId>
|
||||
<version>1.3.1.Final</version>
|
||||
<version>1.5.3.Final</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.apache.activemq</groupId>
|
||||
<artifactId>activemq-core-client</artifactId>
|
||||
<version>2.3.0.Final</version>
|
||||
<version>6.0.0</version>
|
||||
</dependency>
|
||||
|
||||
There are 2 properties you need to set when starting your java program,
|
||||
|
|
|
@ -216,7 +216,7 @@ messages with a given property.)
|
|||
|
||||
Message counters can be listed for a queue with the
|
||||
`listMessageCounter()` and `listMessageCounterHistory()` methods
|
||||
(see Message Counters section). The message counters can also be
|
||||
(see Message Counters section). The message counters can also be
|
||||
reset for a single queue using the `resetMessageCounter()` method.
|
||||
|
||||
- Retrieving the queue attributes
|
||||
|
@ -329,7 +329,7 @@ using the `JMSServerControl` class (with the ObjectName
|
|||
curly braces. For example `{key=10}, {key=20}`. In that case, the
|
||||
first `key` will be associated to the first transport configuration
|
||||
and the second `key` will be associated to the second transport
|
||||
configuration (see [Configuring Transports](configuring-transports.md)
|
||||
configuration (see [Configuring Transports](configuring-transports.md)
|
||||
for a list of the transport parameters)
|
||||
|
||||
- Listing, creating, destroying queues
|
||||
|
@ -541,9 +541,22 @@ is also deployed to allow access to the mbean server via rest.
|
|||
|
||||
### Example
|
||||
|
||||
See ? for an example which shows how to use a remote connection to JMX
|
||||
See the [chapters](examples.md) chapter for an example which shows how to use a remote connection to JMX
|
||||
and MBean proxies to manage ActiveMQ.
|
||||
|
||||
### Exposing JMX using Jolokia
|
||||
|
||||
The default Broker configuration ships with the [Jolokia](http://www.jolokia.org)
|
||||
http agent deployed as a Web Application. Jolokia is a remote
|
||||
JMX over HTTP bridge that exposed mBeans, for a full guids as
|
||||
to how to use refer to [Jolokia Documentation](http://www.jolokia.org/documentation.html),
|
||||
however a simple example to query thebrokers version would
|
||||
be to use a brower and go to the URL http://localhost:8161/jolokia/read/org.apache.activemq:module=Core,type=Server/Version.
|
||||
|
||||
This would give you back something like the following:
|
||||
|
||||
{"timestamp":1422019706,"status":200,"request":{"mbean":"org.apache.activemq:module=Core,type=Server","attribute":"Version","type":"read"},"value":"6.0.0.SNAPSHOT (Active Hornet, 126)"}
|
||||
|
||||
## Using Management Via Core API
|
||||
|
||||
The core management API in ActiveMQ is called by sending Core messages
|
||||
|
@ -685,8 +698,8 @@ steps are the same (see Configuring Core Management section).
|
|||
|
||||
### Example
|
||||
|
||||
See ? for an example which shows how to use JMS messages to manage
|
||||
ActiveMQ server.
|
||||
See the [examples](examples.md) chapter for an example which shows
|
||||
how to use JMS messages to manage the ActiveMQ server.
|
||||
|
||||
## Management Notifications
|
||||
|
||||
|
@ -787,8 +800,7 @@ notificationConsumer.setMessageListener(new MessageListener()
|
|||
```
|
||||
### Example
|
||||
|
||||
See ? for an example which shows how to use a JMS `MessageListener` to
|
||||
receive management notifications from ActiveMQ server.
|
||||
See the [examples](examples.md) chapter for an example which shows how to use a JMS `MessageListener` to receive management notifications from ActiveMQ server.
|
||||
|
||||
### Notification Types and Headers
|
||||
|
||||
|
@ -967,10 +979,10 @@ JMSQueueControlMBean queueControl = (JMSQueueControl)MBeanServerInvocationHandle
|
|||
on,
|
||||
JMSQueueControl.class,
|
||||
false);
|
||||
// message counters are retrieved as a JSON String
|
||||
// message counters are retrieved as a JSON String
|
||||
String counters = queueControl.listMessageCounter();
|
||||
// use the MessageCounterInfo helper class to manipulate message counters more easily
|
||||
MessageCounterInfo messageCounter = MessageCounterInfo.fromJSON(counters);
|
||||
MessageCounterInfo messageCounter = MessageCounterInfo.fromJSON(counters);
|
||||
System.out.format("%s message(s) in the queue (since last sample: %s)\n",
|
||||
messageCounter.getMessageCount(),
|
||||
messageCounter.getMessageCountDelta());
|
||||
|
@ -978,5 +990,4 @@ messageCounter.getMessageCountDelta());
|
|||
|
||||
### Example
|
||||
|
||||
See ? for an example which shows how to use message counters to retrieve
|
||||
information on a JMS `Queue`.
|
||||
See the [examples](examples.md) chapter for an example which shows how to use message counters to retrieve information on a JMS `Queue`.
|
||||
|
|
|
@ -21,7 +21,7 @@ message:
|
|||
|
||||
JMS MessageProducer allows to set a TimeToLive for the messages it sent:
|
||||
|
||||
// messages sent by this producer will be retained for 5s (5000ms) before expiration
|
||||
// messages sent by this producer will be retained for 5s (5000ms) before expiration
|
||||
producer.setTimeToLive(5000);
|
||||
|
||||
Expired messages which are consumed from an expiry address have the
|
||||
|
@ -76,5 +76,4 @@ The reaper thread can be configured with the following properties in
|
|||
|
||||
## Example
|
||||
|
||||
See ? for an example which shows how message expiry is configured and
|
||||
used with JMS.
|
||||
See the [examples.md](examples.md) chapter for an example which shows how message expiry is configured and used with JMS.
|
||||
|
|
|
@ -84,13 +84,7 @@ which is available in the context by default:
|
|||
|
||||
## Example
|
||||
|
||||
See ? for an example which shows how message groups are configured and
|
||||
used with JMS.
|
||||
|
||||
## Example
|
||||
|
||||
See ? for an example which shows how message groups are configured via a
|
||||
connection factory.
|
||||
See the [examples](examples.md} chapter for an example which shows how message groups are configured and used with JMS and via a connection factory.
|
||||
|
||||
## Clustered Grouping
|
||||
|
||||
|
@ -186,5 +180,4 @@ Some best practices should be followed when using clustered grouping:
|
|||
|
||||
## Clustered Grouping Example
|
||||
|
||||
See ? for an example of how to configure message groups with a ActiveMQ
|
||||
cluster
|
||||
See the [examples](examples.md) chapter for an example of how to configure message groups with a ActiveMQ Cluster.
|
||||
|
|
|
@ -37,7 +37,7 @@ Global paging parameters are specified on the main configuration file
|
|||
|
||||
<configuration xmlns="urn:activemq"
|
||||
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
|
||||
xsi:schemaLocation="urn:activemq /schema/activemq-configuration.xsd">
|
||||
xsi:schemaLocation="urn:activemq /schema/activemq-server.xsd">
|
||||
...
|
||||
<paging-directory>/somewhere/paging-directory</paging-directory>
|
||||
...
|
||||
|
@ -76,14 +76,42 @@ configuration file (`activemq-configuration.xml`).
|
|||
|
||||
This is the list of available parameters on the address settings.
|
||||
|
||||
Property Name Description Default
|
||||
----------------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ----------------------------------
|
||||
`max-size-bytes` What's the max memory the address could have before entering on page mode. -1 (disabled)
|
||||
`page-size-bytes` The size of each page file used on the paging system 10MiB (10 \* 1024 \* 1024 bytes)
|
||||
`address-full-policy` This must be set to PAGE for paging to enable. If the value is PAGE then further messages will be paged to disk. If the value is DROP then further messages will be silently dropped. If the value is FAIL then the messages will be dropped and the client message producers will receive an exception. If the value is BLOCK then client message producers will block when they try and send further messages. PAGE
|
||||
`page-max-cache-size` The system will keep up to \<`page-max-cache-size` page files in memory to optimize IO during paging navigation. 5
|
||||
|
||||
: Paging Address Settings
|
||||
<table summary="Server Configuration" border="1">
|
||||
<colgroup>
|
||||
<col/>
|
||||
<col/>
|
||||
<col/>
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Property Name</th>
|
||||
<th>Description</th>
|
||||
<th>Default</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>`max-size-bytes`</td>
|
||||
<td>What's the max memory the address could have before entering on page mode.</td>
|
||||
<td>-1 (disabled)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>`page-size-bytes`</td>
|
||||
<td>The size of each page file used on the paging system</td>
|
||||
<td>10MiB (10 \* 1024 \* 1024 bytes)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>`address-full-policy`</td>
|
||||
<td>This must be set to PAGE for paging to enable. If the value is PAGE then further messages will be paged to disk. If the value is DROP then further messages will be silently dropped. If the value is FAIL then the messages will be dropped and the client message producers will receive an exception. If the value is BLOCK then client message producers will block when they try and send further messages.</td>
|
||||
<td>PAGE</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>`page-max-cache-size`</td>
|
||||
<td>The system will keep up to \<`page-max-cache-size` page files in memory to optimize IO during paging navigation.</td>
|
||||
<td>5</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## Dropping messages
|
||||
|
||||
|
@ -147,4 +175,4 @@ undesirable state.
|
|||
|
||||
## Example
|
||||
|
||||
See ? for an example which shows how to use paging with ActiveMQ.
|
||||
See the [examples]9examples.md) chapter for an example which shows how to use paging with ActiveMQ.
|
||||
|
|
|
@ -85,7 +85,7 @@ tuning:
|
|||
reached the server by the time the call to send() returns, don't set
|
||||
durable messages to be sent blocking, instead use asynchronous send
|
||||
acknowledgements to get your acknowledgements of send back in a
|
||||
separate stream, see [Guarantees of sends and commits](send-guarantees.md)
|
||||
separate stream, see [Guarantees of sends and commits](send-guarantees.md)
|
||||
for more information on this.
|
||||
|
||||
- Use pre-acknowledge mode. With pre-acknowledge mode, messages are
|
||||
|
@ -104,7 +104,7 @@ tuning:
|
|||
- Sync transactions lazily. Setting `journal-sync-transactional` to
|
||||
`false` in `activemq-configuration.xml` can give you better
|
||||
transactional persistent performance at the expense of some
|
||||
possibility of loss of transactions on failure. See [Guarantees of sends and commits](send-guarantees.md)
|
||||
possibility of loss of transactions on failure. See [Guarantees of sends and commits](send-guarantees.md)
|
||||
for more information.
|
||||
|
||||
- Sync non transactional lazily. Setting
|
||||
|
@ -115,10 +115,10 @@ tuning:
|
|||
for more information.
|
||||
|
||||
- Send messages non blocking. Setting `block-on-durable-send` and
|
||||
`block-on-non-durable-send` to `false` in `activemq-jms.xml` (if
|
||||
`block-on-non-durable-send` to `false` in the jms config (if
|
||||
you're using JMS and JNDI) or directly on the ServerLocator. This
|
||||
means you don't have to wait a whole network round trip for every
|
||||
message sent. See [Guarantees of sends and commits](send-guarantees.md)
|
||||
message sent. See [Guarantees of sends and commits](send-guarantees.md)
|
||||
for more information.
|
||||
|
||||
- If you have very fast consumers, you can increase
|
||||
|
@ -148,7 +148,7 @@ tuning:
|
|||
|
||||
- TCP buffer sizes. If you have a fast network and fast machines you
|
||||
may get a performance boost by increasing the TCP send and receive
|
||||
buffer sizes. See the [Configuring the Transport](configuring-transports.md)
|
||||
buffer sizes. See the [Configuring the Transport](configuring-transports.md)
|
||||
for more information on this.
|
||||
|
||||
> **Note**
|
||||
|
@ -179,7 +179,7 @@ tuning:
|
|||
`activemq-configuration.xml` and JMS connection factory
|
||||
(`ThroughputConnectionFactory`) in `activemq-jms.xml`which can be
|
||||
used to give the very best throughput, especially for small
|
||||
messages. See the [Configuring the Transport](configuring-transports.md)
|
||||
messages. See the [Configuring the Transport](configuring-transports.md)
|
||||
for more information on this.
|
||||
|
||||
## Tuning the VM
|
||||
|
|
|
@ -123,7 +123,7 @@ ActiveMQ can also be configured to page messages to disk in low memory
|
|||
situations. This is discussed in [Paging](paging.md).
|
||||
|
||||
If no persistence is required at all, ActiveMQ can also be configured
|
||||
not to persist any data at all to storage as discussed in the Configuring
|
||||
not to persist any data at all to storage as discussed in the Configuring
|
||||
HornetQ for Zero Persistence section.
|
||||
|
||||
## Configuring the bindings journal
|
||||
|
|
|
@ -84,5 +84,4 @@ the exception the message is individually acked.
|
|||
|
||||
## Example
|
||||
|
||||
See ? for an example which shows how to use pre-acknowledgement mode
|
||||
with JMS.
|
||||
See the [examples](examples.md) chapter for an example which shows how to use pre-acknowledgement mode with JMS.
|
||||
|
|
|
@ -10,7 +10,7 @@ attribute has.
|
|||
Queues can be predefined via configuration at a core level or at a JMS
|
||||
level. Firstly let's look at a JMS level.
|
||||
|
||||
The following shows a queue predefined in the `activemq-jms.xml`
|
||||
The following shows a queue predefined in the jms element of the `activemq-configuration.xml`
|
||||
configuration file.
|
||||
|
||||
<queue name="selectorQueue">
|
||||
|
@ -187,4 +187,4 @@ queue whose name fits the address `match`. Queues which are auto-created
|
|||
are durable, non-temporary, and non-transient.
|
||||
|
||||
`auto-delete-jms-queues`. Whether or not to the broker should automatically
|
||||
delete auto-created JMS queues when they have both 0 consumers and 0 messages.
|
||||
delete auto-created JMS queues when they have both 0 consumers and 0 messages.
|
||||
|
|
|
@ -140,28 +140,6 @@ Maven pom.xml that can build your WAR for this case.
|
|||
</dependencies>
|
||||
</project>
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> JBoss AS 7 loads classes differently than previous versions. To work
|
||||
> properly in AS 7 the WAR will need this in its MANIFEST.MF:
|
||||
>
|
||||
> Dependencies: org.apache.activemq, org.jboss.netty
|
||||
>
|
||||
> You can add this to the`<plugins>` section of the pom.xml to create
|
||||
> this entry automatically:
|
||||
>
|
||||
> <plugin>
|
||||
> <groupId>org.apache.maven.plugins</groupId>
|
||||
> <artifactId>maven-war-plugin</artifactId>
|
||||
> <configuration>
|
||||
> <archive>
|
||||
> <manifestEntries>
|
||||
> <Dependencies>org.apache.activemq, org.jboss.netty</Dependencies>
|
||||
> </manifestEntries>
|
||||
> </archive>
|
||||
> </configuration>
|
||||
> </plugin>
|
||||
|
||||
It is worth noting that when deploying a WAR in a Java EE application
|
||||
server like AS7 the URL for the resulting application will include the
|
||||
name of the WAR by default. For example, if you've constructed a WAR as
|
||||
|
@ -169,11 +147,6 @@ described above named "activemq-rest.war" then clients will access it
|
|||
at, e.g. http://localhost:8080/activemq-rest/[queues|topics]. We'll see
|
||||
more about this later.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> It is possible to put the WAR file at the "root context" of AS7, but
|
||||
> that is beyond the scope of this documentation.
|
||||
|
||||
### Bootstrapping ActiveMQ Along with REST
|
||||
|
||||
You can bootstrap ActiveMQ within your WAR as well. To do this, you must
|
||||
|
|
|
@ -30,5 +30,5 @@ same property on the core message before sending.
|
|||
|
||||
## Example
|
||||
|
||||
See ? for an example which shows how scheduled messages can be used with
|
||||
See the [examples](examples.md) chapter for an example which shows how scheduled messages can be used with
|
||||
JMS.
|
||||
|
|
Loading…
Reference in New Issue