CritasWang opened a new pull request, #11:
URL: https://github.com/apache/iotdb-client-rust/pull/11

   ## Summary
   
   One combined PR for the session-pool / connection-lifecycle / redirect 
review findings, split into
   issues #4–#10 for tracking. The root cause (#4) is fixed by a new 
socket-level I/O timeout, and the
   other fixes are the follow-on work each issue describes.
   
   ## What changed
   
   - **#4 — client-side time bound after the TCP handshake.** New 
`socket_timeout` on
     `ConnectionOptions`/`SessionConfig` (`Some(60s)` by default, `None` 
restores the old
     behaviour, zero treated as `None`). It is applied via `socket2` right 
after connect and
     **before** the TLS handshake, so the TLS handshake, every RPC read, and 
the best-effort
     `closeSession` on `Drop` are all bounded. `SO_KEEPALIVE` is now enabled on 
the socket.
     Wedged reads surface as `Error::Thrift`, so `with_retry`/reconnect 
actually engages.
   - **#5 — handshake-level failover in `Session::open`.** The endpoint loop 
now retries
     connect + `openSession` + `requestStatementId` together, mirroring 
`reconnect()`.
   - **#6 — pool accounting.** `acquire()` spends its `acquire_timeout` budget 
on growth /
     hand-out failures instead of failing instantly; `live` is now decremented 
under the state lock
     (no lost Condvar wakeups); `close()` wakes waiters before the blocking 
`closeSession` calls;
     `acquire_timeout = Duration::MAX` means "wait without a deadline" via 
`checked_add`.
   - **#7 — per-endpoint connect budget.** `connect_stream` shares one total 
`connect_timeout`
     across every resolved address of an endpoint.
   - **#8 — desynchronized connections.** A transport-level failure (including 
frame-too-large
     rejection and socket timeouts, and `fetch_results` which cannot be 
retried) marks the
     connection broken; `is_open()` then reports false and pools discard the 
session. Note: the
     16,384,000-byte frame cap itself cannot be raised without a thrift 0.23 
API change
     (`TFramedReadTransport` exposes no config setter), so this PR fixes the 
desync/reuse half.
   - **#9 — redirect/pool refinements.** Endpoint matching now normalizes 
case/brackets/whitespace
     and treats loopback spellings as equivalent (general hostname-vs-IP DNS 
resolution is deliberately
     not done on the acquire path); the newest hint wins when idle sessions 
hold conflicting hints
     (the cache insertion seq is now process-wide); `SessionConfig` gains
     `redirect_cache_ttl` / `redirect_cache_max_entries`; 
`TableSessionPool::acquire_for_device`
     is exposed.
   - **#10 — reconnect slot hold.** Pooled sessions skip the between-attempt 
pacing sleeps during
     reconnect, so a pool slot is no longer held for the full C#-style 
reconnect walk.
   
   ## Tests
   
   New regression tests use fake/silent listeners:
   
   - `connection::tests::socket_timeout_bounds_reads_after_handshake`
   - `connection::tls_tests::tls_handshake_times_out_against_silent_peer`
   - 
`session::tests::open_fails_over_to_next_endpoint_when_authentication_fails` 
(live-server gated)
   - `no_reconnect_when_disabled` now asserts the broken-session behaviour
   - `pool::tests::growth_failure_spends_acquire_timeout_budget`,
     `close_wakes_waiters_promptly`, 
`acquire_timeout_max_waits_until_closed_without_panicking`,
     `acquire_for_device_prefers_newest_conflicting_hint`
   - `connection::tests::endpoint_equivalent_normalizes_and_matches_loopback`
   
   Verified locally: `cargo fmt --check`, `./tools/check-license.sh`,
   `cargo clippy --all-targets -- -D warnings` (default and `--features tls`),
   `cargo test` 120 passed, `cargo test --features tls` 132 passed
   (live-server tests ran against a local IoTDB instance).
   
   Closes #4, closes #5, closes #6, closes #7, closes #8, closes #9, closes #10.
   


-- 
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]

Reply via email to