Cloudera Runtime Release NotesPDF version

Fixed Issues in Apache Kudu

Review the list of Apache Kudu issues that are resolved in Cloudera Runtime 7.2.14.

Validation for extra configuration properties for a table
A new validation logic is added. It is performed on the strings representing the keys of extra configuration properties for a Table. As a result an error is returned on attempt to set unsupported extra configuration properties for a table.
Custom hash schema criterion in KuduTableCreator::Create()
This patch fixes a bug in KuduTableCreator::Create(). The criterion for the presence of custom hash schemas per range flag accounts when the table-wide hash schema is non-empty, but there is a range partition with empty hash schema.
KUDU-75: Allow RPC proxies to take HostPort and do DNS resolution inline with calls
Kudu will now automatically re-resolve addresses in cases where a tablet server address is no longer valid. This previously manifested itself as a crash when DNS resolution between servers failed.
KUDU-1938: Support for VARCHAR type
It's now possible to create Kudu tables with VARCHAR columns using impala-shell since KUDU-1938 and IMPALA-5092 have been addressed.
KUDU-3295: kudu client cannot read if one of tablet replica is unhealthy
When the tserver is shutdown and its DNS cannot be resolved, it is still possible for the client to receive the replicas including this tserver. As a result, discoverTablets sees the servers size not equal to replica size because the replica does not verify server connectivity. This patch fixes this issue by ignoring replicas whose server cannot be resolved.
KUDU-3334: Clarify whether it's possible to hide libprotobuf symbols exported from libkudu_client
Conflicts happened during static initialization of symbols related to protobuf extensions in an application using libkudu_client and also linking in libprotobuf on its own.This patch adds the --exclude-libs flag for the GNU linker to completely hide all symbols inherited by libkudu_client from libprotobuf.
KUDU-3341: Catalog Manager should stop retrying DeleteTablet when receive WRONG_SERVER_UUID error
When the calatog_manager tries to delete a tablet but gets WRONG_SERVER_UUID error it will not retry this task because the served uuid can only be corrected by restarting the tablet server.

We want your opinion

How can we improve this page?

What kind of feedback do you have?