[
https://issues.apache.org/jira/browse/FLINK-9884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16548559#comment-16548559
]
ASF GitHub Bot commented on FLINK-9884:
---------------------------------------
Github user tison1 commented on the issue:
https://github.com/apache/flink/pull/6360
@shuai-xu
It makes sense.
The message that TM has successfully allocated slot might lost in transport.
When slot manager receives a slot status report which says one slot has
allocation id irrelevant to this offer, then the slot is allocated to another
slot request.
It looks this PR prevents runtime from some potential resource leak,
doesn't it?
> Slot request may not be removed when it has already be assigned in slot
> manager
> -------------------------------------------------------------------------------
>
> Key: FLINK-9884
> URL: https://issues.apache.org/jira/browse/FLINK-9884
> Project: Flink
> Issue Type: Bug
> Components: Cluster Management
> Reporter: shuai.xu
> Assignee: shuai.xu
> Priority: Major
> Labels: pull-request-available
>
> When task executor report a slotA with allocationId1, it may happen that slot
> manager record slotA is assigned to allocationId2, and the slot request with
> allocationId1 is not assigned. Then slot manager will update itself with
> slotA assigned to allocationId1, by it does not clear the slot request with
> allocationId1.
> For example:
> # There is one free slot in slot manager.
> # Now come two slot request with allocationId1 and allocationId2.
> # The slot is assigned to allocationId1, but the requestSlot call timeout.
> # SlotManager assign the slot to allocationId2 and insert a slot request
> with allocationId1.
> # The second requestSlot call to task executor return SlotOccupiedException.
> # SlotManager update the slot to allocationID1, but the slot request is left.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
