Rmi method call timeout

Question

i was wondering if there was any way to timeout a rmi method call.
the situation i had was that a client would envoke an rmi method, and
the method would deadlock in weblogic. the client making the call will
hang forever.
thanks

Answer 1

Thank you for this enlightening addition. I regret I failed to perceive
earlier that your comments were to be interpreted as evidence of sincere
commitment to solving this problem.
Regarding 7.0, you'll note that I described the timeout attribute solution
as "improving stability" rather than as a complete cure. It should be borne
bear in mind that this is an alternative to a completely locked system. When
stress tested, this change did allow the application to recover and run for
the rest of the day.
I'm obliged to you for your concern regarding any liability I might be
incurring in relation to the BEA licensing agreement. Fortunately I think I
may be able to put your mind at rest on this matter relatively easily. If I
may direct your attention to the BEA support site, my experience is that on
entering the search terms "rmi descriptor timeout", the relevant information
will be revealed. Also, I suspect that, as a fellow engineer, it has not
escaped your attention that the RMI descriptor is a valid XML document. As
such, it has a DTD named "rmi.dtd" which (alas) also fails to conceal this
attribute.
While we're pursuing what has now become a gratifyingly productive vein,
let's offer another possible approach to this issue, namely the use of
per-VM timeouts for socket calls. These were introduced in the Sun JDK 1.4.1
and so are available to people running WebLogic 8.1 today. Again these
suggestions have been tested for basic socket I/O (I haven't tried RMI). To
my knowledge these are not endorsed by BEA:
For client connections, timeouts can be set globally by passing the
following startup parameters to the JVM:
sun.net.client.defaultConnectTimeout (default: -1)
sun.net.client.defaultReadTimeout (default: -1)
sun.net.client.defaultConnectTimeout specifies the timeout (in milliseconds)
to establish the connection to the host.
sun.net.client.defaultReadTimeout specifies the timeout (in milliseconds)
when reading from input stream when a connection is established to a
resource.
(reference: Sun's Networking Properties documentation at
http://java.sun.com/j2se/1.4.1/docs/guide/net/properties.html )
Supplying non-default values for these properties should allow a server to
recover from a blocked downstream system if socket I/O is being used.
Regards
Alex
On Fri, 30 Jan 2004 09:02:23 -0800, Andy Piper <[email protected]>
wrote:
Alex Thomas <[email protected]> writes:
Hardly a constructive response to what is clearly a significant problem.
First, it should be obvious that this issue will be encountered in any
distributed system using T3 or RMI, not because of any shortcoming in
WebLogic services but because of blocking behaviour in downstream systems.That's why it is a new feature in 9.0. I'm not arguing that the
use-case is invalid, simply that your suggestion should not be tried.
Second, the solution I proposed has been tested (on 7.0SP1) and does improve
overall stability, as other people here have apparently discovered.Tested by who? Not by us because we know there are significant,
dangerous, problems with the approach you describe. Support are
under strict instructions not to offer this as a solution to
anyone. If anyone in BEA told you, they shouldn't have. If you
discovered it by decompiling the code then you are in violation of
your license agreement.
There is a supported mechanism for timing out connect attempts in 7.0
and later which you can get through support, but for timing out RMI
calls you will have to wait until 9.0 (or cook up a business case for
a backport).
Hope this clears things up.
andy