river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Vinod Johnson (JIRA)" <j...@apache.org>
Subject [jira] Work started: (RIVER-226) LLD: consider delaying the queuing of a discovery request immediately after a discard
Date Wed, 05 Mar 2008 22:09:40 GMT

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

Work on RIVER-226 started by Thomas Vinod Johnson.

> 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.


Mime
View raw message