[JBoss JIRA] (ISPN-11117) In a distributed cache stale entries are not removed from the store
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11117?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11117:
--------------------------------
Status: Open (was: New)
> In a distributed cache stale entries are not removed from the store
> -------------------------------------------------------------------
>
> Key: ISPN-11117
> URL: https://issues.redhat.com/browse/ISPN-11117
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 9.3.6.Final, 9.4.17.Final, 10.0.1.Final, 10.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 11.0.0.Final
>
>
> This is a follow-up on ISPN-11116. It's wrong for invalidation commands to load the previous value from the store, but we also have the opposite problem: in a distributed cache, when a node loses some segments and the store is not segmented, we use an {{InvalidateCommand}} to remove stale entries, and it doesn't actually remove any entries from the store.
> Instead of keeping {{InvalidateCommand}} as is and finding another solution for removing stale segments, we could change {{InvalidateCommand}} to also remove entries from private stores.
> Invalidation mode is very unlikely to be used with private stores, but we don't actually prohibit it, so it's better for invalidation mode as well if {{InvalidateCommand}} removed entries from the private stores and ignored the shared stores. The only problem remaining is to actually optimize {{CacheLoaderInterceptor}} so that it doesn't load the previous value unless there is a listener.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (ISPN-11117) In a distributed cache stale entries are not removed from the store
by Dan Berindei (Jira)
Dan Berindei created ISPN-11117:
-----------------------------------
Summary: In a distributed cache stale entries are not removed from the store
Key: ISPN-11117
URL: https://issues.redhat.com/browse/ISPN-11117
Project: Infinispan
Issue Type: Bug
Components: Core, State Transfer
Affects Versions: 10.1.0.Final, 10.0.1.Final, 9.4.17.Final, 9.3.6.Final
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 11.0.0.Final
This is a follow-up on ISPN-11116. It's wrong for invalidation commands to load the previous value from the store, but we also have the opposite problem: in a distributed cache, when a node loses some segments and the store is not segmented, we use an {{InvalidateCommand}} to remove stale entries, and it doesn't actually remove any entries from the store.
Instead of keeping {{InvalidateCommand}} as is and finding another solution for removing stale segments, we could change {{InvalidateCommand}} to also remove entries from private stores.
Invalidation mode is very unlikely to be used with private stores, but we don't actually prohibit it, so it's better for invalidation mode as well if {{InvalidateCommand}} removed entries from the private stores and ignored the shared stores. The only problem remaining is to actually optimize {{CacheLoaderInterceptor}} so that it doesn't load the previous value unless there is a listener.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (ISPN-11116) Invalidation commands should not load the previous value from the store
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11116?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11116:
--------------------------------
Description:
{{CacheLoaderInterceptor.visitInvalidateCommand()}} loads the previous value from the store, just in case there is a {{CacheEntryInvalidated}} listener that needs the previous value. This makes invalidation mode with a shared store very costly: for every write, every node receives an invalidation command, every node reads the value from the store, and then discards it.
But {{InvalidateCommand}} only removes entries from memory, it never removes entry from stores (either shared or private). If we don't load the previous value in the data container, there is nothing for the {{InvalidateCommand}} to do. No invalidated entry means no listener notifications, so we don't need to load the previous value or to change the behaviour of {{CacheEntryInvalidatedEvent}}.
was:
{{CacheLoaderInterceptor.visitInvalidateCommand()}} loads the previous value from the store, just in case there is a {{CacheEntryInvalidated}} listener that needs the previous value. This makes invalidation mode with a shared store very costly: for every write, every node receives an invalidation command, every node reads the value from the store, and then discards it.
But {{InvalidateCommand}} only removes entries from memory, it never removes entry from stores (either shared or private). If we don't load the previous value in the data container, there is nothing for the {{InvalidateCommand}} to do. No invalidated entry means no listener notifications, so we don't need to load the previous value or to change the behaviour of {{CacheEntryInvalidatedEvent}}.
However, we also have the opposite problem: in a distributed cache, when a node loses some segments and the store is not segmented, we use an {{InvalidateCommand}} to remove stale entries, and it doesn't actually remove any entries from the store. Instead of keeping {{InvalidateCommand}} as is and finding another solution for removing stale segments, we could change {{InvalidateCommand}} to also remove entries from private stores.
Invalidation mode is very unlikely to be used with private stores, but we don't actually prohibit it, so it's better for invalidation mode as well if {{InvalidateCommand}} removed entries from the private stores and ignored the shared stores.
> Invalidation commands should not load the previous value from the store
> -----------------------------------------------------------------------
>
> Key: ISPN-11116
> URL: https://issues.redhat.com/browse/ISPN-11116
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.3.6.Final, 9.4.17.Final, 10.0.1.Final, 10.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 11.0.0.Final, 10.1.1.Final
>
>
> {{CacheLoaderInterceptor.visitInvalidateCommand()}} loads the previous value from the store, just in case there is a {{CacheEntryInvalidated}} listener that needs the previous value. This makes invalidation mode with a shared store very costly: for every write, every node receives an invalidation command, every node reads the value from the store, and then discards it.
> But {{InvalidateCommand}} only removes entries from memory, it never removes entry from stores (either shared or private). If we don't load the previous value in the data container, there is nothing for the {{InvalidateCommand}} to do. No invalidated entry means no listener notifications, so we don't need to load the previous value or to change the behaviour of {{CacheEntryInvalidatedEvent}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (ISPN-11116) Invalidation commands should not load the previous value from the store
by Dan Berindei (Jira)
Dan Berindei created ISPN-11116:
-----------------------------------
Summary: Invalidation commands should not load the previous value from the store
Key: ISPN-11116
URL: https://issues.redhat.com/browse/ISPN-11116
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 10.1.0.Final, 10.0.1.Final, 9.4.17.Final, 9.3.6.Final
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 11.0.0.Final, 10.1.1.Final
{{CacheLoaderInterceptor.visitInvalidateCommand()}} loads the previous value from the store, just in case there is a {{CacheEntryInvalidated}} listener that needs the previous value. This makes invalidation mode with a shared store very costly: for every write, every node receives an invalidation command, every node reads the value from the store, and then discards it.
But {{InvalidateCommand}} only removes entries from memory, it never removes entry from stores (either shared or private). If we don't load the previous value in the data container, there is nothing for the {{InvalidateCommand}} to do. No invalidated entry means no listener notifications, so we don't need to load the previous value or to change the behaviour of {{CacheEntryInvalidatedEvent}}.
However, we also have the opposite problem: in a distributed cache, when a node loses some segments and the store is not segmented, we use an {{InvalidateCommand}} to remove stale entries, and it doesn't actually remove any entries from the store. Instead of keeping {{InvalidateCommand}} as is and finding another solution for removing stale segments, we could change {{InvalidateCommand}} to also remove entries from private stores.
Invalidation mode is very unlikely to be used with private stores, but we don't actually prohibit it, so it's better for invalidation mode as well if {{InvalidateCommand}} removed entries from the private stores and ignored the shared stores.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months