river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank Barnaby (JIRA)" <j...@apache.org>
Subject [jira] Updated: (RIVER-74) LookupDiscovery and LookupLocatorDiscovery should have a different UnicastSocketTimeout
Date Thu, 26 Jul 2007 19:48:03 GMT

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


Mime
View raw message