<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Yeah, Carlo also pointed out that NCDFE is a java.lang.Error, which, as
you note, is not caught.&nbsp; 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").&nbsp; But I have mixed feelings about terminating
ServerThread in this case.&nbsp; Unlike, IOException, SocketException, etc.,
the NoClassDefFoundError doesn't suggest that the socket is no longer
usable.&nbsp; Maybe a better solution (along with fixing the classloader
problem, of course) is to use a positive timeout on the client side.<br>
<br>
-Ron<br>
<br>
Jaikiran Pai wrote:
<blockquote cite="mid:4B702A6A.90003@redhat.com" type="cite">
  <pre wrap="">The mailing list doesn't allow me to attach anything more than 500KB. So 
the log has been sent to Ron and the rest of the reply follows:

I don't think it's going to be too useful because the log level is set 
to INFO and as i mentioned in the earlier part of the mail - the logging 
itself seems to be a bit messed up. I haven't yet been able to reproduce 
this locally. The test run on our build setup  reproduces this 
consistently, so we can enable DEBUG level logging of remoting, the next 
time we start the test run.

One thing to note is that the ServerThread catches a "Exception" and 
later down the flow closes the socketwrapper:

processInvocation(socketWrapper, inputStream, outputStream);
     }
     catch (Exception ex)
     {
        if (running)
        {
           log.error(this + " exception occurred during first 
invocation", ex);
           running = false;
        }
        else
        {
           log.debug(this + " exception occurred during first 
invocation", ex);
        }
     }
....// some more code

log.debug(this + " closed socketWrapper: " + desc);


The closing of the socketwrapper will be skipped in case of "Error" like 
the NCDFE.

regards,
-Jaikiran


  </pre>
  <blockquote type="cite">
    <pre wrap="">Ron Sigal wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">In fact, ServerThread should close the socket when the attempt to 
write generates an exception.

Jaikiran, do you have a server.log?  It should have the output of

   log.debug(this + " closed socketWrapper: " + desc);

-Ron

Carlo de Wolf wrote:
      </pre>
      <blockquote type="cite">
        <pre wrap="">I also want to raise how Remoting should behave when it encounters 
such an error.
I would like to see it close the socket outright, because now the 
client goes into a hang state.

Carlo
_______________________________________________
jboss-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:jboss-development@lists.jboss.org">jboss-development@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/jboss-development">https://lists.jboss.org/mailman/listinfo/jboss-development</a>
  
        </pre>
      </blockquote>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->
_______________________________________________
jboss-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:jboss-development@lists.jboss.org">jboss-development@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/jboss-development">https://lists.jboss.org/mailman/listinfo/jboss-development</a>
  </pre>
</blockquote>
</body>
</html>