You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Maxim Muzafarov (JIRA)" <ji...@apache.org> on 2018/05/15 17:59:00 UTC

[jira] [Comment Edited] (IGNITE-8469) Non-heap memroy leak for calling cluster activation multi times

    [ https://issues.apache.org/jira/browse/IGNITE-8469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476264#comment-16476264 ] 

Maxim Muzafarov edited comment on IGNITE-8469 at 5/15/18 5:58 PM:
------------------------------------------------------------------

[~agoncharuk]
 # I've founded my solution on assuption that e.g. [{{MappedFileMemoryProvider#initialize}} |https://github.com/Mmuzaf/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/mem/file/MappedFileMemoryProvider.java#L87] releases file resources if double initialization occurs. If this implementation is freeing resources, so the others can do the same because of they hides by {{DirectMemoryProvider}} interface. Double initialization is not the common case.

 # I agree with you, generally we should provide proper activation process but also should think about design "How can we rollback resources of other manages if some of them fails on {{onActivate()}}" mehtod called. Please, refer to this line of code:
 [org/apache/ignite/internal/processors/cache/GridCacheSharedContext.java:256|https://github.com/Mmuzaf/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheSharedContext.java#L256]

 # Also, please look at this line of code:
 [org/apache/ignite/internal/processors/cache/persistence/IgniteCacheDatabaseSharedManager.java:223|https://github.com/Mmuzaf/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/IgniteCacheDatabaseSharedManager.java#L223]
 This was added by IEP-4 implementation and from my point of view looks like protection point from double init. So, I've added "the same protection" to UnsafeMemoryProvider by freeing unused resources.

From my current perspective, this fix is correct and based on other code blocks, but I agree with you and I will thought about "How can we achive the proper activation scenario" in case some activate(true) fails. 
Please, share your thoughts


was (Author: mmuzaf):
[~agoncharuk]
 # I've founded my solution on assuption that e.g. MappedFileMemoryProvider#initialize releases file resources if double initialization occurs. If this implementation is freeing resources, so the others can do the same because of they hides by DirectMemoryProvider interface. Double initialization is not the common case.

 # I agree with you, generally we should provide proper activation process but also should think about design "How can we rollback resources of other manages if some of them fails on onActivate()" mehtod called. Please, refer to this line of code:
 [org/apache/ignite/internal/processors/cache/GridCacheSharedContext.java:256|https://github.com/Mmuzaf/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheSharedContext.java#L256]

 # Also, please look at this line of code:
 [org/apache/ignite/internal/processors/cache/persistence/IgniteCacheDatabaseSharedManager.java:223|https://github.com/Mmuzaf/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/IgniteCacheDatabaseSharedManager.java#L223]
 This was added by IEP-4 implementation and from my point of view looks like protection point from double init. So, I've added "the same protection" to UnsafeMemoryProvider by freeing unused resources.

From my current perspective, this fix is correct and based on other code blocks, but I agree with you and I will thought about "How can we achive the proper activation scenario" in case some activate(true) fails. 
Please, share your thoughts

> Non-heap memroy leak for calling cluster activation multi times
> ---------------------------------------------------------------
>
>                 Key: IGNITE-8469
>                 URL: https://issues.apache.org/jira/browse/IGNITE-8469
>             Project: Ignite
>          Issue Type: Bug
>          Components: persistence
>            Reporter: Maxim Muzafarov
>            Assignee: Maxim Muzafarov
>            Priority: Major
>             Fix For: 2.6
>
>
> Calling multiple time cluster (with enabled persistence and started client nodes) activation {{ig3CB.cluster().active(true);}} leads to non-heap memory leak.
> Line {{org/apache/ignite/internal/pagemem/impl/PageMemoryNoStoreImpl.java:234}} looks suspicious because of in case method {{org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl#start}} callled multi times (e.g. activate(true) called multi times) we lost info about allocated regions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)