On 6/23/06, Tim Ellison <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) IBM Java technology centre, UK. --------------------------------------------------------------------- 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
