RFR: 8213942:URLStreamHandler initialization race

Alan Bateman Alan.Bateman at oracle.com
Tue Nov 20 19:07:50 UTC 2018

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?


More information about the net-dev mailing list