当前位置: 首页 > 知识库问答 >
问题:

从另一个监听器内部调用重试监听器,维护整个重试逻辑

竺焕
2023-03-14

我们使用的是spring-kafka-2.2.8.release。我有一个需要帮助的具体情况。我有4个主题topic、retryTopic、Successstopic和ErrorTopic。如果topic失败,则应该重定向到retryTopic,在那里将进行3次重试尝试。如果这些尝试失败,则必须重定向到ErrorTopic。如果在topic和retryTopic上都有sucess,则应该重定向到sucestopic。基于如何使用spring kafka Version2..2重试的问题,已经实现了这种情况。但是现在,我有了一个新的情况,我需要根据业务逻辑错误从主题侦听器内部调用retryTopic侦听器,而不抛出异常(当抛出异常时,它已经调用了retryTopic,并且必须保持这种行为)。我还需要知道retryTopic在哪个重试尝试号上被调用,作为侦听器bellow的paramater。

 @KafkaListener(id = "so60172304.2", topics = "retryTopic")
 public void listen2(String in) {
            RetryTemplate retryTemplate = new RetryTemplate();
    retryTemplate.execute(new RetryCallback<Void, RuntimeException>() {
        @Override
        public Void doWithRetry(RetryContext retryContext) throws RuntimeException {
             // Can I get the retry count here? It didn't work
             Integer count =RetrySynchronizationManager.getContext().getRetryCount());
            return this.doWithRetry(retryContext);
        }
    }); 
  }

共有1个答案

萧懿轩
2023-03-14

没有理由不能从一个监听器调用另一个监听器(但是除非在第一个方法中使用RetryTemplate调用,否则不会重试)。

如果使用容器工厂上配置的RetryTemplate进行重试(而不是在2.3.x及更高版本中向SeekTocurEnterrorHandler添加backoff),则可以获得重试计数(从零开始),如下所示...

@KafkaListener(id = "so60172304.2", topics = "retryTopic")
public void listen2(String in) {
    int retryCount = RetrySynchronizationManager.getContext().getRetryCount();
    ...
}

getContext()将返回null(除非您将调用封装在retrytemplate.execute())中)。

在2.5.x中,即使在容器工厂中使用SeekTocurEnterrorHandlerbackoff,而不是使用RetryTemplate,传递尝试头也是可用的(可选)。

 类似资料:
  • 常常它是有用的能够接受附加的回调为了切割关注点穿过一些不同的重试 为了这个目的Spring Batch 提供了RetryListene 接口,RetryTemplate 允许使用者注册RetryListene,并且他们将发送回调随从RetryContext和Throwable,在迭代期间可用。 这个接口看起来像这样: public interface RetryListener { voi

  • 主要内容:监听器的分类,监听对象创建和销毁的监听器,监听属性变更的监听器,监听 Session 中对象状态改变的监听器,注册监听器监听器 Listener 是一个实现特定接口的 Java 程序,这个程序专门用于监听另一个 Java 对象的方法调用或属性改变,当被监听对象发生上述事件后,监听器某个方法将立即自动执行。 监听器的相关概念: 事件:方法调用、属性改变、状态改变等。 事件源:被监听的对象( 例如:request、session、servletContext)。 监听器:用于监听事件源对象

  • 性能测试就是以各种形式分析服务器响应,然后将其呈现给客户端。 当JMeter的采样器组件被执行时,监听器提供JMeter收集的关于那些测试用例的数据的图形表示。它便于用户在某些日志文件中以表格,图形,树或简单文本的形式查看采样器结果。 监听器可以在测试的任何地方进行调整,直接包括在测试计划下。JMeter提供了大约15个监听器,但主要使用的是表,树和图形。 以下是JMeter中所有监听器的列表:

  • { "name": "...", "address": "...", "filters": [], "ssl_context": "{...}", "bind_to_port": "...", "use_proxy_proto": "...", "use_original_dst": "...", "per_connection_buffer_lim

  • Envoy配置顶层包含一个监听器列表。每个单独的监听器配置具有以下格式: v1 API参考 v2 API参考 统计 监听器 每个监听器都有一个以 listener.<address> 为根的统计树。统计如下: 名称 类型 描述 downstream_cx_total Counter 连接总数 downstream_cx_destroy Counter 销毁的连接总数 downstream_cx_a

  • Envoy配置支持单个进程中的任意数量的监听器。通常我们建议每台机器运行一个Envoy,而不关心监听器数量。这样可以使操作更简单,统计也更简单。目前Envoy只支持监听TCP。 每个监听器都独立配置一定数量的(L3 / L4)网络过滤器。当监听器接收到新连接时,实例化相应过滤器,并开始处理后续事务。通用监听器用于执行不同代理任务(例如,速率限制,TLS客户机认证,HTTP连接管理,MongoDB嗅