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][LUNI | NIO] How to write stable tests for blocking write/read operations of Socket and SocketChannel
Date Mon, 26 Jun 2006 02:43:24 GMT
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.
     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
>>
> 
> 
> 


-- 

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