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

[Carlo de Wolf (JIRA)]

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1175?page=comments#action_12404410 ] 
            
Carlo de Wolf commented on EJBTHREE-1175:
-----------------------------------------

The scenario sketched above does not constitute a bug. currentBeanContext can contain 1 method-ready instance. The backing infinite pool contains all instances in use (in case a bean is called recursively).
During a method call currentBeanContext is null (there is no method-ready instance). Any get done during that time will immediately be delegated to the infinite pool.
After the method call the bean is placed back in the currentBeanContext or removed by the infinite pool.
Thus thread local pool constitutes a 1 instance method-ready pool without any sizing restriction.

> 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 5.0.0.Beta3, AS 4.2.2.GA
>            Reporter: Galder Zamarreno
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>             Fix For: AS 5.0.0.CR1
>
>
> 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.

-- 
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