[
https://issues.apache.org/jira/browse/NIFI-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15403180#comment-15403180
]
Koji Kawamura edited comment on NIFI-2364 at 8/2/16 1:35 AM:
-------------------------------------------------------------
This issue happened after applying NIFI-2363 and testing with a clustered NIFI.
Without NIFI-2363, all nodes will respond with the same response, then this
will not happen.
So, this issue is more a sub task of NIFI-2363.
Based on Joe's review comment, I thought we will need more time to go though
review & test cycle. Since this is a new feature, I'm ok with moving it to 1.1.
Also, cancel the patch to break it down to smaller PRs only focusing individual
JIRA issue.
was (Author: ijokarumawak):
This issue happened after applying NIFI-2363 and testing with a clustered NIFI.
Without NIFI-2363, all nodes will respond with the same response, and this will
not happen.
So, this issue is more a sub task of NIFI-2363.
Spoked with Joe Witt and Joe Percivall about release target. Since there is not
enough time to go though review & test cycle to be in 1.0. Also, cancel the
patch to break it down to smaller PRs only focusing individual JIRA issue.
> Node shouldn't be disconnected from a cluster when clear component state
> operation gets error related to underlying data source
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: NIFI-2364
> URL: https://issues.apache.org/jira/browse/NIFI-2364
> Project: Apache NiFi
> Issue Type: Sub-task
> Components: Core Framework
> Reporter: Koji Kawamura
> Assignee: Koji Kawamura
> Fix For: 1.1.0
>
>
> NodeClusterCoordinator.afterRequest() disconnects a node if it couldn't
> handle mutation requests such as POST, assuming that node is not functioning
> properly.
> However, if the cause of issue is related to an external data source, such as
> Zookeeper or Kafka, other node will have the same problem even if other node
> is elected as a primary node. In such case, disconnecting node wouldn't be a
> good recovery solution. Instead, the node should keep connected, and let
> users retry the operation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
