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: [classlib][nio] Modify ServerSocketChannel.implConfigureBlocking() method
Date Fri, 07 Jul 2006 03:14:09 GMT
Andrew Zhang wrote:
> 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.
> 

Hi Andrew:

     I have some new discovery and "remove setNonblocking()" may be a 
bad suggestion. Though in native code read operation uses a select() for 
non-blocking mode, write operation are implemented in the other way, it 
uses blocking write always. As a result, setNonBlocking here are still 
reasonable.
     All the complex come from connect_with_timeout() in portlib, which 
set nonblocking and did not set back to ordinary mode, this is properly 
a bug. But before its fixing, we should work around.
     I have noticed that Harmony-779 on JIRA, it removes setNonBlocking. 
This may causes some bugs, especially in send/write, however to 
datagramSocket, this may be trifling as its send/write can be hardly 
blocked (I have not got a testcase for blocking send yet). But I also 
notice JIRA-778 also require removing "setNonblocking()",I suggest not. 
For socket.write, it will block until system underlying buffer is large 
enough. As a result, keep it as it is, and a fix to portlib shall be an 
improvement.

> Any ideas and comments?
> 
> Thanks!
> 
> On 7/3/06, Jimmy, Jing Lv <firepure@gmail.com> 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 <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
>>
>>
> 
> 


-- 

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