[
https://issues.apache.org/jira/browse/NIFI-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15370625#comment-15370625
]
ASF GitHub Bot commented on NIFI-2185:
--------------------------------------
Github user mcgilman commented on the issue:
https://github.com/apache/nifi/pull/621
Looks good @markap14. This has been merged to master. I ran into a couple
of unrelated issues while testing and will open additional JIRAs as necessary.
Thanks!
> Implement two-phase read for GET requests when replicated across the cluster
> ----------------------------------------------------------------------------
>
> Key: NIFI-2185
> URL: https://issues.apache.org/jira/browse/NIFI-2185
> Project: Apache NiFi
> Issue Type: Task
> Components: Core Framework
> Affects Versions: 1.0.0
> Reporter: Mark Payne
> Assignee: Mark Payne
> Priority: Blocker
> Fix For: 1.0.0
>
>
> With the new zero-master clustering paradigm, we can have a scenario where a
> GET request and a POST request occur 'at the same time' but the requests are
> replicated to the nodes in different orders. For instance, if I have a
> Process Group with ID 1234, it's possible that the group could be read via a
> GET and modified via a POST request simultaneously.
> If we have a 3 node cluster, this can result in Nodes 1 and 2 servicing the
> GET request before the POST request, while Node 3 services the POST request
> before the GET request. As a result, Nodes 1 and 2 return one view of the
> Process Group while Node 3 returns a different view of the Process Group.
> This wasn't an issue with the NCM because the NCM provided a locking
> mechanism that prevented any GET requests from being replicated while a
> POST/PUT/DELETE was also being replicated.
> In the new clustering model, in order to implement the same type of logic, we
> need a two-phase read, where the first phase simply obtains a Read Lock, and
> the second phase handles the logic of creating the response for the client to
> consume and then unlocking the Read Lock.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
