[jira] Commented: (DIRMINA-736) MdcInjectionFilterTest sometimes fails for SESSION_CLOSED event

2009-08-18 Thread james defelice (JIRA)

[ 
https://issues.apache.org/jira/browse/DIRMINA-736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744475#action_12744475
 ] 

james defelice commented on DIRMINA-736:


from the trunk (on 2009-08-10)


 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
 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.



[jira] Created: (DIRMINA-736) MdcInjectionFilterTest sometimes fails for SESSION_CLOSED event

2009-08-10 Thread james defelice (JIRA)
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
 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.