harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@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:20:43 GMT
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.
>     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


Mime
View raw message