EJB timer pool has problems with OOME and workaround does too.

Request for fix of issue- EJB timer pool has problems with OOME.

Summary:
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.

A workaround is provided but this has issues too - StrictMaxPool for SFSB does not decrease Pool-Usage on bean-removal.

Summary:
When using SFSB in the old fasioned way for long life operations - not as substitution for SLSB for accessing an extended EntityManager within a short-life-period (http-request) - we mentioned several side-effects (not covered in this JIRA-entry) which we could be trace back to the default-poolclass "ThreadLocalPool". So we decided to use instead the "StrictMaxPool"-class.

Now - and this is the bug we found - we could see that the StrictMaxPool's semaphore is not decreased on SFSB-removal which leads to errors upon 1000 (our limit) SFSB has been created. We have mentioned that SFSB's removal does not call the pool's method "release" (The bean should not be reused) but the method "remove" isn't overwritten by StrictMaxPool so the semaphore is never decreased.

See related IT ticket for complete description.

A fix for either of these should suffice as the customer is stuck between the two issues.