[
http://jira.jboss.com/jira/browse/JBAS-4359?page=comments#action_12360320 ]
Ron Sigal commented on JBAS-4359:
---------------------------------
The Remoting test suite has finished, and the RawTestCase is the only problem. The only
difference between the "fake" Remoting client invoker and the real one (using
the JavaSerializationManager) is that the latter writes a TC_RESET byte before writing
each object. When I updated RawTestCase to write a TC_RESET byte, it works.
So, I'll put a new jboss-remoting.jar in the repository.
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