Replies: 6 comments 6 replies
-
There are worker shutdown timeout in many places. With quorum queues, streams and CQ v2 it should not be necessary to increase them because very little data is kept in memory. Connection shutdown log messages are irrelevant for CQ index rebuilding. |
Beta Was this translation helpful? Give feedback.
-
EDIT: I actually don't always see the "rebuilding" message, even if I stop RabbitMQ with a TERM signal. I'm investigating. @serut it's safe to ignore that message. The SIGTERM handling in the @michaelklishin I think we should investigate why that message appears on occasion. |
Beta Was this translation helpful? Give feedback.
-
Thank you for your reply !! If I run
You can notice this log is much longer than the log produced by a Here is the log produced by the next boot after a
The server boots under 3 mins, which is much better. The main difference so far is this log :
There is no indices to rebuild from scratch after a May I ask you why you move this as a discussion ? |
Beta Was this translation helpful? Give feedback.
-
cc @michaelklishin @dumbbell the code that is executed when
The biggest difference I see is that I still have yet to reliably duplicate the "rebuilding" message. |
Beta Was this translation helpful? Give feedback.
-
Here's a test I did with
Note that indices were only rebuilt from scratch on the first start of RabbitMQ, as I would expect. Going to try out the same tests using Docker next. |
Beta Was this translation helpful? Give feedback.
-
Here is the repo with GNU In the log file, you can see that the only time indices are rebuilt from scratch is when the container is terminated via So, at this point, I don't see an issue to fix.
I ran
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello there,
Our RabbitMQ container does not seem to correctly shutdown as the next boot rebuilds indices from scratch.
I've tryed to configure the
stop_grace_period
docker property to let RabbitMQ properly write its indices but it's not working.Our Swarm deployment looks like this :
When the container stops, we can see it does not fully save its index correctly :
This is the log when the server boots :
The configuration file
rabbitmq.conf
Moreover, this is a very small instance we use since a couple of days to validate our software, as you can see here :

Do you know how to configure the property
worker_shutdown_timeout
or to see its current value ?Duplicates of docker-library/rabbitmq#610
Beta Was this translation helpful? Give feedback.
All reactions