RFR: 8213942:URLStreamHandler initialization race
sean.coffey at oracle.com
Tue Nov 20 20:43:33 UTC 2018
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.
>> 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.
More information about the net-dev