-
Notifications
You must be signed in to change notification settings - Fork 626
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatic reconnection when RMQ is not available when sending the first message. #1038
Comments
You are correct - thanks for the analysis. |
Fixes spring-projects#1038 Don't set `evaluatedFastReplyTo` if we didn't actually evaluate it because the broker is down on the first request. **cherry-pick to all 2.x; backport to 1.7.x**
Fixes #1038 Don't set `evaluatedFastReplyTo` if we didn't actually evaluate it because the broker is down on the first request. **cherry-pick to all 2.x; backport to 1.7.x**
Fixes #1038 Don't set `evaluatedFastReplyTo` if we didn't actually evaluate it because the broker is down on the first request. **cherry-pick to all 2.x; backport to 1.7.x** # Conflicts: # spring-rabbit/src/test/java/org/springframework/amqp/rabbit/core/RabbitTemplateTests.java
Fixes #1038 Don't set `evaluatedFastReplyTo` if we didn't actually evaluate it because the broker is down on the first request. **cherry-pick to all 2.x; backport to 1.7.x** # Conflicts: # spring-rabbit/src/test/java/org/springframework/amqp/rabbit/core/RabbitTemplateTests.java # Conflicts: # spring-rabbit/src/test/java/org/springframework/amqp/rabbit/core/RabbitTemplateTests.java
Fixes #1038 Don't set `evaluatedFastReplyTo` if we didn't actually evaluate it because the broker is down on the first request. **cherry-pick to all 2.x; backport to 1.7.x** # Conflicts: # spring-rabbit/src/test/java/org/springframework/amqp/rabbit/core/RabbitTemplateTests.java # Conflicts: # spring-rabbit/src/test/java/org/springframework/amqp/rabbit/core/RabbitTemplateTests.java # Conflicts: # spring-rabbit/src/main/java/org/springframework/amqp/rabbit/core/RabbitTemplate.java # spring-rabbit/src/test/java/org/springframework/amqp/rabbit/core/RabbitTemplateTests.java
Hi! |
What operating system/JDK? For me it gets a
|
The problem with using |
OK |
Fixes spring-projects#1038 The previous fix to catch `AmqpConnectException` was incorrect - the `ShutdownSignalException` for the passive queue declaration failure is wrapped in an `AmqpConnectException` so we would have failed to detect the failure. Also, it has been reported that sometimes an `AmqpIOException` is thrown. - Add `AmqpIOException` to the catch block - Search for, and explitly check for the queue declaration failed exception - For all other cases rethrow so we can test again
Fixes spring-projects#1038 The previous fix to catch `AmqpConnectException` was incorrect - the `ShutdownSignalException` for the passive queue declaration failure is wrapped in an `AmqpConnectException` so we would have failed to detect the failure. Also, it has been reported that sometimes an `AmqpIOException` is thrown. - Add `AmqpIOException` to the catch block - Search for, and explitly check for the queue declaration failed exception - For all other cases rethrow so we can test again **cherry-pick to all supported**
Fixes spring-projects#1038 The previous fix to catch `AmqpConnectException` was incorrect - the `ShutdownSignalException` for the passive queue declaration failure is wrapped in an `AmqpConnectException` so we would have failed to detect the failure. Also, it has been reported that sometimes an `AmqpIOException` is thrown. - Add `AmqpIOException` to the catch block - Search for, and explitly check for the queue declaration failed exception - For all other cases rethrow so we can test again **cherry-pick to all supported**
Fixes #1038 The previous fix to catch `AmqpConnectException` was incorrect - the `ShutdownSignalException` for the passive queue declaration failure is wrapped in an `AmqpConnectException` so we would have failed to detect the failure. Also, it has been reported that sometimes an `AmqpIOException` is thrown. - Add `AmqpIOException` to the catch block - Search for, and explitly check for the queue declaration failed exception - For all other cases rethrow so we can test again **cherry-pick to all supported** * * Fix log messages
Hello. Please help me with the problem.
The problem is related to automatic reconnection.
I use Spring Boot 2.1.3, but it happens in version 2.1.6 and RabbitMQ with spring-boot-starter-amqp
Bin RabbitTemplate looks like this:
We use the following method to support rpc:
We want to use Direct ReplyTo with pseudo queues.
The scenario in which the normal behavior RabbitTemplate
Scenario in which abnormal behavior is detected:
The error is as follows:
I tried to figure out what was happening and found the following. The selected code block is executed 1 time at the first call. If the access was to the rabbit, then the first condition in the chain is satisfied. If we get an exception, then we get into the second condition block. Everything happens because at the first message(RQM is not available) we get replyAddress = null and usingFastReplyTo = false.
I hope this is enough.
The text was updated successfully, but these errors were encountered: