Thanks for sharing Deepak. That's interesting. I think we may look into a way of disabling components that doesn't impact version control, or else fix performance issues such that disabling is not necessary.
Just out of curiosity, what version of NiFi are you on? The reason I ask is that I know there have been some UI performance improvements made in recent versions of NiFi, so I'm wondering if some of this might already have been addressed... Thanks, Kevin On Dec 13, 2022 at 09:52:47, "Chirthani, Deepak Reddy" < c-deepakreddy.chirth...@charter.com> wrote: > Hi Kevin, > > Thank you for your quick response. The only reason why I prefer processors > to be disabled is to improve the NiFi UI performance by simply disabling > stopped processors which I am not using. > > > https://community.cloudera.com/t5/Support-Questions/Nifi-UI-Working-very-Slow-How-to-increase-performance-of-a/td-p/214550 > > I had issues with Nifi UI performance in the past where the refresh wheel > keeps on spinning like for 10 seconds and disabling stopped processors > really helped me. > > Thanks > Deepak > > > > > > *[image: image005]* > > *Deepak Reddy* | Data Engineer > IT Centers of Excellence > 13736 Riverport Dr., Maryland Heights, MO 63043 > > > > *From:* Kevin Doran <kdo...@apache.org> > *Sent:* Friday, December 9, 2022 9:33 AM > *To:* users@nifi.apache.org > *Subject:* [EXTERNAL] Re: Disabling flows - nifi registry > > > > *CAUTION:* The e-mail below is from an external source. Please exercise > caution before opening attachments, clicking links, or following guidance. > > Hi Deepak, > > > > So far, we have been honoring the following policy for what constitutes a > change in version control: > > > > - stopped/started does not count as a "local change" > - enabled/disabled does count as a change, and that state is captured > in the flow snapshot json version saved to registry. > > > > One reason for this is that some users want to setup CI/CD to deploy from > Registry and automatically start a flow in the target NiFi. If there are > components they don't want to start, the disabled state gives them a way to > capture that configuration in the flow. > > > > Is there a reason you prefer disable over stop in your lower environment? > I leave flows stopped in dev environments all the time and have never run > into an issue, but of course, everyone's workflow and use case is slightly > different, so I'm interested in hearing your perspective on this to see if > we need to consider something more flexible. > > > > Cheers, > > Kevin > > > > On Dec 9, 2022 at 10:26:27, "Chirthani, Deepak Reddy" < > c-deepakreddy.chirth...@charter.com> wrote: > > Hey guys, > > So, once I fully develop and parameterize my nifi dataflow, let’s say in > dev environment, I enable the version control, import the flow in higher > environment and turn on the dataflow. In most of the cases both the flows > in lower and higher environments will be running. Let says dev nifi > connects to dev gcp pubsub and prod nifi connects to prod gcp pubsub. > However, in some cases, we do want to stop and disable the flow in lower > env. When I do that the registry is identifying that local changes are made > to the flow which is nothing but all the components are disabled. I don’t > want to keep the processors in stopped state on the canvas(registry do not > identify for stopping) but want to disable them. Any workaround for > registry not to identify local changes when flow is disabled? > > > > Thanks > > Deepak > > > > *[image: image005]* > > *Deepak Reddy* | Data Engineer > IT Centers of Excellence > 13736 Riverport Dr., Maryland Heights, MO 63043 > > > > The contents of this e-mail message and > any attachments are intended solely for the > addressee(s) and may contain confidential > and/or legally privileged information. If you > are not the intended recipient of this message > or if this message has been addressed to you > in error, please immediately alert the sender > by reply e-mail and then delete this message > and any attachments. If you are not the > intended recipient, you are notified that > any use, dissemination, distribution, copying, > or storage of this message or any attachment > is strictly prohibited. > > The contents of this e-mail message and > any attachments are intended solely for the > addressee(s) and may contain confidential > and/or legally privileged information. If you > are not the intended recipient of this message > or if this message has been addressed to you > in error, please immediately alert the sender > by reply e-mail and then delete this message > and any attachments. If you are not the > intended recipient, you are notified that > any use, dissemination, distribution, copying, > or storage of this message or any attachment > is strictly prohibited. >
