activemq

We'd be interested to hear any experiences with the pros and cons of ActiveMQ vs RabbitMQ vs ZeroMQ. Information about any other interesting message queues is also welcome. Julien Edit: My initial answer had a strong focus on AMQP. I decided to rewrite it to offer a wider view on the topic. These 3 messaging technologies have different approaches on building distributed systems : RabbitMQ is one of the leading implementation of the AMQP protocol (along with Apache Qpid). Therefore, it implements a broker architecture, meaning that messages are queued on a central node before being sent to

Apache ActiveMQ任意文件写入漏洞（CVE-2016-3088）复现 一、漏洞描述 该漏洞出现在fileserver应用中,漏洞原理:ActiveMQ中的fileserver服务允许用户通过HTTP PUT方法上传文件到指定目录。Fileserver支持写入文件(不解析jsp),但是支持移动文件(Move)我们可以将jsp的文件PUT到Fileserver下,然后再通过Move指令移动到可执行目录下访问。 二、漏洞影响版本 Apache ActiveMQ 5.0.0 - 5.13.2 三、漏洞环境搭建 1、官网下载apache-activemq-5.7.0-bin.tar 下载地址:http://activemq.apache.org/download-archives.html 2、解压 3、启动,进入bin目录下,运行./activemq start 　　 4、浏览器访问http://192.168.10.149:8161/,如下图可以看到成功搭建环境 　　 四、漏洞复现 1、PUT上传一个jsp的webshell到fileserver目录,下图可以看到成功上传jsp文件 Jsp文件内容: <%@ page import="java.io.*"%> <% out.print("Hello</br>"); String strcmd=request

摘要 公司运维同事针对ActiveMQ提出了两个问题，其中一个是“队列长时间无人监听时，自动删除该队列”。 调研提出了三种方案。这里是相关记录和说明。 问题 运维同事对生产环境使用的ActiveMQ做了相关监控。这个监控在某个队列出现消息积压时（实际规则更复杂一些，并且正在调整）发送短信报警。运维接到短信后会通知开发负责人。开发负责人再检查系统是否在正常监听相关队列。 但是，从过往经验来看，只有一次消息积压是业务系统故障导致的；其它情况（没有统计到具体数据，大约五六次）都是业务系统已经不再监听该队列导致的。这使得我们的运维、开发同事半夜三更火急火燎检查问题，结果发现只需要删除那个队列就可以了。 尤其惹发起床气的是，由于线上ActiveMQ配置了消息持久化，这种消息积压其实并不会对ActiveMQ产生多大的影响，完全可以在第二天上班后再处理。 考虑到大家的睡眠质量和夫妻感情，在JIRA中，我们调研、讨论了三个方案。 方案一：ActiveMQ自带配置 在ActiveMQ官方提供的功能列表中，有这样一项功能：Delete Inactive Destination。它可以删除“没有未处理消息、并且没有消费者的Destination”。 配置示例 这个配置比较简单，在ActiveMQ的配置文件activemq.xml中，做如下改动即可。这里示例的是对queue的配置；topic配置是类似的。

netty的pipeline处理链上的handler：需要IdleStateHandler心跳检测channel是否可以，以及处理登录认证的UserAuthHandler和消息处理MessageHandler protected void initChannel(SocketChannel ch) throws Exception { ch.pipeline().addLast(defLoopGroup, //编码解码器 new HttpServerCodec(), //将多个消息转换成单一的消息对象 new HttpObjectAggregator(65536), //支持异步发送大的码流，一般用于发送文件流 new ChunkedWriteHandler(), //检测链路是否读空闲,配合心跳handler检测channel是否正常 new IdleStateHandler(60, 0, 0), //处理握手和认证 new UserAuthHandler(), //处理消息的发送 new MessageHandler() ); } 对于所有连进来的channel，我们需要保存起来，往后的群发消息需要依靠这些channel public static void addChannel(Channel channel) { String remoteAddr = NettyUtil

浅谈消息队列及常见的消息中间件 前言 消息队列 已经逐渐成为企业应用系统 内部通信 的核心手段。它具有 低耦合 、 可靠投递 、 广播 、 流量控制 、 最终一致性 等一系列功能。 当前使用较多的 消息队列 有 RabbitMQ 、 RocketMQ 、 ActiveMQ 、 Kafka 、 ZeroMQ 、 MetaMQ 等，而部分 数据库 如 Redis 、 MySQL 以及 phxsql 也可实现消息队列的功能。 正文 1. 消息队列概述 消息队列 是指利用 高效可靠 的 消息传递机制 进行与平台无关的 数据交流 ，并基于 数据通信 来进行分布式系统的集成。 通过提供 消息传递 和 消息排队 模型，它可以在 分布式环境 下提供 应用解耦 、 弹性伸缩 、 冗余存储 、 流量削峰 、 异步通信 、 数据同步 等等功能，其作为 分布式系统架构 中的一个重要组件，有着举足轻重的地位。 2. 消息队列的特点 2.1. 采用异步处理模式 消息发送者 可以发送一个消息而无须等待响应。 消息发送者 将消息发送到一条 虚拟的通道 （ 主题 或 队列 ）上， 消息接收者 则 订阅 或是 监听 该通道。一条信息可能最终转发给 一个或多个 消息接收者，这些接收者都无需对 消息发送者 做出 同步回应 。整个过程都是 异步的 。 2.2. 应用系统之间解耦合 主要体现在如下两点：