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/23 08:47:01 UTC
RI's bug of Socket.getOutputStream().write(byte[]) ?
Hi everybody,
It seems RI Socket.getOutputStream().write(byte[]) doesn't send all data
sometimes. Consider following test, which often blocks on RI:
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 serverSocket = server.accept();
OutputStream out = serverSocket.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();
ByteBuffer buf1 = ByteBuffer.allocate(CAPACITY_NORMAL);
ByteBuffer buf2 = ByteBuffer.allocate(CAPACITY_NORMAL);
ByteBuffer[] buf ={buf1, buf2};
// should receive CAPACITY_NORMAL * 2 bytes data
// RI often hangs here, with CAPACITY_NORMAL bytes data received.
long count = 0;
do{
count += channel.read(buf);
}while(count < CAPACITY_NORMAL*2);
assertEquals(CAPACITY_NORMAL * 2, count);
}
I think it's a bug of RI. Am I missing something? Please correct me if I'm
wrong. There're also some similar tests in NIO module with FIXME mark.
If it's a bug of RI, I'll raise a JIRA to tidy up those "FIXME" in NIO.
Thanks!
Best regards,
--
Andrew Zhang
China Software Development Lab, IBM
Re: RI's bug of Socket.getOutputStream().write(byte[]) ?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Andrew Zhang wrote:
> On 6/23/06, Tim Ellison <t....@gmail.com> wrote:
>>
>> Andrew Zhang wrote:
>> > Hi Alexander,
>> >
>> > Thanks for your kind reminder.
>> >
>> > Certainly I'll use sth. like Support_PortManager.getNextPort() to avoid
>> > such
>> > port conflict issue.
>>
>> No, please! Don't perpetuate that abomination<g>! Alexander is right,
>> you should bind to port 0 and let the OS assign one.
>
>
> Yes, I agree that getNextPort doesn't really get the next free port, and
> bind to port 0 is the right way.
>
> But if I remembered clearly, in Jetty based tests thread, someone objected
> automatically select port.
> "> What's the problem if the port is selected automatically?
>
> Repeatability. IMO, there should be no random elements in our testing.
> That leads to frustration, fear, despair, pathos, pain, agony, angst and
> much pulling of limited resources, like hair, in my case."
That was me. And yes, I don't think that listening on a random port is a
good idea.
geir
---------------------------------------------------------------------
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: RI's bug of Socket.getOutputStream().write(byte[]) ?
Posted by Tim Ellison <t....@gmail.com>.
Andrew Zhang wrote:
> Then does getNextPort() make sense under any circumstance?
I can't think of a case.
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: RI's bug of Socket.getOutputStream().write(byte[]) ?
Posted by Andrew Zhang <zh...@gmail.com>.
On 6/24/06, Tim Ellison <t....@gmail.com> wrote:
>
> Andrew Zhang wrote:
> > On 6/23/06, Tim Ellison <t....@gmail.com> wrote:
> >>
> >> Andrew Zhang wrote:
> >> > Hi Alexander,
> >> >
> >> > Thanks for your kind reminder.
> >> >
> >> > Certainly I'll use sth. like Support_PortManager.getNextPort() to
> avoid
> >> > such
> >> > port conflict issue.
> >>
> >> No, please! Don't perpetuate that abomination<g>! Alexander is right,
> >> you should bind to port 0 and let the OS assign one.
> >
> > Yes, I agree that getNextPort doesn't really get the next free port, and
> > bind to port 0 is the right way.
> >
> > But if I remembered clearly, in Jetty based tests thread, someone
> objected
> > automatically select port.
> > "> What's the problem if the port is selected automatically?
> >
> > Repeatability. IMO, there should be no random elements in our testing.
> > That leads to frustration, fear, despair, pathos, pain, agony, angst and
> > much pulling of limited resources, like hair, in my case."
Sorry. I forgot to say that the paragraph above is cited from "Jetty based
tests" thread.
I totally agree that bind to port 0 is the right way.
LOL. Have you seen Support_PortManager.getNextPort()?, there is nothing
> repeatable about that either (unless you always run the test at the same
> time of day ;-) ) _and_ it may give you a port that is in use.
>
> > Additionally, getNextPort() is referenced many times in LUNI, NIO
> modules.
> > Most of them are used to avoid port conflict.
>
> How do they do that? the port manager gives out numbers sequentially
> starting at a 'somewhat random' point.
>
> > Shall we fix those codes?
>
> IMHO it should be on the to-do list, yes.
Then does getNextPort() make sense under any circumstance?
Thanks!
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: RI's bug of Socket.getOutputStream().write(byte[]) ?
Posted by Tim Ellison <t....@gmail.com>.
Andrew Zhang wrote:
> On 6/23/06, Tim Ellison <t....@gmail.com> wrote:
>>
>> Andrew Zhang wrote:
>> > Hi Alexander,
>> >
>> > Thanks for your kind reminder.
>> >
>> > Certainly I'll use sth. like Support_PortManager.getNextPort() to avoid
>> > such
>> > port conflict issue.
>>
>> No, please! Don't perpetuate that abomination<g>! Alexander is right,
>> you should bind to port 0 and let the OS assign one.
>
> Yes, I agree that getNextPort doesn't really get the next free port, and
> bind to port 0 is the right way.
>
> But if I remembered clearly, in Jetty based tests thread, someone objected
> automatically select port.
> "> What's the problem if the port is selected automatically?
>
> Repeatability. IMO, there should be no random elements in our testing.
> That leads to frustration, fear, despair, pathos, pain, agony, angst and
> much pulling of limited resources, like hair, in my case."
LOL. Have you seen Support_PortManager.getNextPort()?, there is nothing
repeatable about that either (unless you always run the test at the same
time of day ;-) ) _and_ it may give you a port that is in use.
> Additionally, getNextPort() is referenced many times in LUNI, NIO modules.
> Most of them are used to avoid port conflict.
How do they do that? the port manager gives out numbers sequentially
starting at a 'somewhat random' point.
> Shall we fix those codes?
IMHO it should be on the to-do list, yes.
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: RI's bug of Socket.getOutputStream().write(byte[]) ?
Posted by Andrew Zhang <zh...@gmail.com>.
On 6/25/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
>
> Andrew Zhang wrote:
> > On 6/25/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >>
> >>
> >>
> >> Andrew Zhang wrote:
> >> > On 6/23/06, Tim Ellison <t....@gmail.com> wrote:
> >> >>
> >> >> Andrew Zhang wrote:
> >> >> > Hi Alexander,
> >> >> >
> >> >> > Thanks for your kind reminder.
> >> >> >
> >> >> > Certainly I'll use sth. like Support_PortManager.getNextPort() to
> >> avoid
> >> >> > such
> >> >> > port conflict issue.
> >> >>
> >> >> No, please! Don't perpetuate that abomination<g>! Alexander is
> >> right,
> >> >> you should bind to port 0 and let the OS assign one.
> >> >
> >> >
> >> > Yes, I agree that getNextPort doesn't really get the next free port,
> >> and
> >> > bind to port 0 is the right way.
> >> >
> >> > But if I remembered clearly, in Jetty based tests thread, someone
> >> objected
> >> > automatically select port.
> >> > "> What's the problem if the port is selected automatically?
> >> >
> >> > Repeatability. IMO, there should be no random elements in our
> testing.
> >> > That leads to frustration, fear, despair, pathos, pain, agony, angst
> >> and
> >> > much pulling of limited resources, like hair, in my case."
> >>
> >> That was me, and that was to ensure repeatability :) Of course, I had
> a
> >> slightly different notion of a test in mind, not one where the same
> >> thread is both the client and server. In fact, what I was imagining
> was
> >> that the server and client were in separate VMs at least, and separate
> >> machines too.
> >
> >
> > Great Geir!
> > If no one objects, I'm going to fix those "getNextPort()" codes in
> LUNI/NIO
> > module.
>
> Don't do it based on my ranting and raving. :)
>
> Instead of fixing it, should we stop using it?
Sure! :)
Any suggestions for blocking write/read tests ? :-)
geir
>
>
> ---------------------------------------------------------------------
> 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: RI's bug of Socket.getOutputStream().write(byte[]) ?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Andrew Zhang wrote:
> On 6/25/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>
>>
>>
>> Andrew Zhang wrote:
>> > On 6/23/06, Tim Ellison <t....@gmail.com> wrote:
>> >>
>> >> Andrew Zhang wrote:
>> >> > Hi Alexander,
>> >> >
>> >> > Thanks for your kind reminder.
>> >> >
>> >> > Certainly I'll use sth. like Support_PortManager.getNextPort() to
>> avoid
>> >> > such
>> >> > port conflict issue.
>> >>
>> >> No, please! Don't perpetuate that abomination<g>! Alexander is
>> right,
>> >> you should bind to port 0 and let the OS assign one.
>> >
>> >
>> > Yes, I agree that getNextPort doesn't really get the next free port,
>> and
>> > bind to port 0 is the right way.
>> >
>> > But if I remembered clearly, in Jetty based tests thread, someone
>> objected
>> > automatically select port.
>> > "> What's the problem if the port is selected automatically?
>> >
>> > Repeatability. IMO, there should be no random elements in our testing.
>> > That leads to frustration, fear, despair, pathos, pain, agony, angst
>> and
>> > much pulling of limited resources, like hair, in my case."
>>
>> That was me, and that was to ensure repeatability :) Of course, I had a
>> slightly different notion of a test in mind, not one where the same
>> thread is both the client and server. In fact, what I was imagining was
>> that the server and client were in separate VMs at least, and separate
>> machines too.
>
>
> Great Geir!
> If no one objects, I'm going to fix those "getNextPort()" codes in LUNI/NIO
> module.
Don't do it based on my ranting and raving. :)
Instead of fixing it, should we stop using it?
geir
---------------------------------------------------------------------
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: RI's bug of Socket.getOutputStream().write(byte[]) ?
Posted by Andrew Zhang <zh...@gmail.com>.
On 6/25/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
>
> Andrew Zhang wrote:
> > On 6/23/06, Tim Ellison <t....@gmail.com> wrote:
> >>
> >> Andrew Zhang wrote:
> >> > Hi Alexander,
> >> >
> >> > Thanks for your kind reminder.
> >> >
> >> > Certainly I'll use sth. like Support_PortManager.getNextPort() to
> avoid
> >> > such
> >> > port conflict issue.
> >>
> >> No, please! Don't perpetuate that abomination<g>! Alexander is right,
> >> you should bind to port 0 and let the OS assign one.
> >
> >
> > Yes, I agree that getNextPort doesn't really get the next free port, and
> > bind to port 0 is the right way.
> >
> > But if I remembered clearly, in Jetty based tests thread, someone
> objected
> > automatically select port.
> > "> What's the problem if the port is selected automatically?
> >
> > Repeatability. IMO, there should be no random elements in our testing.
> > That leads to frustration, fear, despair, pathos, pain, agony, angst and
> > much pulling of limited resources, like hair, in my case."
>
> That was me, and that was to ensure repeatability :) Of course, I had a
> slightly different notion of a test in mind, not one where the same
> thread is both the client and server. In fact, what I was imagining was
> that the server and client were in separate VMs at least, and separate
> machines too.
Great Geir!
If no one objects, I'm going to fix those "getNextPort()" codes in LUNI/NIO
module.
geir
>
> ---------------------------------------------------------------------
> 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: RI's bug of Socket.getOutputStream().write(byte[]) ?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Andrew Zhang wrote:
> On 6/23/06, Tim Ellison <t....@gmail.com> wrote:
>>
>> Andrew Zhang wrote:
>> > Hi Alexander,
>> >
>> > Thanks for your kind reminder.
>> >
>> > Certainly I'll use sth. like Support_PortManager.getNextPort() to avoid
>> > such
>> > port conflict issue.
>>
>> No, please! Don't perpetuate that abomination<g>! Alexander is right,
>> you should bind to port 0 and let the OS assign one.
>
>
> Yes, I agree that getNextPort doesn't really get the next free port, and
> bind to port 0 is the right way.
>
> But if I remembered clearly, in Jetty based tests thread, someone objected
> automatically select port.
> "> What's the problem if the port is selected automatically?
>
> Repeatability. IMO, there should be no random elements in our testing.
> That leads to frustration, fear, despair, pathos, pain, agony, angst and
> much pulling of limited resources, like hair, in my case."
That was me, and that was to ensure repeatability :) Of course, I had a
slightly different notion of a test in mind, not one where the same
thread is both the client and server. In fact, what I was imagining was
that the server and client were in separate VMs at least, and separate
machines too.
geir
---------------------------------------------------------------------
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: RI's bug of Socket.getOutputStream().write(byte[]) ?
Posted by Andrew Zhang <zh...@gmail.com>.
On 6/23/06, Tim Ellison <t....@gmail.com> wrote:
>
> Andrew Zhang wrote:
> > Hi Alexander,
> >
> > Thanks for your kind reminder.
> >
> > Certainly I'll use sth. like Support_PortManager.getNextPort() to avoid
> > such
> > port conflict issue.
>
> No, please! Don't perpetuate that abomination<g>! Alexander is right,
> you should bind to port 0 and let the OS assign one.
Yes, I agree that getNextPort doesn't really get the next free port, and
bind to port 0 is the right way.
But if I remembered clearly, in Jetty based tests thread, someone objected
automatically select port.
"> What's the problem if the port is selected automatically?
Repeatability. IMO, there should be no random elements in our testing.
That leads to frustration, fear, despair, pathos, pain, agony, angst and
much pulling of limited resources, like hair, in my case."
Additionally, getNextPort() is referenced many times in LUNI, NIO modules.
Most of them are used to avoid port conflict. Shall we fix those codes?
> 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?
>
> Perhaps you could tell us what you are testing on?
I want to test read/write function of Socket or SocketChannel (blocking
mode).
How could I verify whether the data are sent out successfully? Thanks!
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: RI's bug of Socket.getOutputStream().write(byte[]) ?
Posted by Tim Ellison <t....@gmail.com>.
Andrew Zhang wrote:
> Hi Alexander,
>
> Thanks for your kind reminder.
>
> Certainly I'll use sth. like Support_PortManager.getNextPort() to avoid
> such
> port conflict issue.
No, please! Don't perpetuate that abomination<g>! Alexander is right,
you should bind to port 0 and let the OS assign one.
> 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?
Perhaps you could tell us what you are testing on?
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: RI's bug of Socket.getOutputStream().write(byte[]) ?
Posted by Andrew Zhang <zh...@gmail.com>.
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
Re: RI's bug of Socket.getOutputStream().write(byte[]) ?
Posted by Alexander Kleymenov <kl...@gmail.com>.
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
Re: RI's bug of Socket.getOutputStream().write(byte[]) ?
Posted by Florian Weimer <fw...@deneb.enyo.de>.
* Tim Ellison:
>> Hmm, I think I was wrong. The scenario I had on mind can only occur
>> if the client also sends some data which is still in transit when the
>> server closes the connection. In this case, the server sends an RST
>> when that data arrives, and some clients discard all pending the data
>> they receive the RST.
>
> Yes, of course, but in this case the sender is doing the close(), so
> reading until -1 should be safe, right?
Yes, the important point is that the client does not send any data.
---------------------------------------------------------------------
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: RI's bug of Socket.getOutputStream().write(byte[]) ?
Posted by Tim Ellison <t....@gmail.com>.
Florian Weimer wrote:
> * Tim Ellison:
>
>> Thanks Florian, I need to go back and read Steven's more closely ;-) .
>> I have no doubt you are correct, but have never seen a close overtake
>> the data -- we should of course do it right.
>
> Hmm, I think I was wrong. The scenario I had on mind can only occur
> if the client also sends some data which is still in transit when the
> server closes the connection. In this case, the server sends an RST
> when that data arrives, and some clients discard all pending the data
> they receive the RST.
Yes, of course, but in this case the sender is doing the close(), so
reading until -1 should be safe, right?
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: RI's bug of Socket.getOutputStream().write(byte[]) ?
Posted by Florian Weimer <fw...@deneb.enyo.de>.
* Tim Ellison:
> Thanks Florian, I need to go back and read Steven's more closely ;-) .
> I have no doubt you are correct, but have never seen a close overtake
> the data -- we should of course do it right.
Hmm, I think I was wrong. The scenario I had on mind can only occur
if the client also sends some data which is still in transit when the
server closes the connection. In this case, the server sends an RST
when that data arrives, and some clients discard all pending the data
they receive the RST.
---------------------------------------------------------------------
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: RI's bug of Socket.getOutputStream().write(byte[]) ?
Posted by Andrew Zhang <zh...@gmail.com>.
On 6/25/06, Tim Ellison <t....@gmail.com> wrote:
>
> Thanks Florian, I need to go back and read Steven's more closely ;-) .
> I have no doubt you are correct, but have never seen a close overtake
> the data -- we should of course do it right.
>
> In such tests I would usually have a trivial protocol (i.e. sending a
> fixed-size length field first) so that the reader knows much to keep
> reading.
e.g, A wrote length = 100, then sent 100 bytes data,
B read the length field, then kept reading until 100 bytes data were
received.
But does it make sense? Still B maybe could hang on reading and never return
since A maybe didn't send out 100 bytes at all.
At least, RI hangs on in such case. Did I miss something?
Thanks!
Regards,
> Tim
>
> Florian Weimer wrote:
> > * Tim Ellison:
> >
> >> Maybe I'm misunderstanding the flow of the test here.
> >>
> >> here's how I read it...
> >>
> >> Server Side Client Side
> >> ----------- -----------
> >> 'server' listens on 1234
> >> 'channel' connects
> >> 'server' accepts
> >> 'out' sends 2xCAPACITY bytes
> >> 'out' flushes
> >> 'out' closes server end
> >> 'channel' reads in loop until -1
> >> assert that channel gets 2xCAPACITY
> bytes
> >>
> >>
> >> Is that right?
> >
> > In this case, the effects of the close operation can overtake the
> > data. You need the equivalent of shutdown(SHUT_WR) or
> > shutdown(SHUT_RDWR), or use some other form of synchronization.
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
>
> --
>
> 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: RI's bug of Socket.getOutputStream().write(byte[]) ?
Posted by Tim Ellison <t....@gmail.com>.
Thanks Florian, I need to go back and read Steven's more closely ;-) .
I have no doubt you are correct, but have never seen a close overtake
the data -- we should of course do it right.
In such tests I would usually have a trivial protocol (i.e. sending a
fixed-size length field first) so that the reader knows much to keep
reading.
Regards,
Tim
Florian Weimer wrote:
> * Tim Ellison:
>
>> Maybe I'm misunderstanding the flow of the test here.
>>
>> here's how I read it...
>>
>> Server Side Client Side
>> ----------- -----------
>> 'server' listens on 1234
>> 'channel' connects
>> 'server' accepts
>> 'out' sends 2xCAPACITY bytes
>> 'out' flushes
>> 'out' closes server end
>> 'channel' reads in loop until -1
>> assert that channel gets 2xCAPACITY bytes
>>
>>
>> Is that right?
>
> In this case, the effects of the close operation can overtake the
> data. You need the equivalent of shutdown(SHUT_WR) or
> shutdown(SHUT_RDWR), or use some other form of synchronization.
>
> ---------------------------------------------------------------------
> 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
>
>
--
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: RI's bug of Socket.getOutputStream().write(byte[]) ?
Posted by Florian Weimer <fw...@deneb.enyo.de>.
* Tim Ellison:
> Maybe I'm misunderstanding the flow of the test here.
>
> here's how I read it...
>
> Server Side Client Side
> ----------- -----------
> 'server' listens on 1234
> 'channel' connects
> 'server' accepts
> 'out' sends 2xCAPACITY bytes
> 'out' flushes
> 'out' closes server end
> 'channel' reads in loop until -1
> assert that channel gets 2xCAPACITY bytes
>
>
> Is that right?
In this case, the effects of the close operation can overtake the
data. You need the equivalent of shutdown(SHUT_WR) or
shutdown(SHUT_RDWR), or use some other form of synchronization.
---------------------------------------------------------------------
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: RI's bug of Socket.getOutputStream().write(byte[]) ?
Posted by Tim Ellison <t....@gmail.com>.
Maybe I'm misunderstanding the flow of the test here.
here's how I read it...
Server Side Client Side
----------- -----------
'server' listens on 1234
'channel' connects
'server' accepts
'out' sends 2xCAPACITY bytes
'out' flushes
'out' closes server end
'channel' reads in loop until -1
assert that channel gets 2xCAPACITY bytes
Is that right?
Regards,
Tim
Alex Blewitt wrote:
> Sometimes the close() can cause problems for the remote server, since
> it yanks the connection out. There's no particular guarantee that the
> server will have time to process the entire request and send you the
> results.
>
> Also, on some systems, closing the output stream can close the socket
> too, so you may never be able to read from it if you do this. I would
> strongly suggest moving the close to the end.
>
> Alex.
>
> On 23/06/06, Andrew Zhang <zh...@gmail.com> wrote:
>> Tim,
>>
>> Thank you very much. I revised the test case a little according to your
>> suggestion, but RI still fails sometimes.
>> Would you please review the test? The error message is: expected
>> <400> but
>> was: <200>
>> 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 serverSocket = server.accept();
>>
>> OutputStream out = serverSocket.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();
>> out.close();
>>
>> 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);
>> }
>>
>> Best regards,
>>
>> On 6/23/06, Tim Ellison <t....@gmail.com> wrote:
>> >
>> > Andrew,
>> >
>> > There is no guarantee that the out.flush() will actually send the bytes
>> > (it will just ensure that they get from Java to the OS). Indeed, there
>> > is no guaranteed way to force the TCP stack to send the bytes; but you
>> > can try by reducing the socket send buffer size (SO_SNDBUF) and setting
>> > no delay on (TCP_NODELAY). The best bet is to close the output stream
>> > socket when you have finished writing, and read until you get a -1 on
>> > the client.
>> >
>> > Regards,
>> > Tim
>> >
>> > Andrew Zhang wrote:
>> > > Hi everybody,
>> > >
>> > > It seems RI Socket.getOutputStream().write(byte[]) doesn't send all
>> > data
>> > > sometimes. Consider following test, which often blocks on RI:
>> > >
>> > > 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 serverSocket = server.accept();
>> > >
>> > > OutputStream out = serverSocket.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();
>> > >
>> > > ByteBuffer buf1 = ByteBuffer.allocate(CAPACITY_NORMAL);
>> > > ByteBuffer buf2 = ByteBuffer.allocate(CAPACITY_NORMAL);
>> > > ByteBuffer[] buf ={buf1, buf2};
>> > >
>> > > // should receive CAPACITY_NORMAL * 2 bytes data
>> > > // RI often hangs here, with CAPACITY_NORMAL bytes data
>> received.
>> > > long count = 0;
>> > > do{
>> > > count += channel.read(buf);
>> > > }while(count < CAPACITY_NORMAL*2);
>> > > assertEquals(CAPACITY_NORMAL * 2, count);
>> > > }
>> > >
>> > > I think it's a bug of RI. Am I missing something? Please correct
>> me if
>> > I'm
>> > > wrong. There're also some similar tests in NIO module with FIXME
>> mark.
>> > >
>> > > If it's a bug of RI, I'll raise a JIRA to tidy up those "FIXME" in
>> NIO.
>> > >
>> > > Thanks!
>> > >
>> > > Best regards,
>> > >
>> >
>> > --
>> >
>> > 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
>>
>>
>
> ---------------------------------------------------------------------
> 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
>
>
--
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: RI's bug of Socket.getOutputStream().write(byte[]) ?
Posted by Alex Blewitt <al...@gmail.com>.
Sometimes the close() can cause problems for the remote server, since
it yanks the connection out. There's no particular guarantee that the
server will have time to process the entire request and send you the
results.
Also, on some systems, closing the output stream can close the socket
too, so you may never be able to read from it if you do this. I would
strongly suggest moving the close to the end.
Alex.
On 23/06/06, Andrew Zhang <zh...@gmail.com> wrote:
> Tim,
>
> Thank you very much. I revised the test case a little according to your
> suggestion, but RI still fails sometimes.
> Would you please review the test? The error message is: expected <400> but
> was: <200>
> 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 serverSocket = server.accept();
>
> OutputStream out = serverSocket.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();
> out.close();
>
> 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);
> }
>
> Best regards,
>
> On 6/23/06, Tim Ellison <t....@gmail.com> wrote:
> >
> > Andrew,
> >
> > There is no guarantee that the out.flush() will actually send the bytes
> > (it will just ensure that they get from Java to the OS). Indeed, there
> > is no guaranteed way to force the TCP stack to send the bytes; but you
> > can try by reducing the socket send buffer size (SO_SNDBUF) and setting
> > no delay on (TCP_NODELAY). The best bet is to close the output stream
> > socket when you have finished writing, and read until you get a -1 on
> > the client.
> >
> > Regards,
> > Tim
> >
> > Andrew Zhang wrote:
> > > Hi everybody,
> > >
> > > It seems RI Socket.getOutputStream().write(byte[]) doesn't send all
> > data
> > > sometimes. Consider following test, which often blocks on RI:
> > >
> > > 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 serverSocket = server.accept();
> > >
> > > OutputStream out = serverSocket.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();
> > >
> > > ByteBuffer buf1 = ByteBuffer.allocate(CAPACITY_NORMAL);
> > > ByteBuffer buf2 = ByteBuffer.allocate(CAPACITY_NORMAL);
> > > ByteBuffer[] buf ={buf1, buf2};
> > >
> > > // should receive CAPACITY_NORMAL * 2 bytes data
> > > // RI often hangs here, with CAPACITY_NORMAL bytes data received.
> > > long count = 0;
> > > do{
> > > count += channel.read(buf);
> > > }while(count < CAPACITY_NORMAL*2);
> > > assertEquals(CAPACITY_NORMAL * 2, count);
> > > }
> > >
> > > I think it's a bug of RI. Am I missing something? Please correct me if
> > I'm
> > > wrong. There're also some similar tests in NIO module with FIXME mark.
> > >
> > > If it's a bug of RI, I'll raise a JIRA to tidy up those "FIXME" in NIO.
> > >
> > > Thanks!
> > >
> > > Best regards,
> > >
> >
> > --
> >
> > 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
>
>
---------------------------------------------------------------------
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: RI's bug of Socket.getOutputStream().write(byte[]) ?
Posted by Andrew Zhang <zh...@gmail.com>.
Tim,
Thank you very much. I revised the test case a little according to your
suggestion, but RI still fails sometimes.
Would you please review the test? The error message is: expected <400> but
was: <200>
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 serverSocket = server.accept();
OutputStream out = serverSocket.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();
out.close();
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);
}
Best regards,
On 6/23/06, Tim Ellison <t....@gmail.com> wrote:
>
> Andrew,
>
> There is no guarantee that the out.flush() will actually send the bytes
> (it will just ensure that they get from Java to the OS). Indeed, there
> is no guaranteed way to force the TCP stack to send the bytes; but you
> can try by reducing the socket send buffer size (SO_SNDBUF) and setting
> no delay on (TCP_NODELAY). The best bet is to close the output stream
> socket when you have finished writing, and read until you get a -1 on
> the client.
>
> Regards,
> Tim
>
> Andrew Zhang wrote:
> > Hi everybody,
> >
> > It seems RI Socket.getOutputStream().write(byte[]) doesn't send all
> data
> > sometimes. Consider following test, which often blocks on RI:
> >
> > 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 serverSocket = server.accept();
> >
> > OutputStream out = serverSocket.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();
> >
> > ByteBuffer buf1 = ByteBuffer.allocate(CAPACITY_NORMAL);
> > ByteBuffer buf2 = ByteBuffer.allocate(CAPACITY_NORMAL);
> > ByteBuffer[] buf ={buf1, buf2};
> >
> > // should receive CAPACITY_NORMAL * 2 bytes data
> > // RI often hangs here, with CAPACITY_NORMAL bytes data received.
> > long count = 0;
> > do{
> > count += channel.read(buf);
> > }while(count < CAPACITY_NORMAL*2);
> > assertEquals(CAPACITY_NORMAL * 2, count);
> > }
> >
> > I think it's a bug of RI. Am I missing something? Please correct me if
> I'm
> > wrong. There're also some similar tests in NIO module with FIXME mark.
> >
> > If it's a bug of RI, I'll raise a JIRA to tidy up those "FIXME" in NIO.
> >
> > Thanks!
> >
> > Best regards,
> >
>
> --
>
> 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: RI's bug of Socket.getOutputStream().write(byte[]) ?
Posted by Tim Ellison <t....@gmail.com>.
Andrew,
There is no guarantee that the out.flush() will actually send the bytes
(it will just ensure that they get from Java to the OS). Indeed, there
is no guaranteed way to force the TCP stack to send the bytes; but you
can try by reducing the socket send buffer size (SO_SNDBUF) and setting
no delay on (TCP_NODELAY). The best bet is to close the output stream
socket when you have finished writing, and read until you get a -1 on
the client.
Regards,
Tim
Andrew Zhang wrote:
> Hi everybody,
>
> It seems RI Socket.getOutputStream().write(byte[]) doesn't send all data
> sometimes. Consider following test, which often blocks on RI:
>
> 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 serverSocket = server.accept();
>
> OutputStream out = serverSocket.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();
>
> ByteBuffer buf1 = ByteBuffer.allocate(CAPACITY_NORMAL);
> ByteBuffer buf2 = ByteBuffer.allocate(CAPACITY_NORMAL);
> ByteBuffer[] buf ={buf1, buf2};
>
> // should receive CAPACITY_NORMAL * 2 bytes data
> // RI often hangs here, with CAPACITY_NORMAL bytes data received.
> long count = 0;
> do{
> count += channel.read(buf);
> }while(count < CAPACITY_NORMAL*2);
> assertEquals(CAPACITY_NORMAL * 2, count);
> }
>
> I think it's a bug of RI. Am I missing something? Please correct me if I'm
> wrong. There're also some similar tests in NIO module with FIXME mark.
>
> If it's a bug of RI, I'll raise a JIRA to tidy up those "FIXME" in NIO.
>
> Thanks!
>
> Best regards,
>
--
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