markobean commented on PR #9685: URL: https://github.com/apache/nifi/pull/9685#issuecomment-2638076911
> Thanks for the reply @mosermw, see responses in line: > > > I support users that temporarily add load balanced connections to help distribute a rare spike in flowfile load (think of a Split processor that normally has no trouble but will rarely output millions of flowfiles). They load balance a connection to work off a load, then 2 hours later want to remove that load balancing later. A Flow Analysis Rule such as this (in WARN enforcement mode) can ensure that this isn't forgotten and mistakenly left in place (which happens a lot). > > In this scenario, is there a reason for not having load balancing enabled all the time? Having to turn it on and off seems questionable, but perhaps there is some other driving reason. In this scenario, is the desire that load balancing is never enabled anywhere in the flow? > > > Another use case is a NiFi system owner has given access to tenants and doesn't want those tenants to use certain load balanced connection configurations, or load balancing at all. > > Disallowing all load balancing could be a reason for a streamlined version of this rule, but then the configuration properties could be simplified. Allowing only specific types of load balancing across all flow configurations seems to broad of a limitation, which is part of the fundamental concern. > > > Another use case can be the desire to require compression on attributes+content because the flow manager knows that their data is easily compressible and wants to ensure this efficiency is always enabled. > > Would the current approach support this use case? The properties allow compression, but would not require it if I am following. Also, this would require the same compression setting for all load balanced connections. > > > With many people modifying a NiFi graph, these Flow Analysis Rules are a great tool for performing some quality checks. > > I agree with you that performing quality checks is a value, the current problem is that the rule implementation doesn't provide enough fine-grained control. This could arguably be a limitation of the current framework implementation for evaluating all rules across all process groups, but that's where things stand. I agree with use cases that @mwmoser presented. @exceptionfactory you are correct that the submitted implementation and the compression use case outlined is will not work quite the way we'd like for that use case. For it to work, there would have to be a `Required` state in addition to `Allowed` and `Disallowed`. The best we could do would be negative testing; set compression for `Disallowed` and verify the list of violations covers all load balanced connections. I could add an additional state if this use case is strong desired. But I won't spend the cycles if it still going to receive a "-1". The original use case - which is still a powerful one that has been requested for years - is to use this rule as a mechanism to locate all load balanced connections. Currently, there is no way to do that short of manually parsing the flow.json.gz file. For this reason alone, I find this Flow Analysis Rule a significant improvement. For this reason alone, I find it unreasonable to reject even if not yet a perfect solution (with many of the arguments against being within framework, not the rule.) -- 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]
