Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
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
-
None
Description
If the monitoring scope is configured to "cluster", then there are multiple restart cases when markers are incorrectly generated:
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.)
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.
Attachments
Attachments
Issue Links
- links to