[JBoss JIRA] (ISPN-5929) InfinispanQueryIT.testQueryOnFirstNode random failures
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-5929?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5929:
----------------------------------
Fix Version/s: 9.4.4.Final
(was: 9.4.3.Final)
> InfinispanQueryIT.testQueryOnFirstNode random failures
> ------------------------------------------------------
>
> Key: ISPN-5929
> URL: https://issues.jboss.org/browse/ISPN-5929
> Project: Infinispan
> Issue Type: Bug
> Components: Integration , Test Suite - Query
> Affects Versions: 8.1.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Adrian Nistor
> Priority: Blocker
> Fix For: 9.4.4.Final
>
>
> {{InfinispanQueryIT.testQueryOnFirstNode()}} and {{InfinispanQueryIT.testQueryOnSecondNode()}} fail randomly in CI with this assertion:
> {noformat}
> java.lang.AssertionError: expected:<3> but was:<2>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at org.infinispan.test.integration.as.query.InfinispanQueryIT.testQueryOnFirstNode(InfinispanQueryIT.java:99)
> {noformat}
> Example: http://ci.infinispan.org/viewLog.html?buildId=31810&tab=buildResultsDiv&b...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (ISPN-5600) Optimize transactions on multiple caches
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-5600?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5600:
----------------------------------
Fix Version/s: 9.4.4.Final
(was: 9.4.3.Final)
> Optimize transactions on multiple caches
> ----------------------------------------
>
> Key: ISPN-5600
> URL: https://issues.jboss.org/browse/ISPN-5600
> Project: Infinispan
> Issue Type: Enhancement
> Components: Transactions
> Affects Versions: 8.0.0.Alpha2
> Reporter: Radim Vansa
> Priority: Major
> Fix For: 9.4.4.Final
>
>
> NON_XA transactions that span multiple caches are registered as multiple synchronizations, and these synchronizations are often processed sequentially ^1^; therefore, we send synchronous PrepareCommand for each cache and then CommitCommand for each cache as well, delaying the commit by these round-trips.
> Since the targets for different caches may differ, we still need to send the RPCs separately, but in parallel. Therefore, there should be one uber-synchronization for all caches that use NON_XA mode (and maybe something similar with XA). I believe that using single synchronization could save some allocations, too.
> ^1^ Not sure if full-fledged JTA implementations do that; JTA spec does not say anything about the order of synchronizations and whether these should be processed in parallel.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (ISPN-6279) Refactor CacheLoader API to make it thread safe
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-6279?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6279:
----------------------------------
Fix Version/s: 9.4.4.Final
(was: 9.4.3.Final)
> Refactor CacheLoader API to make it thread safe
> -----------------------------------------------
>
> Key: ISPN-6279
> URL: https://issues.jboss.org/browse/ISPN-6279
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores
> Reporter: Sebastian Łaskawiec
> Priority: Minor
> Fix For: 9.4.4.Final
>
>
> h3. Introduction
> Currently {{CacheLoader}} thread safety can be easily compromised by broken implementations. We should provide a better implementation to make it more convenient and less error prone.
> h3. Problem statement
> CacheLoader API looks like this:
> {code}
> public interface AdvancedCacheLoader<K, V> extends CacheLoader<K, V> {
> ...
> void process(KeyFilter<? super K> filter, CacheLoaderTask<K, V> task, Executor executor, boolean fetchValue, boolean fetchMetadata);
> ...
> }
> {code}
> The CacheLoader implementation controls {{CacheLoaderTask}} as well as the number of threads used for processing (specified by {{Executor}}). If one wants to collect all keys (similarly to [AdvancedCacheLoader|https://github.com/infinispan/infinispan/blob/master/...]) it is very easy to hit concurrently issues while adding them to the set (See previous JIRAs: ISPN-3938 and ISPN-6276).
> h3. Solution
> The solution should take away currently control (Executor) and keyset (the simplest idea is to add it to {{CacheLoaderTask}}) from from the implementation. One of the ideas is to create a Lambda expression for pulling records from Cache Store. Note that similar changes will need to be performed to {{CacheWriter}} (to make it similar).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (ISPN-6224) Simplify configuration of Query with Indexing Affinity
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-6224?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6224:
----------------------------------
Fix Version/s: 9.4.4.Final
(was: 9.4.3.Final)
> Simplify configuration of Query with Indexing Affinity
> ------------------------------------------------------
>
> Key: ISPN-6224
> URL: https://issues.jboss.org/browse/ISPN-6224
> Project: Infinispan
> Issue Type: Enhancement
> Components: Embedded Querying
> Reporter: Sanne Grinovero
> Priority: Major
> Fix For: 9.4.4.Final
>
>
> We should try to enable the "Index Affinity" capabilities in an easier way from a configuration point of view.
> For example I wonder if the capabilities provided by the {{AffinityPartitioner}} could not be enabled by default, for example automatically decorating any user defined {{HashFunctionPartitioner}} so that people can't neither forget to enable it, nor override it.
> Second, should it be enabled by default when the cache configuration suggests it, for example in most clustered caches?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (ISPN-6220) Speedup index rebuilds but using ADD rather than UPDATE statements when safe
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-6220?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6220:
----------------------------------
Fix Version/s: 9.4.4.Final
(was: 9.4.3.Final)
> Speedup index rebuilds but using ADD rather than UPDATE statements when safe
> ----------------------------------------------------------------------------
>
> Key: ISPN-6220
> URL: https://issues.jboss.org/browse/ISPN-6220
> Project: Infinispan
> Issue Type: Enhancement
> Components: Embedded Querying
> Reporter: Sanne Grinovero
> Priority: Major
> Fix For: 9.4.4.Final
>
>
> The {{DistributedExecutorMassIndexer}} relies on update commands to index the new entries, but when we just run a full purge of the index it should be safe to use Add commands instead if we know that there aren't concurrent updates.
> The lack of concurrent updates might be tricky but I think we can find such a condition when using Affinity as the index is being fully controlled by the current indexing engine, similarly to the checks to see if it's safe to use an NRT workspace.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months