[ https://issues.jboss.org/browse/WFCORE-2351?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-2351: ------------------------------------------ [~soul2zimate] I think the fix is something different, although you are on the right track regarding checking if a service controller is still installed. Here's what's going on: AbstractOperationContext.processStages() before going to Stage.VERIFY calls awaitServiceContainerStability() which eventually calls ContainerStateMonitor.createContainerStateChangeReport(false). *Nothing is logged at this point* (which is deliberate), but the internal fields in ContainerStateMonitor get populated with some data. The logging at 16:54:18,810 comes from ContainerStateMonitor.logContainerStateChangesAndReset() which indirectly is called by OperationContextImpl.Step.releaseStepLocks. This is called when the operation is completing. In this case the op has rolled back, and therefore there is no unsatisfied dependency any more! But the logging at 16:54:18,810 is as if the rollback hasn't occurred. Then the next op comes along, and when it completes and reaches OperationContextImpl.Step.releaseStepLocks, that's when another report is generated that reports the "correction" that actually occurred during the rollback of the previous op. The reason you get a report after the second op is ContainerStateMonitor is not left in the correct state after the first op completes. ContainerStateMonitor.previousMissingDepSet should be empty at that point. The cause of that not being empty is that when ContainerStateMonitor.createContainerStateChangeReport is called the 2nd time in the first op, the time that produces logging, it uses the 'failed' and 'problems' sets. But those sets can contain ServiceControllers that were added over the course of execution of the op, but which are no longer installed (because the op rolled back). If they are no longer installed, they are no longer "problems" or "failed" so they should be ignored when creating the report. https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCO... does that (sorry; I kind of hide the key change behind some refactoring to use Collections.emptySet/Map where possible.) Doing that makes the bogus report after the 2nd op go away. A problem is it makes the first report at 16:54:18,810 go away as well. Perhaps that's good! Quite a few people dislike those messages; they can be quite noisy. And if the end result of the operation is that MSC has no failed services or missing dependencies, then there's nothing to report. But I'm a bit reluctant to just drop that first report. I could restore it by having the call from AbstractOperationContext.processStages() result in logging, and then the OperationContextImpl.Step.releaseStepLocks call also logs, but now reporting the "no longer missing" services. So basically the 2 log statements shown in the description, but now the 2nd one is at the right time. Having those 2 log messages right after one another is also kind of noisy, plus confusing. To reduce the confusion there would probably have to be some sort of INFO message in between saying the op is being rolled back, which helps explain the 2nd report. There would be other issue too with logging twice. For example what if a service is failed and rollback-on-runtime-failure=false is used so there's no rollback? We don't want log the same failed service twice for one op. I'll have to think whether I want that 16:54:18,810 logging even when the op rolls back. The basic point of the report is to report unusual MSC state at the end of an op, so really it's pointless to log it if the end state of the op has no unusual MSC state. The log already has ERROR messages for the missing / failed services that were detected while the op executed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)