ActiveMQ中queues.jsp显示的队列信息

2019-03-18 23:34|来源: 网路



127.0.0.1:8161/admin/queues.jsp,显示的一些信息解析如下:


name是队列名称

Number Of Pending Messages  是队列中有多少个消息等待出队列

Number Of Consumers  是队列中有多少个消费者

Messages Enqueued  是队列共有多少个信息

Messages Dequeued  是队列中已经出列多少个消息


转自:http://mikzhang.iteye.com/blog/2228096


相关问答

更多
  • 对于无JMX的方法,您还可以使用由activemq控制台页面提供的XML提要。 XML源位于http://ip:port/admin/xml/queues.jsp 这将为每个队列使用类似于以下的标签: .... 只需在你的代码中解析这个XML,你就很好。 For a JMX-free approac ...
  • 有一个代理属性,org.apache.activemq.broker.BrokerService#cacheTempDestinations,这应该有助于在故障转移中:case。 在xml配置中设置为true,当客户端断开连接时,临时目标不会立即被删除。 快速故障转移:重新连接将能够再次从临时队列生成器和/或使用。 有一个基于timeBeforePurgeTempDestinations(默认5秒)处理高速缓存删除的计时器任务。 有一点值得注意的是,我没有看到在activemq-core中使用该属性的任何测 ...
  • 您可以使用Apache Camel轻松桥接代理。 Camel具有RabbitMQ和ActiveMQ的组件,允许您定义桥接要与之共享消息的目标的路由。 Camel网站有很多文档可以帮助您入门。 You can easily bridge brokers using Apache Camel. Camel has components for both RabbitMQ and ActiveMQ that would allow you to define a route that bridges the de ...
  • 您可以使用mapJmsMessage=false选项将映射从JMS转换为Camel Message。 然后设置jmsMessageType=Object这样当发送到队列时,Camel不会尝试猜测消息类型,而是按配置使用对象,然后按原样发送消息。 You can turn of mapping from JMS to Camel Message using the mapJmsMessage=false option. And then set jmsMessageType=Object so when se ...
  • 看来karaf shell并没有提供任何方式来监控Artemis队列。 我们可以做的就是在卡拉夫上安装 hawtio,然后监控Artemis队列。 It seems karaf shell does not provide any way to monitor Artemis queue. What we can do is install hawtio on karaf and then monitor Artemis queues.
  • 您可以利用较新的ActiveMQ Broker Camel组件拦截进入分析/诊断队列的消息并添加您的TTL值,或者您甚至可以拦截并仅在某些外部源告诉您已启用等时调度到该队列。是实现你正在做的事情的方法,但由于它有点超出正常经纪人操作的范围,你需要工作一点才能得到你想要的东西。 You could take advantage of the newer ActiveMQ Broker Camel component to intercept messages going to your analytic/di ...
  • 找到解决方案,BrokerName是错误的,右边是brokerName。 def query = new ObjectName('org.apache.activemq:brokerName=localhost,type=Broker,destinationType=Queue,destinationName=*') found the solution, BrokerName is wrong, right is brokerName. def query = new ObjectName('org.a ...
  • 我们通过调查ActiveMQ源代码来理解片段来解决这个问题: 首先是tx:89:10178611之后的候选人 结果是,89是日志文件名(db-89.log),10178611是文件中的偏移量。 所以,我们转储了日志文件: xxd -g1 db-89.log | less 然后我们对偏移量进行了文本搜索(转换为十六进制)。 在转储中,有一个人类可读的队列名称,其中包含挂起事务和来自它的服务器。 我无法访问有问题的服务器或代码,但管理员非正式地告诉我他们的开发人员“修复”了事务的结束,无论修复程序是什么。 这 ...
  • 当主站和从站都指向数据存储库的同一个文件夹时,这种安排称为“带有共享数据库的主从配置”,在这种情况下会出现以下情况 当您的主节点启动时,它会获得该数据库上的锁定并成功启动,因此您可以从UI访问此节点的详细信息。 但是当一个从节点启动时,它试图获得数据库的锁定,但由于它已被主节点锁定,它不能获得锁定并继续轮询数据库以进行锁定并不启动(这是预期的并且是正确的行为) 现在每当主节点发生故障时,它释放锁,并且这个锁由从节点获得(因为它连续轮询数据库),现在它获得锁并启动,由此在任何给定时间只有一个节点启动,并且如果 ...
  • 您可以像这样镜像单个队列: