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
