[
https://issues.apache.org/jira/browse/FLINK-6295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15972872#comment-15972872
]
ASF GitHub Bot commented on FLINK-6295:
---------------------------------------
Github user zentol commented on the issue:
https://github.com/apache/flink/pull/3709
@WangTaoTheTonic Because *everyone* uses guava which results again and
again in dependency conflicts.
What do you mean with "how long it should be"? We remove the job from the
cache and that's it. If more request for that job come in nothing will be
returned resulting in the response you get when querying for a non-existing
job, which is an accurate representation of the state of the JobManager. If the
same JM recovers the job then it is no longer in a SUSPENDED state and will be
added to the cache again. If another JM picks the job up the web-ui will be
redirected to that JM and everything's fine.
> use LoadingCache instead of WeakHashMap to lower latency
> --------------------------------------------------------
>
> Key: FLINK-6295
> URL: https://issues.apache.org/jira/browse/FLINK-6295
> Project: Flink
> Issue Type: Bug
> Components: Webfrontend
> Reporter: Tao Wang
> Assignee: Tao Wang
>
> Now in ExecutionGraphHolder, which is used in many handlers, we use a
> WeakHashMap to cache ExecutionGraph(s), which is only sensitive to garbage
> collection.
> The latency is too high when JVM do GC rarely, which will make status of jobs
> or its tasks unmatched with the real ones.
> LoadingCache is a common used cache implementation from guava lib, we can use
> its time based eviction to lower latency of status update.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
