You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Thomas Vinod Johnson (JIRA)" <ji...@apache.org> on 2007/08/10 21:51:42 UTC
[jira] Created: (RIVER-226) LLD: consider delaying the queuing of a
discovery request immediately after a discard
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
Priority: Minor
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.
[jira] Updated: (RIVER-226) LLD: consider delaying the queuing of a
discovery request immediately after a discard
Posted by "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.
[jira] Resolved: (RIVER-226) LLD: consider delaying the queuing of
a discovery request immediately after a discard
Posted by "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 resolved RIVER-226.
----------------------------------------
Resolution: Fixed
Fix Version/s: AR2
> 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
>
>
> 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.
[jira] Updated: (RIVER-226) LLD: consider delaying the queuing of a
discovery request immediately after a discard
Posted by "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. (see 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.
[jira] Reopened: (RIVER-226) LLD: consider delaying the queuing of
a discovery request immediately after a discard
Posted by "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 reopened RIVER-226:
----------------------------------------
> 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
>
>
> 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.
[jira] Updated: (RIVER-226) LLD: consider delaying the queuing of a
discovery request immediately after a discard
Posted by "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: (was: RIVER-226.220.patch)
> 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.
[jira] Work started: (RIVER-226) LLD: consider delaying the queuing
of a discovery request immediately after a discard
Posted by "Thomas Vinod Johnson (JIRA)" <ji...@apache.org>.
[ 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.
Re: [jira] Updated: (RIVER-226) LLD: consider delaying the queuing
of a discovery request immediately after a discard
Posted by Mark Brouwer <ma...@cheiron.org>.
Thomas Vinod Johnson wrote:
> Mark Brouwer wrote:
>> Hi Vinod,
>>
>> Patch looks good however I wonder why you decided to start with a
>> delay of 20 seconds (due to the index of 2) versus removing the first
>> 2 entries in the sleepTime array? Not
> Thanks.
>> that it really matters much ...
> Not sure I follow. The sleepTime array's values (including the first
> two) could continue still be used for the back off in the case that
> initial discovery fails. As for using 20 seconds, that was somewhat
> arbitrary.
I overlooked the initial discovery case, sorry.
--
Mark
Re: [jira] Updated: (RIVER-226) LLD: consider delaying the queuing of
a discovery request immediately after a discard
Posted by Thomas Vinod Johnson <Th...@Sun.COM>.
Mark Brouwer wrote:
> Hi Vinod,
>
> Patch looks good however I wonder why you decided to start with a
> delay of 20 seconds (due to the index of 2) versus removing the first
> 2 entries in the sleepTime array? Not
Thanks.
> that it really matters much ...
Not sure I follow. The sleepTime array's values (including the first
two) could continue still be used for the back off in the case that
initial discovery fails. As for using 20 seconds, that was somewhat
arbitrary.
Re: [jira] Updated: (RIVER-226) LLD: consider delaying the queuing
of a discovery request immediately after a discard
Posted by Mark Brouwer <ma...@cheiron.org>.
Hi Vinod,
Patch looks good however I wonder why you decided to start with a delay
of 20 seconds (due to the index of 2) versus removing the first 2
entries in the sleepTime array? Not that it really matters much ...
--
Mark
[jira] Updated: (RIVER-226) LLD: consider delaying the queuing of a
discovery request immediately after a discard
Posted by "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:
---------------------------------------
Comment: was deleted
> 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.
[jira] Assigned: (RIVER-226) LLD: consider delaying the queuing of
a discovery request immediately after a discard
Posted by "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 reassigned RIVER-226:
------------------------------------------
Assignee: 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
>
>
> 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.
[jira] Resolved: (RIVER-226) LLD: consider delaying the queuing of
a discovery request immediately after a discard
Posted by "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 resolved RIVER-226.
----------------------------------------
Resolution: Fixed
> 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.
[jira] Closed: (RIVER-226) LLD: consider delaying the queuing of a
discovery request immediately after a discard
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Firmstone closed RIVER-226.
---------------------------------
> 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.