[
https://jira.jboss.org/jira/browse/EJBTHREE-1330?page=com.atlassian.jira....
]
Alexander Bollaert commented on EJBTHREE-1330:
----------------------------------------------
AFAIK the workaround specified here just limits the number of corresponding EJB instances.
It does not limit the number of timer threads and hence, if you have enough timers (a
couple of thousands), it will OOM because it cannot allocate a stack for the newly created
native thread.
This would mean that the current implementation severely limits scalability (I've been
looking in the source code of 5.0.0.GA and it still uses a java.util.Timer per EJB timer
scheduling). Maybe it would be best if there is an alternative implementation that uses a
ScheduledExecutorService with an adjustable pool size. This would at least prevent the
unbounded thread creation problem the Timers exhibit now.
EJB timer service should use a thread pool to avoid OOM
-------------------------------------------------------
Key: EJBTHREE-1330
URL:
https://jira.jboss.org/jira/browse/EJBTHREE-1330
Project: EJB 3.0
Issue Type: Bug
Components: pool
Affects Versions: AS 4.2.2.GA, AS 5.0.0.Beta4
Reporter: Galder ZamarreƱo
Assignee: Galder ZamarreƱo
Priority: Minor
The default EJB timer service used by the EJB3 layer is based on
org.jboss.ejb3.timerservice.jboss.JBossTimerServiceFactory which delegates
to the standard org.jboss.ejb.txtimer.EJBTimerService.
For EJB3 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.
--
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