[
https://issues.apache.org/jira/browse/NIFI-15917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18079490#comment-18079490
]
ASF subversion and git services commented on NIFI-15917:
--------------------------------------------------------
Commit 9148f1ba28d642ce6c070fefbd791c38d9edb4e0 in nifi's branch
refs/heads/main from Mark Payne
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=9148f1ba28d ]
NIFI-15917 Fixed potential corruption with modify-after-write on Local State
Provider (#11220)
When creating a StandardStateMap, create a defensive copy of the provided map
to avoid allowing modifications by the extension after state is stored to alter
the internal state.
Signed-off-by: David Handermann <[email protected]>
> If an extension stores Local state and then modifies the Map, it could lead
> to a corrupted stored state
> -------------------------------------------------------------------------------------------------------
>
> Key: NIFI-15917
> URL: https://issues.apache.org/jira/browse/NIFI-15917
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
> Reporter: Mark Payne
> Assignee: Mark Payne
> Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> If an extension does something like this:
> {code:java}
> private final Map<String, String> state = new ConcurrentHashMap<>();
> private final AtomicLong counter = new AtomicLong(0L);
> public void onTrigger(...) {
> state.put("invocation", String.valueOf(counter.getAndIncrement()));
> session.setState(state);
> } {code}
> What gets written to the state journal when the session commit is performed
> is correct.
> However, at some time later, when the WriteAhead Repository checkpoints, it
> uses a reference to that same `state` Map rather than a defensive copy. So
> the checkpoint may have a very different value than what was written to the
> journal.
> Further, if timing is just write, it may write out the number of entries as
> `n` and then write out `m` different entries. For example, if the `onTrigger`
> method were to call `state.put("secondKey", "two");` while the checkpoint is
> occurring, it could end up writing the fact that the map has 1 key
> (`invocation`) followed by writing 2 entries (`invocation` and `secondKey`)
> which would cause corruption.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
