[
https://issues.apache.org/jira/browse/NIFI-5892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16724209#comment-16724209
]
Bryan Bende commented on NIFI-5892:
-----------------------------------
We can't assume everyone is using NiFi Registry so we can add properties to
processors like we always have.
Even with registry, it is a fairly specific scenario... if you had two
environments like dev and prod, and you upgraded dev NiFi and it has a
processor in a versioned flow with new properties you would then need to save
the versioned flow to registry to capture the new properties. If you then went
to prod it would show an upgrade on the flow which you could do even though you
haven't upgrade prod NiFi yet, so if you do the upgrade then your processor
becomes invalid because it doesn't have those properties. If you then delete
those properties, now you made local changes again.
> 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)
