Lucas
The change proposed is specific to the original intent, implementation,
evolution, and bridging to new intent for certain cases of that specific
processor.
I remain supportive of processors using the capabiltities of the api and
framework to best meet the user needs. “failure” is just a
I think that's a good approach which actually addresses the underlying
issue. Thank you Joe, Mark and all others.
As far as I know the default last resort behaviour of rollback + yield,
that a lot processors exhibit, is due to them being based on
AbstractProcessor.
Does it make sense to
Lots of good commentary and great focus on minimizing impact to the users
while fixing what is admittedly not the most desired behavior for some
cases as it relates to the very popular UpdateAttribute.
We do not want to enforce that all processors have failure relationships.
Presumably that
I mean, this really speaks to the principal that (in my humble opinion) All
Processors Shalt Have Failure Relationships as best practice.
So I think the decision is really, how much pain do we want to impose on
NiFi 2.0 adopters. UpdateAttribute and RouteOnAttribute are used literally
everywhere
Yes, that certainly involves a lot of effort.
I wonder whether it's a good idea to fix a possible "design flaw" with a
construct that is neither consistent nor easy to handle.
I also think the argument that you have to adjust a lot in the flow is
questionable.
With Release 2.0, so much has to
These are great ideas! I do love Adam's dynamic relationship idea over
creating a failure relationship that is auto-terminated. This would make
flow migrations in Registry and NiFi easier.
After some more pondering, I (slowly) realized that this problem affects
more than UpdateAttribute, though.
--Uwe
> Am 09.02.2024 um 13:50 schrieb Mike Thomsen :
>
> How about a third option which is to provide three options:
>
> 1) Default - status quo, exceptions cause it to yield
> 2) Exception = moves forward to success w/ an error attribute, an error log
> statement that triggers a bulletin,
How about a third option which is to provide three options:
1) Default - status quo, exceptions cause it to yield
2) Exception = moves forward to success w/ an error attribute, an error log
statement that triggers a bulletin, etc to let data manages know what's
happening.
3) Exception = moves to
Obviously, three options in a drop down :-D
On Fri, Feb 9, 2024 at 7:49 AM Mike Thomsen wrote:
> How about a third option which is to provide three options:
>
> 1) Default - status quo, exceptions cause it to yield
> 2) Exception = moves forward to success w/ an error attribute, an error
> log
Mike's option #2 seems solid but would take a lot of work and there will
always be inputs we don't account for. I support that work but in code
sometimes we just do a "catch(Throwable)" just so it doesn't blow up. What
about a subjectless "try" or "trycatch" function you can wrap around your
whole
IMO... UpdateAttribute has been around since the beginning of time, I can't
see adding a failure relationship. At the same time I understand the want
for such exceptions to be handled more gracefully rather than rolling back
indefinitely.
I'd vote in favor of considering Moser's option #2... and
Or better, the failure relationship just doesn't even exist until the
property "Has Failure Relationship" is set to True. This involves updating
UpdateAttribute to have dynamic relationships (the failure relationships
appearing on true), which isn't hard to do in processor code.
This has the
Hi Mike,
How about the option of introducing a new property that decides whether to
route to the 'failure' relationship in the event of an error?
If this property is set to false, then the 'failure' relationship is
automatically set to 'terminate' (since nothing is routed there anyway).
Then
Hi Dan,
This has been discussed in the past, as you found with those two Jira
tickets. Personally, I'm still not sure whether a new failure relationship
on UpdateAttribute in 2.0 is a good approach. I have heard from some
dataflow managers that would not want to go through their entire graph
14 matches
Mail list logo