[RIVER-260] Need to be more proactive about checking for idle connections in Endpoint implementation

• Type: Bug
• Status: Open
• Priority: Minor
• Resolution: Unresolved
• Affects Version/s: jtsk_2.0
• Component/s: net_jini_jeri
• Assignee: Unassigned
• Reporter: Thomas Vinod Johnson
• Created: 20/Aug/07 15:25
• Updated: 20/Aug/07 15:53

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.