Copilot commented on code in PR #14230:
URL: https://github.com/apache/gravitino/pull/14230#discussion_r4374628313
##########
plugins/k8s-job-executor/src/main/java/org/apache/gravitino/job/k8s/K8sJobExecutor.java:
##########
@@ -129,17 +139,13 @@ void initialize(K8sJobExecutorConfigs configs,
KubernetesClient client) {
this.sparkApplicationCache =
new NamespacedResourceCache<>(
configs.statusCacheTtlMs(),
- namespace ->
- getSparkApplicationClient(namespace)
- .withLabel(
- K8sJobResourceUtils.LABEL_MANAGED_BY,
- K8sJobResourceUtils.MANAGED_BY_GRAVITINO)
- .list()
- .getItems(),
- // Getting the SparkApplication itself couldn't reach the API
server either.
+ this::listSparkApplications,
+ // Getting the SparkApplication itself couldn't reach the API
server either. A listing
+ // that the API server is too slow to answer isn't, it gets the
jobs one by one instead.
e ->
e instanceof KubernetesClientException
- && isUnreachable((KubernetesClientException) e),
+ && isUnreachable((KubernetesClientException) e)
+ && !isResponseTimedOut((KubernetesClientException) e),
Review Comment:
Treating response timeouts as recoverable exposes an expired fallback cache
entry: `NamespacedResourceCache.snapshotOf()` timestamps failures before the
LIST starts, so the default 10-second request timeout exceeds the 5-second
cache TTL. Subsequent jobs in the same namespace therefore repeat the slow LIST
before falling back to GET, delaying the sequential status poll by another
timeout per job. Timestamp the empty failure snapshot when the LIST fails, and
add a regression test that advances the clock during a failing LIST beyond the
cache TTL.
--
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]
