harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Zhang" <zhanghuang...@gmail.com>
Subject Re: [classlib][LUNI | NIO] How to write stable tests for blocking write/read operations of Socket and SocketChannel
Date Thu, 29 Jun 2006 05:41:14 GMT
On 6/29/06, Paulex Yang <paulex.yang@gmail.com> wrote:
>
> Jimmy, Jing Lv wrote:
> > Andrew Zhang wrote:
> >> Hi everybody,
> >>
> >> I'm struggling to write a stable test for blocking write/read
> >> operation of
> >> Socket and SocketChannel.
> >>
> >> Could you anybody help me out?
> >>
> >>
> >
> > Hi Andrew:
> >
> >     The network testing is a problem to me as well. As all I/O depends
> > on OS, I wonder there is a way to ensure the data has pass the network
> > and reach the destination.
> >     As Tim mentioned, a close of socket may cause a real flush and
> > send the data, however on my workstation(windows XP, RI v1.5.06), the
> > testcase you listed below still fails randomly (fails 1 out of 4
> > approximately) on RI, is that a bug of RI?
> >     I also notice that a testcase of pipe meets such situation(in
> > Harmony implementation, pipe use SocketChannel as its two channels),
> > which is in SourcechannelTest, test_read_$LByteBufferII() and
> > test_read_$LByteBuffer():
> >
> >     ByteBuffer[] bufArray = { buffer, positionedBuffer };
> >     ...
> >     sink.write(bufArray);
> >     ...
> >     do {
> >     long count = source.read(readBufArray, 0, 2);
> >         if (count < 0) {
> >         break;
> >     }totalCount += count;
> >     } while (totalCount != 10 && !isBlocking);
> >     // assert read result
> >     for (ByteBuffer readBuf : readBufArray) {
> >     // RI may fail because of its bug implementation
> >     assertEquals(BUFFER_SIZE, readBuf.position());
> >     assertEquals("bytes", new String(readBuf.array(), ISO8859_1));
> >     }
> >
> >     Seems RI fails to write all data in bufArray into network (but it
> > always at least write the first ByteBuffer in the array, strange! ),
> > even I add "close" in the testcase.
> >
> >     It is important to test the code of read I/O. However the testcase
> > is hard to write. I notice many unstable testcases are deleted in
> > nio.channels, though they are valuable in ensuring the code is right
> > in some way. And seems non-blocking network operation are much more
> > unstable than blocking ones (And another strange thing is that one
> > workstation here NEVER fail on any of such testcases!) .I think it is
> > a limitation of unit test, for it can hardly control some changefully
> > situation, or it'll be meaningless.
> For non-blocking socket I/O, except closing socket in proper time to
> make it flush, we may also need to execute the read-try to assert-wait
> in a loop until it receives all bytes we expected, however, timeout may
> be necessary to avoid test case hanging, I think it should be safe to
> assume the tests fail if it cannot pass assertion after some reasonable
> time, even for non-blocking I/O.


 +1.

Timeout makes our test more robust.

>     I'd like to see if there are great ideas on such issue. Before
> > that,IMHO, these testcases may be still valuable when doing some
> > develop work, even if need to delete or add them to excluded list
> > after development, are them?
> >
> >
> >> On 6/23/06, Andrew Zhang <zhanghuangzhu@gmail.com> wrote:
> >>>
> >>>  Hi Alexander,
> >>>
> >>> Thanks for your kind reminder.
> >>>
> >>> Certainly I'll use sth. like Support_PortManager.getNextPort() to
> avoid
> >>> such port conflict issue.
> >>>
> >>> Here I just want to describe the problem.
> >>>
> >>> The test still fails on my machine sometimes.  Could anyone tell me
> >>> how to
> >>> write a stable test on this issue?
> >>>
> >>> Or is it a bug of RI? Or is it possible to write a theoretically
> stable
> >>> test?
> >>>
> >>> Thanks a lot in advance!
> >>>
> >>>      public void test_SocketChannel_BlockWriteRead() throws
> >>> IOException {
> >>>         final int CAPACITY_NORMAL = 200;
> >>>         InetSocketAddress localAddr1 = new InetSocketAddress("
> 127.0.0.1
> >>> ",1234);
> >>>
> >>>         ServerSocket server = new ServerSocket(1234);
> >>>
> >>>         SocketChannel channel = SocketChannel.open();
> >>>         channel.connect(localAddr1);
> >>>         Socket client = server.accept ();
> >>>         client.setTcpNoDelay(true);
> >>>         client.setSendBufferSize(1);
> >>>
> >>>         OutputStream out = client.getOutputStream();
> >>>
> >>>         byte[] sendBuf = new byte[CAPACITY_NORMAL * 2];
> >>>         for (int i = 0; i < CAPACITY_NORMAL * 2; i++) {
> >>>             sendBuf[i] = (byte) i;
> >>>         }
> >>>         // send CAPACITY_NORMAL * 2 bytes data
> >>>         out.write(sendBuf);
> >>>         out.flush();
> >>>
> >>>         // no matter out.close() or client.shutdownOutput () is used
> >>>         // the test still fails sometimes.
> >>>         // out.close();
> >>>         client.shutdownOutput();
> >>>
> >>>
> >>>         ByteBuffer buf1 = ByteBuffer.allocate(CAPACITY_NORMAL);
> >>>         ByteBuffer buf2 = ByteBuffer.allocate(CAPACITY_NORMAL);
> >>>         ByteBuffer[] buf ={buf1, buf2};
> >>>
> >>>         // should receive CAPACITY_NORMAL * 2 bytes data
> >>>         long count = 0;
> >>>         do{
> >>>             long ret = channel.read(buf);
> >>>             if(ret == -1){
> >>>                 break;
> >>>             }
> >>>             count += ret;
> >>>         }while(count < CAPACITY_NORMAL*2);
> >>>         assertEquals(CAPACITY_NORMAL * 2, count);
> >>>     }
> >>>
> >>>
> >>>  On 6/23/06, Alexander Kleymenov <kleymenov@gmail.com> wrote:
> >>> >
> >>> > Hello Andrew,
> >>> >
> >>> > I ran the test on RI (1.4.2_04-b05 and 1.5.0-b64)  and could not
> >>> > reproduce the failure. Is it still an issue?
> >>> >
> >>> > Can I suggest a little improvement for your test? Try do not use
> >>> > hardcoded port numbers in the test.
> >>> > Let the ServerSocket choose the available port by specifying 0 as
> >>> > parameter.
> >>> > I.e. write the test as:
> >>> >
> >>> >       ServerSocket server = new ServerSocket(0);
> >>> >       InetSocketAddress localAddr1 = new
> >>> InetSocketAddress("127.0.0.1",
> >>> >               server.getLocalPort());
> >>> >
> >>> > Such a way prevents the test from "Address in use" exception.
> >>> >
> >>> > Thank You,
> >>> > Alexander
> >>> >
> >>> >
> ---------------------------------------------------------------------
> >>> > 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
> >>>
> >>
> >>
> >>
> >
> >
>
>
> --
> Paulex Yang
> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message