question Re: hue - impala query on hue, returns error - TSocket read 0 bytes in Support Questions

hue - impala query on hue, returns error - TSocket read 0 bytes

yagoaparecidoti — Tue, 21 Apr 2026 06:17:41 GMT

hi community cloudera,

recently, we've been receiving the following error when querying impala on hue:

queryerror: tsocket read 0 bytes (code thrifttransport): ttransportexception('tsocket read 0 bytes',)

- the "query_timeout_s" and "session_timeout_s" parameters have already been set to 2 hours in the hue settings.
- the hs2 and impala thrift connection timeout has already been set to 2 hours in the hue settings.
- the hs2 authentication timeout has already been set to kerberos in the hue settings.
- the "proxytimeout" parameter has already been set to 10 minutes in the hue settings.

and we're still receiving this error.

has anyone experienced this issue and managed to resolve it?

we're using cdh 6.3.4.

Re: hue - impala query on hue, returns error - TSocket read 0 bytes

Boris G — Tue, 29 Jul 2025 17:33:20 GMT

Hello-

The error means that the socket connection cannot be instantiated or was closed by the peer.

In the setup, the most likely reasons are:

a. the coordinator to which Hue is trying to connect is down

b. the coordinator to which hue is trying to connect has its front end connections pool maxed out

c. the coordinator is down or not listening on the port forwarded by the loadbalancer

d. a network connectivity issue (including a faulty loadbalancer)

A good alternative test would be to run an impaal-shell connection to the same coordinator:

impala-shell -b <loadbalancer FQDN> -i <coordinator FQDN> ..... <the rest of the impala-shell parameters>

- if the same issue cannot be reproduced then the issue is likely on the Hue side (network as mentioned and/or a port to which Hue is configured to connect), else

- the issue is likely with the coordinator itself (it cannot accept new connections - front end connection pool is maxed out or the daemon itself is in a bad state. Usually restart should help then.

There is also a slight chance that your kerberos is misconfigured - if the issue happens only when you run a Hue connection.

As you can see there may be many reasons to what is happening. We usually investigate these kinds of issues via analyzing logs and traces in Cloudera Support tickets.

Re: hue - impala query on hue, returns error - TSocket read 0 bytes

yagoaparecidoti — Thu, 31 Jul 2025 12:14:19 GMT

hi @Boris G,

we believe the problem is with Impala and not Hue, as the same error is occurring when trying to connect directly to the Impala daemon host with Impala-shell.

Re: hue - impala query on hue, returns error - TSocket read 0 bytes

yagoaparecidoti — Thu, 31 Jul 2025 13:14:58 GMT

hi @Boris G,

example of an error collected in the impalad log:

E0731 04:30:49.177050 59498 authentication.cc:164] SASL message (Kerberos (external)): GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Clock skew too great)

error when trying to connect to impalad with impala-shell:

Error connecting: TTransportException, TSocket read 0 bytes

Researching this error (Clock skew too great), it's something related to NTP synchronization, but the NTP service is synchronized with KDC (AD), as shown in the chronyd tracking command:

Ref time (UTC): Thu Jul 31 12:25:09 2025

Date command:

Thu Jul 31 09:25:14 -03 2025

PS: My timezone is -3.

Re: hue - impala query on hue, returns error - TSocket read 0 bytes

Boris G — Thu, 31 Jul 2025 17:57:41 GMT

The "Clock skew too great" error in your release (which is out of maintenance due to its age) usually happens when the daemon is overloaded and KRPC is *not* enabled (--use_krpc=false in the Impala safety valve). That is likely why you see those errors. Although - certain overload conditions trigger unusual errors regardless.

That is likely why you get the rejection on any client.

You can try several things:

a. make sure "--use_krpc=false" is not in the current Impala configs

b. adjust the workload

c. if you get the error with near zero load *after the coordinator restart* that definitely points at a network issue as I have alluded to before

d. make sure the coordinator host's kernel settings are adequate:

kernel.pid_max = 1048480
vm.max_map_count = 1048480
kernel.pid_max = 2000000
vm.max_map_count = 8000000