mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raman Gupta (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DIRMINA-277) Various tests block with JDK5 concurrent used in place of backport
Date Wed, 04 Oct 2006 06:01:20 GMT
    [ http://issues.apache.org/jira/browse/DIRMINA-277?page=comments#action_12439734 ] 
            
Raman Gupta commented on DIRMINA-277:
-------------------------------------

I have investigated this some more and believe I have found the problem. In ExpiringMap, line
370, the code attempts to upgrade a read lock into a write lock. Here is the relevant code:

        public void startExpiringIfNotStarted()
        {
            stateLock.readLock().lock();
            if( running )
            {
                stateLock.readLock().unlock();
                return;
            }
            
            stateLock.writeLock().lock();
            try
            {
                if( !running )
                {
                    running = true;
                    expirerThread.start();
                }
            }
            finally
            {
                stateLock.writeLock().unlock();
            }
        }

If running == false, then the method will attempt to upgrade its read lock into a write lock,
which will cause a hang when using the JDK5 concurrent classes. The backport Javadoc for ReentrantReaderWriterLock
also states that a read lock cannot be upgraded into a write lock, so presumably this should
also be causing a problem with the backport classes, but for whatever reason it is not.

I will attach a simple patch that fixes this problem (and all tests pass with Java 5).

> Various tests block with JDK5 concurrent used in place of backport
> ------------------------------------------------------------------
>
>                 Key: DIRMINA-277
>                 URL: http://issues.apache.org/jira/browse/DIRMINA-277
>             Project: Directory MINA
>          Issue Type: New Feature
>          Components: Transport
>    Affects Versions: 1.0
>         Environment: Sun JDK 1.5.0_07 (Linux 2.6.17), Sun JDK 1.5.0_08 (Windows 2000),
and Sun JDK 1.5.0_06 (Windows XP)
>            Reporter: Raman Gupta
>            Priority: Minor
>
> When running "mvn test" with all references to the concurrent backport removed, the tests
block at:
> org.apache.mina.transport.socket.nio.DatagramConfigTest 
> The stack dump shows the blocked thread is:
> "main" prio=1 tid=0x082dedd0 nid=0x620d in Object.wait() [0xbfde4000..0xbfde6188]
>        at java.lang.Object.wait(Native Method)
>        - waiting on <0x88a07930> (a org.apache.mina.transport.socket.nio.support.DatagramConnectorDelegate$RegistrationRequest)
>        at java.lang.Object.wait(Object.java:474)
>        at org.apache.mina.common.support.DefaultIoFuture.join(DefaultIoFuture.java:86)
>        - locked <0x88a07930> (a org.apache.mina.transport.socket.nio.support.DatagramConnectorDelegate$RegistrationRequest)
>        at org.apache.mina.transport.socket.nio.DatagramConfigTest.testAcceptorFilterChain(DatagramConfigTest.java:73)
>        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:585)
>        at junit.framework.TestCase.runTest(TestCase.java:154)
>        at junit.framework.TestCase.runBare(TestCase.java:127)
>        at junit.framework.TestResult$1.protect(TestResult.java:106)
>        at junit.framework.TestResult.runProtected(TestResult.java:124)
>        at junit.framework.TestResult.run(TestResult.java:109)
>        at junit.framework.TestCase.run(TestCase.java:118)
>        at junit.framework.TestSuite.runTest(TestSuite.java:208)
>        at junit.framework.TestSuite.run(TestSuite.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:585)
>        at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210)
>        at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135)
>        at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122)
>        at org.apache.maven.surefire.Surefire.run(Surefire.java:129)
>        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:585)
>        at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225)
>        at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message