You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@nifi.apache.org by Lars Birger Aasheim <la...@sherpaconsulting.no> on 2018/12/06 08:31:46 UTC
Lingering Wait timestamp
Hi,
I make good use of wait-notify pairs in my nifi flow, and have several in
succession with other processors in between. I also make use of replays
during testing.
To reproduce this issue, all you need is a wait-notify pair followed by an
UpdateAttribute processor, and another wait-notify pair, with expiration
times in the Wait processors set to a minute or something. First run a file
through the complete flow, and it will come out the other end just fine.
Then wait until the expiration time of the first wait processor has passed,
and run a replay from the UpdateAttribute processor. In this case the
flowfile is routed directly to "expired" in the second wait processor.
Then, stop the UpdateAttribute processor, run a new file from the start of
the flow, wait until the expiration time has passed, start the
UpdateAttribute processor, and the file is once again routed directly to
"expired" in the second wait processor. Lastly, set the UpdateAttribute
processor to delete "wait.start.timestamp", do another replay, and the file
will pass through the second wait-notify pair just fine.
My conclusion is that the Wait processor is quite "stupid", not tracking
when it meets a flowfile for the first time, seemingly just checking
whether "wait.start.timestamp" is empty or not. This is of course fine, but
I suggest making the processor delete the timestamp before passing the
flowfile on to "success", and perhaps noting the current behaviour in the
documentation.
Regards,
Lars
Re: Lingering Wait timestamp
Posted by Lars Birger Aasheim <la...@sherpaconsulting.no>.
Sorry for the delay, busy times, but now I have created a jira issue
<https://jira.apache.org/jira/browse/NIFI-5892>, with template.
[image: Sherpa Consulting] <https://htmlsig.com/t/000001CDVNCG>
*Lars Birger Aasheim* / Konsulent
lba@sherpaconsulting.no / +47 97 14 19 90
Sherpa Consulting <http://www.sherpaconsulting.no/>
Stortorvet 5, 0155 Oslo <https://goo.gl/maps/E2VJWKostaB2>
Den tor. 6. des. 2018 kl. 13:14 skrev Otto Fowler <ot...@gmail.com>:
> Can you create a jira issue, and attach a template with an example of what
> you are talking about?
>
>
> On December 6, 2018 at 03:38:47, Lars Birger Aasheim (
> lars.birger.aasheim@sherpaconsulting.no) wrote:
>
> Hi,
>
> I make good use of wait-notify pairs in my nifi flow, and have several in
> succession with other processors in between. I also make use of replays
> during testing.
>
> To reproduce this issue, all you need is a wait-notify pair followed by an
> UpdateAttribute processor, and another wait-notify pair, with expiration
> times in the Wait processors set to a minute or something. First run a file
> through the complete flow, and it will come out the other end just fine.
> Then wait until the expiration time of the first wait processor has passed,
> and run a replay from the UpdateAttribute processor. In this case the
> flowfile is routed directly to "expired" in the second wait processor.
> Then, stop the UpdateAttribute processor, run a new file from the start of
> the flow, wait until the expiration time has passed, start the
> UpdateAttribute processor, and the file is once again routed directly to
> "expired" in the second wait processor. Lastly, set the UpdateAttribute
> processor to delete "wait.start.timestamp", do another replay, and the file
> will pass through the second wait-notify pair just fine.
>
> My conclusion is that the Wait processor is quite "stupid", not tracking
> when it meets a flowfile for the first time, seemingly just checking
> whether "wait.start.timestamp" is empty or not. This is of course fine, but
> I suggest making the processor delete the timestamp before passing the
> flowfile on to "success", and perhaps noting the current behaviour in the
> documentation.
>
> Regards,
> Lars
>
>
>
>
Re: Lingering Wait timestamp
Posted by Otto Fowler <ot...@gmail.com>.
Can you create a jira issue, and attach a template with an example of what
you are talking about?
On December 6, 2018 at 03:38:47, Lars Birger Aasheim (
lars.birger.aasheim@sherpaconsulting.no) wrote:
Hi,
I make good use of wait-notify pairs in my nifi flow, and have several in
succession with other processors in between. I also make use of replays
during testing.
To reproduce this issue, all you need is a wait-notify pair followed by an
UpdateAttribute processor, and another wait-notify pair, with expiration
times in the Wait processors set to a minute or something. First run a file
through the complete flow, and it will come out the other end just fine.
Then wait until the expiration time of the first wait processor has passed,
and run a replay from the UpdateAttribute processor. In this case the
flowfile is routed directly to "expired" in the second wait processor.
Then, stop the UpdateAttribute processor, run a new file from the start of
the flow, wait until the expiration time has passed, start the
UpdateAttribute processor, and the file is once again routed directly to
"expired" in the second wait processor. Lastly, set the UpdateAttribute
processor to delete "wait.start.timestamp", do another replay, and the file
will pass through the second wait-notify pair just fine.
My conclusion is that the Wait processor is quite "stupid", not tracking
when it meets a flowfile for the first time, seemingly just checking
whether "wait.start.timestamp" is empty or not. This is of course fine, but
I suggest making the processor delete the timestamp before passing the
flowfile on to "success", and perhaps noting the current behaviour in the
documentation.
Regards,
Lars