exceptionfactory commented on PR #9685: URL: https://github.com/apache/nifi/pull/9685#issuecomment-2635026776
> > Thanks for proposing this rule @markobean. > > I made some comments around the property definitions, as the number of Boolean values creates a variety of options. > > The proposed description mentions locating connections with load balancing, but that should not be the primary purpose of analysis rules. > > On initial review, the rule itself seems too broad. Connection Load Balancing makes sense at very particular parts of a flow, and does not make sense in others. One anti-pattern is load balancing at every Processor, as opposed to just an initial source. Having a general rule that checks for the presence of load balancing one way or the other doesn't provide enough granularity to determine whether the implementation is good or bad. > > Are there other use cases where this generalized approach fits? > > I envisioned this particular rule (and maybe others) as a way to spot check your flow. This is why it is great the rules have an enable/disable feature. It doesn't have to be left enabled all the time, but rather enable it to perform analysis and then disable it again. This may be more appropriate for the warning type violation, not enforcement. > > I see your point though. One way around this would be to apply Flow Analysis Rules to specific Process Group(s). Doing so would be well beyond the scope of this ticket. I recommend this PR continue with the existing Rules framework - good and bad. (I already have another Jira issue to improve the way violations on a connection work.) > > There is an immediately use case for using this rule to quickly identify all locations where load balancing is employed. As you say, this should be implemented judiciously for obvious performance reasons. This rule will aid in finding an over-abundance of load balanced connections. Thanks for the additional background @markobean, that provides helpful context for consideration. I agree with you that being able to scope rules analysis to the Process Group level would be useful in this scenario. Implementing it is not trivial as you noted, and some past work around this didn't go forward due to initial usability concerns, so it is an open area. Although the Flow Analysis Rules space has fewer examples right now, this is an area where it is important to provide generally usable and understandable components, just like Processors. In other words, too many knobs can be counter-productive long term. For that reason, and for the use of the `nifi-framework-api`, I don't think this rule provides a good general pattern as it stands. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
