On 6/29/06, Paulex Yang <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>>> > For additional commands, e-mail:
>>> [EMAIL PROTECTED]
>>> >
>>> >
>>>
>>>
>>> --
>>> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrew Zhang
China Software Development Lab, IBM
