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

Details

    • Bug
    • Resolution: Done
    • 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.

    Description

      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.

      Attachments

        Activity

          People

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

            Dates

              Created:
              Updated:
              Resolved: