About vafs

vafs · ‎04-09-2026

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.

vafs · ‎04-08-2026

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.

vafs · ‎04-07-2026

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.

vafs · ‎03-12-2026

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.

vafs · ‎03-04-2026

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

vafs · ‎03-03-2026

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.

vafs · ‎02-23-2026

Hello , That error is not normal, and the mount should exist. So this points to be some external issues that may be identified by Cloudera Support on case. What risks you may face, the first is considering that deployments are handled by Cloudera, so in future updates of it may get overwritten. Your steps are fine, should work, but still a support case would be a safer option. If you still want to proceed, do that, rollout the pods and then check status: kubectl exec -it deploy/api -- ls -lah /projects kubectl exec -it deploy/api -- touch /projects/test.txt

vafs · ‎02-17-2026

Hello @Sid17, This looks very similar to what we see here: https://community.cloudera.com/t5/Support-Questions/Jolt-spec-to-flatten-the-nested-JSON/m-p/399054#M250380 Can you take a look on that and see if it helps?

vafs · ‎02-15-2026

Hello @hckorkmaz01, I was testing one way that in CFM didn't worked, but in your case, in NiFi directly, it may work, you can test. Under NiFi settings, create a reporting task like this: You will need to use this QueryNiFiReportingTask. This query should work for what you need: SELECT QUEUE_ID, QUEUE_NAME, FLOWFILE_COUNT, CONTENT_SIZE FROM FLOWFILE_QUEUE_STATS Then save the output to either log or any other method you prefer. Another option I was thinking is to use InvokeHTTP processor. To get the information you need. That will be in NiFi but using the REST API: GET http://localhost:8080/nifi-api/flow/process-groups/<PG_ID>/connections That could be an option for you. Maybe test this and let us know if that worked.

vafs · ‎02-15-2026

Hello @aaaver, Just wanted to see if you can share little bit more details, for example, the NiFi version and if your using the CFM provided by Cloudera. Have you followed these steps from the documentation? https://docs.cloudera.com/cfm-operator/2.11.0/configure-nifi-cr/topics/cfm-op-configure-nifi-cr-oidc-auth.html

Online	Offline
Last Visited	‎08-14-2026 08:51 PM

Member Since	‎08-08-2024 10:35 AM
Last Visited	‎08-14-2026 08:51 PM
Posts	118
Kudos received	30

Cloudera Community

Re: Missing certification appointment

Re: Cloudera Data Visualization — Passing Paramete...

Re: Support of OpenJDK 17

Re: Successfully Passed the Cloudera Certification...

Re: Using Cloudera Provider of Apache Airflow with...

Re: Issue with Added NARs in MiNiFi/EFM - New proc...

Re: Issue with Added NARs in MiNiFi/EFM - New proc...

Re: Issue with Added NARs in MiNiFi/EFM - New proc...

Re: Apache Nifi PutS3Object integrity check

Re: security related problem file

Re: PutEmail Timeout smtp.office365

Re: Runtime Addon Upload Failing - "Failed saving ...

Re: JOLT to flatten nested JSON

Re: JOLT Guide for Apache NiFi

Re: Nifi cannot auth using OIDC keycloak with prox...