[jboss-jira] [JBoss JIRA] Commented: (JBAS-4359) Fix the org.jboss.test.classloader.leak.test.ClassloaderLeakUnitTestCase

[Clebert Suconic (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBAS-4359?page=comments#action_12360300 ] 
            
Clebert Suconic commented on JBAS-4359:
---------------------------------------

The issue is that remoting now will aways keep the last invocation objects on the memory, until the next invocation or until the invoker is down.

This was changed on the protocol.. .Remoting used to aways clear its object through a object.clear/object.writeDumbObject.

This was changed on remoting marshallers now:

>From Remoting marshallers:

   public void sendObject(ObjectOutputStream oos, Object dataObject) throws IOException
   {
      oos.reset();
      oos.writeObject(dataObject);
//      oos.reset();
      // to make sure stream gets reset
      // Stupid ObjectInputStream holds object graph
      // can only be set by the client/server sending a TC_RESET
//      oos.writeObject(Boolean.TRUE);
      oos.flush();
//      oos.reset();
   }



So... a fix would be either to change the testcase to send another message dumb message after the ejb test.

Or to hack remoting code to clear ObjectInputStream without changing binary format.


Dimitris.. I would like to talk to you about this. If you could call me over e-mail, telephone,  smoke sign, telepathy, IM or any other way you like :-)

> 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: Clebert Suconic
>            Priority: Blocker
>             Fix For: JBossAS-4.2.0.GA
>
>         Attachments: apr212007.zip
>
>
> 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