[
https://issues.apache.org/jira/browse/IGNITE-11296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Kamyshnikov updated IGNITE-11296:
--------------------------------------
Description:
1) run 2 ignite servers on different machines
(this is important because of
org.apache.ignite.internal.processors.cache.GridCacheContext#selectAffinityNodeBalanced
- it takes into account MACs)
the cache under test should be partitioned with backups = 1.
2) run cassandra and insert some records into cassandra
3) connect to the ignite cluster as Ignite client node and invoke
IgniteCache.get(pk);
for the existing pk. This will load data into caches.
4) execute IgniteCache.withSkipStore().get(pk) several times
The values returned will be randomly NULLs or non-NULLs.
5) depending on a chance, the data loaded in 3) can appear in primary partition
or backup partition. If they are in backup partition, then they are not visible
to Ignite JDBC.
Various techniques with ignite.affinity.mapKeyToPrimaryAndBackups and
{noformat}ignite.compute.call(() -> { cache.localPeek }){noformat} prove that
either backup partition or primary partition does not contain data after p. 3).
However, cache.loadCache(null) loads all the data in both primary and backup
partitions.
Self describing demo code added: [^PrimaryBackupTest.java] :
1) create nodes with different MACs
2) create a test cache <Integer,Integer> with a number of backup partitions
3) implicitely load several keys, making sure we found all the keys that have
at least one empty partition after implicit load.
4) test other partterns of putting keys
5) test SQL and gets with skip store for implicitely loaded keys, making sure
that both nulls and not nulls are returned.
was:
1) run 2 ignite servers on different machines
(this is important because of
org.apache.ignite.internal.processors.cache.GridCacheContext#selectAffinityNodeBalanced
- it takes into account MACs)
the cache under test should be partitioned with backups = 1.
2) run cassandra and insert some records into cassandra
3) connect to the ignite cluster as Ignite client node and invoke
IgniteCache.get(pk);
for the existing pk. This will load data into caches.
4) execute IgniteCache.withSkipStore().get(pk) several times
The values returned will be randomly NULLs or non-NULLs.
5) depending on a chance, the data loaded in 3) can appear in primary partition
or backup partition. If they are in backup partition, then they are not visible
to Ignite JDBC.
Various techniques with ignite.affinity.mapKeyToPrimaryAndBackups and
{noformat}ignite.compute.call(() -> { cache.localPeek }){noformat} prove that
either backup partition or primary partition does not contain data after p. 3).
However, cache.loadCache(null) loads all the data in both primary and backup
partitions.
Self describing demo code added: [^PrimaryBackupTest.java] :
1) create nodes with different MACs
2) create a test cache <Integer,Integer> with a number of backup partitions
3) implicitely load several keys, making sure we found all the keys that have
at least one empty partition after implicit load.
> 3rd-party persistence: Backup and primary partitions data differ after a
> single IgniteCache.get that loaded data from the persistent store which
> breaks skipStore and Ignite JDBC behavior
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: IGNITE-11296
> URL: https://issues.apache.org/jira/browse/IGNITE-11296
> Project: Ignite
> Issue Type: Bug
> Components: cache, cassandra
> Affects Versions: 2.5, 2.7
> Reporter: Igor Kamyshnikov
> Priority: Major
> Attachments: PrimaryBackupTest.java
>
>
> 1) run 2 ignite servers on different machines
> (this is important because of
> org.apache.ignite.internal.processors.cache.GridCacheContext#selectAffinityNodeBalanced
> - it takes into account MACs)
> the cache under test should be partitioned with backups = 1.
> 2) run cassandra and insert some records into cassandra
> 3) connect to the ignite cluster as Ignite client node and invoke
> IgniteCache.get(pk);
> for the existing pk. This will load data into caches.
> 4) execute IgniteCache.withSkipStore().get(pk) several times
> The values returned will be randomly NULLs or non-NULLs.
> 5) depending on a chance, the data loaded in 3) can appear in primary
> partition or backup partition. If they are in backup partition, then they are
> not visible to Ignite JDBC.
> Various techniques with ignite.affinity.mapKeyToPrimaryAndBackups and
> {noformat}ignite.compute.call(() -> { cache.localPeek }){noformat} prove that
> either backup partition or primary partition does not contain data after p.
> 3).
> However, cache.loadCache(null) loads all the data in both primary and backup
> partitions.
> Self describing demo code added: [^PrimaryBackupTest.java] :
> 1) create nodes with different MACs
> 2) create a test cache <Integer,Integer> with a number of backup partitions
> 3) implicitely load several keys, making sure we found all the keys that have
> at least one empty partition after implicit load.
> 4) test other partterns of putting keys
> 5) test SQL and gets with skip store for implicitely loaded keys, making sure
> that both nulls and not nulls are returned.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
