We're using the 2.5.41 version of the Cloudera Impala ODBC driver on Windows 64 bit to support connectivity from the Spotfire BI platform. We've found that the time taken to make a connection to our Impala servers varies massively depending on whether the connection is made from a Spotfire server with a lot of RAM vs. one with less RAM. The connections on a machine with 160GB RAM can take over a minute, whereas connections from a server with 8GB of RAM take roughly 1 second.
I believe I've traced the problem to an issue in the implementation of random numbers within OpenSSL. Versions of OpenSSL up to 1.0.1 (as used by the ODBC driver) include a method of seeding random numbers by walking the heap of the process, whereas OpenSSL 1.1.0 has removed this approach (https://github.com/openssl/openssl/commit/eb9b92ec8efd81abf4642b65c34cc542197a545a#diff-805d74d112f0...).
I enabled trace logging within the ODBC driver and can see that the delay is between these lines (this particular example "only" took 27 seconds to connect):
May 09 04:18:26.346 TRACE 10208 ImpalaClient::Connect: +++++ enter +++++
May 09 04:18:53.156 DEBUG 10208 TEUtils::DeriveKerberosHostFQDN: Special value _HOST specified for Host FQDN connfiguration. Using xxxxxxxxx for Host FQDN instead.
I checked network traces and there is no activity during this delay - network activity starts shortly afterwards showing that the delay is before the SSL connection is made. Finally, I used Process Explorer to look at what was happening and can clearly see that CPU is being used during the delay and the thread using the CPU is processing within the LIBEAY32 dll, include the RAND_POLL method.
So - can the driver be updated to use the latest version of OpenSSL so as to remove this issue? Unfortunately, the problem renders the driver rather unusable as there are significant delays whenever the user interacts with the application and data is required.
Thanks. That's actually a different problem - my problem is that the initial connection itself is very slow, prior to issuing any sort of query. Once you're connected queries run fine and data is retrieved at the expected rate.
I've got a ticket open with Cloudera and they've reproduced the problem. No word yet on a fix, but hopefully they'll provide one soon.