[Questions] RabbitMQ queue crash after upgrading to 4.2 #15134
Replies: 4 comments 2 replies
-
|
This is a known Windows-specific filesystem API behavior that we have addressed in some places but possibly not all. A file handle on Windows cannot be closed if it has more than one concurrent user or something like that. This time the function that has run into it is Switching to running RabbitMQ on Linux, which is something our team strongly recommends, will fundamentally address this behavior. |
Beta Was this translation helpful? Give feedback.
-
|
Searching this repository's issues, discussions and PRs for |
Beta Was this translation helpful? Give feedback.
-
|
The problem is that after the crash the queue restarts and tries to recover fast enough that opening this same file gives the same error as the original crash. And then it gives up. We can add an |
Beta Was this translation helpful? Give feedback.
-
|
I'm adding another crash log from today to help further identify the error. Details |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Community Support Policy
RabbitMQ version used
4.2.1
Erlang version used
27.3.x
Operating system (distribution) used
Windows Server
How is RabbitMQ deployed?
Windows installer
rabbitmq-diagnostics status output
NA
Logs from node 1 (with sensitive values edited out)
See https://www.rabbitmq.com/docs/logging to learn how to collect logs
Details
Logs from node 2 (if applicable, with sensitive values edited out)
No response
Logs from node 3 (if applicable, with sensitive values edited out)
No response
rabbitmq.conf
Default
Steps to deploy RabbitMQ cluster
NA
Steps to reproduce the behavior in question
Not reproducible
advanced.config
NA
Application code
No response
Kubernetes deployment file
No response
What problem are you trying to solve?
Could someone review the attached log file and advise if it indicates the root cause of the crash?
Beta Was this translation helpful? Give feedback.
All reactions