Hi all,   Issue has been resolved , while running job at staging level it requires more space in HDFS but no sufficient space in HDFS after added more disks , then job got success. ... View more

HI @damon The most likely culprit, in this case, would be the Packet length crossing the jute buffer limit. As this is seen for the Kms service, verify if you are getting any warnings such as "Packet len is out of range!"   If you do, then raise the jute buffer for the Zookeeper service as well as for the Kms service ( client ) and restart the respective services to resolve this issue. ... View more

Hi @kolli_sandeep , I believe you are talking about Secondary Namenode and not the Standby Namenode on a Non-HA cluster. If so, the functionality of the Secondary Namenode would be to perform the checkpointing of the fsimage with the new edits.   The Secondary NameNode does require some memory to hold the data structures and objects necessary for merging the edits log and the FsImage. However, it does not load the entire FsImage into memory at once. As such, I would suggest keeping the heap to atleast 2x times the fsimage fpr smooth functioning. ... View more

@JobBranwl This is Kerberos issue now and moreover with the usage of keyring for ticket cache which is not supported. You can refer to the below post to see if that helps.   https://community.cloudera.com/t5/Support-Questions/Unable-to-access-Hadoop-CLI-after-enabling-Kerberos/m-p/305291 ... View more

Hi @stephen_obrien As discussed via Cloudera case, there is a performance bottleneck when connecting via knox ( tracked in internal jira ) than directly from phoenix-sqlline from the edge node.   You can test the same when the runtime version 7.2.17 is released. ... View more