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