Are closed links allowed to fire error events? #205
Comments
|
In 4. is it a connection error? I assume it can't be a link error in the AMQP sense if the link is not open. I think this is the question you ask 'When the link is in a "closed" state, why is the server able to send a error for it?' and the answer is that it can't. If the link has not been reopened after disconnection, the server cannot send a link error only a connection error (and rhea does not emit these on the link). Is it possible that rhea-promise is adding a listener for connection events to a receiver object and that is what is firing? At present rhea does not remove listeners from any object at any state. While we could change that, my instinct would only be to do so in the case where the link.session/connection is fully closed (i.e. both sides have closed it) or at the very least where the local application has closed it. If I understand correctly, step 2. involves the implicit closing of a link due to loss of a connection and in that case I think the application should take some specific action. So to 'Can we expect rhea to completely "close" and clean up the link in this scenario?' I would say no, and implicitly closed link with no reconnect will remain implicitly closed and I don't think rhea should do anything further without some explicit action by the application to indicate it no longer cares about that object, e.g. as you suggest by removing the link. |
It is not a connection error. It is an error on the original receiver link. We added the link name in the log that prints event being fired from rhea and it clearly shows that the error is coming from the original receiver link.
We also noticed a Below are the relevant logs. DEBUG was set to Things to note:
|
|
So the link is not closed at the point the error is sent by the server. The link was reopened and then closed by server with an error. |
|
What should we look for in the logs to confirm that the server has indeed re-opened the link? |
|
The receiver_open event shows that. You can also turn on frame tracing and you should see the attach. I believe the attach will be triggered by your client (either reconnect, or if that is off then the application or rhea-promise library). |
|
@grs It looks like rhea is sending the request to open the link. Below is the logs with rhea frames. If you look at each Once the Correct me if I am wrong, but this looks like rhea is trying to reconnect the links. FYI: When creating the connection we have set |
|
Yes, as suspected, the client is initiating the attach. That is expected for reconnect, either automatic where the reconnect option is on, or where a manual call to reconnect() on the connection is made. If the reconnect option is not on then even the connection would not be re-established. |
|
@grs We found that we do call connection.open() in rhea-promise that calls connection.connect() in rhea And Lines 271 to 273 in 96a2324 false
Shouldnt rhea clear up cc @ShivangiReja who investigated and made the above observations |
|
The reconnect option is there to control whether the library automatically reconnects on disconnection. I don't think it setting it to false should cause the local_channel_map to be deleted. For one thing some users might need to know about the state of sessions and links at the time of disconnection. If you don't want to use any of the connection state when re-establishing a connection, you can always use a new connection. If you just wish to remove certain sessions or links, you can do that. |
|
That clarifies a lot of things, thanks @grs. One last question. Say we do the following (completely hypothetical case)
rhea will now attempt to reconnect all the sessions and its links? Because I see that session.close() or link.close() dont clear the internal map that the connection or the session maintain respectively. |
|
It won't reconnect closed sessions and links. |
|
Thanks @grs
We want to remove all the sessions and links on the connection. Would you be open for a PR (#207) from us that introduces a new function |
This was referenced Mar 17, 2019
Merged
|
Sure, though at that point you could also just create a new connection(?). |
|
Yes, that is a good point and we will explore that approach, but for now this Thanks for the quick response on the PR @grs! Could you please drop a note here when a new version is published? |
|
1.0.2 published |
|
Thanks a ton! |
6 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Below is the sequence of events relevant to this issue
connectionobject fires thedisconnectedevent, the receiver link is now in a "closed" state. Our application hasn't called close on it.It's hard for us to give a code sample to reproduce this because we would need the server to send the error. Hopefully, the above gives enough details about our situation.
My question:
disconnectedevent on the connection?cc @grs, @amarzavery
The text was updated successfully, but these errors were encountered: