RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners

[Alan Bateman]

On 10/06/2019 09:30, Andrew Leonard wrote:
> Thanks for the feedback everyone.
>
> Hi Alan, yes I can put some cycles into digging deeper with this one, 
> as you point out there's probably more that needs doing.
> As Alex found running the new testcase 400 times it failed once still, 
> interestingly during initial startListening() rather than the accept() 
> where it was failing before.
> On a general issue of "thread-safety", I had a good look through the 
> spec docs and architecture docs and couldn't find any specification of 
> thread-safety(or not), should it be inferred if the docs don't 
> specifically state "thread-safe" that it should be assumed as 
> "not-thread safe"?
Right, Connectors aren't specified to be thread safe so any test that 
assumes otherwise is an issue (there may be a second issue here with a 
test using a fixed TCP port, it sounds like you might be running into 
both issues).

I've no objection to changing GenericListeningConnector to be thread 
safe. Also no issue with exploring the impact of a spec change too. 
Although Connectors (and transports) are pluggable, there probably 
aren't too many implementations outside of the JDK so you might have 
some scope to go beyond recommending that implementations be thread safe.

I've read your other mails where you've done some exploration into 
startListening/stopListening but I think there is more to do. Minimally 
I think startListening will need synchronization, alternatively changed 
to use putIfAbsent and stop the transport listening if it looses the 
race. There is also an issue with stopListening. It requires looking at 
the super class too because ConnectorImpl is not thread safe, esp. the 
defaultArguments which is a separate mutable map to listenMap.

-Alan



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20190612/f7d3e620/attachment.html>