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

[Andrew Leonard]

Thanks for the feedback Alan. I think i'm going to have to defer on this 
issue for the moment, as I dont' have enough experience with JDI usecases 
to accurately study this at the moment. I think you have also demonstrated 
my "rustiness" in thread-safety issues, I think I will go and brush up!!

Should we create a separate bug to update the spec/doc to clarify the 
position on JDI Connectors being non-thread-safe, or is the current 
non-statement the normal stance on this one?

Thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
internet email: andrew_m_leonard at uk.ibm.com 




From:   Alan Bateman <Alan.Bateman at oracle.com>
To:     Andrew Leonard <andrew_m_leonard at uk.ibm.com>
Cc:     serviceability-dev at openjdk.java.net
Date:   14/06/2019 17:06
Subject:        Re: RFR JDK-8225474: JDI connector accept fails "Address 
already in use" with concurrent listeners



On 14/06/2019 15:52, Andrew Leonard wrote:
In doing the recent changes I applied knowledge of how the ConnectorImpl 
and its defaultArguments are used to decide on what is necessary from a 
threading perspective. I also am only considering the "listening" 
concurrency issue, at this stage, and was not considering making all the 
jdi classes thread-safe. 
Sure but default arguments exposed in the ListeningConnector API are 
mutable. It may be that debuggers and other tools aren't changing them but 
we can't say that the GenericListeningConnector and its implementations 
are safe for by use by concurrent threads without studying this further. 
Also the comments about changing fields to final are not optimizations, 
that are suggestions to allow GenericListeningConnector objects be safely 
published.

-Alan


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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