[jira] Created: (RIVER-52) event delivery in Reggie should not impact discovery request processing and vice versa

["Jim Waldo (JIRA)" <ji...@apache.org>]

event delivery in Reggie should not impact discovery request processing and vice versa
--------------------------------------------------------------------------------------

                 Key: RIVER-52
                 URL: https://issues.apache.org/jira/browse/RIVER-52
             Project: River
          Issue Type: Improvement
          Components: com_sun_jini_reggie
    Affects Versions: jtsk_2.1
            Reporter: Jim Waldo
            Priority: Minor


Currently Reggie draws threads from the same pool to process discovery requests and to deliver event notifications;  if there is a large number of events to be delivered or if delivery of a number of events blocks for a period of time, it is possible that Reggie's response time to discovery requests will be increased; the converse is also possible where delays in processing discovery requests would cause delays in event notifications.  There are already mechanisms in place to minimize these scenarios; i.e., Reggie's thread pool can be increased and timeouts can be set on connection establishment to event listeners and multicast response servers (incidentally, it seems that a malicious or faulty event listener could still consume a thread indefinitely, which perhaps is an argument for having call-level timeouts at some point).  The question this RFE is trying to capture is whether fundamentally the two operations, processing of discovery requests and event delivery, should be isolated.  Another question is what expectation should clients have as to Reggie's response time in answering a discovery request; if, for example, Reggie is busy processing a large number of discovery requests some clients are still going to notice an increased response time even if discovery request processing is isolated from event delivery.

Another question that has come up in discussions is whether Reggie should reject discovery requests if it cannot process the request immediately, instead of queueing the request; it is not clear what advantage this would provide if Reggie has no knowledge of how long a client is willing to wait; i.e., the client may be willing to wait long enough for Reggie to process the request but Reggie would automatically reject the request forcing the client to try and establish another connection.  One could imagine Reggie rejecting a discovery request if it knows it cannot satisfy the timeout the client is willing to wait, but it seems this would require changes in the discovery protocol and gets into the QOS realm.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.