[
http://jira.jboss.com/jira/browse/EJBTHREE-1175?page=comments#action_1240... ]
Carlo de Wolf commented on EJBTHREE-1175:
-----------------------------------------
CAVEAT: For beans using the EJB timer service the thread local pool should not be used.
Since the current EJB timer service creates a new thread for each timer being created, the
thread local pool will create a matching instance of the bean for that thread. Thus the
number of active instances in total can effectively grow unchecked and thus an OOM will
occur.
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