mirror of
https://github.com/facebook/squangle.git
synced 2026-10-22 22:08:56 +03:00
44eae6d72f
Summary: A squangle `PoolKey` decides whether a connection request can reuse an idle pooled connection. This diff makes two keys with the same connection attributes equal whatever order the attribute map iterates in, so such a request reuses the idle connection instead of opening a new one. It does not depend on any other diff. **Problem** A request whose key does not match opens a new connection while an idle one with the same attributes sits in the pool. `PoolKey` hashed the attributes with `folly::hash::hash_range`, which depends on iteration order, and two keys are equal only if those hashes are equal. The attributes have been a `folly::F14NodeMap` since D47197821, and the iteration order of that map is not part of its value: - In a build without `NDEBUG`, F14 puts each insert in a random slot. Two maps filled with the same four attributes in the same order then give different keys about seven times in ten. - In any build, two maps filled with the same attributes in a different order give different keys. **Who sees it** - `DBQueryTest::testConnectionPooling` in www runs one pooled query twice and expects the second to reuse the connection of the first. - It fails on diffs that change HHVM sources under `fbcode/hphp`. Their CI builds HHVM in `@//mode/dbgo`, which has no `NDEBUG`, and runs the `flib/core` www tests against that build in the job `hhvm-flib-test-dbgo`. - That job reported 121 failures of the test on 65 diffs in the two weeks to 2026-10-03. In the 72 hours to 21:36 PDT on 2026-10-03 the job ran the test 59 times without this change: 28 failed, 15 passed only after one or two reruns, and 16 passed with no rerun. D71821697, created in March 2025, called the test "very flaky on changes to HHVM". **What changes when this lands** - A binary built without `NDEBUG` that connects through a pool with two or more attributes reuses pooled connections, as a release build already does. That includes debug and dev-mode tests elsewhere in fbcode that use the pool this way, such as the one in Test Plan step 5. - A release build is unchanged for callers that set the same attributes in the same order. `DBQueryTest` is one: in the same 72 hours it passed with no rerun in all 109 runs of the optimized `hhvm-flib-test` job and all 52 runs of `continuous-hhvm-flib-test`. - On any build, release included, two callers that pass the same attributes in a different order did not share pooled connections before this change, and do after it. HHVM sets them in the order of the array given to `setConnectionAttributes`. **Change** `options_hash_` is now `folly::hash::commutative_hash_combine_range` over the attributes, which does not depend on order. `QueryOptions::hashValue()` in the same library already hashes its attribute map this way. The diff adds `PoolKeyTest`, with five cases, and its BUCK target. **Unchanged** - Two keys are still compared by their hashes and their `ConnectionKey`. The attribute maps themselves are not compared. - The hash values change for keys that have attributes. A key with no attributes keeps an options hash of 0. The hashes are used only as keys of in-memory maps, through `PoolKeyHash` and `PoolKeyPartialHash`. - No knob gates this. Rollback is a revert of this diff. Reviewed By: jkedgar Differential Revision: D123240364 fbshipit-source-id: 02e88be12c1a0a9bbee38b235c2b52a816c47678
SQuangLe
Overview
SQuangLe is a C++ MySQL client library built on top of WebScaleSQL's C client library. It does not require a WebScaleSQL server - WebScaleSQL, MySQL, MariaDB, and Percona Server should all work fine.
Current Status
SQuangLe is not supported as a standalone project; it is released as a dependency of HHVM's async mysql extension to the Hack language.
Features
- Object-oriented API
- Query builder with automatic escaping
- Asynchronous query execution
License
SQuangLe is BSD-licensed. We also provide an additional patent grant. Please see the LICENSE file.
Contributing
Please see CONTRIBUTING.md