nifi-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lucas Ottersbach (Jira)" <>
Subject [jira] [Assigned] (NIFI-7348) FlowFiles re-entering a Wait-processor after they've expired expire immediatelly
Date Fri, 10 Apr 2020 06:19:00 GMT


Lucas Ottersbach reassigned NIFI-7348:

    Assignee: Lucas Ottersbach

> FlowFiles re-entering a Wait-processor after they've expired expire immediatelly
> --------------------------------------------------------------------------------
>                 Key: NIFI-7348
>                 URL:
>             Project: Apache NiFi
>          Issue Type: Bug
>          Components: Extensions
>    Affects Versions: 1.11.4
>         Environment: Windows 10 / Ubuntu
>            Reporter: Lucas Ottersbach
>            Assignee: Lucas Ottersbach
>            Priority: Minor
>              Labels: easyfix
>         Attachments: Wait_processor_expiration_issue.xml
> 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
> 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 

This message was sent by Atlassian Jira

View raw message