TheR1sing3un commented on PR #7732:
URL: https://github.com/apache/paimon/pull/7732#issuecomment-4345045000
> Why can't it be consistent with Java implementation?
Thanks for the review @JingsongLi.
I do want to keep both the bug fix and the new options in this PR. The
reason isn't just convenience — without these as catalog options the client's
actual behaviour is not under our control. requests falls back to the OS /
kernel for
things we can't choose at the application level: TCP connect retries
(net.ipv4.tcp_syn_retries), keep-alive probe cadence, socket-level timeouts,
etc. Today on the Python side self.session.timeout = (180, 180) is dead code
(Session.timeout isn't honoured), so:
- connect/read timeouts are effectively unbounded — a slow or hung server
can wedge the client indefinitely;
- retry behaviour is whatever urllib3/the kernel decide, not what we
promise.
Exposing the five keys (http.connect-timeout / http.read-timeout /
http.max-connect-retries / http.max-read-retries / http.keep-alive) is what
lets us pin those down deterministically per-catalog. The defaults already
match Java's
hardcoded values (180s / 180s / 5 retries / keep-alive on), so
out-of-the-box behaviour stays equivalent — only operators who today have no
knob gain one.
On the Java consistency point: I take that seriously. My plan is, once
this PR lands, to follow up with a dedicated PR that introduces the same option
keys on the Java side (extending RESTCatalogOptions and wiring them through
HttpClientUtils), so the two SDKs converge on the same configuration
surface. That follow-up needs its own Java-side validation (HttpClient5 test
coverage etc.) which I'd rather not bundle into a Python PR.
If that two-step plan works for you, I'll keep this PR as-is. Otherwise
happy to discuss alternatives.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
