ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Igor Kamyshnikov (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (IGNITE-11296) 3rd-party persistence: Backup and primary partitions data differ after a single IgniteCache.get that loaded data from the persistent store which breaks skipStore behavior
Date Tue, 12 Feb 2019 11:22:00 GMT

     [ 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 ignite.compute.call(()
-> { cache.localPeek }) prove that either backup partition or primary partition does not
contain data after p. 3).

  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)

2) run cassandra and insert some records into cassandra

3) connect to the ignite cluster as Ignite client node and invoke
IgniteCache.get(pk);

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.


> 3rd-party persistence: Backup and primary partitions data differ after a single IgniteCache.get
that loaded data from the persistent store which breaks skipStore 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
>
> 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 ignite.compute.call(()
-> { cache.localPeek }) prove that either backup partition or primary partition does not
contain data after p. 3).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message