Uploaded image for project: 'WildFly Core'
  1. WildFly Core
  2. WFCORE-788

Executing a composite operation allowing services to restart fails if the first operation relies on a capability of a remove operation

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 2.0.0.Alpha6
    • None
    • Management
    • None
    • Hide

      You'll need to build a local copy of https://github.com/wildfly/wildfly/pull/7682 then start a standalone server and CLI.

      Execute the following command:

      /subsystem=datasources/data-source=test:add(driver-name=h2,jndi-name="java:jboss/datasources/Test",connection-url="jdbc:h2:~/tmp/db/test",enabled=true)
      

      Then we need to disable and remove the data-source in a batch operation.

      batch
      /subsystem=datasources/data-source=test:disable
      /subsystem=datasources/data-source=test:remove
      run-batch --headers={allow-resource-service-restart=true}
      

      Execute the run-batch command again and there is no failure.

      Show
      You'll need to build a local copy of https://github.com/wildfly/wildfly/pull/7682 then start a standalone server and CLI. Execute the following command: /subsystem=datasources/data-source=test:add(driver-name=h2,jndi-name= "java:jboss/datasources/Test" ,connection-url= "jdbc:h2:~/tmp/db/test" ,enabled= true ) Then we need to disable and remove the data-source in a batch operation. batch /subsystem=datasources/data-source=test:disable /subsystem=datasources/data-source=test:remove run-batch --headers={allow-resource-service-restart= true } Execute the run-batch command again and there is no failure.

      This does seem to be somewhat of an edge case as the only way to reproduce it is to add the allow-resource-service-restart=true header to a composite operation. The first operation must also need access to a capability provided by a resource being removed. It's likely an acceptable failure, but the failure isn't seen when executing the same composite operation again.

      The issue seems to be that the capability is removed on the first execution that fails and is rolled back. On the second execution of the composite operation there is no capability registered registered in the RuntimeCapabilityRegistration so the remove of the capability doesn't happen. This allows the first operation to pass.

              bstansbe@redhat.com Brian Stansberry
              jperkins-rhn James Perkins
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: