[jira] [Updated] (IGNITE-2714) Cleanup GridOffHeapPartitionedMap when cache is destroyed
[ https://issues.apache.org/jira/browse/IGNITE-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Martianov updated IGNITE-2714: - Assignee: (was: Andrey Martianov) > Cleanup GridOffHeapPartitionedMap when cache is destroyed > - > > Key: IGNITE-2714 > URL: https://issues.apache.org/jira/browse/IGNITE-2714 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Semen Boikov >Priority: Critical > Fix For: 2.0 > > > For cache with offheap enabled GridOffHeapPartitionedMap is created (see > GridOffHeapProcessor). But this GridOffHeapPartitionedMap is not removed > when cache is destroyed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2698) CacheKeyConfiguration is used only with BinaryMarshaller
[ https://issues.apache.org/jira/browse/IGNITE-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Martianov updated IGNITE-2698: - Assignee: Semen Boikov (was: Andrey Martianov) > CacheKeyConfiguration is used only with BinaryMarshaller > > > Key: IGNITE-2698 > URL: https://issues.apache.org/jira/browse/IGNITE-2698 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Semen Boikov >Assignee: Semen Boikov > Fix For: 1.8 > > > Now if CacheKeyConfiguration is specified it is used only with > BinaryMarshaller. Need to take it into account with others marshallers as > well or update documentation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2698) CacheKeyConfiguration is used only with BinaryMarshaller
[ https://issues.apache.org/jira/browse/IGNITE-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15584665#comment-15584665 ] Andrey Martianov commented on IGNITE-2698: -- Hi [~sboikov], Thanks for your comments, I agree with you. I addressed it and updated pull-request. TC is ok, please review. Thanks > CacheKeyConfiguration is used only with BinaryMarshaller > > > Key: IGNITE-2698 > URL: https://issues.apache.org/jira/browse/IGNITE-2698 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Semen Boikov >Assignee: Andrey Martianov > Fix For: 1.8 > > > Now if CacheKeyConfiguration is specified it is used only with > BinaryMarshaller. Need to take it into account with others marshallers as > well or update documentation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2698) CacheKeyConfiguration is used only with BinaryMarshaller
[ https://issues.apache.org/jira/browse/IGNITE-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Martianov updated IGNITE-2698: - Assignee: Semen Boikov (was: Andrey Martianov) > CacheKeyConfiguration is used only with BinaryMarshaller > > > Key: IGNITE-2698 > URL: https://issues.apache.org/jira/browse/IGNITE-2698 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Semen Boikov >Assignee: Semen Boikov > Fix For: 1.8 > > > Now if CacheKeyConfiguration is specified it is used only with > BinaryMarshaller. Need to take it into account with others marshallers as > well or update documentation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3957) Swap space is not cleared when the cache is destroyed
[ https://issues.apache.org/jira/browse/IGNITE-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Martianov updated IGNITE-3957: - Assignee: Semen Boikov (was: Andrey Martianov) > Swap space is not cleared when the cache is destroyed > - > > Key: IGNITE-3957 > URL: https://issues.apache.org/jira/browse/IGNITE-3957 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.7 >Reporter: Valentin Kulichenko >Assignee: Semen Boikov > Attachments: SwapTest.java > > > Test attached. > When the cache is destroyed, corresponding swap filed are not deleted. > However, they are deleted on node stop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2714) Cleanup GridOffHeapPartitionedMap when cache is destroyed
[ https://issues.apache.org/jira/browse/IGNITE-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15516739#comment-15516739 ] Andrey Martianov commented on IGNITE-2714: -- TC tests passed. Please review. > Cleanup GridOffHeapPartitionedMap when cache is destroyed > - > > Key: IGNITE-2714 > URL: https://issues.apache.org/jira/browse/IGNITE-2714 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Semen Boikov >Assignee: Andrey Martianov >Priority: Critical > Fix For: 1.8 > > > For cache with offheap enabled GridOffHeapPartitionedMap is created (see > GridOffHeapProcessor). But this GridOffHeapPartitionedMap is not removed > when cache is destroyed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-3957) Swap space is not cleared when the cache is destroyed
[ https://issues.apache.org/jira/browse/IGNITE-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Martianov reassigned IGNITE-3957: Assignee: Andrey Martianov > Swap space is not cleared when the cache is destroyed > - > > Key: IGNITE-3957 > URL: https://issues.apache.org/jira/browse/IGNITE-3957 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.7 >Reporter: Valentin Kulichenko >Assignee: Andrey Martianov > Attachments: SwapTest.java > > > Test attached. > When the cache is destroyed, corresponding swap filed are not deleted. > However, they are deleted on node stop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2714) Cleanup GridOffHeapPartitionedMap when cache is destroyed
[ https://issues.apache.org/jira/browse/IGNITE-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15516168#comment-15516168 ] Andrey Martianov commented on IGNITE-2714: -- I added clearing of offheap memory at cache destroy in OFFHEAP_VALUES mode and updated PR. > Cleanup GridOffHeapPartitionedMap when cache is destroyed > - > > Key: IGNITE-2714 > URL: https://issues.apache.org/jira/browse/IGNITE-2714 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Semen Boikov >Assignee: Andrey Martianov >Priority: Critical > Fix For: 1.8 > > > For cache with offheap enabled GridOffHeapPartitionedMap is created (see > GridOffHeapProcessor). But this GridOffHeapPartitionedMap is not removed > when cache is destroyed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-2698) CacheKeyConfiguration is used only with BinaryMarshaller
[ https://issues.apache.org/jira/browse/IGNITE-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15512946#comment-15512946 ] Andrey Martianov edited comment on IGNITE-2698 at 9/22/16 10:54 AM: I ran tests on TC - everything seems ok. Please review was (Author: amartianov): I run tests on TC - everything seems ok. Please review > CacheKeyConfiguration is used only with BinaryMarshaller > > > Key: IGNITE-2698 > URL: https://issues.apache.org/jira/browse/IGNITE-2698 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Semen Boikov >Assignee: Andrey Martianov > Fix For: 1.8 > > > Now if CacheKeyConfiguration is specified it is used only with > BinaryMarshaller. Need to take it into account with others marshallers as > well or update documentation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-2698) CacheKeyConfiguration is used only with BinaryMarshaller
[ https://issues.apache.org/jira/browse/IGNITE-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15512946#comment-15512946 ] Andrey Martianov edited comment on IGNITE-2698 at 9/22/16 10:54 AM: I run tests on TC - everything seems ok. Please review was (Author: amartianov): I ran tests on TC - everything seems ok. Please review > CacheKeyConfiguration is used only with BinaryMarshaller > > > Key: IGNITE-2698 > URL: https://issues.apache.org/jira/browse/IGNITE-2698 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Semen Boikov >Assignee: Andrey Martianov > Fix For: 1.8 > > > Now if CacheKeyConfiguration is specified it is used only with > BinaryMarshaller. Need to take it into account with others marshallers as > well or update documentation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2698) CacheKeyConfiguration is used only with BinaryMarshaller
[ https://issues.apache.org/jira/browse/IGNITE-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15512946#comment-15512946 ] Andrey Martianov commented on IGNITE-2698: -- I ran tests on TC - everything seems ok. Please review > CacheKeyConfiguration is used only with BinaryMarshaller > > > Key: IGNITE-2698 > URL: https://issues.apache.org/jira/browse/IGNITE-2698 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Semen Boikov >Assignee: Andrey Martianov > Fix For: 1.8 > > > Now if CacheKeyConfiguration is specified it is used only with > BinaryMarshaller. Need to take it into account with others marshallers as > well or update documentation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2698) CacheKeyConfiguration is used only with BinaryMarshaller
[ https://issues.apache.org/jira/browse/IGNITE-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15509786#comment-15509786 ] Andrey Martianov commented on IGNITE-2698: -- I made following changes: 1. Added processing of CacheKeyConfiguration when Jdk/Optimized marshallers are used. 2. Added check at node startup (if Jdk/Optimized marshallers are used) that local cache key configurations are in accordance with remote cache key configurations. 3. Fixed bug: BinaryMarshaller doesn't use CacheKeyConfiguration for classes those aren't explicitly defined in BinaryConfiguration (using BinaryTypeConfiguration). > CacheKeyConfiguration is used only with BinaryMarshaller > > > Key: IGNITE-2698 > URL: https://issues.apache.org/jira/browse/IGNITE-2698 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Semen Boikov >Assignee: Andrey Martianov > Fix For: 1.8 > > > Now if CacheKeyConfiguration is specified it is used only with > BinaryMarshaller. Need to take it into account with others marshallers as > well or update documentation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2698) CacheKeyConfiguration is used only with BinaryMarshaller
[ https://issues.apache.org/jira/browse/IGNITE-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15506971#comment-15506971 ] Andrey Martianov commented on IGNITE-2698: -- Found out root cause. Working on fix. > CacheKeyConfiguration is used only with BinaryMarshaller > > > Key: IGNITE-2698 > URL: https://issues.apache.org/jira/browse/IGNITE-2698 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Semen Boikov >Assignee: Andrey Martianov > Fix For: 1.8 > > > Now if CacheKeyConfiguration is specified it is used only with > BinaryMarshaller. Need to take it into account with others marshallers as > well or update documentation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-2698) CacheKeyConfiguration is used only with BinaryMarshaller
[ https://issues.apache.org/jira/browse/IGNITE-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Martianov reassigned IGNITE-2698: Assignee: Andrey Martianov (was: Yakov Zhdanov) > CacheKeyConfiguration is used only with BinaryMarshaller > > > Key: IGNITE-2698 > URL: https://issues.apache.org/jira/browse/IGNITE-2698 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Semen Boikov >Assignee: Andrey Martianov > Fix For: 1.8 > > > Now if CacheKeyConfiguration is specified it is used only with > BinaryMarshaller. Need to take it into account with others marshallers as > well or update documentation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2714) Cleanup GridOffHeapPartitionedMap when cache is destroyed
[ https://issues.apache.org/jira/browse/IGNITE-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15496495#comment-15496495 ] Andrey Martianov commented on IGNITE-2714: -- I fixed problem with unremoved GridOffHeapPartitionedMap. This fix is actual for ONHEAP_TIERED and OFFHEAP_TIERED memory modes. But found out another bug: if cache is created with memory mode OFFHEAP_VALUES then offheap memory is processed in another way and isn't freed after cache destroy. > Cleanup GridOffHeapPartitionedMap when cache is destroyed > - > > Key: IGNITE-2714 > URL: https://issues.apache.org/jira/browse/IGNITE-2714 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Semen Boikov >Assignee: Andrey Martianov >Priority: Critical > Fix For: 1.8 > > > For cache with offheap enabled GridOffHeapPartitionedMap is created (see > GridOffHeapProcessor). But this GridOffHeapPartitionedMap is not removed > when cache is destroyed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3621) Make GridCacheTtlManager singleton
[
https://issues.apache.org/jira/browse/IGNITE-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15493932#comment-15493932
]
Andrey Martianov commented on IGNITE-3621:
--
[~sboikov], Thanks!
[~amashenkov], Entries expiration is checked on every cache action (in way as
point #1 of description says) and processed in threads performed that actions.
So I suppose we don't need additional cleaner threads.
CleanupWorker really helps only in case if it isn't any cache activity for some
time. And I think in this case it will be enough.
> Make GridCacheTtlManager singleton
> --
>
> Key: IGNITE-3621
> URL: https://issues.apache.org/jira/browse/IGNITE-3621
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.6
>Reporter: Eduard Shangareev
>Assignee: Andrey Martianov
> Labels: performance
>
> Now every cache has own TTL manager, which creates CleanupWorker = new extra
> thread. This can cause to extra hundreds of threads (redundant context
> switches = performance penalty).
> Also, under IGNITE-3513 every put can enter critical section to notify
> worker. Obviously, it is not good from performance point of view.
> So, my proposal is next:
> 1. Expiration should be done on every cache action (on exit thread which
> updates cache should invoke {{expire}}).
> 2. TtlManager will exist only in one instance.
> 3. CleanupWorker will be the only backup if there is no cache activity. It
> will wake up with some period to check for work (500 ms, for example).
> Moreover, now we keep on-heap pending entries even if a cache is kept
> off-head. At least, this issue needs discussion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-3621) Make GridCacheTtlManager singleton
[
https://issues.apache.org/jira/browse/IGNITE-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15493932#comment-15493932
]
Andrey Martianov edited comment on IGNITE-3621 at 9/15/16 4:59 PM:
---
[~sboikov], Thanks!
[~amashenkov], Entries expiration is checked on every cache action (in way as
point #1 of description says) and processed in threads performed those actions.
So I suppose we don't need additional cleaner threads.
CleanupWorker really helps only in case if it isn't any cache activity for some
time. And I think in this case it will be enough.
was (Author: amartianov):
[~sboikov], Thanks!
[~amashenkov], Entries expiration is checked on every cache action (in way as
point #1 of description says) and processed in threads performed that actions.
So I suppose we don't need additional cleaner threads.
CleanupWorker really helps only in case if it isn't any cache activity for some
time. And I think in this case it will be enough.
> Make GridCacheTtlManager singleton
> --
>
> Key: IGNITE-3621
> URL: https://issues.apache.org/jira/browse/IGNITE-3621
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.6
>Reporter: Eduard Shangareev
>Assignee: Andrey Martianov
> Labels: performance
>
> Now every cache has own TTL manager, which creates CleanupWorker = new extra
> thread. This can cause to extra hundreds of threads (redundant context
> switches = performance penalty).
> Also, under IGNITE-3513 every put can enter critical section to notify
> worker. Obviously, it is not good from performance point of view.
> So, my proposal is next:
> 1. Expiration should be done on every cache action (on exit thread which
> updates cache should invoke {{expire}}).
> 2. TtlManager will exist only in one instance.
> 3. CleanupWorker will be the only backup if there is no cache activity. It
> will wake up with some period to check for work (500 ms, for example).
> Moreover, now we keep on-heap pending entries even if a cache is kept
> off-head. At least, this issue needs discussion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-2714) Cleanup GridOffHeapPartitionedMap when cache is destroyed
[ https://issues.apache.org/jira/browse/IGNITE-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Martianov reassigned IGNITE-2714: Assignee: Andrey Martianov (was: Yakov Zhdanov) > Cleanup GridOffHeapPartitionedMap when cache is destroyed > - > > Key: IGNITE-2714 > URL: https://issues.apache.org/jira/browse/IGNITE-2714 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Semen Boikov >Assignee: Andrey Martianov >Priority: Critical > Fix For: 1.8 > > > For cache with offheap enabled GridOffHeapPartitionedMap is created (see > GridOffHeapProcessor). But this GridOffHeapPartitionedMap is not removed > when cache is destroyed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3621) Make GridCacheTtlManager singleton
[
https://issues.apache.org/jira/browse/IGNITE-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15493425#comment-15493425
]
Andrey Martianov commented on IGNITE-3621:
--
Cleanup worker and related logic extracted into shared
GridCacheSharedTtlCleanupManager. Single worker thread are started only if at
least one cache created with 'isEagerTtl' flag set. This worker checks caches
on expired entries every 500 ms.
> Make GridCacheTtlManager singleton
> --
>
> Key: IGNITE-3621
> URL: https://issues.apache.org/jira/browse/IGNITE-3621
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.6
>Reporter: Eduard Shangareev
>Assignee: Andrey Martianov
> Labels: performance
>
> Now every cache has own TTL manager, which creates CleanupWorker = new extra
> thread. This can cause to extra hundreds of threads (redundant context
> switches = performance penalty).
> Also, under IGNITE-3513 every put can enter critical section to notify
> worker. Obviously, it is not good from performance point of view.
> So, my proposal is next:
> 1. Expiration should be done on every cache action (on exit thread which
> updates cache should invoke {{expire}}).
> 2. TtlManager will exist only in one instance.
> 3. CleanupWorker will be the only backup if there is no cache activity. It
> will wake up with some period to check for work (500 ms, for example).
> Moreover, now we keep on-heap pending entries even if a cache is kept
> off-head. At least, this issue needs discussion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3621) Make GridCacheTtlManager singleton
[
https://issues.apache.org/jira/browse/IGNITE-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15490803#comment-15490803
]
Andrey Martianov commented on IGNITE-3621:
--
I suggest we should keep separate TtlManager-s for each cache (in order to
manage queues of pending entries of different caches separately) but extract
CleanupWorker and related logic in shared component.
Working this way.
> Make GridCacheTtlManager singleton
> --
>
> Key: IGNITE-3621
> URL: https://issues.apache.org/jira/browse/IGNITE-3621
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.6
>Reporter: Eduard Shangareev
>Assignee: Andrey Martianov
> Labels: performance
>
> Now every cache has own TTL manager, which creates CleanupWorker = new extra
> thread. This can cause to extra hundreds of threads (redundant context
> switches = performance penalty).
> Also, under IGNITE-3513 every put can enter critical section to notify
> worker. Obviously, it is not good from performance point of view.
> So, my proposal is next:
> 1. Expiration should be done on every cache action (on exit thread which
> updates cache should invoke {{expire}}).
> 2. TtlManager will exist only in one instance.
> 3. CleanupWorker will be the only backup if there is no cache activity. It
> will wake up with some period to check for work (500 ms, for example).
> Moreover, now we keep on-heap pending entries even if a cache is kept
> off-head. At least, this issue needs discussion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-3621) Make GridCacheTtlManager singleton
[
https://issues.apache.org/jira/browse/IGNITE-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Martianov reassigned IGNITE-3621:
Assignee: Andrey Martianov (was: Alexei Scherbakov)
> Make GridCacheTtlManager singleton
> --
>
> Key: IGNITE-3621
> URL: https://issues.apache.org/jira/browse/IGNITE-3621
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.6
>Reporter: Eduard Shangareev
>Assignee: Andrey Martianov
> Labels: performance
>
> Now every cache has own TTL manager, which creates CleanupWorker = new extra
> thread. This can cause to extra hundreds of threads (redundant context
> switches = performance penalty).
> Also, under IGNITE-3513 every put can enter critical section to notify
> worker. Obviously, it is not good from performance point of view.
> So, my proposal is next:
> 1. Expiration should be done on every cache action (on exit thread which
> updates cache should invoke {{expire}}).
> 2. TtlManager will exist only in one instance.
> 3. CleanupWorker will be the only backup if there is no cache activity. It
> will wake up with some period to check for work (500 ms, for example).
> Moreover, now we keep on-heap pending entries even if a cache is kept
> off-head. At least, this issue needs discussion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3621) Make GridCacheTtlManager singleton
[
https://issues.apache.org/jira/browse/IGNITE-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15487491#comment-15487491
]
Andrey Martianov commented on IGNITE-3621:
--
[~ascherbakov], could you please reassign this issue to me (if you don't have
progress on it)
> Make GridCacheTtlManager singleton
> --
>
> Key: IGNITE-3621
> URL: https://issues.apache.org/jira/browse/IGNITE-3621
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.6
>Reporter: Eduard Shangareev
>Assignee: Alexei Scherbakov
> Labels: performance
>
> Now every cache has own TTL manager, which creates CleanupWorker = new extra
> thread. This can cause to extra hundreds of threads (redundant context
> switches = performance penalty).
> Also, under IGNITE-3513 every put can enter critical section to notify
> worker. Obviously, it is not good from performance point of view.
> So, my proposal is next:
> 1. Expiration should be done on every cache action (on exit thread which
> updates cache should invoke {{expire}}).
> 2. TtlManager will exist only in one instance.
> 3. CleanupWorker will be the only backup if there is no cache activity. It
> will wake up with some period to check for work (500 ms, for example).
> Moreover, now we keep on-heap pending entries even if a cache is kept
> off-head. At least, this issue needs discussion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
