You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Frank Barnaby (JIRA)" <ji...@apache.org> on 2007/07/26 21:46:03 UTC
[jira] Created: (RIVER-74) LookupDiscovery and
LookupLocatorDiscovery should have a different UnicastSocketTimeout
LookupDiscovery and LookupLocatorDiscovery should have a different UnicastSocketTimeout
---------------------------------------------------------------------------------------
Key: RIVER-74
URL: https://issues.apache.org/jira/browse/RIVER-74
Project: River
Issue Type: Improvement
Components: net_jini_discovery
Reporter: Frank Barnaby
Priority: Minor
Bugtraq ID [6234394|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id= 6234394]
Currently, {{LookupDiscovery}} and {{LookupLocatorDiscovery}} time out on unicast discovery requests within 1 minute of initiation (the default). This timeout value may be too short. In a pathological case with multiple discovering entities and a loaded LUS, this may result in large numbers of prematurely closed connections (characterized by large number of {{CLOSE_WAIT}} TCP connections on the LUS). Given that the LUS has accepted the request, there seems to be very little point to prematurely giving up on the request (A possible reason would be to save a thread at the discovering entity - especially in the case that the LUS host goes down or becomes inaccessible). An appropriate value for this timeout needs to be determined.
*Comments*
Coming up with a reasonable value is difficult. One possible reason for upper-bounding this timeout might be out of concern for a network disconnection long enough to absorb all of the LUS's attempts to (re)transmit the unicast response-- given that the unicast discovery protocol doesn't support an application-level ping that could be processed as aggressively as a new connection attempt currently is. Again, across server-side OSes, the relative durations should be Windows < Solaris < Linux, but all should be less than the typical two-hour TCP keepalive interval that would (if enabled) otherwise catch this condition.
*See Also*
[6179194|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6179194]
[6209059|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6209059]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (RIVER-74) LookupDiscovery and
LookupLocatorDiscovery should have a different UnicastSocketTimeout
Posted by "Frank Barnaby (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Frank Barnaby updated RIVER-74:
-------------------------------
Description:
Bugtraq ID [6234394|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6234394]
Currently, {{LookupDiscovery}} and {{LookupLocatorDiscovery}} time out on unicast discovery requests within 1 minute of initiation (the default). This timeout value may be too short. In a pathological case with multiple discovering entities and a loaded LUS, this may result in large numbers of prematurely closed connections (characterized by large number of {{CLOSE_WAIT}} TCP connections on the LUS). Given that the LUS has accepted the request, there seems to be very little point to prematurely giving up on the request (A possible reason would be to save a thread at the discovering entity - especially in the case that the LUS host goes down or becomes inaccessible). An appropriate value for this timeout needs to be determined.
*Comments*
Coming up with a reasonable value is difficult. One possible reason for upper-bounding this timeout might be out of concern for a network disconnection long enough to absorb all of the LUS's attempts to (re)transmit the unicast response-- given that the unicast discovery protocol doesn't support an application-level ping that could be processed as aggressively as a new connection attempt currently is. Again, across server-side OSes, the relative durations should be Windows < Solaris < Linux, but all should be less than the typical two-hour TCP keepalive interval that would (if enabled) otherwise catch this condition.
*See Also*
[6179194|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6179194]
[6209059|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6209059]
was:
Bugtraq ID [6234394|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id= 6234394]
Currently, {{LookupDiscovery}} and {{LookupLocatorDiscovery}} time out on unicast discovery requests within 1 minute of initiation (the default). This timeout value may be too short. In a pathological case with multiple discovering entities and a loaded LUS, this may result in large numbers of prematurely closed connections (characterized by large number of {{CLOSE_WAIT}} TCP connections on the LUS). Given that the LUS has accepted the request, there seems to be very little point to prematurely giving up on the request (A possible reason would be to save a thread at the discovering entity - especially in the case that the LUS host goes down or becomes inaccessible). An appropriate value for this timeout needs to be determined.
*Comments*
Coming up with a reasonable value is difficult. One possible reason for upper-bounding this timeout might be out of concern for a network disconnection long enough to absorb all of the LUS's attempts to (re)transmit the unicast response-- given that the unicast discovery protocol doesn't support an application-level ping that could be processed as aggressively as a new connection attempt currently is. Again, across server-side OSes, the relative durations should be Windows < Solaris < Linux, but all should be less than the typical two-hour TCP keepalive interval that would (if enabled) otherwise catch this condition.
*See Also*
[6179194|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6179194]
[6209059|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6209059]
Fixed broken link to Bugtraq ID
> LookupDiscovery and LookupLocatorDiscovery should have a different UnicastSocketTimeout
> ---------------------------------------------------------------------------------------
>
> Key: RIVER-74
> URL: https://issues.apache.org/jira/browse/RIVER-74
> Project: River
> Issue Type: Improvement
> Components: net_jini_discovery
> Reporter: Frank Barnaby
> Priority: Minor
>
> Bugtraq ID [6234394|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6234394]
> Currently, {{LookupDiscovery}} and {{LookupLocatorDiscovery}} time out on unicast discovery requests within 1 minute of initiation (the default). This timeout value may be too short. In a pathological case with multiple discovering entities and a loaded LUS, this may result in large numbers of prematurely closed connections (characterized by large number of {{CLOSE_WAIT}} TCP connections on the LUS). Given that the LUS has accepted the request, there seems to be very little point to prematurely giving up on the request (A possible reason would be to save a thread at the discovering entity - especially in the case that the LUS host goes down or becomes inaccessible). An appropriate value for this timeout needs to be determined.
> *Comments*
> Coming up with a reasonable value is difficult. One possible reason for upper-bounding this timeout might be out of concern for a network disconnection long enough to absorb all of the LUS's attempts to (re)transmit the unicast response-- given that the unicast discovery protocol doesn't support an application-level ping that could be processed as aggressively as a new connection attempt currently is. Again, across server-side OSes, the relative durations should be Windows < Solaris < Linux, but all should be less than the typical two-hour TCP keepalive interval that would (if enabled) otherwise catch this condition.
> *See Also*
> [6179194|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6179194]
> [6209059|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6209059]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.