Member since
11-17-2021
1154
Posts
259
Kudos Received
30
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 234 | 04-23-2026 02:02 PM | |
| 700 | 03-17-2026 05:26 PM | |
| 5613 | 11-05-2025 10:13 AM | |
| 958 | 10-16-2025 02:45 PM | |
| 1588 | 10-06-2025 01:01 PM |
03-10-2026
07:43 PM
@okanergun Has the reply helped resolve your issue? If so, please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future. Thanks.
... View more
03-10-2026
07:41 PM
@jI-mi Has the reply helped resolve your issue? If so, please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future. Thanks.
... View more
03-07-2026
06:45 AM
certificate used in ranger KMS expired which caused the pyspark job to fail. we renewed the certificate and update KMS configuration. now jobs are running fine.
... View more
03-05-2026
09:53 AM
@DevOpsWorld Has the reply helped resolve your issue? If so, please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future. Thanks.
... View more
02-24-2026
07:35 AM
Thanks to the issue created by @svenvk this was at least partially addressed in NiFi 2.8.0. The problem was that newer Avro/Parquet libraries are using Java 8 Datatypes instead of Long/Integer to represent timestamps. I say partially, because the fix only implements the Avro types: time-millis time-micros timestamp-millis timestamp-micros Missing is the type for nanosecond precision "timestamp-nanos" as well as the three "local-timestamp-{millis,micros,nanos}" types. See https://avro.apache.org/docs/1.12.0/specification/#timestamps Additionally, the new parquet viewer when displaying a flow file seems to suffer from the same problem that created the error described here. I will create new issues in the NiFi Jira 🙂
... View more
02-13-2026
09:47 AM
@FGhidotti I have reached out via DM with further steps, thank you!
... View more
02-06-2026
02:55 PM
Thanks Asish! In our product, we've already bumped up our Hive version to 4.1 and connecting from a Hive 4.1 client to Hive 3.x doesn't work in many instances. We've made some changes to Hive 4.1 to allow slightly more backwards compatibility but there are some instances where serialized objects are used and can't be deserialized because of version mismatches. Thanks, Moe
... View more
01-30-2026
09:11 PM
1 Kudo
Here are some highlights from the month of December
68 new support questions
2863 new members
WEBINAR
The Future of Agents with Private AI
Watch Now
WEBINAR
A Leader's Fireside Chat about Securing Next-Gen AI
Watch Now
Check out the FY26 Cloudera Meetup Events Calendar for upcoming & past event details!
We would like to recognize the below community members and employees for their efforts over the last month to provide community solutions.
See all our top participants at Top Solution Authors leaderboard and all the other leaderboards on our Leaderboards and Badges page.
@MattWho @vafs @venkatsambath @pajoshi @upadhyayk04 @Pedro_E @Bern @blackboks @zzzz77
Share your expertise and answer some of the below open questions. Also, be sure to bookmark the unanswered question page to find additional open questions.
Unanswered Community Post
Components/ Labels
LPAD/RPAD Parsing Issues
Apache NiFi
ConsumeKafka_2_6 leaking lot of memory in apache nifi 1.25
Apache NiFi
... View more
01-10-2026
11:06 PM
@EmilKle FYI ➤This issue typically arises because the comma (,) is a reserved delimiter in HBase for the hbase:meta table structure, used to separate the Table Name, Start Key, and Region ID. When a rowkey is inserted with an unexpected comma, the HBase shell and client API often misinterpret the entry as a malformed region name, causing GET or DELETE commands to route incorrectly or fail validation. ➤Here is how you can approach a safe repair, as traditional methods like HBCK2 fixMeta often bypass these "illegal" keys if they don't follow the expected region naming convention. 1. Use the HBase Shell with Hexadecimal Rowkeys Standard string-based commands in the shell often fail because the shell parses the comma as a delimiter. Instead, find the exact byte representation of the rowkey and delete it using hexadecimal notation. 1. Find the Hex Key: Run a scan to get the exact bytes of the corrupted row. scan 'hbase:meta', {ROWPREFIXFILTER => 'rowkey,'} 2. Delete using the binary string: If the rowkey is exactly rowkey,, use the binary notation in the shell: delete 'hbase:meta', "rowkey\x2C", 'info:regioninfo' (Note: \x2C is the hex code for a comma).
... View more