zclllyybb commented on issue #65305:
URL: https://github.com/apache/doris/issues/65305#issuecomment-4900867326
Breakwater-GitHub-Analysis-Slot: slot_c465cd8651c6
This content is generated by AI for reference only.
Initial code-level triage: this should be treated as a likely FE-side Arrow
Flight SQL direct-memory leak, not as a client-only connection leak.
I checked the FE Arrow Flight SQL path in the 4.1.2 line and current
upstream/master. The suspicious code shape still exists:
- `DorisFlightSqlProducer#createPreparedStatement` creates a dummy result
metadata schema via
`connectContext.getFlightSqlChannel().createOneOneSchemaRoot("ResultMeta",
"UNIMPLEMENTED").getSchema()`.
- `FlightSqlChannel#createOneOneSchemaRoot` allocates a `VarCharVector`
using the channel `RootAllocator`.
- That temporary `VectorSchemaRoot` is not closed in
`createPreparedStatement`; only its `Schema` is extracted. Repeated prepare
calls therefore allocate Arrow/Netty direct buffers that are not explicitly
released.
- `closePreparedStatement` only removes the stored SQL text from the session
map. It cannot release the dummy metadata root because that root was never
stored.
- `FlightSqlChannel#close()` only invalidates the result cache; it does not
close the channel `RootAllocator`.
- `FlightSqlConnectPoolMgr#unregisterConnection` removes the context from
maps but does not close the Flight SQL channel/allocator. This matches the
report that rebuilding or closing client sessions does not necessarily bring FE
direct memory back down.
So the report is consistent with a real resource-lifecycle bug in the FE
Flight SQL prepare/session path. The `io.netty.buffer.PoolSubpage` growth is
also consistent with unclosed Arrow vectors backed by Netty pooled direct
buffers.
One nuance for maintainers: in the checked code, `createPreparedStatement`
itself does not analyze the SQL or check table existence; it mostly stores the
query and returns placeholder metadata. A `Table does not exist` audit error
should come from the later prepared statement query/getFlightInfo execution
path, even if the ADBC client surfaces it as `Prepare`. Please capture the
exact Flight SQL RPC sequence if possible.
Suggested next steps:
1. Fix `createPreparedStatement` so temporary metadata vectors are closed,
or better, build the placeholder `Schema` directly without allocating a
`VectorSchemaRoot`.
2. On any prepare failure after the prepared statement id is registered,
remove the prepared query from the session map before returning the error.
3. Make Flight SQL session cleanup close both cached results and the
`FlightSqlChannel` allocator; unregistering/closing a Flight SQL context should
not only remove it from connection/token maps.
4. Add a stress/regression test that repeatedly prepares and closes distinct
Flight SQL statements, including invalid SQL, and checks that the FE Arrow
allocator/direct memory returns to a bounded level.
Helpful missing data for confirming the production instance:
- Exact `select version();` output.
- Healthy-FE `jcmd <pid> GC.class_histogram` numbers for
`io.netty.buffer.PoolSubpage`.
- FE logs around `createPreparedStatement`,
`getFlightInfoPreparedStatement`, `closePreparedStatement`, and `closeSession`
for one failing client session.
- Whether the client actually sends `closePreparedStatement` and/or
`closeSession` on the error path.
- A minimal Python ADBC script that reproduces the monotonic FE
direct-memory growth.
I do not see evidence from the current upstream/master code that this exact
FE prepare/direct-memory lifecycle issue is already fixed.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
