[
http://jira.jboss.com/jira/browse/JBAS-4359?page=comments#action_12360323 ]
Ron Sigal commented on JBAS-4359:
---------------------------------
I don't think things would work otherwise. The socket transport writes the whole
invocation at once, so the loop goes (unrolling things a little):
ObjectOutputStream oos = ...;
ObjectInputStream ois = ...;
int version;
while (...)
{
oos.write(version);
oos.reset();
oos.writeObject(invocation);
oos.flush();
version = ois.read();
Object result = ois.readObject();
}
Fix the
org.jboss.test.classloader.leak.test.ClassloaderLeakUnitTestCase
------------------------------------------------------------------------
Key: JBAS-4359
URL:
http://jira.jboss.com/jira/browse/JBAS-4359
Project: JBoss Application Server
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: Test Suite
Reporter: Dimitris Andreadis
Assigned To: Ron Sigal
Priority: Blocker
Fix For: JBossAS-4.2.0.GA
Attachments: apr212007.zip, JavaSerializationManager.java,
ObjectInputStreamWithClassLoader.java, RawTestCase.output
Brian, did the initial analysis for the failure:
"The classloader leak test timing out is basically due to a failure; different tests
in the class are all encountering the same leak and taking time trying to force a release,
so it times out.
The failure is on a remote ejb2 sfsb invocation. Not sure, but think it's related to
the Remoting upgrade.
I've attached a JBoss Profiler report showing refs to the leaked classloader. This
one's long and complicated, but I think the relevant stuff is right at the start. The
MarshalledInvocation seems to be leaking to the input stream and from there into a thread
pool.
I switched my build back to Remoting 2.0.0 and the test passed."
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira