ActiveMQ 重发机制(消息发送失败后的重新发送)

一、写RedeliveryPolicy配置文件

<!-- 定义ReDelivery(重发机制)机制 ,重发时间间隔是100毫秒,最大重发次数是3次 -->
    <bean id="activeMQRedeliveryPolicy" class="org.apache.activemq.RedeliveryPolicy">
        <!--是否在每次尝试重新发送失败后,增长这个等待时间 -->
        <property name="useExponentialBackOff" value="true"></property>
        <!--重发次数,默认为6次   这里设置为1次 -->
        <property name="maximumRedeliveries" value="1"></property>
        <!--重发时间间隔,默认为1秒 -->
        <property name="initialRedeliveryDelay" value="1000"></property>
        <!--第一次失败后重新发送之前等待500毫秒,第二次失败再等待500 * 2毫秒,这里的2就是value -->
        <property name="backOffMultiplier" value="2"></property>
        <!--最大传送延迟,只在useExponentialBackOff为true时有效(V5.5),假设首次重连间隔为10ms,倍数为2,那么第
            二次重连时间间隔为 20ms,第三次重连时间间隔为40ms,当重连时间间隔大的最大重连时间间隔时,以后每次重连时间间隔都为最大重连时间间隔。 -->
        <property name="maximumRedeliveryDelay" value="1000"></property>
    </bean>  

二、引用RedeliveryPolicy的配置:

<!--创建连接工厂 -->
<bean id="connectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">
    <property name="brokerURL" value="tcp://localhost:61616"></property>
    <property name="redeliveryPolicy" ref="activeMQRedeliveryPolicy" />  <!-- 引用重发机制 -->
</bean>  

原文地址:https://www.cnblogs.com/sjshare/p/8915669.html

时间: 2024-10-09 11:26:51

ActiveMQ 重发机制(消息发送失败后的重新发送)的相关文章

ActiveMQ 重发机制与确认机制 实践

一.配置spring-activemq.xml 1 <?xml version="1.0" encoding="UTF-8"?> 2 <beans xmlns="http://www.springframework.org/schema/beans" 3 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 4 xsi:schemaLocation=&qu

学习ActiveMQ(六):JMS消息的确认与重发机制

当我们发送消息的时候,会出现发送失败的情况,此时我们需要用到activemq为我们提供了消息重发机制,进行消息的重新发送.那么我们怎么知道消息有没有发送失败呢?activemq还有消息确认机制,消费者在接收到消息的时候可以进行确认.本节将确认机制和重发机制一起在原有的代码中学习. 消息确认机制有四种:定义于在session对象中 AUTO_ACKNOWLEDGE= 1 :自动确认 CLIENT_ACKNOWLEDGE= 2:客户端手动确认 UPS_OK_ACKNOWLEDGE= 3: 自动批量确

EmojiChat聊天页面实现,支持发送失败重发《IT蓝豹》

EmojiChat聊天页面实现,支持发送失败重发 EmojiChat聊天页面实现,支持发送失败后重新发送,且支持发送表情,发送图片,适合做社交软件聊天页面参考,功能已经很强大稳定了,本项目主要通过ListView对List<Message>设置ChatAdapter进行显示的.自定义聊天底部弹窗KJChatKeyboard,KJChatKeyboard 控件继承RelativeLayout实现SoftKeyboardStateHelper.SoftKeyboardStateListener,

rabbitmq~消息失败后重试达到 TTL放到死信队列(事务型消息补偿机制)

这是一个基于消息的分布式事务的一部分,主要通过消息来实现,生产者把消息发到队列后,由消费方去执行剩下的逻辑,而当消费方处理失败后,我们需要进行重试,即为了最现数据的最终一致性,在rabbitmq里,它有消息重试和重试次数的配置,但当你配置之后,你的TTL达到 后,消息不能自动放入死信队列,所以这块需要手工处理一下. rabbitmq关于消息重试的配置 rabbitmq: host: xxx port: xxx username: xxx password: xxx virtual-host: x

RabbitMQ消息确认机制—消息发送确认和 消息接收确认

/** * RabbitMQ消息确认机制 * 关于rabbit的生产和消费方的一些实用的操作: * producer的confirm和consumer的ack,这两者使用的模式都是用来保证数据完整性,防止数据丢失 */ /** * producer的confirm模式 * 业务场景描述: * 促销系统在做活动前,需要给用户的手机发送一条活动内容短信希望用户来参加, * 因为用户量有点大,所以通过往短信mq中插入数据方式,让短信服务来消费mq发短信: * 此时插入mq消息的服务为了保证给所有用户发

【Kafka 源码解读】之 【代码没报错但是消息却发送失败!】

聊聊最近,2020年,在2019年的年尾时,大家可谓对这年充满新希望,特别是有20200202这一天.可是澳洲长达几个月的大火,新型冠状病毒nCoV的发现,科比的去世等等事情,让大家感到相当的无奈,生命是如此的脆弱,明天又是如此的未知.但是人应当活在当下,勇敢的面对疫情,和大家和政府一起打赢这场没硝烟的战争! 作为程序员,我必定不能停止工作,不能停止学习,现在在家办公,完全配合现在提倡的隔离战术,对自己负责,对社会负责.下面我会和大家分享一篇我之前写的笔记,和大家一起讨论关于 Kafka 的一个

Hadoop3.1.1源码Client详解 : Packet入队后消息系统运作之DataStreamer(Packet发送) : 主干

该系列总览: Hadoop3.1.1架构体系——设计原理阐述与Client源码图文详解 : 总览 在上一章(Hadoop3.1.1源码Client详解 : 写入准备-RPC调用与流的建立) 我们提到,在输出流DFSOutputStream创建后,DataStreamer也随之创建,并且被启动 下文主要是围绕DataStreamer进行讲解 DataStreamer是一个守护线程类,继承关系如下.       观察DataStreamer的run方法,没有意外的,我们可以发现他和普通的做法一样,用

SQL Server 2008 R2中配置作业失败后邮件发送通知

SQL Server日常维护中难免会遇到作业失败的情况.失败后自然需要知道它失败了,除了例行检查可以发现出错以外,有一个较实时的监控还是很有必要的.比较专业的监控系统比如SCOM虽然可以监控作业执行情况在出错时进行报警,但对于DBA来说可能可定制性不高,最主要的是负责监控的人员在看到报警后一般都需要立刻联系DBA来解决,对于一些重要性不高的作业失败了,大半夜把你叫起来,感觉肯定是不爽的.SQL Server 本身支持发送数据库邮件,结合发送邮件的功能,在作业失败后将出错情况通过邮件通知DBA,这

JavaMail在Windows平台下正常发送邮件,部署到Linux后则发送失败

问题: 在本机(Windows)环境下可以成功发送邮件,但部署到Linux服务器上后不能成功发送,前台不提示错误或提示502. linux下日志提示:javamail isssl false.... JavaMail: package com.ruili.uitl; import java.util.Date; import java.util.Properties; import javax.mail.Session; import javax.mail.Transport; import j