[
https://issues.apache.org/jira/browse/DIRMINA-736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny resolved DIRMINA-736.
---------------------------------------
Resolution: Fixed
Seems to have been fixed in RC2
> MdcInjectionFilterTest sometimes fails for SESSION_CLOSED event
> ---------------------------------------------------------------
>
> Key: DIRMINA-736
> URL: https://issues.apache.org/jira/browse/DIRMINA-736
> Project: MINA
> Issue Type: Bug
> Components: Filter
> Affects Versions: 2.0.0-M6
> Environment: [16:09:14]<>$ uname -a
> Linux devws 2.6.18-92.1.22.el5.centos.plus #1 SMP Wed Dec 17 10:50:49 EST
> 2008 i686 i686 i386 GNU/Linux
> [vl...@devws ~/tools/mina/svn-20090810]
> [16:09:19]<>$ $JAVA_HOME/bin/java -version
> java version "1.6.0_14"
> Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
> Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode, sharing)
> Reporter: james defelice
>
> building from svn trunk:
> mvn -Dwith-LGPL-dependencies clean install
> mvn -Dwith-LGPL-dependencies site
> completed succesfully, then the next command failed:
> mvn -Dwith-LGPL-dependencies package assembly:assembly
> stack trace from bug report:
> Test set: org.apache.mina.filter.logging.MdcInjectionFilterTest
> -------------------------------------------------------------------------------
> Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 9.42 sec <<<
> FAILURE!
> testOnlyRemoteAddress(org.apache.mina.filter.logging.MdcInjectionFilterTest)
> Time elapsed: 1.03 sec <<< FAILURE!
> java.lang.AssertionError: MDC[handlerClass] set for [Event SESSION_CLOSED has
> been fired for session 91]
> at org.junit.Assert.fail(Assert.java:74)
> at org.junit.Assert.assertTrue(Assert.java:37)
> at org.junit.Assert.assertNull(Assert.java:375)
> at
> org.apache.mina.filter.logging.MdcInjectionFilterTest.testOnlyRemoteAddress(MdcInjectionFilterTest.java:203)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
>
> at
> org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
> at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
> at
> org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
> at
> org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
> at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
>
> at
> org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
> at
> org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
> at
> org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
>
> at
> org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
> at
> org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
> at
> org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
> at
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
> at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
> ... so this test doesn't use handlerClass MDC, but other test cases in this
> test class do, so maybe there's some garbage lingering somewhere else in the
> stack that's not being cleaned up between tests? Strange since this test
> case allocates an entirely new IO stack.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
