java.lang.IllegalStateException: Only one connection receive subscriber allowed

针对Spring Cloud Gateway在处理特定POST请求时出现的Only one connection receive subscriber allowed异常,详细探讨了异常原因并提供了两种解决方案:一是调整Spring Boot版本至2.0.4;二是禁用HiddenHttpMethodFilter过滤器,附带具体实现代码。

 

 

在使用spring-cloud-gateway当作网关服务,当收到post请求,且content-type为application/x-www-form-urlencoded时,网关服务报如下异常:
2018-10-08 13:11:34.971 ERROR 8304 --- [ctor-http-nio-3] .a.w.r.e.DefaultErrorWebExceptionHandler : Failed to handle request [POST http://127.0.0.1:8088/demo/login]
 
java.lang.IllegalStateException: Only one connection receive subscriber allowed.
    at reactor.ipc.netty.channel.FluxReceive.startReceiver(FluxReceive.java:279) ~[reactor-netty-0.7.9.RELEASE.jar:0.7.9.RELEASE]
    at reactor.ipc.netty.channel.FluxReceive.lambda$subscribe$2(FluxReceive.java:129) ~[reactor-netty-0.7.9.RELEASE.jar:0.7.9.RELEASE]
    at io.netty.util.concurrent.AbstractEventExecutor.safeExecute$$$capture(AbstractEventExecutor.java:163) ~[netty-common-4.1.29.Final.jar:4.1.29.Final]
    at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java) ~[netty-common-4.1.29.Final.jar:4.1.29.Final]
    at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:404) ~[netty-common-4.1.29.Final.jar:4.1.29.Final]
    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:446) ~[netty-transport-4.1.29.Final.jar:4.1.29.Final]
    at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:884) ~[netty-common-4.1.29.Final.jar:4.1.29.Final]
    at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_60]
该异常大概意思是连接中的请求体只能被订阅一次,也就是说这个请求的body已经被读取过一次了,然后我从网上查阅各种资料也请教了大神,提供的解决思路都是通过缓存body之后,再重新封装一次request转发出去,但是我试过N多遍,并且各种改良,我的接口服务始终接收不到任何参数。无奈,后来在stackoverflow发布了这个问题,得到了国外大神的指点有两个解决办法

 

方法一:

    其实这个问题是在spring-boot-2.0.5这个版本上才出现的,所以将版本改为2.0.4即可,如果不想改版本号可参考方法二。

 

方法二:

    使用如下代码禁用HiddenHttpMethodFilter 过滤器,该过滤器的作用请参考:https://blog.youkuaiyun.com/geloin/article/details/7444321

    @Bean
    public HiddenHttpMethodFilter hiddenHttpMethodFilter() {
        return new HiddenHttpMethodFilter() {
            @Override
            public Mono<Void> filter(ServerWebExchange exchange, WebFilterChain chain) {
                return chain.filter(exchange);
            }
        };
    }
 

国外大神关于这个问题的讨论帖:https://github.com/spring-cloud/spring-cloud-gateway/issues/541
————————————————
版权声明:本文为优快云博主「哪托的轮滑鞋」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.youkuaiyun.com/weixin_40420213/article/details/82966550

