Hi @jayGenesis , Impala supports simple bind authentication in CDH 6.3. The documentation for reference:   LDAP BaseDN (--ldap_baseDN) Replaces the username with a distinguished name (DN) of the form: uid=userid,ldap_baseDN. (This is equivalent to a Hive option). LDAP Pattern (--ldap_bind_pattern) This is the most general option, and replaces the username with the string ldap_bind_pattern where all instances of the string #UID are replaced with userid. For example, an ldap_bind_pattern of "user=#UID,OU=foo,CN=bar" with a username of henry will construct a bind name of "user=henry,OU=foo,CN=bar".   This means that with the mentioned base dn configured there will be a bind request from Impala towards the LDAP server with  uid=<username>,ou=users,dc=ldap,dc=xxx,dc=com user dn and its password, if this user does not exist the authentication will fail. Does the mentioned user exist in the LDAP directory? ... View more

Hi @tomtobin, Cloudera ships Simba drivers  as the native drivers of the Cloudera platform. Simba drivers are not open sourced. What issues were you experiencing with the drivers and with which version? ... View more

Hi @jaya123, Earlier when I have seen ImpalaThriftAPICallFailed it was due to a connection timeout between the client and Impala. Through ODBC/JDBC the connection can become inactive when Impala is executing the query, if the client tries to use a closed connection the call fails. The client might be trying to close the connection as well. Possible causes of the connection termination could be: A load balancer terminates the idle connection The driver closes the connection because SocketTimeout is reached The TRACE level driver logs can help to identify how and when was the connection terminated the next steps could be: Enable TRACE level driver logging, the log level and the log path has to be configured, please see our documentation here. This configuration is often client specific. Open the connection logs and look for the  ImpalaThriftAPICallFailed message. Check the earlier messages, there could be other errors or the connection was probably closed just before the client request. The timestamps should help identify which timeout was reached, the SocketTimeout is 30s by default. The timeouts could be reached because a slow query execution or because the client did not close the query. As the dashboard is refreshing it is probably because the client does not close the query. Just in case the query speed should be checked, if that is fine then the socket timeout could be increased a bit to give time for the client to close the query. ... View more

Hi @mrmikewhitman, Based on the error message it appears to be a certification issue. I would start by verifying if the certificate is valid with openssl and check if it works with impala-shell to connect to Impala. Additionally, with a proxy installed there are further requirements, please see them here. ... View more

Hi @Asad, Impala does not fully support unicode characters at the moment, please see 'Character sets' chapter of our documentation here for more information. Could you advise if the data is stored in UTF-8? ... View more

Hi @Shruhti, This indeed odd, my first assumption would be that the 'select 1' queries are triggered by a client application such as a BI tool silently. Maybe to check/keep the connection alive? Might worth checking the trace level driver logs, that could verify if the queries are coming from a tool/application. This can be done by changing the driver log level, which is described here for ODBC. Additionally, the query profile contains a Network Address as well, this should help confirm whether the source of the query is valid. ... View more