[
https://issues.apache.org/jira/browse/NIFI-13072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajmund Takacs updated NIFI-13072:
----------------------------------
Description:
If the monitoring scope is configured to "cluster", then there are multiple
restart cases when markers are incorrectly generated:
h4. CASE 1
* The flow is already inactive, and there is no traffic. The processor is still
running and scheduled on all nodes.
* We restart any of the NiFi nodes in the cluster.
* *All nodes, except the restarted one, generates activation marker.* (Reason
for this is, that the common timestamp is updated by the restarted node during
initialization.)
h4. CASE 2:
* The flow is already inactive, and there is no traffic. The processor is still
running and scheduled on all nodes. Reporting is done by all nodes.
* We temporarily stop any of the nodes.
* We start traffic on any other node, so that an activation marker is generated.
* We start the previously stopped node again.
* *This node does not send activation marker.* (Reason for this is that the
initial state is always active.)
Expected behavior for stop/start cases would be:
* Single node restart alone should not affect the flow activity state.
* If a marker has already been sent before stopping the processor, it should
not be repeated on next start, unless asked for, or there is a change in
activity state.
* If the flow was active during a weekend shutdown, it should not begin with an
inactivity marker right after startup on monday. Although it should send
inactivity marker after the threshold has expired since startup.
* If the flow was inactive during a weekend shutdown, it should send activation
marker after started up again with traffic.
was:
If the monitoring scope is configured to "cluster", then there are multiple
restart cases when false positive markers are generated:
h4. CASE 1
* The flow is already inactive, and there is no traffic. The processor is still
running and scheduled on all nodes.
* We restart any of the NiFi nodes in the cluster.
* *All nodes, except the restarted one, generates activation marker.* (Reason
for this is, that the common timestamp is updated by the restarted node during
initialization.)
h4. CASE 2:
* The flow is already inactive, and there is no traffic. The processor is still
running and scheduled on all nodes. Reporting is done by all nodes.
* We temporarily stop any of the nodes.
* We start traffic on any other node, so that an activation marker is generated.
* We start the previously stopped node again.
* *This node does not send activation marker.* (Reason for this is that the
initial state is always active.)
Expected behavior for stop/start cases would be:
* Single node restart alone should not affect the flow activity state.
* If a marker has already been sent before stopping the processor, it should
not be repeated on next start, unless asked for, or there is a change in
activity state.
* If the flow was active during a weekend shutdown, it should not begin with an
inactivity marker right after startup on monday. Although it should send
inactivity marker after the threshold has expired since startup.
* If the flow was inactive during a weekend shutdown, it should send activation
marker after started up again with traffic.
> MonitorActivity processor generates a false positive on a node restart
> ----------------------------------------------------------------------
>
> Key: NIFI-13072
> URL: https://issues.apache.org/jira/browse/NIFI-13072
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
> Affects Versions: 2.0.0-M1, 1.18.0, 1.19.0, 1.20.0, 1.19.1, 1.21.0,
> 1.22.0, 1.23.0, 1.24.0, 1.23.1, 1.23.2, 1.25.0, 2.0.0-M2
> Reporter: Rajmund Takacs
> Assignee: Rajmund Takacs
> Priority: Major
>
> If the monitoring scope is configured to "cluster", then there are multiple
> restart cases when markers are incorrectly generated:
> h4. CASE 1
> * The flow is already inactive, and there is no traffic. The processor is
> still running and scheduled on all nodes.
> * We restart any of the NiFi nodes in the cluster.
> * *All nodes, except the restarted one, generates activation marker.* (Reason
> for this is, that the common timestamp is updated by the restarted node
> during initialization.)
> h4. CASE 2:
> * The flow is already inactive, and there is no traffic. The processor is
> still running and scheduled on all nodes. Reporting is done by all nodes.
> * We temporarily stop any of the nodes.
> * We start traffic on any other node, so that an activation marker is
> generated.
> * We start the previously stopped node again.
> * *This node does not send activation marker.* (Reason for this is that the
> initial state is always active.)
> Expected behavior for stop/start cases would be:
> * Single node restart alone should not affect the flow activity state.
> * If a marker has already been sent before stopping the processor, it should
> not be repeated on next start, unless asked for, or there is a change in
> activity state.
> * If the flow was active during a weekend shutdown, it should not begin with
> an inactivity marker right after startup on monday. Although it should send
> inactivity marker after the threshold has expired since startup.
> * If the flow was inactive during a weekend shutdown, it should send
> activation marker after started up again with traffic.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
