Two fixes to the Java MemWAL LSM surface, both reproduced against the
scripted test server before being fixed.
Transport retries. `HttpClients.createDefault()` installs Apache's default
response retry strategy, whose retryable-status list is exactly 429 and 503
— the two statuses `LanceDbTableLsm.isRetryable` owns. Every explicit retry
budget in `checkpointLsm` was therefore doubled on the wire (a 429 held
against flush issued 18 requests, not 9), and `compactLsm` was retried in
place despite the loop being built to fall through to a fresh stats poll.
Automatic retries are now disabled, so the checkpoint loop is the sole owner
of the 421/429/503 transitions.
Stats decoding. `getLsmStats` read the response with Jackson's `path()`,
which yields a missing node that iterates as an empty array. That made
"malformed" indistinguishable from "no buckets", which is indistinguishable
from "drained" — so an empty response body, a `{"lsm_stats": {}}`, or a
bucket missing its required fields all made `checkpointLsm()` report
convergence for a checkpoint that never ran.
Stats now decode into `LsmStats`, `BucketStats`, `GenerationStats` and
`MemtableStats`, mirroring the Rust structs in
`rust/lancedb/src/table/lsm_stats.rs` and the objects the Node binding
already exposes. Decoding is strict and fails closed, matching the serde
contract on the Rust side: absent or null `lsm_stats` means the LSM write
path is off, and anything else present must decode into the full
bucket/generation shape. `newestGeneration` and `outstandingGenerations`
move onto `BucketStats`, matching Rust's `impl BucketStats`.
This changes `getLsmStats` from `Optional<JsonNode>` to `Optional<LsmStats>`,
which also brings Java to the typed surface Node already had rather than
handing back a raw JSON blob.
Testing: 33 passing in lancedb-core, up from 29. The new tests pin the wire
request count against the retry budget and reject five malformed stats
payloads. `testCheckpointRetriesRetryableStatusInPlace` previously passed on
a transport-absorbed 429 and now exercises the real retry path.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Four of the eight LSM methods are remote-only in the core: `impl BaseTable
for NativeTable` implements only set/unset/get_lsm_write_spec and
close_lsm_writers, while flush_lsm, compact_lsm and get_lsm_stats fall
through to trait defaults returning NotSupported. That is why Node had
bound the four that work locally and stopped, and why the remaining four
had no binding-level coverage anywhere.
Node: add napi bindings for flush_lsm, compact_lsm, checkpoint_lsm and
get_lsm_stats, with typed LsmStats/BucketStats/GenerationStats/
MemtableStats objects mirroring the existing LsmWriteSpec object in the
same file. Tests assert each binding reaches the core and surfaces
NotSupported locally; behavior against a real endpoint stays covered by
the mocked-endpoint tests in rust/lancedb/src/remote/table.rs.
Python: LsmWriteSpec was importable only from the private lancedb._lancedb
-- it appeared in table.py solely under `if TYPE_CHECKING:`. Export it as
lancedb.LsmWriteSpec, add it to __all__, and list it in the API reference,
which had no mention of it and so rendered it nowhere.
Java: add the LSM routes to lancedb-core. Java reaches LanceDB purely over
REST through the generated namespace client, and these routes are not in
the Lance Namespace spec, so they are issued through a small dedicated
client. LsmWriteSpec is deliberately not org.lance.memwal.
InitializeMemWalParams: that type defaults to maintaining no indexes where
a spec here defaults to maintaining every index, and it cannot express the
null that asks the server to resolve the set. checkpointLsm is ported from
rust/lancedb/src/table/checkpoint.rs with its constants and status
semantics intact -- 429/503 retried in place, 421 restarting from flush.
Note: `mvnw spotless:apply` cannot run on JDK 21 (google-java-format 1.7,
pinned in java/pom.xml, predates JDK 16's compiler API change). This is
pre-existing and reproduces on a pristine main checkout; the Java sources
here were formatted by hand to the checkstyle rules.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
In #2845 we ported the lancedb integration in lance-namespace to
lancedb. But that is too specific to RestNamespace. We can improve the
user entry point so that we can put local mode and future version of the
Flight SQL-based LanceDB server all behind this single
`LanceDbNamespaceClientBuilder` API.
Also I renamed `namespace` to `namesapceClient` to avoid confusion with
the namespace path.
After the refactoring on both client and server side, we should have the
ability to fully use lance REST namespace to call into LanceDB cloud and
enterprise. We can avoid having a JNI implementation (which today does
not really do anything except for vending a connection object), and just
use lance-core's RestNamespace.
We will at this moment have a LanceDbRestNamespaceBuilder to allow users
to more easily build the RestNamespace to talk to LanceDB Cloud or
Enterprise endpoint.
In the future, we could extend this further to also support the local
mode through DirectoryNamespace. That will be a separated PR.
Daniel Rammer
Xuanwo
Jack Ye