[
https://issues.apache.org/jira/browse/NIFI-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368266#comment-15368266
]
ASF GitHub Bot commented on NIFI-2185:
--------------------------------------
GitHub user markap14 opened a pull request:
https://github.com/apache/nifi/pull/621
NIFI-2185: Proxy requests through the cluster coordinator rather than…
… making use of distributed read/write locks
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/markap14/nifi NIFI-2185
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/nifi/pull/621.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #621
----
commit b8bfb286fc54dfae9b09fe010209942f04fb2065
Author: Mark Payne <[email protected]>
Date: 2016-07-08T16:58:06Z
NIFI-2185: Proxy requests through the cluster coordinator rather than
making use of distributed read/write locks
----
> 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)
