实战activeMQ

1.JMS介绍
    JMS源于企业应用对于消息中间件的需求，使应用程序可以通过消息进行异步处理而互不影响。Sun公司和它的合作伙伴设计的JMS API定义了一组公共的应用程序接口和相应语法，使得Java程序能够和其他消息组件进行通信。JMS有四个组成部分：JMS服务提供者、消息管理对象、消息的生产者消费者和消息本身。
1)JMS服务提供者实现消息队列和通知，同时实现消息管理的API。JMS已经是J2EE API的一部分，J2EE服务器都提供JMS服务。
2) 消息管理对象提供对消息进行操作的API。JMS API中有两个消息管理对象：创建jms连接使用的工厂（ConnectionFactory）和目的地（Destination），根据消息的消费方式的不同ConnectionFactory可以分为QueueConnectionFactory和TopicConnectionFactory，目的地（Destination）可以分为队列（Queue）和主题（Topic）两种。
3)消息的生产者和消费者。消息的产生由JMS的客户端完成，JMS服务提供者负责管理这些消息，消息的消费者可以接收消息。消息的生产者可以分为――点对点消息发布者（P2P）和主题消息发布者（TopicPublisher）。所以，消息的消费者分为两类：主题消息的订阅者（TopicSubscriber)和点对点消息的接收者（queue receiver）
4)消息。消息是服务提供者和客户端之间传递信息所使用的信息单元。JMS消息由以下三部分组成：
　　消息头（header）――JMS消息头包含了许多字段，它们是消息发送后由JMS提供者或消息发送者产生，用来表示消息、设置优先权和失效时间等等，并且为消息确定路由。
　　属性（property）――用来添加删除消息头以外的附加信息。
　　消息体（body）――JMS中定义了5种消息体：ByteMessage、MapMessage、ObjectMessage、StreamMessage和TextMessage。

2.Messages 通信方式
上面提到JMS通信方式分为点对点通信和发布/订阅方式
1)点对点方式（point-to-point）
   点对点的消息发送方式主要建立在 Message Queue,Sender,reciever上，Message Queue 存贮消息，Sneder 发送消息，receive接收消息.具体点就是Sender Client发送Message Queue ,而 receiver Cliernt从Queue中接收消息和"发送消息已接受"到Quere,确认消息接收。消息发送客户端与接收客户端没有时间上的依赖，发送客户端可以在任何时刻发送信息到Queue，而不需要知道接收客户端是不是在运行
2)发布/订阅 方式（publish/subscriber Messaging）
    发布/订阅方式用于多接收客户端的方式.作为发布订阅的方式，可能存在多个接收客户端，并且接收端客户端与发送客户端存在时间上的依赖。一个接收端只能接收他创建以后发送客户端发送的信息。作为subscriber ,在接收消息时有两种方法，destination的receive方法，和实现message listener 接口的onMessage 方法。

3.为什么选用ActiveMQ
   1）ActiveMQ是一个开放源码
   2）基于Apache 2.0 licenced 发布并实现了JMS 1.1。
   3）ActiveMQ现在已经和作为很多项目的异步消息通信核心了
   4）在很多中小型项目中采用ActiveMQ+SPRING+TOMCAT开发模式。

4.编程模式
4.1消息产生者向JMS发送消息的步骤
(1)创建连接使用的工厂类JMS ConnectionFactory
(2)使用管理对象JMS ConnectionFactory建立连接Connection
(3)使用连接Connection 建立会话Session
(4)使用会话Session和管理对象Destination创建消息生产者MessageSender
(5)使用消息生产者MessageSender发送消息
4.2消息消费者从JMS接受消息的步骤
(1)创建连接使用的工厂类JMS ConnectionFactory
(2)使用管理对象JMS ConnectionFactory建立连接Connection
(3)使用连接Connection 建立会话Session
(4)使用会话Session和管理对象Destination创建消息消费者MessageReceiver
(5)使用消息消费者MessageReceiver接受消息，需要用setMessageListener将MessageListener接口绑定到MessageReceiver
消息消费者必须实现了MessageListener接口，需要定义onMessage事件方法。

5.ActiveMQ运行
ActiveMQ5.0版本默认启动时，启动了内置的jetty服务器，提供一个demo应用和用于监控ActiveMQ的admin应用。运行%activemq_home%bin/目录下的 activemq.bat , 之后你会看见如下一段话表示启动成功。
打开http://localhost:8161/admin/queues.jsp ，可以查看相应的queue中是否有消息


6.SendMessage(用于发送消息)

import javax.jms.Connection;
import javax.jms.Destination;
import javax.jms.JMSException;
import javax.jms.MessageProducer;
import javax.jms.Session;
import javax.jms.TextMessage;
import org.apache.activemq.ActiveMQConnectionFactory;

public class SendMessage {
 private static final String url ="tcp://localhost:61616";
 private static final String QUEUE_NAME ="choice.queue";
 protected String expectedBody = "<hello>world!</hello>";
 public void sendMessage() throws JMSException{
  Connection connection =null;
  try{
   ActiveMQConnectionFactory connectionFactory =new ActiveMQConnectionFactory(url);
   connection = (Connection)connectionFactory.createConnection();
   connection.start();
   Session session = (Session)connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
   Destination destination = session.createQueue(QUEUE_NAME);
   MessageProducer producer = session.createProducer(destination);
   TextMessage message = session.createTextMessage(expectedBody);
   message.setStringProperty("headname", "remoteB");
   producer.send(message);    
  }catch(Exception e){
   e.printStackTrace();
  }
 }
 
