[JBoss JIRA] (ISPN-7988) ScatteredSyncFuncTest>DistSyncFuncTest.testComputeIfAbsentFromNonOwner fails with trace logging enabled
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-7988?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-7988:
-----------------------------------
Fixes seem to be simple, but I wonder how could the tests pass without trace logging...
> ScatteredSyncFuncTest>DistSyncFuncTest.testComputeIfAbsentFromNonOwner fails with trace logging enabled
> -------------------------------------------------------------------------------------------------------
>
> Key: ISPN-7988
> URL: https://issues.jboss.org/browse/ISPN-7988
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Reporter: Dan Berindei
> Assignee: Radim Vansa
> Priority: Critical
> Labels: testsuite_stability
>
> Every time I run the test I get this failure twice, with the same test parameters:
> {noformat}
> testComputeIfAbsentFromNonOwner[SCATTERED_SYNC, tx=false, numOwners=1, l1=false](org.infinispan.scattered.ScatteredSyncFuncTest) Time elapsed: 0.159 sec <<< FAILURE!
> java.lang.AssertionError: expected [1] but found [0]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertEquals(Assert.java:123)
> at org.testng.Assert.assertEquals(Assert.java:370)
> at org.testng.Assert.assertEquals(Assert.java:380)
> at org.infinispan.scattered.Utils.assertOwnershipAndNonOwnership(Utils.java:49)
> at org.infinispan.scattered.ScatteredSyncFuncTest.assertOwnershipAndNonOwnership(ScatteredSyncFuncTest.java:20)
> at org.infinispan.distribution.BaseDistFunctionalTest.assertOnAllCachesAndOwnership(BaseDistFunctionalTest.java:162)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (ISPN-7990) Provide a way to remove an entry from all indexes
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-7990?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-7990:
-------------------------------------
I agree with [~gustavonalle], QueryKnownClasses should give you all the types used in this Cache. Knowing the precise type of the value mapped to key K is still not possible, but at least we have narrowed it down to a short list and instead of deleting from all indexes we'll need to delete just from some.
And the good news is by Infinispan 9.2 QueryKnownClasses will also become immutable (declared upfront).
ATM QueryKnownClasses still allows a deprecated autodetection mode (besides declaration in config). There were some technical difficulties in server that we are closed to solving now, and the autodetection can be finally removed in ispn 9.2 and QueryKnownClasses will become a fully immutable list, declared upfront in config, making things much simpler.
> Provide a way to remove an entry from all indexes
> -------------------------------------------------
>
> Key: ISPN-7990
> URL: https://issues.jboss.org/browse/ISPN-7990
> Project: Infinispan
> Issue Type: Enhancement
> Components: Embedded Querying
> Affects Versions: 9.1.0.Beta1
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
>
> This may be needed in some non frequent scenarios (happening during topology changes) where a write command cannot obtain the previous value to remove it from the index.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (ISPN-7990) Provide a way to remove an entry from all indexes
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-7990?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes commented on ISPN-7990:
-----------------------------------------
bq. you won't know which indexes need to be cleaned up
That's the issue this JIRA is trying to address. As I found out recently, there are some corner cases (considered rare, during state transfer) where it's not possible to know the type.
bq. even cleaning up "all indexes" by id is troublesome as you might not have a full list to define "all indexes"
I assume the QueryKnownClasses object would have all types stored? If not, doesn't the searchFactory know about all existent indexes?
bq. without the type you don't know how to encode the key -> not matching the right key might lead to various mismatches, like delete the wrong data or not deleting it at all
The key encoding is done by the KeyTransformationHandler which is cache-scoped; so I assume the id is consistent across all indexes.
bq. what if the index was created by an instance having a different / out of date configuration
How this could happen? I have a feeling if clusters have caches with outdated configurations indexing would not be the only problem
> Provide a way to remove an entry from all indexes
> -------------------------------------------------
>
> Key: ISPN-7990
> URL: https://issues.jboss.org/browse/ISPN-7990
> Project: Infinispan
> Issue Type: Enhancement
> Components: Embedded Querying
> Affects Versions: 9.1.0.Beta1
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
>
> This may be needed in some non frequent scenarios (happening during topology changes) where a write command cannot obtain the previous value to remove it from the index.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (ISPN-7990) Provide a way to remove an entry from all indexes
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-7990?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero edited comment on ISPN-7990 at 6/28/17 7:01 AM:
----------------------------------------------------------------
Remember that if you don't know the type this is problematic:
* you won't know which indexes need to be cleaned up (can't match the sharding strategy)
* even cleaning up "all indexes" by id is troublesome as you might not have a full list to define "all indexes"
* without the type you don't know how to encode the key -> not matching the right key might lead to various mismatches, like delete the wrong data or not deleting it at all
The only safe solution I see is to know upfront which types might be used in this Cache; even so, what if the index was created by an instance having a different / out of date configuration ?
was (Author: sannegrinovero):
Remember that if you don't know the type this is problematic:
* you won't know which indexes need to be cleaned up
* even cleaning up "all indexes" by id is troublesome as you might not have a full list to define "all indexes"
* without the type you don't know how to encode the key -> not matching the right key might lead to various mismatches, like delete the wrong data or not deleting it at all
The only safe solution I see is to know upfront which types might be used in this Cache; even so, what if the index was created by an instance having a different / out of date configuration ?
> Provide a way to remove an entry from all indexes
> -------------------------------------------------
>
> Key: ISPN-7990
> URL: https://issues.jboss.org/browse/ISPN-7990
> Project: Infinispan
> Issue Type: Enhancement
> Components: Embedded Querying
> Affects Versions: 9.1.0.Beta1
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
>
> This may be needed in some non frequent scenarios (happening during topology changes) where a write command cannot obtain the previous value to remove it from the index.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months