Repository navigation
socket_keepalive doesn't work with shaded clickhouse-jdbc #3092
Description
socket_keepalive doesnt' applied
Steps to reproduce
Note: I would expect that instruction from official site[1] should end up with the same result.
- Specify following option for apache/cloudberry-pxf:
or in JDBC URL
<property> <name>jdbc.connection.property.socket_keepalive</name> <value>true</value> </property>&socket_keepalive=true - expect that
SO_KEEPALIVE=true. However it is not.
Actual:Expected (spot the# ss -Otnpio state established | grep -F '8123' 0 0 [::ffff:10.1.0.9]:44198 [::ffff:10.1.0.20]:8123 users:(("java",pid=2731285,fd=34)) ts sack illinois wscale:10,4 rto:201 rtt:0.343/0.188 <cut>timersection!):0 0 [::ffff:10.1.0.29]:15938 [::ffff:10.1.0.20]:8123 users:(("java",pid=514753,fd=36)) timer:(keepalive,10sec,0) ts sack illinois wscale:10,4 rto:201 rtt:0.249/0.123 <cut>
Environment
- Cloud
- Client version: 0.9.8 and 0.10.0
- OS: Ubuntu 22.04
ClickHouse Server
- ClickHouse Server version: 26.7.5.10
CREATE TABLEstatements for tables involved:SELECT toInt32(sleep(600)) AS slept SETTINGS function_sleep_max_microseconds_per_block = 600000000, max_execution_time = 0
[1] https://clickhouse.com/docs/integrations/language-clients/java/jdbc#linux
Activity
ostinru commentedon Sep 1, 2026
Surprisingly, driver built from source sets keepalive by default, maven version - don't. It is because my build pulls fresh
httpcore5, where default behaviour changed [2].ClickHouse team, what is expected behaviour? I would expect to always have keepalive=true without option to disable it.
[2] apache/httpcomponents-core#550
[-]socket_keepalive doesn't work for me[/-][+]socket_keepalive doesn't work with shaded clickhouse-jdbc[/+][-]socket_keepalive doesn't work with shaded clickhouse-jdbc[/-][+]`socket_keepalive` doesn't work with shaded clickhouse-jdbc[/+]ostinru commentedon Sep 2, 2026
It seems, that #3079 changes:
httpclient55.4.4 -> 5.6.4httpcore55.3.4 -> 5.4.3tcp_keepalive OFF -> ON (idle=5s, interval=5s, count=3)
However I am not 100% sure about transitive dependencies and shaded libraries. Anyway, documentation should be updated to make it clear, how to enable tcp_keepalive.
chernser commentedon Sep 2, 2026
Good day, @ostinru !
Thank you for the analysis! We will look into it shortly.
Would you please tell more about your usage of
tcp_keepalive? We gathering this information to adopt client and document the experience.Thanks!
ostinru commentedon Sep 4, 2026
Actually, we don't care about
tcp_keepalive. We have upgraded from 0.6.5 to 0.9.8 and from time to time our requests to clickhouse started hanging.I digged in and observed that we have ESTABLISHED tcp connections on java-side and no connection at all on clickhouse side. These connections are hanging for couple days. We are running in a small cloud and have very limited access to networking layers and we don't have clear steps to reproduce.
Currently we are testing workaround with
socket_timeout.chernser commentedon Sep 29, 2026
Good day, @ostinru !
Is
socket_timeoutworkaround works?ostinru commentedon Sep 30, 2026
Our clients said that they have added
&socket_timeout=7200000. And then we observed hangs with clickhouse-java-0.9.8.It seems that
tcp_keepalivefixed in #3092 and fresh release to mavencentral will fix an issue.chernser commentedon Sep 30, 2026
@ostinru
#3092 - is this issue. Did you mean some PR ?
Would you please describe condition when it hangs? Thanks!
ostinru commentedon Oct 1, 2026
Sorry -
tcp_keepaliveenabled in #3079We don't have steps to reproduce. It hangs once in a week during client ETL process: Greenplum -> PXF -> ClickHouse. All parts are running in virtualised environment. Greenplum can consume all available CPU and network resources available for its internal communication.
As workaround we provided to our clients a way to call Thread.interrupt() / Socket.close() on request thread/socket. We are expecting that next clickhouse-jdbc release will fix this issue.
chernser commentedon Oct 1, 2026
@ostinru
Thank you for response!
Yes, I understand about reproducing - no need for that. I just want better understand conditions and if we can do something.
May be a retry, may be special socket timeout handling.
If application that uses java client runs on on the same VM as greenplum? or in the same process? or in the same k8s cluster?
Thanks!