<!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">
Uh, maybe it's 30 minutes in metric. :)<br>
<br>
Actually, we fooled you. The actual client invoker is
org.jboss.remoting.transport.socket.SocketClientInvoker, which
overrides createServerAddress():<br>
<br>
<tt> protected ServerAddress createServerAddress()<br>
{<br>
return new ServerAddress(addr.getHostAddress(), port,
enableTcpNoDelay, timeout, maxPoolSize);<br>
}<br>
<br>
</tt>"Once upon upon, in a disney far away", Tom Elrod got a request to
make Remoting suitable for micro devices without timeouts, and he broke
out MicroSocketClientInvoker from the original SocketClientInvoker. It
never went anywhere, since the requester soon disappeared, as usual.<br>
<br>
-Ron<br>
<br>
===========================<br>
<i><font class="txt"><b>Snore Wife and Some Several Dwarts</b><br>
<br>
Once upon upon in a dizney far away - say three hundred year agoal if
you like-there lived in a sneaky forest some several dwarts or cretins;
all named - Sleezy, Grumpty, Sneeky, Dog, Smirkey, Alice? Derick - and
Wimpey. Anyway they
all dug about in a diamond mind, which was rich beyond compere. Every
day when they came hulme from wirk, they would sing a song - just like
ordinary wirkers - the song went something like - 'Yo, ho! Yo, ho! it's
off to wirk we go!' -
which is silly really considerable they were comeing hulme. (Perhaps
ther was slight housework to be do.)<br>
One day howitzer they (Dwarts) arrived home, at aprodestant six
o'cloth, and who? - who do they find? - but only Snore Wife, asleep in
Grumpty's bed. He didn't seem to mine. 'Sambody's been feeding my
porrage!' screams Wimpey, who was wearing a light blue pullover.
Meanwife in a grand Carstle, not so a mile
away, a womand is looging in her daily mirror shouting, 'Mirror mirror
on the wall, whom is de fairy in the land.' which doesn't even rhyme.
'Cassandle!' answers the mirror. 'Chirsh O'Malley' studders the womand
who appears to be a Queen or a witch or an acorn.<br>
<br>
-</font></i><font class="txt">John Lennon, <i>A Spaniard in the Works<br>
<br>
</i></font><br>
Jaikiran Pai wrote:
<blockquote cite="mid:4B7E804B.4060802@redhat.com" type="cite">The
testcase has been hung since more than 3 days, now :) So looks like
that default client timeout of 30 minutes isn't being honoured. By the
way, EJB3 uses its own config file for remoting JBOSS_HOME/server/<
servername>/deploy/ejb3-connectors-jboss-beans.xml. But that's
irrelevant since the defaults should apply to any remoting config
irrespective of which file it's configured in.
<br>
<br>
So I looked at this in a bit more detail and it now appears to be a bug
in JBoss Remoting. Here's what's happening:
<br>
<br>
- A EJB3 client interceptor
(org.jboss.aspects.remoting.InvokeRemoteInterceptor) responsible for
invoking the remote EJB container does a remoting call:
<br>
<br>
InvokerLocator locator =
(InvokerLocator)invocation.getMetaData(REMOTING, INVOKER_LOCATOR);
<br>
...
<br>
Client client = new Client(locator, subsystem);
<br>
try
<br>
{
<br>
client.connect();
<br>
...
<br>
client.invoke(invocation, null);
<br>
<br>
- Remoting internally creates a
org.jboss.remoting.transport.socket.MicroSocketClientInvoker which
creates a ServerAddress:
<br>
<br>
protected ServerAddress createServerAddress(InetAddress addr, int port)
<br>
{
<br>
return new ServerAddress(addr.getHostAddress(), port,
enableTcpNoDelay, -1, maxPoolSize);
<br>
}
<br>
<br>
Notice the hardcoded -1 being passed to the ServerAddress. That's the
"timeout". The ServerAddress internally ignores negative timeout values
and sets the timeout to 0 (resulting in infinite timeout).
<br>
<br>
- The MicroSocketClientInvoker then ultimately ends up creating a
client socket with timeout = 0.
<br>
<br>
- So when the server side remoting thread crashes (for any unrelated
reason - like the classloading issue), the client ends up with this
infinite block.
<br>
<br>
The issues i see here:
<br>
<br>
1) I don't see a way, how i can pass a timeout for the client socket.
Contrary to the comments in remoting-jboss-beans.xml, based on what i
see in the code, it's only the server side timeout which has a
corresponding param. Did i miss something?
<br>
<br>
2) Even if there was some way of passing the client socket timeout,
currently the ServerAddress creation through MicroSocketClientInvoker
hardcodes the timeout to -1.
<br>
<br>
regards,
<br>
-Jaikiran Adrian Brock wrote:
<br>
<blockquote type="cite">On Tue, 2010-02-16 at 18:14 +0530, Jaikiran
Pai wrote:
<br>
<blockquote type="cite">Ron Sigal wrote:
<br>
<blockquote type="cite">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.
<br>
</blockquote>
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?
<br>
<br>
</blockquote>
<br>
It already exists, but whether 30 minutes is a "sensible" default
<br>
is a different issue. ;-)
<br>
<br>
See remoting-jboss-beans.xml
<br>
<br>
<!-- Socket read timeout. Defaults to 60000
ms (1 minute)
<br>
-->
<br>
<!-- on the server, 1800000 ms (30 minutes) on the
client.
<br>
-->
<br>
<!--entry><key>timeout</key>
<value>120000</value></entry-->
<br>
<br>
<br>
</blockquote>
<br>
</blockquote>
</body>
</html>