What causes "invalid message length: computed %d from BLR but client sent %d" in apache/shardingsphere?

Use a maintained Firebird client library (Jaybird 5+) whose batch BLR and message-length computation match the protocol.

apache/shardingsphere · error · InvalidBatchMessageFormatException

invalid message length: computed %d from BLR but client sent

Error message

invalid message length: computed %d from BLR but client sent %d

What it means

InvalidBatchMessageFormatException thrown when the message length declared in the CREATE BATCH packet differs from the length computed by the proxy from the batch BLR (FirebirdParseBatchBlr.getMessageLength()). The two must agree byte-for-byte because each subsequent batch MESSAGE payload is sliced using this length.

Source

Thrown at proxy/frontend/dialect/firebird/src/main/java/org/apache/shardingsphere/proxy/frontend/firebird/command/query/batch/FirebirdBatchCreateCommandExecutor.java:89

    
    @Override
    public Collection<DatabasePacket> execute() throws SQLException {
        int connectionId = connectionSession.getConnectionId();
        int statementId = packet.getStatementHandle();
        if (null == connectionSession.getServerPreparedStatementRegistry().getPreparedStatement(statementId)) {
            throw new InvalidStatementHandleException(statementId);
        }
        if (null != FirebirdBatchRegistry.getInstance().getBatchStatement(connectionId, statementId)) {
            throw new BatchAlreadyOpenedException(statementId);
        }
        ByteBuf batchBlr = packet.getBatchBlr();
        int blrLength = batchBlr.readableBytes();
        FirebirdParseBatchBlr messageFormat = FirebirdParseBatchBlr.parse(batchBlr, blrLength);
        if (messageFormat.getFields().isEmpty()) {
            throw new BatchParametersRequiredException(statementId);
        }
        if (packet.getBatchMessageLength() != messageFormat.getMessageLength()) {
            throw new InvalidBatchMessageFormatException(
                    String.format("invalid message length: computed %d from BLR but client sent %d", messageFormat.getMessageLength(), packet.getBatchMessageLength()));
        }
        ByteBuf batchParametersBuffer = packet.getBatchParametersBuffer();
        BatchParameters batchParameters = BatchParameters.parse(batchParametersBuffer);
        FirebirdBatchRegistry.getInstance().registerBatchStatement(connectionId, statementId,
                new FirebirdBatchStatement(statementId, messageFormat.getFields(), batchParameters.getBufferSize(), batchParameters.isRecordCounts(), batchParameters.isMultiError()));
        return Collections.singleton(new FirebirdGenericResponsePacket().setHandle(statementId));
    }
    
    @Getter
    @RequiredArgsConstructor
    static final class BatchParameters {
        
        private final int version;
        
        private final long bufferSize;
        
        private final boolean recordCounts;

View on GitHub (pinned to e952770a21)

Solutions

Use a maintained Firebird client library (Jaybird 5+) whose batch BLR and message-length computation match the protocol.
When building BLR manually, derive the message length from the exact same field descriptors used to build the BLR, including null indicators (one bit per field) and alignment padding.
Verify against a real Firebird server with the same statement: if the server accepts it, compare the bytes the client sends to what the proxy's FirebirdParseBatchBlr computed.

Defensive patterns

Strategy: try-catch

Try / catch

catch (SQLException e) {
    if (e.getMessage().contains("invalid message length")) {
        // BLR and declared length disagree: recompute length from the BLR you send, then retry
        throw new IllegalStateException("client BLR/message-length bug", e);
    }
    throw e;
}

Prevention

Never hand-compute batch message length; derive it from the same descriptors used to build the BLR.
Use library-provided batch builders (Jaybird) which keep them consistent.

When it happens

Trigger: packet.getBatchMessageLength() != messageFormat.getMessageLength() after parsing batchBlr; caused by a client computing message length with a different BLR than the one it sends, wrong alignment/short/int type widths in the length calculation, or a corrupted packet.

Common situations: hand-rolled or ported client code that computes message length including/excluding the null indicator bitmap differently than the server; client and proxy disagreeing on Firebird version-specific BLR encoding (e.g. int64 vs int slots); truncation from a buggy packet builder.

Related errors

AI-assisted analysis of apache/shardingsphere@e952770a21 (2026-08-14). Data as JSON: /api/errors/984474f51375e019. Report an issue: GitHub.