ActiveMQ 问题

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