Nikita-Shupletsov commented on code in PR #23452:
URL: https://github.com/apache/kafka/pull/23452#discussion_r4319978910
##########
clients/src/main/java/org/apache/kafka/common/telemetry/internals/ClientTelemetryReporter.java:
##########
@@ -746,6 +750,26 @@ private Optional<Builder<?>>
createPushRequest(ClientTelemetrySubscription local
compressionType = CompressionType.NONE;
}
+ /*
+ Per KIP-714, the payload must not exceed the maximum size the
broker advertised in the
+ subscription. Sending it anyway would only be rejected with
TELEMETRY_TOO_LARGE, hence
+ skip the push and re-fetch the subscription, which may narrow the
requested metrics or
+ raise the limit, before attempting the next push.
+ */
+ if (compressedPayload.remaining() >
localSubscription.telemetryMaxBytes()) {
+ log.warn("Skipping telemetry push as the {} compressed payload
for {} metrics is {} bytes,"
+ + " which exceeds the maximum of {} bytes accepted by
the broker", compressionType,
+ metricsCount, compressedPayload.remaining(),
localSubscription.telemetryMaxBytes());
Review Comment:
if we split metrics across intervals, we will never be able to keep up and
will keep sending stale data.
I think a better approach would be to split deterministically and send only
one part. as the broker accepts only one request per window as of now.
This way we will be able to keep sending metrics(even though all of them),
and everything that we send will be up to date, nothing stale.
--
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]
