CLI error when parsing thru the Impala/Hive table using SAS ODBC

[#1]

We are facing the CLI Error intermittently, when parsing thru Impala(Both Parquet/Standard) and Hive tables using SAS ODBC Connection.

Impala Error:
 
ERROR: CLI cursor fetch error: [Cloudera][ImpalaODBC] (120) Error while retrieving data from in
       Impala: [HY000] :  RPC Error: SSL_read: Resource temporarily unavailable


Hive Error:

ERROR: CLI cursor fetch error: [Cloudera][Hardy] (35) Error from server: error code: '0' error
       message: 'Invalid OperationHandle: OperationHandle [opType=EXECUTE_STATEMENT,
       getHandleIdentifier()=aef23648-028f-4252-9769-97b4997f7d2d]'. 

Any help is higly appriciated!!

[#2]

@SpoorthyB

pls hide the confidential info and share the command that you have used

[#3]

Hi Sravan,

code is pretty straight farward with simple libname and proc sql statements :

libname impala odbc dsn="XXXXXXX" user=XXXXXXX password='XXXXX' schema=XXXX;
libname tgtlib "XXXXX";

proc sql;
create table tgtlib.xyz as
select * from impala.xyz;
quit;

[#4]

@SpoorthyB

Do you have kerberos enabled in your environment?

Also pls check that your issue is related to the one mentioned in this link

https://issues.apache.org/jira/browse/IMPALA-5020

[#5]

Saranvisa,

I have active ticket from kerberos.

proc sql (executing from PC SAS) runs for about 15-20min and then it fails with above error saying resource unavaialble.

fyi, this is a huge table with 4k+ columns and 2 million+ records.

Tried with filtering data to different chunks and it works fine, but issue is I get duplicate records in each indivudual chuck i.e. count mismtach with source.

[#6]

@SpoorthyB

Can you execute your query directly in Impala/Hive?

it may need detailed analysis, becuase

1. If your answer is yes for my above question, the similar issue "Resource temporarily unavailable error message from Impala shell " has already been discussed in this link

https://community.cloudera.com/t5/Interactive-Short-cycle-SQL/Resource-temporarily-unavailable-error...

2. if your answer is no then it might be an issue with ODBC (or) your network capacity issue for the table with huge size.