rishi-rana opened a new issue, #39772: URL: https://github.com/apache/shardingsphere/issues/39772
Split off from #39052 at makssent's suggestion (https://github.com/apache/shardingsphere/issues/39052#issuecomment-5581713843), since this needs a program-logic change rather than just wiring an existing signal to an error response. ## Bug Report ### Expected behavior Once a client-uploaded BLOB (via op_put_segment / op_batch_segments) exceeds some maximum buffered size, further segments for that BLOB should keep failing with isc_blobtoobig instead of being silently accepted. ### Actual behavior `FirebirdBlobWrite` buffers an in-flight BLOB write into an unbounded `ByteArrayOutputStream` (`proxy/frontend/dialect/firebird/.../command/query/blob/cache/FirebirdBlobWrite.java`). There is no size tracking or limit anywhere in the BLOB write path, so a client can buffer an arbitrarily large BLOB into proxy heap memory before it is ever routed to a backend. ### Why this needs its own issue Unlike the other four sub-cases in #39052, this one isn't "surface an error the cache layer already detects" — no such signal exists yet. It needs: - A decision on where the limit comes from (a hardcoded constant vs. a configurable proxy property), since Firebird itself has no fixed protocol-level BLOB size ceiling — this would be a ShardingSphere-proxy-specific safety guard against unbounded heap buffering. - Once decided, tracking buffered size against that limit in `FirebirdBlobWrite`/`FirebirdBlobWriteCache`, and returning isc_blobtoobig (already scaffolded via the #38927 error-handling pattern) from `FirebirdPutBlobSegmentCommandExecutor`/`FirebirdBatchBlobSegmentsCommandExecutor` once exceeded, with segments received after the limit continuing to fail rather than being accepted again. ### Related - #39052 (parent issue, now scoped to the other 4 sub-cases) - #38927 (established the Firebird dialect error-handling pattern this would extend) -- 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]
