On Tue, 11 Jan 2005, Steve Cohen [EMAIL PROTECTED] wrote:
Checked in refactored test that hopefully will not break under GUMP
Stefan, please let me know how it works.
Great - Gump build on Sun JDKs passes now (tests fail in the Kaffe
build in various places, probably Kaffe's fault).
Stefan
On Tue, 11 Jan 2005, Steve Cohen [EMAIL PROTECTED] wrote:
Checked in refactored test that hopefully will not break under GUMP
Stefan, please let me know how it works.
The last Gump run started too early, I think, so one more nag is to be
expected. We'll see after that.
Stefan
I thought they just used some unused ports for the test.
That's just it, though. On Gump, these ports do NOT seem to be unused.
The test simply assumes that these three ports are unused and fails if
they aren't. I think the openConnections() method of this class should
look within some
Checked in refactored test that hopefully will not break under GUMP
Stefan, please let me know how it works.
Steve Cohen wrote:
I thought they just used some unused ports for the test.
That's just it, though. On Gump, these ports do NOT seem to be unused.
The test simply assumes that these
Has anyone had a chance to look at this?
The root of the problem seems to be that the test assumes that it should
always be able to open three sockets at ports , 3334, and 3335,
which it tries to do in the initalizing method openConnections(). On
Gump, this fails, presumably because one of
I should have said On Gump, this fails, presumably because one of these
sockets is sometimes in use.
Steve Cohen wrote:
Has anyone had a chance to look at this?
The root of the problem seems to be that the test assumes that it should
always be able to open three sockets at ports , 3334, and
I'm not sure about those tests and if they need to be looking at
specific ports, I thought they just used some unused ports for the test.
We could also move them into the test:functional section so the build is
not dependant on them, but then we loose the continual testing benefit.
Steve Cohen