You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "Mark Payne (JIRA)" <ji...@apache.org> on 2016/07/11 13:54:11 UTC

[jira] [Resolved] (NIFI-2185) Ensure that read lock is held across all nodes when replicating GET requests

     [ https://issues.apache.org/jira/browse/NIFI-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Payne resolved NIFI-2185.
------------------------------
    Resolution: Fixed

> Ensure that read lock is held across all nodes when replicating GET requests
> ----------------------------------------------------------------------------
>
>                 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)