Comments (5)
Some notes on the setup:
That "reporting-service.SnapshotSync" queue is started and stopped later by the application. It is running only during a certain phase of the application lifetime. This is done by auto-wiring the RabbitListenerEndpointRegistry and calling start()/stop() as in the following snippet:
endpointRegistry.getListenerContainer(RabbitConfig.LISTENER_ID_SNAPSHOT_SYNC).start()
// ...
endpointRegistry.getListenerContainer(RabbitConfig.LISTENER_ID_SNAPSHOT_SYNC).stop()
The problematic queue is an non-auto-startup, exclusive queue as defined by
@RabbitListener(
queues = "#{snapshotSyncQueue.name}",
autoStartup = "false",
id = RabbitConfig.LISTENER_ID_SNAPSHOT_SYNC,
exclusive = true
)
public class SnapshotSyncRabbitController {
// ...
from spring-amqp.
The fix you are mentioning has not been released yet: #2492.
Probably this b98847c or this 95631d8.
It would be great if you can test your project against 2.4.15-SNAPSHOT
. It is going to be released in a couple weeks: https://calendar.spring.io/
from spring-amqp.
Hi @artembilan ,
thanks for your response, but unfortunately using the 2.4.15-SNAPSHOT versions of spring-amqp and spring-rabbit does not fix the issue. I think it is not related to the forceStop() flag, which I already tried to set on my own via a ContainerCustomizer bean.
The error message stays the same:
Failed to shut down 1 bean with phase value 2147483647 within timeout of 30000ms: [org.springframework.amqp.rabbit.config.internalRabbitListenerEndpointRegistry] [stop(), DefaultLifecycleProcessor.java:384]
I double-checked the classpath of the running app to ensure it is using the snapshot version:
.gradle\caches\modules-2\files-2.1\org.springframework.amqp\spring-rabbit\2.4.15-SNAPSHOT\b3a16ac4af72a8cc4aca73236df4d90cde140442\spring-rabbit-2.4.15-SNAPSHOT.jar
.gradle\caches\modules-2\files-2.1\org.springframework.amqp\spring-amqp\2.4.15-SNAPSHOT\389a7a17bb5c73e1ed4cc09d11ac427a6f22845\spring-amqp-2.4.15-SNAPSHOT.jar
I know it is a long text 😉 But I guess the problem is the same as in my original issue conclusion:
In AbstractMessageListenerContainer.java:1370 the method can return without executing a given (non-nulll) shutdown callback, therefore missing to decrease a countdown latch in the DefaultLifecycleProcessor.
from spring-amqp.
This is a minimal sample app that reproduces the issue with 2.4.15-SNAPSHOT. Just start and then stop the application to see the issue:
DemoApplication.java
@SpringBootApplication
@EnableRabbit
public class DemoApplication {
@Bean
public Queue queue1() {
return new Queue("reporting-service.queue1", false);
}
@Bean
public Queue queue2() {
return new Queue("reporting-service.queue2", false);
}
public static void main(String[] args) {
SpringApplication.run(DemoApplication.class, args);
}
}
DemoRabbitController.java
@Controller
public class DemoRabbitController {
@RabbitListener(queues = "#{queue1.name}")
public void receive1(String message) {
System.out.println(message);
}
@RabbitListener(queues = "#{queue2.name}", autoStartup = "false")
public void receive2(String message) {
System.out.println(message);
}
}
Result
The graceful shutdown hangs for 30sec and then prints the Failed to shut down 1 bean
error before the process exits:
...
2023-08-09 10:21:03.267 INFO 6860 --- [ main] o.s.amqp.rabbit.core.RabbitAdmin : Auto-declaring a non-durable, auto-delete, or exclusive Queue (reporting-service.queue1) durable:false, auto-delete:false, exclusive:false. It will be redeclared if the broker stops and is restarted while the connection factory is alive, but all messages will be lost.
2023-08-09 10:21:03.267 INFO 6860 --- [ main] o.s.amqp.rabbit.core.RabbitAdmin : Auto-declaring a non-durable, auto-delete, or exclusive Queue (reporting-service.queue2) durable:false, auto-delete:false, exclusive:false. It will be redeclared if the broker stops and is restarted while the connection factory is alive, but all messages will be lost.
2023-08-09 10:21:03.302 INFO 6860 --- [ main] c.example.shutdownhang.DemoApplication : Started DemoApplication in 1.67 seconds (JVM running for 2.138)
// -------- triggered application stop via InteliJ --------
2023-08-09 10:21:13.318 INFO 6860 --- [ntContainer#0-2] o.s.a.r.l.SimpleMessageListenerContainer : Waiting for workers to finish.
2023-08-09 10:21:14.319 INFO 6860 --- [ntContainer#0-2] o.s.a.r.l.SimpleMessageListenerContainer : Successfully waited for workers to finish.
2023-08-09 10:21:43.320 INFO 6860 --- [ionShutdownHook] o.s.c.support.DefaultLifecycleProcessor : Failed to shut down 1 bean with phase value 2147483647 within timeout of 30000ms: [org.springframework.amqp.rabbit.config.internalRabbitListenerEndpointRegistry]
Process finished with exit code 130
from spring-amqp.
Confirmed regression; probably caused by 1fdfe65
from spring-amqp.
Related Issues (20)
- MessageProperties setDelay maximum value problem HOT 3
- ImmediateAcknowledgeAmqpException keeps the message in the queue HOT 10
- TraceId propagation to the new thread local HOT 4
- Wrong ClassLoader is used for message deserialization when devtools are active
- Wrong ClassLoader is used for message deserialization when devtools are active HOT 1
- Kotlin suspend functions return type is incorrect HOT 3
- Kotlin suspend functions return type is incorrect HOT 1
- Channel cache leak when no answers from broker for pending confirms
- Channel cache leak when no answers from broker for pending confirms HOT 1
- Invoke RabbitListenerErrorHandler when the batch of the listener is enabled HOT 2
- Document that micrometer observations aren't started for batch listeners HOT 4
- Unable to access AMQP Channel from RabbitListenerErrorHandler in case of MessageConversionException HOT 1
- Deadlock when reaching channel limit in DirectMessageListenerContainer HOT 5
- Remove deprecated method in the `RabbitListenerErrorHandler`
- DefaultMessagePropertiesConverter#toMessageProperties should handle x-delay in Short HOT 4
- DefaultMessagePropertiesConverter#toMessageProperties should handle x-delay in Short HOT 1
- Memory leak with AsyncRabbitTemplate HOT 5
- Memory leak with AsyncRabbitTemplate HOT 1
- Use JDK `ObjectInputFilter` instead of calling `AllowedListDeserializingMessageConverter::checkAllowedList` in `ConfigurableObjectInputStream::resolveClass` HOT 1
- Fix RabbitMQ x-death header documentation HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from spring-amqp.