ActiveMQ配置参考手册

ActiveMQ配置参考手册1ActiveMQ Server端配置

1.1 设置Broker名字

修改%activemq%/conf/activemq.xml文件

1.2设置persistenceAdapter

修改%activemq%/conf/activemq.xml文件

1.3 设置destinationPolicy

打开%activemq%/conf/activemq.xml文件，添加如下红色配置属性：

1.4设置networkConnectors

修改%activemq%/conf/activemq.xml文件

1.5 设置transportConnectors 修改%activemq%/conf/activemq.xml文件

2ActiveMQ Client端连接配置

目前Client端使用Failover协议组合TCP协议的方式连接broker，示例如下：

可以看到，tcp协议和failover协议分别支持一些不同的连接配置参数。如示例URL中的soTimeout和randomize。

下面就TCP协议和Failover协议的连接配置参数分别进行详细介绍。

2.1TCP连接参数配置

2.1.1The TCP Transport Options

2.1.2The OpenWire Wire Format Options

OpenWire is the default Wire Format that ActiveMQ uses. It provides a highly efficent binary format for high speed messaging. OpenWire options can be configured on a JMS client's

2.2Failover协议参数配置

The Failover configuration syntax allows you to specify any number of composite uris. The Failover transport randomly chooses one of the composite URI and attempts to establish a connection to it. If it does not succeed or if it subsequently fails, a new connection is established to one of the other uris in the list.

2.2.1The Failover Transport Options

Notes

If you use failover, and a broker dies at some point, your sends will block by default. Using TransportListener can help with this regard. It is best to set the Listener directly on the ActiveMQConnectionFactory so that it is in place before any request that may require an network hop.

Additionally you can use timeout option which will cause your current send to fail after specified timeout. The following URL, for example:

will cause send to fail after 3 seconds if the connection isn't established. The connection will not be killed, so you can try sending messages later at some point using the same connection (presumably some of your brokers will be available again). Timeouts on the failover transport are available since 5.3 version.

大意如下：

在使用failover协议时，如果broker发生僵死的情况，则在默认情况下消息生产者将会被阻塞。可以使用TransportListener或者在连接broker URL中增加timeout参数的方式来解决这个问题。若使用后者，则发送消息超过指定超时时间后，将会抛出一个JMS异常。但值得注意的是，该无效的连接并不会被“杀死”。

3ActiveMQ性能调优

3.1持久化(persistent)

Using persistent messaging is quite a bit slower than non-persistent messaging. Many things are a tradeoff in IT between performance and quality of service.

With non-persistent messaging, things are reliable - unless the broker is killed in which case any messages in the broker are lost. Persistent messaging avoids this by ensuring by default that every message is written to disk before the MessageProducer.send() method returns.

Even if you need persistent messaging there are various things you can do to speed things up - such as do you really need to block the sender to wait until the message is physically on disk on the broker before being able to send another message? There now follows a number of options you can consider if you need the extra safety of persistent messaging.

到底采取何种持久化方式，应取决于具体应用对性能（performance）和服务质量（QOS）这两个因素的要求。如果是性能要求较高的话则建议采用非持久化方式；如果对服务质量要求较高则建议采用持久化方式。

下表列出了目前可选的持久化方式（注：下表按消息发送&消费速度由高到低的顺序排列）：

从安全性和性能的综合角度考虑，我们建议选择KahaDB持久化方式。

3.2事务

If you are using persistent messaging and you don't want to use Async Sends then you should use JMS transactions to batch up many operations inside a single transaction. Even if you have to pay the performance cost of XA transactions - using batching (processing and sending many messages in a single transaction (JMS or XA) will boost performance considerably. This is because you share the synchrony cost (the waiting for things to be written and sync'd to disk) across many many messages.

3.3异步发送

If you enable Async Sends then you will reduce the blocking in senders which increases throughput.

采用异步发送是为了提高生产者发送消息的速度（在消息持久化的场合下可能会引起消息丢失），因此可以在生产能力不足时酌情使用。

注：默认情况下发送持久化消息是采取同步方式的，这样在broker将每一条消息进行持久化并向生产者返回应答(acknowledgement)之前，生产者的发送方法将会产生阻塞。如果采用异步发送，生产者将不再等待来自broker的应答，此时若broker一旦宕机，则无法保证每条已发送的消息都被写入持久化介质（如物理文件等）。

3.4增加prefetch大小

ActiveMQ will push as many messages to the consumer as fast as possible, where they will be queued for processing by an ActiveMQ Session. The maximum number of messages that ActiveMQ will push to a Consumer without the Consumer processing a message is set by the

pre-fetch size. You can improve throughput by running ActiveMQ with larger pre-fetch sizes. Pre-fetch sizes are determined by the ActiveMQPrefetchPolicy bean, which is set on the ActiveMQ ConnectionFactory.

ActiveMQ uses a prefetch size to determine how many messages are streamed to a JMS consumer. The higher this number then typically the higher the throughput of the consumers as it typically means under heavy message load then the consumer always has more messages available immediately in RAM for processing - rather than having to wait for messages to be read and parsed from a socket.

