You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Andrew Zhang <zh...@gmail.com> on 2006/06/24 02:11:18 UTC
[classlib][LUNI | NIO] How to write stable tests for blocking write/read operations of Socket and SocketChannel
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?
On 6/23/06, Andrew Zhang <zh...@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 <kl...@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
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib][LUNI | NIO] How to write stable tests for blocking write/read operations of Socket and SocketChannel
Posted by Andrew Zhang <zh...@gmail.com>.
Hi Tim,
The test also fails frequently on IBM 5.0 JRE, windows XP, SP2.
Thanks.
On 6/26/06, Tim Ellison <t....@gmail.com> wrote:
>
> Jimmy, Jing Lv wrote:
> <snip>
> > 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?
>
> It would be interesting to know if you can reproduce it on other JREs /
> platforms.
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> 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
Re: [classlib][LUNI | NIO] How to write stable tests for blocking
write/read operations of Socket and SocketChannel
Posted by Tim Ellison <t....@gmail.com>.
Jimmy, Jing Lv wrote:
<snip>
> 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?
It would be interesting to know if you can reproduce it on other JREs /
platforms.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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
Re: [classlib][LUNI | NIO] How to write stable tests for blocking write/read operations of Socket and SocketChannel
Posted by Andrew Zhang <zh...@gmail.com>.
On 6/29/06, Paulex Yang <pa...@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 <zh...@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 <kl...@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
Re: [classlib][LUNI | NIO] How to write stable tests for blocking
write/read operations of Socket and SocketChannel
Posted by Paulex Yang <pa...@gmail.com>.
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 <zh...@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 <kl...@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
Re: [classlib][LUNI | NIO] How to write stable tests for blocking
write/read operations of Socket and SocketChannel
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
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 <zh...@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 <kl...@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