[RIVER-177] Support configurable concurrency limits on processing of connections and requests

• Type: Bug
• Status: Open
• Priority: Minor
• Resolution: Unresolved
• Component/s: net_jini_jeri
• Bugtraq ID: 6313634
• Assignee: Unassigned
• Reporter: Phil Steitz
• Created: 02/Aug/07 01:54
• Updated: 25/Aug/09 03:08

Description

Bugtraq ID 6313634

The JERI transport implementations generally attempt to process incoming client communication-- either new connections, or new requests-- with unlimited concurrency, until it is impossible to create more concurrent threads (and the VM throws an OutOfMemoryError because of that).

In order to allow for more controlled management of system behavior in the face of incoming requests beyond the intended concurrency scale, it would be useful to be able to specify limits on both the number of connections that are accepted and the number of requests dispatched-- when such a limit is exceeded, a new connection attempt or request attempt is actively rejected. Note that according to the JERI specification, dispatching of a request must not be queued indefinitely behind requests already in customer ; for related discussion, see this JINI-USERS post:

http://archives.java.sun.com/cgi-bin/wa?A2=ind0504&L=jini-users&P=33490

Such limits could be specified using system properties. One question would be whether or not the limits are shared across all the standard transport provider implementations (instead of per transport provider implementation).
Posted Date : 2005-08-19 20:13:57.0

Issue Links

• is related to: RIVER-318 JERI Performance Issues