[jira] [Commented] (IGNITE-12116) Cache doesn't support array as key
[ https://issues.apache.org/jira/browse/IGNITE-12116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917836#comment-16917836 ] Eduard Shangareev commented on IGNITE-12116: Looks good. Thank you, great improvement! > Cache doesn't support array as key > -- > > Key: IGNITE-12116 > URL: https://issues.apache.org/jira/browse/IGNITE-12116 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The ignite cache doesn't support array as key. You couldn't do the base > operations with it. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (IGNITE-12087) Transactional putAll - significant performance drop on big batches of entries.
[
https://issues.apache.org/jira/browse/IGNITE-12087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev reassigned IGNITE-12087:
--
Assignee: Eduard Shangareev
> Transactional putAll - significant performance drop on big batches of entries.
> --
>
> Key: IGNITE-12087
> URL: https://issues.apache.org/jira/browse/IGNITE-12087
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Pavel Pereslegin
>Assignee: Eduard Shangareev
>Priority: Major
>
> After IGNITE-5227 have been fixed I found significant performance drop in
> putAll operation.
> Insertion of 30_000 entries before IGNITE-5227 took ~1 second.
> After IGNITE-5227 - 130 seconds (~100x slower).
> I checked a different batch size:
> 10_000 - 10 seconds
> 20_000 - 48 seconds
> 30_000 - 130 seconds
> and I was not able to wait for the result of 100_000 entries.
> Reproducer
> {code:java}
> public class CheckPutAll extends GridCommonAbstractTest {
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> CacheConfiguration ccfg = new CacheConfiguration(DEFAULT_CACHE_NAME);
> ccfg.setAtomicityMode(TRANSACTIONAL);
> cfg.setCacheConfiguration(ccfg);
> return cfg;
> }
> @Test
> public void check() throws Exception {
> int cnt = 30_000;
> Map data = new HashMap<>(U.capacity(cnt));
> for (int i = 0; i < cnt; i++)
> data.put(i, i);
> Ignite node0 = startGrid(0);
> IgniteCache cache0 =
> node0.cache(DEFAULT_CACHE_NAME);
> cache0.putAll(data);
> }
> }{code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (IGNITE-12080) Add extended logging for rebalance
[ https://issues.apache.org/jira/browse/IGNITE-12080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911539#comment-16911539 ] Eduard Shangareev commented on IGNITE-12080: Looks good. Thank you for your contribution. > Add extended logging for rebalance > -- > > Key: IGNITE-12080 > URL: https://issues.apache.org/jira/browse/IGNITE-12080 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > > We should log all information about finished rebalance on demander node. > I'd have in log: > h3. Total information: > # Rebalance duration, rebalance start time/rebalance finish time > # How many partitions were processed in each topic (number of paritions, > number of entries, number of bytes) > # How many nodes were suppliers in rebalance (nodeId, number of supplied > paritions, number of supplied entries, number of bytes, duraton of getting > and processing partitions from supplier) > h3. Information per cache group: > # Rebalance duration, rebalance start time/rebalance finish time > # How many partitions were processed in each topic (number of paritions, > number of entries, number of bytes) > # How many nodes were suppliers in rebalance (nodeId, number of supplied > paritions, list of partition ids with PRIMARY/BACKUP flag, number of supplied > entries, number of bytes, duraton of getting and processing partitions from > supplier) > # Information about each partition distribution (list of nodeIds with > primary/backup flag and marked supplier nodeId) > h3. Information per supplier node: > # How many paritions were requested: > #* Total number > #* Primary/backup distribution (number of primary partitions, number of > backup partitions) > #* Total number of entries > #* Total size partitions in bytes > # How many paritions were requested per cache group: > #* Number of requested partitions > #* Number of entries in partitions > #* Total size of partitions in bytes > #* List of requested partitions with size in bytes, count entries, primary or > backup partition flag -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IGNITE-12072) Starting node with extra cache in cache group cause assertion error
Eduard Shangareev created IGNITE-12072:
--
Summary: Starting node with extra cache in cache group cause
assertion error
Key: IGNITE-12072
URL: https://issues.apache.org/jira/browse/IGNITE-12072
Project: Ignite
Issue Type: Bug
Reporter: Eduard Shangareev
Reproducer
IgniteCacheGroupsWithRestartsTest#testNodeRestartWithNewStaticallyConfiguredCache
{code}
java.lang.AssertionError: AffinityTopologyVersion [topVer=-1, minorTopVer=0]
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:770)
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:747)
at
org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.updateLocal(GridDhtPartitionTopologyImpl.java:2571)
at
org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.afterStateRestored(GridDhtPartitionTopologyImpl.java:714)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.lambda$beforeExchange$38edadb$1(GridCacheDatabaseSharedManager.java:1415)
at
org.apache.ignite.internal.util.IgniteUtils.lambda$null$1(IgniteUtils.java:11037)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (IGNITE-12059) DiskPageCompressionConfigValidationTest.testIncorrectStaticCacheConfiguration fails
[ https://issues.apache.org/jira/browse/IGNITE-12059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev updated IGNITE-12059: --- Ignite Flags: (was: Docs Required) > DiskPageCompressionConfigValidationTest.testIncorrectStaticCacheConfiguration > fails > --- > > Key: IGNITE-12059 > URL: https://issues.apache.org/jira/browse/IGNITE-12059 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > DiskPageCompressionConfigValidationTest.testIncorrectStaticCacheConfiguration > fails because validation was removed in IGNITE-9562. > Need to restore this validation. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-12059) DiskPageCompressionConfigValidationTest.testIncorrectStaticCacheConfiguration fails
[ https://issues.apache.org/jira/browse/IGNITE-12059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905066#comment-16905066 ] Eduard Shangareev commented on IGNITE-12059: https://ci.ignite.apache.org/viewQueued.html?itemId=4491407 > DiskPageCompressionConfigValidationTest.testIncorrectStaticCacheConfiguration > fails > --- > > Key: IGNITE-12059 > URL: https://issues.apache.org/jira/browse/IGNITE-12059 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > DiskPageCompressionConfigValidationTest.testIncorrectStaticCacheConfiguration > fails because validation was removed in IGNITE-9562. > Need to restore this validation. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-12059) DiskPageCompressionConfigValidationTest.testIncorrectStaticCacheConfiguration fails
Eduard Shangareev created IGNITE-12059: -- Summary: DiskPageCompressionConfigValidationTest.testIncorrectStaticCacheConfiguration fails Key: IGNITE-12059 URL: https://issues.apache.org/jira/browse/IGNITE-12059 Project: Ignite Issue Type: Bug Reporter: Eduard Shangareev Assignee: Eduard Shangareev DiskPageCompressionConfigValidationTest.testIncorrectStaticCacheConfiguration fails because validation was removed in IGNITE-9562. Need to restore this validation. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-9562) Destroyed cache that resurrected on a old offline node breaks PME
[
https://issues.apache.org/jira/browse/IGNITE-9562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901162#comment-16901162
]
Eduard Shangareev commented on IGNITE-9562:
---
The proper solution is moving cache configuration to metastore. There was
implemented a workaround to not get the cluster to hang.
We don’t allow nodes with caches which don’t exist in running cluster and the
nodes have data on disk.
To allow the nodes join, you need to remove directories with absent caches or
start the nodes first.
> Destroyed cache that resurrected on a old offline node breaks PME
> -
>
> Key: IGNITE-9562
> URL: https://issues.apache.org/jira/browse/IGNITE-9562
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Eduard Shangareev
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Given:
> 2 nodes, persistence enabled.
> 1) Stop 1 node
> 2) Destroy cache through client
> 3) Start stopped node
> When the stopped node joins to cluster it starts all caches that it has seen
> before stopping.
> If that cache was cluster-widely destroyed it leads to breaking the crash
> recovery process or PME.
> Root cause - we don't start/collect caches from the stopped node on another
> part of a cluster.
> In case of PARTITIONED cache mode that scenario breaks crash recovery:
> {noformat}
> java.lang.AssertionError: AffinityTopologyVersion [topVer=-1, minorTopVer=0]
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:696)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.updateLocal(GridDhtPartitionTopologyImpl.java:2449)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.afterStateRestored(GridDhtPartitionTopologyImpl.java:679)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restorePartitionStates(GridCacheDatabaseSharedManager.java:2445)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLastUpdates(GridCacheDatabaseSharedManager.java:2321)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1568)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java:1308)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1255)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:766)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2577)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2457)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> In case of REPLICATED cache mode that scenario breaks PME coordinator process:
> {noformat}
> [2018-09-12
> 18:50:36,407][ERROR][sys-#148%distributed.CacheStopAndRessurectOnOldNodeTest0%][GridCacheIoManager]
> Failed to process message [senderId=4b6fd0d4-b756-4a9f-90ca-f0ee2511,
> messageType=class
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsSingleMessage]
> java.lang.AssertionError: 3080586
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.clientTopology(GridCachePartitionExchangeManager.java:815)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.updatePartitionSingleMap(GridDhtPartitionsExchangeFuture.java:3621)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2439)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:137)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2261)
> at
>
[jira] [Assigned] (IGNITE-9562) Destroyed cache that resurrected on a old offline node breaks PME
[
https://issues.apache.org/jira/browse/IGNITE-9562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev reassigned IGNITE-9562:
-
Assignee: Eduard Shangareev
> Destroyed cache that resurrected on a old offline node breaks PME
> -
>
> Key: IGNITE-9562
> URL: https://issues.apache.org/jira/browse/IGNITE-9562
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Eduard Shangareev
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Given:
> 2 nodes, persistence enabled.
> 1) Stop 1 node
> 2) Destroy cache through client
> 3) Start stopped node
> When the stopped node joins to cluster it starts all caches that it has seen
> before stopping.
> If that cache was cluster-widely destroyed it leads to breaking the crash
> recovery process or PME.
> Root cause - we don't start/collect caches from the stopped node on another
> part of a cluster.
> In case of PARTITIONED cache mode that scenario breaks crash recovery:
> {noformat}
> java.lang.AssertionError: AffinityTopologyVersion [topVer=-1, minorTopVer=0]
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:696)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.updateLocal(GridDhtPartitionTopologyImpl.java:2449)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.afterStateRestored(GridDhtPartitionTopologyImpl.java:679)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restorePartitionStates(GridCacheDatabaseSharedManager.java:2445)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLastUpdates(GridCacheDatabaseSharedManager.java:2321)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1568)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java:1308)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1255)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:766)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2577)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2457)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> In case of REPLICATED cache mode that scenario breaks PME coordinator process:
> {noformat}
> [2018-09-12
> 18:50:36,407][ERROR][sys-#148%distributed.CacheStopAndRessurectOnOldNodeTest0%][GridCacheIoManager]
> Failed to process message [senderId=4b6fd0d4-b756-4a9f-90ca-f0ee2511,
> messageType=class
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsSingleMessage]
> java.lang.AssertionError: 3080586
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.clientTopology(GridCachePartitionExchangeManager.java:815)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.updatePartitionSingleMap(GridDhtPartitionsExchangeFuture.java:3621)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2439)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:137)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2261)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2249)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
> at
>
[jira] [Commented] (IGNITE-8717) Move persisted cache configuration to metastore and introduce cache configuration versioning
[ https://issues.apache.org/jira/browse/IGNITE-8717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881515#comment-16881515 ] Eduard Shangareev commented on IGNITE-8717: --- Any updates here? Is it in progress yet? > Move persisted cache configuration to metastore and introduce cache > configuration versioning > > > Key: IGNITE-8717 > URL: https://issues.apache.org/jira/browse/IGNITE-8717 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Sergey Antonov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently, we persist cache configuration to local files which resulted in > several inconsistencies when a node misses configuration update (create > index, cache destroy, etc). > I think the cache configuration should be saved to the metastore the same way > as baseline topology is saved. Same mechanics should be used for conflicting > configuration updates resolution. > Along with cache configuration, it also makes sense to move marshaller and > binary metadata to the metastore. -- 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=16852884#comment-16852884 ] Eduard Shangareev commented on IGNITE-10913: Looks good. Thank you for contribution. > 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: 1h 40m > 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] [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=16845042#comment-16845042 ] Eduard Shangareev commented on IGNITE-10913: I have left some comments in PR. [~Denis Chudov], please, take a look. > 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: 1h 20m > 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] [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] [Commented] (IGNITE-11788) Fix issues related to IGNITE-10896
[
https://issues.apache.org/jira/browse/IGNITE-11788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840586#comment-16840586
]
Eduard Shangareev commented on IGNITE-11788:
Looks good! Thank you for contribution.
> Fix issues related to IGNITE-10896
> --
>
> Key: IGNITE-11788
> URL: https://issues.apache.org/jira/browse/IGNITE-11788
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Both following cases related to executing commands in control.sh
> 1. New boolean field *succeeded* {color:#33}in
> {color}*org.apache.ignite.internal.processors.cache.verify.**IdleVerifyResultV2*
> is not serialized. It may affect the case when there are no caches matching
> idle_verify command filters: possibly user can get odd output message.
> 2. Cache name parsing now assumes that cache names can be given as regexps -
> it may affect the case when cache name contains regexp special characters:
> user can get error message about incorrect regular expression.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11780) Split command handler on hierarchy of commands
[ https://issues.apache.org/jira/browse/IGNITE-11780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev updated IGNITE-11780: --- Description: Now it is just a big ball of mud. Splitting on command would define API and make adding new command much easier. was: Now it is just a big ball of mud. > Split command handler on hierarchy of commands > -- > > Key: IGNITE-11780 > URL: https://issues.apache.org/jira/browse/IGNITE-11780 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Now it is just a big ball of mud. > Splitting on command would define API and make adding new command much easier. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11780) Split command handler on hierarchy of commands
[ https://issues.apache.org/jira/browse/IGNITE-11780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev updated IGNITE-11780: --- Summary: Split command handler on hierarchy of commands (was: Command handler refactoring) > Split command handler on hierarchy of commands > -- > > Key: IGNITE-11780 > URL: https://issues.apache.org/jira/browse/IGNITE-11780 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Shangareev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Now it is just a big ball of mud. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11780) Split command handler on hierarchy of commands
[ https://issues.apache.org/jira/browse/IGNITE-11780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev reassigned IGNITE-11780: -- Assignee: Eduard Shangareev > Split command handler on hierarchy of commands > -- > > Key: IGNITE-11780 > URL: https://issues.apache.org/jira/browse/IGNITE-11780 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Now it is just a big ball of mud. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11833) Tests for cache group functionality don't have version with persistence enabled
[ https://issues.apache.org/jira/browse/IGNITE-11833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev reassigned IGNITE-11833: -- Assignee: Eduard Shangareev > Tests for cache group functionality don't have version with persistence > enabled > --- > > Key: IGNITE-11833 > URL: https://issues.apache.org/jira/browse/IGNITE-11833 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > > There are many tests for cache group functionality but most of them don't > have version with enabled persistence. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11833) Tests for cache group functionality don't have version with persistence enabled
Eduard Shangareev created IGNITE-11833: -- Summary: Tests for cache group functionality don't have version with persistence enabled Key: IGNITE-11833 URL: https://issues.apache.org/jira/browse/IGNITE-11833 Project: Ignite Issue Type: Bug Reporter: Eduard Shangareev There are many tests for cache group functionality but most of them don't have version with enabled persistence. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11780) Command handler refactoring
Eduard Shangareev created IGNITE-11780: -- Summary: Command handler refactoring Key: IGNITE-11780 URL: https://issues.apache.org/jira/browse/IGNITE-11780 Project: Ignite Issue Type: Improvement Reporter: Eduard Shangareev Now it is just a big ball of mud. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11142) Control.sh should print detailed information about transaction.
[
https://issues.apache.org/jira/browse/IGNITE-11142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821027#comment-16821027
]
Eduard Shangareev commented on IGNITE-11142:
Looks good.
> Control.sh should print detailed information about transaction.
> ---
>
> Key: IGNITE-11142
> URL: https://issues.apache.org/jira/browse/IGNITE-11142
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Ivan Rakov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 7h 20m
> Remaining Estimate: 0h
>
> We should be able to get detailed information about transactions. Approximate
> info per node:
> * Initiator node
> * Transaction state
> * Used caches
> * Used entry keys
> * Locked keys
>
> Possible command: {{control.sh --tx-info --ids txid1[txid2,...txidN]}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11728) DELME
Eduard Shangareev created IGNITE-11728: -- Summary: DELME Key: IGNITE-11728 URL: https://issues.apache.org/jira/browse/IGNITE-11728 Project: Ignite Issue Type: Bug Reporter: Eduard Shangareev Created by mistake -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11579) Add new commands to deal with garbage in partitions which left after cache destroy in shared cache groups
[ https://issues.apache.org/jira/browse/IGNITE-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev reassigned IGNITE-11579: -- Assignee: Eduard Shangareev > Add new commands to deal with garbage in partitions which left after cache > destroy in shared cache groups > - > > Key: IGNITE-11579 > URL: https://issues.apache.org/jira/browse/IGNITE-11579 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > > The scenario of how to get to this situation (garbage in partition) described > in IGNITE-11578. > We need to add a new command for control.sh: > - show such keys; > - remove such keys. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11411) Remove tearDown, setUp from JUnit3TestLegacySupport
[ https://issues.apache.org/jira/browse/IGNITE-11411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16802933#comment-16802933 ] Eduard Shangareev commented on IGNITE-11411: Looks good! Thank you for contribution. > Remove tearDown, setUp from JUnit3TestLegacySupport > --- > > Key: IGNITE-11411 > URL: https://issues.apache.org/jira/browse/IGNITE-11411 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep-30 > Time Spent: 10m > Remaining Estimate: 0h > > TearDown and setUp methods are deprecated for JUnit 4+ version. It is > necessary to replace them with appropriate methods, marked by @Before and > @After annotations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11606) Index could not contain all values from cache after index full rebuild
[
https://issues.apache.org/jira/browse/IGNITE-11606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16802913#comment-16802913
]
Eduard Shangareev commented on IGNITE-11606:
[~vozerov], [~Pavlukhin], please, take a look.
> Index could not contain all values from cache after index full rebuild
> --
>
> Key: IGNITE-11606
> URL: https://issues.apache.org/jira/browse/IGNITE-11606
> Project: Ignite
> Issue Type: Bug
> Components: cache, persistence, sql
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If index.bin was deleted, we would rebuild it on node start.
> But it could cause to the situation when a key is in the cache but SQL query
> doesn't return it.
> {code}
> [18:29:07][:363] idle_verify check has finished, found 1194 conflict
> partitions: [counterConflicts=0, hashConflicts=1194]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11606) Index could not contain all values from cache after index full rebuild
[
https://issues.apache.org/jira/browse/IGNITE-11606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16802590#comment-16802590
]
Eduard Shangareev commented on IGNITE-11606:
The situation happens if there was replace during logical recovery in the cache
which index.bin should be rebuilt or replace during index.bin rebuild.
It happens because there was not an explicit assumption that cache and pk index
are always synced.
> Index could not contain all values from cache after index full rebuild
> --
>
> Key: IGNITE-11606
> URL: https://issues.apache.org/jira/browse/IGNITE-11606
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If index.bin was deleted, we would rebuild it on node start.
> But it could cause to the situation when a key is in the cache but SQL query
> doesn't return it.
> {code}
> [18:29:07][:363] idle_verify check has finished, found 1194 conflict
> partitions: [counterConflicts=0, hashConflicts=1194]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11589) GridDhtPartitionsExchangeFuture remained incompleted in some circumstances
[
https://issues.apache.org/jira/browse/IGNITE-11589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801650#comment-16801650
]
Eduard Shangareev commented on IGNITE-11589:
I looked through, looks good! Thank you for contribution.
> GridDhtPartitionsExchangeFuture remained incompleted in some circumstances
> --
>
> Key: IGNITE-11589
> URL: https://issues.apache.org/jira/browse/IGNITE-11589
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{GridDhtPartitionsExchangeFuture#onDone}} contains a piece of code that
> should be executed before {{GridFutureAdapter#onDone}} is called and so,
> in case of an exception is thrown by that code, exchange future is not
> completed and, therefore, it may cause a deadlock.
> the following stack trace can be used as an example of that behavior:
> {noformat}
> [GridDhtPartitionsExchangeFuture] Failed to reinitialize local partitions
> (rebalancing will be stopped): GridDhtPartitionExchangeId [...msg=Node left:
> TcpDiscoveryNode [ ], type=NODE_LEFT]
> class org.apache.ignite.IgniteException: null
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.detectLostPartitions(GridDhtPartitionsExchangeFuture.java:3152)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:3549)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:3301)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1516)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:849)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2878)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2727)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: class
> org.apache.ignite.internal.IgniteInterruptedCheckedException: null
> at
> org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:10846)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.detectLostPartitions(GridDhtPartitionsExchangeFuture.java:3135)
> ... 9 more
> Caused by: java.lang.InterruptedException
> at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:404)
> at java.util.concurrent.FutureTask.get(FutureTask.java:191)
> at
> org.apache.ignite.internal.util.IgniteUtils$Batch.result(IgniteUtils.java:10947)
> at
> org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:10836)
> ... 10 more{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11568) Change afterTest() annotation in TcpDiscoveryFailedJoinTest
[ https://issues.apache.org/jira/browse/IGNITE-11568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16799979#comment-16799979 ] Eduard Shangareev commented on IGNITE-11568: Looks good. Thank you for contribution. > Change afterTest() annotation in TcpDiscoveryFailedJoinTest > --- > > Key: IGNITE-11568 > URL: https://issues.apache.org/jira/browse/IGNITE-11568 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > afterTest() method in TcpDiscoveryFailedJoinTest is overridden and annotated > by after. Meanwhile, it is under prohibition because afterTest will be > executed after test anyway (see JUnit3TestLegacySupport and > beforeTest/afterTest usage in GridAbstractTest for more details). > > So, it is necessary to change after annotation on override. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11606) Index could not contain all values from cache after index full rebuild
[
https://issues.apache.org/jira/browse/IGNITE-11606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev updated IGNITE-11606:
---
Ignite Flags: (was: Docs Required)
> Index could not contain all values from cache after index full rebuild
> --
>
> Key: IGNITE-11606
> URL: https://issues.apache.org/jira/browse/IGNITE-11606
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
>
> If index.bin was deleted, we would rebuild it on node start.
> But it could cause to the situation when a key is in the cache but SQL query
> doesn't return it.
> {code}
> [18:29:07][:363] idle_verify check has finished, found 1194 conflict
> partitions: [counterConflicts=0, hashConflicts=1194]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11606) Index could not contain all values from cache after index full rebuild
[
https://issues.apache.org/jira/browse/IGNITE-11606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev reassigned IGNITE-11606:
--
Assignee: Eduard Shangareev
> Index could not contain all values from cache after index full rebuild
> --
>
> Key: IGNITE-11606
> URL: https://issues.apache.org/jira/browse/IGNITE-11606
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
>
> If index.bin was deleted, we would rebuild it on node start.
> But it could cause to the situation when a key is in the cache but SQL query
> doesn't return it.
> {code}
> [18:29:07][:363] idle_verify check has finished, found 1194 conflict
> partitions: [counterConflicts=0, hashConflicts=1194]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11606) Index could not contain all values from cache after full rebuild
Eduard Shangareev created IGNITE-11606:
--
Summary: Index could not contain all values from cache after full
rebuild
Key: IGNITE-11606
URL: https://issues.apache.org/jira/browse/IGNITE-11606
Project: Ignite
Issue Type: Bug
Reporter: Eduard Shangareev
If index.bin was deleted, we would rebuild it on node start.
But it could cause to the situation when a key is in the cache but SQL query
doesn't return it.
{code}
[18:29:07][:363] idle_verify check has finished, found 1194 conflict
partitions: [counterConflicts=0, hashConflicts=1194]
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11606) Index could not contain all values from cache after index full rebuild
[
https://issues.apache.org/jira/browse/IGNITE-11606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev updated IGNITE-11606:
---
Summary: Index could not contain all values from cache after index full
rebuild (was: Index could not contain all values from cache after full rebuild)
> Index could not contain all values from cache after index full rebuild
> --
>
> Key: IGNITE-11606
> URL: https://issues.apache.org/jira/browse/IGNITE-11606
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Priority: Major
>
> If index.bin was deleted, we would rebuild it on node start.
> But it could cause to the situation when a key is in the cache but SQL query
> doesn't return it.
> {code}
> [18:29:07][:363] idle_verify check has finished, found 1194 conflict
> partitions: [counterConflicts=0, hashConflicts=1194]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11579) Add new commands to deal with garbage in partitions which left after cache destroy in shared cache groups
Eduard Shangareev created IGNITE-11579: -- Summary: Add new commands to deal with garbage in partitions which left after cache destroy in shared cache groups Key: IGNITE-11579 URL: https://issues.apache.org/jira/browse/IGNITE-11579 Project: Ignite Issue Type: Improvement Reporter: Eduard Shangareev The scenario of how to get to this situation (garbage in partition) described in IGNITE-11578. We need to add a new command for control.sh: - show such keys; - remove such keys. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11578) Stopping node after destroying cache in shared cache group would leave data of this cache in persistence
Eduard Shangareev created IGNITE-11578: -- Summary: Stopping node after destroying cache in shared cache group would leave data of this cache in persistence Key: IGNITE-11578 URL: https://issues.apache.org/jira/browse/IGNITE-11578 Project: Ignite Issue Type: Improvement Reporter: Eduard Shangareev If a cache is in a shared group its destroy would trigger async eviction of its cache. If we stop node at the moment, after restart the eviction wouldn't be retriggered. As a result, the part of data of the cache would last on persistence. We could fix it by adding a flag in metastore about eviction start and removing only on eviction stop. If on node start such flag is presented, we need to continue the eviction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11549) Replace array of AtomicLongs with AtomicLongArray
[ https://issues.apache.org/jira/browse/IGNITE-11549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev reassigned IGNITE-11549: -- Assignee: Eduard Shangareev > Replace array of AtomicLongs with AtomicLongArray > - > > Key: IGNITE-11549 > URL: https://issues.apache.org/jira/browse/IGNITE-11549 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > > org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList#bucketsSize -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11550) Destroy cache in shared cache group could leave garbage in partitions
Eduard Shangareev created IGNITE-11550: -- Summary: Destroy cache in shared cache group could leave garbage in partitions Key: IGNITE-11550 URL: https://issues.apache.org/jira/browse/IGNITE-11550 Project: Ignite Issue Type: Improvement Reporter: Eduard Shangareev If the cache was not the only in cache group, cache data would be evicted key by key asynchronously. If the node would go done during the eviction, it wouldn't be continued after restart. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11549) Replace array of AtomicLongs with AtomicLongArray
[ https://issues.apache.org/jira/browse/IGNITE-11549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev updated IGNITE-11549: --- Description: org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList#bucketsSize It should decrease the count of object and memory footprint. was:org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList#bucketsSize > Replace array of AtomicLongs with AtomicLongArray > - > > Key: IGNITE-11549 > URL: https://issues.apache.org/jira/browse/IGNITE-11549 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > > org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList#bucketsSize > It should decrease the count of object and memory footprint. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11549) Replace array of AtomicLongs with AtomicLongArray
Eduard Shangareev created IGNITE-11549: -- Summary: Replace array of AtomicLongs with AtomicLongArray Key: IGNITE-11549 URL: https://issues.apache.org/jira/browse/IGNITE-11549 Project: Ignite Issue Type: Improvement Reporter: Eduard Shangareev org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList#bucketsSize -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11288) TcpDiscovery locks forever on SSLSocket.close().
[
https://issues.apache.org/jira/browse/IGNITE-11288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16766998#comment-16766998
]
Eduard Shangareev commented on IGNITE-11288:
Definitely, [~ivandasch] is right, we need to update PlatformConfigurationUtils
with platform code, maybe in a separate ticket.
I am OK with change, but we need to create a new ticket for updating platform
code in 2.8 version.
> TcpDiscovery locks forever on SSLSocket.close().
>
>
> Key: IGNITE-11288
> URL: https://issues.apache.org/jira/browse/IGNITE-11288
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Voronkin
>Assignee: Pavel Voronkin
>Priority: Critical
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Rootcause is java bug locking on SSLSocketImpl.close() on write lock:
> //we create socket with soTimeout(0) here, but setting it here won't help
> anyway.
> RingMessageWorker: 3152 sock = spi.openSocket(addr, timeoutHelper);
> //After timeout grid-timeout-worker blocks forever on SSLSOcketImpl.close().
> According to java8 SSLSocketImpl:
> {code:java}
> if (var1.isAlert((byte)0) && this.getSoLinger() >= 0) {
> boolean var3 = Thread.interrupted();
> try {
> if (this.writeLock.tryLock((long)this.getSoLinger(), TimeUnit.SECONDS)) {
> try
> { this.writeRecordInternal(var1, var2); }
> finally
> { this.writeLock.unlock(); }
> } else
> { SSLException var4 = new SSLException("SO_LINGER timeout, close_notify
> message cannot be sent."); if (this.isLayered() && !this.autoClose) {
> this.fatal((byte)-1, (Throwable)var4); }
> else if (debug != null && Debug.isOn("ssl"))
> { System.out.println(Thread.currentThread().getName() + ", received
> Exception: " + var4); }
> this.sess.invalidate();
> }
> } catch (InterruptedException var14)
> { var3 = true; }
> if (var3)
> { Thread.currentThread().interrupt(); }
> } else
> { this.writeLock.lock(); try { this.writeRecordInternal(var1, var2); }
> finally
> { this.writeLock.unlock(); }
> }{code}
> In case of soLinger is not set we fallback to this.writeLock.lock(); which
> wait forever, cause RingMessageWorker is writing message with SO_TIMEOUT zero.
> Solution:
> 1) Set proper SO_TIMEOUT //that didn't help on Linux in case we drop packets
> using iptables.
> 2) Set SO_LINGER to some reasonable positive value.
> Similar JDK bug [https://bugs.openjdk.java.net/browse/JDK-6668261].
> Guys end up setting SO_LINGER.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11288) TcpDiscovery deadlock on SSLSocket.close().
[
https://issues.apache.org/jira/browse/IGNITE-11288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev updated IGNITE-11288:
---
Description:
Rootcause is we not set SO_TIMEOUT on discovery socket on retry:
RingMessageWorker: 3152 sock = spi.openSocket(addr, timeoutHelper);
So ring message worker blocks forever but SSLSOcketImpl.close() onTimeout hangs
on writeLock.
According to java8 SSLSocketImpl:
{code}
if (var1.isAlert((byte)0) && this.getSoLinger() >= 0) {
boolean var3 = Thread.interrupted();
try {
if (this.writeLock.tryLock((long)this.getSoLinger(), TimeUnit.SECONDS)) {
try
{ this.writeRecordInternal(var1, var2); }
finally \{ this.writeLock.unlock(); }
} else
\{ SSLException var4 = new SSLException("SO_LINGER timeout, close_notify
message cannot be sent."); if (this.isLayered() && !this.autoClose) {
this.fatal((byte)-1, (Throwable)var4); }
else if (debug != null && Debug.isOn("ssl")) \{
System.out.println(Thread.currentThread().getName() + ", received Exception: "
+ var4); }
this.sess.invalidate();
}
} catch (InterruptedException var14) \{ var3 = true; }
if (var3) \{ Thread.currentThread().interrupt(); }
} else
\{ this.writeLock.lock(); try { this.writeRecordInternal(var1, var2); }
finally
{ this.writeLock.unlock(); }
}
{code}
In case of soLinger is not set we fallback to this.writeLock.lock(); which wait
forever, cause RingMessageWorker is writing message with SO_TIMEOUT zero.
U.closeQuiet(socket) if SSL is on will hang if soLinger() is negative.
Solution:
1) Set proper SO_TIMEOUT
2) Possibly add ability to override SO_LINGER to some reasonable value.
Similar bug [https://bugs.openjdk.java.net/browse/JDK-6668261].
was:
Rootcause is we not set SO_TIMEOUT on discovery socket on retry:
RingMessageWorker: 3152 sock = spi.openSocket(addr, timeoutHelper);
So ring message worker blocks forever but SSLSOcketImpl.close() onTimeout hangs
on writeLock.
According to java8 SSLSocketImpl:
if (var1.isAlert((byte)0) && this.getSoLinger() >= 0) {
boolean var3 = Thread.interrupted();
try {
if (this.writeLock.tryLock((long)this.getSoLinger(), TimeUnit.SECONDS)) {
try
{ this.writeRecordInternal(var1, var2); }
finally \{ this.writeLock.unlock(); }
} else
\{ SSLException var4 = new SSLException("SO_LINGER timeout, close_notify
message cannot be sent."); if (this.isLayered() && !this.autoClose) {
this.fatal((byte)-1, (Throwable)var4); }
else if (debug != null && Debug.isOn("ssl")) \{
System.out.println(Thread.currentThread().getName() + ", received Exception: "
+ var4); }
this.sess.invalidate();
}
} catch (InterruptedException var14) \{ var3 = true; }
if (var3) \{ Thread.currentThread().interrupt(); }
} else
\{ this.writeLock.lock(); try { this.writeRecordInternal(var1, var2); }
finally
{ this.writeLock.unlock(); }
}
In case of soLinger is not set we fallback to this.writeLock.lock(); which wait
forever, cause RingMessageWorker is writing message with SO_TIMEOUT zero.
U.closeQuiet(socket) if SSL is on will hang if soLinger() is negative.
Solution:
1) Set proper SO_TIMEOUT
2) Possibly add ability to override SO_LINGER to some reasonable value.
Similar bug [https://bugs.openjdk.java.net/browse/JDK-6668261].
> TcpDiscovery deadlock on SSLSocket.close().
> ---
>
> Key: IGNITE-11288
> URL: https://issues.apache.org/jira/browse/IGNITE-11288
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Voronkin
>Assignee: Pavel Voronkin
>Priority: Critical
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Rootcause is we not set SO_TIMEOUT on discovery socket on retry:
> RingMessageWorker: 3152 sock = spi.openSocket(addr, timeoutHelper);
> So ring message worker blocks forever but SSLSOcketImpl.close() onTimeout
> hangs on writeLock.
>
> According to java8 SSLSocketImpl:
> {code}
> if (var1.isAlert((byte)0) && this.getSoLinger() >= 0) {
> boolean var3 = Thread.interrupted();
> try {
> if (this.writeLock.tryLock((long)this.getSoLinger(), TimeUnit.SECONDS)) {
> try
> { this.writeRecordInternal(var1, var2); }
>
> finally \{ this.writeLock.unlock(); }
> } else
>
> \{ SSLException var4 = new SSLException("SO_LINGER timeout, close_notify
> message cannot be sent."); if (this.isLayered() && !this.autoClose) {
> this.fatal((byte)-1, (Throwable)var4); }
>
> else if (debug != null && Debug.isOn("ssl")) \{
> System.out.println(Thread.currentThread().getName() + ", received Exception:
> " + var4); }
>
> this.sess.invalidate();
> }
> } catch (InterruptedException var14) \{ var3 = true; }
>
> if (var3) \{ Thread.currentThread().interrupt(); }
> } else
>
> \{ this.writeLock.lock(); try { this.writeRecordInternal(var1, var2); }
> finally
> { this.writeLock.unlock(); }
> }
>
[jira] [Resolved] (IGNITE-11264) JVM crash in OffheapReadWriteLock#tryWriteLock
[ https://issues.apache.org/jira/browse/IGNITE-11264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev resolved IGNITE-11264. Resolution: Duplicate > JVM crash in OffheapReadWriteLock#tryWriteLock > -- > > Key: IGNITE-11264 > URL: https://issues.apache.org/jira/browse/IGNITE-11264 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Eduard Shangareev >Priority: Major > Attachments: hs_err_pid19407.log, test_output.txt > > > JVM crash in the end of > IgniteClusterActivateDeactivateTest#testClientReconnectClusterActivateInProgress. > Test was invoked using "Until Failure" mode in IDEA. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11265) JVM Crash on TeamCity
[ https://issues.apache.org/jira/browse/IGNITE-11265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev updated IGNITE-11265: --- Summary: JVM Crash on TeamCity (was: JVM Crash is often on TeamCity for Java 11 runs) > JVM Crash on TeamCity > - > > Key: IGNITE-11265 > URL: https://issues.apache.org/jira/browse/IGNITE-11265 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Pavlov >Assignee: Eduard Shangareev >Priority: Critical > Attachments: hs_err_pid2431080.log.txt, hs_err_pid2458635.log.txt, > hs_err_pid2674225.log.txt, hs_err_pid3473289.log.txt > > Time Spent: 10m > Remaining Estimate: 0h > > All crash dumps complain about the same method > org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writeLock > Data Structures (https://ci.ignite.apache.org/viewLog.html?buildId=3007882) > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_DataStructures/3007882:id/hs_err_pid2674225.log > Other recent examples > Queries 1 > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_Queries1/3027655:id/hs_err_pid2458635.log > Client Nodes > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_ClientNodes/3027569:id/hs_err_pid2431080.log > Zookeeper Discovery > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_ZooKeeperDiscovery1/3027601:id/hs_err_pid3473289.log -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11265) JVM Crashes on TeamCity
[ https://issues.apache.org/jira/browse/IGNITE-11265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev updated IGNITE-11265: --- Summary: JVM Crashes on TeamCity (was: JVM Crash on TeamCity) > JVM Crashes on TeamCity > --- > > Key: IGNITE-11265 > URL: https://issues.apache.org/jira/browse/IGNITE-11265 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Pavlov >Assignee: Eduard Shangareev >Priority: Critical > Attachments: hs_err_pid2431080.log.txt, hs_err_pid2458635.log.txt, > hs_err_pid2674225.log.txt, hs_err_pid3473289.log.txt > > Time Spent: 10m > Remaining Estimate: 0h > > All crash dumps complain about the same method > org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writeLock > Data Structures (https://ci.ignite.apache.org/viewLog.html?buildId=3007882) > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_DataStructures/3007882:id/hs_err_pid2674225.log > Other recent examples > Queries 1 > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_Queries1/3027655:id/hs_err_pid2458635.log > Client Nodes > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_ClientNodes/3027569:id/hs_err_pid2431080.log > Zookeeper Discovery > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_ZooKeeperDiscovery1/3027601:id/hs_err_pid3473289.log -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11265) JVM Crash is often on TeamCity for Java 11 runs
[ https://issues.apache.org/jira/browse/IGNITE-11265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev reassigned IGNITE-11265: -- Assignee: Eduard Shangareev > JVM Crash is often on TeamCity for Java 11 runs > --- > > Key: IGNITE-11265 > URL: https://issues.apache.org/jira/browse/IGNITE-11265 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Pavlov >Assignee: Eduard Shangareev >Priority: Critical > Attachments: hs_err_pid2431080.log.txt, hs_err_pid2458635.log.txt, > hs_err_pid2674225.log.txt, hs_err_pid3473289.log.txt > > > All crash dumps complain about the same method > org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writeLock > Data Structures (https://ci.ignite.apache.org/viewLog.html?buildId=3007882) > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_DataStructures/3007882:id/hs_err_pid2674225.log > Other recent examples > Queries 1 > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_Queries1/3027655:id/hs_err_pid2458635.log > Client Nodes > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_ClientNodes/3027569:id/hs_err_pid2431080.log > Zookeeper Discovery > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_ZooKeeperDiscovery1/3027601:id/hs_err_pid3473289.log -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9672) Move o.a.i.i.processors.cache.persistence.tree.io.PageMetaIO to metastore.
[ https://issues.apache.org/jira/browse/IGNITE-9672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16766009#comment-16766009 ] Eduard Shangareev commented on IGNITE-9672: --- Looks good! [~dpavlov], could you assist with merge? > Move o.a.i.i.processors.cache.persistence.tree.io.PageMetaIO to metastore. > -- > > Key: IGNITE-9672 > URL: https://issues.apache.org/jira/browse/IGNITE-9672 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > We have in current implementation special meta page related to snapshot > functionality. > Meta page is stored in index partition. > If index.bin is removed (for triggering index rebuild), all information is > lost and incremental snapshot logic is broken. > Solution: move snapshot metadata in metastore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11158) Accommodate some of the recent tests to changes made per IGNITE-10179
[
https://issues.apache.org/jira/browse/IGNITE-11158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757190#comment-16757190
]
Eduard Shangareev commented on IGNITE-11158:
[~oignatenko], looks good! Thank you for contribution.
> Accommodate some of the recent tests to changes made per IGNITE-10179
> -
>
> Key: IGNITE-11158
> URL: https://issues.apache.org/jira/browse/IGNITE-11158
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Changes made per IGNITE-10179 can impact any test inheriting
> {{GridAbstractTest}}. Some of recent tests were added / enabled too late to
> properly accommodate to these changes.
> This task is to investigate such tests and do corrections if needed.
> Per failure report of Teamcity bot, list of involved tests is as follows:
> {quote}
> * cache.IgniteTopologyValidatorNearPartitionedTxCacheGroupsTest
> * eviction.GridCacheConcurrentEvictionConsistencySelfTest
> * cache.IgniteTopologyValidatorNearPartitionedTxCacheTest
> * eviction.DhtAndNearEvictionTest
> * cache.CacheMetricsForClusterGroupSelfTest
> * eviction.GridCacheEvictionLockUnlockSelfTest
> * replicated.GridCacheReplicatedMetricsSelfTest
> * eviction.GridCacheEvictionTouchSelfTest
> * eviction.GridCacheConcurrentEvictionsSelfTest
> * local.GridCacheLocalMetricsSelfTest
> * near.GridCachePartitionedMetricsSelfTest
> * local.GridCacheLocalIteratorsSelfTest
> * internal.TransactionMetricsMxBeanImplTest
> * cache.GridEvictionPolicyMBeansTest
> * cache.GridCacheTxPartitionedLocalStoreSelfTest
> * cache.IgniteCacheNearLockValueSelfTest
> * cache.IgnitePutAllLargeBatchSelfTest
> * jdbc.CacheJdbcPojoStoreBinaryMarshallerStoreKeepBinarySelfTest
> * cache.IgnitePutAllUpdateNonPreloadedPartitionSelfTest
> * jdbc.CacheJdbcPojoStoreBinaryMarshallerSelfTest
> * near.GridCacheGetStoreErrorSelfTest
> * distributed.IgniteCrossCacheTxStoreSelfTest
> * cache.GridCacheColocatedTxStoreExceptionSelfTest
> * cache.IgniteCacheEntryListenerTxTest
> * cache.GridCacheLocalTxStoreExceptionSelfTest
> * near.GridCachePartitionedStorePutSelfTest
> * local.GridCacheLocalTxExceptionSelfTest
> * cache.GridCacheNearTxStoreExceptionSelfTest
> * cache.GridCacheReplicatedTxStoreExceptionSelfTest
> * distributed.CacheTxNearUpdateTopologyChangeTest
> * dht.GridCacheGlobalLoadTest
> * cache.GridCacheTtlManagerSelfTest
> * cache.IgniteCacheEntryListenerEagerTtlDisabledTest
> * store.CacheTransactionalStoreReadFromBackupTest
> * jdbc.CacheJdbcPojoStoreBinaryMarshallerStoreKeepBinaryWithSqlEscapeSelfTest
> * cache.IgniteCacheEntryListenerTxReplicatedTest
> * store.GridCacheLoadOnlyStoreAdapterSelfTest
> * cache.IgniteCacheEntryListenerTxLocalTest
> * cache.CachePutEventListenerErrorSelfTest
> * cache.GridCacheObjectToStringSelfTest
> * near.GridCacheNearTxExceptionSelfTest
> * jdbc.CacheJdbcPojoStoreBinaryMarshallerWithSqlEscapeSelfTest
> * cache.IgniteCacheTxLocalInvokeTest
> * jdbc.GridCacheJdbcBlobStoreMultithreadedSelfTest
> * GridCacheRebalancingPartitionDistributionTest.testRollingRestart
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-537) Continuous processor should support p2p deployment on discovery data exchange
[ https://issues.apache.org/jira/browse/IGNITE-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev updated IGNITE-537: - Fix Version/s: 3.0 > Continuous processor should support p2p deployment on discovery data exchange > - > > Key: IGNITE-537 > URL: https://issues.apache.org/jira/browse/IGNITE-537 > Project: Ignite > Issue Type: Task >Reporter: Yakov Zhdanov >Assignee: Yakov Zhdanov >Priority: Major > Fix For: 3.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5979) [Test Failed] GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync
[
https://issues.apache.org/jira/browse/IGNITE-5979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev updated IGNITE-5979:
--
Description:
Example of failing -
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7197727268986978983=testDetails
{noformat}
junit.framework.AssertionFailedError: Failed to check value for key [key=72625,
node=0671e5c8-8bd5-4f2a-b1b8-9e945742, primary=false,
recNodeId=101770ef-a622-4f7c-b714-70ecf1f1] expected:<0> but
was:<-1994497644>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.failNotEquals(Assert.java:329)
at junit.framework.Assert.assertEquals(Assert.java:78)
at junit.framework.TestCase.assertEquals(TestCase.java:244)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.checkRestarts(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:334)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:154)
{noformat}
was:
Example of failing -
http://ci.ignite.apache.org/viewLog.html?buildId=760709=buildResultsDiv=Ignite20Tests_IgniteDataGridFailover#testNameId6248548165747570497
{noformat}
junit.framework.AssertionFailedError: Failed to check value for key [key=72625,
node=0671e5c8-8bd5-4f2a-b1b8-9e945742, primary=false,
recNodeId=101770ef-a622-4f7c-b714-70ecf1f1] expected:<0> but
was:<-1994497644>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.failNotEquals(Assert.java:329)
at junit.framework.Assert.assertEquals(Assert.java:78)
at junit.framework.TestCase.assertEquals(TestCase.java:244)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.checkRestarts(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:334)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:154)
{noformat}
> [Test Failed]
> GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync
>
>
> Key: IGNITE-5979
> URL: https://issues.apache.org/jira/browse/IGNITE-5979
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Priority: Major
> Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.8
>
>
> Example of failing -
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7197727268986978983=testDetails
> {noformat}
> junit.framework.AssertionFailedError: Failed to check value for key
> [key=72625, node=0671e5c8-8bd5-4f2a-b1b8-9e945742, primary=false,
> recNodeId=101770ef-a622-4f7c-b714-70ecf1f1] expected:<0> but
> was:<-1994497644>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.TestCase.assertEquals(TestCase.java:244)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.checkRestarts(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:334)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:154)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-5970) Flaky failure of org.apache.ignite.p2p.GridP2PLocalDeploymentSelfTest#testConcurrentDeploymentWithDelegatingClassloader
[
https://issues.apache.org/jira/browse/IGNITE-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev updated IGNITE-5970:
--
Description:
Can't reproduce locally on Win 10.
On TC test has 50% success rate:
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=3101872679882751520=testDetails
{noformat}
org.apache.ignite.internal.IgniteDeploymentCheckedException: Task not deployed:
org.apache.ignite.p2p.GridP2PLocalDeploymentSelfTest$TestClosure
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:712)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:448)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor.callAsync(GridClosureProcessor.java:673)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor.callAsync(GridClosureProcessor.java:478)
at
org.apache.ignite.internal.IgniteComputeImpl.callAsync0(IgniteComputeImpl.java:809)
at
org.apache.ignite.internal.IgniteComputeImpl.call(IgniteComputeImpl.java:785)
at
org.apache.ignite.p2p.GridP2PLocalDeploymentSelfTest$1.call(GridP2PLocalDeploymentSelfTest.java:240)
at
org.apache.ignite.p2p.GridP2PLocalDeploymentSelfTest$1.call(GridP2PLocalDeploymentSelfTest.java:235)
at
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
{noformat}
was:
Can't reproduce locally on Win 10.
On TC test has 50% success rate:
http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=3101872679882751520=testDetails_Ignite20Tests=%3Cdefault%3E
{noformat}
org.apache.ignite.internal.IgniteDeploymentCheckedException: Task not deployed:
org.apache.ignite.p2p.GridP2PLocalDeploymentSelfTest$TestClosure
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:712)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:448)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor.callAsync(GridClosureProcessor.java:673)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor.callAsync(GridClosureProcessor.java:478)
at
org.apache.ignite.internal.IgniteComputeImpl.callAsync0(IgniteComputeImpl.java:809)
at
org.apache.ignite.internal.IgniteComputeImpl.call(IgniteComputeImpl.java:785)
at
org.apache.ignite.p2p.GridP2PLocalDeploymentSelfTest$1.call(GridP2PLocalDeploymentSelfTest.java:240)
at
org.apache.ignite.p2p.GridP2PLocalDeploymentSelfTest$1.call(GridP2PLocalDeploymentSelfTest.java:235)
at
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
{noformat}
> Flaky failure of
> org.apache.ignite.p2p.GridP2PLocalDeploymentSelfTest#testConcurrentDeploymentWithDelegatingClassloader
> ---
>
> Key: IGNITE-5970
> URL: https://issues.apache.org/jira/browse/IGNITE-5970
> Project: Ignite
> Issue Type: Test
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> Can't reproduce locally on Win 10.
> On TC test has 50% success rate:
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=3101872679882751520=testDetails
> {noformat}
> org.apache.ignite.internal.IgniteDeploymentCheckedException: Task not
> deployed: org.apache.ignite.p2p.GridP2PLocalDeploymentSelfTest$TestClosure
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:712)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:448)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor.callAsync(GridClosureProcessor.java:673)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor.callAsync(GridClosureProcessor.java:478)
> at
> org.apache.ignite.internal.IgniteComputeImpl.callAsync0(IgniteComputeImpl.java:809)
> at
> org.apache.ignite.internal.IgniteComputeImpl.call(IgniteComputeImpl.java:785)
> at
> org.apache.ignite.p2p.GridP2PLocalDeploymentSelfTest$1.call(GridP2PLocalDeploymentSelfTest.java:240)
> at
> org.apache.ignite.p2p.GridP2PLocalDeploymentSelfTest$1.call(GridP2PLocalDeploymentSelfTest.java:235)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10905) org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtInvalidPartitionException happens during rolling restart of a cluster
[
https://issues.apache.org/jira/browse/IGNITE-10905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev updated IGNITE-10905:
---
Description:
JVM is halted after this error during rolling restart of a cluster:
{code}
org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtInvalidPartitionException:
Adding entry to partition that is concurrently evicted [grp=cacheGroup_7,
part=518, shouldBeMoving=, belongs=true, topVer=AffinityTopologyVersion
[topVer=42, minorTopVer=0], curTopVer=AffinityTopologyVersion [topVer=43,
minorTopVer=0]]
at
org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.localPartition0(GridDhtPartitionTopologyImpl.java:950)
at
org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.localPartition(GridDhtPartitionTopologyImpl.java:825)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.handleSupplyMessage(GridDhtPartitionDemander.java:744)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleSupplyMessage(GridDhtPreloader.java:387)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:418)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:408)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1056)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$700(GridCacheIoManager.java:101)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1613)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4100(GridIoManager.java:127)
at
org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2768)
at
org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1529)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4400(GridIoManager.java:127)
at
org.apache.ignite.internal.managers.communication.GridIoManager$10.run(GridIoManager.java:1498)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
was:
JVM is halted after this error during rolling restart of a cluster:
org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtInvalidPartitionException:
Adding entry to partition that is concurrently evicted [grp=cacheGroup_7,
part=518, shouldBeMoving=, belongs=true, topVer=AffinityTopologyVersion
[topVer=42, minorTopVer=0], curTopVer=AffinityTopologyVersion [topVer=43,
minorTopVer=0]]
at
org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.localPartition0(GridDhtPartitionTopologyImpl.java:950)
at
org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.localPartition(GridDhtPartitionTopologyImpl.java:825)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.handleSupplyMessage(GridDhtPartitionDemander.java:744)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleSupplyMessage(GridDhtPreloader.java:387)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:418)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:408)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1056)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$700(GridCacheIoManager.java:101)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1613)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4100(GridIoManager.java:127)
at
org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2768)
at
[jira] [Commented] (IGNITE-10758) remove from tests scaffolding annotations "@RunWith(JUnit4.class)" and their respective imports
[
https://issues.apache.org/jira/browse/IGNITE-10758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754201#comment-16754201
]
Eduard Shangareev commented on IGNITE-10758:
[~oignatenko], I have only one suggestion - revert adding extra space in
ServiceDeploymentDiscoveryListenerNotificationOrderTest.
Everything else looks good.
> remove from tests scaffolding annotations "@RunWith(JUnit4.class)" and their
> respective imports
> ---
>
> Key: IGNITE-10758
> URL: https://issues.apache.org/jira/browse/IGNITE-10758
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the course of IGNITE-10175 and IGNITE-10176 many test classes were
> annotated {{@RunWith(JUnit4.class)}}. This was necessary to allow gradual
> switching to JUnit 4 to let classes run under the version that worked for
> these.
> After IGNITE-10177 is over, these scaffolding annotations will be not needed
> anymore (and will become even somewhat damaging by misleading readers to
> think that they serve some real purpose).
> The task is to remove these annotations and respective import statements
> after IGNITE-10177 is merged to master. Note it was initially planned as a
> part of IGNITE-10177 but per discussion with [~EdShangGG] we decided that it
> will be more convenient to do this in a separate ticket because this will
> make changes much easier to review, test and merge.
> (!) Thing worth paying attention is that mentioned annotations should be kept
> in one case - namely in root test class {{GridAbstractTest}} because over
> there these are necessary until JUnit 3 dependencies are wiped out from
> remaining cases listed in IGNITE-10739.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7718) Collections.singleton() and Collections.singletonMap() are not properly serialized by binary marshaller
[ https://issues.apache.org/jira/browse/IGNITE-7718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753973#comment-16753973 ] Eduard Shangareev commented on IGNITE-7718: --- [~vozerov], [~pvinokurov], hi guys. Any update here? > Collections.singleton() and Collections.singletonMap() are not properly > serialized by binary marshaller > --- > > Key: IGNITE-7718 > URL: https://issues.apache.org/jira/browse/IGNITE-7718 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Major > > After desialization collections obtained by Collections.singleton() and > Collections.singletonMap() does not return collection of binary objects, but > rather collection of deserialized objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10777) Cleanup remainders of JUnit4TestAdapter and other JUnit 3 API involving test suites
[ https://issues.apache.org/jira/browse/IGNITE-10777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746523#comment-16746523 ] Eduard Shangareev commented on IGNITE-10777: Looks good, [~oignatenko], thank you! > Cleanup remainders of JUnit4TestAdapter and other JUnit 3 API involving test > suites > --- > > Key: IGNITE-10777 > URL: https://issues.apache.org/jira/browse/IGNITE-10777 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.8 >Reporter: Oleg Ignatenko >Assignee: Oleg Ignatenko >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > This task is to cleanup remainders of JUnit4TestAdapter and other JUnit 3 API > involving test suites that may be missed in prior sub-tasks under the parent > task. > If needed, refer to parent task comments for more details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10899) Service Grid: disconnecting during node stop may lead to deadlock
[
https://issues.apache.org/jira/browse/IGNITE-10899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744038#comment-16744038
]
Eduard Shangareev edited comment on IGNITE-10899 at 1/16/19 1:27 PM:
-
[~daradurvs], looks good. Thank you for your contribution!
was (Author: edshanggg):
[~daradurvs], looks good. Thank you for your cotribution!
> Service Grid: disconnecting during node stop may lead to deadlock
> -
>
> Key: IGNITE-10899
> URL: https://issues.apache.org/jira/browse/IGNITE-10899
> Project: Ignite
> Issue Type: Task
> Components: managed services
>Affects Versions: 2.7
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> In a rare case {{onDisconneced}} may be called during node stopping and
> deadlock may occur because of {{ServiceDeploymentManage#stopProcessong}}
> blocks busyLock and not release it intentionally.
> The issue has been found on TeamCity in [Zookeeper's
> suite|https://ci.ignite.apache.org/viewLog.html?buildId=2768270=IgniteTests24Java8_ZooKeeperDiscovery2]
> with the following stack trace:
> {code:java}
> disco-notifier-worker-#569118%client4%"
> #609288
> prio=5 os_prio=0 tid=0x7f905b440800 nid=0x3f6fbd
> sleeping[0x7f9383efd000]
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.ignite.internal.util.GridSpinReadWriteLock.writeLock(GridSpinReadWriteLock.java:204)
> at
> org.apache.ignite.internal.util.GridSpinBusyLock.block(GridSpinBusyLock.java:76)
> at
> org.apache.ignite.internal.processors.service.ServiceDeploymentManager.stopProcessing(ServiceDeploymentManager.java:137)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.stopProcessor(IgniteServiceProcessor.java:261)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.onDisconnected(IgniteServiceProcessor.java:429)
> at
> org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:4010)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:819)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:602)
> - locked <0xf7ecdfa0> (a java.lang.Object)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4$$Lambda$25/2087171109.run(Unknown
> Source)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2696)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2734)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10899) Service Grid: disconnecting during node stop may lead to deadlock
[
https://issues.apache.org/jira/browse/IGNITE-10899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744038#comment-16744038
]
Eduard Shangareev commented on IGNITE-10899:
[~daradurvs], looks good. Thank you for your cotribution!
> Service Grid: disconnecting during node stop may lead to deadlock
> -
>
> Key: IGNITE-10899
> URL: https://issues.apache.org/jira/browse/IGNITE-10899
> Project: Ignite
> Issue Type: Task
> Components: managed services
>Affects Versions: 2.7
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> In a rare case {{onDisconneced}} may be called during node stopping and
> deadlock may occur because of {{ServiceDeploymentManage#stopProcessong}}
> blocks busyLock and not release it intentionally.
> The issue has been found on TeamCity in [Zookeeper's
> suite|https://ci.ignite.apache.org/viewLog.html?buildId=2768270=IgniteTests24Java8_ZooKeeperDiscovery2]
> with the following stack trace:
> {code:java}
> disco-notifier-worker-#569118%client4%"
> #609288
> prio=5 os_prio=0 tid=0x7f905b440800 nid=0x3f6fbd
> sleeping[0x7f9383efd000]
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.ignite.internal.util.GridSpinReadWriteLock.writeLock(GridSpinReadWriteLock.java:204)
> at
> org.apache.ignite.internal.util.GridSpinBusyLock.block(GridSpinBusyLock.java:76)
> at
> org.apache.ignite.internal.processors.service.ServiceDeploymentManager.stopProcessing(ServiceDeploymentManager.java:137)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.stopProcessor(IgniteServiceProcessor.java:261)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.onDisconnected(IgniteServiceProcessor.java:429)
> at
> org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:4010)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:819)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:602)
> - locked <0xf7ecdfa0> (a java.lang.Object)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4$$Lambda$25/2087171109.run(Unknown
> Source)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2696)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2734)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10796) Migrate from JUnit 3 to 4 suites involving IgniteTestSuite
[
https://issues.apache.org/jira/browse/IGNITE-10796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743435#comment-16743435
]
Eduard Shangareev commented on IGNITE-10796:
[~oignatenko], I've looked through. Looks good! Thank you for contribution.
> Migrate from JUnit 3 to 4 suites involving IgniteTestSuite
> --
>
> Key: IGNITE-10796
> URL: https://issues.apache.org/jira/browse/IGNITE-10796
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This task is to migrate from JUnit 3 to 4 test suites suites involving
> {{IgniteTestSuite}} API that was introduced per IGNITE-3658.
> If needed, refer parent task comments for more details.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10880) Document how we should evolve our persistence functionality while keeping it compatible with files created by old versions
[ https://issues.apache.org/jira/browse/IGNITE-10880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16742207#comment-16742207 ] Eduard Shangareev commented on IGNITE-10880: [~agoncharuk], I have looked through, and in theory, it's covered well, but practical aspects not at all. I believe that there would be many questions when somebody would want to change WAL record or page layout. So, I would ask you to add the next topics: -when compatibility would be broken - adding new field etc; -how to add new versions of previous records/pageIo and absolutely new things. > Document how we should evolve our persistence functionality while keeping it > compatible with files created by old versions > -- > > Key: IGNITE-10880 > URL: https://issues.apache.org/jira/browse/IGNITE-10880 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Eduard Shangareev >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.8 > > > It's not documented at all (???). > We need complete documentation to not break compatibility with previously > created database files while updating/evolving code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10931) Get rid of GridTestUtils#addTestIfNeeded
Eduard Shangareev created IGNITE-10931: -- Summary: Get rid of GridTestUtils#addTestIfNeeded Key: IGNITE-10931 URL: https://issues.apache.org/jira/browse/IGNITE-10931 Project: Ignite Issue Type: Task Reporter: Eduard Shangareev It could be replaced with Assume. It will allow to remove some suites with replacing them by new TC configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10931) Get rid of GridTestUtils#addTestIfNeeded
[ https://issues.apache.org/jira/browse/IGNITE-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev reassigned IGNITE-10931: -- Assignee: Eduard Shangareev > Get rid of GridTestUtils#addTestIfNeeded > > > Key: IGNITE-10931 > URL: https://issues.apache.org/jira/browse/IGNITE-10931 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > > It could be replaced with Assume. > It will allow to remove some suites with replacing them by new TC > configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10931) Get rid of GridTestUtils#addTestIfNeeded
[ https://issues.apache.org/jira/browse/IGNITE-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev updated IGNITE-10931: --- Issue Type: Improvement (was: Task) > Get rid of GridTestUtils#addTestIfNeeded > > > Key: IGNITE-10931 > URL: https://issues.apache.org/jira/browse/IGNITE-10931 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Shangareev >Priority: Major > > It could be replaced with Assume. > It will allow to remove some suites with replacing them by new TC > configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10775) Migrate from JUnit 3 to 4 test suites of simple dynamic lists that use addTestIfNeeded API
[
https://issues.apache.org/jira/browse/IGNITE-10775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739547#comment-16739547
]
Eduard Shangareev commented on IGNITE-10775:
[~oignatenko], looks good! Thank you for your endless efforts in tests
improving :)
> Migrate from JUnit 3 to 4 test suites of simple dynamic lists that use
> addTestIfNeeded API
> --
>
> Key: IGNITE-10775
> URL: https://issues.apache.org/jira/browse/IGNITE-10775
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> This task is to migrate from JUnit 3 to 4 test suites of simple dynamic lists
> that use {{GridTestUtils.addTestIfNeeded}} API.
> If needed, refer parent task comments for more details.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10880) Document how we should evolve our persistence functionality while keeping it compatible with files created by old versions
Eduard Shangareev created IGNITE-10880: -- Summary: Document how we should evolve our persistence functionality while keeping it compatible with files created by old versions Key: IGNITE-10880 URL: https://issues.apache.org/jira/browse/IGNITE-10880 Project: Ignite Issue Type: Task Components: documentation Reporter: Eduard Shangareev Assignee: Alexey Goncharuk It's not documented at all (???). We need complete documentation to not break compatibility with previously created database files while updating/evolving code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10873) CorruptedTreeException during simultaneous cache put operations
[
https://issues.apache.org/jira/browse/IGNITE-10873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev updated IGNITE-10873:
---
Description:
{code}
[2019-01-09 20:47:04,376][ERROR][pool-9-thread-9][GridDhtAtomicCache]
Unexpected exception during cache update
org.h2.message.DbException: General error: "class
org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
Runtime failure on row: Row@780acfb4[ key: .. ][ GTEST, null, 254, null,
null, null, null, 0, null, null, null, null, null, null, null, 0, 0, 0, null,
0, 0, 0, 0, 0, 0, 0, null, 0, 0, null, 0, null, 0, null, 0, null, null, null,
0, 0, 0, 0, 0, 0, null, null, null, null, null, null, null, 0.0, 0, 0.0, 0,
0.0, 0, null, 0, 0, 0, 0, null, null, null, null, null, null, null, null, null,
null, null, null, null, null, null, null ]" [5-197]
at org.h2.message.DbException.get(DbException.java:168)
at org.h2.message.DbException.convert(DbException.java:307)
at
org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:302)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.addToIndex(GridH2Table.java:546)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:479)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:768)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1905)
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:404)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:2633)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1646)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1621)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1935)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:428)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2295)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2494)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1951)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1780)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1668)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1153)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:611)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2449)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2426)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1105)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:820)
at IndexCorruptionReproducer$1.run(IndexCorruptionReproducer.java:43)
at
java.util.concurrent.Executors$RunnableAdapter.call$$$capture(Executors.java:511)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java)
at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266)
at java.util.concurrent.FutureTask.run(FutureTask.java)
at
[jira] [Comment Edited] (IGNITE-10774) Migrate test suites that are fixed lists of test classes from Junit 3 to 4
[
https://issues.apache.org/jira/browse/IGNITE-10774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729597#comment-16729597
]
Eduard Shangareev edited comment on IGNITE-10774 at 12/27/18 3:41 PM:
--
[~oignatenko], looks good. Thank you for the contribution!
was (Author: edshanggg):
[~oignatenko], looks good! Thank you for the contribution.
> Migrate test suites that are fixed lists of test classes from Junit 3 to 4
> --
>
> Key: IGNITE-10774
> URL: https://issues.apache.org/jira/browse/IGNITE-10774
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> This task is to migrate test suites that are fixed lists of test classes from
> Junit 3 to 4 that can be handled by {{@SuiteClasses}} API.
> If needed, find more details in the comments of the parent task.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10773) Migrate examples testsuites from Junit 3 to 4
[ https://issues.apache.org/jira/browse/IGNITE-10773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729607#comment-16729607 ] Eduard Shangareev edited comment on IGNITE-10773 at 12/27/18 3:41 PM: -- [~oignatenko], looks good! Thank you for moving tests to JUnit 4. was (Author: edshanggg): [~oignatenko], looks good. Thank you for moving tests to JUnit 4! > Migrate examples testsuites from Junit 3 to 4 > - > > Key: IGNITE-10773 > URL: https://issues.apache.org/jira/browse/IGNITE-10773 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.8 >Reporter: Oleg Ignatenko >Assignee: Oleg Ignatenko >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > This taks is to migrate examples testsuites from Junit 3 to 4. If needed, > find more details in comments of parent task -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10828) GridAbstractTest calculates test count incorrectly
[ https://issues.apache.org/jira/browse/IGNITE-10828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev updated IGNITE-10828: --- Fix Version/s: 2.8 > GridAbstractTest calculates test count incorrectly > -- > > Key: IGNITE-10828 > URL: https://issues.apache.org/jira/browse/IGNITE-10828 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > Fix For: 2.8 > > > I have found that our naive approach doesn't work. In my case, it counted > while 112 while IDEA 113, what cause wrong isLastTest result. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10828) GridAbstractTest calculates test count incorrectly
[ https://issues.apache.org/jira/browse/IGNITE-10828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev updated IGNITE-10828: --- Ignite Flags: (was: Docs Required) > GridAbstractTest calculates test count incorrectly > -- > > Key: IGNITE-10828 > URL: https://issues.apache.org/jira/browse/IGNITE-10828 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > > I have found that our naive approach doesn't work. In my case, it counted > while 112 while IDEA 113, what cause wrong isLastTest result. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10773) migrate examples testsuites from Junit 3 to 4
[ https://issues.apache.org/jira/browse/IGNITE-10773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729607#comment-16729607 ] Eduard Shangareev commented on IGNITE-10773: [~oignatenko], looks good. Thank you for moving tests to JUnit 4! > migrate examples testsuites from Junit 3 to 4 > - > > Key: IGNITE-10773 > URL: https://issues.apache.org/jira/browse/IGNITE-10773 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.8 >Reporter: Oleg Ignatenko >Assignee: Oleg Ignatenko >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > This taks is to migrate examples testsuites from Junit 3 to 4. If needed, > find more details in comments of parent task -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10774) migrate test suites that are fixed lists of test classes from Junit 3 to 4
[
https://issues.apache.org/jira/browse/IGNITE-10774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729597#comment-16729597
]
Eduard Shangareev commented on IGNITE-10774:
[~oignatenko], looks good! Thank you for the contribution.
> migrate test suites that are fixed lists of test classes from Junit 3 to 4
> --
>
> Key: IGNITE-10774
> URL: https://issues.apache.org/jira/browse/IGNITE-10774
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> This task is to migrate test suites that are fixed lists of test classes from
> Junit 3 to 4 that can be handled by {{@SuiteClasses}} API.
> If needed, find more details in the comments of the parent task.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10828) GridAbstractTest calculates test count incorrectly
[ https://issues.apache.org/jira/browse/IGNITE-10828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev reassigned IGNITE-10828: -- Assignee: Eduard Shangareev > GridAbstractTest calculates test count incorrectly > -- > > Key: IGNITE-10828 > URL: https://issues.apache.org/jira/browse/IGNITE-10828 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > > I have found that our naive approach doesn't work. In my case, it counted > while 112 while IDEA 113, what cause wrong isLastTest result. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10828) GridAbstractTest calculates test count incorrectly
[ https://issues.apache.org/jira/browse/IGNITE-10828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev updated IGNITE-10828: --- Summary: GridAbstractTest calculates test count incorrectly (was: GridAbstractTest wrongly calculates test count) > GridAbstractTest calculates test count incorrectly > -- > > Key: IGNITE-10828 > URL: https://issues.apache.org/jira/browse/IGNITE-10828 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Priority: Major > > I have found that our naive approach doesn't work. In my case, it counted > while 112 while IDEA 113, what cause wrong isLastTest result. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10828) GridAbstractTest wrongly calculates test count
Eduard Shangareev created IGNITE-10828: -- Summary: GridAbstractTest wrongly calculates test count Key: IGNITE-10828 URL: https://issues.apache.org/jira/browse/IGNITE-10828 Project: Ignite Issue Type: Bug Reporter: Eduard Shangareev I have found that our naive approach doesn't work. In my case, it counted while 112 while IDEA 113, what cause wrong isLastTest result. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7616) GridDataStreamExecutor and GridCallbackExecutor JMX beans return incorrect values due to invalid interface registration.
[
https://issues.apache.org/jira/browse/IGNITE-7616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16728759#comment-16728759
]
Eduard Shangareev commented on IGNITE-7616:
---
[~syssoftsol], hi! I looked through, looks good, but there is no any test. And
there are already conflicts with master :(
{code}
ObjectName anyInstance =
ignite.configuration().getMBeanServer().queryNames(null,
Query.isInstanceOf(new
StringValueExp("org.apache.YourMXBeanClassName"))).iterator().next();
// Invoke operation
Object val =
ignite.configuration().getMBeanServer().invoke(anyInstance, "yourMethod", null,
null);
{code}
You could use this snippet for test coverage of new MX bean.
> GridDataStreamExecutor and GridCallbackExecutor JMX beans return incorrect
> values due to invalid interface registration.
>
>
> Key: IGNITE-7616
> URL: https://issues.apache.org/jira/browse/IGNITE-7616
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Max Shonichev
>Assignee: David Harvey
>Priority: Major
> Labels: jmx
> Fix For: 2.8
>
> Attachments: image-2018-10-03-10-23-24-676.png,
> image-2018-10-03-10-24-12-459.png, master_1b3742f4d7_mxbeans_threads2.patch
>
>
> Two of newly added management beans as a result of implementing feature
> request https://issues.apache.org/jira/browse/IGNITE-7217 have bugs:
> # GridDataStreamExecutor is registered as conforming to ThreadPoolMXBean
> interface, though actually it is an incompatible StripedExecutor.
> # GridCallbackExecutor is registered as conforming to ThreadPoolMXBean
> interface, though actually it is an incompatible
> IgniteStripedThreadPoolExecutor.
> # ThreadPoolMXBeanAdapter checks whether adapted instance is
> ThreadPoolExecutor, and as interfaces are incompatible, most of the JMX
> attributes of GridCallbackExecutor and GridDataStreamExecutor are returned as
> -1 or null.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10177) cleanup Junit 3 from the project
[
https://issues.apache.org/jira/browse/IGNITE-10177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16727324#comment-16727324
]
Eduard Shangareev commented on IGNITE-10177:
[~oignatenko], looks good! Thank you for contribution. There are only few steps
to complete moving from JUnit 3 to 4.
> cleanup Junit 3 from the project
>
>
> Key: IGNITE-10177
> URL: https://issues.apache.org/jira/browse/IGNITE-10177
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
>
> If needed, refer parent task for more details.
> # remove Junit3-specific parts of API of GridAbstractTest and its subclasses
> # remove dependencies from Junit 3 in Maven (if there are any)
> # migrate tests that were missed at prior steps for various reasons:
> ## untangle design of {{IgnitePdsContinuousRestartTest}} and its subclass
> which currently conflict with Junit4 execution because of using constructors
> and make them properly use {{@Test}} annotation
> ## find out why
> {{WalCompactionTest.testCompressorToleratesEmptyWalSegmentsFsync}} appears to
> start running slow / timing out after adding Junit 4 annotations (reproduced
> this on teamcity and locally as was discovered in IGNITE-10175)
> ## find out why {{IgniteTwitterStreamerTest}} runs fine under JUnit 3 but
> starts failing after move to JUnit 4
> ## IgniteCachePartitionedQuerySelfTest,
> IgniteCacheReplicatedQueryP2PDisabledSelfTest, ComputeUtilsTest,
> CacheBasedDatasetBuilderTest, CacheBasedDatasetTest,
> GridPartitionedCacheJtaLookupClassNameSelfTest,
> GridReplicatedCacheJtaLookupClassNameSelfTest (there were problems migrating
> these at IGNITE-10176)
> ## find out why tests in logging suite failed on teamcity (not locally) when
> setup method was annotated {{@Before}}
> ## (!) note part of this work related to
> {{IgniteConfigVariationsAbstractTest}} is expected to be done separately per
> IGNITE-10739
> # in tests suite classes, change {{extends TestSuite}} to either
> {{@RunWith(AllTests.class)}} or {{@Suite.SuiteClasses}}
> # find and update all Junit3-specific code that {{extends TestCase}}
> # execute junit related inspections of IDE and analyse results
> # remove redundant references to {{JUnit4.class}} if there are any (like in
> {{@RunWith(JUnit4.class)}})
> (i) per discussion with [~EdShangGG] plan to to do this in a separate
> ticket for smoother merges - IGNITE-10758
> Side note if for some reason it turns out critically important to keep test
> suites names (by default Junit 4 will use suite class names instead),
> approach with custom description annotation [described
> here|https://stackoverflow.com/questions/34745080/is-it-possible-to-name-a-test-suite-in-junit-4/34745518]
> can be used to address that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8911) While cache is restarting it's possible to start new cache with this name
[ https://issues.apache.org/jira/browse/IGNITE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726256#comment-16726256 ] Eduard Shangareev commented on IGNITE-8911: --- [~DmitriyGovorukhin], I don't think that statement in your first point is true. As I see, GridStripedReadWriteLock contains collections of java ReadWriteLock and it is all. > While cache is restarting it's possible to start new cache with this name > - > > Key: IGNITE-8911 > URL: https://issues.apache.org/jira/browse/IGNITE-8911 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > Fix For: 2.8 > > > We have the state "restarting" for caches when we certainly now that these > caches would start at some moment in future. But we could start new cache > with the same name. > Plus, NPE is throwing when we try to get proxy for such caches (in > "restarting" state). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10176) migrate non-core modules tests from Junit 3 to 4
[
https://issues.apache.org/jira/browse/IGNITE-10176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16721592#comment-16721592
]
Eduard Shangareev commented on IGNITE-10176:
[~oignatenko], I have looked through, looks great! Enormous efforts.
> migrate non-core modules tests from Junit 3 to 4
>
>
> Key: IGNITE-10176
> URL: https://issues.apache.org/jira/browse/IGNITE-10176
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
>
> If needed, refer parent task for more details.
> Migrate using new API introduced and tested at prior step.
> Also, make sure that there are no inappropriate annotations in methods that
> override {{beforeTest}} and {{afterTest}} as explained in more details [in
> comments
> below|https://issues.apache.org/jira/browse/IGNITE-10176?focusedCommentId=16718914=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16718914].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10670) investigate why Cassandra modules don't have testsuite(s)
[ https://issues.apache.org/jira/browse/IGNITE-10670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev updated IGNITE-10670: --- Labels: MakeTeamcityGreenAgain (was: ) > investigate why Cassandra modules don't have testsuite(s) > - > > Key: IGNITE-10670 > URL: https://issues.apache.org/jira/browse/IGNITE-10670 > Project: Ignite > Issue Type: Task >Affects Versions: 2.8 >Reporter: Oleg Ignatenko >Priority: Major > Labels: MakeTeamcityGreenAgain > > Unlike most if not all other Ignite modules, > [cassandra|https://github.com/apache/ignite/tree/master/modules/cassandra] > currently doesn't have testsuites. > Find out why is that and if it is a matter of simple omission, add testsuites > and integrate them in Teamcity. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8849) Split suites to achieve 1 hour per suite run
[ https://issues.apache.org/jira/browse/IGNITE-8849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev resolved IGNITE-8849. --- Resolution: Fixed > Split suites to achieve 1 hour per suite run > > > Key: IGNITE-8849 > URL: https://issues.apache.org/jira/browse/IGNITE-8849 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10623) Possible JVM crash when node stopped with errors
[
https://issues.apache.org/jira/browse/IGNITE-10623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev updated IGNITE-10623:
---
Summary: Possible JVM crash when node stopped with errors (was: Possible
JVM crash in case of stopping node with errors)
> Possible JVM crash when node stopped with errors
>
>
> Key: IGNITE-10623
> URL: https://issues.apache.org/jira/browse/IGNITE-10623
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> {noformat}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x03a23bde,
> pid=5444, tid=0x18d0
> #
> # JRE version: Java(TM) SE Runtime Environment (8.0_102-b14) (build
> 1.8.0_102-b14)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.102-b14 mixed mode
> windows-amd64 compressed oops)
> # Problematic frame:
> # J 25052 C2
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(IJZ)J
> (1421 bytes) @ 0x03a23bde [0x03a23800+0x3de]
> #
> # Core dump written. Default location:
> C:\BuildAgent\work\81a8bed9f07f3feb\ggprivate\hs_err_pid5444.mdmp
> #
> # If you would like to submit a bug report, please visit:
> # http://bugreport.java.com/bugreport/crash.jsp
> {noformat}
> Seems that it was caused by an erroneous stop on a node which left
> checkpoint-thread alive.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10623) Possible JVM crash in case of stopping node with errors
[
https://issues.apache.org/jira/browse/IGNITE-10623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev updated IGNITE-10623:
---
Labels: MakeTeamcityGreenAgain (was: )
> Possible JVM crash in case of stopping node with errors
> ---
>
> Key: IGNITE-10623
> URL: https://issues.apache.org/jira/browse/IGNITE-10623
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> {noformat}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x03a23bde,
> pid=5444, tid=0x18d0
> #
> # JRE version: Java(TM) SE Runtime Environment (8.0_102-b14) (build
> 1.8.0_102-b14)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.102-b14 mixed mode
> windows-amd64 compressed oops)
> # Problematic frame:
> # J 25052 C2
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(IJZ)J
> (1421 bytes) @ 0x03a23bde [0x03a23800+0x3de]
> #
> # Core dump written. Default location:
> C:\BuildAgent\work\81a8bed9f07f3feb\ggprivate\hs_err_pid5444.mdmp
> #
> # If you would like to submit a bug report, please visit:
> # http://bugreport.java.com/bugreport/crash.jsp
> {noformat}
> Seems that it was caused by an erroneous stop on a node which left
> checkpoint-thread alive.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10623) Possible JVM crash in case of stopping node with errors
Eduard Shangareev created IGNITE-10623:
--
Summary: Possible JVM crash in case of stopping node with errors
Key: IGNITE-10623
URL: https://issues.apache.org/jira/browse/IGNITE-10623
Project: Ignite
Issue Type: Bug
Reporter: Eduard Shangareev
Assignee: Eduard Shangareev
{noformat}
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x03a23bde, pid=5444,
tid=0x18d0
#
# JRE version: Java(TM) SE Runtime Environment (8.0_102-b14) (build
1.8.0_102-b14)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.102-b14 mixed mode
windows-amd64 compressed oops)
# Problematic frame:
# J 25052 C2
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(IJZ)J
(1421 bytes) @ 0x03a23bde [0x03a23800+0x3de]
#
# Core dump written. Default location:
C:\BuildAgent\work\81a8bed9f07f3feb\ggprivate\hs_err_pid5444.mdmp
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
{noformat}
Seems that it was caused by an erroneous stop on a node which left
checkpoint-thread alive.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10492) No need to normalize QueryEntities if cache in restarting state.
[ https://issues.apache.org/jira/browse/IGNITE-10492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16714784#comment-16714784 ] Eduard Shangareev commented on IGNITE-10492: Looks good! [~zstan], thank you for contribution. > No need to normalize QueryEntities if cache in restarting state. > > > Key: IGNITE-10492 > URL: https://issues.apache.org/jira/browse/IGNITE-10492 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.6 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Fix For: 2.8 > > > After IGNITE-7976 implementation we can obtain caches with erroneous > normalized QueryEntities. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8911) While cache is restarting it's possible to start new cache with this name
[ https://issues.apache.org/jira/browse/IGNITE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev updated IGNITE-8911: -- Fix Version/s: 2.8 > While cache is restarting it's possible to start new cache with this name > - > > Key: IGNITE-8911 > URL: https://issues.apache.org/jira/browse/IGNITE-8911 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > Fix For: 2.8 > > > We have the state "restarting" for caches when we certainly now that these > caches would start at some moment in future. But we could start new cache > with the same name. > Plus, NPE is throwing when we try to get proxy for such caches (in > "restarting" state). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10440) Analyse test suites for possible acceleration
[ https://issues.apache.org/jira/browse/IGNITE-10440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16714159#comment-16714159 ] Eduard Shangareev commented on IGNITE-10440: [~aplatonov], I have looked through. Looks good. It should help in decreasing Run All runtime. Thank you for your contribution. > Analyse test suites for possible acceleration > - > > Key: IGNITE-10440 > URL: https://issues.apache.org/jira/browse/IGNITE-10440 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10175) migrate core module tests from Junit 3 to 4
[ https://issues.apache.org/jira/browse/IGNITE-10175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16714129#comment-16714129 ] Eduard Shangareev commented on IGNITE-10175: [~oignatenko], I have looked through your change (huge one) and it looks ready to merge. Thank you for enormous efforts. > migrate core module tests from Junit 3 to 4 > --- > > Key: IGNITE-10175 > URL: https://issues.apache.org/jira/browse/IGNITE-10175 > Project: Ignite > Issue Type: Sub-task >Reporter: Oleg Ignatenko >Assignee: Oleg Ignatenko >Priority: Major > Labels: MakeTeamcityGreenAgain > > If needed, refer parent task for more details. > Migrate using new API introduced at prior step. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10175) migrate core module tests from Junit 3 to 4
[ https://issues.apache.org/jira/browse/IGNITE-10175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711933#comment-16711933 ] Eduard Shangareev edited comment on IGNITE-10175 at 12/6/18 9:24 PM: - I have looked through! It's great. Enormous efforts, thank you! :) But I have found that if you had renamed the test, it wouldn't be run from a suite. I believe, we need to wrap all tests in JUnit4Adapter. was (Author: edshanggg): I have looked through! It's great. Enormous efforts, thank you! :) > migrate core module tests from Junit 3 to 4 > --- > > Key: IGNITE-10175 > URL: https://issues.apache.org/jira/browse/IGNITE-10175 > Project: Ignite > Issue Type: Sub-task >Reporter: Oleg Ignatenko >Assignee: Oleg Ignatenko >Priority: Major > Labels: MakeTeamcityGreenAgain > > If needed, refer parent task for more details. > Migrate using new API introduced at prior step. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10175) migrate core module tests from Junit 3 to 4
[ https://issues.apache.org/jira/browse/IGNITE-10175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711933#comment-16711933 ] Eduard Shangareev commented on IGNITE-10175: I have looked through! It's great. Enormous efforts, thank you! :) > migrate core module tests from Junit 3 to 4 > --- > > Key: IGNITE-10175 > URL: https://issues.apache.org/jira/browse/IGNITE-10175 > Project: Ignite > Issue Type: Sub-task >Reporter: Oleg Ignatenko >Assignee: Oleg Ignatenko >Priority: Major > Labels: MakeTeamcityGreenAgain > > If needed, refer parent task for more details. > Migrate using new API introduced at prior step. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10442) Failed checks on successful tasks canceling
[ https://issues.apache.org/jira/browse/IGNITE-10442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16710057#comment-16710057 ] Eduard Shangareev commented on IGNITE-10442: Looks good! Thank you for contribution. > Failed checks on successful tasks canceling > --- > > Key: IGNITE-10442 > URL: https://issues.apache.org/jira/browse/IGNITE-10442 > Project: Ignite > Issue Type: Test >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Trivial > Fix For: 2.8 > > > Test on checks that tasks canceling does not lead to node failure > [testFailNodesOnCanceledTask|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-1511425443970810161=testDetails_IgniteTests24Java8=%3Cdefault%3E] > seems flaky. > One of the reason - "Possible thread pool starvation detected": there are 16 > NUM_TASKS, which invoke in separate threads. Default size of ignite thread > pool is 8. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-4380) Cache invoke calls can be lost
[
https://issues.apache.org/jira/browse/IGNITE-4380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16709072#comment-16709072
]
Eduard Shangareev commented on IGNITE-4380:
---
Would change status and assignee because of long silence time.
> Cache invoke calls can be lost
> --
>
> Key: IGNITE-4380
> URL: https://issues.apache.org/jira/browse/IGNITE-4380
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.0
>Reporter: Semen Boikov
>Assignee: Alexey Kuznetsov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
>
> * Recently added test
> GridCacheAbstractFullApiSelfTest.testInvokeAllMultithreaded fails on TC in
> various configurations with transactional cache.
> Example of failure
> GridCacheReplicatedOffHeapTieredMultiNodeFullApiSelfTest.testInvokeAllMultithreaded:
> {noformat}
> junit.framework.AssertionFailedError: expected:<2> but was:<10868>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.Assert.assertEquals(Assert.java:241)
> at junit.framework.TestCase.assertEquals(TestCase.java:409)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAbstractFullApiSelfTest.testInvokeAllMultithreaded(GridCacheAbstractFullApiSelfTest.java:342)
> at sun.reflect.GeneratedMethodAccessor96.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1803)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1718)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-4380) Cache invoke calls can be lost
[
https://issues.apache.org/jira/browse/IGNITE-4380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev reassigned IGNITE-4380:
-
Assignee: Eduard Shangareev (was: Alexey Kuznetsov)
> Cache invoke calls can be lost
> --
>
> Key: IGNITE-4380
> URL: https://issues.apache.org/jira/browse/IGNITE-4380
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.0
>Reporter: Semen Boikov
>Assignee: Eduard Shangareev
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
>
> * Recently added test
> GridCacheAbstractFullApiSelfTest.testInvokeAllMultithreaded fails on TC in
> various configurations with transactional cache.
> Example of failure
> GridCacheReplicatedOffHeapTieredMultiNodeFullApiSelfTest.testInvokeAllMultithreaded:
> {noformat}
> junit.framework.AssertionFailedError: expected:<2> but was:<10868>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.Assert.assertEquals(Assert.java:241)
> at junit.framework.TestCase.assertEquals(TestCase.java:409)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAbstractFullApiSelfTest.testInvokeAllMultithreaded(GridCacheAbstractFullApiSelfTest.java:342)
> at sun.reflect.GeneratedMethodAccessor96.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1803)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1718)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-4380) Cache invoke calls can be lost
[
https://issues.apache.org/jira/browse/IGNITE-4380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev reassigned IGNITE-4380:
-
Assignee: (was: Eduard Shangareev)
> Cache invoke calls can be lost
> --
>
> Key: IGNITE-4380
> URL: https://issues.apache.org/jira/browse/IGNITE-4380
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.0
>Reporter: Semen Boikov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
>
> * Recently added test
> GridCacheAbstractFullApiSelfTest.testInvokeAllMultithreaded fails on TC in
> various configurations with transactional cache.
> Example of failure
> GridCacheReplicatedOffHeapTieredMultiNodeFullApiSelfTest.testInvokeAllMultithreaded:
> {noformat}
> junit.framework.AssertionFailedError: expected:<2> but was:<10868>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.Assert.assertEquals(Assert.java:241)
> at junit.framework.TestCase.assertEquals(TestCase.java:409)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAbstractFullApiSelfTest.testInvokeAllMultithreaded(GridCacheAbstractFullApiSelfTest.java:342)
> at sun.reflect.GeneratedMethodAccessor96.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1803)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1718)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10514) Cache validation on the primary node may result in AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-10514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev updated IGNITE-10514:
---
Labels: MakeTeamcityGreenAgain (was: )
> Cache validation on the primary node may result in AssertionError
> -
>
> Key: IGNITE-10514
> URL: https://issues.apache.org/jira/browse/IGNITE-10514
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> Cache validation on the primary node, that was introduced by IGNITE-10413,
> may lead to the following AssertionError.
> {code:java}
> java.lang.AssertionError: GridDhtPartitionsExchangeFuture
> [firstDiscoEvt=DiscoveryCustomEvent [customMsg=CacheAffinityChangeMessage
> [...]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1788)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1671)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3184)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:138)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:273)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:268)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1059)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:584)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:383)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:309)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:100)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:299)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1568)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1196)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1092)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Let's consider the following scenario:
> * Start one node and upload data.
> * Start a new node (note that this step triggers rebalancing).
> * Start explicit transaction and try to update atomic cache (it is assumed
> that atomic operation are allowed for use inside transactions, see Ignite
> system property DFLT_ALLOW_ATOMIC_OPS_IN_TX)
> {code:java}
> IgniteTransactions txs = ignite.transactions();
> try (Transaction tx = txs.txStart()) {
> atomicCache.put();
> tx.commit();
> }
> {code}
> Let's assume that the transaction mapped on the topology version that is
> related to {{NODE_JOIN}} event,
> on the other hand, the corresponding request
> {{GridNearAtomicAbstractUpdateRequest}} can be validated on the primary node
> using the next topology version, triggered by {{CacheAffinityMessage}}.
> {code:java|title=GridDhtAtomicCache.java}
> private void updateAllAsyncInternal0() {
> ...
> if (validateCache) {
> GridDhtTopologyFuture topFut = top.topologyVersionFuture();
> // There is a chance that the topFut is not done yet!
> assert topFut.isDone() : topFut;
> Throwable err = topFut.validateCache(ctx, req.recovery(), false,
> null, null);
> ...
> }
> }{code}
> That is the root cause of the {{AssertionError}} mentioned above.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9304) AssertionError while updating ATOMIC cache while topology changes
[
https://issues.apache.org/jira/browse/IGNITE-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev reassigned IGNITE-9304:
-
Assignee: (was: Eduard Shangareev)
> AssertionError while updating ATOMIC cache while topology changes
> -
>
> Key: IGNITE-9304
> URL: https://issues.apache.org/jira/browse/IGNITE-9304
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Priority: Major
>
> I have reproduced it with
> CacheContinuousQueryFailoverAbstractSelfTest#testMultiThreadedFailover.
> {code}
> java.lang.AssertionError: Assertion error on search row:
> org.apache.ignite.internal.processors.cache.tree.SearchRow@257eba3
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1655)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1306)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:381)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1789)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2471)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1930)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1772)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1662)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3111)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:133)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:269)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:264)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1056)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1$2$1.run(GridCacheIoManager.java:275)
> 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:745)
> Caused by: java.lang.AssertionError: Invalid version for inner update
> [isNew=false, entry=GridDhtCacheEntry [rdrs=ReaderId[] [], part=2,
> super=GridDistributedCacheEntry [super=CacheObjectImpl [val=null,
> hasValBytes=true]CacheObjectImpl [val=null, hasValBytes=true],
> ver=GridCacheVersion [topVer=145812931, order=1534332978541, nodeOrder=37],
> hash=2, extras=null, flags=0]]], newVer=GridCacheVersion [topVer=145812931,
> order=1534332978538, nodeOrder=43]]
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.versionCheck(GridCacheMapEntry.java:5397)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:4778)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:4562)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:3104)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.access$6200(BPlusTree.java:2998)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:1744)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1622)
> ... 20 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10478) SQL index creation fails if cache, which query method was called, was statically configured
Eduard Shangareev created IGNITE-10478:
--
Summary: SQL index creation fails if cache, which query method was
called, was statically configured
Key: IGNITE-10478
URL: https://issues.apache.org/jira/browse/IGNITE-10478
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Eduard Shangareev
{code}
javax.cache.CacheException: Cache doesn't exist: cache2
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:698)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:637)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:455)
at
org.gridgain.grid.internal.processors.cache.database.IgniteDbSnapshotSameTopologyTest.testDynamicIndexForStaticCacheRestoredWithRebuild(IgniteDbSnapshotSameTopologyTest.java:1469)
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 junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2166)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:144)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2082)
at java.lang.Thread.run(Thread.java:745)
Caused by: class
org.apache.ignite.internal.processors.query.IgniteSQLException: Cache doesn't
exist: cache2
at
org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.convert(DdlStatementsProcessor.java:642)
at
org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:242)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFieldsNative(IgniteH2Indexing.java:1661)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1823)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2175)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2170)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2678)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$0(GridQueryProcessor.java:2184)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2204)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2165)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2126)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:686)
... 12 more
{code}
As I see it is thrown from
{code}
if (cache == null || !F.eq(depId, cache.context().dynamicDeploymentId()))
throw new
SchemaOperationException(SchemaOperationException.CODE_CACHE_NOT_FOUND,
cacheName);
{code}
at
org.apache.ignite.internal.processors.query.GridQueryProcessor#processSchemaOperationLocal.
And the second check fails.
It looks strange from my point of view why we throw CODE_CACHE_NOT_FOUND in
this case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10350) Document that now it's allowed to stop caches created via SQL/DDL via Java API
[ https://issues.apache.org/jira/browse/IGNITE-10350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701992#comment-16701992 ] Eduard Shangareev commented on IGNITE-10350: If it was never documented then I would add a comment that via SQL you could destroy only caches which were created via SQL/DDL. I think, it should be in DDL documentation. > Document that now it's allowed to stop caches created via SQL/DDL via Java API > -- > > Key: IGNITE-10350 > URL: https://issues.apache.org/jira/browse/IGNITE-10350 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Eduard Shangareev >Priority: Major > > We need to update our documentation that behavior has changed. > https://issues.apache.org/jira/browse/IGNITE-10328 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9948) JettyRestProcessorAuthenticationWithTokenSelfTest.testGetOrCreateCache fails on TC
[
https://issues.apache.org/jira/browse/IGNITE-9948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16700380#comment-16700380
]
Eduard Shangareev edited comment on IGNITE-9948 at 11/27/18 12:55 PM:
--
Looks good. Thank you for the contribution!
was (Author: edshanggg):
Looks good. Thank you for contribution!
> JettyRestProcessorAuthenticationWithTokenSelfTest.testGetOrCreateCache fails
> on TC
> ---
>
> Key: IGNITE-9948
> URL: https://issues.apache.org/jira/browse/IGNITE-9948
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> [Example of
> fail.|https://ci.ignite.apache.org/viewLog.html?buildId=2118632=buildResultsDiv=IgniteTests24Java8_JavaClient#testNameId-4416495803371140089]
> Log details:
> {noformat}
> [2018-10-19 06:59:53,063][ERROR][main][root] Test failed.
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.rest.JettyRestProcessorAbstractSelfTest.checkGetOrCreateAndDestroy(JettyRestProcessorAbstractSelfTest.java:593)
> at
> org.apache.ignite.internal.processors.rest.JettyRestProcessorAbstractSelfTest.testGetOrCreateCache(JettyRestProcessorAbstractSelfTest.java:619)
> 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 junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:142)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2091)
> at java.lang.Thread.run(Thread.java:748){noformat}
> The possible reason is the race between getting cache instance on different
> nodes:
> # Jetty query create cache successfully on one node.
> # PME doesn't have completed.
> # The test fails with NPE while getting the instance of cache on another node.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9948) JettyRestProcessorAuthenticationWithTokenSelfTest.testGetOrCreateCache fails on TC
[
https://issues.apache.org/jira/browse/IGNITE-9948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16700380#comment-16700380
]
Eduard Shangareev commented on IGNITE-9948:
---
Looks good. Thank you for contribution!
> JettyRestProcessorAuthenticationWithTokenSelfTest.testGetOrCreateCache fails
> on TC
> ---
>
> Key: IGNITE-9948
> URL: https://issues.apache.org/jira/browse/IGNITE-9948
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> [Example of
> fail.|https://ci.ignite.apache.org/viewLog.html?buildId=2118632=buildResultsDiv=IgniteTests24Java8_JavaClient#testNameId-4416495803371140089]
> Log details:
> {noformat}
> [2018-10-19 06:59:53,063][ERROR][main][root] Test failed.
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.rest.JettyRestProcessorAbstractSelfTest.checkGetOrCreateAndDestroy(JettyRestProcessorAbstractSelfTest.java:593)
> at
> org.apache.ignite.internal.processors.rest.JettyRestProcessorAbstractSelfTest.testGetOrCreateCache(JettyRestProcessorAbstractSelfTest.java:619)
> 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 junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:142)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2091)
> at java.lang.Thread.run(Thread.java:748){noformat}
> The possible reason is the race between getting cache instance on different
> nodes:
> # Jetty query create cache successfully on one node.
> # PME doesn't have completed.
> # The test fails with NPE while getting the instance of cache on another node.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10343) Stop grid anyway in testGetRestartReplicated
[ https://issues.apache.org/jira/browse/IGNITE-10343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16699409#comment-16699409 ] Eduard Shangareev commented on IGNITE-10343: Looks good. > Stop grid anyway in testGetRestartReplicated > > > Key: IGNITE-10343 > URL: https://issues.apache.org/jira/browse/IGNITE-10343 > Project: Ignite > Issue Type: Test >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: MakeTeamcityGreenAgain, stability, test-fail > > In the test > [testGetRestartReplicated|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=7917326378982816549=testDetails] > it is necessary to add startGrid/stopGrid in try/finally block to stop grid > anyway even error between startGrid and stopGrid was raised. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9948) JettyRestProcessorAuthenticationWithTokenSelfTest.testGetOrCreateCache fails on TC
[
https://issues.apache.org/jira/browse/IGNITE-9948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16698907#comment-16698907
]
Eduard Shangareev commented on IGNITE-9948:
---
[~NSAmelchev], hi!
I have looked through your change. It looks good, but could you rename, please,
jsonResponse to something sounding (like validateJsonResponse). Without reading
javaDoc it is not clear what it does.
> JettyRestProcessorAuthenticationWithTokenSelfTest.testGetOrCreateCache fails
> on TC
> ---
>
> Key: IGNITE-9948
> URL: https://issues.apache.org/jira/browse/IGNITE-9948
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> [Example of
> fail.|https://ci.ignite.apache.org/viewLog.html?buildId=2118632=buildResultsDiv=IgniteTests24Java8_JavaClient#testNameId-4416495803371140089]
> Log details:
> {noformat}
> [2018-10-19 06:59:53,063][ERROR][main][root] Test failed.
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.rest.JettyRestProcessorAbstractSelfTest.checkGetOrCreateAndDestroy(JettyRestProcessorAbstractSelfTest.java:593)
> at
> org.apache.ignite.internal.processors.rest.JettyRestProcessorAbstractSelfTest.testGetOrCreateCache(JettyRestProcessorAbstractSelfTest.java:619)
> 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 junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:142)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2091)
> at java.lang.Thread.run(Thread.java:748){noformat}
> The possible reason is the race between getting cache instance on different
> nodes:
> # Jetty query create cache successfully on one node.
> # PME doesn't have completed.
> # The test fails with NPE while getting the instance of cache on another node.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10350) Document that now it's allowed to stop caches created via SQL/DDL via Java API
[ https://issues.apache.org/jira/browse/IGNITE-10350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev updated IGNITE-10350: --- Summary: Document that now it's allowed to stop caches created via SQL/DDL via Java API (was: Document that now it's allowed to stop caches created via SQL/DDL) > Document that now it's allowed to stop caches created via SQL/DDL via Java API > -- > > Key: IGNITE-10350 > URL: https://issues.apache.org/jira/browse/IGNITE-10350 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Eduard Shangareev >Priority: Major > > We need to update our documentation that behavior has changed. > https://issues.apache.org/jira/browse/IGNITE-10328 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
