New SocketChannel test that requires testing

Hi,

I've written a new test case for SocketChannel and I require some
assistance testing it on different platforms (and/or opinions on it)
because it uses a trick and I would like to know if the trick is
reliable or not.

The trick is that it creates a server socket with a backlog of 1 and
then it fills up that backlog queue by initiating a connection to make
sure that a subsequent connection attempt will block (to test if
asynchronous connections work correctly).

I tested this on Windows (JDK 1.5 and IKVM) and I would appreciate it if
people would run this test on their platform of choice. Other feedback
on the validity of this approach is also appreciated.

Thanks,
Jeroen

// Tags: JDK1.4

// Copyright (C) 2006 Jeroen Frijters

// This file is part of Mauve.

// Mauve is free software; you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation; either version 2, or (at your option)
// any later version.

Re: New SocketChannel test that requires testing

Jeroen Frijters wrote:
> Hi,
> 
> I've written a new test case for SocketChannel and I require some
> assistance testing it on different platforms (and/or opinions on it)
> because it uses a trick and I would like to know if the trick is
> reliable or not.
> 
> The trick is that it creates a server socket with a backlog of 1 and
> then it fills up that backlog queue by initiating a connection to make
> sure that a subsequent connection attempt will block (to test if
> asynchronous connections work correctly).
> 
> I tested this on Windows (JDK 1.5 and IKVM) and I would appreciate it if
> people would run this test on their platform of choice. Other feedback
> on the validity of this approach is also appreciated.
> 

It doesn't quite work for me (jamvm+classpath CVS and java 1.5; both on
OSX/x86). I get two fails with classpath:

  FAIL: java.nio.channels.SocketChannel.tests
    line 65: initiate async connect [2] -- boolean passed to check was false
    line 67: initiate async connect [4] -- boolean passed to check was false

And one with Sun/Apple Java:

  FAIL: java.nio.channels.SocketChannel.tests
    line 67: initiate async connect [4] -- boolean passed to check was false

RE: New SocketChannel test that requires testing

Casey Marshall wrote:
> Jeroen Frijters wrote:
> > Hi,
> > 
> > I've written a new test case for SocketChannel and I require some
> > assistance testing it on different platforms (and/or opinions on it)
> > because it uses a trick and I would like to know if the trick is
> > reliable or not.
> > 
> > The trick is that it creates a server socket with a backlog of 1 and
> > then it fills up that backlog queue by initiating a 
> connection to make
> > sure that a subsequent connection attempt will block (to test if
> > asynchronous connections work correctly).
> > 
> > I tested this on Windows (JDK 1.5 and IKVM) and I would 
> appreciate it if
> > people would run this test on their platform of choice. 
> Other feedback
> > on the validity of this approach is also appreciated.
> > 
> 
> It doesn't quite work for me (jamvm+classpath CVS and java 
> 1.5; both on
> OSX/x86). I get two fails with classpath:
> 
>   FAIL: java.nio.channels.SocketChannel.tests
>     line 65: initiate async connect [2] -- boolean passed to 
> check was false
>     line 67: initiate async connect [4] -- boolean passed to 

Re: New SocketChannel test that requires testing

Jeroen Frijters wrote:
> Casey Marshall wrote:
>> Maybe we are wrong for returning true for `isConnected' that 
>> early after trying to establish the connection; the test we're using
>> is whether or not the socket has a remote address or not, which may
>> not be the criteria we're interested in.
> 
> Yes, I believe that's incorrect. I think you can only transition into
> the connected state by calling finishConnect (if connect was called in
> non-blocking mode).
> 

That's not necessarily true; on some systems, even a non-blocking call
to connect() can succeed immediately, if you are connecting to the local
machine. It doesn't sound right that you get this condition even when
the server process hasn't pulled the connection off the queue, but that
may be how it works.

I wonder, now, if this is an artifact of our (new) RI: we call a
nonblocking connect() every time, then select() on the server's FD to
handle the blocking case, with timeout. This may be doing the wrong
thing with nonblocking sockets.

Thanks.

RE: New SocketChannel test that requires testing

Casey Marshall wrote:
> Jeroen Frijters wrote:
> > Casey Marshall wrote:
> >> Maybe we are wrong for returning true for `isConnected' that 
> >> early after trying to establish the connection; the test 
> we're using
> >> is whether or not the socket has a remote address or not, which may
> >> not be the criteria we're interested in.
> > 
> > Yes, I believe that's incorrect. I think you can only 
> transition into
> > the connected state by calling finishConnect (if connect 
> was called in
> > non-blocking mode).
> > 
> 
> That's not necessarily true; on some systems, even a non-blocking call
> to connect() can succeed immediately, if you are connecting 
> to the local machine. It doesn't sound right that you get this
> condition even when the server process hasn't pulled the connection
> off the queue, but that may be how it works.

