javaee/fighterfish

Modules supporting use of OSGi by Java EE applications.

fighterfish's Issues

WAB deployed twice due to a race condition on server startup

When bundle osgi-javaee-base started during server startup it's activator starts ExtenderManager which tracks registered Extenders and starts them in turn.

When started, JavaEEExtender initializes OSGiContainer to track OSGiDeployers and to launch a DeployerAddedThread thread whenever deployer is registered. Then it opens a bundle tracker to schedule a deploy of any registered bundles as a task in a separate local thread pool.

These threads are racing to deploy bundle using deploy method of OSGiContainer. When application was first deployed by DeployerAddedThread, it skips the second deployment. In other case, when application was first deployed by the task in JavaEEExtender, it is undeployed and deployed once again.

While this should not present an issue other than a slightly longer startup for well-written applications, it can be fatal for poorly written one. For instance, any CDI beans, registered as an OSGi service and not unregistered during undeployment, become defunct; singletons that reference application scoped objects (such as ServletContext) do not work properly, etc. Beside that glassfish apparently has some issues cleaning-up OSGi services, and such application redeployment contributes to a memory leak.

This race condition also requires OsgiWebDeployer to be registered before JavaEEExtender starts. But since extenders are OSGi services defined in (usually) autostarted bundles, their launch order is platform-dependent. In case of my installation this order depends on jar-file creation order.

I was able to easily reproduce the issue on my installation by setting up one-thread breakpoint in the first line of DeployerAddedThread run method and waiting for task to deploy applications in other threads.