适用于消息消费速度较快的场合，采用更大的prefetch size以防止消费者进入等待状态。如果消息本身消费速度较慢，则应采取相反做法，否则一旦在消费端累积大量的消息，亦可能会影响消费者本身的性能。

3.5使用Session.DUPS_OK_ACKNOWLEDGE应答方式

For transient messages (non persistent) or where performance is more critical than QOS, use Session.DUPS_OK_ACKNOWLEDGE on message consumers. The message consumer can lazily acknowledge and batch receipt of messages to the broker - which will dramatically improve performance. However, if you use Session.DUPS_OK_ACKNOWLEDGE with durable topic or Queue consumers for persistent messages, duplicate messages can be received if a consumer terminates abnormally (is killed without closing).

对于瞬时消息（非持久化）或者性能要求超出服务质量的场合，消费者可以使用Session.DUPS_OK_ACKNOWLEDGE（重复应答）方式。消费者可以延迟应答并批量接收消息，这样可以在极大程度上提高性能。然而，如果在使用持久化消息的场合，这种应答方式可能会导致消费者接收到重复的消息。

3.6异步转发

This makes more sense since you want to do async message delivery to slower consumers, but do sync message delivery to faster consumers (to avoid the synchronization and context switching costs of adding another seda queue). The downside to using sync message delivery is that the producer is more likely to block if there is a slow consumer that he is dispatching messages to.(使

用同步消息转发的缺点：如果存在一个速度较慢的消费者，那么可能会引起该消息的生产者产生阻塞)

如何进行消息转发主要取决于消息消费者处理消息的速度：如果消费速度较快，则采用同步转发；如果消费速度较慢，则采用异步转发。

3.7其它选项

If you look at javadoc of ActiveMQConnection you will see a number of properties you can use.

For example if you enable the following flags

?optimizedAcknowledge

?optimizedMessageDispatch

?useAsyncSend

?asyncDispatch

You will generally make ActiveMQ go faster, acknowledge messages in batches and use asynchronous sending

You can set these properties on the Connection object using Java code or using the connection URI String such as for Async Sends.

3.8 开启消息压缩

If your application sends large messages and you know that your network is slow, it might be worthwhile to enable compression on your connections. When compression is enabled, the body of each JMS message (but not the headers) is compressed before it is sent across the wire. This results in smaller messages and better network performance. On the other hand, it has the disadvantage of being CPU intensive.

To enable compression, enable the useCompression option on the ActiveMQConnectionFactory class. For example, to initialize a JMS connection with compression enabled in a Java client, insert

Alternatively, you can enable compression by setting the https://www.360docs.net/doc/29790002.html,eCompression option on a producer URI—for example:

3.9 消息格式

JMS defines five message body types:

●StreamMessage

●MapMessage

●TextMessage

●ObjectMessage

●BytesMessage

Of these message types, BytesMessage (a stream of uninterpreted bytes) is the fastest, while ObjectMessage (serialization of a Java object) is the slowest.

为了获取更高的性能，建议尽可能使用BytesMessage消息编码格式。

4ActiveMQ异常问题及解决方法

4.1 连接broker超时等待解决办法

增加tcp协议的connectionTimeout配置，参见2.1.1章节The TCP Transport Options。

4.2Wire format negociation timeout

If you get exception like this:

javax.jms.JMSException: Wire format negociation timeout: peer did not send his wire format.

at

org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:58 )

at

org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.ja va:1185)

at

org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQCon

nection.java:1263)

at

org.apache.activemq.ActiveMQConnection.start(ActiveMQConnection.java:449)

it can mean one of three things:

1. You're connecting to the port not used by ActiveMQ TCP transport

Make sure to check that you're connecting to the appropriate host:port

2. You're using log4j JMS appender and doesn't filter out ActiveMQ log messages

Be sure to read How do I use log4j JMS appender with ActiveMQ and more importantly to never send ActiveMQ log messages to JMS appender

3. Your broker is probably under heavy load (or network connection is unreliable), so connection setup cannot be completed in a reasonable time

If you experience sporadic exceptions like this, the best solution is to use failover transport, so that your clients can try connecting again if the first attempt fails. If

you're getting these kind of exceptions more frequently you can also try extending wire format negotiation period (default 10 sec). You can do that by using wireFormat.maxInactivityDurationInitalDelay property on the connection URL in your client. For example:

tcp://localhost:61616?wireFormat.maxInactivityDurationInitalDelay=30000

will use 30 sec timeout.

4.3 Slow KahaDB access log messages

If database operation is slower than some threshold (default 500 ms), you will see messages like

Slow KahaDB access: cleanup took 1277 |

org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal Checkpoint Worker

You can configure a threshold used to log the message by using

-Dorg.apache.activemq.store.kahadb.LOG_SLOW_ACCESS_TIME=10000 system property and adjust it to your disk speed.