[
https://issues.apache.org/jira/browse/SPARK-21955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16158402#comment-16158402
]
Sean Owen commented on SPARK-21955:
-----------------------------------
You might be on to something, but this is poorly described. Can you revise the
description, attach the image, and specify the change you are suggesting?
> OneForOneStreamManager may leak memory when network is poor
> -----------------------------------------------------------
>
> Key: SPARK-21955
> URL: https://issues.apache.org/jira/browse/SPARK-21955
> Project: Spark
> Issue Type: Bug
> Components: Block Manager
> Affects Versions: 1.6.1
> Environment: hdp 2.4.2.0-258
> spark 1.6
> Reporter: poseidon
>
> just in my way to know how stream , chunk , block works in netty found some
> nasty case.
> process OpenBlocks message registerStream Stream in OneForOneStreamManager
> org.apache.spark.network.server.OneForOneStreamManager#registerStream
> fill with streamState with app & buber
> process ChunkFetchRequest registerChannel
> org.apache.spark.network.server.OneForOneStreamManager#registerChannel
> fill with streamState with channel
> In
> org.apache.spark.network.shuffle.OneForOneBlockFetcher#start
> OpenBlocks -> ChunkFetchRequest come in sequnce.
> If network down in OpenBlocks process, no more ChunkFetchRequest message
> then.
> So, we can see some leaked Buffer in OneForOneStreamManager
> !attachment-name.jpg|thumbnail!
> if
> org.apache.spark.network.server.OneForOneStreamManager.StreamState#associatedChannel
> is not set, then after search the code , it will remain in memory forever.
> Because the only way to release it was in channel close , or someone read the
> last piece of block.
> OneForOneStreamManager#registerStream we can set channel in this method, just
> in case of this case.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
