| Summary: | Peers not removed when Channels are reset | ||
|---|---|---|---|
| Product: | [Tools] TCF | Reporter: | Doug Schaefer <cdtdoug> |
| Component: | Core | Assignee: | Eugene Tarassov <eugene> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | unspecified | ||
| Target Milestone: | 0.4.0 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Doug Schaefer
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. |