amahussein commented on a change in pull request #161:
URL: https://github.com/apache/tez/pull/161#discussion_r750410092
##########
File path: tez-api/src/main/java/org/apache/tez/dag/api/TezConfiguration.java
##########
@@ -1975,6 +1975,18 @@ public static void validateProperty(String property,
Scope usedScope) {
TEZ_PREFIX + "test.minicluster.app.wait.on.shutdown.secs";
public static final long
TEZ_TEST_MINI_CLUSTER_APP_WAIT_ON_SHUTDOWN_SECS_DEFAULT = 30;
+ /**
+ * Long value
+ * Status Cache timeout window in minutes for the DAGClient.
+ */
+ @Private
+ @ConfigurationScope(Scope.CLIENT)
+ @ConfigurationProperty(type="long")
+ public static final String TEZ_CLIENT_DAG_STATUS_CACHE_TIMEOUT_MINUTES =
TEZ_PREFIX
+ + "client.dag.status.cache.timeout-minutes";
+ // Default timeout is 5 minutes.
+ public static final long TEZ_CLIENT_DAG_STATUS_CACHE_TIMEOUT_MINUTES_DEFAULT
= 5;
Review comment:
I am fine with seconds. However, I am not so sure about the impact of
setting the expiration to a small value.
For example, it is possible to have some delay in the AM executing the RPC
call (or even a timeout at one time). If the expiration of the cache is smaller
than the total of ("AM RPC with failure" + "wait for the client to retry" + "AM
RPC"), then the cache won't serve its purpose.
If I understand correctly, `cachedDAGStatus` purpose is to protect the
client from falling too soon to the RM. Correct me if I misunderstand the
purpose of the `cachedDAGStatus`.
--
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: issues-unsubscr...@tez.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
