You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 11, 2021. It is now read-only.
while analyzing our logs and comparing them to the source code, we found some issues.
If the connection gets lost and somehow the ChannelOwner receives a Shutdown before the ConnectionOwner, the ChannelOwner asks the ConnectionOwner to create a new channel (ChannelOwner.scala:219) and becomes disconnected (ChannelOwner.scala:221). The ConnectionOwner tries to create the channel (ConnectionOwner.scala:177) which failes with an AlreadyClosedException. Due to this exception, the ConnectionOwner becomes disconnected (ConnectionOwner.scala:181), too. However, in this case it does not inform its children about the disconnect.
Shouldn't the same error handling apply in this case like on a received Shutdown message (ConnectionOwner.scala:192)?
In our case we haven't received the Shutdown on the Connection at all, otherwhise we would have seen it as unknown message logged out by the ConnectionOwner when it is in the disconnected state.
Best regards
Niko
P.S.: we use the amqp-client_2.11 in version 1.5.
The text was updated successfully, but these errors were encountered:
the actual rabbitmq connection was lost (or the broker stopped or ...)
the connection actor never received a Shutdown message (so there is not trace of it, it should be logged as an error)
some channel actors never received a Shutdown message
Is it correct ?
I guess that in ConnectionOwner shutdown handling could (though I'm not sure yet that it should) be moved to unhandled() instead of connected() but in any case channel actors should have received a Shutdown message:
connection owners register a "connection shutdown callback" when the actual connection is created (see ConnectionOwner L119)
each channel actor registers a "channel shutdown callback" when they create their forwarder (see ChanelOwner L185)
So even if the connection somehow did not receive a Shutdown message, and so did not forward it to its children, they should have received a Shutdown message sent by their forwarder anyway ?
Moving the Shutdown handling to the unhandled could actually work.
To be honest, we only had one Consumer/ChannelOwner in this case. It could be, that we otherwise would have received the Shutdown in each of them directly. Looking again at the Shutdown handler in the ConnectionOwner, it could also be, that we received the Shutdown after it already was put to the disconnected state because there wouldn't be any log output then.
Nevertheless, all transitions to the disconnected state should handle it the same way (e.g. set the Connection var to None).
Best regards
Niko
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hi,
while analyzing our logs and comparing them to the source code, we found some issues.
If the connection gets lost and somehow the ChannelOwner receives a Shutdown before the ConnectionOwner, the ChannelOwner asks the ConnectionOwner to create a new channel (ChannelOwner.scala:219) and becomes disconnected (ChannelOwner.scala:221). The ConnectionOwner tries to create the channel (ConnectionOwner.scala:177) which failes with an AlreadyClosedException. Due to this exception, the ConnectionOwner becomes disconnected (ConnectionOwner.scala:181), too. However, in this case it does not inform its children about the disconnect.
Shouldn't the same error handling apply in this case like on a received Shutdown message (ConnectionOwner.scala:192)?
In our case we haven't received the Shutdown on the Connection at all, otherwhise we would have seen it as unknown message logged out by the ConnectionOwner when it is in the disconnected state.
Best regards
Niko
P.S.: we use the amqp-client_2.11 in version 1.5.
The text was updated successfully, but these errors were encountered: