[JBoss JIRA] (ISPN-11164) Docs: Clustered max idle updates
by Pedro Zapata Fernandez (Jira)
[ https://issues.redhat.com/browse/ISPN-11164?page=com.atlassian.jira.plugi... ]
Pedro Zapata Fernandez updated ISPN-11164:
------------------------------------------
Sprint: DataGrid Sprint #38, DataGrid Sprint #39 (was: DataGrid Sprint #38)
> Docs: Clustered max idle updates
> --------------------------------
>
> Key: ISPN-11164
> URL: https://issues.redhat.com/browse/ISPN-11164
> Project: Infinispan
> Issue Type: Enhancement
> Components: Documentation
> Reporter: Donald Naro
> Assignee: Donald Naro
> Priority: Major
> Fix For: 10.1.1.Final, 11.0.0.Final
>
>
> whenever an entry is read that can expire via max idle, we send a touch command to all owners so they all have the same relative access time. the get won't return until the touch command has completed.
> scattered the backup can be any node and we don't know which nodes are backups. in this case the touch command goes to all nodes.
> if you have max idle and eviction, any access of an entry on any node will update the eviction recency on all owners as well
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-11166) SocketTimeoutFailureRetryTest random failures
by Pedro Zapata Fernandez (Jira)
[ https://issues.redhat.com/browse/ISPN-11166?page=com.atlassian.jira.plugi... ]
Pedro Zapata Fernandez updated ISPN-11166:
------------------------------------------
Sprint: DataGrid Sprint #38, DataGrid Sprint #39 (was: DataGrid Sprint #38)
> SocketTimeoutFailureRetryTest random failures
> ---------------------------------------------
>
> Key: ISPN-11166
> URL: https://issues.redhat.com/browse/ISPN-11166
> Project: Infinispan
> Issue Type: Bug
> Components: Server, Test Suite
> Affects Versions: 10.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 11.0.0.Final
>
>
> Replicated non-tx caches without stores have an optimization for get operations to bypass the interceptor chain and query the data container directly. The optimization was added with the non-blocking listener changes, in order to compensate their overhead, but it only covered {{get()}} and {{getAsync()}}, while the HotRod server uses {{getCacheEntryAsync()}}.
> The ISPN-11020 fix extended the replicated get optimization to {{getCacheEntryAsync()}}, so now HotRod replicated reads bypass the interceptor chain, including the {{DelayingInterceptor}} added by {{SocketTimeoutFailureRetryTest}}.
> {noformat}
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:170)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:177)
> at org.infinispan.client.hotrod.retry.SocketTimeoutFailureRetryTest.testRetrySocketTimeout(SocketTimeoutFailureRetryTest.java:68)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-11168) DuplicateDomainCdiIT should use manifest dependencies
by Pedro Zapata Fernandez (Jira)
[ https://issues.redhat.com/browse/ISPN-11168?page=com.atlassian.jira.plugi... ]
Pedro Zapata Fernandez updated ISPN-11168:
------------------------------------------
Sprint: DataGrid Sprint #38, DataGrid Sprint #39 (was: DataGrid Sprint #38)
> DuplicateDomainCdiIT should use manifest dependencies
> -----------------------------------------------------
>
> Key: ISPN-11168
> URL: https://issues.redhat.com/browse/ISPN-11168
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite, WildFly modules
> Affects Versions: 10.1.0.Final
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Priority: Major
> Fix For: 10.1.2.Final
>
>
> DuplicateDomainCdiIT currently pulls in dependencies through Shrinkwrap's pom resolution. This is quite brittle in some environments. The test should be changed to use wildfly manifest dependencies.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-11116) Invalidation commands should not load the previous value from the store
by Pedro Zapata Fernandez (Jira)
[ https://issues.redhat.com/browse/ISPN-11116?page=com.atlassian.jira.plugi... ]
Pedro Zapata Fernandez updated ISPN-11116:
------------------------------------------
Sprint: DataGrid Sprint #38, DataGrid Sprint #39 (was: DataGrid Sprint #38)
> 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: 9.3.8.Final, 10.1.1.Final, 9.4.18.Final, 11.0.0.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, 11 months
[JBoss JIRA] (ISPN-11115) Infinispan BOM should only have dependency management for its own artifacts
by Pedro Zapata Fernandez (Jira)
[ https://issues.redhat.com/browse/ISPN-11115?page=com.atlassian.jira.plugi... ]
Pedro Zapata Fernandez updated ISPN-11115:
------------------------------------------
Sprint: DataGrid Sprint #38, DataGrid Sprint #39 (was: DataGrid Sprint #38)
> Infinispan BOM should only have dependency management for its own artifacts
> ---------------------------------------------------------------------------
>
> Key: ISPN-11115
> URL: https://issues.redhat.com/browse/ISPN-11115
> Project: Infinispan
> Issue Type: Bug
> Components: Build
> Affects Versions: 10.1.0.Final
> Reporter: Stéphane Nicoll
> Assignee: Pedro Ruivo
> Priority: Major
> Fix For: 10.1.1.Final
>
>
> A BOM should usually have dependency management for the artifacts of the project. Any attempt to provide dependency management for third party artifacts can lead to clashes and warnings in Maven when two boms compete for the same artifact.
> Could you please consider removing dependency management for the transaction and cache API please?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-11117) In a distributed cache stale entries are not removed from the store
by Pedro Zapata Fernandez (Jira)
[ https://issues.redhat.com/browse/ISPN-11117?page=com.atlassian.jira.plugi... ]
Pedro Zapata Fernandez updated ISPN-11117:
------------------------------------------
Sprint: DataGrid Sprint #38, DataGrid Sprint #39 (was: DataGrid Sprint #38)
> 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, 11 months
[JBoss JIRA] (ISPN-11119) Invalidation put should load previous value from stores
by Pedro Zapata Fernandez (Jira)
[ https://issues.redhat.com/browse/ISPN-11119?page=com.atlassian.jira.plugi... ]
Pedro Zapata Fernandez updated ISPN-11119:
------------------------------------------
Sprint: DataGrid Sprint #38, DataGrid Sprint #39 (was: DataGrid Sprint #38)
> Invalidation put should load previous value from stores
> -------------------------------------------------------
>
> Key: ISPN-11119
> URL: https://issues.redhat.com/browse/ISPN-11119
> 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
>
>
> A {{cache.put(key, value)}} without the {{IGNORE_RETURN_VALUES}} flag should load the previous value from the store(s) and return it.
> Currently the previous value is loaded only if the originator of the put is the primary owner of the key (see {{ClusteredCacheLoaderInterceptor.skipLoadForWriteCommand()}}).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months