[
https://issues.apache.org/jira/browse/FLINK-8501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16337402#comment-16337402
]
ASF GitHub Bot commented on FLINK-8501:
---------------------------------------
GitHub user tillrohrmann opened a pull request:
https://github.com/apache/flink/pull/5350
[FLINK-8501] [flip6] Use single BlobCacheService per TaskExecutor
## What is the purpose of the change
Instead of creating for each new JobManagerConnection a dedicated
BlobCacheService
the TaskExecutor uses a single BlobCacheService which it shares between the
different JobManagerConnections. The initial BlobServer address is passed
by the
ResourceManager when the TaskExecutor registers at it. In order to avoid
the re-
creation of BlobCacheServices, this commit changes the behaviour such that
one can
update the BlobServer address.
## Brief change log
- Introducing `ClusterInformation` which contains the cluster specific
information (e.g. `BlobServer` address and port)
- Sending `ClusterInformation` when `TaskExecutor` register at the
`ResourceManager`
- Allow to reconfigure `BlobServer` address in `BlobCacheService` to make
it reusable across failovers
- Remove `BlobCacheService` from `JobManagerConnection`
## Verifying this change
- Covered by existing tests
## Does this pull request potentially affect one of the following parts:
- Dependencies (does it add or upgrade a dependency): (no)
- The public API, i.e., is any changed class annotated with
`@Public(Evolving)`: (no)
- The serializers: (no)
- The runtime per-record code paths (performance sensitive): (no)
- Anything that affects deployment or recovery: JobManager (and its
components), Checkpointing, Yarn/Mesos, ZooKeeper: (yes)
- The S3 file system connector: (no)
## Documentation
- Does this pull request introduce a new feature? (no)
- If yes, how is the feature documented? (not applicable)
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/tillrohrmann/flink
taskExecutorBlobCacheService
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/flink/pull/5350.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #5350
----
commit b9db2ab22c346ec64363b446ed23692af1365239
Author: Till Rohrmann <trohrmann@...>
Date: 2018-01-23T18:12:27Z
[FLINK-8501] [flip6] Use single BlobCacheService per TaskExecutor
Instead of creating for each new JobManagerConnection a dedicated
BlobCacheService
the TaskExecutor uses a single BlobCacheService which it shares between the
different JobManagerConnections. The initial BlobServer address is passed
by the
ResourceManager when the TaskExecutor registers at it. In order to avoid
the re-
creation of BlobCacheServices, this commit changes the behaviour such that
one can
update the BlobServer address.
----
> Use single BlobCacheService per TaskExecutor
> --------------------------------------------
>
> Key: FLINK-8501
> URL: https://issues.apache.org/jira/browse/FLINK-8501
> Project: Flink
> Issue Type: Improvement
> Components: Distributed Coordination
> Affects Versions: 1.5.0
> Reporter: Till Rohrmann
> Assignee: Till Rohrmann
> Priority: Major
> Labels: flip-6
> Fix For: 1.5.0
>
>
> Currently, the {{TaskExecutor}} creates a new {{BlobCacheService}} for each
> new {{JobManagerConnection}}. This is wasteful and, moreover, gives only
> access to the {{BlobService}} after a connection to a {{JobMaster}} has been
> established. Due to this, it is not possible to upload the {{TaskExecutor}}
> logs before a {{TaskExecutor}} is used by a {{JobMaster}}.
>
> Since the {{BlobServer}} address is something cluster specific and not
> {{JobMaster}} specific, I propose to propagate this information when the
> {{TaskExecutor}} registers at the {{ResourceManager}}. Moreover, I propose to
> make the {{BlobCacheService}} reusable in case of a {{BlobServer}} address
> change (e.g. failover) by allowing to change the {{BlobServer}} address.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
