Spring Framework
  1. Spring Framework
  2. SPR-9288

JMX related failures in spring-context tests

    Details

    • Type: Task Task
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 3.2 M1
    • Fix Version/s: 3.2 RC2
    • Component/s: [Build]
    • Labels:
      None
    • Last commented by a User:
      false

      Description

      The failure occurs when I run all spring-context tests from the command line. It doesn't fail when running the test alone, the tests in the same package, or all tests inside Eclipse.

      The test creates an MBeanServer via javax.management.MBeanServerFactory, then tries to check if an MBeanServerFactoryBean will locate that same instance. The assertSame on line 65 fails because more than one MBeanServer instances were found and the first one returned was not the same instance.

      Running gradle in debug mode and using breakpoints in addMBeanServer() and removeMBeanServer() of MBeanServerFactory, I was able to find one case where an MBeanServer is added but not removed. It happens in AdvisedJRubyScriptFactoryTests inside JRuby itself when Spring tries to load a script via JRubyScriptFactory. So it looks like a side effect, which explains why the failure doesn't occur when running a single test but not why it doesn't fail inside Eclipse.

      I experimented with a tearDown() method in AdvisedJRubyScriptFactoryTests, which looks for and releases any MBeanServers it finds but that caused a failure in JmxUtilsTests.testLocatePlatformMBeanServer. So clearly not a good fix. Furthermore the fact this is an environment-sensitive issue makes even more hesitant to go any further.

        Issue Links

          Activity

          Hide
          Rob Winch added a comment -

          I probably should have explained why I included JmxUtilsTests in the examples I provided (sorry about that). The ordering to replicate the issue appears to be a bit more complex than ensuring AdvisedJRubyScriptFactoryTests is first if you include JmxUtilsTests into the mix. For example, the following works despite the fact that AdvisedJRubyScriptFactoryTests is first:

          @RunWith(Suite.class)
          @RunWith(Suite.class)
          @Suite.SuiteClasses({AdvisedJRubyScriptFactoryTests.class,
              JmxUtilsTests.class,
              AnnotationMetadataAssemblerTests.class,
              MBeanServerFactoryBeanTests.class})
          public class Spr9288WorksTestSuite {
          }
          

          You will notice the only difference from my previous failing example is that JmxUtilsTests is moved up. I mention this to hopefully make solving this a bit easier when it gets looked into. I should also note that there may be other tests that impact this issue, but I haven't dug that deep.

          Show
          Rob Winch added a comment - I probably should have explained why I included JmxUtilsTests in the examples I provided (sorry about that). The ordering to replicate the issue appears to be a bit more complex than ensuring AdvisedJRubyScriptFactoryTests is first if you include JmxUtilsTests into the mix. For example, the following works despite the fact that AdvisedJRubyScriptFactoryTests is first: @RunWith(Suite.class) @RunWith(Suite.class) @Suite.SuiteClasses({AdvisedJRubyScriptFactoryTests.class, JmxUtilsTests.class, AnnotationMetadataAssemblerTests.class, MBeanServerFactoryBeanTests.class}) public class Spr9288WorksTestSuite { } You will notice the only difference from my previous failing example is that JmxUtilsTests is moved up. I mention this to hopefully make solving this a bit easier when it gets looked into. I should also note that there may be other tests that impact this issue, but I haven't dug that deep.
          Hide
          Chris Beams added a comment -

          Promoting this to 3.2 M2 in the spirit of "never putting a bug in a backlog". Thanks for looking so deeply into this, both of you. The test classes posted above will help a lot in nailing this down.

          Show
          Chris Beams added a comment - Promoting this to 3.2 M2 in the spirit of "never putting a bug in a backlog". Thanks for looking so deeply into this, both of you. The test classes posted above will help a lot in nailing this down.
          Hide
          Juergen Hoeller added a comment -

          I wouldn't use the "Bug" label on issues like this one, since it's only really an issue with the test suite, and even there just for specific modes of running. Since we haven't really got a proper label for this kind of issue, I switched it to "Task"...

          In any case, I'd prefer using "Bug" for actual issues within the framework only.

          Juergen

          Show
          Juergen Hoeller added a comment - I wouldn't use the "Bug" label on issues like this one, since it's only really an issue with the test suite, and even there just for specific modes of running. Since we haven't really got a proper label for this kind of issue, I switched it to "Task"... In any case, I'd prefer using "Bug" for actual issues within the framework only. Juergen
          Hide
          Phil Webb added a comment -
          commit 6ca71abf934ee689f227d5ff864e7a4c4d8ae9d5
          Author: Phillip Webb <pwebb@vmware.com>
          Commit: Phillip Webb <pwebb@vmware.com>
          
              Intermittent MBeanServerFactoryBeanTests failure
              
              Prior to this commit the testWithLocateExistingAndExistingServer method
              would fail if any preceding test called the ManagementFactory
              getPlatformMBeanServer() method. In such situations the platform
              server is located instead of the expected freshly created server.
              
              These failures are more likely to happen when compiling with JDK 7
              due to the fact that the reflection API no longer returns methods
              in a consistent order.
              
              Unfortunately there is no easy way to reset the platform MBean server
              so the new code must resort to using reflection to access the private
              static ManagementFactory.platformMBeanServer field.
              
              Issue: SPR-9288
          
          Show
          Phil Webb added a comment - commit 6ca71abf934ee689f227d5ff864e7a4c4d8ae9d5 Author: Phillip Webb <pwebb@vmware.com> Commit: Phillip Webb <pwebb@vmware.com> Intermittent MBeanServerFactoryBeanTests failure Prior to this commit the testWithLocateExistingAndExistingServer method would fail if any preceding test called the ManagementFactory getPlatformMBeanServer() method. In such situations the platform server is located instead of the expected freshly created server. These failures are more likely to happen when compiling with JDK 7 due to the fact that the reflection API no longer returns methods in a consistent order. Unfortunately there is no easy way to reset the platform MBean server so the new code must resort to using reflection to access the private static ManagementFactory.platformMBeanServer field. Issue: SPR-9288
          Hide
          Phil Webb added a comment -
          commit 0d73d199ec645f6d332d3283b72a531b26575cf6
          Author: Phillip Webb <pwebb@vmware.com>
          Commit: Phillip Webb <pwebb@vmware.com>
          
              Reset MBean Servers after JRuby and JMX tests
              
              Refactor MBean Server reset code from MBeanServerFactoryBeanTests
              and reuse in AdvisedJRubyScriptFactoryTests and
              AbstractMBeanServerTests.
              
              Issue: SPR-9288
          
          Show
          Phil Webb added a comment - commit 0d73d199ec645f6d332d3283b72a531b26575cf6 Author: Phillip Webb <pwebb@vmware.com> Commit: Phillip Webb <pwebb@vmware.com> Reset MBean Servers after JRuby and JMX tests Refactor MBean Server reset code from MBeanServerFactoryBeanTests and reuse in AdvisedJRubyScriptFactoryTests and AbstractMBeanServerTests. Issue: SPR-9288

            People

            • Assignee:
              Phil Webb
              Reporter:
              Rossen Stoyanchev
              Last updater:
              Phil Webb
            • Votes:
              1 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                1 year, 20 weeks, 5 days ago