Member since
08-08-2024
102
Posts
27
Kudos Received
10
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 310 | 04-15-2026 11:56 AM | |
| 735 | 04-07-2026 02:00 PM | |
| 337 | 03-12-2026 09:53 AM | |
| 357 | 03-04-2026 03:07 PM | |
| 501 | 02-10-2026 07:31 PM |
04-24-2026
11:57 AM
1 Kudo
Hello @Dagonvlg, As far as I know, NiFi 2 does not have a stateless mode to the entire service. That was removed. But what it offers is an stateless engine. You can configure it at Processor Group level: https://nifi.apache.org/nifi-docs/user-guide.html#stateless-execution-engine
... View more
04-21-2026
08:43 AM
Hello @dylee, Try with https://archive.cloudera.com/p/cdp-public/ this one do open and have all the available versions.
... View more
04-17-2026
04:16 PM
Hello @MusabAlosaimi, I would suggest to open an administrative case on Lighthouse. They could help you updating your profile.
... View more
04-15-2026
11:56 AM
3 Kudos
Hello @karsten, You should not include anything under the unpacked folder, after a restart it will always remove the content and the new unpack will put only the nar content. Now, you can use the resources path for this, for example: ├── your-nifi-custom-processor
│ ├── pom.xml
│ └── src
│ └── main
│ ├── java
│ ├── resources
│ └── data
│ │ └── config.ini
│ └── webapp This is based on the examples here: https://nifi.apache.org/docs/nifi-docs/html/developer-guide.html You should include all the information on your pom.xml. The resources part should look like this: <resources>
<resource>
<directory>src/main/resources</directory>
<includes>
<include>**/*</include>
</includes>
</resource>
</resources> Also found this interesting blog with the same explanation: https://medium.com/@mr.sinchan.banerjee/nifi-custom-processor-series-part-1-writing-your-first-custom-processor-dd7aa901c896 This is not Cloudera or NiFi official, but it could help you.
... View more
04-09-2026
09:02 AM
1 Kudo
Hello @YSFSK, I understand now. I do see the error you mention: 2026-04-02 12:22:09,133 INFO [MiNiFi logging handler] org.apache.nifi.minifi.StdOut 12:22:09.133 [pool-15-thread-1] DEBUG org.apache.nifi.controller.serialization.VersionedFlowSynchronizer -- Could not find a compatible bundle for org.apache.nifi:nifi-azure-nar:2.4.0 type org.apache.nifi.processors.azure.eventhub.PutAzureEventHub That error points to be a problem with the version. So we are basically on the same point. We have nifi-azure-nar at 2.4.0, nifi-azure-services-api at 2.3.0 and nifi-cdf-debezium-postgresql at 1.28.1. This is a mix that is not working. I do not know the NiFi version you have, but should use that version for all the NARs as well. Using different versions is not a good idea. You can download them from the Sonatype Nexus Repository.
... View more
04-08-2026
01:05 PM
Hello @YSFSK, I do not understand part of your response. I attempted to test the same Debezium NAR with a more recent version, however, we were unable to upload new extensions to EFM. Why you were unable to upload it? Any errors? I understand your point regarding the use of an older Debezium NAR version. However, we also conducted tests using a separate class and flow that included only the two Azure NARs (both are above 2.3 in versions) without the debezium processer & nar (About a year ago, this same flow and exact NARs worked with the exact same MiNiFi image currently tested). For this reason, I believe the issue may not be solely related to the Debezium 1.x NAR, as the EventHub processor is also affected. On the first part you say that tested only with the two Azure NARs on 2.3, which should be good for your version, without the Debezium 1.x, and it worked. Which makes sense that this points to this Debezium 1.x NAR only as it is created for a different version. On Sonatype Nexus Repository I do see Debezium 2.3 version, that is the correct for your environment.
... View more
04-07-2026
02:00 PM
1 Kudo
Hello @YSFSK, MiNiFi version you have is compatible with CFM 4.2.0, which is based on NiFi 2 https://docs.cloudera.com/cem/2.2.0/release-notes-minifi-java/topics/cem-java-agent-processors.html You mentioned you downloaded nifi-cdf-debezium-postgresql-nar-1.28.1.2.1.7.2006-1.nar that is for NiFi 1.28. I checked and the nar is available for different 2.x versions, so you should select one that it matches your NiFi version. Do the same for the other two NARs, they are 2.4 and 2.3, so just make sure they match the actual version.
... View more
03-12-2026
09:53 AM
1 Kudo
Hello @criki, No, PutS3Object itself does not perform MD5 integrity check. This can be confirmed on the processor source code where we do not have any checksum method: https://github.com/apache/nifi/blob/main/nifi-extension-bundles/nifi-aws-bundle/nifi-aws-processors/src/main/java/org/apache/nifi/processors/aws/s3/PutS3Object.java On this link you can see how the SDK can configure the MD5 checksum, which is not part of the processor code: https://docs.aws.amazon.com/AmazonS3/latest/userguide/checking-object-integrity-upload.html What you can do is, in your Flow, add a hash and then review it. First with CryptographicHashContent create the hash, then do the PutS3Object. After that, you can confirm it is fine do FetchS3Object then CryptographicHashContent and compare the hash with RouteOnAttribute.
... View more
03-04-2026
03:07 PM
1 Kudo
Hello @jI-mi, As @haridjh told, it will be good to know the CVE that you're seeing to confirm if this is solved or reported. Anyways, there are some fixed Apache Shiro CVEs documented here: 7.1.8 CHF2: https://docs.cloudera.com/cdp-private-cloud-base/7.1.8/runtime-release-notes/topics/chf2-pvcb-718.html CDPD-45726 - Upgrade Shiro to 1.10.0 due to CVE-2022-40664 CDPD-45727 - CDPD - Upgrade Shiro to 1.10.0 due to CVE-2022-40664 7.1.8 CHF18: https://docs.cloudera.com/cdp-private-cloud-base/7.1.8/runtime-release-notes/topics/chf18-pvcb-718.html CDPD-59365: CDPD - Upgrade Shiro to 1.12.0 due to CVE-2023-34478 CDPD-59364: Upgrade Shiro to 1.12.0 due to CVE-2023-34478 7.1.8 CHF19: https://docs.cloudera.com/cdp-private-cloud-base/7.1.8/runtime-release-notes/topics/chf19-pvcb-718.html CDPD-65013: CDPD - Upgrade Apache Shiro to 1.13.0 due to CVE-2023-46750 CDPD-65012: Upgrade Apache Shiro to 1.13.0 due to CVE-2023-46750 7.1.9: https://docs.cloudera.com/cdp-private-cloud-base/7.1.9/runtime-release-notes/topics/fixed_common_vulnerabilities_exposures_719.html CVE-2023-22602 - When using Apache Shiro before 1.11.0 together with Spring Boot 2.6+, a specially crafted HTTP request may cause an authentication bypass. 7.1.9 SP1: https://docs.cloudera.com/cdp-private-cloud-base/7.1.9/runtime-release-notes/topics/rt-pvc-cve-719sp1.html CVE-2023-34478 Apache Shiro CVE-2023-46749 Apache Shiro CVE-2023-46750 Apache Shiro 7.1.3 SP3 CHF1: https://docs.cloudera.com/cdp-private-cloud-base/7.3.1/private-release-notes/topics/fixed-common-vulnerabilities-exposures-731_600.html CVE-2023-46750 - Shiro Ehcache CVE-2023-46749 - Shiro Ehcache CVE-2023-34478 - Shiro Ehcache CVE-2023-22602 - Shiro Ehcache CVE-2022-40664 - Shiro Ehcache CVE-2022-32532 - Shiro Ehcache CVE-2021-41303 - Shiro Ehcache CVE-2020-1957 - Shiro Ehcache CVE-2020-17523 - Shiro Ehcache CVE-2020-17510 - Shiro Ehcache CVE-2020-13933 - Shiro Ehcache CVE-2020-11989 - Shiro Ehcache CVE-2019-12422 - Shiro Ehcache CVE-2016-4437 - Shiro Ehcache CVE-2010-3863 - Shiro Ehcache Take a look on those CVE and see if the one you need to resolve is included there. I found two that looks similar to what you mentioned: https://nvd.nist.gov/vuln/detail/CVE-2023-46749 solved in 7.1.9 SP1 https://nvd.nist.gov/vuln/detail/CVE-2023-46750 solved in 7.1.8 CHF19
... View more
03-03-2026
03:11 PM
2 Kudos
Hello @okanergun, According to https://issues.apache.org/jira/browse/NIFI-8630 the PutEmail processor was updated as mentioned here: "Upgraded javax.mail 1.4.7 to jakarta.mail 2.0.1 for PutEmail" That was on 1.14.0, so in your case, you were using the old javax.mail and not the new jakarta.mail. There is a difference on the environment to take in consideration. The log you shared shows this: Couldn't connect to host, port: smtp.office365.com, 587; timeout -1 This means you do not have a socket timeout defines, which could case the processor to hang and report those timeouts when OS tells so. You can try to add these setting: -Dmail.smtp.connectiontimeout=30000 -Dmail.smtp.timeout=30000 -Dmail.smtp.writetimeout=30000 https://eclipse-ee4j.github.io/angus-mail/docs/api/org.eclipse.angus.mail/org/eclipse/angus/mail/smtp/package-summary.html Also, make sure you have "Concurrent Tasks" under the PutEmail processor set to 1. This kind of SMTP for Microsoft may block parallel connections.
... View more