前阵子对Spring Jms实现进行了一些扩展,借此机会系统化地研究了一下Spring对JMS的支持,整理成文,希望大家能够喜欢!
本文打算从两个维度(编程API和包结构)进行阐述,希望大家读完,能对Spring在JMS层面上做的事情有一个大致了解。当然喜欢扣细节的朋友,也欢迎提出你的疑惑!
第一部分:编程API
首先,让我们来看下Spring中我们最最经常用到的JmsTemplate,上图
从继承关系上,我们先来看下接口 JmsOperations,基本上可以归纳出这几类方法:
Conveniencemethods for sending messages
Conveniencemethods for sending auto-converted messages
Conveniencemethods for receiving messages
Conveniencemethods for receiving auto-converted messages
Conveniencemethods for browsing messages
充分遵循了CQRS原则。一个MQ其实就是Wrapper后的Queue,数据结构的知识告诉我们,queue有两种存储结构:Array and LinkedList。Array擅长随机读取,LinkedList则擅长删除更新操作,一旦底层采用 了LinkedList结构,Brower就是个大问题,这个要格外注意一下。
再来看下JmsDestinationAccessor,该类继承自JmsAccessor(该类实现了InitializingBean,不解释),注意里面的DestinationResolver类,主要是从简单的String类型的名字解析成具体的Destination,其默认的实现DynamicDestinationResolver基本上已经够用了。举个例子,倘若你要扩展将其解析成zookeeper可识别的Location,可以考虑实现该类。
好,终于轮到JmsTemplate了,先贴一段Javadoc(这里面有两个地方需要先了解下)
This template uses a org.springframework.jms.support.destination.DynamicDestinationResolver and a SimpleMessageConverter as default strategies for resolving a destination name or converting a message, respectively. These defaults can be overridden through the "destinationResolver" and "messageConverter" bean properties.
直白,不解释了。。。。。。
NOTE: The ConnectionFactory used with this template should return pooled Connections (or a single shared Connection) as well as pooled Sessions and MessageProducers. Otherwise, performance of ad-hoc JMS operations is going to suffer.
ok,下面我们深入JmsTemplate,了解其中几个重要的方法:
/**
* Execute the action specified by the given action object within a
* JMS Session. Generalized version of {@code execute(SessionCallback)},
* allowing the JMS Connection to be started on the fly.
* <p>Use {@code execute(SessionCallback)} for the general case.
* Starting the JMS Connection is just necessary for receiving messages,
* which is preferably achieved through the {@code receive} methods.
* @param action callback object that exposes the Session
* @param startConnection whether to start the Connection
* @return the result object from working with the Session
* @throws JmsException if there is any problem
* @see #execute(SessionCallback)
* @see #receive
*/
public <T> T execute(SessionCallback<T> action, boolean startConnection) throws JmsException {
Assert.notNull(action, "Callback object must not be null");
Connection conToClose = null;
Session sessionToClose = null;
try {
//通过事务同步管理器获取与当前线程绑定的Resouce,这里是JmsResourceHolder
Session sessionToUse = ConnectionFactoryUtils.doGetTransactionalSession(
getConnectionFactory(), this.transactionalResourceFactory, startConnection);
if (sessionToUse == null) {
conToClose = createConnection();
sessionToClose = createSession(conToClose);
if (startConnection) {
conToClose.start();
}
sessionToUse = sessionToClose;
}
if (logger.isDebugEnabled()) {
logger.debug("Executing callback on JMS Session: " + sessionToUse);
}
return action.doInJms(sessionToUse);
}
catch (JMSException ex) {
//注意这里的妙处 - 异常转译
throw convertJmsAccessException(ex);
}
finally {
JmsUtils.closeSession(sessionToClose);
ConnectionFactoryUtils.releaseConnection(conToClose, getConnectionFactory(), startConnection);
}
}
/**
* Send the given JMS message.
* @param session the JMS Session to operate on
* @param destination the JMS Destination to send to
* @param messageCreator callback to create a JMS Message
* @throws JMSException if thrown by JMS API methods
*/
protected void doSend(Session session, Destination destination, MessageCreator messageCreator)
throws JMSException {
Assert.notNull(messageCreator, "MessageCreator must not be null");
MessageProducer producer = createProducer(session, destination);
try {
Message message = messageCreator.createMessage(session);
if (logger.isDebugEnabled()) {
logger.debug("Sending created message: " + message);
}
doSend(producer, message);
// Check commit - avoid commit call within a JTA transaction.
if (session.getTransacted() && isSessionLocallyTransacted(session)) {
// Transacted session created by this template -> commit.
JmsUtils.commitIfNecessary(session);
}
}
finally {
JmsUtils.closeMessageProducer(producer);
}
}
public void convertAndSend(
Destination destination, final Object message, final MessagePostProcessor postProcessor)
throws JmsException {
send(destination, new MessageCreator() {
public Message createMessage(Session session) throws JMSException {
Message msg = getRequiredMessageConverter().toMessage(message, session);
return postProcessor.postProcessMessage(msg);//注意这里不是对消息发送的后置处理,而是对消息Converter的后置处理(消息发送前的一个Hook)
}
});
}
/**
* Actually receive a JMS message.
* @param session the JMS Session to operate on
* @param consumer the JMS MessageConsumer to receive with
* @return the JMS Message received, or {@code null} if none
* @throws JMSException if thrown by JMS API methods
*/
protected Message doReceive(Session session, MessageConsumer consumer) throws JMSException {
try {
// Use transaction timeout (if available).
long timeout = getReceiveTimeout();
JmsResourceHolder resourceHolder =
(JmsResourceHolder) TransactionSynchronizationManager.getResource(getConnectionFactory());
if (resourceHolder != null && resourceHolder.hasTimeout()) {
timeout = Math.min(timeout, resourceHolder.getTimeToLiveInMillis());
}
Message message = doReceive(consumer, timeout);
if (session.getTransacted()) {
// Commit necessary - but avoid commit call within a JTA transaction.
if (isSessionLocallyTransacted(session)) {
// Transacted session created by this template -> commit.
JmsUtils.commitIfNecessary(session);
}
}
else if (isClientAcknowledge(session)) {
// Manually acknowledge message, if any.
if (message != null) {
message.acknowledge();
}
}
return message;
}
finally {
JmsUtils.closeMessageConsumer(consumer);
}
}
关键代码处已经有注释了,这里就不再赘述了,掌握了这几个核心方法,这个类就算拿下了。
恩,从编程API的角度来看,差不多就这些内容了。
第二部分:包结构
下面,我们从包结构的角度再来进一步了解一下Spring对Jms的集成,如下图:
org.springframework.jms包里面提供了一些JMS规范异常的runtime版本,看看jms2在这方面的改进,就知道spring在这方面已然是先驱了。
org.springframework.jms.config包里面放置了对Jms schema的解析,这是spring为我们提供的一个非常有用的特性,schema用的好的话,也可以做到面向接口编程,扩展性极好。这方面感兴趣的同学,推荐阅读这里http://openwebx.org/docs/Webx3_Guide_Book.html#d0e574,深入了解下Webx是怎么利用Schema实现OCP原则的。
org.springframework.jms.connection包里面放置了一些与Connection相关的工具类(ConnectionFactoryUtils),基础类(JmsResourceHolder等)。这里重点关注一下JmsTransactionManager(extendsAbstractPlatformTransactionManager,其中的doXXX方法非常有看点),这个类也是JMS本地事务处理的一个核心工作类,如下:
org.springframework.jms.core包里面主要是spring封装的一些回调接口,如BrowserCallback,MessageCreator,MessagePostProcessor,ProducerCallback,SessionCallback,当然我们之前分析过的JmsTemplate也在这个包里面。
org.springframework.jms.core.support包里面就一个抽象类JmsGatewaySupport,暂时没怎么用,就是在afterPropertiesSet方法里面内置了一个initGateway方法,用来做一些定制化操作(custominitialization behavior)。
org.springframework.jms.listener和org.springframework.jms.listener.adapter包,我们要重点关注一下,刚才编程式API主要介绍了消息的发送,消息的接受是怎么处理的呢,主要看这两个包里面的类。类图如下:
我们先来了解下SimpleMessageListenerContainer的核心方法:
/**
* Create a MessageConsumer for the given JMS Session,
* registering a MessageListener for the specified listener.
* @param session the JMS Session to work on
* @return the MessageConsumer
* @throws JMSException if thrown by JMS methods
* @see #executeListener
*/
protected MessageConsumer createListenerConsumer(final Session session) throws JMSException {
Destination destination = getDestination();
if (destination == null) {
destination = resolveDestinationName(session, getDestinationName());
}
MessageConsumer consumer = createConsumer(session, destination);
if (this.taskExecutor != null) {
consumer.setMessageListener(new MessageListener() {
public void onMessage(final Message message) {
taskExecutor.execute(new Runnable() {
public void run() {
processMessage(message, session);
}
});
}
});
}
else {
consumer.setMessageListener(new MessageListener() {
public void onMessage(Message message) {
processMessage(message, session);
}
});
}
return consumer;
}
怎么样,很简单吧?非常简单的调度算法,也没有失败重连等高级功能。如果需要这些功能,怎么办?ok,是时候DefaultMessageListenerContainer出场了,
一个功能相对比较丰富的
Listener
容器,和
SimpleMessageListenerContainer
不同,它使用
AsyncMessageListenerInvoker
执行一个
looped
的
MessageConsumer.receive()
调用来接收消息,注意这里的
Executor
,默认是
SimpleAsyncTaskExecutor
,文档里写的很清楚:
NOTE: This implementation does not reuse threads! Consider a thread-pooling TaskExecutor implementation instead, in particular for executing a large number of short-lived tasks.
来看看这个类里面几个重要的成员变量,首先是
concurrentConsumers和
maxConcurrentConsumers。
通过设置
setConcurrency
方法,可以
scale up number of consumers between the minimum number ofconsumers
(
concurrentConsumers
)
and the maximum number of consumers(maxConcurrentConsumers)。那么
单个消费任务如何消费消息呢,这里又有一个变量需要注意一下,即
idleTaskExecutionLimit
,官方的解释很清楚了:
Within each task execution, a number of message reception attempts (according to the "maxMessagesPerTask" setting) will each wait for an incoming message (according to the "receiveTimeout" setting). If all of those receive attempts in a given task return without a message, the task is considered idle with respect to received messages. Such a task may still be rescheduled; however, once it reached the specified "idleTaskExecutionLimit", it will shut down (in case of dynamic scaling).
接下来,我们来看这个类里面最最重要的调度方法,在其内部类AsyncMessageListenerInvoker里面,如下:
public void run() {
synchronized (lifecycleMonitor) {
activeInvokerCount++;
lifecycleMonitor.notifyAll();
}
boolean messageReceived = false;
try {
if (maxMessagesPerTask < 0) {
messageReceived = executeOngoingLoop();
}
else {
int messageCount = 0;
while (isRunning() && messageCount < maxMessagesPerTask) {
messageReceived = (invokeListener() || messageReceived);
messageCount++;
}
}
}
catch (Throwable ex) {
clearResources();
if (!this.lastMessageSucceeded) {
// We failed more than once in a row - sleep for recovery interval
// even before first recovery attempt.
sleepInbetweenRecoveryAttempts();
}
this.lastMessageSucceeded = false;
boolean alreadyRecovered = false;
synchronized (recoveryMonitor) {
if (this.lastRecoveryMarker == currentRecoveryMarker) {
handleListenerSetupFailure(ex, false);
recoverAfterListenerSetupFailure();
currentRecoveryMarker = new Object();
}
else {
alreadyRecovered = true;
}
}
if (alreadyRecovered) {
handleListenerSetupFailure(ex, true);
}
}
finally {
synchronized (lifecycleMonitor) {
decreaseActiveInvokerCount();
lifecycleMonitor.notifyAll();
}
if (!messageReceived) {
this.idleTaskExecutionCount++;
}
else {
this.idleTaskExecutionCount = 0;
}
synchronized (lifecycleMonitor) {
if (!shouldRescheduleInvoker(this.idleTaskExecutionCount) || !rescheduleTaskIfNecessary(this)) {
// We're shutting down completely.
scheduledInvokers.remove(this);
if (logger.isDebugEnabled()) {
logger.debug("Lowered scheduled invoker count: " + scheduledInvokers.size());
}
lifecycleMonitor.notifyAll();
clearResources();
}
else if (isRunning()) {
int nonPausedConsumers = getScheduledConsumerCount() - getPausedTaskCount();
if (nonPausedConsumers < 1) {
logger.error("All scheduled consumers have been paused, probably due to tasks having been rejected. " +
"Check your thread pool configuration! Manual recovery necessary through a start() call.");
}
else if (nonPausedConsumers < getConcurrentConsumers()) {
logger.warn("Number of scheduled consumers has dropped below concurrentConsumers limit, probably " +
"due to tasks having been rejected. Check your thread pool configuration! Automatic recovery " +
"to be triggered by remaining consumers.");
}
}
}
}
}
private boolean executeOngoingLoop() throws JMSException {
boolean messageReceived = false;
boolean active = true;
while (active) {
synchronized (lifecycleMonitor) {
boolean interrupted = false;
boolean wasWaiting = false;
while ((active = isActive()) && !isRunning()) {
if (interrupted) {
throw new IllegalStateException("Thread was interrupted while waiting for " +
"a restart of the listener container, but container is still stopped");
}
if (!wasWaiting) {
decreaseActiveInvokerCount();
}
wasWaiting = true;
try {
lifecycleMonitor.wait();
}
catch (InterruptedException ex) {
// Re-interrupt current thread, to allow other threads to react.
Thread.currentThread().interrupt();
interrupted = true;
}
}
if (wasWaiting) {
activeInvokerCount++;
}
if (scheduledInvokers.size() > maxConcurrentConsumers) {
active = false;
}
}
if (active) {
messageReceived = (invokeListener() || messageReceived);
}
}
return messageReceived;
}
差不多这个类就介绍到这里,继续往下看吧~
org.springframework.jms.listener.endpoint包里面提供了一些JavaEE特性 – 对JCA的支持,这里就不展开了。
org.springframework.jms.support,org.springframework.jms.support.converter,org.springframework.jms.support.destination则分别提供了Jms工具类JmsUtils(依我来看,JmsAccessor类可以考虑放到core包里面,而把一些工具类抽到这里来),针对消息转换器(主要包括三类转换,Object<->Message,XML<->Message,Json<->Message),Destination的支持,难度不大,这里也就不展开讨论了。
org.springframework.jms.remoting包则告诉我们底层可以通过JMS走远程服务,类似RMI的Remoting。
ok,差不多就这些内容。看了这么多,最后我们再总结一下Spring对JMS封装的不足之处吧:
(1) Spring对JMS的封装停留在JMS 1.1规范上(1.0.2中的支持Deprecated了),JMS 2的支持在最新的4.0 版本中未曾找见;
(2) 消息发送&接收的时候没有预留钩子方法。比方说我们有这样的需求 - 跟踪消息走向,在消息发送完后向本地的agent写一点数据,agent定时,定量推送数据去server端做统计运算,展示等。这个时候就没有out-of-box的方法可以去实现,当然变通的方法也有不少,但不适合和开源版本融合;
(3) 缺少一些容错策略,比方说消息发送失败,如何处理?
(4) 缺少连接复用,一种很重要的提升性能策略。
如果有不明白的地方,欢迎大家留言讨论!
参考资料:
http://docs.spring.io/spring/docs/4.0.0.RELEASE/spring-framework-reference/htmlsingle/#jms