[JBoss JIRA] (ISPN-5717) Continuous query ignores expited entries
by Vojtech Juranek (JIRA)
Vojtech Juranek created ISPN-5717:
-------------------------------------
Summary: Continuous query ignores expited entries
Key: ISPN-5717
URL: https://issues.jboss.org/browse/ISPN-5717
Project: Infinispan
Issue Type: Bug
Components: Embedded Querying, Remote Querying
Reporter: Vojtech Juranek
When cache entry expires, CQ listeners are not updated and thus can server obsolete results
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 7 months
[JBoss JIRA] (ISPN-5710) Unknown entity name when indexing entities defined in inner classes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5710?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5710:
-----------------------------------------------
Adrian Nistor <anistor(a)redhat.com> changed the Status of [bug 1258800|https://bugzilla.redhat.com/show_bug.cgi?id=1258800] from NEW to POST
> Unknown entity name when indexing entities defined in inner classes
> -------------------------------------------------------------------
>
> Key: ISPN-5710
> URL: https://issues.jboss.org/browse/ISPN-5710
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 7.2.4.Final, 8.0.0.CR1
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 8.0.0.Final, 7.2.5.Final
>
>
> Reproducer:
> {code}
> import java.util.List;
> import org.hibernate.search.annotations.Analyze;
> import org.hibernate.search.annotations.Field;
> import org.hibernate.search.annotations.Indexed;
> import org.hibernate.search.annotations.Store;
> import org.infinispan.Cache;
> import org.infinispan.configuration.cache.ConfigurationBuilder;
> import org.infinispan.configuration.cache.Index;
> import org.infinispan.manager.DefaultCacheManager;
> import org.infinispan.query.Search;
> import org.infinispan.query.dsl.Query;
> import org.infinispan.query.dsl.QueryFactory;
> public class Test {
> public static void main(String[] args) {
> ConfigurationBuilder builder = new ConfigurationBuilder();
> builder.indexing().index(Index.ALL)
> .addProperty("default.directory_provider", "ram")
> .addProperty("lucene_version", "LUCENE_CURRENT");
> // Construct a simple local cache manager with default configuration
> DefaultCacheManager cacheManager = new DefaultCacheManager(builder.build());
> // Obtain the default cache
> Cache<String, Person> cache = cacheManager.getCache();
> // Store some entries
> cache.put("person1", new Person("William", "Shakespeare"));
> cache.put("person2", new Person("William", "Wordsworth"));
> cache.put("person3", new Person("John", "Milton"));
> // Obtain a query factory for the cache
> QueryFactory<?> queryFactory = Search.getQueryFactory(cache);
> // Construct a query
> Query query = queryFactory.from(Person.class).having("name").eq("William").toBuilder().build();
> // Execute the query
> List<Person> matches = query.list();
> matches.forEach(person -> System.out.printf("Match: %s", person));
> // Stop the cache manager and release all resources
> cacheManager.stop();
> }
> @Indexed
> static class Person {
> @Field(store = Store.YES, analyze = Analyze.NO)
> String name;
> @Field(store = Store.YES, analyze = Analyze.NO, indexNullAs = Field.DEFAULT_NULL_TOKEN)
> String surname;
> public Person(String name, String surname) {
> this.name = name;
> this.surname = surname;
> }
> @Override
> public String toString() {
> return "Person2 [name=" + name + ", surname=" + surname + "]";
> }
> }
> }
> {code}
> Stack Trace:
> {code}
> Exception in thread "main" java.lang.IllegalStateException: Unknown entity name com.gustavonalle.infinispan.perf.config.Test.Person
> at org.infinispan.objectfilter.impl.hql.FilterQueryResolverDelegate.registerPersisterSpace(FilterQueryResolverDelegate.java:52)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.entityName(GeneratedHQLResolver.java:12784)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.persisterSpaceRoot(GeneratedHQLResolver.java:3064)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.persisterSpace(GeneratedHQLResolver.java:2956)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.persisterSpaces(GeneratedHQLResolver.java:2893)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.fromClause(GeneratedHQLResolver.java:2803)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.selectFrom(GeneratedHQLResolver.java:2704)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.querySpec(GeneratedHQLResolver.java:2182)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.queryExpression(GeneratedHQLResolver.java:2106)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.queryStatement(GeneratedHQLResolver.java:1745)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.queryStatementSet(GeneratedHQLResolver.java:1658)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.statement(GeneratedHQLResolver.java:654)
> at org.hibernate.hql.ast.spi.QueryResolverProcessor.process(QueryResolverProcessor.java:52)
> at org.hibernate.hql.QueryParser.parseQuery(QueryParser.java:82)
> at org.infinispan.objectfilter.impl.BaseMatcher.parse(BaseMatcher.java:115)
> at org.infinispan.query.dsl.embedded.impl.QueryEngine.parse(QueryEngine.java:377)
> at org.infinispan.query.dsl.embedded.impl.QueryEngine.buildQuery(QueryEngine.java:81)
> at org.infinispan.query.dsl.embedded.impl.EmbeddedQueryBuilder.build(EmbeddedQueryBuilder.java:30)
> at com.gustavonalle.infinispan.perf.config.Test.main(Test.java:35)
> 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 7 months
[JBoss JIRA] (ISPN-5705) Execution of a Hibrid Query that involves certain specific 'OR' conditions returns incorrect results
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5705?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5705:
-----------------------------------------------
Adrian Nistor <anistor(a)redhat.com> changed the Status of [bug 1258800|https://bugzilla.redhat.com/show_bug.cgi?id=1258800] from NEW to POST
> Execution of a Hibrid Query that involves certain specific 'OR' conditions returns incorrect results
> ----------------------------------------------------------------------------------------------------
>
> Key: ISPN-5705
> URL: https://issues.jboss.org/browse/ISPN-5705
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 8.0.0.Beta3
> Environment: Hibrid Query that includes 'OR' condition fails in certain specific cases
> Reporter: Prashanth Reddy
> Assignee: Adrian Nistor
> Priority: Critical
> Fix For: 8.0.0.Final
>
> Attachments: BooleShannonExpansion.diff
>
>
> The hibrid query, mentioned below produces wrong results, upon execution.
> SELECT p.ID, p.NAME FROM com.testapp.Person p WHERE p.IS_ACTIVE=1 AND (p.CITY='city1' OR p.CITY='city2') AND p.ID>1000
> for the Data:
> ID | NAME | CITY | IS_ACTIVE
> -------------------
> 2001 person1 city1 1
> 2002 person1 city1 1
> 2003 person1 city1 1
> 2004 person1 city1 0
> 2005 person1 city2 1
> 2006 person1 city2 1
> 2007 person1 city3 0
> 2008 person1 city3 1
> Indexed fields: ID, NAME, CITY
> Non-indexed fields: IS_ACTIVE
> Query execution returned 0 number of rows, whereas expected result count is 5.
> After some analysis root cause for the problem has been found, and the details are as follows,
> As a part of separating the query that depends on indexed fields, using boole shannon algorithm, it has first extraced out the condition 'IS_ACTIVE=1' (as it deals with non-indexed fields).
> Assuming four boolean conditions as c1, c2, c3, c4, where c1 represents the condition 'IS_ACTIVE=1'
> f(c1,c2,c3,c4) = c1.f(1, c2, c3, c4) + c1`.f`(0, c2, c3, c4)
> consider
> e1=f(1, c2, c3, c4)
> e2=f`(0, c2, c3, c4)
> which have to be used for constructing the lucene query, for further transformation.
> After splitting as per the above logic, it is trying to optimize the resultant subconditions(e1, e2), so as to reduce the number of conditions to be evaluated. One such optimization that has been found is that when there is a conjuction operation between two comparison predicates dealing with same lvalues(here, same fields), but with the different rvalues(here, constants), it has been optimized to replace it with a contradiction(constant false boolean expression). As we know, this optimization is applicable only for conjuction. But, the same is applied even for the disjuction, which is causing the above mentioned problem.
> For example,
> condition p.CITY='city1' AND p.CITY='city2'
> can be replaced with CONTRADICTION(BooleanConst.FALSE)
> But, the same cannot be done, for
> condition p.CITY='city1' OR p.CITY='city2'
> Following change may correct the problem.
> File: infinispan-8.0.0.Beta3/object-filter/src/main/java/org/infinispan/objectfilter/impl/syntax/BooleShannonExpansion.java:155
> diff:
> @@ -152,7 +152,7 @@
> }
> }
> }
> - PredicateOptimisations.optimizePredicates(newChildren, true);
> + PredicateOptimisations.optimizePredicates(newChildren, false);
> if (newChildren.size() == 1) {
> return newChildren.get(0);
> }
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 7 months
[JBoss JIRA] (ISPN-5710) Unknown entity name when indexing entities defined in inner classes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5710?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-5710:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1258800
Bugzilla Update: Perform
> Unknown entity name when indexing entities defined in inner classes
> -------------------------------------------------------------------
>
> Key: ISPN-5710
> URL: https://issues.jboss.org/browse/ISPN-5710
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 7.2.4.Final, 8.0.0.CR1
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 8.0.0.Final, 7.2.5.Final
>
>
> Reproducer:
> {code}
> import java.util.List;
> import org.hibernate.search.annotations.Analyze;
> import org.hibernate.search.annotations.Field;
> import org.hibernate.search.annotations.Indexed;
> import org.hibernate.search.annotations.Store;
> import org.infinispan.Cache;
> import org.infinispan.configuration.cache.ConfigurationBuilder;
> import org.infinispan.configuration.cache.Index;
> import org.infinispan.manager.DefaultCacheManager;
> import org.infinispan.query.Search;
> import org.infinispan.query.dsl.Query;
> import org.infinispan.query.dsl.QueryFactory;
> public class Test {
> public static void main(String[] args) {
> ConfigurationBuilder builder = new ConfigurationBuilder();
> builder.indexing().index(Index.ALL)
> .addProperty("default.directory_provider", "ram")
> .addProperty("lucene_version", "LUCENE_CURRENT");
> // Construct a simple local cache manager with default configuration
> DefaultCacheManager cacheManager = new DefaultCacheManager(builder.build());
> // Obtain the default cache
> Cache<String, Person> cache = cacheManager.getCache();
> // Store some entries
> cache.put("person1", new Person("William", "Shakespeare"));
> cache.put("person2", new Person("William", "Wordsworth"));
> cache.put("person3", new Person("John", "Milton"));
> // Obtain a query factory for the cache
> QueryFactory<?> queryFactory = Search.getQueryFactory(cache);
> // Construct a query
> Query query = queryFactory.from(Person.class).having("name").eq("William").toBuilder().build();
> // Execute the query
> List<Person> matches = query.list();
> matches.forEach(person -> System.out.printf("Match: %s", person));
> // Stop the cache manager and release all resources
> cacheManager.stop();
> }
> @Indexed
> static class Person {
> @Field(store = Store.YES, analyze = Analyze.NO)
> String name;
> @Field(store = Store.YES, analyze = Analyze.NO, indexNullAs = Field.DEFAULT_NULL_TOKEN)
> String surname;
> public Person(String name, String surname) {
> this.name = name;
> this.surname = surname;
> }
> @Override
> public String toString() {
> return "Person2 [name=" + name + ", surname=" + surname + "]";
> }
> }
> }
> {code}
> Stack Trace:
> {code}
> Exception in thread "main" java.lang.IllegalStateException: Unknown entity name com.gustavonalle.infinispan.perf.config.Test.Person
> at org.infinispan.objectfilter.impl.hql.FilterQueryResolverDelegate.registerPersisterSpace(FilterQueryResolverDelegate.java:52)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.entityName(GeneratedHQLResolver.java:12784)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.persisterSpaceRoot(GeneratedHQLResolver.java:3064)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.persisterSpace(GeneratedHQLResolver.java:2956)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.persisterSpaces(GeneratedHQLResolver.java:2893)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.fromClause(GeneratedHQLResolver.java:2803)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.selectFrom(GeneratedHQLResolver.java:2704)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.querySpec(GeneratedHQLResolver.java:2182)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.queryExpression(GeneratedHQLResolver.java:2106)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.queryStatement(GeneratedHQLResolver.java:1745)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.queryStatementSet(GeneratedHQLResolver.java:1658)
> at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.statement(GeneratedHQLResolver.java:654)
> at org.hibernate.hql.ast.spi.QueryResolverProcessor.process(QueryResolverProcessor.java:52)
> at org.hibernate.hql.QueryParser.parseQuery(QueryParser.java:82)
> at org.infinispan.objectfilter.impl.BaseMatcher.parse(BaseMatcher.java:115)
> at org.infinispan.query.dsl.embedded.impl.QueryEngine.parse(QueryEngine.java:377)
> at org.infinispan.query.dsl.embedded.impl.QueryEngine.buildQuery(QueryEngine.java:81)
> at org.infinispan.query.dsl.embedded.impl.EmbeddedQueryBuilder.build(EmbeddedQueryBuilder.java:30)
> at com.gustavonalle.infinispan.perf.config.Test.main(Test.java:35)
> 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 7 months
[JBoss JIRA] (ISPN-5705) Execution of a Hibrid Query that involves certain specific 'OR' conditions returns incorrect results
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5705?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-5705:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1258800
Bugzilla Update: Perform
> Execution of a Hibrid Query that involves certain specific 'OR' conditions returns incorrect results
> ----------------------------------------------------------------------------------------------------
>
> Key: ISPN-5705
> URL: https://issues.jboss.org/browse/ISPN-5705
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 8.0.0.Beta3
> Environment: Hibrid Query that includes 'OR' condition fails in certain specific cases
> Reporter: Prashanth Reddy
> Assignee: Adrian Nistor
> Priority: Critical
> Fix For: 8.0.0.Final
>
> Attachments: BooleShannonExpansion.diff
>
>
> The hibrid query, mentioned below produces wrong results, upon execution.
> SELECT p.ID, p.NAME FROM com.testapp.Person p WHERE p.IS_ACTIVE=1 AND (p.CITY='city1' OR p.CITY='city2') AND p.ID>1000
> for the Data:
> ID | NAME | CITY | IS_ACTIVE
> -------------------
> 2001 person1 city1 1
> 2002 person1 city1 1
> 2003 person1 city1 1
> 2004 person1 city1 0
> 2005 person1 city2 1
> 2006 person1 city2 1
> 2007 person1 city3 0
> 2008 person1 city3 1
> Indexed fields: ID, NAME, CITY
> Non-indexed fields: IS_ACTIVE
> Query execution returned 0 number of rows, whereas expected result count is 5.
> After some analysis root cause for the problem has been found, and the details are as follows,
> As a part of separating the query that depends on indexed fields, using boole shannon algorithm, it has first extraced out the condition 'IS_ACTIVE=1' (as it deals with non-indexed fields).
> Assuming four boolean conditions as c1, c2, c3, c4, where c1 represents the condition 'IS_ACTIVE=1'
> f(c1,c2,c3,c4) = c1.f(1, c2, c3, c4) + c1`.f`(0, c2, c3, c4)
> consider
> e1=f(1, c2, c3, c4)
> e2=f`(0, c2, c3, c4)
> which have to be used for constructing the lucene query, for further transformation.
> After splitting as per the above logic, it is trying to optimize the resultant subconditions(e1, e2), so as to reduce the number of conditions to be evaluated. One such optimization that has been found is that when there is a conjuction operation between two comparison predicates dealing with same lvalues(here, same fields), but with the different rvalues(here, constants), it has been optimized to replace it with a contradiction(constant false boolean expression). As we know, this optimization is applicable only for conjuction. But, the same is applied even for the disjuction, which is causing the above mentioned problem.
> For example,
> condition p.CITY='city1' AND p.CITY='city2'
> can be replaced with CONTRADICTION(BooleanConst.FALSE)
> But, the same cannot be done, for
> condition p.CITY='city1' OR p.CITY='city2'
> Following change may correct the problem.
> File: infinispan-8.0.0.Beta3/object-filter/src/main/java/org/infinispan/objectfilter/impl/syntax/BooleShannonExpansion.java:155
> diff:
> @@ -152,7 +152,7 @@
> }
> }
> }
> - PredicateOptimisations.optimizePredicates(newChildren, true);
> + PredicateOptimisations.optimizePredicates(newChildren, false);
> if (newChildren.size() == 1) {
> return newChildren.get(0);
> }
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 7 months
[JBoss JIRA] (ISPN-4777) Replace command not atomic in REPL_SYNC cache mode
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-4777?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-4777:
------------------------------------
Affects Version/s: 5.2.6.Final
> Replace command not atomic in REPL_SYNC cache mode
> --------------------------------------------------
>
> Key: ISPN-4777
> URL: https://issues.jboss.org/browse/ISPN-4777
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.6.Final
> Reporter: Anuj Shah
> Assignee: Gustavo Fernandes
> Attachments: ReaderLockerTest.java
>
>
> This problem was discovered using the Lucene InfinispanDirectory with DistributedSegmentReadLocker. We found after a while of production usage that some Lucene files were randomly removed from the caches, but remained in the file listing entry, which resulted in an unusable index.
> We managed to replicate the problem in a test that acquires and releases read lock concurrently and checks for file deletion. We found this fails quickly when using REPL_SYNC mode, but runs for a while with DIST_SYNC.
> Some extra logging indicated that the replace command used to increment the lock counter across multiple cluster members, results in an single increment when called concurrently, with both calls reporting success. This eventually causes the file deletion, as we have now mis-counted the number of readers. We also observed the opposite effect of the counter only decrementing by one when releasing.
> Our conclusion is that the replace command fails atomicity when in REPL_SYNC mode, but works in other modes, we tried DIST_SYNC, DIST_ASYNC and REPL_ASYNC.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 7 months
[JBoss JIRA] (ISPN-4777) Replace command not atomic in REPL_SYNC cache mode
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-4777?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-4777:
------------------------------------
Affects Version/s: (was: 7.2.4.Final)
> Replace command not atomic in REPL_SYNC cache mode
> --------------------------------------------------
>
> Key: ISPN-4777
> URL: https://issues.jboss.org/browse/ISPN-4777
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.6.Final
> Reporter: Anuj Shah
> Assignee: Gustavo Fernandes
> Attachments: ReaderLockerTest.java
>
>
> This problem was discovered using the Lucene InfinispanDirectory with DistributedSegmentReadLocker. We found after a while of production usage that some Lucene files were randomly removed from the caches, but remained in the file listing entry, which resulted in an unusable index.
> We managed to replicate the problem in a test that acquires and releases read lock concurrently and checks for file deletion. We found this fails quickly when using REPL_SYNC mode, but runs for a while with DIST_SYNC.
> Some extra logging indicated that the replace command used to increment the lock counter across multiple cluster members, results in an single increment when called concurrently, with both calls reporting success. This eventually causes the file deletion, as we have now mis-counted the number of readers. We also observed the opposite effect of the counter only decrementing by one when releasing.
> Our conclusion is that the replace command fails atomicity when in REPL_SYNC mode, but works in other modes, we tried DIST_SYNC, DIST_ASYNC and REPL_ASYNC.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 7 months
[JBoss JIRA] (ISPN-4777) Replace command not atomic in REPL_SYNC cache mode
by Anuj Shah (JIRA)
[ https://issues.jboss.org/browse/ISPN-4777?page=com.atlassian.jira.plugin.... ]
Anuj Shah commented on ISPN-4777:
---------------------------------
[~gustavofersan], I think you're right, this doesn't seem to be a problem in 7.2.x, I didn't spot the change the {{DistributedSegmentReadLocker}} to use {{isMultiChunked}}.
Still an issue on 5.2.6, but happy for this bug to be resolved.
> Replace command not atomic in REPL_SYNC cache mode
> --------------------------------------------------
>
> Key: ISPN-4777
> URL: https://issues.jboss.org/browse/ISPN-4777
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 7.2.4.Final
> Reporter: Anuj Shah
> Assignee: Gustavo Fernandes
> Attachments: ReaderLockerTest.java
>
>
> This problem was discovered using the Lucene InfinispanDirectory with DistributedSegmentReadLocker. We found after a while of production usage that some Lucene files were randomly removed from the caches, but remained in the file listing entry, which resulted in an unusable index.
> We managed to replicate the problem in a test that acquires and releases read lock concurrently and checks for file deletion. We found this fails quickly when using REPL_SYNC mode, but runs for a while with DIST_SYNC.
> Some extra logging indicated that the replace command used to increment the lock counter across multiple cluster members, results in an single increment when called concurrently, with both calls reporting success. This eventually causes the file deletion, as we have now mis-counted the number of readers. We also observed the opposite effect of the counter only decrementing by one when releasing.
> Our conclusion is that the replace command fails atomicity when in REPL_SYNC mode, but works in other modes, we tried DIST_SYNC, DIST_ASYNC and REPL_ASYNC.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 7 months