You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2018/07/23 08:03:00 UTC
[jira] [Commented] (FLINK-9917) Remove superfluous lock from
SlotSharingManager
[ https://issues.apache.org/jira/browse/FLINK-9917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16552457#comment-16552457 ]
ASF GitHub Bot commented on FLINK-9917:
---------------------------------------
GitHub user tillrohrmann opened a pull request:
https://github.com/apache/flink/pull/6389
[FLINK-9917][JM] Remove superfluous lock from SlotSharingManager
## What is the purpose of the change
The SlotSharingManager is designed to be used by a single thread. Therefore,
it is the responsibility of the caller to make sure that there is only a single
thread at any given time accesssing this component. Consequently, the component
does not need to be synchronized.
This PR is based on #6386.
## Brief change log
- Remove the `lock` and the synchronized blocks from `SlotSharingManager`
- Harden `MultiTaskSlot#release`
## Verifying this change
- Trivial change which is guarded 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 hardenSlotSharingManager
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/flink/pull/6389.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 #6389
----
commit 4f76e9b70aa7b51d686cdb8cab6badc7b26006d0
Author: Till Rohrmann <tr...@...>
Date: 2018-07-19T11:07:44Z
[FLINK-9838][logging] Don't log slot request failures on the ResourceManager
commit dcd5b80fb894dae708234b05b56fc3aef39b76ca
Author: Till Rohrmann <tr...@...>
Date: 2018-07-19T11:41:03Z
[hotfix] Improve logging of SlotPool and SlotSharingManager
commit 4c6fcf42c41b77444af8ad83d2c69b3504e9a755
Author: Till Rohrmann <tr...@...>
Date: 2018-07-22T18:05:05Z
[FLINK-9908][scheduling] Do not cancel individual scheduling future
Since the individual scheduling futures contain logic to release the slot if it cannot
be assigned to the Execution, we must not cancel them. Otherwise we might risk that
slots are not returned to the SlotPool leaving it in an inconsistent state.
commit a4e674a38a4577d6c58f01af2579b654b346ee30
Author: Till Rohrmann <tr...@...>
Date: 2018-07-22T18:17:11Z
[FLINK-9909][core] ConjunctFuture does not cancel input futures
If a ConjunctFuture is cancelled, then it won't cancel all of its input
futures automatically. If the users needs this behaviour then he has to
implement it explicitly. The reason for this change is that an implicit
cancellation can have unwanted side effects, because all of the cancelled
input futures' producers won't be executed.
commit c8e9e691a71b678e4b0b77c7af1a1c7cb5e57ed4
Author: Till Rohrmann <tr...@...>
Date: 2018-07-22T18:20:53Z
[hotfix] Fix checkstyle violations in FutureUtils
commit f07eb87a029a5ba685520ea9f533a0a6732926a4
Author: Till Rohrmann <tr...@...>
Date: 2018-07-22T18:34:33Z
[hotfix] Replace check state condition in Execution#tryAssignResource with if check
Instead of risking an IllegalStateException it is better to check that the
taskManagerLocationFuture has not been completed yet. If, then we also reject
the assignment of the LogicalSlot to the Execution. That way, we don't risk
that we don't release the slot in case of an exception in
Execution#allocateAndAssignSlotForExecution.
commit e7f7c930bc82fa3414594901323c06b4e4d749d2
Author: Till Rohrmann <tr...@...>
Date: 2018-07-22T18:43:44Z
[hotfix] Fix checkstyle violations in ExecutionVertex
commit fa5593a26079f7e1f46dcb84380747852bac451d
Author: Till Rohrmann <tr...@...>
Date: 2018-07-22T18:46:37Z
[hotfix] Fix checkstyle violations in ExecutionJobVertex
commit bc628da8d58a2828730900ce2bd2363bb24efbbb
Author: Till Rohrmann <tr...@...>
Date: 2018-07-22T18:48:53Z
[hotfix] Fix checkstyle violations in Execution
commit 15b6a6078affbe0e2a4087b3e9fed7a40579bd74
Author: Till Rohrmann <tr...@...>
Date: 2018-07-22T19:38:42Z
[FLINK-9910][scheduling] Execution#scheduleForeExecution does not cancel slot future
In order to properly give back an allocated slot to the SlotPool, one must not complete
the result future of Execution#allocateAndAssignSlotForExecution. This commit changes the
behaviour in Execution#scheduleForExecution accordingly.
commit d7852ea67f7ac596c4f87030f18399bcef4775c3
Author: Till Rohrmann <tr...@...>
Date: 2018-07-22T19:57:59Z
[FLINK-9911][JM] Use SlotPoolGateway to call failAllocation
Since the SlotPool is an actor, we must use the SlotPoolGateway to interact with
the SlotPool. Otherwise, we might risk an inconsistent state since there are
multiple threads modifying the component.
commit 1c588e7c90066f009c1919da25b0c8ec7d58c2d1
Author: Till Rohrmann <tr...@...>
Date: 2018-07-22T20:11:13Z
[FLINK-9917][JM] Remove superfluous lock from SlotSharingManager
The SlotSharingManager is designed to be used by a single thread. Therefore,
it is the responsibility of the caller to make sure that there is only a single
thread at any given time accesssing this component. Consequently, the component
does not need to be synchronized.
----
> Remove superfluous lock from SlotSharingManager
> -----------------------------------------------
>
> Key: FLINK-9917
> URL: https://issues.apache.org/jira/browse/FLINK-9917
> Project: Flink
> Issue Type: Improvement
> Components: JobManager
> Affects Versions: 1.6.0
> Reporter: Till Rohrmann
> Assignee: Till Rohrmann
> Priority: Major
> Labels: pull-request-available
>
> The {{SlotSharingManager}} uses a lock to synchronize access to some of its fields. Since the component is designed to be used only in a single threaded context, the lock are superfluous and confusing. Therefore, I propose to remove it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)