harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jimmy, Jing Lv" <firep...@gmail.com>
Subject Re: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test
Date Mon, 03 Jul 2006 09:05:16 GMT
Andrew Zhang wrote:
> Hello Tim
> 
> I think I have found where the problem is.
> 
> When I ran the test with latest code, the test failed again on my machine.
> How lucky am I :)
> 

Lucky dog :)

> The failure trace[1] tells us it fails because of 
> ServerSocketChannel.accept().
> 
> 
> Message "The socket is marked as nonblocking operation would block" means
> "The socket is marked non-blocking and no connections are present to be
> accepted.".
> 
> On linux, the return value is EAGAIN or EWOULDBLOCK. It happens when the
> native file descriptor is configured as nonblocking and no connections are
> pending. Therefore, we have two ways to fix the bug in
> ServerSocketChannel.accept():
> 
> 1. Don't configure native file descriptor as nonblocking, and use 
> "select" +
> "blocking accept" to implement non blocking accept, which is similiar with
> nonblocking read/write implementaion of SocketChannel. The fix is rather
> simple, leave "implConfigureBlocking" as empty is ok.
> 
> 2. Check the exception thrown by native code. Harmony throws BindException
> with "The socket is marked as nonblocking operation would block" message.
> We could catch BindException and check exception message to know whether 
> the
> accept is successful. Such check is ugly, but native code acts in this way.
> :(  If error code is returned, the things wil be much easier. (Of course,
> it's not a good idea either, since error code is platform dependent.)
> 
> Therefore, in my opnion, solution 1 sounds more reasonable.
> 
> Any suggestions? Thanks a lot!
> 

Interesting, trace into native code, it just do as you said in (1). :)
Seems it is unnecessary to set real blocking/nonblocking to OS level, so 
remove setNonblocking() in implConfigureBlocking() is correct.

What's more, I find some operations related to network are also written 
in this way, first select and then read/write/accept/connect, so I guess 
all implementation in java.nio.channels shall remove setNonblocking() in 
implConfigureBlocking().

And what you said in (2) may be correct as well. And I find 
setNonblocking() shall not be effective sometimes if it call a timeout 
connect(). The native code of connect() is rather strange, it set socket 
to nonblocking mode as first and set it to blocking mode at the end (But 
not set it back to the origin mode!), in this way it cause confusion. 
Luckily we found try...catch to catch such exception in Harmony Java 
code, that's why Harmony is still correct in logic(Maybe accept() is 
not, as it does not deal with this exception at all).
The reason why should deal this problem is the native function for both 
java.net and net-related java.nio.channels, and I guess some methods 
were written for java.net(blocking network I/O) and re-used by 
NIO(non-blocking network I/O). It works properly except for a few 
differences between java.net and NIO, these differences rise the 
complexity, luckily most of them are resloved.


> [1]
> 
> java.net.BindException: The socket is marked as nonblocking operation would
> block at
> org.apache.harmony.luni.platform.OSNetworkSystem.acceptStreamSocketImpl
> (Native
> Method)
>        at
> org.apache.harmony.luni.platform.OSNetworkSystem.acceptStreamSocket(
> OSNetworkSystem.java:219)
>        at
> org.apache.harmony.luni.net.PlainSocketImpl.accept(PlainSocketImpl.java:96)
>        at java.net.ServerSocket.implAccept(ServerSocket.java:252)
>        at
> org.apache.harmony.nio.internal.ServerSocketChannelImpl$ServerSocketAdapter.accept 
> 
> (ServerSocketChannelImpl.java:241)
>        at
> org.apache.harmony.nio.internal.ServerSocketChannelImpl$ServerSocketAdapter.access$0

> 
> (ServerSocketChannelImpl.java:227)
>        at
> org.apache.harmony.nio.internal.ServerSocketChannelImpl.accept(
> ServerSocketChannelImpl.java:144)
>        at
> org.apache.harmony.tests.java.nio.channels.SelectorTest.assert_select_OP_READ 
> 
> (SelectorTest.java:413)
>        at
> org.apache.harmony.tests.java.nio.channels.SelectorTest.test_selectNow(
> SelectorTest.java:200)
>        at
> java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
>        at java.lang.reflect.Method.invoke(Method.java:255)
>        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 junit.framework.TestSuite.runTest(TestSuite.java:208)
>        at junit.framework.TestSuite.run(TestSuite.java:203)
>        at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(
> RemoteTestRunner.java:478)
>        at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(
> RemoteTestRunner.java:344)
>        at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(
> RemoteTestRunner.java:196)
> 
> 
> 
> On 6/30/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
>>
>> Latest Windows build just failed a test:
>>
>>
>> java.nio.channels.ClosedChannelException at
>> java.nio.channels.spi.AbstractSelectableChannel.configureBlocking(
>> AbstractSelectableChannel.java:208)
>> at
>>
>> org.apache.harmony.tests.java.nio.channels.SelectorTest.assert_select_OP_READ 
>>
>> (SelectorTest.java:416)
>> at
>> org.apache.harmony.tests.java.nio.channels.SelectorTest.test_selectNow(
>> SelectorTest.java:200)
>> at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
>>
>>
>>
>>
>> Apache Harmony Build wrote:
>> > Online report :
>> http://ibmonly.hursley.ibm.com/continuum/win.ia32/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/6/buildId/1507

>>
>> > Build statistics:
>> >   State: Failed
>> >   Previous State: Ok
>> >   Started at: Fri, 30 Jun 2006 09:05:23 +0100
>> >   Finished at: Fri, 30 Jun 2006 09:14:47 +0100
>> >   Total time: 9m 23s
>> >   Build Trigger: Schedule
>> >   Exit code: 1
>> >   Building machine hostname: hy1
>> >   Operating system : Windows XP(Service Pack 2)
>> >   Java version : 1.5.0_06(Sun Microsystems Inc.)
>> >
>> > Changes
>> >
>> classlib\modules\tools\src\main\java\org\apache\harmony\tools\javac\Compiler.java

>>
>> >
>> classlib\modules\beans\src\main\java\java\beans\PropertyChangeSupport.java 
>>
>> >
>> classlib\modules\security\src\test\api\java\org\apache\harmony\security\tests\java\security\serialization\KeyPairTest.java

>>
>> >
>> classlib\modules\security\src\test\resources\serialization\org\apache\harmony\security\tests\java\security\serialization\KeyPairTest.golden.ser

>>
>> >             classlib\modules\security\build.xml
>> >
>> >
>> **************************************************************************** 
>>
>> > Output:
>> >
>> **************************************************************************** 
>>
>> > Buildfile: build.xml
>> >
>>
>> >
>> >
>> >
>>
>> -- 
>>
>> Tim Ellison (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
> 
> 


-- 

Best Regards!

Jimmy, Jing Lv
China Software Development Lab, IBM

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message