RE: Does expiration add up?

["Vos, Walter" <wa...@ns.nl>]

Hi! I've asked this question a while ago and kind of forgot about it. But now I'm facing issues with this same thing again. A flowfile expires quicker than I expected it to because it has a previous wait.start.timestamp attribute. Should I be actively removing this attribute after every wait processor to prevent this or is there a design thing that I'm not getting? I'm on NiFi 1.5, by the way.

-Walter

From: Vos, Walter
Sent: donderdag 7 februari 2019 16:47
To: users@nifi.apache.org
Subject: Does expiration add up?

Hi,

I've recently been working with wait/notify processors to determine whether or not flowfiles may move forward. The final wait/notify component of my flow waits for a truncate. That should be done in 10 minutes so I set the expiration duration to that (actually it should be much shorter, but who knows, right? All my flowfiles got dropped right the instant the entered the wait processor though. So doesn't the wait.start.timestamp ever reset? Any way to work around this? Or should I just add the previous expiration durations to each other?

-Walter

________________________________

Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor (gebruik door) de geadresseerde. De e-mail kan persoonlijke of vertrouwelijke informatie bevatten. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van (de inhoud van) deze e-mail (en eventuele bijlagen) aan derden is uitdrukkelijk niet toegestaan. Indien u niet de bedoelde geadresseerde bent, wordt u vriendelijk verzocht degene die de e-mail verzond hiervan direct op de hoogte te brengen en de e-mail (en eventuele bijlagen) te vernietigen.

Informatie vennootschap<http://www.ns.nl/emaildisclaimer>

________________________________

Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor (gebruik door) de geadresseerde. De e-mail kan persoonlijke of vertrouwelijke informatie bevatten. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van (de inhoud van) deze e-mail (en eventuele bijlagen) aan derden is uitdrukkelijk niet toegestaan. Indien u niet de bedoelde geadresseerde bent, wordt u vriendelijk verzocht degene die de e-mail verzond hiervan direct op de hoogte te brengen en de e-mail (en eventuele bijlagen) te vernietigen.

Informatie vennootschap<http://www.ns.nl/emaildisclaimer>

RE: Does expiration add up?

["Vos, Walter" <wa...@ns.nl>]

Thanks for the heads-up, Otto! We’re deciding on upgrades anyway, so I’ll push for 1.9(.2).

-Walter

From: Otto Fowler <ot...@gmail.com>
Sent: dinsdag 7 mei 2019 12:53
To: users@nifi.apache.org
Subject: RE: Does expiration add up?

https://github.com/apache/nifi/pull/3233



On May 7, 2019 at 02:23:51, Vos, Walter (walter.vos@ns.nl<ma...@ns.nl>) wrote:
Hi! I’ve asked this question a while ago and kind of forgot about it. But now I’m facing issues with this same thing again. A flowfile expires quicker than I expected it to because it has a previous wait.start.timestamp attribute. Should I be actively removing this attribute after every wait processor to prevent this or is there a design thing that I’m not getting? I’m on NiFi 1.5, by the way.

-Walter

From: Vos, Walter
Sent: donderdag 7 februari 2019 16:47
To: users@nifi.apache.org<ma...@nifi.apache.org>
Subject: Does expiration add up?

Hi,

