[jira] [Commented] (IGNITE-9878) Failed to start near cache after second call of getOrCreateCache
[
https://issues.apache.org/jira/browse/IGNITE-9878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844456#comment-16844456
]
Roman Guseinov commented on IGNITE-9878:
[~vkulichenko], thanks for your comment.
I believe it should work like `IgniteCache
getOrCreateCache(CacheConfiguration cacheCfg)`. You can call this method
with the same cacheCfg multiple times without any errors.
If you try to do the same with `IgniteCache
getOrCreateCache(CacheConfiguration cacheCfg, NearCacheConfiguration nearCfg)` the first call will be successful, but the second one will fail.
Does it look correct to you? Why Ignite should throw an exception instead of
returning the same results (like for the first call)?
> Failed to start near cache after second call of getOrCreateCache
>
>
> Key: IGNITE-9878
> URL: https://issues.apache.org/jira/browse/IGNITE-9878
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
> Attachments: NearCacheIssueReproducer.java, NearCacheTest.java
>
>
> Repeated call of `Ignite.getOrCreateCache(CacheConfiguration cacheCfg,
> NearCacheConfiguration nearCfg)` lead the following exception:
> {code:java}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to start near cache (local node is an affinity node for cache):
> ignite-test-near-rep
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2995)
> at
> org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testRepeatedGetOrCreateCache(NearCacheIssueReproducer.java:24)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> near cache (local node is an affinity node for cache): ignite-test-near-rep
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheChangeRequest(GridCacheProcessor.java:5235)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3621)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3560)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2983)
> ... 23 more
> {code}
> Also, if a cache is specified in the IgniteConfiguration,
> `Ignite#getOrCreateNearCache` will fail with the following exception:
> {code:java}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to start near cache (a cache with the same name without near cache is
> already started)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3072)
> at
> org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testGetOrCreateNearCache(NearCacheIssueReproducer.java:32)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> near cache (a cache with the same name without near cache is already started)
> at
> org.apache.ignite.internal.IgniteKernal.checkNearCacheStarted(IgniteKernal.java:3085)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3067)
> ... 23 more
> {code}
> The test is attached [^NearCacheIssueReproducer.java]. The workaround is to
> put near cache config into cache configuration
> `CacheConfiguration.setNearConfiguration`.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10663) Implement cache mode allows reads with consistency check and fix
[
https://issues.apache.org/jira/browse/IGNITE-10663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844211#comment-16844211
]
Ignite TC Bot commented on IGNITE-10663:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET{color} [[tests
8|https://ci.ignite.apache.org/viewLog.html?buildId=3894167]]
* exe: CacheParityTest.TestCache
{color:#d04437}Platform .NET (Core Linux){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3894168]]
* dll: CacheParityTest.TestCache
{color:#d04437}MVCC PDS 4{color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=3894193]]
* IgnitePdsMvccTestSuite4:
IgniteRebalanceOnCachesStoppingOrDestroyingTest.testDestroySpecificCacheAndCacheGroupSecondGroup
* IgnitePdsMvccTestSuite4:
IgniteRebalanceOnCachesStoppingOrDestroyingTest.testStopCachesOnDeactivationSecondGroup
{color:#d04437}[Check Code Style]{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3894195]]
{color:#d04437}Thin client: PHP{color} [[tests 104 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3894131]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3894196buildTypeId=IgniteTests24Java8_RunAll]
> Implement cache mode allows reads with consistency check and fix
>
>
> Key: IGNITE-10663
> URL: https://issues.apache.org/jira/browse/IGNITE-10663
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.8
>
> Time Spent: 10h 10m
> Remaining Estimate: 0h
>
> The main idea is to provide special "read from cache" mode which will read a
> value from primary and all backups and will check that values are the same.
> In case values differ they should be fixed according to the appropriate
> strategy.
> ToDo list:
> 1) {{cache.withConsistency().get(key)}} should guarantee values will be
> checked across the topology and fixed if necessary.
> 2) LWW (Last Write Wins) strategy should be used for validation.
> 3) Since LWW and any other strategy do not guarantee that the correct value
> will be chosen.
> We have to record the event contains all values and the chosen one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10913) Reduce heap occupation by o.a.i.i.processors.cache.persistence.file.FilePageStore instances.
[ https://issues.apache.org/jira/browse/IGNITE-10913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844078#comment-16844078 ] Denis Chudov commented on IGNITE-10913: --- This PR should not be merged to master before passing performance tests. > Reduce heap occupation by > o.a.i.i.processors.cache.persistence.file.FilePageStore instances. > > > Key: IGNITE-10913 > URL: https://issues.apache.org/jira/browse/IGNITE-10913 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Denis Chudov >Priority: Major > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > With large topology and large amount of caches/partitions and enabled > persistence could be millions of FilePageStore objects in heap (for each > partition). > Each instance has a reference to a File (field cfgFile) storing as String > absolute path to a partition. > Also internal File inplementation (on example UnixFile) also allocates space > for file path. > I observed about 2Gb of heap space occupied by these objects in one of > environments. > Solution: dereference (set to null) cfgFile after object creation, create > File object lazily on demand when needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10913) Reduce heap occupation by o.a.i.i.processors.cache.persistence.file.FilePageStore instances.
[ https://issues.apache.org/jira/browse/IGNITE-10913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-10913: Reviewer: Eduard Shangareev > Reduce heap occupation by > o.a.i.i.processors.cache.persistence.file.FilePageStore instances. > > > Key: IGNITE-10913 > URL: https://issues.apache.org/jira/browse/IGNITE-10913 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Denis Chudov >Priority: Major > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > With large topology and large amount of caches/partitions and enabled > persistence could be millions of FilePageStore objects in heap (for each > partition). > Each instance has a reference to a File (field cfgFile) storing as String > absolute path to a partition. > Also internal File inplementation (on example UnixFile) also allocates space > for file path. > I observed about 2Gb of heap space occupied by these objects in one of > environments. > Solution: dereference (set to null) cfgFile after object creation, create > File object lazily on demand when needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9878) Failed to start near cache after second call of getOrCreateCache
[
https://issues.apache.org/jira/browse/IGNITE-9878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844036#comment-16844036
]
Valentin Kulichenko edited comment on IGNITE-9878 at 5/20/19 3:17 PM:
--
I don't think it's a bug, because these exceptions are thrown on a server node.
If you want to have a near cache on server node, you need to define
{{NearCacheConfiguration}} as part of {{CacheConfiguration}}, and not provide
one in {{getOrCreateCache}}.
Said that, behavior looks correct to me, although there is a definite usability
issue. Exceptions have to be clearer, and we might even think about revisiting
this API for future major versions.
was (Author: vkulichenko):
I don't think it's a bug, because these exceptions are thrown on a server node.
If you want to have a near cache on server node, you need to define
`NearCacheConfiguration` as part of `CacheConfiguration`, and not provide one
in `getOrCreateCache`.
Said that, behavior looks correct to me, although there is a definite usability
issue. Exceptions have to be clearer, and we might even think about revisiting
this API for future major versions.
> Failed to start near cache after second call of getOrCreateCache
>
>
> Key: IGNITE-9878
> URL: https://issues.apache.org/jira/browse/IGNITE-9878
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
> Attachments: NearCacheIssueReproducer.java
>
>
> Repeated call of `Ignite.getOrCreateCache(CacheConfiguration cacheCfg,
> NearCacheConfiguration nearCfg)` lead the following exception:
> {code:java}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to start near cache (local node is an affinity node for cache):
> ignite-test-near-rep
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2995)
> at
> org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testRepeatedGetOrCreateCache(NearCacheIssueReproducer.java:24)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> near cache (local node is an affinity node for cache): ignite-test-near-rep
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheChangeRequest(GridCacheProcessor.java:5235)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3621)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3560)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2983)
> ... 23 more
> {code}
> Also, if a cache is specified in the IgniteConfiguration,
> `Ignite#getOrCreateNearCache` will fail with the following exception:
> {code:java}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to start near cache (a cache with the same name without near cache is
> already started)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3072)
> at
> org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testGetOrCreateNearCache(NearCacheIssueReproducer.java:32)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> near cache (a cache with the same name without near cache is already started)
> at
> org.apache.ignite.internal.IgniteKernal.checkNearCacheStarted(IgniteKernal.java:3085)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3067)
> ... 23 more
> {code}
> The test is attached [^NearCacheIssueReproducer.java]. The workaround is to
> put near cache config into cache configuration
> `CacheConfiguration.setNearConfiguration`.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9878) Failed to start near cache after second call of getOrCreateCache
[
https://issues.apache.org/jira/browse/IGNITE-9878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844036#comment-16844036
]
Valentin Kulichenko commented on IGNITE-9878:
-
I don't think it's a bug, because these exceptions are thrown on a server node.
If you want to have a near cache on server node, you need to define
`NearCacheConfiguration` as part of `CacheConfiguration`, and not provide one
in `getOrCreateCache`.
Said that, behavior looks correct to me, although there is a definite usability
issue. Exceptions have to be clearer, and we might even think about revisiting
this API for future major versions.
> Failed to start near cache after second call of getOrCreateCache
>
>
> Key: IGNITE-9878
> URL: https://issues.apache.org/jira/browse/IGNITE-9878
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
> Attachments: NearCacheIssueReproducer.java
>
>
> Repeated call of `Ignite.getOrCreateCache(CacheConfiguration cacheCfg,
> NearCacheConfiguration nearCfg)` lead the following exception:
> {code:java}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to start near cache (local node is an affinity node for cache):
> ignite-test-near-rep
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2995)
> at
> org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testRepeatedGetOrCreateCache(NearCacheIssueReproducer.java:24)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> near cache (local node is an affinity node for cache): ignite-test-near-rep
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheChangeRequest(GridCacheProcessor.java:5235)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3621)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3560)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2983)
> ... 23 more
> {code}
> Also, if a cache is specified in the IgniteConfiguration,
> `Ignite#getOrCreateNearCache` will fail with the following exception:
> {code:java}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to start near cache (a cache with the same name without near cache is
> already started)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3072)
> at
> org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testGetOrCreateNearCache(NearCacheIssueReproducer.java:32)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> near cache (a cache with the same name without near cache is already started)
> at
> org.apache.ignite.internal.IgniteKernal.checkNearCacheStarted(IgniteKernal.java:3085)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3067)
> ... 23 more
> {code}
> The test is attached [^NearCacheIssueReproducer.java]. The workaround is to
> put near cache config into cache configuration
> `CacheConfiguration.setNearConfiguration`.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9878) Failed to start near cache after second call of getOrCreateCache
[
https://issues.apache.org/jira/browse/IGNITE-9878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844043#comment-16844043
]
Valentin Kulichenko commented on IGNITE-9878:
-
Attached another reproducer - {{NearCacheTest.java}}. This looks like a bug.
Basically, I can't create a near cache on a *client* node if cache
configuration is declared as a part of `IgniteConfiguration` on this client.
> Failed to start near cache after second call of getOrCreateCache
>
>
> Key: IGNITE-9878
> URL: https://issues.apache.org/jira/browse/IGNITE-9878
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
> Attachments: NearCacheIssueReproducer.java, NearCacheTest.java
>
>
> Repeated call of `Ignite.getOrCreateCache(CacheConfiguration cacheCfg,
> NearCacheConfiguration nearCfg)` lead the following exception:
> {code:java}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to start near cache (local node is an affinity node for cache):
> ignite-test-near-rep
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2995)
> at
> org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testRepeatedGetOrCreateCache(NearCacheIssueReproducer.java:24)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> near cache (local node is an affinity node for cache): ignite-test-near-rep
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheChangeRequest(GridCacheProcessor.java:5235)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3621)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3560)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2983)
> ... 23 more
> {code}
> Also, if a cache is specified in the IgniteConfiguration,
> `Ignite#getOrCreateNearCache` will fail with the following exception:
> {code:java}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to start near cache (a cache with the same name without near cache is
> already started)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3072)
> at
> org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testGetOrCreateNearCache(NearCacheIssueReproducer.java:32)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> near cache (a cache with the same name without near cache is already started)
> at
> org.apache.ignite.internal.IgniteKernal.checkNearCacheStarted(IgniteKernal.java:3085)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3067)
> ... 23 more
> {code}
> The test is attached [^NearCacheIssueReproducer.java]. The workaround is to
> put near cache config into cache configuration
> `CacheConfiguration.setNearConfiguration`.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9878) Failed to start near cache after second call of getOrCreateCache
[
https://issues.apache.org/jira/browse/IGNITE-9878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-9878:
Attachment: NearCacheTest.java
> Failed to start near cache after second call of getOrCreateCache
>
>
> Key: IGNITE-9878
> URL: https://issues.apache.org/jira/browse/IGNITE-9878
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
> Attachments: NearCacheIssueReproducer.java, NearCacheTest.java
>
>
> Repeated call of `Ignite.getOrCreateCache(CacheConfiguration cacheCfg,
> NearCacheConfiguration nearCfg)` lead the following exception:
> {code:java}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to start near cache (local node is an affinity node for cache):
> ignite-test-near-rep
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2995)
> at
> org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testRepeatedGetOrCreateCache(NearCacheIssueReproducer.java:24)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> near cache (local node is an affinity node for cache): ignite-test-near-rep
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheChangeRequest(GridCacheProcessor.java:5235)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3621)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3560)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2983)
> ... 23 more
> {code}
> Also, if a cache is specified in the IgniteConfiguration,
> `Ignite#getOrCreateNearCache` will fail with the following exception:
> {code:java}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to start near cache (a cache with the same name without near cache is
> already started)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3072)
> at
> org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testGetOrCreateNearCache(NearCacheIssueReproducer.java:32)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> near cache (a cache with the same name without near cache is already started)
> at
> org.apache.ignite.internal.IgniteKernal.checkNearCacheStarted(IgniteKernal.java:3085)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3067)
> ... 23 more
> {code}
> The test is attached [^NearCacheIssueReproducer.java]. The workaround is to
> put near cache config into cache configuration
> `CacheConfiguration.setNearConfiguration`.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11592) NPE in case of continuing tx and cache stop operation.
[
https://issues.apache.org/jira/browse/IGNITE-11592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844012#comment-16844012
]
Pavel Kovalenko commented on IGNITE-11592:
--
[~zstan] It's not clear to understand what is the cause of the problem and what
is the scenario (step-by-step) to get into such a situation.
Could you please fill in the scenario to the ticket description?
> NPE in case of continuing tx and cache stop operation.
> ---
>
> Key: IGNITE-11592
> URL: https://issues.apache.org/jira/browse/IGNITE-11592
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Parallel cache stop and tx operations may lead to NPE.
> {code}
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.CacheObjectImpl.finishUnmarshal(CacheObjectImpl.java:129)
> at
> org.apache.ignite.internal.processors.cache.transactions.TxEntryValueHolder.unmarshal(TxEntryValueHolder.java:151)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxEntry.unmarshal(IgniteTxEntry.java:964)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.unmarshal(IgniteTxHandler.java:306)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:338)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:154)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.lambda$null$0(IgniteTxHandler.java:580)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:496)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> i hope that correct decision would be to roll back tx (on exchange phase)
> participating in stopped caches.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11110) UnsupportedOperationException: null when stopping grid
[
https://issues.apache.org/jira/browse/IGNITE-0?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov updated IGNITE-0:
--
Ignite Flags: (was: Docs Required)
> UnsupportedOperationException: null when stopping grid
> --
>
> Key: IGNITE-0
> URL: https://issues.apache.org/jira/browse/IGNITE-0
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Jens Borgland
>Priority: Major
>
> After upgrading to 2.7 we've started getting these errors when stopping grids:
> {noformat}
> java.lang.UnsupportedOperationException: null
> at
> org.jsr166.ConcurrentLinkedHashMap.clear(ConcurrentLinkedHashMap.java:1551)
> ~[ignite-core-2.7.0.jar:2.7.0]
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.stop(GridJobProcessor.java:264)
> ~[ignite-core-2.7.0.jar:2.7.0]
> at
> org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2356)
> ~[ignite-core-2.7.0.jar:2.7.0]
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2228)
> ~[ignite-core-2.7.0.jar:2.7.0]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2612)
> ~[ignite-core-2.7.0.jar:2.7.0]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2575)
> ~[ignite-core-2.7.0.jar:2.7.0]
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:379)
> ~[ignite-core-2.7.0.jar:2.7.0]
> at org.apache.ignite.Ignition.stop(Ignition.java:225)
> ~[ignite-core-2.7.0.jar:2.7.0]
> at
> org.apache.ignite.internal.IgniteKernal.close(IgniteKernal.java:3568)
> ~[ignite-core-2.7.0.jar:2.7.0]
> {noformat}
> At first glance it looks likely that it was introduced with commit
> [d04d764|https://github.com/apache/ignite/commit/d04d76440ce86873de7aebc8c03d39484cd1e3e5]
> (the {{GridJobProcessor}} still calls {{clear()}} on maps).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11592) NPE in case of continuing tx and cache stop operation.
[
https://issues.apache.org/jira/browse/IGNITE-11592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843955#comment-16843955
]
Eduard Shangareev commented on IGNITE-11592:
I have left some comments.
But I am not sure that we need to fix it. This case should be covered by a new
latch on exchange.
[~Jokser], [~agoncharuk], please, look through, need your expertise.
> NPE in case of continuing tx and cache stop operation.
> ---
>
> Key: IGNITE-11592
> URL: https://issues.apache.org/jira/browse/IGNITE-11592
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Parallel cache stop and tx operations may lead to NPE.
> {code}
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.CacheObjectImpl.finishUnmarshal(CacheObjectImpl.java:129)
> at
> org.apache.ignite.internal.processors.cache.transactions.TxEntryValueHolder.unmarshal(TxEntryValueHolder.java:151)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxEntry.unmarshal(IgniteTxEntry.java:964)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.unmarshal(IgniteTxHandler.java:306)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:338)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:154)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.lambda$null$0(IgniteTxHandler.java:580)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:496)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> i hope that correct decision would be to roll back tx (on exchange phase)
> participating in stopped caches.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11855) Need to reduce log message in case: Topology projection is empty. Cluster group is empty.
[
https://issues.apache.org/jira/browse/IGNITE-11855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-11855:
--
Reviewer: Ivan Rakov
> Need to reduce log message in case: Topology projection is empty. Cluster
> group is empty.
> -
>
> Key: IGNITE-11855
> URL: https://issues.apache.org/jira/browse/IGNITE-11855
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In some cases - there is a lot of stack trace in logs
> {code:java}
> [18:53:00,811][SEVERE][grid-timeout-worker-#39][diagnostic] Could not get
> thread dump from transaction owner near node:
> class org.apache.ignite.cluster.ClusterGroupEmptyException: Cluster group is
> empty.
> at org.apache.ignite.internal.util.IgniteUtils$6.apply(IgniteUtils.java:853)
> at org.apache.ignite.internal.util.IgniteUtils$6.apply(IgniteUtils.java:851)
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:991)
> at
> org.apache.ignite.internal.util.future.IgniteFutureImpl.convertException(IgniteFutureImpl.java:168)
> at
> org.apache.ignite.internal.util.future.IgniteFutureImpl.get(IgniteFutureImpl.java:137)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$8.apply(GridCachePartitionExchangeManager.java:2112)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$8.apply(GridCachePartitionExchangeManager.java:2107)
> at
> org.apache.ignite.internal.util.future.IgniteFutureImpl$InternalFutureListener.apply(IgniteFutureImpl.java:215)
> at
> org.apache.ignite.internal.util.future.IgniteFutureImpl$InternalFutureListener.apply(IgniteFutureImpl.java:179)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:385)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:355)
> at
> org.apache.ignite.internal.util.future.IgniteFutureImpl.listen(IgniteFutureImpl.java:71)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningTransaction(GridCachePartitionExchangeManager.java:2107)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations0(GridCachePartitionExchangeManager.java:2009)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations(GridCachePartitionExchangeManager.java:2163)
> at org.apache.ignite.internal.IgniteKernal$4.run(IgniteKernal.java:1344)
> at
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$CancelableTask.onTimeout(GridTimeoutProcessor.java:365)
> at
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:234)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class
> org.apache.ignite.internal.cluster.ClusterGroupEmptyCheckedException: Cluster
> group is empty.
> at
> org.apache.ignite.internal.util.IgniteUtils.emptyTopologyException(IgniteUtils.java:4811)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor.callAsync(GridClosureProcessor.java:670)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor.callAsync(GridClosureProcessor.java:479)
> at
> org.apache.ignite.internal.IgniteComputeImpl.callAsync0(IgniteComputeImpl.java:809)
> at
> org.apache.ignite.internal.IgniteComputeImpl.callAsync(IgniteComputeImpl.java:794)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningTransaction(GridCachePartitionExchangeManager.java:2106)
> ... 7 more
> {code}
> {code:java}
> [18:53:00,809][SEVERE][grid-timeout-worker-#39][diagnostic] Could not get
> thread dump from transaction owner near node:
> class org.apache.ignite.cluster.ClusterGroupEmptyException: Topology
> projection is empty.
> at org.apache.ignite.internal.util.IgniteUtils$6.apply(IgniteUtils.java:853)
> at org.apache.ignite.internal.util.IgniteUtils$6.apply(IgniteUtils.java:851)
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:991)
> at
> org.apache.ignite.internal.util.future.IgniteFutureImpl.convertException(IgniteFutureImpl.java:168)
> at
> org.apache.ignite.internal.util.future.IgniteFutureImpl.get(IgniteFutureImpl.java:137)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$8.apply(GridCachePartitionExchangeManager.java:2112)
> at
>
[jira] [Commented] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
[ https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843893#comment-16843893 ] Ivan Pavlukhin commented on IGNITE-11708: - [~ivanan.fed], thank you for keeping track on it. I left comments on [GitHub|https://github.com/apache/ignite/pull/6434]. > Unable to run tests in IgniteConfigVariationsAbstractTest subclasses > > > Key: IGNITE-11708 > URL: https://issues.apache.org/jira/browse/IGNITE-11708 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep30 > Attachments: read_through_eviction_self_test.patch, > tx_out_test_fixed.patch > > Time Spent: 1h 10m > Remaining Estimate: 0h > > It seems that test classes that extend from > IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test > annotation. > It is easy to check: if throw exception in any test methods, nothing will > happen. > Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1], > maybe it destroys existing test workflow. > [1] > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10078) Node failure during concurrent partition updates may cause partition desync between primary and backup.
[
https://issues.apache.org/jira/browse/IGNITE-10078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843839#comment-16843839
]
Anton Vinogradov commented on IGNITE-10078:
---
[~map7000], Could you please join the discussion as a jepsen test author?
> Node failure during concurrent partition updates may cause partition desync
> between primary and backup.
> ---
>
> Key: IGNITE-10078
> URL: https://issues.apache.org/jira/browse/IGNITE-10078
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> This is possible if some updates are not written to WAL before node failure.
> They will be not applied by rebalancing due to same partition counters in
> certain scenario:
> 1. Start grid with 3 nodes, 2 backups.
> 2. Preload some data to partition P.
> 3. Start two concurrent transactions writing single key to the same partition
> P, keys are different
> {noformat}
> try(Transaction tx = client.transactions().txStart(PESSIMISTIC,
> REPEATABLE_READ, 0, 1)) {
> client.cache(DEFAULT_CACHE_NAME).put(k, v);
> tx.commit();
> }
> {noformat}
> 4. Order updates on backup in the way such update with max partition counter
> is written to WAL and update with lesser partition counter failed due to
> triggering of FH before it's added to WAL
> 5. Return failed node to grid, observe no rebalancing due to same partition
> counters.
> Possible solution: detect gaps in update counters on recovery and force
> rebalance from a node without gaps if detected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11592) NPE in case of continuing tx and cache stop operation.
[
https://issues.apache.org/jira/browse/IGNITE-11592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-11592:
Reviewer: Eduard Shangareev (was: Ivan Rakov)
> NPE in case of continuing tx and cache stop operation.
> ---
>
> Key: IGNITE-11592
> URL: https://issues.apache.org/jira/browse/IGNITE-11592
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Parallel cache stop and tx operations may lead to NPE.
> {code}
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.CacheObjectImpl.finishUnmarshal(CacheObjectImpl.java:129)
> at
> org.apache.ignite.internal.processors.cache.transactions.TxEntryValueHolder.unmarshal(TxEntryValueHolder.java:151)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxEntry.unmarshal(IgniteTxEntry.java:964)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.unmarshal(IgniteTxHandler.java:306)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:338)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:154)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.lambda$null$0(IgniteTxHandler.java:580)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:496)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> i hope that correct decision would be to roll back tx (on exchange phase)
> participating in stopped caches.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11592) NPE in case of continuing tx and cache stop operation.
[
https://issues.apache.org/jira/browse/IGNITE-11592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843820#comment-16843820
]
Ivan Rakov commented on IGNITE-11592:
-
[~EdShangGG], please take a look as well.
> NPE in case of continuing tx and cache stop operation.
> ---
>
> Key: IGNITE-11592
> URL: https://issues.apache.org/jira/browse/IGNITE-11592
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Parallel cache stop and tx operations may lead to NPE.
> {code}
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.CacheObjectImpl.finishUnmarshal(CacheObjectImpl.java:129)
> at
> org.apache.ignite.internal.processors.cache.transactions.TxEntryValueHolder.unmarshal(TxEntryValueHolder.java:151)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxEntry.unmarshal(IgniteTxEntry.java:964)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.unmarshal(IgniteTxHandler.java:306)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:338)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:154)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.lambda$null$0(IgniteTxHandler.java:580)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:496)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> i hope that correct decision would be to roll back tx (on exchange phase)
> participating in stopped caches.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10078) Node failure during concurrent partition updates may cause partition desync between primary and backup.
[
https://issues.apache.org/jira/browse/IGNITE-10078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843819#comment-16843819
]
Ivan Pavlukhin commented on IGNITE-10078:
-
[~avinogradov], keep in mind that the fix requires that in any point in time
there is at least one alive node in a cluster and there is always only one
active cluster (no split brain). Otherwise inconsistency is possible.
> Node failure during concurrent partition updates may cause partition desync
> between primary and backup.
> ---
>
> Key: IGNITE-10078
> URL: https://issues.apache.org/jira/browse/IGNITE-10078
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> This is possible if some updates are not written to WAL before node failure.
> They will be not applied by rebalancing due to same partition counters in
> certain scenario:
> 1. Start grid with 3 nodes, 2 backups.
> 2. Preload some data to partition P.
> 3. Start two concurrent transactions writing single key to the same partition
> P, keys are different
> {noformat}
> try(Transaction tx = client.transactions().txStart(PESSIMISTIC,
> REPEATABLE_READ, 0, 1)) {
> client.cache(DEFAULT_CACHE_NAME).put(k, v);
> tx.commit();
> }
> {noformat}
> 4. Order updates on backup in the way such update with max partition counter
> is written to WAL and update with lesser partition counter failed due to
> triggering of FH before it's added to WAL
> 5. Return failed node to grid, observe no rebalancing due to same partition
> counters.
> Possible solution: detect gaps in update counters on recovery and force
> rebalance from a node without gaps if detected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10078) Node failure during concurrent partition updates may cause partition desync between primary and backup.
[
https://issues.apache.org/jira/browse/IGNITE-10078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843814#comment-16843814
]
Ivan Pavlukhin commented on IGNITE-10078:
-
[~avinogradov], anyways great stuff!
> Node failure during concurrent partition updates may cause partition desync
> between primary and backup.
> ---
>
> Key: IGNITE-10078
> URL: https://issues.apache.org/jira/browse/IGNITE-10078
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> This is possible if some updates are not written to WAL before node failure.
> They will be not applied by rebalancing due to same partition counters in
> certain scenario:
> 1. Start grid with 3 nodes, 2 backups.
> 2. Preload some data to partition P.
> 3. Start two concurrent transactions writing single key to the same partition
> P, keys are different
> {noformat}
> try(Transaction tx = client.transactions().txStart(PESSIMISTIC,
> REPEATABLE_READ, 0, 1)) {
> client.cache(DEFAULT_CACHE_NAME).put(k, v);
> tx.commit();
> }
> {noformat}
> 4. Order updates on backup in the way such update with max partition counter
> is written to WAL and update with lesser partition counter failed due to
> triggering of FH before it's added to WAL
> 5. Return failed node to grid, observe no rebalancing due to same partition
> counters.
> Possible solution: detect gaps in update counters on recovery and force
> rebalance from a node without gaps if detected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10078) Node failure during concurrent partition updates may cause partition desync between primary and backup.
[
https://issues.apache.org/jira/browse/IGNITE-10078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843810#comment-16843810
]
Anton Vinogradov commented on IGNITE-10078:
---
[~Pavlukhin], that's exactly what we're doing now :)
> Node failure during concurrent partition updates may cause partition desync
> between primary and backup.
> ---
>
> Key: IGNITE-10078
> URL: https://issues.apache.org/jira/browse/IGNITE-10078
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> This is possible if some updates are not written to WAL before node failure.
> They will be not applied by rebalancing due to same partition counters in
> certain scenario:
> 1. Start grid with 3 nodes, 2 backups.
> 2. Preload some data to partition P.
> 3. Start two concurrent transactions writing single key to the same partition
> P, keys are different
> {noformat}
> try(Transaction tx = client.transactions().txStart(PESSIMISTIC,
> REPEATABLE_READ, 0, 1)) {
> client.cache(DEFAULT_CACHE_NAME).put(k, v);
> tx.commit();
> }
> {noformat}
> 4. Order updates on backup in the way such update with max partition counter
> is written to WAL and update with lesser partition counter failed due to
> triggering of FH before it's added to WAL
> 5. Return failed node to grid, observe no rebalancing due to same partition
> counters.
> Possible solution: detect gaps in update counters on recovery and force
> rebalance from a node without gaps if detected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10078) Node failure during concurrent partition updates may cause partition desync between primary and backup.
[
https://issues.apache.org/jira/browse/IGNITE-10078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843803#comment-16843803
]
Ivan Pavlukhin commented on IGNITE-10078:
-
[~avinogradov], out of curiosity, have you run these tests against Ignite
without current fix? Could you please share results?
> Node failure during concurrent partition updates may cause partition desync
> between primary and backup.
> ---
>
> Key: IGNITE-10078
> URL: https://issues.apache.org/jira/browse/IGNITE-10078
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> This is possible if some updates are not written to WAL before node failure.
> They will be not applied by rebalancing due to same partition counters in
> certain scenario:
> 1. Start grid with 3 nodes, 2 backups.
> 2. Preload some data to partition P.
> 3. Start two concurrent transactions writing single key to the same partition
> P, keys are different
> {noformat}
> try(Transaction tx = client.transactions().txStart(PESSIMISTIC,
> REPEATABLE_READ, 0, 1)) {
> client.cache(DEFAULT_CACHE_NAME).put(k, v);
> tx.commit();
> }
> {noformat}
> 4. Order updates on backup in the way such update with max partition counter
> is written to WAL and update with lesser partition counter failed due to
> triggering of FH before it's added to WAL
> 5. Return failed node to grid, observe no rebalancing due to same partition
> counters.
> Possible solution: detect gaps in update counters on recovery and force
> rebalance from a node without gaps if detected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10078) Node failure during concurrent partition updates may cause partition desync between primary and backup.
[
https://issues.apache.org/jira/browse/IGNITE-10078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843791#comment-16843791
]
Anton Vinogradov commented on IGNITE-10078:
---
Folks,
We're currently checking fix using brandnew jepsen's test.
We have inconsistent state at bank test [1] at master at node's failures.
Checking PR now, will let you know about the results.
[1]
https://github.com/jepsen-io/jepsen/blob/master/ignite/src/jepsen/ignite/bank.clj
> Node failure during concurrent partition updates may cause partition desync
> between primary and backup.
> ---
>
> Key: IGNITE-10078
> URL: https://issues.apache.org/jira/browse/IGNITE-10078
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> This is possible if some updates are not written to WAL before node failure.
> They will be not applied by rebalancing due to same partition counters in
> certain scenario:
> 1. Start grid with 3 nodes, 2 backups.
> 2. Preload some data to partition P.
> 3. Start two concurrent transactions writing single key to the same partition
> P, keys are different
> {noformat}
> try(Transaction tx = client.transactions().txStart(PESSIMISTIC,
> REPEATABLE_READ, 0, 1)) {
> client.cache(DEFAULT_CACHE_NAME).put(k, v);
> tx.commit();
> }
> {noformat}
> 4. Order updates on backup in the way such update with max partition counter
> is written to WAL and update with lesser partition counter failed due to
> triggering of FH before it's added to WAL
> 5. Return failed node to grid, observe no rebalancing due to same partition
> counters.
> Possible solution: detect gaps in update counters on recovery and force
> rebalance from a node without gaps if detected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10619) Add support files transmission between nodes over connection via CommunicationSpi
[
https://issues.apache.org/jira/browse/IGNITE-10619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843788#comment-16843788
]
Alexey Goncharuk commented on IGNITE-10619:
---
[~Mmuzaf], folks,
The current API looks too complex to me. Are there any reasons to introduce our
own Channel, ChannelId, IgniteSocketChannel, etc... ? Ignite is not a framework
to transfer files, so internal API should be kept as simple as possible.
I would suggest the following change to the GridIOManager:
{code}
public IgniteFuture openChannel(ClusterNode rmtNode,
Message channelInitMessage);
public void addChannelListener(ChannelListener lsnr);
interface ChannelListener {
onChannelOpened(ClusterNode rmtNode, Message initMessage, Channel channel);
}
{code}
The IgniteFileTransmitProcessor API also feels too redundant. The only thing
that needs to be provided on the supplier side is an input stream/channel. I
see no need in {{TransmitSessionFactory}} and sibling classes.
[~DmitriyGovorukhin], [~ibessonov], can you take a look at the change as well?
> Add support files transmission between nodes over connection via
> CommunicationSpi
> -
>
> Key: IGNITE-10619
> URL: https://issues.apache.org/jira/browse/IGNITE-10619
> Project: Ignite
> Issue Type: Sub-task
> Components: persistence
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: iep-28
>
> Partition preloader must support cache partition file relocation from one
> cluster node to another (the zero copy algorithm [1] assume to be used by
> default). To achieve this, the file transfer machinery must be implemented at
> Apache Ignite over Communication SPI.
> _CommunicationSpi_
> Ignite's Comminication SPI must support to:
> * establishing channel connections to the remote node to an arbitrary topic
> (GridTopic) with predefined processing policy;
> * listening incoming channel creation events and registering connection
> handlers on the particular node;
> * an arbitrary set of channel parameters on connection handshake;
> _FileTransmitProcessor_
> The file transmission manager must support to:
> * using different approaches of incoming data handling – buffered and direct
> (zero-copy approach of FileChannel#transferTo);
> * transferring data by chunks of predefined size with saving intermediate
> results;
> * re-establishing connection if an error occurs and continue file
> upload\download;
> * limiting connection bandwidth (upload and download) at runtime;
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
[ https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843757#comment-16843757 ] Ivan Fedotov commented on IGNITE-11708: --- [~Pavlukhin] , I think that PR is ready for review/merge. Could you please take a look on it? > Unable to run tests in IgniteConfigVariationsAbstractTest subclasses > > > Key: IGNITE-11708 > URL: https://issues.apache.org/jira/browse/IGNITE-11708 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep30 > Attachments: read_through_eviction_self_test.patch, > tx_out_test_fixed.patch > > Time Spent: 10m > Remaining Estimate: 0h > > It seems that test classes that extend from > IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test > annotation. > It is easy to check: if throw exception in any test methods, nothing will > happen. > Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1], > maybe it destroys existing test workflow. > [1] > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
[
https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843755#comment-16843755
]
Ignite TC Bot commented on IGNITE-11708:
{panel:title=-- Run :: All (Nightly): No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All (Nightly)*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3825815buildTypeId=IgniteTests24Java8_RunAllNightly]
> Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
>
>
> Key: IGNITE-11708
> URL: https://issues.apache.org/jira/browse/IGNITE-11708
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
> Labels: iep30
> Attachments: read_through_eviction_self_test.patch,
> tx_out_test_fixed.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It seems that test classes that extend from
> IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test
> annotation.
> It is easy to check: if throw exception in any test methods, nothing will
> happen.
> Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1],
> maybe it destroys existing test workflow.
> [1]
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9878) Failed to start near cache after second call of getOrCreateCache
[
https://issues.apache.org/jira/browse/IGNITE-9878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Guseinov updated IGNITE-9878:
---
Attachment: NearCacheIssueReproducer.java
> Failed to start near cache after second call of getOrCreateCache
>
>
> Key: IGNITE-9878
> URL: https://issues.apache.org/jira/browse/IGNITE-9878
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
> Attachments: NearCacheIssueReproducer.java
>
>
> Repeated call of `Ignite.getOrCreateCache(CacheConfiguration cacheCfg,
> NearCacheConfiguration nearCfg)` lead the following exception:
> {code:java}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to start near cache (local node is an affinity node for cache):
> ignite-test-near-rep
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2995)
> at
> org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testRepeatedGetOrCreateCache(NearCacheIssueReproducer.java:24)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> near cache (local node is an affinity node for cache): ignite-test-near-rep
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheChangeRequest(GridCacheProcessor.java:5235)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3621)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3560)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2983)
> ... 23 more
> {code}
> Also, if a cache is specified in the IgniteConfiguration,
> `Ignite#getOrCreateNearCache` will fail with the following exception:
> {code:java}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to start near cache (a cache with the same name without near cache is
> already started)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3072)
> at
> org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testGetOrCreateNearCache(NearCacheIssueReproducer.java:32)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> near cache (a cache with the same name without near cache is already started)
> at
> org.apache.ignite.internal.IgniteKernal.checkNearCacheStarted(IgniteKernal.java:3085)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3067)
> ... 23 more
> {code}
> The test is attached [^NearCacheIssueReproducer.java]. The workaround is to
> put near cache config into cache configuration
> `CacheConfiguration.setNearConfiguration`.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9878) Failed to start near cache after second call of getOrCreateCache
[
https://issues.apache.org/jira/browse/IGNITE-9878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Guseinov updated IGNITE-9878:
---
Description:
Repeated call of `Ignite.getOrCreateCache(CacheConfiguration cacheCfg,
NearCacheConfiguration nearCfg)` lead the following exception:
{code:java}
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Failed to start near cache (local node is an affinity node for cache):
ignite-test-near-rep
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
at
org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2995)
at
org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testRepeatedGetOrCreateCache(NearCacheIssueReproducer.java:24)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start near
cache (local node is an affinity node for cache): ignite-test-near-rep
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheChangeRequest(GridCacheProcessor.java:5235)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3621)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3560)
at
org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2983)
... 23 more
{code}
Also, if a cache is specified in the IgniteConfiguration,
`Ignite#getOrCreateNearCache` will fail with the following exception:
{code:java}
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Failed to start near cache (a cache with the same name without near cache is
already started)
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
at
org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3072)
at
org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testGetOrCreateNearCache(NearCacheIssueReproducer.java:32)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start near
cache (a cache with the same name without near cache is already started)
at
org.apache.ignite.internal.IgniteKernal.checkNearCacheStarted(IgniteKernal.java:3085)
at
org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3067)
... 23 more
{code}
The test is attached [^NearCacheIssueReproducer.java]. The workaround is to
put near cache config into cache configuration
`CacheConfiguration.setNearConfiguration`.
was:
Repeated call of `Ignite.getOrCreateCache(CacheConfiguration cacheCfg,
NearCacheConfiguration nearCfg)` lead the following exception:
{code:java}
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Failed to start near cache (local node is an affinity node for cache):
ignite-test-near-rep
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
at
org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2995)
at
org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testRepeatedGetOrCreateCache(NearCacheIssueReproducer.java:24)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start near
cache (local node is an affinity node for cache): ignite-test-near-rep
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheChangeRequest(GridCacheProcessor.java:5235)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3621)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3560)
at
org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2983)
... 23 more
{code}
Also, if a cache is specified in the IgniteConfiguration,
`Ignite#getOrCreateNearCache` will fail with the following exception:
{code:java}
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Failed to start near cache (a cache with the same name without near cache is
already started)
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
at
org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3072)
at
org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testGetOrCreateNearCache(NearCacheIssueReproducer.java:32)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start near
cache (a cache with the same name without near cache is already started)
at
org.apache.ignite.internal.IgniteKernal.checkNearCacheStarted(IgniteKernal.java:3085)
[jira] [Updated] (IGNITE-9878) Failed to start near cache after second call of getOrCreateCache
[
https://issues.apache.org/jira/browse/IGNITE-9878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Guseinov updated IGNITE-9878:
---
Attachment: (was: NearCacheIssueReproducer.java)
> Failed to start near cache after second call of getOrCreateCache
>
>
> Key: IGNITE-9878
> URL: https://issues.apache.org/jira/browse/IGNITE-9878
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
>
> Repeated call of `Ignite.getOrCreateCache(CacheConfiguration cacheCfg,
> NearCacheConfiguration nearCfg)` lead the following exception:
> {code:java}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to start near cache (local node is an affinity node for cache):
> ignite-test-near-rep
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2995)
> at
> org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testRepeatedGetOrCreateCache(NearCacheIssueReproducer.java:24)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> near cache (local node is an affinity node for cache): ignite-test-near-rep
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheChangeRequest(GridCacheProcessor.java:5235)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3621)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3560)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2983)
> ... 23 more
> {code}
> Also, if a cache is specified in the IgniteConfiguration,
> `Ignite#getOrCreateNearCache` will fail with the following exception:
> {code:java}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to start near cache (a cache with the same name without near cache is
> already started)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3072)
> at
> org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testGetOrCreateNearCache(NearCacheIssueReproducer.java:32)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> near cache (a cache with the same name without near cache is already started)
> at
> org.apache.ignite.internal.IgniteKernal.checkNearCacheStarted(IgniteKernal.java:3085)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3067)
> ... 23 more
> {code}
> The test is attached [^NearCacheIssueReproducer.java]. The workaround is to
> put near cache config into cache configuration
> `CacheConfiguration.setNearConfiguration`.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9878) Failed to start near cache after second call of getOrCreateCache
[
https://issues.apache.org/jira/browse/IGNITE-9878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Guseinov updated IGNITE-9878:
---
Description:
Repeated call of `Ignite.getOrCreateCache(CacheConfiguration cacheCfg,
NearCacheConfiguration nearCfg)` lead the following exception:
{code:java}
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Failed to start near cache (local node is an affinity node for cache):
ignite-test-near-rep
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1300)
at
org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2872)
at
org.apache.ignite.examples.NearCacheIssueReproducer.testIgniteNearCacheReplicated(NearCacheIssueReproducer.java:29)
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:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start near
cache (local node is an affinity node for cache): ignite-test-near-rep
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheChangeRequest(GridCacheProcessor.java:4302)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:2877)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:2816)
at
org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2860)
... 23 more
{code}
Also, if a cache is specified in the IgniteConfiguration,
`Ignite#getOrCreateNearCache` will fail with the following exception:
{code:java}
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Failed to start near cache (a cache with the same name without near cache is
already started)
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
at
org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3072)
at
org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testGetOrCreateNearCache(NearCacheIssueReproducer.java:32)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start near
cache (a cache with the same name without near cache is already started)
at
org.apache.ignite.internal.IgniteKernal.checkNearCacheStarted(IgniteKernal.java:3085)
at
org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3067)
... 23 more
{code}
The test is attached [^NearCacheIssueReproducer.java]. The workaround is to
put near cache config into cache configuration
`CacheConfiguration.setNearConfiguration`.
was:
Repeated call of `Ignite.getOrCreateCache(CacheConfiguration cacheCfg,
NearCacheConfiguration nearCfg)` lead the following exception:
{code:java}
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Failed to start near cache (local node is an affinity node for cache):
ignite-test-near-rep
at
[jira] [Updated] (IGNITE-9878) Failed to start near cache after second call of getOrCreateCache
[
https://issues.apache.org/jira/browse/IGNITE-9878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Guseinov updated IGNITE-9878:
---
Description:
Repeated call of `Ignite.getOrCreateCache(CacheConfiguration cacheCfg,
NearCacheConfiguration nearCfg)` lead the following exception:
{code:java}
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Failed to start near cache (local node is an affinity node for cache):
ignite-test-near-rep
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
at
org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2995)
at
org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testRepeatedGetOrCreateCache(NearCacheIssueReproducer.java:24)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start near
cache (local node is an affinity node for cache): ignite-test-near-rep
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheChangeRequest(GridCacheProcessor.java:5235)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3621)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3560)
at
org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2983)
... 23 more
{code}
Also, if a cache is specified in the IgniteConfiguration,
`Ignite#getOrCreateNearCache` will fail with the following exception:
{code:java}
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Failed to start near cache (a cache with the same name without near cache is
already started)
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
at
org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3072)
at
org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testGetOrCreateNearCache(NearCacheIssueReproducer.java:32)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start near
cache (a cache with the same name without near cache is already started)
at
org.apache.ignite.internal.IgniteKernal.checkNearCacheStarted(IgniteKernal.java:3085)
at
org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3067)
... 23 more
{code}
The test is attached [^NearCacheIssueReproducer.java]. The workaround is to
put near cache config into cache configuration
`CacheConfiguration.setNearConfiguration`.
was:
Repeated call of `Ignite.getOrCreateCache(CacheConfiguration cacheCfg,
NearCacheConfiguration nearCfg)` lead the following exception:
{code:java}
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Failed to start near cache (local node is an affinity node for cache):
ignite-test-near-rep
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1300)
at
org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2872)
at
org.apache.ignite.examples.NearCacheIssueReproducer.testIgniteNearCacheReplicated(NearCacheIssueReproducer.java:29)
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:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
