On 20/11/2018 19:07, Alan Bateman wrote:
On 20/11/2018 17:55, Seán Coffey wrote:
A race condition recently reported by the WLS team. Access to the
handlers Hashtable and the factory should be made while holding the
streamHandlerLock lock.
WLS team also made efforts to create a reproducer. I've modified to
jtreg format and reduced it down further for unit testing.
https://bugs.openjdk.java.net/browse/JDK-8213942
webrev: http://cr.openjdk.java.net/~coffeys/webrev.8213942/webrev/
Most URLs are created without specifying a handler so it means
creating a URL will go through getURLStreamHandler most of the time.
So I think we want to avoid locking on that code path where possible.
It's sad that handlers is a Hashtable but I think it makes it worse to
have it always synchronize on streamHandlerLock. Reading this code
makes me want to replace handlers and replace it with fully concurrent
lookups but I realize you might not want to go there for this issue
(as I assume you are looking to back-port it). Assuming you don't want
a re-write, have you considered always retrying handles.get(protocol)
when you acquire the lock?
I'll consider reworking this area Alan. Like you say, if we're
backporting, then less change could be better.
I tried the re-trying approach but didn't get the desired results. I
think the factory Object needs to be read/set while holding the lock
also. Will take a closer look tomorrow.
regards,
Sean.
-Alan
