1. 云栖社区>
  2. >
  3. 正文

ActiveMQ 问题

作者:用户 来源:互联网 时间:2018-09-01 10:12:28

问题activemq中间件

ActiveMQ 问题 - 摘要: 本文讲的是ActiveMQ 问题, 1.如何在activemq.xml里面配置消息队列的大小,来保证队列不会溢出。 如果采用非持久化消息,那么当大量发送消息时,首先大量占用内存,造成消息堆积,容易造成内存溢出; 消息类型建议使用持久化消息的同时

1.如何在activemq.xml里面配置消息队列的大小,来保证队列不会溢出。
如果采用非持久化消息,那么当大量发送消息时,首先大量占用内存,造成消息堆积,容易造成内存溢出;
消息类型建议使用持久化消息的同时配合其他方式的master/slave或者failover机制,尽量保持消息的畅通。

2.ActiveMQ的另一个问题就是只要是软件就有可能挂掉,挂掉不可怕,怕的是挂掉之后把信息给丢了;
ActiveMQ消息持久化有三种方式:AMQ、KahaDB、JDBC;默认支持KahaDB;
在broker中设置属性persistent=”true”(默认是true),同时发送的消息也应该是persitent类型的;

3.kahaDB,是一个基于文件支持事务的消息存储器,是一个可靠,高性能,可扩展的消息存储器。
他的设计初衷就是使用简单并尽可能的快。KahaDB的索引使用一个transaction log,并且所有的destination只使用一个index,
有人测试表明:如果用于生产环境,支持1万个active connection,每个connection有一个独立的queue。该表现已经足矣应付大部分的需求。

4.当对消息处理性能要求很高或者当前环境配置处于内外网环境时,就需要配置多个ActiveMQ服务器来搭建集群环境。

5.transport Connection to :tp://* failed:java.net.SocketException:Connection reset
应用日志和ActiveMQ中可能经常会看到上述异常信息;
这是因为activemq 客户端停掉,或者网络中断导致MQ 连接异常中断的时候就会打出如上日志,当网络恢复后会自动连接,不会影响系统正常运行。

6.持久化策略使用KahaDB时,有可能会发现 data/kahadb 下的db.data文件或db-*.log文件大小异常,比如达到几G或几十G大小,这是不正常的。
因为这个目录里的文件保存的是当前未处理的消息,db.data是btree 索引文件,db-*.log是消息信息文件,消息被处理完成后db-*.log文件会被自动清理删除,db-*.log文件的序号会自动上升。
如果发现db.data文件太大,可能是历史某一时刻未被处理的消息过多;

7.Could not accept connection :org.apache.activemq.transport.tcp.ExceededMaximumConnectionsException:Exceeded the maximum number of allowed client connections. See the 'maximumConnections' property on the TCP transport configuration URI in the ActiveMQ configuration file (e.g., activemq.xml)

如果ActiveMQ配置正常,但服务连接不上,并且日志中出现以上异常信息;可以判断是因为连接数超上限造成的连接拒绝,ActiveMQ默认的连接数上限时1000.


8.如果发现消费者分配不公平,一个消费者忙死,另外的消费者闲死了;由于activemq有一定机制将队列中的数据交给consumer处理,这个机制就是数据的prefetch预取机制,默认是1000,把这个值调小就可以了,在客户端的连接url中,修改为tcp://ipaddr:61616?jms.prefetchPolicy.all=2  



以上是云栖社区小编为您精心准备的的内容,在云栖社区的博客、问答、公众号、人物、课程等栏目也有的相关内容,欢迎继续使用右上角搜索按钮进行搜索问题 , activemq 中间件 ,以便于您获取更多的相关知识。