Uploaded image for project: 'Spring Framework'
  1. Spring Framework
  2. SPR-9288

JMX related failures in spring-context tests

    Details

    • Type: Task
    • Status: Resolved
    • Priority: 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

          rstoya05-aop Rossen Stoyanchev created issue -
          rstoya05-aop Rossen Stoyanchev made changes -
          Field Original Value New Value
          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 it more than one MBeanServer instances were found and the first one on the list 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.

          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.

          cbeams Chris Beams made changes -
          Fix Version/s 3.2 Backlog [ 11128 ]
          Assignee Chris Beams [ cbeams ]
          cbeams Chris Beams made changes -
          Affects Version/s 3.2 M1 [ 11896 ]
          Affects Version/s 3.1.1 [ 12706 ]
          tmarshall Trevor Marshall made changes -
          Workflow SPR Workflow [ 52726 ] New SPR Workflow [ 58838 ]
          tmarshall Trevor Marshall made changes -
          Workflow New SPR Workflow [ 58838 ] SPR Workflow [ 68540 ]
          rstoya05-aop Rossen Stoyanchev made changes -
          Summary Test failure in MBeanServerFactoryBeanTests.testWithLocateExistingAndExistingServer JMX related failures in spring-context tests
          rstoya05-aop Rossen Stoyanchev made changes -
          Issue Type Task [ 3 ] Bug [ 1 ]
          cbeams Chris Beams made changes -
          Fix Version/s 3.2 Backlog [ 11128 ]
          Fix Version/s 3.2 M2 [ 12702 ]
          juergen.hoeller Juergen Hoeller made changes -
          Issue Type Bug [ 1 ] Task [ 3 ]
          Fix Version/s 3.2 RC1 [ 13216 ]
          Fix Version/s 3.2 M2 [ 12702 ]
          cbeams Chris Beams made changes -
          Fix Version/s 3.2 RC2 [ 13611 ]
          Fix Version/s 3.2 RC1 [ 13216 ]
          rstoya05-aop Rossen Stoyanchev made changes -
          Link This issue is duplicated by SPR-10030 [ SPR-10030 ]
          pwebb Phil Webb made changes -
          Assignee Chris Beams [ cbeams ] Phil Webb [ pwebb ]
          pwebb Phil Webb made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Complete [ 8 ]
          sslavic Stevo Slavić made changes -
          Link This issue is duplicated by SPR-10031 [ SPR-10031 ]
          pwebb Phil Webb made changes -
          Resolution Complete [ 8 ]
          Status Resolved [ 5 ] Reopened [ 4 ]
          pwebb Phil Webb made changes -
          Status Reopened [ 4 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]

            People

            • Assignee:
              pwebb Phil Webb
              Reporter:
              rstoya05-aop Rossen Stoyanchev
              Last updater:
              Phil Webb
            • Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                5 years, 1 day ago