[ 
https://issues.apache.org/jira/browse/NIFI-5892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16724635#comment-16724635
 ] 

Koji Kawamura commented on NIFI-5892:
-------------------------------------

[~ottobackwards] I'd leave default name blank. And if not specified, Wait 
processor works just the same. My idea is adding specified prefix to any wait 
related attribute so that the single FlowFile can be waited by few different 
Wait processors. E.g. using 3 Wait processors to wait for 'validation', 
'registration' and 'reporting' phases ... etc.
Having said that, while I was writing this comment, I'm just reminded that this 
use-case is already supported by 'Signal Counter Name'.

Now I think deleting 'wait.start.timestamp' is the best approach, as [~laashe] 
suggested. wait.counters.* can be left as is because if subsequent flow uses 
Wait processor again, 'Signal Counter Name' can be used to wait for different 
notification.

> Wait timestamp lingers, potentially messing up downstream wait-notify pairs
> ---------------------------------------------------------------------------
>
>                 Key: NIFI-5892
>                 URL: https://issues.apache.org/jira/browse/NIFI-5892
>             Project: Apache NiFi
>          Issue Type: Improvement
>            Reporter: Lars Birger Aasheim
>            Assignee: Otto Fowler
>            Priority: Minor
>         Attachments: TestLingeringWaitTimestamps.xml
>
>
> The Wait processor makes use of the attribute "wait.start.timestamp" to keep 
> track of when it first encountered a flowfile. The observed behaviour is that 
> this attribute is set only if it does not exist, if else it is just checked 
> against the current time. With several wait-notify pairs in succession, there 
> is a likelihood that a flowfile will be routed directly to "expired" in one 
> of the downstream Wait processors due to a timestamp set upstream of it. I 
> suggest allowing an option of deleting the timestamp once a file is routed to 
> success (and perhaps also to expired). Currently I do this manually with an 
> UpdateAttribute processor.
>  
> Attached is a template with necessary components and also an explanation of 
> how to reproduce the issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to