IllegalThreadState thrown from WeakReferenceMonitor

[davidkarlsen]

Hi!

I'm extending AbstractStatelessSessionBean and setting this in the
setSessionContext(Context ctx){
super.setSessionContext(ctx);
setBeanFactoryLocator( ContextSingletonBeanFactoryLocatorgetInstance() );
setBeanFactoryLocatorKey("application-context");
}

which should be best-practice when using stateless beans inside my EJB.


But I notice that WeakReferenceMonitor is spawning threads - which really isn't allowed inside an EJB container. I must say I'm a little surprised that a framework like this is breaking the container rules in such a brutal way.
:shock:

The stack trace from an ejbCreate():

com.ibm.ejs.container.CreateFailureException: ; nested exception is:
java.lang.reflect.InvocationTargetException
java.lang.reflect.InvocationTargetException: java.lang.IllegalThreadStateException
at java.lang.Thread.start(Native Method)
at org.springframework.util.WeakReferenceMonitor.addE ntry(WeakReferenceMonitor.java:94)
at org.springframework.util.WeakReferenceMonitor.moni tor(WeakReferenceMonitor.java:78)
at org.springframework.ejb.support.AbstractEnterprise Bean.loadBeanFactory(AbstractEnterpriseBean.java:1 29)
at org.springframework.ejb.support.AbstractStatelessS essionBean.ejbCreate(AbstractStatelessSessionBean. java:63)
at java.lang.reflect.Method.invoke(Native Method)
at com.ibm.ejs.container.StatelessBeanO.<init>(Statel essBeanO.java:132)
at com.ibm.ejs.container.CMStatelessBeanO.<init>(CMSt atelessBeanO.java:53)
at com.ibm.ejs.container.CMStatelessBeanOFactory.crea te(CMStatelessBeanOFactory.java:40)
at com.ibm.ejs.container.EJSHome.createBeanO(EJSHome. java:586)
at com.ibm.ejs.container.EJSHome.createBeanO(EJSHome. java:673)
at com.ibm.ejs.container.activator.UncachedActivation Strategy.atActivate(UncachedActivationStrategy.jav a:78)
at com.ibm.ejs.container.activator.Activator.activate Bean(Activator.java:516)
at com.ibm.ejs.container.EJSContainer.preInvoke_inter nal(EJSContainer.java:2609)
at com.ibm.ejs.container.EJSContainer.preInvoke(EJSCo ntainer.java:2337)
at com.ibm.ejs.container.EJSContainer.removeBean(EJSC ontainer.java:2006)
at com.ibm.ejs.container.EJSWrapper.remove(EJSWrapper .java:184)
at no.dnbnor.crg.server.func.ejb._EJSRemoteStatelessC RGService_692891ba_Tie.remove(_EJSRemoteStatelessC RGService_692891ba_Tie.java:125)
at no.dnbnor.crg.server.func.ejb._EJSRemoteStatelessC RGService_692891ba_Tie._invoke(_EJSRemoteStateless CRGService_692891ba_Tie.java:86)
at com.ibm.CORBA.iiop.ServerDelegate.dispatchInvokeHa ndler(ServerDelegate.java:615)
at com.ibm.CORBA.iiop.ServerDelegate.dispatch(ServerD elegate.java:468)
at com.ibm.rmi.iiop.ORB.process(ORB.java:396)
at com.ibm.CORBA.iiop.ORB.process(ORB.java:1608)
at com.ibm.rmi.iiop.Connection.doWork(Connection.java :2164)
at com.ibm.rmi.iiop.WorkUnitImpl.doWork(WorkUnitImpl. java:63)
at com.ibm.ejs.oa.pool.PooledThread.run(ThreadPool.ja va:95)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.j ava:593)
<< END server: 1198777258 at host localhost

What are my options for avoiding the spawned thread (and thus inncorrect behaviour in the container)?

[Andreas Senft]

But I notice that WeakReferenceMonitor is spawning threads - which really isn't allowed inside an EJB container. I must say I'm a little surprised that a framework like this is breaking the container rules in such a brutal way.

Afaik this is actually used to get around some shortcomings when working with EJB containers.
As of container rules: Generally one should not violate them carelessly. But you should be pragmatic enough to decide when it's time to do so.

Concerning your problem: It looks like several threads are trying to start the monitoring thread simultaneously, causing this issue. I guess some synchronisation is required to resolve this issue. Therefore I suggest to create a JIRA issue for this (if none already exists).

Regards,
Andreas

[davidkarlsen]

Added

http://opensource2.atlassian.com/pro...rowse/SPR-1364

hope this will be fixed quickly as I have to throw Spring out if not.