glassfish
  1. glassfish
  2. GLASSFISH-19275

Flashlight seeing probes in ProbeRegistry even though the ProbeProvider failed to register

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: monitoring
    • Labels:
      None
    • Environment:

      Linux

      Description

      I've been doing some testing which uses XML probes.

      During some testing which uses XML probe definitions, I had inadvertently had defined some XML probe provider definitions which were being rejected by Flashlight, but my tests were actually still finding the probes in the ProbeRegistry.

      The probe definitions from the XML providers that failed appear to actually have been consumed here and were showing up in the ProbeRegistry after that occurred. For example, while my unit tests logged a severe error, the call to FlashlightProbeProviderFactory.processXMLProbeProviders() itself though returned as if it had succeeded and the probe definitions from those providers showed up and appeared valid when the unit tests called probeRegistry.getAllProbes() and verified it found the probes.

      Knowing the provider failed to be processed fully there, I'm thinking that the probes from those providers would not want to be showing up after that occurred. For example, even if the FlashlightProbeProviderFactory.processXMLProbeProviders() eats the exception, I'm thinking that the probes that were defined for those providers that were determined to be invalid would not show up as being registered later (right?). I haven't dug into why that happened and whether they may case adverse side effects later on if they are not cleared out (ie: it may be that they are just "zombie" probes taking up heap and not causing other issues since the provider wasn't really completely registered?)

      I suspect what is happening there is as the provider is being processed createProbe calls are registering the probes.

      I believe that this could be reproduced using the flashlight unit tests by adding a new test that does something along these lines:

      @BeforeClass
      public static void setUpClass() throws Exception

      { FlashlightUtils.initialize(new MyServiceLocator(), new MyMonitoringService()); flashlightProbeProviderFactory = new FlashlightProbeProviderFactory(); assertNotNull(flashlightProbeProviderFactory); flashlightProbeProviderFactory.postConstruct(); flashlightProbeProviderFactory.processXMLProbeProviders(ProbeEventGenerationTest.class.getClassLoader(), "one_probe.xml", true); flashlightProbeProviderFactory.processXMLProbeProviders(ProbeEventGenerationTest.class.getClassLoader(), "two_probe.xml", true); probeRegistry = ProbeRegistry.getInstance(); assertNotNull(probeRegistry); // check the probe registry for probes from the failed provider }

        Activity

        There are no comments yet on this issue.

          People

          • Assignee:
            Byron Nevins
            Reporter:
            tvlatas
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: