ConcreteResourceRegistration#registerSubModel is not thread safe

The ConcreteResourceRegistration#registerSubModel method does not handle concurrency correctly. It exposes the new child ManagementResourceRegistration in the registry and then makes the calls that register the MRR's attributes, operations and children. The result is an incompletely populated MRR is briefly visible to other threads. This results in failures if those other threads assume that the MRR is populated.

This has resulted in intermittent failures in the WildFly testsuite, notably in a test where a deployment includes multiple rars and those rars are manipulating the MRR tree as part of service start. There are multiple rars so multiple services, and MSC is concurrent so there's concurrent MRR initialization. For example:

http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=75813&tab=buildResultsDiv&buildTypeId=MasterWindows

05:18:46,317 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.ra.deployer."ear_packaged.ear#ear_packaged2.rar".jboss.ironjacamar.resource: org.jboss.msc.service.StartException in service jboss.ra.deployer."ear_packaged.ear#ear_packaged2.rar".jboss.ironjacamar.resource: Failed to start service
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
    at org.jboss.as.connector.services.resourceadapters.IronJacamarActivationResourceService.start(IronJacamarActivationResourceService.java:196)
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
    ... 3 more

The failing code is:

ManagementResourceRegistration cdRegistration = raRegistration.getSubModel(PathAddress.pathAddress(peCD));
ManagementResourceRegistration overrideCdRegistration = cdRegistration.registerOverrideModel(cm.getJndiName(), new OverrideDescriptionProvider() {

Dereferencing cdRegistration throws the NPE. It's null because raRegistration is a ref to an incompletely populated MRR.

I found another failure of that test, and it was in a different spot in IronJacamarActivationResourceService but the same basic pattern – getSubModel is called on an MRR and it unexpectedly returns null.

End users who include multiple rars in their deployment might experience an equivalent failure. There also may be other places in the EAP code that have a similar pattern. I would not be surprised if including multiple ds.xml files in a deployment would have the same problem, as the r-a subsystem and datasource have similar patterns in how they are using the ManagementResourceRegistration tree to register vendor-specific overrides. The failures in the testsuite are related to that handling.