nifi-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lucas Ottersbach (Jira)" <j...@apache.org>
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

     [ https://issues.apache.org/jira/browse/NIFI-7348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Lucas Ottersbach reassigned NIFI-7348:
--------------------------------------

    Assignee: Lucas Ottersbach

> 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: 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
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 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message