JMS中为数不多的重点就是消息的确认机制,下面分别介绍J2EE和Spring的MessageListenerContainer的确认机制

J2EE中JMS确认机制

在JMS规范中一共4种确认方式

AUTO_ACKNOWLEDGE当调用recieve方法成功后或MessageListener处理函数成功返回后进行确认

CLIENT_ACKNOWLEDGE客户端通过message的acknowledge方法手动确认

DUPS_OK_ACKNOWLEDGE延迟确认,在对重复接受同一消息不敏感时可以选用此确认模式,相比AUTO_ACKNOWLEDGE有性能提升

SESSION_TRANSACTED调用session的commit或rollback进行事务式确认

Spring中的确认机制

多数情况下会使用Spring集成相关JMS的操作,可以减少相关开发的复杂度,但是Spring的确认方式和默认的JMS确认方式有些许不同,根据官方API

AUTO_ACKNOWLEDGE(默认):这个模式依赖于具体的实现,DefaultMessageListenerContainer中是在调用listener方法之前确认,SimpleMessageListenerContainer是在listener返回后确认,但是即使listener抛出异常,是不会重发的。

DUPS_OK_ACKNOWLEDGE延迟确认,同样也不会对用户异常进行重发

CLIENT_ACKNOWLEDGE当listener抛出异常时会进行重发

基于事务的确认将sessionTransacted设置为true,会在listener抛出异常进行重发,同时这也是spring推荐使用的方式

可以看出Spring的AUTO_ACKNOWLEDGE方式并不会关心listener抛出的异常,这个和J2EE的在listener成功返回后确认有所区别。

SpringJMS相关实现

下面看下SpringJMS MessageListenerContainer的继承树

Object
|-JmsAccessor
|-JmsDestinationAccessor
|-AbstractJmsListeningContainer
|-AbstractMessageListenerContainer
|-AbstractPollingMessageListenerContainer
|-DefaultMessageListenerContainer
|-SimpleMessageListenerContainer
|-SimpleMessageListenerContainer

如上面介绍的DefaultMessageListenerContainer和SimpleMessageListenerContainer是两个不同的分支,

前者继承了AbstractPollingMessageListenerContainer,从名字可以看出这个是客户端polling来获得消息的,也就是使用recieve方法,所以在API中说是在listener方法执行前确认的

后者是直接封装了MessageListener进行调用,但是对用户代码进行了异常控制所以就算抛出异常也不会进行重发,这个也许是为了统一AUTO_ACKNOWLEDGE的行为吧。

总结

spring默认的JMS确认方式是无法保证在用户代码出现异常时进行重发的(如OOM的情况等),这样会导致消息的丢失,在某些场景这个是不可接受的,所以使用中需要注意选用适当的确认方式进行JMS开发

JMS确认机制的更多相关文章

  1. AMQ学习笔记 - 16. 确认机制的测试

    概述 对Acknowledge机制进行测试. 此处的测试是针对Consumer的确认设计的:对于Producer的确认是透明的,无法提供测试. 测试实例 设计demo,测试三种确认机制. 测试机制 测 ...

  2. activemq的消息确认机制ACK

    一.简介 消息消费者有没有接收到消息,需要有一种机制让消息提供者知道,这个机制就是消息确认机制. ACK(Acknowledgement)即确认字符,在数据通信中,接收站发给发送站的一种传输类控制字符 ...

  3. JAVA消息确认机制之ACK模式

    JMS API中约定了Client端可以使用四种ACK模式,在javax.jms.Session接口中: AUTO_ACKNOWLEDGE = 1    自动确认 CLIENT_ACKNOWLEDGE ...

  4. Activemq消息确认机制 --转载

      转自:http://blog.csdn.net/czp11210/article/details/47022639 ActiveMQ消息传送机制以及ACK机制详解 AcitveMQ是作为一种消息存 ...

  5. RabbitMQ 消息确认机制

    消息确认机制 在之前异常处理部分就已经写了,对于consumer的异常退出导致消息丢失,可以时候consumer的消息确认机制.重复的就不说了,这里说一些不一样的. consumer的消息确认机制 当 ...

  6. (转)RabbitMQ消息队列(九):Publisher的消息确认机制

    在前面的文章中提到了queue和consumer之间的消息确认机制:通过设置ack.那么Publisher能不到知道他post的Message有没有到达queue,甚至更近一步,是否被某个Consum ...

  7. RabbitMQ消息队列(九):Publisher的消息确认机制

    在前面的文章中提到了queue和consumer之间的消息确认机制:通过设置ack.那么Publisher能不到知道他post的Message有没有到达queue,甚至更近一步,是否被某个Consum ...

  8. RabbitMQ消息队列(六)-消息任务分发与消息ACK确认机制(.Net Core版)

    在前面一章介绍了在.Net Core中如何使用RabbitMQ,至此入门的的部分就完成了,我们内心中一定还有很多疑问:如果多个消费者消费同一个队列怎么办?如果这几个消费者分任务的权重不同怎么办?怎么把 ...

  9. RabbitMQ的消息确认机制

    一:确认种类 RabbitMQ的消息确认有两种. 一种是消息发送确认.这种是用来确认生产者将消息发送给交换器,交换器传递给队列的过程中,消息是否成功投递.发送确认分为两步,一是确认是否到达交换器,二是 ...

随机推荐

  1. 老版mapreduce跑streaming作业多路输出的方法

    1. 继承MultipleTextOutputFormat实现自己的输出类. 2. 重写generateFileNameForKeyValue方法,返回输出的名字,可通过"/"分割 ...

  2. Cracking-- 1.1 判断字符串中是否有重复字符

    第三种方法为位运算的方法. 位运算符: << 左移  & 与 | 或 #include <iostream> #include <string> #incl ...

  3. 实现js的二叉树

    今天算是第一次写一篇自己的博客,越是学习就越感叹学无止境,为了记录下来用js实现二叉树的方法,这算是最简单的一个算法了. 二叉树实现原理:把数组的第一个数据当作根节点,每个节点都有根节点,左孩子和右孩 ...

  4. SAS提供的机器学习算法

    SAS graphical user interfaces help you build machine-learning models and implement an iterative mach ...

  5. ListView之头部浮动效果

    ListView 中有时需要在顶部固定一个浮动栏,当向上滑动 ListView 时,浮动栏固定在顶部,当向下滑动 ListView 到其 HeaderView 可见时,浮动栏成为ListView的一部 ...

  6. lockfree

    为什么要lockfree 按我的理解, lockfree就是不去 调用操作系统给定的锁机制. 1. 会有system call,  and system call is expensive; 比如pt ...

  7. week7 read

    对于银弹: 在<No Silver Bullet>这篇IBM大型电脑之父佛瑞德·布鲁克斯(Fred Brooks)在1987年所发表的一篇关于软体工程的经典论文中,强调了由于软件的复杂性本 ...

  8. 百度地图API多个点聚合时,标注添加的标签label地图刷新就丢失的问题解决

    当将自定义的Marker(含有Label)通过MarkerClusterer 管理的时候,当地图发生任何移动.缩放 的时候,Marker 的Label 就会自动消失. 这个问题主要是由于百度的点聚合A ...

  9. TestNG教程

    TestNG教程 http://www.yiibai.com/testng/2013/0916311.html TestNG,3种执行方式: 1.ant(build.xml) 2.Eclipse(安装 ...

  10. foremost

    foremost 恢复单个类型文件 删除一个 USB(/dev/sdba1)存储器中一个 png 文件然后使用 formost 恢复. #rm -f /dev/sdb1/1.png #foremost ...