Bug 997583

Brian Stansberry <brian.stansberry> made a comment on jira WFLY-1305

It's not undeployed because the management ops created by the scanner are inserted into the list of boot ops, and boot ops do not roll back on failure.

I'm not sure why the .deployed file is written instead of a .failed file, since even though the ops don't roll back, they still failed. Figuring that out will hopefully point to an overall solution.

Chao Wang <chaowan> made a comment on jira WFLY-1305

As example in attached file, one of the composite ops "add" in step-1 comes out "success", without roll-back the overall outcome is success.

Brian Stansberry <brian.stansberry> made a comment on jira WFLY-1305

I assume the "RESULT" section in the attached operation-outcome.xml is what is assigned to var 'result' at FileSystemDeploymentService L423.

So the problem is

"result" => {"step-1" => {
        "outcome" => "success"

The operation is actually a composite of composites. So that "step-1" is itself a composite. And it is being marked as "success" even though one of *it's* steps failed:

           "step-2" => {
                "outcome" => "failed",
                "failure-description" => {"JBAS014671: Failed services" => {"jboss.module.service.\"deployment.test.war\".main" => "org.jboss.msc.service.StartException in service jboss.module.service.\"deployment.test.war\".main: JBAS018759: Failed to load module: deployment.test.war:main
    Caused by: org.jboss.modules.ModuleNotFoundException: aaa.bbb:1.0"}}
            }

This happens because CompositeOperationHandler only marks the composite operation as "failed" if rollback occurs. I have a vague memory that that's by design; I'll need to do some research.

FileSystemDeploymentService can likely deal with this by

1) knowing it's executing during boot, which it could learn from DeploymentOperation (which would have to have a property added to reveal that.)

2) If so digging further into that RESULT to look for problems and not relying on the result of the composite. Perhaps it should do that always.

That will get the .failed marker correctly written. Analysis/testing also needs to be done to ensure that FileSystemDeploymentService will correctly handle the deployment being subsequently fixed; i.e. it needs to recognize that the deployment is still registered with the server and needs to be replaced, not added a second time.

Brian Stansberry <brian.stansberry> made a comment on jira WFLY-1305

"This happens because CompositeOperationHandler only marks the composite operation as "failed" if rollback occurs. I have a vague memory that that's by design; I'll need to do some research."

My vague memory was correct. The docs on this are quite clear (and I wrote them):

https://docs.jboss.org/author/display/AS72/Admin+Guide#AdminGuide-BasicCompositeOperationResponses

"The high level format of a basic composite operation response is largely the same as that of a simple operation response, although there is an important semantic difference. For a composite operation, the meaning of the outcome flag is controlled by the value of the operation request's rollback-on-runtime-failure header field. If that field was false (default is true), the outcome flag will be success if all steps were successfully applied to the persistent configuration even if none of the composite operation's steps was successfully applied to the runtime."

So, the RESULT in the attachment is per design. We'll have to figure out how to have FileSystemDeploymentService dig further into the result if rollback-on-runtime-failure will be set to 'false'. Or perhaps always. Should be solvable easily enough.

*** Bug 1119159 has been marked as a duplicate of this bug. ***