RFR: 8232853: AuthenticationFilter.Cache::remove may throw ConcurrentModificationException

[Martin Buchholz]

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.boes at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20191102/c01fce63/attachment.html>