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 Tue, 26 Dec 2006 17:06:57 GMT
> I'm OK with both this interesting approach and fixed port. :) btw, it
> doesn't solve port confliction thoroughly in theory. Other applications
may
> open the "free" port during close and open.
Agree.

So i'll ask Alexei to integrate my patch and if it does not work for some
reasons - i'll prepare another patch with fixed port number provided by a
property.

Regards,
Mikhail

On 12/26/06, Andrew Zhang <zhanghuangzhu@gmail.com> wrote:
>
> On 12/26/06, Mikhail Markov <mikhail.a.markov@gmail.com> wrote:
> >
> > > No. But at least we need to test the behaviour of ServerSocket(fixed
> > port)
> > > constructor once. For example, if I implemented ServerSocket(int port)
> > as
> > > follows:
> > > public ServerSocket(int port) {
> > >   port = 0;
> > >   // no matter what the port is, the constructor always constructs a
> > server
> > > socket with free port
> > > }
> > > It's obviously wrong, but can any test detect this error?
> > I could suggest something like this:
> > ServerSocket ss = ServerSocket(0);
> > int fixedPort = ss.getLocalPort();
> > ss.close();
> > ServerSocket ssUnderTest = new ServerSocket(fixedPort);
> > // test if opened ServerSocket listens on port "fixedPort"
> > // even if SS is set the port internally to 0 - this code will find the
> > bug
> > :-)
> >
> > Yes, yes - i could guess your argument "What if first SS not actually
> > close
> > the connection but reuse it?" :-).
> > Well - let's consider this as one of 2 axiom:
> > 1) ServerSocket(0) really choose non-busy port (BTW, this is not tested
> in
> > ServerSocketTest at all, but i do understand that this is hard to test)
> > 2) close() method really close an open SS (this assumption is tested by
> > ServerSocketTest.test_close() method).
> > Also, for example, ServerSocketTest.test_ConstructorII() calls
> > getNextPort() 3 times, so we need either to reserve 3 ports for testing
> or
> > reuse 1 port 3 times. Thoughts?
>
>
> I'm OK with both this interesting approach and fixed port. :) btw, it
> doesn't solve port confliction thoroughly in theory. Other applications
> may
> open the "free" port during close and open.
>
> Regards,
> > Mikhail
> >
> >
> > On 12/26/06, Andrew Zhang <zhanghuangzhu@gmail.com> wrote:
> > >
> > > On 12/25/06, Mikhail Markov <mikhail.a.markov@gmail.com> wrote:
> > > >
> > > > 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?
> > >
> > >
> > > No. But at least we need to test the behaviour of ServerSocket(fixed
> > port)
> > > constructor once. For example, if I implemented ServerSocket(int port)
> > as
> > > follows:
> > > public ServerSocket(int port) {
> > >   port = 0;
> > >   // no matter what the port is, the constructor always constructs a
> > > server
> > > socket with free port
> > > }
> > > It's obviously wrong, but can any test detect this error?
> > >
> > > 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
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Best regards,
> > > Andrew Zhang
> > >
> > >
> >
> >
>
>
> --
> Best regards,
> Andrew Zhang
>
>

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