[
https://issues.apache.org/jira/browse/NIFI-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15370621#comment-15370621
]
ASF subversion and git services commented on NIFI-2185:
-------------------------------------------------------
Commit cf183e15e3d400a138791ee5ca79287e87ebd932 in nifi's branch
refs/heads/master from [~markap14]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=cf183e1 ]
NIFI-2185: Proxy requests through the cluster coordinator rather than making
use of distributed read/write locks. This closes #621
> 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)
