Member since
03-10-2017
155
Posts
77
Kudos Received
32
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
249 | 08-12-2024 08:42 AM | |
665 | 05-30-2024 04:11 AM | |
1169 | 05-29-2024 06:58 AM | |
682 | 05-16-2024 05:05 AM | |
560 | 04-23-2024 01:46 AM |
08-19-2024
07:03 AM
Hi @ckumar , I couldn't find the command, would it be in the parcels path as shown in the attached printout?
... View more
08-13-2024
05:30 PM
1 Kudo
Thanks kumar. Yeah we found that content repository file was not persistent in our container. After changing that , it works.
... View more
08-12-2024
07:54 PM
1 Kudo
Hi Ckumar, recently I can not open the UI because the error of 403 when I check the nifi-request.log file also. I think all error come from same reason.
... View more
08-09-2024
09:17 PM
thank u very much. that helped me
... View more
06-14-2024
07:46 AM
1 Kudo
@Alexy Without seeing your logs, I have no idea which NiFi classes are producing the majority of your logging. But logback is functioning exactly as you have it configured. Each time the nifi-app.log reaches 500 MB within a single day it is compressed and rolled using an incrementing number. I would suggest changing the log level for the base class "org.apache.nifi" from INFO to WARN. The bulk of all NiFi classes begin with org.apache.nifi and by changing this to WARN to you will only see ERROR and WARN level log output from the bulk of the ora.apache.nifi.<XYZ...> classes. <logger name="org.apache.nifi" level="WARN"/> Unless you have a lot of exception happening within your NiFi processor components used in your dataflow(s), this should have significant impact on the amount of nifi-app.log logging being produced. Please help our community thrive. 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
06-10-2024
10:32 PM
@Naveen_Sagar, were you able to resolve this issue? If you were, could you please share the solution so that it can help others? If you still have concerns, could you please provide the information that @ckumar has requested?
... View more
06-06-2024
07:12 AM
@alan18080 NiFi-Registry only pushes to the GitFlowPersistenceProvider while running. NIFi-Registry will only read from Git on startup. The GitFlowPersistence Provider also only contains the flow definitions for the version controlled process groups. Each NiFi-Registry has a metadata database maintains the knowledge of which buckets exist, which versioned items belong to which buckets, as well as the version history for each item. So if you are trying to share a single Git Repo across multiple running NiFi-Registry instances this will explain why you are seeing missing versions at times across your multiple instances. Please help our community thrive. 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
06-02-2024
10:15 PM
@Naveen_Sagar, Did the response assist in resolving your query? If it did, kindly mark the relevant reply as the solution, as it will aid others in locating the answer more easily in the future.
... View more
05-30-2024
06:17 AM
@Vikas-Nifi @ckumar is 100% correct. Only fields explicitly marked as supporting NiFi Expression Language (NEL) can support a NEL expression "${schedule}". I am however curious about your use case as to why you would even being trying to do this. From what you shared you are extracting a cron schedule from the json content of some FlowFiles traversing an EvaluateJsonPath processor. That "schedule" is added on to the NiFi FlowFile as a FlowFile attribute (key=value pair). This would not make that key=value pair accessible to any other NiFi component unless that FlowFile containing the FlowFile attribute was processed by that other component. However, in your shared dataflow you do not mention that EvaluateJsonPath connects to your invokeHTTP processor via an inbound dataflow connection (Keep in mind that even if you did do this, it does not change the fact that the run schedule property does not support NEL). I just wanted to clarify how FlowFile attributes are and can be used. Also keep in mind that the "run schedule" is a scheduler only. The run schedule set on a processor controls when the NiFi controller will schedule the execution of the processors code. It does not mean that they the processor will immediately execute at time of scheduling (It may be delayed on execution waiting for an available execution thread from the thread pool). All scheduled components share a thread pool and NiFi framework will also handle assigning threads to next scheduled component as thread become available. So the NiFi framework needs to know the scheduling for a component when it is started; otherwise, NiFi would never know when to schedule it to execute. Unless a component property has an explicit tool tip that tells you it support NEL, then it does not. For NiFi processor components, you will find that only some processor specific properties within the "PROPERTIES" tab support NEL. This is not only available through property tooltips, but also in the processors documentation. Examples: Even when NEL is supported there is a scope. It may support FlowFile attributes, Variable Registry (going away in NiFi 2.x releases), or both. Thank you, Matt
... View more
05-16-2024
05:43 AM
1 Kudo
yes I think that was the issue. I am still new to Nifi and slowly learning to work with it. Thank you @ckumar
... View more