Hello everybody, I changed the subject to make things clear.
Jimmy, as you mentioned, "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()." I agree with you. That's what I suggested in solution 1. So if no objects, I'll adopt solution 1 to fix the problem. Any ideas and comments? Thanks! On 7/3/06, Jimmy, Jing Lv <[EMAIL PROTECTED]> wrote:
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 <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) >> IBM Java technology centre, UK. >> >> --------------------------------------------------------------------- >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Andrew Zhang China Software Development Lab, IBM
