bhaskars2904 commented on issue #39772: URL: https://github.com/apache/shardingsphere/issues/39772#issuecomment-5866936595
@makssent thank you for providing the links to the Firebird docs and code. I have following analysis for the issue: **Firebird protocol**: The firebird protocol states that an op_put_segment or a op_batch_segment are commands that are used to upload the blob data broken into segments by the client. The bytes reserved for the total length of the segment is 2byte (Firebird 3.0 and higher). This implies that the maximum size of the buffer is 2^16-1 i.e. 65535 bytes (64 KB). This is the only limit and it applies to one segment. If the file is larger then there are multiple segments used where the op_batch_segment command provides better performance than op_put_segment command. **Sharding Sphere proxy**: The FirebirdPutBlobSegmentCommandExecutor and FirebirdBatchBlobSegmentsCommandExecutor simply appends the segments into the FirebirdBlobWriteCache in-memory buffer without writing them to the Firebird server. This is a completely different mechanism where the segments are held in-memory before writing them to the server. Hence the Firebird wire protocol can't be used as a reference for imposing the limits on the in-memory buffer. **Conclusion** : This leaves us with 2 choices - 1) To impose a limit on the in-memory buffer which is dictated by Sharding Sphere (a not so good idea imo) or 2) To not buffer the segments in-memory but write them to the server on the execution of every command the way its being done by the Firebird client and server. @makssent please review and provide your suggestions on the approach that is right to be taken here. -- 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]
