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/05 05:12:36 UTC
[classlib][nio] Modify ServerSocketChannel.implConfigureBlocking() method
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 <fi...@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....@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
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib][nio] Modify ServerSocketChannel.implConfigureBlocking() method
Posted by Andrew Zhang <zh...@gmail.com>.
Hi Jimmy
In fact, after I raising Harmony-778, 779, I felt a little guilty, and
didn't have a good sleep. :)
I agree that original implConfigureBlocking is necessary but not sufficient.
Original implConfigureBlocking uses ioctl family function to set underlying
file descriptor, it's correct.
But for SocketChannelImpl, it's still insufficient.
All things are caused by connect_with_timeout() from portlib. As you
mentioned, it always set the file descriptor as blocking file descriptor
when it ends normally. To fix this problem, there are two solutions:
1. modify connect_with_timeout method. Set the file descriptor blocking mode
as the same before invocation.
2. Always invoke implConfigureBlocking before read/write operations.
Currently, solution 2 is easier as a temp fix. If connect_with_timeout is
fixed in portlib, I'll remove these extra implConfigureBlocking codes.
I'll raise a serpate JIRA to solve this problem thoroughly.
Any comments and ideas?
On 7/7/06, Jimmy, Jing Lv <fi...@gmail.com> wrote:
>
> 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 <fi...@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....@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
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib][nio] Modify ServerSocketChannel.implConfigureBlocking()
method
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
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 <fi...@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....@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