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

["Thomas Vinod Johnson (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/RIVER-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Vinod Johnson updated RIVER-226:
---------------------------------------

    Attachment: RIVER-226.220.patch

The patch contains the trivial fix for RIVER-220 also (hunk @@ -476,18 +468,22 @@)

> LLD: consider delaying the queuing of a discovery request immediately after a discard
> -------------------------------------------------------------------------------------
>
>                 Key: RIVER-226
>                 URL: https://issues.apache.org/jira/browse/RIVER-226
>             Project: River
>          Issue Type: Improvement
>          Components: net_jini_discovery
>    Affects Versions: jtsk_2.1
>            Reporter: Thomas Vinod Johnson
>            Assignee: Thomas Vinod Johnson
>            Priority: Minor
>             Fix For: AR2
>
>         Attachments: RIVER-226.220.patch
>
>
> Bugtraq ID [6364552|http://bugs.sun.com/bugdatabase/view_bug.do?bug_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|https://issues.apache.org/jira/browse/RIVER-106]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.