[jira] [Commented] (NIFI-7348) FlowFiles re-entering a Wait-processor after they've expired expire immediatelly
[ https://issues.apache.org/jira/browse/NIFI-7348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17084594#comment-17084594 ] Koji Kawamura commented on NIFI-7348: - Thanks [~EndzeitBegins] for the detailed explanation and fixing this! I've reviewed the PR and merged it to master. > FlowFiles re-entering a Wait-processor after they've expired expire > immediatelly > > > Key: NIFI-7348 > URL: https://issues.apache.org/jira/browse/NIFI-7348 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.11.4 > Environment: Windows 10 / Ubuntu >Reporter: endzeit >Assignee: endzeit >Priority: Major > Labels: easyfix > Attachments: Wait_processor_expiration_issue.xml > > Time Spent: 2h 10m > Remaining Estimate: 0h > > We recently noticed a behaviour of the Wait processor that we thought of to > be a bug. > > As the attribute WAIT_START_TIMESTAMP is only removed once the FlowFile > leaves the processor successfully or failing, it affects FlowFiles that > expire the EXPIRATION_DURATION and re-enter the processor. > In case the FlowFile enters the same processor again - after expiring > beforehand - it is transported to the expired output immediately, without > waiting for the EXPIRATION_DURATION again. > Is this desired behaviour? > > I'll attach a very simple demonstration. Just let it run a minute or two and > look at the FlowFile attribute "counter" afterwards. > > There has been a pull-request addressing a similar issue (NIFI-5892), which > resulted in the attribute being removed after success and failure. This case > just seems to haven't been thought about back then. Or was there a reason to > not clear the attribute after expiration? I couldn't find a mention regarding > expiration in the issue. > > As this should be a very easy fix I would love to contribute, once you > confirm this is not intentional. > > *Current workaround:* > simply remove the attribute WAIT_START_TIMESTAMP after the FlowFile leaves > the Wait processor, e.g. using an UpdateAttribute processor > > *Edit 2020-04-13:* > Also this seems to have the side effect of NOT documenting the repeated > processing. There is no provenance entry added when re-entering the processor > and expiring immediately, leading to the error being harder to trace. > Because of this I reset the priority to "Major", which seems to be the > default anyway. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-7348) FlowFiles re-entering a Wait-processor after they've expired expire immediatelly
[ https://issues.apache.org/jira/browse/NIFI-7348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17084590#comment-17084590 ] ASF subversion and git services commented on NIFI-7348: --- Commit 8e3f42051fb3c7da27873de8b6d4507827a7b80d in nifi's branch refs/heads/master from EndzeitBegins [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=8e3f420 ] NIFI-7348 Wait - Removes WAIT_START_TIMESTAMP after expiration This closes #4201. Signed-off-by: Koji Kawamura > FlowFiles re-entering a Wait-processor after they've expired expire > immediatelly > > > Key: NIFI-7348 > URL: https://issues.apache.org/jira/browse/NIFI-7348 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.11.4 > Environment: Windows 10 / Ubuntu >Reporter: endzeit >Assignee: endzeit >Priority: Major > Labels: easyfix > Attachments: Wait_processor_expiration_issue.xml > > Time Spent: 2h > Remaining Estimate: 0h > > We recently noticed a behaviour of the Wait processor that we thought of to > be a bug. > > As the attribute WAIT_START_TIMESTAMP is only removed once the FlowFile > leaves the processor successfully or failing, it affects FlowFiles that > expire the EXPIRATION_DURATION and re-enter the processor. > In case the FlowFile enters the same processor again - after expiring > beforehand - it is transported to the expired output immediately, without > waiting for the EXPIRATION_DURATION again. > Is this desired behaviour? > > I'll attach a very simple demonstration. Just let it run a minute or two and > look at the FlowFile attribute "counter" afterwards. > > There has been a pull-request addressing a similar issue (NIFI-5892), which > resulted in the attribute being removed after success and failure. This case > just seems to haven't been thought about back then. Or was there a reason to > not clear the attribute after expiration? I couldn't find a mention regarding > expiration in the issue. > > As this should be a very easy fix I would love to contribute, once you > confirm this is not intentional. > > *Current workaround:* > simply remove the attribute WAIT_START_TIMESTAMP after the FlowFile leaves > the Wait processor, e.g. using an UpdateAttribute processor > > *Edit 2020-04-13:* > Also this seems to have the side effect of NOT documenting the repeated > processing. There is no provenance entry added when re-entering the processor > and expiring immediately, leading to the error being harder to trace. > Because of this I reset the priority to "Major", which seems to be the > default anyway. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-7348) FlowFiles re-entering a Wait-processor after they've expired expire immediatelly
[ https://issues.apache.org/jira/browse/NIFI-7348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17082268#comment-17082268 ] Otto Fowler commented on NIFI-7348: --- I don't think this is intentional. > FlowFiles re-entering a Wait-processor after they've expired expire > immediatelly > > > Key: NIFI-7348 > URL: https://issues.apache.org/jira/browse/NIFI-7348 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.11.4 > Environment: Windows 10 / Ubuntu >Reporter: endzeit >Assignee: endzeit >Priority: Major > Labels: easyfix > Attachments: Wait_processor_expiration_issue.xml > > Time Spent: 40m > Remaining Estimate: 0h > > We recently noticed a behaviour of the Wait processor that we thought of to > be a bug. > > As the attribute WAIT_START_TIMESTAMP is only removed once the FlowFile > leaves the processor successfully or failing, it affects FlowFiles that > expire the EXPIRATION_DURATION and re-enter the processor. > In case the FlowFile enters the same processor again - after expiring > beforehand - it is transported to the expired output immediately, without > waiting for the EXPIRATION_DURATION again. > Is this desired behaviour? > > I'll attach a very simple demonstration. Just let it run a minute or two and > look at the FlowFile attribute "counter" afterwards. > > There has been a pull-request addressing a similar issue (NIFI-5892), which > resulted in the attribute being removed after success and failure. This case > just seems to haven't been thought about back then. Or was there a reason to > not clear the attribute after expiration? I couldn't find a mention regarding > expiration in the issue. > > As this should be a very easy fix I would love to contribute, once you > confirm this is not intentional. > > *Current workaround:* > simply remove the attribute WAIT_START_TIMESTAMP after the FlowFile leaves > the Wait processor, e.g. using an UpdateAttribute processor > > *Edit 2020-04-13:* > Also this seems to have the side effect of NOT documenting the repeated > processing. There is no provenance entry added when re-entering the processor > and expiring immediately, leading to the error being harder to trace. > Because of this I reset the priority to "Major", which seems to be the > default anyway. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
