[RIVER-226] LLD: consider delaying the queuing of a discovery request immediately after a discard

• Type: Improvement
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: jtsk_2.1
• Fix Version/s: River_2.1.2
• Component/s: net_jini_discovery
• Bugtraq ID: 6364552
• Assignee: Thomas Vinod Johnson
• Reporter: Thomas Vinod Johnson
• Created: 10/Aug/07 19:50
• Updated: 06/Jan/10 06:04
• Resolved: 06/Mar/08 19:46

Description

Bugtraq ID 6364552
A situation can occur in which a tight loop of discard-discover-discard stack traces under certain circumstances (see the e-mail thread in the comments). Although the LLD takes the position that if it can discover a lookup service, then things must be okay, it might be better to assume that if a lookup service is discarded, things may not be okay. Then, rather than rediscovering a 'not-okay' lookup service which will have to be discarded again, and reporting the same problem over and over again in tight loop, delay the reporting of the problem over time. That is, rather than queuing a rediscovery attempt immediately after a discard, delay the queuing of the attempt in a manner similar to what LLD currently does with retry tasks when failure to discover a lookup occurs.
Suggested fix:
Currently, when a discard occurs, LLD computes the next retry time. So it might be as simple as queuing a task at the "next" time in the set of retry times, rather than always queuing a task at the first (0) time.
See also River-106