[jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1442) Ejb3ClassloaderLeakUnitTestCase failures in AS testsuite

[Ron Sigal (JIRA)]

    [ https://jira.jboss.org/jira/browse/EJBTHREE-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12427031#action_12427031 ] 

Ron Sigal commented on EJBTHREE-1442:
-------------------------------------

I think I might see what's happening, though I don't know why the problem would suddenly appear.

In Remoting 1.x, we used to marshal objects like so:

      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();
      
Each call to ObjectOutputStream.reset() clears the HandleTable that shows up in Andrew's picture.  It also writes a TC_RESET byte to the stream, which interfered with the version byte we started writing in Remoting 2.0.  So, I changed the marshalling code to

      oos.reset();
      oos.writeObject(dataObject);
      oos.flush();
      
So HandleTable gets cleared every time except the last time, which is probably the source of the problem.  Clebert tracked the problem down on the input side (ObjectInputStream) when Brian's classloader leak test failed, and he used reflection to grab the private method ObjectInputStream.clear(), which clears HandleTable without sending the TC_RESET byte.

It looks like I should do the same on the sending ObjectOutputStream.  Make sense? 

How urgent is this?  Given that the component cutoff date is Friday, the fix probably won't make it into AS 5.0.0.CR2.



> Ejb3ClassloaderLeakUnitTestCase failures in AS testsuite
> --------------------------------------------------------
>
>                 Key: EJBTHREE-1442
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1442
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Brian Stansberry
>            Assignee: Andrew Lee Rubinger
>             Fix For: AS 5.0.0.CR2
>
>         Attachments: EJBTHREE-1442.png
>
>
> The Ejb3ClassloaderLeakUnitTestCase tests started failing on Jul 17 (see https://hudson.jboss.org/hudson/job/JBoss-AS-5.0.x-TestSuite-sun15/746/).  I ran the test with the JBoss Profiler analysis of the classloader leak enabled and found that a proxy remains bound in JNDI after bean undeploy, leaking the CL.  I will attach the classloader leak report.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira