harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Markov" <mikhail.a.mar...@gmail.com>
Subject Re: [classlib][luni] java.net.ServerSocketTest fails - need help
Date Mon, 25 Dec 2006 14:21:22 GMT
Thank you for your warm words!

> But without fixed port meaning that we never test the behaviour of
> ServerSocket(1000).
> That's why I suggest to introduce fixed port for ServerSocket constructor
> test.
> My suggestion is not to discard your patch, but using your patch + fixed
> port to replace current getNextPort machenism. Does it make sense? Thanks!
Why my approach does not work in this case?
For example:
void test_ServerSocketCosntructor() {
...
    int port = getNextPort(); // got free port number
    ServerSocket ss = new ServerSocket(port);

    // tests ServerSocket opened on fixed port here
    // checks if ServerSocket listens on this port etc.
...
}
Or testing ServerSocket each time on the same port number is critical?

Regards,
Mikhail

On 12/25/06, Andrew Zhang <zhanghuangzhu@gmail.com> wrote:
>
> On 12/25/06, Mikhail Markov <mikhail.a.markov@gmail.com> wrote:
> >
> > > Hey Mikhail, I think I have agreed with all  your words in my previous
> > > letter. We've agreed to use port 0 for most network tests. Fixed port
> > number
> > > is required sometimes, i.e., how do you write test for
> ServerSocket(int
> > > port)?
> > Sorry, Andrew - I did not participated in original discussion and Alexei
> > in
> > http://issues.apache.org/jira/browse/HARMONY-2338 said that he
> > understands the final decision as we will use reserved ports numbers -
> so
> > I've decided to re-check once again.
> >
> > > We'd better test ServerSocket constructor with both legal value(not
> > > only 0, but also some positive numbers), and illegal value. That's
> where
> > > fixed port number is used. Make sense? Thanks!
> > Why not use ServerSocket(0) to just *obtain* some positive non-busy port
> > number (and close it after port number obtaining) and after that test
> > ServerSocket constructor with this obtained port number? In this case
> > we'll
> > not require any reserved ports at all.
> > I've implemented this approach and attached the patch - could you please
> > take a look at it?
>
>
> Hi Mikhail, the patch is good! I agree that it's a good fix as always. :-)
> But without fixed port meaning that we never test the behaviour of
> ServerSocket(1000).
> That's why I suggest to introduce fixed port for ServerSocket constructor
> test.
> My suggestion is not to discard your patch, but using your patch + fixed
> port to replace current getNextPort machenism. Does it make sense? Thanks!
>
> Thanks,
> > Mikhail
> >
> >
> > On 12/24/06, Andrew Zhang <zhanghuangzhu@gmail.com> wrote:
> > >
> > > On 12/24/06, Mikhail Markov <mikhail.a.markov@gmail.com> wrote:
> > > >
> > > > I still don't like using fixed port numbers. Moreover, some tests
> > might
> > > > require several ports for testing.
> > > > I did not see any objections against using 0 as a port number,
> except
> > > that
> > > > some functionality should be tested with fixed port numbers.
> > > > How about the following scheme for *finding* non-busy port:
> > > > 1) invoke ServerSocket(0) constructor
> > > > 2) get the port where ServerSocket opened the socket
> > > > 3) close ServerSocket
> > > > 4) use the stored port from 2-nd step for further testing (it could
> be
> > > > Socket/ServerSocket/nio tests etc.)
> > > >
> > > > What do you think?
> > >
> > >
> > > Hey Mikhail, I think I have agreed with all  your words in my previous
> > > letter. We've agreed to use port 0 for most network tests. Fixed port
> > > number
> > > is required sometimes, i.e., how do you write test for
> ServerSocket(int
> > > port)? We'd better test ServerSocket constructor with both legal
> > value(not
> > > only 0, but also some positive numbers), and illegal value. That's
> where
> > > fixed port number is used. Make sense? Thanks!
> > >
> > > Thanks,
> > > > Mikhail
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message