From: "Jeroen Frijters" <jeroen@sumatra.nl>
To: "Casey Marshall" <csm@gnu.org>
Cc: <mauve-discuss@sourceware.org>
Subject: RE: New SocketChannel test that requires testing
Date: Tue, 19 Sep 2006 05:32:00 -0000 [thread overview]
Message-ID: <D92197D0A6547B44A1567814F851FA6827A999@LEMBU.sumatrasoftware.com> (raw)
In-Reply-To: <450F2199.9010501@gnu.org>
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
> 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
Hmm, that's unfortunate. I don't know of any other way to reliably build
a test for these things. Thanks for testing this.
> I think this is because that connect is, indeed, eating up a
> slot in the backlog, but the kernel allowed the connection anyway.
> So as far as the client SocketChannel is concerned, it's connected,
> and the socket is writable.
>
> 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).
Regards,
Jeroen
next prev parent reply other threads:[~2006-09-19 5:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-18 11:30 Jeroen Frijters
2006-09-18 22:45 ` Casey Marshall
2006-09-19 5:32 ` Jeroen Frijters [this message]
2006-09-19 8:08 ` Casey Marshall
2006-09-19 8:21 ` Jeroen Frijters
2006-09-19 18:36 ` Casey Marshall
2006-09-20 4:34 ` Jeroen Frijters
2006-09-20 5:14 ` Casey Marshall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D92197D0A6547B44A1567814F851FA6827A999@LEMBU.sumatrasoftware.com \
--to=jeroen@sumatra.nl \
--cc=csm@gnu.org \
--cc=mauve-discuss@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).