-
1. Re: NPE in DeployersImpl
alesj Sep 16, 2008 7:55 AM (in response to wolfc)It looks like some sort of synch issue:
if (deploy != null && deploy.isEmpty() == false) { // Create the controller contexts for (DeploymentContext context : deploy) { checkShutdown(); DeploymentControllerContext deploymentControllerContext = new DeploymentControllerContext(context, this); (A) context.getTransientAttachments().addAttachment(ControllerContext.class, deploymentControllerContext); try { controller.install(deploymentControllerContext); context.setState(DeploymentState.DEPLOYING); log.debug("Deploying " + context.getName()); if (scopeBuilder != null) context.getTransientAttachments().addAttachment(ScopeBuilder.class, scopeBuilder); if (repository != null) context.getTransientAttachments().addAttachment(MutableMetaDataRepository.class, repository); } catch (Throwable t) { // Set the error on the parent context.setState(DeploymentState.ERROR); context.setProblem(t); // Set the children to not deployed setState(context, DeploymentState.UNDEPLOYED, DeploymentState.DEPLOYING); } } // Go through the states in order ControllerStateModel states = controller.getStates(); for (ControllerState state : states) { for (DeploymentContext context : deploy) { DeploymentControllerContext deploymentControllerContext = context.getTransientAttachments().getAttachment(ControllerContext.class.getName(), DeploymentControllerContext.class); (B) ControllerState current = deploymentControllerContext.getState();
The last line here is the 621 line in DeployerImpl.
It looks like some other process 'cleaned' out the context between from (A) to (B) marks. -
2. Re: NPE in DeployersImpl
adrian.brock Sep 16, 2008 8:09 AM (in response to wolfc)This is really this issue:
https://jira.jboss.org/jira/browse/JBAS-5326
A simple fix for the current case is to just check the DeploymentControllerContext
is not null, i.e. some other thread already won the race and undeployed it.
What is really required (as discussed with Ales in Slovenia)
is that there is a lock where we don't try to (un)deploy
when somebody else is already doing stuff
(with a timeout on the lock to trap broken/deadlocked deployment code).
This code already exists within the MC controller, but there's no timeout
which would mean shutdown would wait forever in the case that some
deployment/undeployment callback does not return.
Similar issues exist in JBoss-4.x so there's nothing new in this problem,
it just remains unresolved in JBoss5 at the moment (but at least in JBoss5
it is fixable since the deployers, jmx and pojo all share the same controller model).
It also needs testing/extending for this feature:
https://jira.jboss.org/jira/browse/JBMICROCONT-327
e.g. allowing groups of unrelated dependencies to run in parallel -
3. Re: Concurrent (un)deployment
adrian.brock Sep 16, 2008 8:11 AM (in response to wolfc)I changed the title of this thread so it is easier to find for future reference.