@Green_  Thinking more about challenges mentioned in my previous response. You could avoid them by creating a parameter-context template on Dev.  This would be a parameter context with all the keys but no assigned values. Then when you import the flow to prod from dev you can uncheck the box for "Keep Existing Parameter Contexts" so that a new unique named parameter context is created each time you import the flow.  Then you can update that newly generated parameter context with a flow specific name and slow specific values assigned to those parameters that currently have no values. Back on dev, if you make a change involving a newly introduced parameter key, simply update the parameter-context-template with the new key without an assigned value.   Now when you change version in dev, you'll get the new key that you just need to assign prod specific flow value to.   Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@MuruganFinastra  Since you are getting a 403 response, the first thing you should do is see what user identity this 403 is being returned for.  For this you'll want to be tailing the nifi-user.log while you attempt to make this rest-api call. You will see the denied related log lines in the nifi-user.log.  That logging will provide the user identity string and which NiFi authorization policy required for which that user identity did not have the required permissions.   Using this output, we can determine the next steps required here.  Is the expected user identity being logged? What is the logged authorization policy resulting in the 403 response? Also which user authentication and authorization configuration options are you using in your setup? Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

If "Infer Schema" isn't working this is likely a bug. Could you provide an example JSON and the error message that happens during schema inference? ... View more

@Green_  I had the same issue can you please share the detailed steps of how you resolved it? As I'm new to NiFi. ... View more

I am also experiencing this issue when attempting to write data to a redis in cluser mode. Did you find a solution or workaround @sofronic ? ... View more

Hello Eyal, thanks once again for your interest in helping out.   I have not expressed myself correctly. I believe there is no backpressure, as I confirmed visually on the nifi UI. On the upper banner I see there are globally about 5000 flowfiles circulating at a particular time. I see some of the queues have 20, 50, 100, 200 flowfiles waiting at an instant. The queue that has more queued flow files is the kafka producer processor, that has about 2000. I believe these quantities are not sufficient to trigger backpressure-caused adjustment of scheduling of tasks.   Apache Benchmark sends concurrent http requests. In this case, i set each of the 5 client instances to send each 1000 requests concurrently.   I have thread pool sized to 96 and assigned 16 concurrent tasks to all of the critical path processors. Despite this, I get a low core load average (between 2 and 7), the disk's IOPS are in the dozens per second (the maximum that the disks allow is 3000). I'm all out of ideas at this point. 😄   Thanks for the support! ... View more

@F_Amini  @Green_ Is absolutely correct here.  You should be careful when increasing concurrent tasks as just blindly increasing it everywhere can have the opposite effect on throughput.  I recommend stopping setting the concurrent tasks back to 1 or maybe 2 on all the processor where you have adjusted away from the default of 1 concurrent task. Then take a look at the processor further downstream in your dataflow where it has a red input connection but black (no backpressure) outbound connections.  This processor s @Green_ mentioned is the processor causing all your upstream backlog.  Your'll want to monitor your CPU usage as you make small incremental adjustments to this processors concurrent tasks until you see the upstream backlog start to come down.   If while monitoring CPU, you see it spike pretty consistently at 100% usage across all your cores, then your dataflow has pretty much reached the max throughput it can handle for yoru specific dataflow design.  At this point you need to look at other options like setting up a NiFi cluster where this work load can be spread across multiple servers or designing your datafow differently with different processors to accomplish same use case that may have a lesser impact on CPU (not always a possibility).  Thanks, Matt ... View more

Hi, thanks for the details. Unfortunately it is not working. I get an empty array [] as output. I have tried it with extract and split mode. I applied the schema text property as suggested with "NestedKey" and "nestedValue" as name. None gives me an output. Meanwhile I have achieved what I wanted using SplitContent and then again another jolt processor. Of course it would be more elegant if I could make it work with ForkRecord. ... View more

Hi @ripo ,   I've tried it out in my own environment and it does not seem like ports have an 'ENABLED' state. If a port is DISABLED, you can only update it to be STOPPED. from a STOPPED state, you can either switch the port to RUNNING or back to DISABLED. ... View more

@Green_ Thank you so much ! It worked as expected. ... View more