<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On the grounds that the socket transport descends from the
PooledInvoker, and assuming that no one will bother checking, I just
say, whenever anything odd surfaces, "Blame Bill Burke". :)<br>
<br>
-Ron<br>
<br>
Adrian Brock wrote:
<blockquote cite="mid:1266326414.2015.24.camel@localhost" type="cite">
<pre wrap="">On Tue, 2010-02-16 at 18:14 +0530, Jaikiran Pai wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Ron Sigal wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Yeah, Carlo also pointed out that NCDFE is a java.lang.Error, which,
as you note, is not caught. I agree that if ServerThread is going to
terminate due to an error, then it should certainly close its socket,
so that's a bug (JBREM-1183 "ServerThread should catch
java.lang.Error"). But I have mixed feelings about terminating
ServerThread in this case. Unlike, IOException, SocketException,
etc., the NoClassDefFoundError doesn't suggest that the socket is no
longer usable. Maybe a better solution (along with fixing the
classloader problem, of course) is to use a positive timeout on the
client side.
</pre>
</blockquote>
<pre wrap="">I think some (sensible) default timeout needs to be added so that the
client does not end up hung. Is this something that can be added to some
*-jboss-beans.xml in the AS?
</pre>
</blockquote>
<pre wrap=""><!---->
It already exists, but whether 30 minutes is a "sensible" default
is a different issue. ;-)
See remoting-jboss-beans.xml
<!-- Socket read timeout. Defaults to 60000 ms (1 minute)
-->
<!-- on the server, 1800000 ms (30 minutes) on the client.
-->
<!--entry><key>timeout</key> <value>120000</value></entry-->
</pre>
</blockquote>
</body>
</html>