[EMAIL PROTECTED] wrote : Show more of the log to establish the context.
Based on the loadClassDepth=9604 this is in the process of causing a stack
overflow so there is nothing like that error in the server.log?
|
No, the server log mentions neither stack nor overflow or the like. The error
I switched on ucl logging after the error reoccurred and repeated the test
case. (I didn't log the first occurrence with ucl logging.)
The result is a bit disappointing, because it is apparently indeed StringBuffer
that can't be found. I am getting hundreds of lines like these in ucl.log:
[EMAIL PROTECTED] wrote : See the following for enabling trace level logging
of the class loading categories:
| [...]
|
OK, I have activated ucl logging. I'll get back to you if I find anything.
View the original post :
[EMAIL PROTECTED] wrote : Without more details I have no idea. Class loading
configuration, full error stack trace is a starting point.
The problem reappeared just now.
As to the settings:
I didn't change any of the global settings of JBoss except activating TRACE in
log4j.xml. (I don' t even
I got this error here today from a Cactus test case in JBoss (4.0.3SP1):
java.lang.NoClassDefFoundError: java/lang/StringBuffer
IMHO it is impossible that a class in java.lang cannot be found.
The strange thing is that this error occurs in one specific line of code that
resembles hundreds of
kannaiyanbalaji wrote :
| java.rmi.server.ExportException: Port already in use: 1098; nested
exception is:
| java.net.BindException: Address already in use: JVM_Bind
|
You don't need to move JBoss to a different port. It is sufficient and maybe
even better to reserve some ports
genman wrote : How do you know it is not network latency?
A ping to the AS takes less than 0.1 ms. And other services on the AS (JBoss
and non-JBoss) respond much faster. And it's independent on whether the client
is local or remote.
genman wrote : There a profiling tools to tell you what it's
I did some tests with SOAP and JBoss 4.0.2 and it seems that a SOAP call to a
stateless SessionBean takes at least 20 ms (if the SessionBean itself does
nothing except for an empty method call).
This is astonishingly independent of the environment: Whether I use a 1GHz
single CPU PC or a 3GHz
