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
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397