[
https://issues.apache.org/jira/browse/FLINK-39711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Savonin updated FLINK-39711:
--------------------------------------
Description:
Problem:
The REST endpoint {{GET /jobs/:jobid/exceptions}} accepts an optional
{{maxExceptions}} query parameter that bounds the size of the response, but
Java clients of Flink's typed REST API cannot set it.
As a result, downstream Java clients (for example
{{{}apache/flink-kubernetes-operator{}}}) fetch the *full* existing job
exception history on every observation tick. For long-running jobs with large
exception histories this is wasteful in terms of network bytes, JobManager-side
serialization, and operator JVM memory.
was:
Problem:
The REST endpoint \{{GET /jobs/:jobid/exceptions}} accepts an optional
\{{maxExceptions}} query parameter that bounds the size of the response, but
Java clients of Flink's typed REST API cannot set it.
As a result, downstream Java clients (for example
\{{apache/flink-kubernetes-operator}}) fetch the *full* existing job exception
history on every observation tick. For long-running jobs with large exception
histories this is wasteful in terms of network bytes, JobManager-side
serialization, and operator JVM memory.
Same gap exists for ApplicationExceptionsMessageParameters.
> Allow setting maxExceptions on JobExceptionsMessageParameters
> -------------------------------------------------------------
>
> Key: FLINK-39711
> URL: https://issues.apache.org/jira/browse/FLINK-39711
> Project: Flink
> Issue Type: Improvement
> Components: Runtime / REST
> Reporter: Aleksandr Savonin
> Priority: Minor
> Labels: pull-request-available
>
> Problem:
> The REST endpoint {{GET /jobs/:jobid/exceptions}} accepts an optional
> {{maxExceptions}} query parameter that bounds the size of the response, but
> Java clients of Flink's typed REST API cannot set it.
> As a result, downstream Java clients (for example
> {{{}apache/flink-kubernetes-operator{}}}) fetch the *full* existing job
> exception history on every observation tick. For long-running jobs with large
> exception histories this is wasteful in terms of network bytes,
> JobManager-side serialization, and operator JVM memory.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
