river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Brouwer (JIRA)" <j...@apache.org>
Subject [jira] Commented: (RIVER-275) implement RoundTripTimeout constraint
Date Thu, 13 Dec 2007 16:04:43 GMT

    [ https://issues.apache.org/jira/browse/RIVER-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551545

Mark Brouwer commented on RIVER-275:

Such a constraint would also prevent from calling threads in the client hanging forever in
case the server thread dealing with the request deadlocks, commenter has experience with cases
where deadlocks at the server crippled the client beyond what could be seen as acceptable.
Although one can argue that deadlocks at the server are a bug, I believe that one of the concepts
of Jini is that implementation of the business interface can differ and as such one should
also have a mechanism that can protect one against those implementation that aren't excellent

For more information related to this subject see a summary of a past discussion [here|http://archives.java.sun.com/cgi-bin/wa?A2=ind0712&L=JINI-USERS&D=0&T=0&P=62].

Interesting in the above case is whether the server should be aware of the timeout constraint
as well, that e.g. if that time has elapsed it should also check whether the thread associated
with executing the remote method is in a deadlock (possible with Java SE 1.6) although that
can be an expensive operation. If the cause for the timeout is due to e.g. an overloaded system
such a check would derail the system further, nevertheless logging at the server side can
be useful in case of a timeout.

> implement RoundTripTimeout constraint
> -------------------------------------
>                 Key: RIVER-275
>                 URL: https://issues.apache.org/jira/browse/RIVER-275
>             Project: River
>          Issue Type: New Feature
>          Components: net_jini_core
>            Reporter: Martin Cornelius
> In realtime scenarios it is often desirable to know, if a remote call can be executed
within a certain duration, that is specified by the caller before making the call. If the
complete call cannot be executed within the specified duration, it should return to the calling
thread with an indication that a timeout occured.
> In CORBA terminology this feature is called the RoundTripTimeout Policy. It would be
nice to have something similar in JINI. A possible implementation could be a new invocation
constraint class, perhaps named net.jini.core.constraint.RoundTripRelativeTime. This class
could implement the same interfaces as net.jini.core.constraint.ConnectionRelativeTime, and
could also have a constructor taking the desired timeout as argument.

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

View raw message