Community
Participate
Working Groups
One thing I noticed in the new Target Explorer is when a channel to a discovered peer fails, e.g. when the agent is killed off, we don't get a peer removed event. Should it? Or am I using the wrong strategy (i.e. relying on peer added and remove events to determine target state).
A peer is removed if no heartbeat packets received from the peer during predefined data retention period, which is set to 1 minute.
Yes, I realize that. But in that time interval between the channel failure and the heartbeat there is a pretty big window when other failures will occur. That leads to pretty bad usability. That and if we assume the channel failure means the target is gone, we don't get the peerAdded event when it comes back, which is real issue at the moment. I'm not sure what the right answer is, but we should be as accurate as possible about the target state.
Removing auto-discovered peer right away when the agent is killed would be good thing to do. It can be done by catching SIGKILL in the agent. However, a peer represents a target address - not the target itself. Peer added and removed events are not supposed to be used to track real time target state. For example, these event are send when user adds or deletes peers - regardless of the target state.
I have extended discovery protocol with additional packet type that is sent when agent is about to exit. Now peers are removed without a delay when the agent is shut down.
Excellent! Thanks, Eugene.
