RFR: 8213942:URLStreamHandler initialization race

Seán Coffey 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.
>> 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.

> -Alan

More information about the net-dev mailing list