[jboss-dev] Remoting behavior on error (Re: Possible blocker with jboss-cl 2.2.0.Alpha1)

[Ron Sigal]

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".  :)

-Ron

Adrian Brock wrote:
> On Tue, 2010-02-16 at 18:14 +0530, Jaikiran Pai wrote:
>   
>> Ron Sigal wrote:
>>     
>>> 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.
>>>       
>> 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?
>>
>>     
>
> 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-->
>
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-development/attachments/20100216/4012be1e/attachment.html