Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-29623

MicroProfile Health: CDI Extension doesn't reset the disabled default procedures configuration when undeploying

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • EAP-XP-5.0.0.GA, EAP-XP-6.0.0.CR1
    • MP Health
    • None
    • False
    • Hide

      None

      Show
      None
    • False
    • +
    • Hide
      • Start WildFly using standalone-microprofile.xml configuration
      • Hit http://localhost:9990/health/ready - "UP", 5 default procedures checks are reported
      • Deploy a MicroProfile application that defines a Readiness check, and the mp.health.disable-default-procedures=true MP Config property, too.
      • Hit http://localhost:9990/health/ready - "UP", 1 application check
      • Undeploy the appliccation
      • Hit http://localhost:9990/health/ready - "UP", 0 checks, which is wrong as the default procedures shouldn't be disabled anymore.
      Show
      Start WildFly using standalone-microprofile.xml configuration Hit http://localhost:9990/health/ready - "UP", 5 default procedures checks are reported Deploy a MicroProfile application that defines a Readiness check, and the mp.health.disable-default-procedures=true MP Config property, too. Hit http://localhost:9990/health/ready - "UP", 1 application check Undeploy the appliccation Hit http://localhost:9990/health/ready - "UP", 0 checks, which is wrong as the default procedures shouldn't be disabled anymore.

      After WFLY-19147 was solved, we started seeing a weird behavior between two separate test cases executions.
      Basically, if a MicroProfile application is deployed that defines mp.health.disable-default-procedures=true, the default procedures are disabled server-wide, as the spec mandates and as tracked by WFLY-19147.
      The issue is that - when undeploying - the status of such configuration, which is held by MicroProfileHealthReporter, is not reset.
      As a consequence, the server wide default procedures will still be disabled, even if a new version of the application - this time not defining the mp.health.disable-default-procedures=true property - is deployed.

      When a MicroProfile application that defined the property and caused the default procedures to be disabled server-wide is undeployed, then the related configuration should be reset, for the server not to take wrongly into account outdated information when processing MP Health checks.

      This behavior isn't so visible in cloud/microservices scenarios, where deploy/undeploy within the same server instance process isn't so common.

      A potential fix is here: https://github.com/wildfly/wildfly/pull/18705 so jmesnil1@redhat.com feel free to assign to me if you wish.

              fburzigo@redhat.com Fabio Burzigotti
              fburzigo@redhat.com Fabio Burzigotti
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: