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/20 17:27:30 UTC
[jira] Created: (RIVER-260) Need to be more proactive about
checking for idle connections in Endpoint implementation
Need to be more proactive about checking for idle connections in Endpoint implementation
----------------------------------------------------------------------------------------
Key: RIVER-260
URL: https://issues.apache.org/jira/browse/RIVER-260
Project: River
Issue Type: Bug
Components: net_jini_jeri
Affects Versions: jtsk_2.0
Reporter: Thomas Vinod Johnson
Priority: Minor
All the client Endpoint implementations support idle connections that may be reused, provided any applicable idle timeout has not expired. The check for expiry and subsequent cleanup is done in separate reaper/timeout handler threads. However, there is no proactive check being done by the endpoints at the point of newRequest creation. In the event that the reaper threads have not been scheduled in a timely manner (general scheduling delays, process suspension as in the case of debugging) it is possible to end up reusing idle connections which should have been timed out, possibly resulting in remote call failure.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (RIVER-260) Need to be more proactive about
checking for idle connections in Endpoint implementation
Posted by "Thomas Vinod Johnson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Vinod Johnson updated RIVER-260:
---------------------------------------
Description:
All the client Endpoint implementations support idle connections that may be reused, provided any applicable idle timeout has not expired. The check for expiry and subsequent cleanup is done in separate reaper/timeout handler threads. However, there is no proactive check being done by the endpoints at the point of newRequest creation. In the event that the reaper threads have not been scheduled in a timely manner (general scheduling delays, process suspension as in the case of debugging) it is possible to end up reusing idle connections which should have been timed out, possibly resulting in remote call failure.
The main effect is in the case of Http(s)Endpoint where the server side may timeout the connection, while the client side does not. The resulting exception is seen as indefinite and the remote operations fails without being able to retry.
The mux-protocol endpoints don't actually have server-side idle connection timeouts in their current implementations; (they really
should), but the protocol does support indicating clean closure of the connection so that the client can retry safely.
was:
All the client Endpoint implementations support idle connections that may be reused, provided any applicable idle timeout has not expired. The check for expiry and subsequent cleanup is done in separate reaper/timeout handler threads. However, there is no proactive check being done by the endpoints at the point of newRequest creation. In the event that the reaper threads have not been scheduled in a timely manner (general scheduling delays, process suspension as in the case of debugging) it is possible to end up reusing idle connections which should have been timed out, possibly resulting in remote call failure.
> Need to be more proactive about checking for idle connections in Endpoint implementation
> ----------------------------------------------------------------------------------------
>
> Key: RIVER-260
> URL: https://issues.apache.org/jira/browse/RIVER-260
> Project: River
> Issue Type: Bug
> Components: net_jini_jeri
> Affects Versions: jtsk_2.0
> Reporter: Thomas Vinod Johnson
> Priority: Minor
>
> All the client Endpoint implementations support idle connections that may be reused, provided any applicable idle timeout has not expired. The check for expiry and subsequent cleanup is done in separate reaper/timeout handler threads. However, there is no proactive check being done by the endpoints at the point of newRequest creation. In the event that the reaper threads have not been scheduled in a timely manner (general scheduling delays, process suspension as in the case of debugging) it is possible to end up reusing idle connections which should have been timed out, possibly resulting in remote call failure.
> The main effect is in the case of Http(s)Endpoint where the server side may timeout the connection, while the client side does not. The resulting exception is seen as indefinite and the remote operations fails without being able to retry.
> The mux-protocol endpoints don't actually have server-side idle connection timeouts in their current implementations; (they really
> should), but the protocol does support indicating clean closure of the connection so that the client can retry safely.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.