river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon IJskes - QCG <si...@qcg.nl>
Subject Re: svn commit: r1412436 - /river/jtsk/trunk/qa/src/com/sun/jini/qa/harness/MasterHarness.java
Date Thu, 22 Nov 2012 09:39:13 GMT
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 

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 

Gr. Simon

QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397

View raw message