Hi Julia, I think this is the wrong fix.
Looking at the Cache class - all the methods are synchronized, so it looks like any failure is not actually due to concurrent execution, but any bug can be reproduced in a single thread. (please add such a repro to the bug report) It looks like Cache#remove can be fixed simply by using an explicit iterator and using iterator#remove instead of List#remove. Cache looks fishy in other ways, e.g. why does Cache#remove ignore authscheme? (Yes, proper caching infrastructure should be added to the JDK someday, but that's a big project) On Fri, Nov 1, 2019 at 9:48 AM Julia Boes <julia.b...@oracle.com> wrote: > Hi, > > This fix addresses an issue in AuthenticationFilter.Cache::remove that > can lead to a ConcurrentModificationException. The cache is implemented > as LinkedList, the method iterates over the list and potentially removes > items without using an iterator. > > To reproduce the bug, multiple requests are sent asynchronously so that > successful response headers might arrive concurrently and compete in > updating the cache. This increases the chances to trigger the removal of > a previously cached credential while storing the credentials of the next > response. Under these circumstances, ConcurrentModificationException is > thrown with very high frequency (if not always). > > The proposed fix replaces LinkedList with CopyOnWriteArrayList to > preclude the exception. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232853 > > Webrev: > http://cr.openjdk.java.net/~jboes/webrevs/8232853/webrev.01/index.html > > The test fails reliably without the fix, and passes with it (jdk_net > tests run 50 times). > > > Regards, > > Julia > > >
