river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Waldo (JIRA)" <j...@apache.org>
Subject [jira] Created: (RIVER-52) event delivery in Reggie should not impact discovery request processing and vice versa
Date Thu, 26 Jul 2007 14:24:40 GMT
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.


Mime
View raw message