Zhengcy05 commented on PR #39081: URL: https://github.com/apache/shardingsphere/pull/39081#issuecomment-4976171969
Thank you very much for this detailed report — both bugs have been reproduced on my end and have now been fixed. **1. Unresolved delay handle '0xFFFF'** Root cause: Both 'FirebirdCreateBlobCommandExecutor' and 'FirebirdOpenBlobCommandExecutor' generate a new handle and return immediately, but neither records the handle for subsequent operations. When Jaybird uses '0xFFFF' to pipeline before the response returns, all subsequent executors (put-segment, get-segment, seek, close, cancel) directly look for '0xFFFF' and get an empty value—causing silent drops (data) during writing and deadlocks when reading. Fix: 'FirebirdBlobRegistry' now tracks the last created/opened blob handle by connection. 'create_blob2' and 'open_blob2' are both recorded using 'setLastBlobHandle()'. All five subsequent executors now call 'resolveBlobHandle()' before each registry/cache lookup, and when the client sends '0xFFFF', it returns the last handle—which matches how a real Firebird server replaces the recently created object handle. **2. Incorrect fill length in the 'op_get_segment' response** Root cause: 'FirebirdGetBlobSegmentResponsePacket.write()' adds its own internal 4-byte alignment padding after a 2-byte prefix. Because 'FirebirdGenericResponsePacket' encapsulates response data with its XDR length prefix, the internal padding is included in that length. For a 21-byte fragment: declared length = 2 + 21 + 3 (padded) = 26, so Jaybird reads the 21-byte data and interprets the 3 padding bytes as the prefix -> for the next 2-byte fragment length, causing buffer overrun. Fix: Removed internal padding from 'FirebirdGetBlobSegmentResponsePacket.write()'. The generic response encapsulation has applied the correct external alignment via '(4 - length) & 3', which lies outside the declared data length, which is exactly what the protocol requires. Now, both fixes include dedicated unit tests, such as the 'assertExecuteWithDeferredHandle' test, which verifies '0xFFFF' parsing on all five subsequent executors, as well as updated response packet tests for misaligned fragments. If you wish to coordinate BLOB testing between these two PRs, I am happy to help. -- 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]
