[jboss-jira] [JBoss JIRA] (WFCORE-3948) Potential race condition on deployment of EAR when Class-Path manifest entry is in use

Brian Stansberry (Jira) issues at jboss.org
Tue Sep 24 16:45:00 EDT 2019


    [ https://issues.jboss.org/browse/WFCORE-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13788683#comment-13788683 ] 

Brian Stansberry commented on WFCORE-3948:
------------------------------------------

The following is just information, no solution.

Here are the uses of ADDITIONAL_MODULES, per IDEA, annotated by me with the Phase n which each DUP runs:

{code}
Field
    ADDITIONAL_MODULES
Found usages  (10 usages found)
    Value read  (10 usages found)
        wildfly-server  (10 usages found)
            org.jboss.as.server.deployment.annotation  (1 usage found)
PARSE                CompositeIndexProcessor  (1 usage found)
                    deploy(DeploymentPhaseContext)  (1 usage found)
                        79 for(AdditionalModuleSpecification i : top.getAttachmentList(Attachments.ADDITIONAL_MODULES)) {
            org.jboss.as.server.deployment.module  (7 usages found)
STRUCTURE                ManifestClassPathProcessor  (2 usages found)
                    deploy(DeploymentPhaseContext)  (1 usage found)
                        132 for (AdditionalModuleSpecification module : topLevelDeployment.getAttachmentList(Attachments.ADDITIONAL_MODULES)) {
                    createAdditionalModule(ResourceRoot, DeploymentUnit, VirtualFile, Map<VirtualFile, AdditionalModuleSpecification>, VirtualFile, ArrayDeque<RootEntry>)  (1 usage found)
                        228 topLevelDeployment.addToAttachmentList(Attachments.ADDITIONAL_MODULES, module);
STRUCTURE                ManifestDependencyProcessor  (1 usage found)
                    deploy(DeploymentPhaseContext)  (1 usage found)
                        73 for(AdditionalModuleSpecification i : top.getAttachmentList(Attachments.ADDITIONAL_MODULES)) {
DEPENDENCIES                ModuleClassPathProcessor  (1 usage found)
                    deploy(DeploymentPhaseContext)  (1 usage found)
                        57 final List<AdditionalModuleSpecification> additionalModules = deploymentUnit.getAttachment(Attachments.ADDITIONAL_MODULES);
DEPENDENCIES                ModuleExtensionListProcessor  (1 usage found)
                    deploy(DeploymentPhaseContext)  (1 usage found)
                        112 final List<AdditionalModuleSpecification> additionalModules = deploymentUnit.getAttachment(Attachments.ADDITIONAL_MODULES);
CONFIGURE_MODULE                ModuleSpecProcessor  (1 usage found)
                    deployModuleSpec(DeploymentPhaseContext)  (1 usage found)
                        143 final List<AdditionalModuleSpecification> additionalModules = deploymentUnit.getAttachmentList(Attachments.ADDITIONAL_MODULES);
DEPENDENCIES                SubDeploymentDependencyProcessor  (1 usage found)
                    deploy(DeploymentPhaseContext)  (1 usage found)
                        66 for (AdditionalModuleSpecification module : deploymentUnit.getAttachmentList(Attachments.ADDITIONAL_MODULES)) {
            org.jboss.as.server.deployment.module.descriptor  (2 usages found)
STRUCTURE                DeploymentStructureDescriptorParser  (2 usages found)
                    deploy(DeploymentPhaseContext)  (2 usages found)
                        134 for(AdditionalModuleSpecification i : deploymentUnit.getParent().getAttachmentList(Attachments.ADDITIONAL_MODULES)) {
                        188 deploymentUnit.addToAttachmentList(Attachments.ADDITIONAL_MODULES, additional);
{code}

So, ManifestClassPathProcessor, ManifestDependencyProcessor and DeploymentStructureDescriptorParser are relevant as they execute in the STRUCTURE phase where writes occur.

Here's the relevant bit from ServerService that shows their relative execution order:

{code}
DeployerChainAddHandler.addDeploymentProcessor(SERVER_NAME, Phase.STRUCTURE, Phase.STRUCTURE_SUB_DEPLOYMENT, new SubDeploymentProcessor());
            ...
            DeployerChainAddHandler.addDeploymentProcessor(SERVER_NAME, Phase.STRUCTURE, Phase.STRUCTURE_JBOSS_DEPLOYMENT_STRUCTURE, new DeploymentStructureDescriptorParser());
            DeployerChainAddHandler.addDeploymentProcessor(SERVER_NAME, Phase.STRUCTURE, Phase.STRUCTURE_CLASS_PATH, new ManifestClassPathProcessor());
            ...
            DeployerChainAddHandler.addDeploymentProcessor(SERVER_NAME, Phase.STRUCTURE, Phase.STRUCTURE_DEPENDENCIES_MANIFEST, new ManifestDependencyProcessor());
{code}

I start with SubDeploymentProcessor because it's the one that creates the SubDeploymentUnitService instances for the subdeployments, which in turn starts and create the parallel DUP execution.

So this seems problematic, e.g. DeploymentStructureDescriptorParser is reading ADDITIONAL_MODULES on behalf of subdeployments, assuming it's correctly populated, but that may not have occurred, even for the top level deployment. The DeploymentStructureDescriptorParser may not have run yet for the root deployment, or it may have *and* ManifestClassPathProcessor may have run for the root and one or more sibling subdeployments. Or not.

And then the execution of ManifestDependencyProcessor is just a race amongst them all.

> Potential race condition on deployment of EAR when Class-Path manifest entry is in use
> --------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3948
>                 URL: https://issues.jboss.org/browse/WFCORE-3948
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>            Reporter: Stuart Douglas
>            Priority: Major
>
> Attachments#ADDITIONAL_MODULES is attached to the top level DU, but modified by sub deployments in ManifestClassPathProcessor#createAdditionalModule without any sort of synchronisation. This can result in ConcurrentModificationException when the list is read/written to by other sub deployments at the same time.



--
This message was sent by Atlassian Jira
(v7.13.8#713008)


More information about the jboss-jira mailing list