[JBoss JIRA] (ISPN-5707) Eviction/Invalidation notficiations are shown as remove in a tx cache
by William Burns (JIRA)
William Burns created ISPN-5707:
-----------------------------------
Summary: Eviction/Invalidation notficiations are shown as remove in a tx cache
Key: ISPN-5707
URL: https://issues.jboss.org/browse/ISPN-5707
Project: Infinispan
Issue Type: Bug
Components: Listeners
Affects Versions: 8.0.0.CR1
Reporter: William Burns
Currently in notifyCommitEntry of ClusterDependentLogic we do the following:
{code}
if (command instanceof RemoveCommand) {
((RemoveCommand)command).notify(ctx, previousValue, previousMetadata, false);
} else {
notifier.notifyCacheEntryRemoved(
entry.getKey(), previousValue, previousMetadata, false, ctx, command);
}
{code}
The problem is in a tx cache we don't pass along a command, since it is done in a batch. This means it always logs the notification as a removed event instead.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (ISPN-5685) Filtering doesn't work with sum aggregation
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5685?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5685:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1257325|https://bugzilla.redhat.com/show_bug.cgi?id=1257325] from POST to MODIFIED
> Filtering doesn't work with sum aggregation
> -------------------------------------------
>
> Key: ISPN-5685
> URL: https://issues.jboss.org/browse/ISPN-5685
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 8.0.0.Beta3
> Reporter: Jakub Markos
> Assignee: Adrian Nistor
> Fix For: 8.0.0.Final
>
>
> The following query
> {code}
> public void testGroupBy() {
> QueryFactory qf = getQueryFactory();
> Query q = qf.from(getModelFactory().getTransactionImplClass())
> .select(Expression.property("accountId"), Expression.sum("amount"))
> .groupBy("accountId")
> .having(Expression.sum("amount")).gt(3324)
> .toBuilder().build();
> }
> {code}
> in the context of QueryDslConditionsTest test class fails with:
> {code}
> java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Double
> at java.lang.Double.compareTo(Double.java:49)
> at org.infinispan.objectfilter.impl.util.Interval.contains(Interval.java:92)
> at org.infinispan.objectfilter.impl.predicateindex.IntervalCondition.match(IntervalCondition.java:19)
> at org.infinispan.objectfilter.impl.predicateindex.IntervalCondition.match(IntervalCondition.java:9)
> at org.infinispan.objectfilter.impl.predicateindex.Predicate.match(Predicate.java:37)
> at org.infinispan.objectfilter.impl.predicateindex.Predicates.notifyMatchingSubscribers(Predicates.java:118)
> at org.infinispan.objectfilter.impl.predicateindex.AttributeNode.processValue(AttributeNode.java:112)
> at org.infinispan.objectfilter.impl.predicateindex.RowMatcherEvalContext.processAttributes(RowMatcherEvalContext.java:30)
> at org.infinispan.objectfilter.impl.predicateindex.MatcherEvalContext.process(MatcherEvalContext.java:120)
> at org.infinispan.objectfilter.impl.ObjectFilterImpl.filter(ObjectFilterImpl.java:73)
> at org.infinispan.query.dsl.embedded.impl.HybridQuery$1.update(HybridQuery.java:75)
> at org.infinispan.query.dsl.embedded.impl.HybridQuery$1.hasNext(HybridQuery.java:56)
> at org.infinispan.query.dsl.embedded.impl.BaseEmbeddedQuery.listInternal(BaseEmbeddedQuery.java:72)
> at org.infinispan.query.dsl.embedded.impl.BaseEmbeddedQuery.list(BaseEmbeddedQuery.java:63)
> at org.infinispan.query.dsl.embedded.QueryDslConditionsTest.testGroupBy(QueryDslConditionsTest.java:1811)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 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 edited comment on ISPN-4777 at 8/27/15 8:58 AM:
------------------------------------------------------------------
Hi Anuj, thanks for providing the testcase!
Unfortunately I found an issue with the supplied test: it basically uses a {{DistributedSegmentReadLocker}} to acquire a lock in a file that has size 0 and bufferSize 10, and after that uses the same {{DistributedSegmentReadLocker}} to release this lock. The trouble is that path is never really followed during normal Lucene Directory execution, since the file having size 0 is less than the buffer size of 10, so it is not eligible to be broken into chunks: so no read lock will be ever acquired/released.
But since the test does artificially acquires the lock, when the call to {{deleteOrReleaseReadLock()}} happens, the Lucene directory will ALWAYS delete it because the file is single chunked, and the test always fail regardless of REPL/DIST single/multiple threads.
Anyway, I pushed an updated test at https://github.com/gustavonalle/infinispan/commit/e6a2ccd93fc60250d3a5149... on top of 7.2.x branch and been trying to reproduce the issue with it.
was (Author: gustavonalle):
Hi Anuj, thanks for providing the testcase!
Unfortunately I found an issue with the supplied test: it basically uses a {{DistributedSegmentReadLocker}} to acquire a lock in a file that has size 0 and bufferSize 10, and after that uses the same {{DistributedSegmentReadLocker}} to release this lock. The trouble is that path is never really followed during normal Lucene Directory execution, since the file having size 0 is less than the buffer size of 10, so it is not eligible to be broken into chunks: so no read lock will be ever acquired/released.
But since the test does artificially acquires the lock, when the call to {{deleteOrReleaseReadLock()}} happens, the Lucene directory will ALWAYS delete it because the file is single chunked,
and the test always fail regardless of REPL/DIST single/multiple threads.
Anyway, I pushed an updated test at https://github.com/gustavonalle/infinispan/commit/e6a2ccd93fc60250d3a5149... on top of 7.2.x branch and been trying to reproduce the issue with it.
> 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, 10 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 commented on ISPN-4777:
-----------------------------------------
Hi Anuj, thanks for providing the testcase!
Unfortunately I found an issue with the supplied test: it basically uses a {{DistributedSegmentReadLocker}} to acquire a lock in a file that has size 0 and bufferSize 10, and after that uses the same {{DistributedSegmentReadLocker}} to release this lock. The trouble is that path is never really followed during normal Lucene Directory execution, since the file having size 0 is less than the buffer size of 10, so it is not eligible to be broken into chunks: so no read lock will be ever acquired/released.
But since the test does artificially acquires the lock, when the call to {{deleteOrReleaseReadLock()}} happens, the Lucene directory will ALWAYS delete it because the file is single chunked,
and the test always fail regardless of REPL/DIST single/multiple threads.
Anyway, I pushed an updated test at https://github.com/gustavonalle/infinispan/commit/e6a2ccd93fc60250d3a5149... on top of 7.2.x branch and been trying to reproduce the issue with it.
> 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, 10 months
[JBoss JIRA] (ISPN-5524) Race condition in SemaphoreCompletionService.executeFront()
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5524?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5524:
-----------------------------------------------
Vitalii Chepeliuk <vchepeli(a)redhat.com> changed the Status of [bug 1229181|https://bugzilla.redhat.com/show_bug.cgi?id=1229181] from ON_QA to VERIFIED
> Race condition in SemaphoreCompletionService.executeFront()
> -----------------------------------------------------------
>
> Key: ISPN-5524
> URL: https://issues.jboss.org/browse/ISPN-5524
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.2.2.Final, 8.0.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Blocker
> Labels: testsuite_stability
> Fix For: 8.0.0.Alpha2, 7.2.3.Final, 8.0.0.Final
>
>
> If two threads call {{executeFront()}} at the same time, it's possible that none of them executes any task, although there are permits available, and one of the threads just added a task in the queue. This scenario causes random initial state transfer timeouts in the testsuite:
> # T1: continueTaskInBackground(): queue = empty, permits = 0
> # T1: backgroundTaskFinished()
> # T1: = semaphore.release(): queue = empty, permits = 1
> # T1: = executeFront()
> # T1: == semaphore.acquire() -> true: queue = empty, permits = 0
> # T2: == queue.poll() -> null
> # T2: submit(task)
> # T2: = executeFront()
> # T2: == semaphore.acquire() -> false
> # T2: return without executing any task
> # T1: return without executing any task
> Failure example: http://ci.infinispan.org/viewLog.html?buildId=27153&tab=buildResultsDiv&b...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (ISPN-5704) Enhancements for Functional Map API
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5704?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-5704:
-----------------------------------
Description:
List of enhancements that didn't make it into 8.0:
* Transaction support.
* Verify locks are acquired for all operations (once tx is in place, locks can be checked easily)
* Complete persistence support (remove many returning previous, put many returning previous, remove many)
* Replication of per-invocation parameters.
* Port mode *Becoming*Test to functional APIs, and expand on testing other functional APIs.
* Test interoperability with cache, e.g. cache put with lifespan can be retrieved via functional map with lifespan, and viceversa
* Test compatibility mode
* Add more listener events: activation, passivation and expiration.
* Use check isLocal instead of `e == null` in command impls
* Fix branch skip issue (see previous PR: https://github.com/infinispan/infinispan/pull/3571)
* Add externalizers for primitive versions of Optional.
was:
List of enhancements that didn't make it into 8.0:
* Transaction support.
* Verify locks are acquired for all operations (once tx is in place, locks can be checked easily)
* Complete persistence support (remove many returning previous, put many returning previous, remove many)
* Replication of per-invocation parameters.
* Port mode *Becoming*Test to functional APIs, and expand on testing other functional APIs.
* Test interoperability with cache, e.g. cache put with lifespan can be retrieved via functional map with lifespan, and viceversa
* Test compatibility mode
> Enhancements for Functional Map API
> -----------------------------------
>
> Key: ISPN-5704
> URL: https://issues.jboss.org/browse/ISPN-5704
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 8.1.0.Final
>
>
> List of enhancements that didn't make it into 8.0:
> * Transaction support.
> * Verify locks are acquired for all operations (once tx is in place, locks can be checked easily)
> * Complete persistence support (remove many returning previous, put many returning previous, remove many)
> * Replication of per-invocation parameters.
> * Port mode *Becoming*Test to functional APIs, and expand on testing other functional APIs.
> * Test interoperability with cache, e.g. cache put with lifespan can be retrieved via functional map with lifespan, and viceversa
> * Test compatibility mode
> * Add more listener events: activation, passivation and expiration.
> * Use check isLocal instead of `e == null` in command impls
> * Fix branch skip issue (see previous PR: https://github.com/infinispan/infinispan/pull/3571)
> * Add externalizers for primitive versions of Optional.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (ISPN-5704) Enhancements for Functional Map API
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5704?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-5704:
-----------------------------------
Description:
List of enhancements that didn't make it into 8.0:
* Transaction support.
* Complete persistence support (remove many returning previous, put many returning previous, remove many)
* Replication of per-invocation parameters.
* Port mode *Becoming*Test to functional APIs, and expand on testing other functional APIs.
* Test interoperability with cache, e.g. cache put with lifespan can be retrieved via functional map with lifespan, and viceversa
* Test compatibility mode
was:
List of enhancements that didn't make it into 8.0:
* Transaction support.
* Complete persistence support (remove many returning previous, put many returning previous, remove many)
* Replication of per-invocation parameters.
* Port mode *Becoming*Test to functional APIs, and expand on testing other functional APIs.
> Enhancements for Functional Map API
> -----------------------------------
>
> Key: ISPN-5704
> URL: https://issues.jboss.org/browse/ISPN-5704
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 8.1.0.Final
>
>
> List of enhancements that didn't make it into 8.0:
> * Transaction support.
> * Complete persistence support (remove many returning previous, put many returning previous, remove many)
> * Replication of per-invocation parameters.
> * Port mode *Becoming*Test to functional APIs, and expand on testing other functional APIs.
> * Test interoperability with cache, e.g. cache put with lifespan can be retrieved via functional map with lifespan, and viceversa
> * Test compatibility mode
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (ISPN-5704) Enhancements for Functional Map API
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5704?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-5704:
-----------------------------------
Description:
List of enhancements that didn't make it into 8.0:
* Transaction support.
* Verify locks are acquired for all operations (once tx is in place, locks can be checked easily)
* Complete persistence support (remove many returning previous, put many returning previous, remove many)
* Replication of per-invocation parameters.
* Port mode *Becoming*Test to functional APIs, and expand on testing other functional APIs.
* Test interoperability with cache, e.g. cache put with lifespan can be retrieved via functional map with lifespan, and viceversa
* Test compatibility mode
was:
List of enhancements that didn't make it into 8.0:
* Transaction support.
* Complete persistence support (remove many returning previous, put many returning previous, remove many)
* Replication of per-invocation parameters.
* Port mode *Becoming*Test to functional APIs, and expand on testing other functional APIs.
* Test interoperability with cache, e.g. cache put with lifespan can be retrieved via functional map with lifespan, and viceversa
* Test compatibility mode
> Enhancements for Functional Map API
> -----------------------------------
>
> Key: ISPN-5704
> URL: https://issues.jboss.org/browse/ISPN-5704
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 8.1.0.Final
>
>
> List of enhancements that didn't make it into 8.0:
> * Transaction support.
> * Verify locks are acquired for all operations (once tx is in place, locks can be checked easily)
> * Complete persistence support (remove many returning previous, put many returning previous, remove many)
> * Replication of per-invocation parameters.
> * Port mode *Becoming*Test to functional APIs, and expand on testing other functional APIs.
> * Test interoperability with cache, e.g. cache put with lifespan can be retrieved via functional map with lifespan, and viceversa
> * Test compatibility mode
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months