You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Steven Schlansker (Jira)" <ji...@apache.org> on 2023/04/27 21:43:00 UTC

[jira] [Commented] (KAFKA-14942) CopyOnWriteMap implements ConcurrentMap but does not implement required default methods

    [ https://issues.apache.org/jira/browse/KAFKA-14942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717388#comment-17717388 ] 

Steven Schlansker commented on KAFKA-14942:
-------------------------------------------

Ah, I am sorry, I made a mistake in this analysis. The ConcurrentMap interface replaces the default Map implementations with more advanced ones. So that should probably not be a problem.

> CopyOnWriteMap implements ConcurrentMap but does not implement required default methods
> ---------------------------------------------------------------------------------------
>
>                 Key: KAFKA-14942
>                 URL: https://issues.apache.org/jira/browse/KAFKA-14942
>             Project: Kafka
>          Issue Type: Bug
>          Components: clients
>    Affects Versions: 3.4.0
>            Reporter: Steven Schlansker
>            Priority: Minor
>
> Hi Kafka team,
> I was reading through the kafka-clients CopyOnWriteMap while investigating a problem in a different library, and I think it is declaring that it is a ConcurrentMap but does not completely implement that interface.
> In particular, it inherits e.g. computeIfAbsent as a default method from Map, which is noted to be a non-atomic implementation, and is not synchronized in any way. I think this can lead to a reader experiencing a map whose contents are not consistent with any serial execution of write ops.
>  
> Consider a thread T1 which calls computeIfAbsent("a", _ -> "1")
> T1 computeIfAbsent calls get("a") and observes null, and is then pre-empted
> T2 calls put("a", "2"), which copies the (empty) backing map and stores \{"a": "2"}
> T1 computeIfAbsent then wakes up, still thinking the value is null, and calls put("a", "1").
>  
> This leads to the map finishing with the contents \{"a":"1"}, while any serial execution of these two operations should always finish with \{"a":"2"}.
>  
> I think CopyOnWriteMap should either re-implement all mutating default methods at least as synchronized. If this is a special internal map and we know those will never be called, perhaps they should throw UnsupportedOperationException or at least document the class as not a complete and proper implementation.
>  
> Thank you for your consideration.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)