[jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1175) ThreadlocalPool does not remove active BeanContext instances from InfinitePool

ThreadlocalPool does not remove active BeanContext instances from InfinitePool ------------------------------------------------------------------------------ Key: EJBTHREE-1175 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1175 Project: EJB 3.0 Issue Type: Bug Affects Versions: AS 4.2.2.GA Reporter: Galder Zamarreno Assigned To: Carlo de Wolf Priority: Critical I've done a mental walkthrough of StatelessInstanceInterceptor.invoke() and seems like there might be a leak: 1st ejb3 stateless invocation: call StatelessInstanceInterceptor.invoke() call pool.get() -> start ThreadlocalPool.get() // currentBeanContext is null so create new BeanContext and add it to InfinitePool.active return created BeanContext // currentBeanContext is still null upon return -> end ThreadlocalPool.get() call ejb.invokeNext(); call pool.release(ctx); -> start ThreadlocalPool.release() //currentBeanContext is null so call currentBeanContext.set(ctx); -> end ThreadlocalPool.release() end StatelessInstanceInterceptor.invoke() // created BeanContext is still in InfinitePool.active // currentBeanContext is not null now and contains the ctx created for this invocation 2nd ejb3 stateless invocation: call StatelessInstanceInterceptor.invoke() call pool.get() -> start ThreadlocalPool.get() // currentBeanContext is not null assign currentBeanContext.get to ctx set currentBeanContext to null return ctx // currentBeanContext is null upon return -> end ThreadlocalPool.get() call ejb.invokeNext(); call pool.release(ctx); -> start ThreadlocalPool.release() //currentBeanContext is null so call currentBeanContext.set(ctx); -> end ThreadlocalPool.release() end StatelessInstanceInterceptor.invoke() // BeanContext is still in InfinitePool.active // currentBeanContext is not null now and contains the ctx created for this invocation Looks to me like there's a leak as active contexts are never removed from InfinitePool.active List because currentBeanContext is always null when it the call lands on pool.release(ctx). Screenshots of the memory analysis can be found in the support case.