Mark Payne created NIFI-6894:
--------------------------------
Summary: When node [re]joins cluster, if browser is pointed at
that node, it can reject any flow modifications due to incorrect revision
Key: NIFI-6894
URL: https://issues.apache.org/jira/browse/NIFI-6894
Project: Apache NiFi
Issue Type: Bug
Components: Core UI
Reporter: Mark Payne
Because the UI sometimes makes several asynchronous requests simultaneously,
when it receives a revision back from the server, it does not blindly accept
it. Instead, it holds onto the Revision with the greatest version number. This
works well in most cases. However, there is an edge case where it causes
problems:
In a cluster with at least 2 nodes, disconnect one of them.
Go to the disconnected node and move some processors around. Don't make any
other modifications, as doing so may prevent the node from rejoining the
cluster.
In another browser tab go back to the cluster and request that the node rejoin.
Once the node has rejoined, the browser tab that is already open to the
(previously) disconnected node does not get the new revisions. Because some
modifications were made while it was disconnected, it may now locally have
revision 10, for instance, while the cluster thinks the revision is 2. As a
result, this browser tab shows the components in their old locations with the
wrong Revision. Any attempt to modify one of those components now will fail,
because the Revision is incorrect.
Given the scenario laid out here, it may seem a bit contrived. This is because
it's a fairly contrived example to recreate the scenario. However, the same
thing can happen when a new node joins a cluster that is behind a firewall,
such as in a Kubernetes environment. The revisions that previously were loaded
in the UI may no longer be the correct revisions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
