Only freebsd openjdk is suffering socket issues now.
I'll be cleaning up and removing hacks where relevant shortly.
I'm waiting for the Ubuntu openjdk test run to complete, that should
help determine if it's freebsd or openjdk at issue, it could be those
ports just aren't available.
A netstat output at the point when failure occurs would be very helpful
and any help is much appreciated.
Regards,
Peter.
On 22/11/2012 7:39 PM, Simon IJskes - QCG wrote:
On 22-11-12 10:18, Peter Firmstone wrote:
I tried SO_REUSEADDR on an earlier attempt, that didn't work either,
that was a hack too.
In general, i do not consider SO_REUSEADDR a hack. It is a perfectly
permissable construct for servers.
The real fix will is to have the client close the port, rather than the
server, but since I don't have direct access to this box, I can't really
tell if that's the actual problem or if those ports aren't available at
all.
You cannot dictate the behaviour of a client. So any solution needs to
be robust enough, to behave correctly independent of the client. TCP
is such a solution. There are problems with the TCP protocol,
exploited by malicious parties, but they are not manifesting themselfs
in the test environment.
So we could have a number of possible causes:
- incorrect assumptions or bugs in the java program.
- bugs in the java VM Socket implementation.
- bugs in the TCP stack.
There are a number of instances where an interrupt is not triggered in
some system calls. Therefore a plausible cause is ServerSockets that
are not really interrupted. Or not closed by java instances of
ourselfs not correctly terminated.
You could try to make a class, that reports with the use of the
'netstat' program which ports are in use and what status they have, to
be triggered at the problem points.
I can help you with that, but only if you stop making those 'just try'
patches, and with improved communication (improved in quality, not
verbosity).
Gr. Simon