<think>好的,我现在需要解决用户遇到的Java中RabbitTemplate只能设置一个ConfirmCallback的问题。用户提供的错误信息显示,当尝试设置第二个ConfirmCallback时,Spring抛出了IllegalStateException,提示每个RabbitTemplate只支持一个ConfirmCallback。我得先理解这个问题的原因,然后找到解决方案。 首先,我应该回顾RabbitTemplate的ConfirmCallback机制。ConfirmCallback用于确认消息是否成功发送到交换机。当消息被Broker接收时,会触发该回调。根据SpringAMQP的文档,每个RabbitTemplate实例确实只能注册一个ConfirmCallback。这是因为ConfirmCallback是一个全局的设置,针对整个模板,而不是针对单个消息。如果用户多次调用setConfirmCallback方法,第二次调用就会触发异常,导致程序崩溃。接下来,我需要思考用户为什么会需要设置多个ConfirmCallback。可能的场景是,用户在不同的地方或针对不同的消息类型,希望有不同的确认处理逻辑。例如,订单消息和日志消息可能需要不同的处理方式。然而,RabbitTemplate的设计不允许这样做,所以必须找到替代方案。解决方案可能包括以下几种:1.**使用单个ConfirmCallback进行路由**:用户可以在唯一的ConfirmCallback中根据消息的属性(如消息头、correlationId等)来分发到不同的处理逻辑。这需要所有发送的消息都携带特定的标识,以便回调时能够识别并路由到正确的处理程序。 2. **创建多个RabbitTemplate实例**:每个实例配置自己的ConfirmCallback。这样,不同的业务模块可以使用不同的模板实例,每个实例处理自己的确认逻辑。但需要注意资源管理,因为每个模板实例都会创建自己的连接等资源,可能增加系统开销。3.**使用异步确认机制的高级特性**:例如,结合Spring Integration或者自定义消息监听容器,但这种方法可能复杂度较高,需要更多配置。 接下来,我需要验证这些方案的可行性。例如,对于第一种方案,如何在ConfirmCallback中区分不同的消息?用户可以在发送消息时,在消息头中添加自定义的标识,比如消息类型或业务标识。然后在回调中检查这些标识,调用相应的处理逻辑。这需要发送端和回调端的协作。对于第二种方案,创建多个RabbitTemplate实例是否会导致资源浪费?SpringAMQP的连接工厂通常使用连接池,所以多个模板可能共享连接,但每个模板的通道可能独立。需要评估系统的资源使用情况,如果消息量不大,这可能是一个可行的解决方案。另外,用户可能遇到的问题是如何管理多个RabbitTemplate实例。例如,在Spring配置中声明多个实例,并确保它们被正确注入到需要的地方。这需要一定的配置工作,但相对直接。 最后,我需要考虑如何将这些解决方案以清晰的方式呈现给用户,确保步骤详细且易于理解。同时,要提醒可能的注意事项,比如资源管理、性能影响等。</think>### 解决RabbitTemplate仅支持一个ConfirmCallback的方法 当使用Spring AMQP的`RabbitTemplate`时,若需要为不同消息类型实现独立的确认逻辑,可通过以下方案解决`ConfirmCallback`单例限制: #### 方案1:通过消息标识路由处理逻辑 1. **发送消息时添加标识** 在消息头中嵌入业务标识(如消息类型或业务ID),用于回调时区分处理逻辑: ```java Message message = MessageBuilder.withBody("订单内容".getBytes()) .setHeader("msgType", "ORDER") // 添加消息类型标识 .build(); rabbitTemplate.send("exchange", "routingKey", message); ``` 2. **统一ConfirmCallback分发逻辑** 在全局`ConfirmCallback`中根据消息头路由到不同处理器: ```java rabbitTemplate.setConfirmCallback((correlationData, ack, cause) -> { if (correlationData != null && correlationData.getReturnedMessage() != null) { Message message = correlationData.getReturnedMessage(); String msgType = message.getMessageProperties().getHeader("msgType"); if ("ORDER".equals(msgType)) { orderService.handleConfirm(ack, cause); } else if ("LOG".equals(msgType)) { logService.handleConfirm(ack, cause); } } }); ``` #### 方案2:创建多个RabbitTemplate实例 1. **配置多个模板实例** 在Spring配置中声明不同业务专用的模板: ```java @Bean(name = "orderRabbitTemplate") public RabbitTemplate orderRabbitTemplate(ConnectionFactory connectionFactory) { RabbitTemplate template = new RabbitTemplate(connectionFactory); template.setConfirmCallback((correlationData, ack, cause) -> { // 订单确认逻辑 }); return template; } @Bean(name = "logRabbitTemplate") public RabbitTemplate logRabbitTemplate(ConnectionFactory connectionFactory) { RabbitTemplate template = new RabbitTemplate(connectionFactory); template.setConfirmCallback((correlationData, ack, cause) -> { // 日志确认逻辑 }); return template; } ``` 2. **按需注入使用** 在业务类中指定要使用的模板: ```java @Autowired @Qualifier("orderRabbitTemplate") private RabbitTemplate orderTemplate; @Autowired @Qualifier("logRabbitTemplate") private RabbitTemplate logTemplate; ``` #### 方案对比 | 方案 | 优点 | 注意事项 | |------|------|----------| | 消息路由 | 资源消耗少 | 需维护消息头标识体系 | | 多模板实例 | 逻辑完全隔离 | 需监控连接池资源使用 | #### 注意事项 1. 使用`CorrelationData`时需确保其与消息的关联性,建议在发送时显式传递: ```java CorrelationData correlationData = new CorrelationData("ORDER-123"); rabbitTemplate.convertAndSend(exchange, routingKey, message, correlationData); ``` 2. 多模板方案中,建议通过`@Primary`标注默认模板避免自动装配冲突[^1] ---
评论 2
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值