 public static void main(String[] args){
  SendMessage sndMsg = new SendMessage();
  try{
   sndMsg.sendMessage();
  }catch(Exception ex){
   System.out.println(ex.toString());
  }
 }
}

7.ReceiveMessage(用于接收消息)

import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import javax.jms.BytesMessage;
import javax.jms.Connection;
import javax.jms.Destination;
import javax.jms.JMSException;
import javax.jms.Message;
import javax.jms.MessageConsumer;
import javax.jms.Session;
import javax.jms.TextMessage;
import org.apache.activemq.ActiveMQConnectionFactory;

public class ReceiveMessage {
 private static final String url = "tcp://localhost:61616";
 private static final String QUEUE_NAME = "choice.queue";
 public void receiveMessage() {
  Connection connection = null;
  try {
   try {
    ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(url);
    connection = connectionFactory.createConnection();
   } catch (Exception e) {
                System.out.println(e.toString());
   }
   connection.start();
   Session session = connection.createSession(false,
     Session.AUTO_ACKNOWLEDGE);
   Destination destination = session.createQueue(QUEUE_NAME);
   MessageConsumer consumer = session.createConsumer(destination);
   consumeMessagesAndClose(connection, session, consumer);
  } catch (Exception e) {
    System.out.println(e.toString());
  }
 }

 protected void consumeMessagesAndClose(Connection connection,Session session, MessageConsumer consumer)
 throws JMSException {
  for (int i = 0; i < 1;) {
   Message message = consumer.receive(1000);
   if (message != null) {
    i++;
    onMessage(message);
   }
  }
  System.out.println("Closing connection");
  consumer.close();
  session.close();
  connection.close();
 }

 public void onMessage(Message message) {
  try {
   if (message instanceof TextMessage) {
    TextMessage txtMsg = (TextMessage) message;
    String msg = txtMsg.getText();
    System.out.println("Received: " + msg);
   }
  } catch (Exception e) {
   e.printStackTrace();
  }

 }

 public static void main(String args[]) {
  ReceiveMessage rm = new ReceiveMessage();
  rm.receiveMessage();
 }

}

文章欢迎转载，但请注明出处和作者

好样的, 我也在做大压力测试, 不过, 有个很严重的问题, 就是如果是有比较多的消息没有被消费<比如10万条>, 使用本地存储的话. 这个时候SHUTDOWN MQ, 起来的恢复时间非常难以忍受, 肯定在10分钟以上, 5.2版本也有这个问题. 不知道怎么修改.有个参数修改了也不成.

呵呵，最近也关注

这么大消息量，有没有丢失消息的情况发生？ 如果有，最好能说一下丢失率。

你能  SHUTDOWN MQ 已经算是不错了,这种情况 就不应该设置这么高的深度.我觉得网络的东西还是需要很强劲的水位保护.

请问一下楼主，有对activeMQ做性能测试吗？我对这方面比较关注。有空可以讨论一下。

是啊，有对activeMQ做性能测试吗？用什么工具做的性能测试？

IBM MQ不错的说

因为毕业论文是关于jms和消息中间件方面的，所以最近一直在看相关方面的书和论文，但是仍有一些疑问，从一开始到现在一直都没解决，并且都是一些很基本的问题，如果这些根本问题不解决，我想在大方向上可能就会出现偏差，这将会是很危险的，所以，我就希望各位能帮忙解开我的这些疑问，谢谢！

    1、在看sun公司提供的关于jms的手册时，它说："Since messaging is peer-to-peer, all users of JMS are referred to generically as clients." 疑问:既然是"点对点"的，那么，就应该不会分客户端和服务器端了，是不是就意味着每个通信端都是客户端和服务器的合成体？

    2、 接着上面的那个疑问，通信端之间是通过什么方式(或说协议)进行通信的呢？在看的那些论文中只是提到的客户端和服务器端之间的通信方式，很多说是通过RMI和JNDI来通信的，但是如果就像第一个疑问中的那个问题，我想真正关心的应该是通信端点之间的通信而不应该是客户端和服务器端之间的通信方式吧？

    3、 消息中间件的应用背景是在分布式环境下的异步通信(当然也可以实现同步通信的)，疑问是，在实际中通信的消息都有什么内容呢？

现在在互联网中构建的并发量比较大的网站，很少是用java写的，好像潜在，人们在构建基于互联网络的应用中已经因为处理并发能力这个因素将java淘汰出局了，但是，很多事实证明，优秀的实践能弥补语言的先天不足，仿佛很多人在用jetty、jms、apache、memcache、mysql(derby\hsqdb)等这些技术的巧妙组合也能实现百万级并发能力，当然，主流的框架是使用不了了。
其中我对jms的理解一直是“提升系统响应能力”的工具，而非“为了实现某些功能而不得不引入”，因为可以这样说“凡是jms能实现的，rpc一样能实现”，接下来的几个话题我比较感兴趣，也是很像听听大家意见的：

1、在一个使用mq的系统中，消息的生产者和消息的消费者是不是一定在不同的主机和不同的进程里面？是不是说消息的生产者和消费者在同一台主机的同一个进程里面，这种设计压根就不应该用jms，这样设计就是荒谬的？

2、从你拿到需求那天开始，如果你有全权决定技术框架的权利，那么如果你最终选定了jms实现其中的某部分，是什么驱动着你做出这个决定？是需求中某部分不用jms就实现不了？是非功能需求中出于对性能的考虑？还是因为出于对遗留系统的集成？

这两个问题对于我来说很重要，因为我不想发生这种事情：虽然对jms相关开发了若指掌，但是现有系统使用jms除了增加复杂性以外没起到什么作用，就算去掉jms效果也差不多。