October 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5987) Create concurrent topology switch under failover unit test

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-5987?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5987: ---------------------------------- Fix Version/s: 9.4.1.Final (was: 9.4.0.Final) > Create concurrent topology switch under failover unit test > ---------------------------------------------------------- > > Key: ISPN-5987 > URL: https://issues.jboss.org/browse/ISPN-5987 > Project: Infinispan > Issue Type: Task > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Major > Fix For: 9.4.1.Final > > > Create a unit test for ISPN-5879. > Matej built a very interesting one [here|https://raw.githubusercontent.com/mcimbora/infinispan/da971738e326a7...] but needs some further work. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6011) ClassCastException in CDI generated keys for JCache

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-6011?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6011: ---------------------------------- Fix Version/s: 9.4.1.Final (was: 9.4.0.Final) > ClassCastException in CDI generated keys for JCache > --------------------------------------------------- > > Key: ISPN-6011 > URL: https://issues.jboss.org/browse/ISPN-6011 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.1.0.CR1, 8.0.2.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Major > Fix For: 9.4.1.Final > > > When using JCache-annotations the DefaultCacheKeyGenerator exclusively looks at parameter values to form the cache key. Therefore it will be very likely that collissions occur (resulting in difficult to find ClassCastExceptions). The provided patch uses the method- and class names as additionally values to make the cache key more unique. > Might also add that I am aware that by spec this should not be an issue when no cachename is given (as it should generate a cache using the class-name), but when a cache name is given collissions may occur. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6212) InfinispanBackendQueueProcessor is assuming all IndexManager implementations are DirectoryBasedIndexManager

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-6212?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6212: ---------------------------------- Fix Version/s: 9.4.1.Final (was: 9.4.0.Final) > InfinispanBackendQueueProcessor is assuming all IndexManager implementations are DirectoryBasedIndexManager > ----------------------------------------------------------------------------------------------------------- > > Key: ISPN-6212 > URL: https://issues.jboss.org/browse/ISPN-6212 > Project: Infinispan > Issue Type: Task > Components: Embedded Querying > Reporter: Sanne Grinovero > Assignee: Adrian Nistor > Priority: Major > Fix For: 9.4.1.Final > > > See also the FIXME note in {{InfinispanBackendQueueProcessor}}: this needs to be cleaned up. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6219) An interruption during a MassIndexer run should exit early

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-6219?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6219: ---------------------------------- Fix Version/s: 9.4.1.Final (was: 9.4.0.Final) > An interruption during a MassIndexer run should exit early > ---------------------------------------------------------- > > Key: ISPN-6219 > URL: https://issues.jboss.org/browse/ISPN-6219 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Reporter: Sanne Grinovero > Priority: Major > Fix For: 9.4.1.Final > > > Methods like {{IndexUpdater.updateIndex()}} correctly check for interruption state to skip some work but they don't trigger an early exit from the indexing loop so we'd still be consuming all of the data stream. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6158) Move interceptors to private package

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-6158?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6158: ---------------------------------- Fix Version/s: 9.4.1.Final (was: 9.4.0.Final) > Move interceptors to private package > ------------------------------------ > > Key: ISPN-6158 > URL: https://issues.jboss.org/browse/ISPN-6158 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Tristan Tarrant > Assignee: Dan Berindei > Priority: Major > Fix For: 9.4.1.Final > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[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.1.Final (was: 9.4.0.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.1.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)

7 years, 6 months

1
0
0 / 0

[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.1.Final (was: 9.4.0.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.1.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)

7 years, 6 months

1
0
0 / 0

[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.1.Final (was: 9.4.0.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.1.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)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6294) Query DSL should allow easy 'continuation' to assist with creating dynamic queries

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-6294?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6294: ---------------------------------- Fix Version/s: 9.4.1.Final (was: 9.4.0.Final) > Query DSL should allow easy 'continuation' to assist with creating dynamic queries > ---------------------------------------------------------------------------------- > > Key: ISPN-6294 > URL: https://issues.jboss.org/browse/ISPN-6294 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Reporter: Adrian Nistor > Priority: Major > Fix For: 9.4.1.Final > > > Conditional chaining of DSL conditions is cumbersome, as shown here: https://github.com/infinispan/infinispan/blob/af7f38ba1cf538be6b08d7b895f... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6336) NonIndexedClusteredDummyInMemoryStoreQueryDslConditionsTest random failures

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-6336?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6336: ---------------------------------- Fix Version/s: 9.4.1.Final (was: 9.4.0.Final) > NonIndexedClusteredDummyInMemoryStoreQueryDslConditionsTest random failures > --------------------------------------------------------------------------- > > Key: ISPN-6336 > URL: https://issues.jboss.org/browse/ISPN-6336 > Project: Infinispan > Issue Type: Bug > Reporter: Gustavo Fernandes > Assignee: Adrian Nistor > Priority: Major > Labels: testsuite_stability > Fix For: 9.4.1.Final > > > Picked this failure when running the query testsuite in loop. It's somehow hard to reproduce. > The presence of the Byteman test runner in the stacktrace looks suspicious, since it is not supposed to run this test. > {code} > Tests run: 2907, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 51.21 sec <<< FAILURE! - in TestSuite > testSampleDomainQuery16(org.infinispan.query.dsl.embedded.NonIndexedClusteredDummyInMemoryStoreQueryDslConditionsTest) Time elapsed: 0.01 sec <<< FAILURE! > java.lang.AssertionError: expected:<50> but was:<0> > 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.query.dsl.embedded.QueryDslConditionsTest.testSampleDomainQuery16(QueryDslConditionsTest.java:1366) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84) > at org.testng.internal.MethodInvocationHelper$1.runTestMethod(MethodInvocationHelper.java:200) > at org.jboss.byteman.contrib.bmunit.BMNGAbstractRunner.run(BMNGAbstractRunner.java:58) > at sun.reflect.GeneratedMethodAccessor72.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.testng.internal.MethodInvocationHelper.invokeHookable(MethodInvocationHelper.java:212) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:707) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:348) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:38) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2018