You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Andrew Zhang <zh...@gmail.com> on 2006/07/03 09:44:07 UTC
Re: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test
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 :)
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!
[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....@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
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
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....@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