I’ve recently been working with wait/notify processors to determine whether or not flowfiles may move forward. The final wait/notify component of my flow waits for a truncate. That should be done in 10 minutes so I set the expiration duration to that (actually it should be much shorter, but who knows, right? All my flowfiles got dropped right the instant the entered the wait processor though. So doesn’t the wait.start.timestamp ever reset? Any way to work around this? Or should I just add the previous expiration durations to each other?

-Walter

________________________________

Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor (gebruik door) de geadresseerde. De e-mail kan persoonlijke of vertrouwelijke informatie bevatten. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van (de inhoud van) deze e-mail (en eventuele bijlagen) aan derden is uitdrukkelijk niet toegestaan. Indien u niet de bedoelde geadresseerde bent, wordt u vriendelijk verzocht degene die de e-mail verzond hiervan direct op de hoogte te brengen en de e-mail (en eventuele bijlagen) te vernietigen.

Informatie vennootschap<http://www.ns.nl/emaildisclaimer>

________________________________

Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor (gebruik door) de geadresseerde. De e-mail kan persoonlijke of vertrouwelijke informatie bevatten. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van (de inhoud van) deze e-mail (en eventuele bijlagen) aan derden is uitdrukkelijk niet toegestaan. Indien u niet de bedoelde geadresseerde bent, wordt u vriendelijk verzocht degene die de e-mail verzond hiervan direct op de hoogte te brengen en de e-mail (en eventuele bijlagen) te vernietigen.

Informatie vennootschap<http://www.ns.nl/emaildisclaimer>

________________________________

Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor (gebruik door) de geadresseerde. De e-mail kan persoonlijke of vertrouwelijke informatie bevatten. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van (de inhoud van) deze e-mail (en eventuele bijlagen) aan derden is uitdrukkelijk niet toegestaan. Indien u niet de bedoelde geadresseerde bent, wordt u vriendelijk verzocht degene die de e-mail verzond hiervan direct op de hoogte te brengen en de e-mail (en eventuele bijlagen) te vernietigen.

Informatie vennootschap<http://www.ns.nl/emaildisclaimer>

RE: Does expiration add up?

[Otto Fowler <ot...@gmail.com>]

https://github.com/apache/nifi/pull/3233


On May 7, 2019 at 02:23:51, Vos, Walter (walter.vos@ns.nl) wrote:

Hi! I’ve asked this question a while ago and kind of forgot about it. But
now I’m facing issues with this same thing again. A flowfile expires
quicker than I expected it to because it has a previous
wait.start.timestamp attribute. Should I be actively removing this
attribute after every wait processor to prevent this or is there a design
thing that I’m not getting? I’m on NiFi 1.5, by the way.



-Walter



*From:* Vos, Walter
*Sent:* donderdag 7 februari 2019 16:47
*To:* users@nifi.apache.org
*Subject:* Does expiration add up?



Hi,



I’ve recently been working with wait/notify processors to determine whether
or not flowfiles may move forward. The final wait/notify component of my
flow waits for a truncate. That should be done in 10 minutes so I set the
expiration duration to that (actually it should be much shorter, but who
knows, right? All my flowfiles got dropped right the instant the entered
the wait processor though. So doesn’t the wait.start.timestamp ever reset?
Any way to work around this? Or should I just add the previous expiration
durations to each other?



-Walter


------------------------------

Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor
(gebruik door) de geadresseerde. De e-mail kan persoonlijke of
vertrouwelijke informatie bevatten. Openbaarmaking, vermenigvuldiging,
verspreiding en/of verstrekking van (de inhoud van) deze e-mail (en
eventuele bijlagen) aan derden is uitdrukkelijk niet toegestaan. Indien u
niet de bedoelde geadresseerde bent, wordt u vriendelijk verzocht degene
die de e-mail verzond hiervan direct op de hoogte te brengen en de e-mail
(en eventuele bijlagen) te vernietigen.

Informatie vennootschap <http://www.ns.nl/emaildisclaimer>

------------------------------

Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor
(gebruik door) de geadresseerde. De e-mail kan persoonlijke of
vertrouwelijke informatie bevatten. Openbaarmaking, vermenigvuldiging,
verspreiding en/of verstrekking van (de inhoud van) deze e-mail (en
eventuele bijlagen) aan derden is uitdrukkelijk niet toegestaan. Indien u
niet de bedoelde geadresseerde bent, wordt u vriendelijk verzocht degene
die de e-mail verzond hiervan direct op de hoogte te brengen en de e-mail
(en eventuele bijlagen) te vernietigen.

Informatie vennootschap <http://www.ns.nl/emaildisclaimer>