geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quintin Beukes <>
Subject Bug in @Startup annotations found - anyone have a possible solution?
Date Wed, 21 Oct 2009 14:06:53 GMT

I found why @Startup causes a deadlock for Singleton beans.

When a bean is annotated with @Startup, at the end of
SingletonContainer.deploy(DeploymentInfo) the following block is
        if (deploymentInfo.isLoadOnStartup()){
            try {
                ThreadContext callContext = new
ThreadContext(deploymentInfo, null);
                ThreadContext old = ThreadContext.enter(callContext);
                try {
                } finally{
            } catch (OpenEJBException e) {
                throw new OpenEJBException("Singleton startup failed:
"+deploymentInfo.getDeploymentID(), e);

Now, threadContext.enter() calls all
ThreadContextListener.contextEntered() methods, which is only
GeronimoThreadContextListener. This class has a the following:
         synchronized (deploymentInfo) {
                if (deploymentInfo.get(EjbDeployment.class) == null) {
                    if (!deploymentInfo.isDestroyed()) {
                        try {
                        } catch (InterruptedException e) {
                        log.warn("Wait on deploymentInfo interrupted

At this point deploymentInfo.get(EjbDeployment.class) returns null,
because it only gets set AFTER the bean has been deployed
(Container.deploy()) returns. Since it's null, and it's not
"destroyed", it goes into a wait() on deploymentInfo, which never
finished and thus holds up thread. From the point onwards OpenEJB's
deployer is held up, and you can continue/deploy/undeploy.

Anyone have a suggestion for how to fix this?

It could be possible to NOT do the isLoadOnStartup() code inside the
SingletonContainer.deploy() method, and execute it at some later time?
Or since a .notifyAll() is called when EjbDeployment.class is set on
the DeploymentInfo object, one could perhaps fork the
isLoadOnStartup() code to an alternative thread? This seems ugly

Alternatively one could execute the isLoadOnStartup() code at a later
time (only after the EjbDeployment.class has been set). Though at
first glance I could find a place to put this code which would leave
OpenEJB's code independent as well as provide the facility to

Any ideas would be appreciated.

Quintin Beukes

View raw message