producer的复用
一开始研究ActiveMQ的资料时，官网只说了connection和session最好复用，在我认识里，producer和consumer是由session创建出来的，session复用没问题，producer应该资源占用没那么大吧？
所以在一开始对项目组暴露的封装好的api接口中，client每发送一条消息，都会自动创建一个producer，随着发送消息的越来越多，在mq控制台上看到的生产者数量就越来越多，mq内存占用越来越大，从而导致mq的宕机。
最后的解决方法是在程序里复用producer，由于client需要持续往三个队列发送消息，因此使用了hashmap来存放建好的producer，map里键是目的地，值则是MessageProducer对象。
每次发送消息时，需要检查是否producer可用，主要是检查会话是否正常。
failover机制的问题
在项目上线后，需求方要求Agent可以在故障时自动切换到另一个MQ集群以实现容错，且在原集群正常后可以自动切换回来。
这个需求直觉上就是ActiveMQ的failover机制，只需要在建立连接时把randomize设置为false，然后加个priorityBackup=true，failover中配置上两个MQ集群的F5就OK，实际上我们也是这么做的。
上线后才发现了一个问题，只要有一点网络抖动，或者因为inactivityMonitor导致的连接断开，那么Agent就会自动连接到另一个集群，而后再尝试连接回来。也就是说，不会尝试多次第一个地址，而是直接尝试第二个可用的地址，就算将配置写成
ip1,ip1,ip2
的形式也不行。因为源码中在识别uri添加uri到重连列表时有一个去重的机制，在FailoverTransport中：
public void add(boolean rebalance, URI u[]) {
boolean newURI = false;
for (URI uri : u) {
if (!contains(uri)) {
uris.add(uri);
newURI = true;
}
}
if (newURI) {
reconnect(rebalance);
}
}
由于我们使用的是MQ上自带的系统消息来判断Agent是否在线，这样就会出现两个集群的ActiveMQ都会上送一条agent连接到该集群的提示，如果离线消息处理不及时，上层就会出现一个agent连接两个mq的情况。
实际解决方法还没有想到，目前想到的就是先把InactivityMonitor给关了，再看看效果吧
Channel was inactive for too long
这个问题出现在使用了上述的failover机制后，由于InactivityMonitor机制，一般情况下如果没有数据包，那么MQ和Agent会互相发送keepAlive Info数据包，是不会出现问题的。但是在MQ负载较高的情况下，会出现无法发送KeepAlive Info的问题（推测），因此InactivityMonitor就会断开连接，而后自动重连到另一个集群再连接回来。
在这种情况下，考虑两种方案
1.彻底关闭该功能
2.延长检测时间，比如10分钟内没数据交互才关闭。
目前暂定方案2具体测试情况待上线后检验
无限重连导致连接暴增
在测试环境上发现一个场景，agent不停发起对mq的重连，但是连接未被关闭，一段时间后，火墙就被这些连接占满了。
现在初步判断原因是mq被连接撑爆，导致mq不停关闭连接，agent又不停尝试重连，具体需要再进行测试。
这个问题的解决方法有两种
1.增加mq集群数量，限制每台mq的连接数
2.放弃failover机制，而是改用自己写的逻辑来进行重连。
具体解决方法待确定，后续更新
KahaDB无法及时清理db-*.log
问题原因已经找到，是ActiveMQ的一个bug：
ActiveMQ使用KahaDB进行消息的持久化存储，在KahaDB的db-.log文件中，存放的是消息和消息被消费者接收的ack数据（messages and acknowledgement），只有一个db-.log文件中所有的消息都被消费（都存在ack）后，这个db-*.log才会被清理。
那么现在存在一种情况，如果MQ上堆积了一条消息，许久没被消费。那么这条消息所在的db-1.log就不会被清理，也就是说db-1.log中所有其他已经被消费的消息也都不会被清理。如果db-2.log,db-3.log中存在db-1.log中的已经被消费的消息的ack数据，这个ack数据也是不能被清理的。原因是如果清理了ack数据，那么在MQ宕机重启后，db-1.log中的被消费的消息又会被置为未消费。因此就会产生一个连锁反应，只要有一条消息卡在MQ上，就可能后续的数据文件均无法被删除。当然连锁反应也有可能在某个环节被打破，比如某个文件刚好包含了自己所有消息的ack和上一个文件的消息的ack数据，但是如果一直连锁下去，文件系统的确是会被撑爆。
在测试环境已重现这个问题
这个bug在ActiveMQ-5.14.0版本中被解决，解决方法是把第一个数据文件中消息的ack给迁移到某个数据文件中。我也在测试环境搭了5.14.1版本的ActiveMQ进行了测试。
可惜我们用的版本是ActiveMQ-5.11.1……………………
解决方法是：
1、尽量减少MQ上的消息堆积的情况，比如设置消息的超时时间，定时清理等。如果堆积了要及时处理，不能让MQ上长期堆积相同的消息。
2、减小db-*.log的文件大小，理论上可以使脏数据的影响范围降低
3、设置KahaDB多实例，让队列之间的数据文件互不干扰。
设置方法
亲测，在分别对两个队列设置KahaDB多实例后，生产者生产持久化消息的TPS提升了
4、升级MQ
MQ服务器上出现大量CLOSE_WAIT连接
CLOSE_WAIT表示一个连接被被动关闭了，服务器没有检测到，因此程序忽略了继续进行连接的关闭。最麻烦的是CLOSE_WAIT的连接会占用amq的总连接数，因此如果要清理，只能重启mq来解决。
有一篇文章对TIME_WAIT和CLOSE_WAIT解释得很详细。
http://www.cnblogs.com/sunxucool/p/3449068.html
出现这个问题后，可能直接导致activemq报出timer already cancelled，连接超限，无法建立线程OOM等报错。（推测）
该问题在JIRA上已经被关闭，见AMQ-5543和AMQ-5251。
经过一段时间的研究，发现是我的代码触发了MQ 的一个bug代码中建立了过多的JMX连接，导致服务器无法建立新的线程，从而导致连接无法被正常处理，而后连接被客户端关闭，就出现了close_wait。
这个bug连接的是InactivityMonitor中建立ReadChecker和WriteCheck的bug，出现问题时会导致MQ上报出大量的Timer Already Cancelled报错，因为无法建立新的checker线程了，但是代码中仍然进行了checker的Timer类的配置，所以抛出了timer already cancelled的异常。在AMQ 5.13及以后的版本已修复该问题。
