Skip to content
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

Nodes fail every other connect (i.e.: deploy) #45

Open
pdreker opened this issue Oct 2, 2021 · 0 comments
Open

Nodes fail every other connect (i.e.: deploy) #45

pdreker opened this issue Oct 2, 2021 · 0 comments

Comments

@pdreker
Copy link

pdreker commented Oct 2, 2021

I am running these nodes against a 3 Node RabbitMQ cluster on a Raspberry Pi Kubernetes Cluster.

When re-deploying there seems to be some kind of race condition: If the flow is currently running, then changed and re-deployed I receive the following error in the Node Red debug console:


"Could not consume message: Error: Channel ended, no reply will be forthcoming"

When the AMQP in node is set to "Exclusive" there is a different message:

"Could not consume message: Error: Operation failed: QueueDeclare; 405 (RESOURCE-LOCKED) with message "RESOURCE_LOCKED - cannot obtain exclusive access to locked queue 'prometheus' in vhost 'homeautomation'. It could be originally declared on another connection or the exclusive property value does not match that of the original declaration.""

In the latter case there are no other consumers on the queue.

In both cases it seems like the disconnect/reconnect is happening so quick, that the broker has not completely cleaned up in between. The Node then either shows disconnected (waited for a few minutes - no change) or actually in case of the first error message shows "connected", but does not receive any messages (exactly as the error message implies: "No messages will be forthcoming"). In both cases the flow does not work as a result and does so in a rather subtle way.

Simply changing the flow (moving some node is enough) and then redeploying makes the connection work.

Maybe there is a retry missing for certain conditions, or maybe even a small (configurable?) delay before actually connecting could solve this... I think...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant