copyMessageOnSend TRUE Should a JMS message be copied to a new JMS Message object as part of the send() method in JMS. This is enabled by default to be compliant with the JMS specification. You can disable it if you do not mutate JMS messages after they are sent for a performance boost. Sets whether or not timestamps on messages should be disabled or not. If you disable them it adds a small performance boost. disableTimeStampsByDefault FALSE dispatchAsync nestedMapAndListEnabled objectMessageSerializationDefered Should the broker dispatch FALSE messages asynchronously to the consumer. Enables/disables whether or not Structured Message Properties and MapMessages are supported so that Message TRUE properties and MapMessage entries can contain nested Map and List objects. Available since version 4.1 onwards When an object is set on an ObjectMessage, the JMS spec requires the object to be serialized by that set method. Enabling this flag FALSE causes the object to not get serialized. The object may subsequently get serialized if the message needs to be sent over a socket or stored to disk. 第23页
optimizeAcknowledge FALSE optimizedMessageDispatch TRUE useAsyncSend FALSE useCompression FALSE useRetroactiveConsumer FALSE Enables an optimised acknowledgement mode where messages are acknowledged in batches rather than individually. Alternatively, you could use Session.DUPS_OK_ACKNOWLEDGE acknowledgement mode for the consumers which can often be faster. WARNING enabling this issue could cause some issues with auto-acknowledgement on reconnection If this flag is set then an larger prefetch limit is used - only applicable for durable topic subscribers Forces the use of Async Sends which adds a massive performance boost; but means that the send() method will return immediately whether the message has been sent or not which could lead to message loss. Enables the use of compression of the message bodies Sets whether or not retroactive consumers are enabled. Retroactive consumers allow non-durable topic subscribers to receive old messages that were published before the non-durable subscriber started. 2.6.9 消息重发与死信管理
DLQ-死信队列(Dead Letter Queue)用来保存处理失败或者过期的消息。 出现以下情况时,消息会被redelivered
A transacted session is used and rollback() is called.
第24页
A transacted session is closed before commit is called.
A session is using CLIENT_ACKNOWLEDGE and Session.recover() is called. 当一个消息被redelivered超过maximumRedeliveries(缺省为6次,具体设置请参考后面的链接)次数时,会给broker发送一个\,这个消息被认为是a poison pill,这时broker会将这个消息发送到DLQ,以便后续处理。
缺省的死信队列是ActiveMQ.DLQ,如果没有特别指定,死信都会被发送到这个队列。
缺省持久消息过期,会被送到DLQ,非持久消息不会送到DLQ 可以通过配置文件(activemq.xml)来调整死信发送策略。 1.不使用缺省的死信队列
缺省所有队列的死信消息都被发送到同一个缺省死信队列,不便于管理。可以通过individualDeadLetterStrategy或sharedDeadLetterStrategy策略来进行修改。如下:
' ,否则用队列名称 -->
第25页 queuePrefix=\ ... 2.非持久消息保存到死信队列 3.过期消息不保存到死信队列 2.6.10 生产者和消费者的密码使用 打开conf/activemq.xml文件,在 password=\ 第26页 注意必须在 第27页 百度搜索“77cn”或“免费范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读,免费范文网,提供经典小说综合文库ActiveMQ使用手册(6)在线全文阅读。
相关推荐: