Member since
12-03-2017
157
Posts
26
Kudos Received
11
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 2750 | 11-03-2023 12:17 AM | |
| 5086 | 12-12-2022 09:16 PM | |
| 2078 | 07-14-2022 03:25 AM | |
| 2889 | 07-28-2021 04:42 AM | |
| 4078 | 06-23-2020 10:08 PM |
08-28-2022
04:17 PM
@hegdemahendra , You need to set the time characteristic of the stream for it to work. For example, try setting it to processing time, as shown below: DataStream<String> matechedStream = patternStream
.inProcessingTime()
.process(new PatternProcessFunction<String, String>() {
@Override
public void processMatch(Map<String, List<String>> map, Context context, Collector<String> collector) throws Exception {
collector.collect(map.get("start").toString());
}
}
); Cheers, André
... View more
08-01-2022
09:07 PM
1 Kudo
@MattWho - We have separated out ebs volumes of each repos and also 3 ebs volumes each for content and provenance repos. Now looks like issue is pretty much resolved ! Thanks for all your suggestions, helped a lot Thanks Mahendra
... View more
07-26-2022
05:44 AM
This is related to Jira https://issues.apache.org/jira/browse/NIFI-9993 , fixed in the latest release 1.16.3 If you found this response assisted with your issue, please take a moment to login and click on "Accept as Solution" below this post. Thank you, Chandan
... View more
07-14-2022
03:25 AM
testRunner.setAllowSynchronousSessionCommits(true); Helped me to get rid of this error
... View more
07-10-2022
04:15 AM
@hegdemahendra Thank you for your reply.. It will be a continuous migration that will run for few months... Once all the historic data is migrated, it will be a CDC. The no of tables could be close to 20-30 tables.. I dont know yet about the volume but it will be huge... Based on your response, the solution looks like the combined approach for multiple tables and CDC. Could you please share little more details about this approach?
... View more
07-05-2022
10:50 PM
1 Kudo
Issue created : https://issues.apache.org/jira/browse/NIFI-10197
... View more
02-07-2022
02:36 PM
What @DigitalPlumber said. Also make sure that Match Requirement is set to "content must contain match", otherwise it won't work.
... View more
01-19-2022
08:35 AM
Hi @ckumar - thanks for the reply. I think that screenshot lacked info may be due to my permission issue. Same issue has been posted by team mate here - https://community.cloudera.com/t5/Support-Questions/NiFi-Node-showing-2-nodes-and-not-respecting-node-down-fault/td-p/334221 Please take a look at the screenshot attachment there which has more info. And i can login from all 3 nodes ui, and in all nodes it shows up only 1 & 2.
... View more
12-17-2021
06:18 AM
Hello @alim, Can you please indicate where I can find the ./conf/providers.xml file ? Also regarding this "Flow snapshot histories are managed as Git commits, meaning only the latest version of Buckets and Flows exist in the Git directory.", is there any way to save all versions of a specific flow in GIT? Thank you!
... View more
09-24-2021
09:24 AM
1 Kudo
@hegdemahendra That is a possibility. The 'Maximum Timer driven thread count' settings sets a thread pool that is used by the NiFi controller to hand out threads to dataflow components when they execute. The general recommendation is setting this value to 2 to 4 times the number fo cores present on a single NiFi instance (If you are running a NiFi cluster, this is setting is applied per node and not a max across entire cluster). This does not mean that you can not set the thread pool much higher like you have, but you need to do that cautiously and monitor CPU usage over extended periods of time as your dataflows may fluctuate between periods of high and low CPU demand. It is the cycles of high CPU usage that can become problematic. What you have in your scenario is 8 cores trying to service threads (up to 300) for your dataflows, NiFi core level threads (not part of that thread pool), and threads associated to any other services on the host and the OS. So i suspect you have many thread often in CPU wait, waiting on their time on a core. You could also have a scenario where one thread is WAITING on another thread which is also WAITING on something else. So as the system cycles through all these threads you end up with periods of time of what appears to be a hung system Your dataflow components used and how they are configured along with volumes of data play in to the overall CPU usage and length of time a thread is actively executing. Interesting that you stated that all logging stops as well. The fact that all logging stops, makes we wonder if with so many threads, some core thread get left in CPU wait so long they impact logging. Have you tried getting thread dumps from NiFi when it is in this hung state? Examining a series of thread dumps might help pinpoint if you get in to state were you have threads waiting on other threads that are not progressing. You may also want to take a close look at disk IOPS for all NiFi repos which can affect performance with regards to how long a thread takes to complete. Also keep in mind that large dataflows and large volumes of FlowFiles can lead to a need for many open file handles. Make sure your NiFi Service user has access to a LOT of file handles (999,999 fo example). Your dataflows may also be spinning off a lot of processes, so make sure your NiFi service user also has a high process limit. Hope this helps you look for areas to dig in to your issue, Matt
... View more
- « Previous
- Next »