pinpoint-apm/pinpoint · error · IOException

OTLP/HTTP decompressed request body exceeded max size: limit

Error message

OTLP/HTTP decompressed request body exceeded max size: limit=

What it means

OtlpTraceDecompressionFilter wraps the gzip-inflated request body in a counting stream; the add() method throws IOException as soon as the decompressed byte count exceeds the configured limit. This protects the collector from decompression bombs: a small gzipped body can expand far beyond acceptable memory/disk usage.

Source

Thrown at otlptrace/otlptrace-collector/src/main/java/com/navercorp/pinpoint/otlp/trace/collector/controller/OtlpTraceDecompressionFilter.java:197

     * The {@link GZIPInputStream} is constructed eagerly, so a body that is not valid gzip fails here
     * (surfaces to the protobuf converter as a 400). Async reads are not supported (OTLP ingestion is
     * a blocking read through the message converter).
     */
    private static final class GzipLimitedServletInputStream extends ServletInputStream {
        private final GZIPInputStream gzip;
        private final long limit;
        private long count;
        private boolean finished;

        private GzipLimitedServletInputStream(InputStream compressed, long limit) throws IOException {
            this.gzip = new GZIPInputStream(compressed);
            this.limit = limit;
        }

        private void add(int read) throws IOException {
            count += read;
            if (count > limit) {
                throw new IOException("OTLP/HTTP decompressed request body exceeded max size: limit=" + limit);
            }
        }

        @Override
        public int read() throws IOException {
            final int b = gzip.read();
            if (b < 0) {
                finished = true;
                return -1;
            }
            add(1);
            return b;
        }

        @Override
        public int read(byte[] b, int off, int len) throws IOException {
            final int n = gzip.read(b, off, len);
            if (n < 0) {

View on GitHub (pinned to 744c3d3075)

Solutions

Reduce client-side batch/export size (max export batch size, export interval) so each compressed request inflates under the limit.
Raise the collector's decompressed body size limit configuration to accommodate legitimate payloads, keeping DoS protection in mind.
Check for compression configuration mistakes (e.g. double compression or compressing already-large payloads unnecessarily).
Handle HTTP 4xx response on the client and retry with smaller batches rather than resending the identical oversized payload.

Example fix

// before
BatchSpanProcessor.builder().setMaxExportBatchSize(8192).build(); // inflates past limit
// after
BatchSpanProcessor.builder().setMaxExportBatchSize(512).build();

Defensive patterns

Strategy: retry

Validate before calling

int inflatedSize = batchSize * avgSpanBytes;
if (inflatedSize > collectorMaxDecompressedBytes) {
    splitBatch();
}

Type guard

boolean underDecompressionLimit(byte[] gzipped, long limit, double worstCaseRatio) {
    return gzipped.length * worstCaseRatio <= limit;
}

Try / catch

try {
    export(batch);
} catch (HttpException e) {
    if (isDecompressionLimitResponse(e)) {
        for (List<SpanData> half : splitInHalf(batch)) export(half);
    }
}

Prevention

Keep client export batch sizes well under the collector's decompressed limit
Align client max-batch-size config with the server's limit when deploying both
Split large queues into multiple exports instead of one flush
Monitor rejected-request metrics to catch limit regressions early

When it happens

Trigger: Sending a gzip- (or deflate-) compressed OTLP/HTTP trace request whose UNCOMPRESSED size exceeds the collector's configured max decompressed body size; the limit is hit while the counting InputStream's read() pumps bytes.

Common situations: A batch-exporting SDK with a huge in-memory queue flushes an oversized payload; misconfigured compression where a client compresses already-huge batches; decompression-bomb protection tripping on a legitimately large but legitimate batch; lowering the collector limit without adjusting client batch sizes.

Understand the failure class

Background: payload too large / request exceeds maximum size: why libraries cap bytes and how to fix oversize payloads — this error's family across 50 libraries.

Related errors

AI-assisted analysis of pinpoint-apm/pinpoint@744c3d3075 (2026-09-07). Data as JSON: /api/errors/c8843adf58de15b0. Report an issue: GitHub.