...
Proposed Changes
Interfaces & Methods
draw.io Diagram border true diagramName CompletedJobStore simpleViewer false width links auto tbstyle top lbox true diagramWidth 1246 revision 3
|
| Calling Code Location | Migration Plan |
| not used | Can be removed. | |
|
Dispatcher#cancel
¹
The graph’s |
Dispatcher#requestExecutionGraphInfo
¹
It can be replaced by the CompletedJobStore
to retrieve the ExecutionGraphInfo
Dispatcher#requestJobResult
¹
JobResult
². | Access |
| The method can use |
| The method can use |
|
|
| Both methods are called from within the |
JobResultEntry
is also just derived from AccessExecutionGraph
². Both methods can be merged into a single one to create the entry with the relevant information.Merging of the two methods into | ||
|
|
JobResultStore
folder to persist the informationThe data is available through the | ||
|
|
JobDetails
²Moves into JobDetailsStore. | ||
|
|
Return type JobDetails
²
Moves into JobDetailsStore. | |
|
|
| At the end of the cleanup process within the |
Can be kept as is
| |
|
|
|
Can be kept as is
| |
|
| At the end of the cleanup process within the |
Can be kept as is
| |
|
| At the end of the cleanup process within the |
| ||
| Before instantiating the |
|
¹ if no JobManagerRunner
is registered for the given JobID
anymore
² can be derived from ArchivedExecutionGraph
Summary of the changes:
ExecutionInfoStore
will be renamed intoCompletedJobStore
to reflect the new purpose- Optional: The
ExecutionGraphInfoStore
methods will be made asynchronous (analogously to what is/was done for theJobResultStore
in FLINK-27204) - All methods from the
JobResultStore
will be integrated into new interfaceCompletedJobStore
ExecutionGraphInfoStore#size()
will be removed: This method is not used anywhere.JobResultStore#getDirtyResults()
is moved into its own interfaceCompletedJobStoreWithDirtyJobRetrieval
(that’s the only method which is used outside of theDispatcher
). It derives fromCompletedJobStore
.
- CompletedJobStore: Takes care of the failover scenario and stores the actual data. The data might live in-memory all the time. A file-based and an in-memory implementation will be provided.
- JobDetailsStore: Takes care of the job details which live in memory. The store will also take care of triggering the final deletion of the CompletedJobStore entry if a TTL is set. The file-based CompletedJobStore will provide a in-memory version of the JobDetailsStore (i.e. the JobDetails will be created along the ExecutionGraphInfo and will live in memory as long as the CompletedJobStore entry isn't removed). In contrast, the in-memory CompletedJobStore will come with a JobDetailsStore implementation that accesses the in-memory ExecutionGraphInfo and creates the JobDetails on the fly.
The sequence diagram below visualizes the process of creating and removing the entries.
draw.io Diagram | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
CompletedJobStoreWithDirtyJobRetrieval
but only CompletedJobStore
is going to be passed on into the Dispatcher
.Serialization
The ExecutionGraphInfoStore
utilizes Java’s object serialization. It dumps the ExecutionGraphInfo
(which includes the ArchivedExecutionGraph
and the exception history) into a file. In contrast, the JobResultEntry
is currently serialized as JSON containing the JobResult
and a version (i.e. the version of the schema). The JobResult
is used in the cleanup process to generate a sparse ArchivedExecutionGraph
to serve to the REST API while cleaning up after failover. The version was added to allow changes to the format.
...