2 Tests failing in MINA trunk build
Build MINA from trunk and saw these 2 test cases failing Failed tests: testExecutorFilterAtTheEnd(org.apache.mina.filter.logging.MdcInjectionFilterTest) testTwoExecutorFilters(org.apache.mina.filter.logging.MdcInjectionFilterTest) Tests run: 185, Failures: 2, Errors: 0, Skipped: 0 This is the error (same for both failures), removed unwanted traces java.lang.AssertionError: MDC[remoteAddress] not set for [encode] at org.junit.Assert.fail(Assert.java:74) at org.junit.Assert.assertTrue(Assert.java:37) at org.junit.Assert.assertNotNull(Assert.java:356) at org.apache.mina.filter.logging.MdcInjectionFilterTest.test(MdcInjectionFilterTest.java:241) at org.apache.mina.filter.logging.MdcInjectionFilterTest.testExecutorFilterAtTheEnd(MdcInjectionFilterTest.java:116) == at org.apache.mina.filter.logging.MdcInjectionFilterTest.test(MdcInjectionFilterTest.java:241) at org.apache.mina.filter.logging.MdcInjectionFilterTest.testTwoExecutorFilters(MdcInjectionFilterTest.java:166) == 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) -- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal
[jira] Assigned: (VYSPER-12) Implement XEP-0199: XMPP Ping
[ https://issues.apache.org/jira/browse/VYSPER-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson reassigned VYSPER-12: --- Assignee: Niklas Gustavsson Implement XEP-0199: XMPP Ping - Key: VYSPER-12 URL: https://issues.apache.org/jira/browse/VYSPER-12 Project: VYSPER Issue Type: Bug Components: extension Reporter: Bernd Fondermann Assignee: Niklas Gustavsson XMPP Ping is a XMPP extension specified at http://www.xmpp.org/extensions/xep-0199.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 2 Tests failing in MINA trunk build
Will try to have a look asap. Maarten On Thu, Jul 2, 2009 at 12:36 PM, Ashish paliwalash...@gmail.com wrote: Build MINA from trunk and saw these 2 test cases failing Failed tests: testExecutorFilterAtTheEnd(org.apache.mina.filter.logging.MdcInjectionFilterTest) testTwoExecutorFilters(org.apache.mina.filter.logging.MdcInjectionFilterTest) Tests run: 185, Failures: 2, Errors: 0, Skipped: 0 This is the error (same for both failures), removed unwanted traces java.lang.AssertionError: MDC[remoteAddress] not set for [encode] at org.junit.Assert.fail(Assert.java:74) at org.junit.Assert.assertTrue(Assert.java:37) at org.junit.Assert.assertNotNull(Assert.java:356) at org.apache.mina.filter.logging.MdcInjectionFilterTest.test(MdcInjectionFilterTest.java:241) at org.apache.mina.filter.logging.MdcInjectionFilterTest.testExecutorFilterAtTheEnd(MdcInjectionFilterTest.java:116) == at org.apache.mina.filter.logging.MdcInjectionFilterTest.test(MdcInjectionFilterTest.java:241) at org.apache.mina.filter.logging.MdcInjectionFilterTest.testTwoExecutorFilters(MdcInjectionFilterTest.java:166) == 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) -- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal
Re: 2 Tests failing in MINA trunk build
Maarten Bosteels wrote: Will try to have a look asap. /me Running mvn clean install atm. -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re : 2 Tests failing in MINA trunk build
This is tracked in DIRMINA-711 Cordialement, Regards, -Edouard De Oliveira- Blog: http://tedorgwp.free.fr WebSite: http://tedorg.free.fr/en/main.php - Message d'origine De : Emmanuel Lecharny elecha...@apache.org À : dev@mina.apache.org Envoyé le : Jeudi, 2 Juillet 2009, 14h56mn 48s Objet : Re: 2 Tests failing in MINA trunk build Maarten Bosteels wrote: Will try to have a look asap. /me Running mvn clean install atm. -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: Re : 2 Tests failing in MINA trunk build
Edouard De Oliveira wrote: This is tracked in DIRMINA-711 Failed tests: testExecutorFilterAtTheEnd(org.apache.mina.filter.logging.MdcInjectionFilterTest) testTwoExecutorFilters(org.apache.mina.filter.logging.MdcInjectionFilterTest) Tests run: 185, Failures: 2, Errors: 0, Skipped: 0 Same error. We need to either fix this quickly, or revert the commits which made the build to fail. One important point for committers : *run mvn clean install before committing* ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
[jira] Commented: (DIRMINA-642) Disposing an IoConnector blocks forever
[ https://issues.apache.org/jira/browse/DIRMINA-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12726513#action_12726513 ] Victor N commented on DIRMINA-642: -- I can confirm that the problem still exists in mina 2.0 M6. Not sure whether this is related to DIRMINA-632 or not. I see the following stack trace: main prio=10 tid=0x4995c000 nid=0x4a5c waiting on condition [0x407cf000] java.lang.Thread.State: TIMED_WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x2aaab45d9ec0 (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1963) at java.util.concurrent.ThreadPoolExecutor.awaitTermination(ThreadPoolExecutor.java:1245) at org.apache.mina.core.service.AbstractIoService.dispose(AbstractIoService.java:305) So we are blocked at ThreadPoolExecutor.awaitTermination. I tried to wait 15 minutes without success - always the same stack trace. For me, the problem occurs when I shut down tomcat. In log file I see that connector continues handling i/o events as if it were not stopped. As a workaround I would propose to add another dispose method to AbstractIoService: void dispose(boolean awaitTermination); This is something like IoSession.close(boolean immediately) Disposing an IoConnector blocks forever --- Key: DIRMINA-642 URL: https://issues.apache.org/jira/browse/DIRMINA-642 Project: MINA Issue Type: Bug Components: Core Affects Versions: 2.0.0-M3 Environment: Linux Reporter: Thomas Berger Assignee: Edouard De Oliveira nHandles in the class Worker (AbstractPollingIoConnector) gets negative: -1 in my case. Then the dispose() method blocks forever as the while loop in this worker class never breaks. Reproducing this error is pretty hard, as it usually happens after several hours. I will do a quick fix and check if nHandles=0. I think it may be related to http://issues.apache.org/jira/browse/DIRMINA-632 as I never block for a write in my app. However, I get some WriteToClosedSessionException. Is it possible that this causes nHandles to become negative? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DIRMINA-722) SocketAcceptor.unbind can hang when unbinding only one of several service adresses
SocketAcceptor.unbind can hang when unbinding only one of several service adresses -- Key: DIRMINA-722 URL: https://issues.apache.org/jira/browse/DIRMINA-722 Project: MINA Issue Type: Bug Affects Versions: 1.0.10 Environment: Centos 5.3, JDK 1.6.0u11 Reporter: Rhys Yarranton If a SocketAcceptor - has multiple service addresses bound and - you unbind one of them and - disconnectOnUnbind is true and - the one being unbound has at least one session connected and - some other session on the acceptor also has at least one session connected the unbind call can hang. Excerpt from stack trace below. I suspect the hang is coming from IoServiceListenerSupport.disconnectSessions. The sessions to be closed are in the sessions variable, which is a subset of managedSessions (line 280). However, at lines 306-309, it is waiting (forever) for managedSessions to be empty. This will never happen. This is 1..0.10. The 1.1.7 code is different (it uses a countdown latch), and looks OK. JBoss Shutdown Hook daemon prio=10 tid=0x2aab00d5b800 nid=0x114a in Object.wait() [0x2aab23215000..0x2aab23217c10] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:485) at org.apache.mina.transport.socket.nio.SocketAcceptor.unbind(SocketAcceptor.java:213) - locked 0x2aaab037 (a org.apache.mina.transport.socket.nio.SocketAcceptor$CancellationRequest) ... SocketAcceptor-0 daemon prio=10 tid=0x2aaafcd93000 nid=0x2ca in Object.wait() [0x4cbc8000..0x4cbc8a10] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) at org.apache.mina.common.support.IoServiceListenerSupport.disconnectSessions(IoServiceListenerSupport.java:308) - locked 0x2aaab0376670 (a java.lang.Object) at org.apache.mina.common.support.IoServiceListenerSupport.fireServiceDeactivated(IoServiceListenerSupport.java:165) - locked 0x2aaab5e783c8 (a org.apache.mina.common.support.IoServiceListenerSupport) at org.apache.mina.transport.socket.nio.SocketAcceptor.cancelKeys(SocketAcceptor.java:470) at org.apache.mina.transport.socket.nio.SocketAcceptor.access$900(SocketAcceptor.java:53) at org.apache.mina.transport.socket.nio.SocketAcceptor$Worker.run(SocketAcceptor.java:251) at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51) at java.lang.Thread.run(Thread.java:619) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DIRMINA-723) OrderedThreadPoolExecutor behavior: configurable queue size, corePoolSize, maximumPoolSize
OrderedThreadPoolExecutor behavior: configurable queue size, corePoolSize, maximumPoolSize -- Key: DIRMINA-723 URL: https://issues.apache.org/jira/browse/DIRMINA-723 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 2.0.0-M6 Environment: Ubuntu Linux, kernel 2.6.x Reporter: Victor N Priority: Minor The problem was discussed with Emmanuel Lecharny in mail lists: http://www.nabble.com/OrderedThreadPoolExecutor%3A-limited-workQueue-td24275973.html If you compare OrderedThreadPoolExecutor and standard ThreadPoolExecutor, you can see that ThreadPoolExecutor has useful params: - core pool size - maximum pool size - work queue size If you use unbounded thread pools and queues with mina Acceptor or Connector, you may get OutOfMemoryError under critical load because Java creates too many threads. With ThreadPoolExecutor you may limit the number of threads (maximumPoolSize) and use a bounded queue (ex. LinkedBlockingQueue of limited capacity). Unfortunately, this does not work with OrderedThreadPoolExecutor -both waitingSessions and sessionTasksQueue do not allow to configure their size nor pass a different queue implementation. Even though OrderedThreadPoolExecutor extends ThreadPoolExecutor, it overrides the behavior significantly - seems that its meaning of corePoolSize and maximumPoolSize is different. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
