You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Raman Gupta (JIRA)" <ji...@apache.org> on 2006/10/04 08:01:20 UTC
[jira] Commented: (DIRMINA-277) Various tests block with JDK5
concurrent used in place of backport
[ 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
CompressionFilter returns error -5 (Z_BUF_ERROR) from jzlib in MINA 1.0
Posted by Frédéric Brégier <fr...@free.fr>.
Hi,
In my switch from MINA 0.9.4 to 1.0,
for one of my project, I have one new problem
that does not occured with MINA 0.9.4
with the CompressionFilter using jdk 1.5.
The example is quite simple :
- the first Filter is the compression filter
I remove everything that could be a possible
error from my project. I don't set any threadpool
at all, letting MINA sets its own way.
My protocol is in TCP (socket).
I was using jdk 1.5 before also.
I get for each try to send a compress packet
the following error :
java.io.IOException: Compression failed with return value : -5
at org.apache.mina.filter.support.Zlib.deflate(Zlib.java:181)
at
org.apache.mina.filter.CompressionFilter.filterWrite(CompressionFilter.java:198)
at
org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilterWrite(AbstractIoFilterChain.java:573)
at
org.apache.mina.common.support.AbstractIoFilterChain.access$7(AbstractIoFilterChain.java:567)
at
org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.filterWrite(AbstractIoFilterChain.java:789)
at
org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:221)
at
org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilterWrite(AbstractIoFilterChain.java:573)
at
org.apache.mina.common.support.AbstractIoFilterChain.access$7(AbstractIoFilterChain.java:567)
at
org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.filterWrite(AbstractIoFilterChain.java:789)
at
org.apache.mina.common.support.AbstractIoFilterChain$2.filterWrite(AbstractIoFilterChain.java:213)
at
org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilterWrite(AbstractIoFilterChain.java:573)
at
org.apache.mina.common.support.AbstractIoFilterChain.fireFilterWrite(AbstractIoFilterChain.java:564)
at
org.apache.mina.transport.socket.nio.SocketSessionImpl.write0(SocketSessionImpl.java:186)
at
org.apache.mina.common.support.BaseIoSession.write(BaseIoSession.java:146)
at
org.apache.mina.common.support.BaseIoSession.write(BaseIoSession.java:132)
...
When not using the compression filter, everything is ok.
I try to remove the inFilter.release but it didn't change anything (recent
patch
that I proposed). So it is not the cause.
I was suspecting in the beginning that it could be relative to the
threadPool
(cachedThreadPool) since one thread could end and so release all
informations
necessary for jzlib (persistent data), but when I remove every threadPool
that I set manually, nothing change.
I did try using backported version of MINA also and it did the same error.
Any idea ?
Frederic