Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of zhanghuangzhu@gmail.com
 designates 66.249.82.192 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:mime-version:content-type;
        b=DPJIhQcOdGRFu5oKDT4cw1PvLqudoez0s869j2NG3EFxt/oZM4uOPXkBn4fPWkKRcmGhtkxo2F0bW5ouUmirFTvRqEd/4tPyYVw3wDVU3pBIfHS2lBsLK4Ox1zNE4mYVPFXstW2U3FSnP9CIx4fXahrgwsQ+CjSN7xORXHDU6d8=
Message-ID: <4d0b24970607042012s207d28ccoad278b1c7ad1e528@mail.gmail.com>
Date: Wed, 5 Jul 2006 11:12:36 +0800
From: "Andrew Zhang" <zhanghuangzhu@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: [classlib][nio] Modify ServerSocketChannel.implConfigureBlocking()
 method
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_50368_930416.1152069156025"

------=_Part_50368_930416.1152069156025
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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 <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
>
>


-- 
Andrew Zhang
China Software Development Lab, IBM

------=_Part_50368_930416.1152069156025--