I don't think it has nothing to do with the underlying socket mechanics,
it is simply an invariant of the SocketChannel API.

Regards,
Jeroen

Re: New SocketChannel test that requires testing

Jeroen Frijters wrote:
> Casey Marshall wrote:
>> Jeroen Frijters wrote:
>>> Casey Marshall wrote:
>>>> Maybe we are wrong for returning true for `isConnected' that 
>>>> early after trying to establish the connection; the test 
>> we're using
>>>> is whether or not the socket has a remote address or not, which may
>>>> not be the criteria we're interested in.
>>> Yes, I believe that's incorrect. I think you can only 
>> transition into
>>> the connected state by calling finishConnect (if connect 
>> was called in
>>> non-blocking mode).
>>>
>> That's not necessarily true; on some systems, even a non-blocking call
>> to connect() can succeed immediately, if you are connecting 
>> to the local machine. It doesn't sound right that you get this
>> condition even when the server process hasn't pulled the connection
>> off the queue, but that may be how it works.
> 
> I don't think it has nothing to do with the underlying socket mechanics,
> it is simply an invariant of the SocketChannel API.
> 

Nope:

"If this channel is in non-blocking mode then an invocation of this
method initiates a non-blocking connection operation. If the connection
is established immediately, as can happen with a local connection, then

RE: New SocketChannel test that requires testing

Casey Marshall wrote:
> > I don't think it has nothing to do with the underlying 
> > socket mechanics,
> > it is simply an invariant of the SocketChannel API.
> 
> Nope:
> 
> "If this channel is in non-blocking mode then an invocation of this
> method initiates a non-blocking connection operation. If the 
> connection is established immediately, as can happen with a local 
> connection, then this method returns true. Otherwise this method
> returns false and the connection operation must later be completed
> by invoking the finishConnect method." [1]
> 
> 1.
> http://java.sun.com/j2se/1.4.2/docs/api/java/nio/channels/Sock
> etChannel.html#connect(java.net.SocketAddress)

May be I misunderstood what you meant, we were talking about
isConnected() changing its return value right? The only way I can read
the text you quoted is that it confirms that isConnected() will only
return true iff either connect() or finishConnect() previously returned
true.

Regards,
Jeroen

Re: New SocketChannel test that requires testing

Jeroen Frijters wrote:
> May be I misunderstood what you meant, we were talking about
> isConnected() changing its return value right? The only way I can read
> the text you quoted is that it confirms that isConnected() will only
> return true iff either connect() or finishConnect() previously returned
> true.
> 

Oops, yeah. I was thinking of connect()'s return value.

multidirectbufferIO and multibufferIO

These two tests, in gnu.testlet.java.nio.channels.FileChannel, look a
bit bogus to me. They test if FileChannel artificially limits the number
of buffers processed in scattering/gathering read/write to 16, which is
definitely the case if the underlying implementation uses readv and
writev, but this limit isn't required otherwise (at least, there is no
mention of any limit in the JDK docs).

I don't see that much point in using readv/writev for file I/O, anyway,
especially because there do seem to be bugs in our implementation of it.
And at any rate, there's no guarantee that on some other system there
would be any limit like this, or if there is, that it would be the same
as it is on POSIXy systems.

Re: multidirectbufferIO and multibufferIO

>>>>> "Casey" == Casey Marshall <csm@...> writes:

Casey> I don't see that much point in using readv/writev for file I/O, anyway,
Casey> especially because there do seem to be bugs in our implementation of it.

Can you ask the guy who wrote this code in Classpath about his
motivations?  I don't remember them, and it would be good to know what
drove the implementation before we look at removing it.

Tom