[jira] [Issue Comment Deleted] (IGNITE-7823) Separate cache for non collocated IgniteSet.

[Pavel Pereslegin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-7823:
-
Comment: was deleted

(was: Implementation details.
* DataStructuresProcessor#compatibleCache creates separate cache for each new 
non-collocated version of IgniteSet (method IgniteSet#close destroys this 
cache).
 * A new implementation of IgniteSet called IgniteCacheSetImpl was introduced 
(also a separate proxy IgniteCacheSetProxy was created), duplicate code 
(GridCacheSetImpl and GridCacheSetProxy) should be removed in next major 
release.
 * Header is not used by non-collocated version of IgniteSet. Header is needed 
to identify keys in the shared cache, but with separate cache the 
GridCacheSetImpl implementation serves as an adapter for Set operations on this 
cache and does not require header.
 * CacheDataStructuresManager#set creates new instance of non-collocated 
version on each invocation.)

> Separate cache for non collocated IgniteSet.
> 
>
> Key: IGNITE-7823
> URL: https://issues.apache.org/jira/browse/IGNITE-7823
> Project: Ignite
>  Issue Type: New Feature
>  Components: data structures
>Reporter: Andrey Kuznetsov
>Assignee: Pavel Pereslegin
>Priority: Major
> Fix For: 2.6
>
>
> Currently, single data structures cache is shared between several collection 
> instances (IgniteQueue, IgniteSet).
> To support iterator() and size() IgniteSet maintains plain on-heap Java sets 
> on every node (see CacheDataStructuresManager.setDataMap). These sets 
> duplicate backing-cache entries, both primary and backup. For big 
> non-collocated sets it's too expensive to maintain redundant onheap data 
> copies. The simplest way to avoid copies is to use separate cache for 
> non-collocated IgniteSet version; hence size of set is the same as size of 
> backing cache, and also set iterator is virtually the same as backing cache 
> iterator. 
> The difference between exising set implementation and set based on separate 
> cache should be properly documented afterwards.



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

[jira] [Commented] (IGNITE-7917) Thin client: document missing data types

[Denis Magda (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16481058#comment-16481058
 ] 

Denis Magda commented on IGNITE-7917:
-

[~isapego], shall we close the ticket then?

> Thin client: document missing data types
> 
>
> Key: IGNITE-7917
> URL: https://issues.apache.org/jira/browse/IGNITE-7917
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, thin client
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.5
>
>
> Docs page: 
> https://apacheignite.readme.io/docs/binary-client-protocol#data-format
> Missing data types:
> COL = 24
> ENUM = 28
> ENUM_ARR = 29
> DECIMAL = 30
> DECIMAL_ARR = 31
> TIMESTAMP = 33
> TIMESTAMP_ARR = 34
> TIME = 36
> TIME_ARR = 37



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

[jira] [Commented] (IGNITE-8316) Update RPM and DEB documentation

[Denis Magda (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16481056#comment-16481056
 ] 

Denis Magda commented on IGNITE-8316:
-

[~vveider], we need to have a DEB section similar to the RPM's on readme.io: 
https://apacheignite.readme.io/docs/getting-started#section-rpm-package-installation

Please edit the hidden 2.5 version of the page: 
https://apacheignite.readme.io/v2.4/docs/getting-started-25

Once you're ready, reassign the ticket to [~pgarg] who will update the 
downloads page on the site.

> Update RPM and DEB documentation
> 
>
> Key: IGNITE-8316
> URL: https://issues.apache.org/jira/browse/IGNITE-8316
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Major
> Fix For: 2.5
>
>
> # Add DEB repository configuration and packages installation.
> # Update RPM repository configuration and packages installation.



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

[jira] [Commented] (IGNITE-6113) Partition eviction prevents exchange from completion

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480925#comment-16480925
 ] 

ASF GitHub Bot commented on IGNITE-6113:


Github user Jokser closed the pull request at:

https://github.com/apache/ignite/pull/3672


> Partition eviction prevents exchange from completion
> 
>
> Key: IGNITE-6113
> URL: https://issues.apache.org/jira/browse/IGNITE-6113
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, persistence
>Affects Versions: 2.1
>Reporter: Vladislav Pyatkov
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.5
>
>
> I has waited for 3 hours for completion without any success.
> exchange-worker is blocked.
> {noformat}
> "exchange-worker-#92%DPL_GRID%grid554.ca.sbrf.ru%" #173 prio=5 os_prio=0 
> tid=0x7f0835c2e000 nid=0xb907 runnable [0x7e74ab1d]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0x7efee630a7c0> (a 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition$1)
> at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:189)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:139)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.assign(GridDhtPreloader.java:340)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1801)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
>Locked ownable synchronizers:
> - None
> {noformat}
> {noformat}
> "sys-#124%DPL_GRID%grid554.ca.sbrf.ru%" #278 prio=5 os_prio=0 
> tid=0x7e731c02d000 nid=0xbf4d runnable [0x7e734e7f7000]
>java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.FileDispatcherImpl.write(FileDispatcherImpl.java:60)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:51)
> at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:211)
> - locked <0x7f056161bf88> (a java.lang.Object)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.writeBuffer(FileWriteAheadLogManager.java:1829)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.flush(FileWriteAheadLogManager.java:1572)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.addRecord(FileWriteAheadLogManager.java:1421)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.access$800(FileWriteAheadLogManager.java:1331)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager.log(FileWriteAheadLogManager.java:339)
> at 
> org.gridgain.grid.internal.processors.cache.database.pagemem.PageMemoryImpl.beforeReleaseWrite(PageMemoryImpl.java:1287)
> at 
> org.gridgain.grid.internal.processors.cache.database.pagemem.PageMemoryImpl.writeUnlockPage(PageMemoryImpl.java:1142)
> at 
> org.gridgain.grid.internal.processors.cache.database.pagemem.PageImpl.releaseWrite(PageImpl.java:167)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writeUnlock(PageHandler.java:193)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writePage(PageHandler.java:242)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writePage(PageHandler.java:119)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.doRemoveFromLeaf(BPlusTree.java:2886)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.removeFromLeaf(BPlusTree.java:2865)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.access$6900(BPlusTree.java:2515)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.removeDown(BPlusTree.java:1607)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.removeDown(BPlusTree.java:1574)
> at 
> 

[jira] [Commented] (IGNITE-8116) Historic WAL rebalance fails

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480923#comment-16480923
 ] 

ASF GitHub Bot commented on IGNITE-8116:


Github user Jokser closed the pull request at:

https://github.com/apache/ignite/pull/3791


> Historic WAL rebalance fails
> 
>
> Key: IGNITE-8116
> URL: https://issues.apache.org/jira/browse/IGNITE-8116
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Eduard Shangareev
>Assignee: Pavel Kovalenko
>Priority: Critical
> Fix For: 2.5
>
>
> So, my reproducer fails because rebalance is never completed. 
> Rebalance fails with next error:
> {code}
> Exception in thread "sys-#95%wal.IgniteWalRebalanceTest0%" 
> java.lang.AssertionError
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionSupplier.handleDemandMessage(GridDhtPartitionSupplier.java:390)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleDemandMessage(GridDhtPreloader.java:364)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:372)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:357)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$700(GridCacheIoManager.java:99)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1603)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4100(GridIoManager.java:125)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2752)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1516)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4400(GridIoManager.java:125)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$10.run(GridIoManager.java:1485)
>   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}
> Reproducer:
> {code}
> /*
>  * Licensed to the Apache Software Foundation (ASF) under one or more
>  * contributor license agreements.  See the NOTICE file distributed with
>  * this work for additional information regarding copyright ownership.
>  * The ASF licenses this file to You under the Apache License, Version 2.0
>  * (the "License"); you may not use this file except in compliance with
>  * the License.  You may obtain a copy of the License at
>  *
>  *  http://www.apache.org/licenses/LICENSE-2.0
>  *
>  * Unless required by applicable law or agreed to in writing, software
>  * distributed under the License is distributed on an "AS IS" BASIS,
>  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
>  * See the License for the specific language governing permissions and
>  * limitations under the License.
>  */
> package org.apache.ignite.internal.processors.cache.persistence.db.wal;
> import java.util.concurrent.TimeUnit;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.CacheRebalanceMode;
> import org.apache.ignite.cache.affinity.rendezvous.RendezvousAffinityFunction;
> import org.apache.ignite.cache.query.annotations.QuerySqlField;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.DataRegionConfiguration;
> import org.apache.ignite.configuration.DataStorageConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.configuration.WALMode;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.internal.util.typedef.internal.S;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import static 
> org.apache.ignite.IgniteSystemProperties.IGNITE_PDS_WAL_REBALANCE_THRESHOLD;
> /**
>  * Historic WAL rebalance test
>  */
> public class IgniteWalRebalanceTest extends 

[jira] [Commented] (IGNITE-8405) Sql query may see intermediate results of topology changes and perform mapping incorrectly

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480922#comment-16480922
 ] 

ASF GitHub Bot commented on IGNITE-8405:


Github user Jokser closed the pull request at:

https://github.com/apache/ignite/pull/4019


> Sql query may see intermediate results of topology changes and perform 
> mapping incorrectly
> --
>
> Key: IGNITE-8405
> URL: https://issues.apache.org/jira/browse/IGNITE-8405
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, sql
>Affects Versions: 2.4
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.5
>
>
> Affected test: IgniteStableBaselineCacheQueryNodeRestartsSelfTest
> Sql query do mapping in following way:
> 1) If there is at least 1 moving partition query will be mapped to current 
> partition owners
> 2) In other case affinity mapping will be used.
> In case of first approach query may see not final partition state if mapping 
> happens during PME. There is "setOwners()" method which does partition 
> movement one-by-one, each time obtaining topology write lock. If query 
> mapping happens in this time it may see that there is some moving partition 
> and performed mapping to OWNING partition which will be moved to MOVING on 
> next "setOwners()" invocation.
> As result we may query from invalid partitions.
> As intermediate solution "setOwners()" method should be refactored in a batch 
> way to perform ALL partitions state changes to MOVING in one operation.
> As general solution query mapping should be revisited, especially 
> "isPreloadingActive" method, to take into account given topology version.



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

[jira] [Updated] (IGNITE-8022) Need to add README.txt for ignite-direct-io

[Andrey Gura (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Gura updated IGNITE-8022:

Fix Version/s: (was: 2.5)
   2.6

> Need to add README.txt for ignite-direct-io
> ---
>
> Key: IGNITE-8022
> URL: https://issues.apache.org/jira/browse/IGNITE-8022
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.4
>Reporter: Ksenia Rybakova
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.6
>
>
> Need to add README.txt for ignite-direct-io



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

[jira] [Commented] (IGNITE-8528) Peer deployment does not work for continuous query transformers

[Andrey Gura (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480911#comment-16480911
 ] 

Andrey Gura commented on IGNITE-8528:
-

Merged to master and ignite-2.5 branches.

> Peer deployment does not work for continuous query transformers
> ---
>
> Key: IGNITE-8528
> URL: https://issues.apache.org/jira/browse/IGNITE-8528
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Alexey Goncharuk
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.5
>
>
> Build local Ignite distribution using
> {code}
> mvn clean install -Pall-java,all-scala,licenses -DskipTests
> mvn initialize -Prelease
> {code}
> Start one node in console and run continuous query with transformer example 
> in IDE. I am getting the following exception:
> {code}
> [15:30:43] To start Console Management & Monitoring run 
> ignitevisorcmd.{sh|bat}
> [15:30:43] 
> [15:30:43] Ignite node started OK (id=f1356a5b)
> [15:30:43] Topology snapshot [ver=1, servers=1, clients=0, CPUs=16, 
> offheap=19.0GB, heap=2.0GB]
> [15:30:43]   ^-- Node [id=F1356A5B-4CDB-4480-A64F-35BF2C96DBB5, 
> clusterState=ACTIVE]
> [15:30:43] Data Regions Configured:
> [15:30:43]   ^-- default [initSize=256.0 MiB, maxSize=18.9 GiB, 
> persistenceEnabled=false]
> [15:30:52] Topology snapshot [ver=2, servers=2, clients=0, CPUs=16, 
> offheap=38.0GB, heap=3.0GB]
> [15:30:52]   ^-- Node [id=F1356A5B-4CDB-4480-A64F-35BF2C96DBB5, 
> clusterState=ACTIVE]
> [15:30:52] Data Regions Configured:
> [15:30:52]   ^-- default [initSize=256.0 MiB, maxSize=18.9 GiB, 
> persistenceEnabled=false]
> [15:30:53,065][SEVERE][tcp-disco-msg-worker-#2][BinaryContext] Failed to 
> deserialize object [typeName=java.lang.invoke.SerializedLambda]
> class org.apache.ignite.binary.BinaryObjectException: Failed to read field 
> [name=capturingClass]
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:870)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1982)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:698)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:183)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:870)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>   at 
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:310)
>   at 
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:99)
>   at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9962)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9991)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryDeployableObject.unmarshal(CacheContinuousQueryDeployableObject.java:94)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandlerV3.p2pUnmarshal(CacheContinuousQueryHandlerV3.java:155)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1327)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$400(GridContinuousProcessor.java:108)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:200)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:191)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:707)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:589)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5479)
>   at 
> 

[jira] [Commented] (IGNITE-8501) Retry on GridServiceNotFoundException in GridServiceProxy needs to be fixed

[Stanislav Lukyanov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480890#comment-16480890
 ] 

Stanislav Lukyanov commented on IGNITE-8501:


[~dmitry.pavlov], could you please review and merge into master?

> Retry on GridServiceNotFoundException in GridServiceProxy needs to be fixed
> ---
>
> Key: IGNITE-8501
> URL: https://issues.apache.org/jira/browse/IGNITE-8501
> Project: Ignite
>  Issue Type: Bug
>Reporter: Stanislav Lukyanov
>Assignee: Stanislav Lukyanov
>Priority: Major
> Fix For: 2.6
>
>
> `GridServiceProxy::invokeMethod` attempts to invoke a method of an Ignite 
> service and performs retries in case the invocation procedure throws 
> `GridServiceNotFoundException` or `ClusterTopologyCheckedException` (these 
> exceptions may be thrown in case the service assignments were already 
> calculated, but the service instance was not yet created and initialized on 
> the affinity server).
> After the fix IGNITE-7904 the exception type thrown by the remote invocation 
> code changed to `IgniteCheckedException` (with a cause being 
> `GridServiceNotFoundException` or `ClusterTopologyCheckedException`). Because 
> of that, the retry doesn't work now.
> Need to fix the code to correctly handle new exception chain.



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

[jira] [Commented] (IGNITE-8085) Flaky failures in Ignite Client Nodes test suite: Remote node could not start.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480883#comment-16480883
 ] 

ASF GitHub Bot commented on IGNITE-8085:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3767


> Flaky failures in Ignite Client Nodes test suite:  Remote node could not 
> start. 
> 
>
> Key: IGNITE-8085
> URL: https://issues.apache.org/jira/browse/IGNITE-8085
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
>   Ignite Start Nodes 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls (master 
> fail rate 12,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodes (master fail rate 
> 10,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodesByIds (master fail rate 
> 10,1%) 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1179745277331816127=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-842929918974855010=%3Cdefault%3E=testDetails
> Test itself is quite old. Last commits were from [~tledkov-gridgain] at 2017.
>  {noformat}
> class org.apache.ignite.IgniteException: Remote node could not start. See log 
> for details: 
> /data/teamcity/work/bd85361428dcdb1/work/log/ignite-startNodes/03-29-2018--02-47-24-2003434e.log
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:388)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:383)
> at 
> org.apache.ignite.internal.util.lang.GridFunc.forEach(GridFunc.java:1897)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls(IgniteProjectionStartStopRestartSelfTest.java:383)
> 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:2002)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1917)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

[jira] [Resolved] (IGNITE-8085) Flaky failures in Ignite Client Nodes test suite: Remote node could not start.

[Dmitriy Pavlov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov resolved IGNITE-8085.

Resolution: Fixed

[~ivanan.fed] thank you. I've merged this fix. Let's see if it helps.

[~ein], thank you for giving this valuable advice.

> Flaky failures in Ignite Client Nodes test suite:  Remote node could not 
> start. 
> 
>
> Key: IGNITE-8085
> URL: https://issues.apache.org/jira/browse/IGNITE-8085
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
>   Ignite Start Nodes 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls (master 
> fail rate 12,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodes (master fail rate 
> 10,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodesByIds (master fail rate 
> 10,1%) 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1179745277331816127=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-842929918974855010=%3Cdefault%3E=testDetails
> Test itself is quite old. Last commits were from [~tledkov-gridgain] at 2017.
>  {noformat}
> class org.apache.ignite.IgniteException: Remote node could not start. See log 
> for details: 
> /data/teamcity/work/bd85361428dcdb1/work/log/ignite-startNodes/03-29-2018--02-47-24-2003434e.log
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:388)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:383)
> at 
> org.apache.ignite.internal.util.lang.GridFunc.forEach(GridFunc.java:1897)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls(IgniteProjectionStartStopRestartSelfTest.java:383)
> 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:2002)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1917)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

[jira] [Commented] (IGNITE-8469) Non-heap memroy leak for calling cluster activation multi times

[Alexey Goncharuk (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480876#comment-16480876
 ] 

Alexey Goncharuk commented on IGNITE-8469:
--

[~Mmuzaf] got it, looks good to me.

> Non-heap memroy leak for calling cluster activation multi times
> ---
>
> Key: IGNITE-8469
> URL: https://issues.apache.org/jira/browse/IGNITE-8469
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.6
>
>
> Calling multiple time cluster (with enabled persistence and started client 
> nodes) activation {{ig3CB.cluster().active(true);}} leads to non-heap memory 
> leak.
> Line 
> {{org/apache/ignite/internal/pagemem/impl/PageMemoryNoStoreImpl.java:234}} 
> looks suspicious because of in case method 
> {{org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl#start}} 
> callled multi times (e.g. activate(true) called multi times) we lost info 
> about allocated regions.



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

[jira] [Updated] (IGNITE-8085) Flaky failures in Ignite Client Nodes test suite: Remote node could not start.

[Dmitriy Pavlov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov updated IGNITE-8085:
---
Fix Version/s: 2.6

> Flaky failures in Ignite Client Nodes test suite:  Remote node could not 
> start. 
> 
>
> Key: IGNITE-8085
> URL: https://issues.apache.org/jira/browse/IGNITE-8085
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
>   Ignite Start Nodes 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls (master 
> fail rate 12,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodes (master fail rate 
> 10,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodesByIds (master fail rate 
> 10,1%) 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1179745277331816127=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-842929918974855010=%3Cdefault%3E=testDetails
> Test itself is quite old. Last commits were from [~tledkov-gridgain] at 2017.
>  {noformat}
> class org.apache.ignite.IgniteException: Remote node could not start. See log 
> for details: 
> /data/teamcity/work/bd85361428dcdb1/work/log/ignite-startNodes/03-29-2018--02-47-24-2003434e.log
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:388)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:383)
> at 
> org.apache.ignite.internal.util.lang.GridFunc.forEach(GridFunc.java:1897)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls(IgniteProjectionStartStopRestartSelfTest.java:383)
> 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:2002)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1917)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

[jira] [Commented] (IGNITE-8238) Operation can fails with unexpected RuntimeException when node is stopping.

[Andrew Mashenkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480874#comment-16480874
 ] 

Andrew Mashenkov commented on IGNITE-8238:
--

Why can't we wrap NodeStoppedException into IgniteException in checkpoint 
Lock\Unlock methods and then just catch it in unwindEvicts() method where 
exception with NodeStopped cause will be Ignored?

Simple rethrowing IllegalStateException still will not give user understanding  
if requested operation was performed or not.

> Operation can fails with unexpected RuntimeException when node is stopping.
> ---
>
> Key: IGNITE-8238
> URL: https://issues.apache.org/jira/browse/IGNITE-8238
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Andrew Mashenkov
>Assignee: Alexander Menshikov
>Priority: Minor
> Fix For: 2.6
>
>
> Operation can fails with RuntimeException when node is stoped in other 
> thread. 
> It is not clear from javadoc that operation can throws RuntimeException.
>  We should add it to javadoc or e.g. throws IllegalStateException which 
> already present in java cache api javadoc.
> Failure in thread: Thread [id=3484, name=updater-2]
> java.lang.RuntimeException: Failed to perform cache update: node is stopping.
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1350)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:1685)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:796)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:197)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:834)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheGateway.leaveNoLock(GridCacheGateway.java:240)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheGateway.leave(GridCacheGateway.java:225)
>  at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.onLeave(GatewayProtectedCacheProxy.java:1708)
>  at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.putAll(GatewayProtectedCacheProxy.java:945)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.IgnitePdsContinuousRestartTest$1.call(IgnitePdsContinuousRestartTest.java:261)
>  at org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)



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

[jira] [Commented] (IGNITE-8531) NPE is thrown on destroying empty partition

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480871#comment-16480871
 ] 

ASF GitHub Bot commented on IGNITE-8531:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/4026


> NPE is thrown on destroying empty partition
> ---
>
> Key: IGNITE-8531
> URL: https://issues.apache.org/jira/browse/IGNITE-8531
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.5
>Reporter: Sergey Chugunov
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.5
>
>
> Improvement IGNITE-8320 introduced situation when NPE may happen: in case of 
> destroying empty partition checkpoint record isn't logged to WAL but code 
> attempts to create checkpoint marker anyway which leads to NPE.
> We need to allow checkpointing empty partitions.



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

[jira] [Commented] (IGNITE-8531) NPE is thrown on destroying empty partition

[Alexey Goncharuk (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480870#comment-16480870
 ] 

Alexey Goncharuk commented on IGNITE-8531:
--

Looks good to me, merged to master.

> NPE is thrown on destroying empty partition
> ---
>
> Key: IGNITE-8531
> URL: https://issues.apache.org/jira/browse/IGNITE-8531
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.5
>Reporter: Sergey Chugunov
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.5
>
>
> Improvement IGNITE-8320 introduced situation when NPE may happen: in case of 
> destroying empty partition checkpoint record isn't logged to WAL but code 
> attempts to create checkpoint marker anyway which leads to NPE.
> We need to allow checkpointing empty partitions.



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

[jira] [Updated] (IGNITE-8528) Peer deployment does not work for continuous query transformers

[Andrey Gura (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Gura updated IGNITE-8528:

Fix Version/s: (was: 2.6)
   2.5

> Peer deployment does not work for continuous query transformers
> ---
>
> Key: IGNITE-8528
> URL: https://issues.apache.org/jira/browse/IGNITE-8528
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Alexey Goncharuk
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.5
>
>
> Build local Ignite distribution using
> {code}
> mvn clean install -Pall-java,all-scala,licenses -DskipTests
> mvn initialize -Prelease
> {code}
> Start one node in console and run continuous query with transformer example 
> in IDE. I am getting the following exception:
> {code}
> [15:30:43] To start Console Management & Monitoring run 
> ignitevisorcmd.{sh|bat}
> [15:30:43] 
> [15:30:43] Ignite node started OK (id=f1356a5b)
> [15:30:43] Topology snapshot [ver=1, servers=1, clients=0, CPUs=16, 
> offheap=19.0GB, heap=2.0GB]
> [15:30:43]   ^-- Node [id=F1356A5B-4CDB-4480-A64F-35BF2C96DBB5, 
> clusterState=ACTIVE]
> [15:30:43] Data Regions Configured:
> [15:30:43]   ^-- default [initSize=256.0 MiB, maxSize=18.9 GiB, 
> persistenceEnabled=false]
> [15:30:52] Topology snapshot [ver=2, servers=2, clients=0, CPUs=16, 
> offheap=38.0GB, heap=3.0GB]
> [15:30:52]   ^-- Node [id=F1356A5B-4CDB-4480-A64F-35BF2C96DBB5, 
> clusterState=ACTIVE]
> [15:30:52] Data Regions Configured:
> [15:30:52]   ^-- default [initSize=256.0 MiB, maxSize=18.9 GiB, 
> persistenceEnabled=false]
> [15:30:53,065][SEVERE][tcp-disco-msg-worker-#2][BinaryContext] Failed to 
> deserialize object [typeName=java.lang.invoke.SerializedLambda]
> class org.apache.ignite.binary.BinaryObjectException: Failed to read field 
> [name=capturingClass]
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:870)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1982)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:698)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:183)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:870)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>   at 
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:310)
>   at 
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:99)
>   at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9962)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9991)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryDeployableObject.unmarshal(CacheContinuousQueryDeployableObject.java:94)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandlerV3.p2pUnmarshal(CacheContinuousQueryHandlerV3.java:155)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1327)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$400(GridContinuousProcessor.java:108)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:200)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:191)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:707)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:589)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5479)
>   at 
> 

[jira] [Commented] (IGNITE-605) [Test] TODO in GridAbstractTest w/ comment "propose another way to avoid network overhead in tests"

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480841#comment-16480841
 ] 

Dmitriy Pavlov commented on IGNITE-605:
---

[~Mmuzaf], I've merged removal. Could you please resolve ticket?

> [Test] TODO in GridAbstractTest w/ comment "propose another way to avoid 
> network overhead in tests"
> ---
>
> Key: IGNITE-605
> URL: https://issues.apache.org/jira/browse/IGNITE-605
> Project: Ignite
>  Issue Type: Bug
>Reporter: Artem Shutak
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: Muted_test
>
> See GG-4048



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

[jira] [Commented] (IGNITE-6846) Add metrics for entry processor invocations

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480834#comment-16480834
 ] 

Dmitriy Pavlov commented on IGNITE-6846:


[~DmitriyGovorukhin], could you please take a look?

Feel free to involve me into (re)running tests and check its result, run 
additional plugin(s) tests if necessary.

> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.6
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



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

[jira] [Commented] (IGNITE-605) [Test] TODO in GridAbstractTest w/ comment "propose another way to avoid network overhead in tests"

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480819#comment-16480819
 ] 

ASF GitHub Bot commented on IGNITE-605:
---

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/4027


> [Test] TODO in GridAbstractTest w/ comment "propose another way to avoid 
> network overhead in tests"
> ---
>
> Key: IGNITE-605
> URL: https://issues.apache.org/jira/browse/IGNITE-605
> Project: Ignite
>  Issue Type: Bug
>Reporter: Artem Shutak
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: Muted_test
>
> See GG-4048



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

[jira] [Commented] (IGNITE-8463) Node.js: setup TeamCity

[Alexey Kosenchuk (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480818#comment-16480818
 ] 

Alexey Kosenchuk commented on IGNITE-8463:
--

Tests updated - the required output added.

> Node.js: setup TeamCity
> ---
>
> Key: IGNITE-8463
> URL: https://issues.apache.org/jira/browse/IGNITE-8463
> Project: Ignite
>  Issue Type: Sub-task
>  Components: thin client
>Reporter: Vladimir Ozerov
>Assignee: Peter Ivanov
>Priority: Major
>
> Minimal implementation of NodeJS client is almost ready (IGNITE-8014). We 
> need to figure out how to integrate it with TeamCity:
> 1) New suite for NodeJS is needed along with required environment (npm, any 
> recent version). 2) Suite should be able to run Jasmine tests [1]
> 3) Currently all tests rely on manually started external node. We need to 
> create a set of scripts (bash?) to start/stop nodes locally from Jasmine. Raw 
> suggestion: call {{ignite.sh}} with predefined configuration.
> [1] https://jasmine.github.io/



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

[jira] [Comment Edited] (IGNITE-8476) AssertionError exception occurs when trying to remove node from baseline under loading

[Dmitry Sherstobitov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480807#comment-16480807
 ] 

Dmitry Sherstobitov edited comment on IGNITE-8476 at 5/18/18 3:33 PM:
--

Another test scenario with no transactional loading:
 # Start cluster, load data
 # Start client
 # Create transactional cache
 # Start long transactions (transactions with infinite sleep() and interrupt 
variable to call commit() on it)
 # Add new node in cluster that is not in baseline
 # Release transactions after some minor timeout
 # Try to get values from cluster that was affected by this long transactions

First 3 cache.get() are successful, next get() hangs and throw Assertion in 
server logs


was (Author: qvad):
Another test scenario with no transactional loading:
 # Start cluster, load data
 # Start client
 # Create transactional cache
 # Start long transactions (transactions with infinite sleep() and interrupt 
variable to call commit() on it)
 # Add new node in cluster that not in baseline
 # Release transactions after some minor timeout
 # Try to get values from cluster that was affected by this long transactions

First 3 cache.get() are successful, next get() hangs and throw Assertion in 
server logs

> AssertionError exception occurs when trying to remove node from baseline 
> under loading
> --
>
> Key: IGNITE-8476
> URL: https://issues.apache.org/jira/browse/IGNITE-8476
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Assignee: Ivan Rakov
>Priority: Blocker
>
> Run 6 nodes, start loading (8 threads, 1000 2x cache.get() and 2x cache.put() 
> in each thread per second)
> Kill 2 nodes and try to remove one node from baseline using
> control.sh --baseline remove node1
>  control.sh --baseline version TOPOLOGY_VERSION
>  
> Utility hangs or connected client may hangs, this assertion appears in log 
> For transactional cache:
> {code:java}
> [16:32:58,960][SEVERE][sys-stripe-14-#15][G] Failed to execute runnable.
> java.lang.AssertionError: localNode = be945692-c750-4d72-b9a1-9ac4170ff125, 
> dhtNodes = [ZookeeperClusterNode [id=810226e6-656a-460d-8069-ca7d2dd294ef, 
> addrs=[172.17.0.1, 0:0:0:0:0:0:0:1%lo, 172.25.1.28, 127.0.0.1], order=1, 
> loc=false, client=false], ZookeeperClusterNode 
> [id=be945692-c750-4d72-b9a1-9ac4170ff125, addrs=[172.17.0.1, 172.25.1.28, 
> 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=3, loc=true, client=false], 
> ZookeeperClusterNode [id=db4503f6-9185-4673-b38c-8890dfa69511, 
> addrs=[172.17.0.1, 172.25.1.37, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=5, 
> loc=false, client=false], ZookeeperClusterNode 
> [id=3b8d8d4f-3513-4d39-a1fd-7ec5b15fc653, addrs=[172.17.0.1, 172.25.1.37, 
> 127.0.0.1, 0:0:0:0:0:0:0:1%lo], order=4, loc=false, client=false], 
> ZookeeperClusterNode [id=2bfc8c2e-2f47-4126-9cc4-6f017ce7efde, 
> addrs=[172.17.0.1, 172.25.1.37, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=6, 
> loc=false, client=false]]
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.map(GridDhtTxPrepareFuture.java:1520)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1239)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:671)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1048)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:397)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:516)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:150)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:135)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:97)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:177)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:175)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at 
> 

[jira] [Comment Edited] (IGNITE-8476) AssertionError exception occurs when trying to remove node from baseline under loading

[Dmitry Sherstobitov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480807#comment-16480807
 ] 

Dmitry Sherstobitov edited comment on IGNITE-8476 at 5/18/18 3:33 PM:
--

Another test scenario with no transactional loading:
 # Start cluster, load data
 # Start client
 # Create transactional cache
 # Start long transactions (transactions with infinite sleep() and interrupt 
variable to call commit() on it)
 # Add new node in cluster that not in baseline
 # Release transactions after some minor timeout
 # Try to get values from cluster that was affected by this long transactions

First 3 cache.get() are successful, next get() hangs and throw Assertion in 
server logs


was (Author: qvad):
Another test scenario with no transactional loading:
 # Start cluster, load data
 # Start client
 # Create transactional cache
 # Start long transactions (transactions with infinite sleep() and interrupt 
variable to call commit() on it)
 # Release transactions after some minor timeout
 # Try to get values from cluster that was affected by this long transactions

First 3 cache.get() are successful, next get() hangs and throw Assertion in 
server logs

> AssertionError exception occurs when trying to remove node from baseline 
> under loading
> --
>
> Key: IGNITE-8476
> URL: https://issues.apache.org/jira/browse/IGNITE-8476
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Assignee: Ivan Rakov
>Priority: Blocker
>
> Run 6 nodes, start loading (8 threads, 1000 2x cache.get() and 2x cache.put() 
> in each thread per second)
> Kill 2 nodes and try to remove one node from baseline using
> control.sh --baseline remove node1
>  control.sh --baseline version TOPOLOGY_VERSION
>  
> Utility hangs or connected client may hangs, this assertion appears in log 
> For transactional cache:
> {code:java}
> [16:32:58,960][SEVERE][sys-stripe-14-#15][G] Failed to execute runnable.
> java.lang.AssertionError: localNode = be945692-c750-4d72-b9a1-9ac4170ff125, 
> dhtNodes = [ZookeeperClusterNode [id=810226e6-656a-460d-8069-ca7d2dd294ef, 
> addrs=[172.17.0.1, 0:0:0:0:0:0:0:1%lo, 172.25.1.28, 127.0.0.1], order=1, 
> loc=false, client=false], ZookeeperClusterNode 
> [id=be945692-c750-4d72-b9a1-9ac4170ff125, addrs=[172.17.0.1, 172.25.1.28, 
> 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=3, loc=true, client=false], 
> ZookeeperClusterNode [id=db4503f6-9185-4673-b38c-8890dfa69511, 
> addrs=[172.17.0.1, 172.25.1.37, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=5, 
> loc=false, client=false], ZookeeperClusterNode 
> [id=3b8d8d4f-3513-4d39-a1fd-7ec5b15fc653, addrs=[172.17.0.1, 172.25.1.37, 
> 127.0.0.1, 0:0:0:0:0:0:0:1%lo], order=4, loc=false, client=false], 
> ZookeeperClusterNode [id=2bfc8c2e-2f47-4126-9cc4-6f017ce7efde, 
> addrs=[172.17.0.1, 172.25.1.37, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=6, 
> loc=false, client=false]]
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.map(GridDhtTxPrepareFuture.java:1520)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1239)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:671)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1048)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:397)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:516)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:150)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:135)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:97)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:177)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:175)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at 
> 

[jira] [Commented] (IGNITE-8476) AssertionError exception occurs when trying to remove node from baseline under loading

[Dmitry Sherstobitov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480807#comment-16480807
 ] 

Dmitry Sherstobitov commented on IGNITE-8476:
-

Another test scenario with no transactional loading:
 # Start cluster, load data
 # Start client
 # Create transactional cache
 # Start long transactions (transactions with infinite sleep() and interrupt 
variable to call commit() on it)
 # Release transactions after some minor timeout
 # Try to get values from cluster that was affected by this long transactions

First 3 cache.get() are successful, next get() hangs and throw Assertion in 
server logs

> AssertionError exception occurs when trying to remove node from baseline 
> under loading
> --
>
> Key: IGNITE-8476
> URL: https://issues.apache.org/jira/browse/IGNITE-8476
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Assignee: Ivan Rakov
>Priority: Blocker
>
> Run 6 nodes, start loading (8 threads, 1000 2x cache.get() and 2x cache.put() 
> in each thread per second)
> Kill 2 nodes and try to remove one node from baseline using
> control.sh --baseline remove node1
>  control.sh --baseline version TOPOLOGY_VERSION
>  
> Utility hangs or connected client may hangs, this assertion appears in log 
> For transactional cache:
> {code:java}
> [16:32:58,960][SEVERE][sys-stripe-14-#15][G] Failed to execute runnable.
> java.lang.AssertionError: localNode = be945692-c750-4d72-b9a1-9ac4170ff125, 
> dhtNodes = [ZookeeperClusterNode [id=810226e6-656a-460d-8069-ca7d2dd294ef, 
> addrs=[172.17.0.1, 0:0:0:0:0:0:0:1%lo, 172.25.1.28, 127.0.0.1], order=1, 
> loc=false, client=false], ZookeeperClusterNode 
> [id=be945692-c750-4d72-b9a1-9ac4170ff125, addrs=[172.17.0.1, 172.25.1.28, 
> 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=3, loc=true, client=false], 
> ZookeeperClusterNode [id=db4503f6-9185-4673-b38c-8890dfa69511, 
> addrs=[172.17.0.1, 172.25.1.37, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=5, 
> loc=false, client=false], ZookeeperClusterNode 
> [id=3b8d8d4f-3513-4d39-a1fd-7ec5b15fc653, addrs=[172.17.0.1, 172.25.1.37, 
> 127.0.0.1, 0:0:0:0:0:0:0:1%lo], order=4, loc=false, client=false], 
> ZookeeperClusterNode [id=2bfc8c2e-2f47-4126-9cc4-6f017ce7efde, 
> addrs=[172.17.0.1, 172.25.1.37, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=6, 
> loc=false, client=false]]
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.map(GridDhtTxPrepareFuture.java:1520)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1239)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:671)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1048)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:397)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:516)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:150)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:135)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:97)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:177)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:175)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
> 

[jira] [Updated] (IGNITE-6977) Wrong initial BitSet size in GridPartitionStateMap

[Alexey Goncharuk (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Goncharuk updated IGNITE-6977:
-
Fix Version/s: 2.6

> Wrong initial BitSet size in GridPartitionStateMap
> --
>
> Key: IGNITE-6977
> URL: https://issues.apache.org/jira/browse/IGNITE-6977
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.1
>Reporter: Alexander Belyak
>Assignee: Alexander Belyak
>Priority: Minor
> Fix For: 2.6
>
>
> In constructor of org.apache.ignite.internal.utilGridPartitionStateMap(int 
> parts) {
> states = new BitSet(parts);
> }
> we initialize BitSet with part bit, but use private static final int BITS for 
> each partition state. As result long[] in BitSet get difficult predictable 
> size (depends of access order it can be exact as needed or almost twice 
> bigger with at least one additional array copying)



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

[jira] [Commented] (IGNITE-6977) Wrong initial BitSet size in GridPartitionStateMap

[Alexey Goncharuk (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480805#comment-16480805
 ] 

Alexey Goncharuk commented on IGNITE-6977:
--

Looks good to me.

> Wrong initial BitSet size in GridPartitionStateMap
> --
>
> Key: IGNITE-6977
> URL: https://issues.apache.org/jira/browse/IGNITE-6977
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.1
>Reporter: Alexander Belyak
>Assignee: Alexander Belyak
>Priority: Minor
> Fix For: 2.6
>
>
> In constructor of org.apache.ignite.internal.utilGridPartitionStateMap(int 
> parts) {
> states = new BitSet(parts);
> }
> we initialize BitSet with part bit, but use private static final int BITS for 
> each partition state. As result long[] in BitSet get difficult predictable 
> size (depends of access order it can be exact as needed or almost twice 
> bigger with at least one additional array copying)



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

[jira] [Commented] (IGNITE-6977) Wrong initial BitSet size in GridPartitionStateMap

[Alexey Goncharuk (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480804#comment-16480804
 ] 

Alexey Goncharuk commented on IGNITE-6977:
--

Looks good to me.

> Wrong initial BitSet size in GridPartitionStateMap
> --
>
> Key: IGNITE-6977
> URL: https://issues.apache.org/jira/browse/IGNITE-6977
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.1
>Reporter: Alexander Belyak
>Assignee: Alexander Belyak
>Priority: Minor
> Fix For: 2.6
>
>
> In constructor of org.apache.ignite.internal.utilGridPartitionStateMap(int 
> parts) {
> states = new BitSet(parts);
> }
> we initialize BitSet with part bit, but use private static final int BITS for 
> each partition state. As result long[] in BitSet get difficult predictable 
> size (depends of access order it can be exact as needed or almost twice 
> bigger with at least one additional array copying)



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

[jira] [Commented] (IGNITE-6528) Warning if no table for BinaryObject

[Taras Ledkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480774#comment-16480774
 ] 

Taras Ledkov commented on IGNITE-6528:
--

[~ilyak], the patch is OK with me.

> Warning if no table for BinaryObject
> 
>
> Key: IGNITE-6528
> URL: https://issues.apache.org/jira/browse/IGNITE-6528
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary, cache, sql
>Reporter: Mikhail Cherkasov
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> I've seen several times that due wrong cache configuration people can't find 
> data in cache and blame Ignite that it's buggy and doesn't work.
> And it's very difficult to find an error in the code, especially if you don't 
> have reach experience with Ignite.
> The problem is that we don't have strong typing when defining QueryEntriy and 
> a user can use an arbitrary string id to
> define a type, but he should use the same string id to obtain binary object 
> builder, however, people sometimes confusing this.
> So the user can define QueryEntity with value type:  
> queryEntity.setValueType("MyCoolName") and 
> later put to cache the following binary object: 
> ignite.binary.toBinary(value), but this object won't be indexed, because
> ignite.binary.toBinary uses class name as string id while indexing expects to 
> find "MyCoolName" as id.
> The example is simple and the error is obvious when you see this two lines 
> close to each other, however, in real life, cache definition and data 
> ingestion are separated by tons of code.
> We can save a lot of man-hours for our users if Ignite will print a warning 
> If a cache has a configured QE and user puts BinaryObject with typeName which 
> doesn't correspond to any QE.
> The warning should be printed only once, something like:
> [WARN] No table is found for %typeName% binary object.



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

[jira] [Comment Edited] (IGNITE-8476) AssertionError exception occurs when trying to remove node from baseline under loading

[Dmitry Sherstobitov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480756#comment-16480756
 ] 

Dmitry Sherstobitov edited comment on IGNITE-8476 at 5/18/18 2:51 PM:
--

[~ivan.glukos] I've got same AssertionError while adding node from baseline 
with clean LFS.
 # Start cluster, activate, start client with loading
 # Kill single node, clean LFS and start it again
 # AssertionError

Next steps in this case:
 # Add new single node in cluster
 # Add new node to baseline
 # Wait for transaction loading ends
 # LRTs in client logs and transactional loading hangs (transactions with 
timeout=5 ms)


was (Author: qvad):
[~ivan.glukos] I've got same AssertionError while adding node from baseline 
with clean LFS.
 # Start cluster, activate, start client with loading
 # Kill single node, clean LFS and start it again
 # AssertionError

> AssertionError exception occurs when trying to remove node from baseline 
> under loading
> --
>
> Key: IGNITE-8476
> URL: https://issues.apache.org/jira/browse/IGNITE-8476
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Assignee: Ivan Rakov
>Priority: Blocker
>
> Run 6 nodes, start loading (8 threads, 1000 2x cache.get() and 2x cache.put() 
> in each thread per second)
> Kill 2 nodes and try to remove one node from baseline using
> control.sh --baseline remove node1
>  control.sh --baseline version TOPOLOGY_VERSION
>  
> Utility hangs or connected client may hangs, this assertion appears in log 
> For transactional cache:
> {code:java}
> [16:32:58,960][SEVERE][sys-stripe-14-#15][G] Failed to execute runnable.
> java.lang.AssertionError: localNode = be945692-c750-4d72-b9a1-9ac4170ff125, 
> dhtNodes = [ZookeeperClusterNode [id=810226e6-656a-460d-8069-ca7d2dd294ef, 
> addrs=[172.17.0.1, 0:0:0:0:0:0:0:1%lo, 172.25.1.28, 127.0.0.1], order=1, 
> loc=false, client=false], ZookeeperClusterNode 
> [id=be945692-c750-4d72-b9a1-9ac4170ff125, addrs=[172.17.0.1, 172.25.1.28, 
> 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=3, loc=true, client=false], 
> ZookeeperClusterNode [id=db4503f6-9185-4673-b38c-8890dfa69511, 
> addrs=[172.17.0.1, 172.25.1.37, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=5, 
> loc=false, client=false], ZookeeperClusterNode 
> [id=3b8d8d4f-3513-4d39-a1fd-7ec5b15fc653, addrs=[172.17.0.1, 172.25.1.37, 
> 127.0.0.1, 0:0:0:0:0:0:0:1%lo], order=4, loc=false, client=false], 
> ZookeeperClusterNode [id=2bfc8c2e-2f47-4126-9cc4-6f017ce7efde, 
> addrs=[172.17.0.1, 172.25.1.37, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=6, 
> loc=false, client=false]]
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.map(GridDhtTxPrepareFuture.java:1520)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1239)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:671)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1048)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:397)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:516)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:150)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:135)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:97)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:177)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:175)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> at 
> 

[jira] [Commented] (IGNITE-8476) AssertionError exception occurs when trying to remove node from baseline under loading

[Dmitry Sherstobitov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480756#comment-16480756
 ] 

Dmitry Sherstobitov commented on IGNITE-8476:
-

[~ivan.glukos] I've got same AssertionError while adding node from baseline 
with clean LFS.
 # Start cluster, activate, start client with loading
 # Kill single node, clean LFS and start it again
 # AssertionError

> AssertionError exception occurs when trying to remove node from baseline 
> under loading
> --
>
> Key: IGNITE-8476
> URL: https://issues.apache.org/jira/browse/IGNITE-8476
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Assignee: Ivan Rakov
>Priority: Blocker
>
> Run 6 nodes, start loading (8 threads, 1000 2x cache.get() and 2x cache.put() 
> in each thread per second)
> Kill 2 nodes and try to remove one node from baseline using
> control.sh --baseline remove node1
>  control.sh --baseline version TOPOLOGY_VERSION
>  
> Utility hangs or connected client may hangs, this assertion appears in log 
> For transactional cache:
> {code:java}
> [16:32:58,960][SEVERE][sys-stripe-14-#15][G] Failed to execute runnable.
> java.lang.AssertionError: localNode = be945692-c750-4d72-b9a1-9ac4170ff125, 
> dhtNodes = [ZookeeperClusterNode [id=810226e6-656a-460d-8069-ca7d2dd294ef, 
> addrs=[172.17.0.1, 0:0:0:0:0:0:0:1%lo, 172.25.1.28, 127.0.0.1], order=1, 
> loc=false, client=false], ZookeeperClusterNode 
> [id=be945692-c750-4d72-b9a1-9ac4170ff125, addrs=[172.17.0.1, 172.25.1.28, 
> 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=3, loc=true, client=false], 
> ZookeeperClusterNode [id=db4503f6-9185-4673-b38c-8890dfa69511, 
> addrs=[172.17.0.1, 172.25.1.37, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=5, 
> loc=false, client=false], ZookeeperClusterNode 
> [id=3b8d8d4f-3513-4d39-a1fd-7ec5b15fc653, addrs=[172.17.0.1, 172.25.1.37, 
> 127.0.0.1, 0:0:0:0:0:0:0:1%lo], order=4, loc=false, client=false], 
> ZookeeperClusterNode [id=2bfc8c2e-2f47-4126-9cc4-6f017ce7efde, 
> addrs=[172.17.0.1, 172.25.1.37, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=6, 
> loc=false, client=false]]
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.map(GridDhtTxPrepareFuture.java:1520)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1239)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:671)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1048)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:397)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:516)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:150)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:135)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:97)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:177)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:175)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
> at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:511)
> at 

[jira] [Commented] (IGNITE-6528) Warning if no table for BinaryObject

[Ilya Kasnacheev (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480736#comment-16480736
 ] 

Ilya Kasnacheev commented on IGNITE-6528:
-

[~tledkov-gridgain] I've updated it again, please look. Sigh.

> Warning if no table for BinaryObject
> 
>
> Key: IGNITE-6528
> URL: https://issues.apache.org/jira/browse/IGNITE-6528
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary, cache, sql
>Reporter: Mikhail Cherkasov
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> I've seen several times that due wrong cache configuration people can't find 
> data in cache and blame Ignite that it's buggy and doesn't work.
> And it's very difficult to find an error in the code, especially if you don't 
> have reach experience with Ignite.
> The problem is that we don't have strong typing when defining QueryEntriy and 
> a user can use an arbitrary string id to
> define a type, but he should use the same string id to obtain binary object 
> builder, however, people sometimes confusing this.
> So the user can define QueryEntity with value type:  
> queryEntity.setValueType("MyCoolName") and 
> later put to cache the following binary object: 
> ignite.binary.toBinary(value), but this object won't be indexed, because
> ignite.binary.toBinary uses class name as string id while indexing expects to 
> find "MyCoolName" as id.
> The example is simple and the error is obvious when you see this two lines 
> close to each other, however, in real life, cache definition and data 
> ingestion are separated by tons of code.
> We can save a lot of man-hours for our users if Ignite will print a warning 
> If a cache has a configured QE and user puts BinaryObject with typeName which 
> doesn't correspond to any QE.
> The warning should be printed only once, something like:
> [WARN] No table is found for %typeName% binary object.



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

[jira] [Commented] (IGNITE-640) Implement IgniteMultimap data structures

[Pavel Pereslegin (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480732#comment-16480732
 ] 

Pavel Pereslegin commented on IGNITE-640:
-

Hi [~aakhmedov], [~avinogradov].

In GridCacheMultimapImpl I noticed some things that you should pay attention to.

- Iterator of collocated multimap can be slow because it performs full scan of 
shared cache (with another multimap instances). May be this should be described 
in docs.
- Close operation of non-collocated multimap does not waits for the result of 
cache destroy operation (may be it's ok).
- Also I noticed a few calls
{code:java}cctx.kernalContext().cache().internalCache(cctx.name()).get(hdrKey){code}
that can be simplified with
{code:java}cctx.cache().get(hdrKey){code}

> Implement IgniteMultimap data structures
> 
>
> Key: IGNITE-640
> URL: https://issues.apache.org/jira/browse/IGNITE-640
> Project: Ignite
>  Issue Type: Sub-task
>  Components: data structures
>Reporter: Dmitriy Setrakyan
>Assignee: Amir Akhmedov
>Priority: Major
> Fix For: 2.6
>
>
> We need to add {{IgniteMultimap}} data structure in addition to other data 
> structures provided by Ignite. {{IgniteMultiMap}} should have similar API to 
> {{java.util.Map}} class in JDK, but support the semantics of multiple values 
> per key, similar to [Guava 
> Multimap|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Multimap.html].
>  
> However, unlike in Guava, our multi-map should work with Lists, not 
> Collections. Lists should make it possible to support the following methods:
> {code}
> // Gets value at a certain index for a key.
> V get(K, index);
> // Gets all values for a collection of keys at a certain index.
> Map getAll(Collection, index);
> // Gets values for specified indexes for a key.
> List get(K, Iterable indexes);
> // Gets all values for a collection of keys at specified indexes.
> Map getAll(Collection, Iterable indexes);
> // Gets values for specified range of indexes, between min and max.
> List get(K, int min, int max);
> // Gets all values for a collection of keys for a specified index range, 
> between min and max.
> Map getAll(Collection, int min, int max);
> // Gets all values for a specific key.
> List get(K);
> // Gets all values for a collection of keys.
> Map getAll(Collection);
> // Iterate through all elements with a certain index.
> Iterator> iterate(int idx);
> // Do we need this?
> Collection get(K, IgniteBiPredicate)
> {code}
> Multimap should also support colocated and non-colocated modes, similar to 
> [IgniteQueue|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteQueue.java]
>  and its implementation, 
> [GridAtomicCacheQueueImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridAtomicCacheQueueImpl.java].
> h2. Design Details
> The most natural way to implement such map, would be to store every value 
> under a separate key in an Ignite cache. For example, let's say that we have 
> a key {{K}} with multiple values: {{V0, V1, V2, ...}}. Then the cache should 
> end up with the following values {{K0, V0}}, {{K1, V1}}, {{K2, V2}}, etc. 
> This means that we need to wrap user key into our own, internal key, which 
> will also have {{index}} field. 
> Also note that we need to collocate all the values for the same key on the 
> same node, which means that we need to define user key K as the affinity key, 
> like so:
> {code}
> class MultiKey {
> @CacheAffinityMapped
> private K key;
> int index;
> }
> {code}
> Look ups of values at specific indexes becomes very simple. Just attach a 
> specific index to a key and do a cache lookup. Look ups for all values for a 
> key should work as following:
> {code}
> MultiKey key;
> V v = null;
> int index = 0;
> List res = new LinkedList<>();
> do {
> v = cache.get(MultiKey(K, index));
> if (v != null)
> res.add(v);
> index++;
> }
> while (v != null);
> return res;
> {code}
> We could also use batching for performance reason. In this case the batch 
> size should be configurable.
> {code}
> int index = 0;
> List res = new LinkedList<>();
> while (true) {
> List batch = new ArrayList<>(batchSize);
> // Populate batch.
> for (; index < batchSize; index++)
> batch.add(new MultiKey(K, index % batchSize);
> Map batchRes = cache.getAll(batch);
> // Potentially need to properly sort values, based on the key order,
> // if the returning map does not do it automatically.
> res.addAll(batchRes.values());
> if (res.size() < batch.size())
> 

[jira] [Commented] (IGNITE-8469) Non-heap memroy leak for calling cluster activation multi times

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480722#comment-16480722
 ] 

Dmitriy Pavlov commented on IGNITE-8469:


[~Mmuzaf], did you updated code accroding new proposal of fix?

> Non-heap memroy leak for calling cluster activation multi times
> ---
>
> Key: IGNITE-8469
> URL: https://issues.apache.org/jira/browse/IGNITE-8469
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.6
>
>
> Calling multiple time cluster (with enabled persistence and started client 
> nodes) activation {{ig3CB.cluster().active(true);}} leads to non-heap memory 
> leak.
> Line 
> {{org/apache/ignite/internal/pagemem/impl/PageMemoryNoStoreImpl.java:234}} 
> looks suspicious because of in case method 
> {{org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl#start}} 
> callled multi times (e.g. activate(true) called multi times) we lost info 
> about allocated regions.



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

[jira] [Commented] (IGNITE-8528) Peer deployment does not work for continuous query transformers

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480709#comment-16480709
 ] 

ASF GitHub Bot commented on IGNITE-8528:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/4025


> Peer deployment does not work for continuous query transformers
> ---
>
> Key: IGNITE-8528
> URL: https://issues.apache.org/jira/browse/IGNITE-8528
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Alexey Goncharuk
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.6
>
>
> Build local Ignite distribution using
> {code}
> mvn clean install -Pall-java,all-scala,licenses -DskipTests
> mvn initialize -Prelease
> {code}
> Start one node in console and run continuous query with transformer example 
> in IDE. I am getting the following exception:
> {code}
> [15:30:43] To start Console Management & Monitoring run 
> ignitevisorcmd.{sh|bat}
> [15:30:43] 
> [15:30:43] Ignite node started OK (id=f1356a5b)
> [15:30:43] Topology snapshot [ver=1, servers=1, clients=0, CPUs=16, 
> offheap=19.0GB, heap=2.0GB]
> [15:30:43]   ^-- Node [id=F1356A5B-4CDB-4480-A64F-35BF2C96DBB5, 
> clusterState=ACTIVE]
> [15:30:43] Data Regions Configured:
> [15:30:43]   ^-- default [initSize=256.0 MiB, maxSize=18.9 GiB, 
> persistenceEnabled=false]
> [15:30:52] Topology snapshot [ver=2, servers=2, clients=0, CPUs=16, 
> offheap=38.0GB, heap=3.0GB]
> [15:30:52]   ^-- Node [id=F1356A5B-4CDB-4480-A64F-35BF2C96DBB5, 
> clusterState=ACTIVE]
> [15:30:52] Data Regions Configured:
> [15:30:52]   ^-- default [initSize=256.0 MiB, maxSize=18.9 GiB, 
> persistenceEnabled=false]
> [15:30:53,065][SEVERE][tcp-disco-msg-worker-#2][BinaryContext] Failed to 
> deserialize object [typeName=java.lang.invoke.SerializedLambda]
> class org.apache.ignite.binary.BinaryObjectException: Failed to read field 
> [name=capturingClass]
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:870)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1982)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:698)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:183)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:870)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>   at 
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:310)
>   at 
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:99)
>   at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9962)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9991)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryDeployableObject.unmarshal(CacheContinuousQueryDeployableObject.java:94)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandlerV3.p2pUnmarshal(CacheContinuousQueryHandlerV3.java:155)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1327)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$400(GridContinuousProcessor.java:108)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:200)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:191)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:707)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:589)
>   at 
> 

[jira] [Updated] (IGNITE-8519) Web Console: Refactor to from Font Awesome to svg icons "Change token" panel on Profile screen

[Vica Abramova (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vica Abramova updated IGNITE-8519:
--
Attachment: (was: Security Token.png)

> Web Console: Refactor to from Font Awesome to svg icons "Change token" panel 
> on Profile screen
> --
>
> Key: IGNITE-8519
> URL: https://issues.apache.org/jira/browse/IGNITE-8519
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Attachments: Security Token.png
>
>
> We are constantly refactoring FontAwesome to svg icons.
> Lets refactor "Change token" on Profile screen



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

[jira] [Updated] (IGNITE-8519) Web Console: Refactor to from Font Awesome to svg icons "Change token" panel on Profile screen

[Vica Abramova (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vica Abramova updated IGNITE-8519:
--
Attachment: Security Token.png

> Web Console: Refactor to from Font Awesome to svg icons "Change token" panel 
> on Profile screen
> --
>
> Key: IGNITE-8519
> URL: https://issues.apache.org/jira/browse/IGNITE-8519
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Attachments: Security Token.png
>
>
> We are constantly refactoring FontAwesome to svg icons.
> Lets refactor "Change token" on Profile screen



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

[jira] [Updated] (IGNITE-8519) Web Console: Refactor to from Font Awesome to svg icons "Change token" panel on Profile screen

[Vica Abramova (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vica Abramova updated IGNITE-8519:
--
Attachment: Security Token.png

> Web Console: Refactor to from Font Awesome to svg icons "Change token" panel 
> on Profile screen
> --
>
> Key: IGNITE-8519
> URL: https://issues.apache.org/jira/browse/IGNITE-8519
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Attachments: Security Token.png
>
>
> We are constantly refactoring FontAwesome to svg icons.
> Lets refactor "Change token" on Profile screen



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

[jira] [Issue Comment Deleted] (IGNITE-8519) Web Console: Refactor to from Font Awesome to svg icons "Change token" panel on Profile screen

[Vica Abramova (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vica Abramova updated IGNITE-8519:
--
Comment: was deleted

(was: Design: https://zpl.io/aRq4rXz)

> Web Console: Refactor to from Font Awesome to svg icons "Change token" panel 
> on Profile screen
> --
>
> Key: IGNITE-8519
> URL: https://issues.apache.org/jira/browse/IGNITE-8519
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Attachments: Security Token.png
>
>
> We are constantly refactoring FontAwesome to svg icons.
> Lets refactor "Change token" on Profile screen



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

[jira] [Commented] (IGNITE-605) [Test] TODO in GridAbstractTest w/ comment "propose another way to avoid network overhead in tests"

[Maxim Muzafarov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480700#comment-16480700
 ] 

Maxim Muzafarov commented on IGNITE-605:


[~dpavlov]

I suggest to resolve this issue as "won't fix" too.
PR for removing TODO mark have been created – please review.

https://github.com/apache/ignite/pull/4027

> [Test] TODO in GridAbstractTest w/ comment "propose another way to avoid 
> network overhead in tests"
> ---
>
> Key: IGNITE-605
> URL: https://issues.apache.org/jira/browse/IGNITE-605
> Project: Ignite
>  Issue Type: Bug
>Reporter: Artem Shutak
>Priority: Major
>  Labels: Muted_test
>
> See GG-4048



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

[jira] [Assigned] (IGNITE-605) [Test] TODO in GridAbstractTest w/ comment "propose another way to avoid network overhead in tests"

[Maxim Muzafarov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maxim Muzafarov reassigned IGNITE-605:
--

Assignee: Maxim Muzafarov

> [Test] TODO in GridAbstractTest w/ comment "propose another way to avoid 
> network overhead in tests"
> ---
>
> Key: IGNITE-605
> URL: https://issues.apache.org/jira/browse/IGNITE-605
> Project: Ignite
>  Issue Type: Bug
>Reporter: Artem Shutak
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: Muted_test
>
> See GG-4048



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

[jira] [Commented] (IGNITE-605) [Test] TODO in GridAbstractTest w/ comment "propose another way to avoid network overhead in tests"

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480699#comment-16480699
 ] 

ASF GitHub Bot commented on IGNITE-605:
---

GitHub user Mmuzaf opened a pull request:

https://github.com/apache/ignite/pull/4027

IGNITE-605: remove todo as no needs



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Mmuzaf/ignite ignite-605

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4027.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4027


commit 2de80dd4c8d33653be29c847243caf33dbbf767f
Author: Maxim Muzafarov 
Date:   2018-05-18T14:06:11Z

IGNITE-605: remove todo as no needs




> [Test] TODO in GridAbstractTest w/ comment "propose another way to avoid 
> network overhead in tests"
> ---
>
> Key: IGNITE-605
> URL: https://issues.apache.org/jira/browse/IGNITE-605
> Project: Ignite
>  Issue Type: Bug
>Reporter: Artem Shutak
>Priority: Major
>  Labels: Muted_test
>
> See GG-4048



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

[jira] [Commented] (IGNITE-8491) Add JMX flag: Is the node in baseline or not?

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480694#comment-16480694
 ] 

ASF GitHub Bot commented on IGNITE-8491:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/4010


> Add JMX flag: Is the node in baseline or not?
> -
>
> Key: IGNITE-8491
> URL: https://issues.apache.org/jira/browse/IGNITE-8491
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.6
>
>
> Need to add a baseline flag on JMX.
> {code}
> public interface IgniteMXBean {
> /**
>  * Gets a flag is node in baseline.
>  *
>  * @return Return a baseline flag.
>  */
> @MXBeanDescription("Baseline node flag.")
> public boolean isNodeInBaseline();
> {code}



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

[jira] [Updated] (IGNITE-8491) Add JMX flag: Is the node in baseline or not?

[Ivan Rakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Rakov updated IGNITE-8491:
---
Fix Version/s: 2.6

> Add JMX flag: Is the node in baseline or not?
> -
>
> Key: IGNITE-8491
> URL: https://issues.apache.org/jira/browse/IGNITE-8491
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.6
>
>
> Need to add a baseline flag on JMX.
> {code}
> public interface IgniteMXBean {
> /**
>  * Gets a flag is node in baseline.
>  *
>  * @return Return a baseline flag.
>  */
> @MXBeanDescription("Baseline node flag.")
> public boolean isNodeInBaseline();
> {code}



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

[jira] [Commented] (IGNITE-8501) Retry on GridServiceNotFoundException in GridServiceProxy needs to be fixed

[Denis Mekhanikov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480676#comment-16480676
 ] 

Denis Mekhanikov commented on IGNITE-8501:
--

Looks good to me (y)

> Retry on GridServiceNotFoundException in GridServiceProxy needs to be fixed
> ---
>
> Key: IGNITE-8501
> URL: https://issues.apache.org/jira/browse/IGNITE-8501
> Project: Ignite
>  Issue Type: Bug
>Reporter: Stanislav Lukyanov
>Assignee: Stanislav Lukyanov
>Priority: Major
> Fix For: 2.6
>
>
> `GridServiceProxy::invokeMethod` attempts to invoke a method of an Ignite 
> service and performs retries in case the invocation procedure throws 
> `GridServiceNotFoundException` or `ClusterTopologyCheckedException` (these 
> exceptions may be thrown in case the service assignments were already 
> calculated, but the service instance was not yet created and initialized on 
> the affinity server).
> After the fix IGNITE-7904 the exception type thrown by the remote invocation 
> code changed to `IgniteCheckedException` (with a cause being 
> `GridServiceNotFoundException` or `ClusterTopologyCheckedException`). Because 
> of that, the retry doesn't work now.
> Need to fix the code to correctly handle new exception chain.



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

[jira] [Commented] (IGNITE-8531) NPE is thrown on destroying empty partition

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480667#comment-16480667
 ] 

ASF GitHub Bot commented on IGNITE-8531:


GitHub user Jokser opened a pull request:

https://github.com/apache/ignite/pull/4026

IGNITE-8531 Fixed NPE if checkpoint has no pages to write, but has 
partitions to destroy



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-8531

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4026.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4026


commit b42b933b62b7f79dfb8355b1e6e4254dcb9e2842
Author: Pavel Kovalenko 
Date:   2018-05-18T13:43:20Z

IGNITE-8531 Fixed NPE if checkpoint has no pages to write, but has 
partitions to destroy.




> NPE is thrown on destroying empty partition
> ---
>
> Key: IGNITE-8531
> URL: https://issues.apache.org/jira/browse/IGNITE-8531
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Sergey Chugunov
>Assignee: Pavel Kovalenko
>Priority: Major
>
> Improvement IGNITE-8320 introduced situation when NPE may happen: in case of 
> destroying empty partition checkpoint record isn't logged to WAL but code 
> attempts to create checkpoint marker anyway which leads to NPE.
> We need to allow checkpointing empty partitions.



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

[jira] [Assigned] (IGNITE-8524) Document consistency check utilities

[Ivan Rakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Rakov reassigned IGNITE-8524:
--

Assignee: Ivan Rakov

> Document consistency check utilities
> 
>
> Key: IGNITE-8524
> URL: https://issues.apache.org/jira/browse/IGNITE-8524
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Ivan Rakov
>Priority: Critical
> Fix For: 2.5
>
>
> Ignite 2.5 will go with special consistency check utilities that, for 
> instance, ensure that the data stays consistent across backups, indexes are 
> correct and many other things. More details can be taken from here:
> * https://issues.apache.org/jira/browse/IGNITE-8277
> * https://issues.apache.org/jira/browse/IGNITE-7467
> Here is an empty page that is created for the documentation: 
> https://apacheignite.readme.io/docs/consistency-check-utilities



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

[jira] [Commented] (IGNITE-8528) Peer deployment does not work for continuous query transformers

[Alexey Goncharuk (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480655#comment-16480655
 ] 

Alexey Goncharuk commented on IGNITE-8528:
--

Looks good to me.

> Peer deployment does not work for continuous query transformers
> ---
>
> Key: IGNITE-8528
> URL: https://issues.apache.org/jira/browse/IGNITE-8528
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Alexey Goncharuk
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.6
>
>
> Build local Ignite distribution using
> {code}
> mvn clean install -Pall-java,all-scala,licenses -DskipTests
> mvn initialize -Prelease
> {code}
> Start one node in console and run continuous query with transformer example 
> in IDE. I am getting the following exception:
> {code}
> [15:30:43] To start Console Management & Monitoring run 
> ignitevisorcmd.{sh|bat}
> [15:30:43] 
> [15:30:43] Ignite node started OK (id=f1356a5b)
> [15:30:43] Topology snapshot [ver=1, servers=1, clients=0, CPUs=16, 
> offheap=19.0GB, heap=2.0GB]
> [15:30:43]   ^-- Node [id=F1356A5B-4CDB-4480-A64F-35BF2C96DBB5, 
> clusterState=ACTIVE]
> [15:30:43] Data Regions Configured:
> [15:30:43]   ^-- default [initSize=256.0 MiB, maxSize=18.9 GiB, 
> persistenceEnabled=false]
> [15:30:52] Topology snapshot [ver=2, servers=2, clients=0, CPUs=16, 
> offheap=38.0GB, heap=3.0GB]
> [15:30:52]   ^-- Node [id=F1356A5B-4CDB-4480-A64F-35BF2C96DBB5, 
> clusterState=ACTIVE]
> [15:30:52] Data Regions Configured:
> [15:30:52]   ^-- default [initSize=256.0 MiB, maxSize=18.9 GiB, 
> persistenceEnabled=false]
> [15:30:53,065][SEVERE][tcp-disco-msg-worker-#2][BinaryContext] Failed to 
> deserialize object [typeName=java.lang.invoke.SerializedLambda]
> class org.apache.ignite.binary.BinaryObjectException: Failed to read field 
> [name=capturingClass]
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:870)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1982)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:698)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:183)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:870)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>   at 
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:310)
>   at 
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:99)
>   at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9962)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9991)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryDeployableObject.unmarshal(CacheContinuousQueryDeployableObject.java:94)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandlerV3.p2pUnmarshal(CacheContinuousQueryHandlerV3.java:155)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1327)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$400(GridContinuousProcessor.java:108)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:200)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:191)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:707)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:589)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5479)
>   at 
> 

[jira] [Commented] (IGNITE-8381) testNodeSingletonDeploy in Basic 2 has high fail rate

[Vyacheslav Daradur (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480652#comment-16480652
 ] 

Vyacheslav Daradur commented on IGNITE-8381:


[~dpavlov], thanks! Test has been unmuted on TC.
 I'm keeping an eye on these tests.

> testNodeSingletonDeploy in Basic 2 has high fail rate
> -
>
> Key: IGNITE-8381
> URL: https://issues.apache.org/jira/browse/IGNITE-8381
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Vyacheslav Daradur
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.6
>
>
> IgniteServiceConfigVariationsFullApiTestSuite: 
> IgniteServiceConfigVariationsFullApiTest.testNodeSingletonDeploy
> is one from most failing test in TC Run All now
> On dev.list IEP-17 is discussed to redesign services and fix deployemnt. In 
> the same time test itself can't await service to be deployed and confuses 
> Igniters in RunAll PR results.
> It is suggested to find out fast fix to make test passing. It should be 
> probably based on waiting instead of checking deployed state.
> Test history
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1909279554207447487=%3Cdefault%3E=testDetails
> {noformat}
> class org.apache.ignite.IgniteException: Service not found: testService
> at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1858)
> at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:568)
> at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6695)
> at 
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:562)
> at 
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:491)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at 
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1189)
> at 
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1921)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
> 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)
> Caused by: class 
> org.apache.ignite.internal.processors.service.GridServiceNotFoundException: 
> Service not found: testService
> at 
> org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.call(GridServiceProxy.java:415)
> at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1855)
> ... 14 more
> {noformat}



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

[jira] [Commented] (IGNITE-8520) ignite-gce/ignite-shmem is redundant

[Andrey Gura (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480641#comment-16480641
 ] 

Andrey Gura commented on IGNITE-8520:
-

Merged to master and ignite-2.5 branches. Thanks!

> ignite-gce/ignite-shmem is redundant
> 
>
> Key: IGNITE-8520
> URL: https://issues.apache.org/jira/browse/IGNITE-8520
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Sergey Kozlov
>Assignee: Peter Ivanov
>Priority: Major
> Fix For: 2.5
>
>
> {{ignite-shmem}} is already included in {{libs}} and thus should  be excluded 
> from {{libs/optional/ignite-gce}}



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

[jira] [Commented] (IGNITE-8381) testNodeSingletonDeploy in Basic 2 has high fail rate

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480639#comment-16480639
 ] 

ASF GitHub Bot commented on IGNITE-8381:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3996


> testNodeSingletonDeploy in Basic 2 has high fail rate
> -
>
> Key: IGNITE-8381
> URL: https://issues.apache.org/jira/browse/IGNITE-8381
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Vyacheslav Daradur
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.6
>
>
> IgniteServiceConfigVariationsFullApiTestSuite: 
> IgniteServiceConfigVariationsFullApiTest.testNodeSingletonDeploy
> is one from most failing test in TC Run All now
> On dev.list IEP-17 is discussed to redesign services and fix deployemnt. In 
> the same time test itself can't await service to be deployed and confuses 
> Igniters in RunAll PR results.
> It is suggested to find out fast fix to make test passing. It should be 
> probably based on waiting instead of checking deployed state.
> Test history
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1909279554207447487=%3Cdefault%3E=testDetails
> {noformat}
> class org.apache.ignite.IgniteException: Service not found: testService
> at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1858)
> at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:568)
> at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6695)
> at 
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:562)
> at 
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:491)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at 
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1189)
> at 
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1921)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
> 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)
> Caused by: class 
> org.apache.ignite.internal.processors.service.GridServiceNotFoundException: 
> Service not found: testService
> at 
> org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.call(GridServiceProxy.java:415)
> at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1855)
> ... 14 more
> {noformat}



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

[jira] [Commented] (IGNITE-605) [Test] TODO in GridAbstractTest w/ comment "propose another way to avoid network overhead in tests"

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480629#comment-16480629
 ] 

Dmitriy Pavlov commented on IGNITE-605:
---

I guess we should

> [Test] TODO in GridAbstractTest w/ comment "propose another way to avoid 
> network overhead in tests"
> ---
>
> Key: IGNITE-605
> URL: https://issues.apache.org/jira/browse/IGNITE-605
> Project: Ignite
>  Issue Type: Bug
>Reporter: Artem Shutak
>Priority: Major
>  Labels: Muted_test
>
> See GG-4048



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

[jira] [Commented] (IGNITE-8525) Support for IgniteZeroMqStreamer non-multi-part pub-sub

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480627#comment-16480627
 ] 

Dmitriy Pavlov commented on IGNITE-8525:


Hi [~roman_s] could you please share link to TC run? I would like to double 
check if there are no failed tests.

> Support for IgniteZeroMqStreamer non-multi-part pub-sub
> ---
>
> Key: IGNITE-8525
> URL: https://issues.apache.org/jira/browse/IGNITE-8525
> Project: Ignite
>  Issue Type: Improvement
>  Components: streaming
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>Priority: Major
> Fix For: 2.6
>
>
> Currently only multi-part pub-sub is supported.



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

[jira] [Commented] (IGNITE-8519) Web Console: Refactor to from Font Awesome to svg icons "Change token" panel on Profile screen

[Vica Abramova (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480620#comment-16480620
 ] 

Vica Abramova commented on IGNITE-8519:
---

Design: https://zpl.io/aRq4rXz

> Web Console: Refactor to from Font Awesome to svg icons "Change token" panel 
> on Profile screen
> --
>
> Key: IGNITE-8519
> URL: https://issues.apache.org/jira/browse/IGNITE-8519
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Vica Abramova
>Priority: Major
>
> We are constantly refactoring FontAwesome to svg icons.
> Lets refactor "Change token" on Profile screen



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

[jira] [Assigned] (IGNITE-8519) Web Console: Refactor to from Font Awesome to svg icons "Change token" panel on Profile screen

[Vica Abramova (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vica Abramova reassigned IGNITE-8519:
-

Assignee: Alexey Kuznetsov  (was: Vica Abramova)

> Web Console: Refactor to from Font Awesome to svg icons "Change token" panel 
> on Profile screen
> --
>
> Key: IGNITE-8519
> URL: https://issues.apache.org/jira/browse/IGNITE-8519
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
>
> We are constantly refactoring FontAwesome to svg icons.
> Lets refactor "Change token" on Profile screen



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

[jira] [Commented] (IGNITE-8238) Operation can fails with unexpected RuntimeException when node is stopping.

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480616#comment-16480616
 ] 

Dmitriy Pavlov commented on IGNITE-8238:


TC looks good, I didn't found any of new failures

> Operation can fails with unexpected RuntimeException when node is stopping.
> ---
>
> Key: IGNITE-8238
> URL: https://issues.apache.org/jira/browse/IGNITE-8238
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Andrew Mashenkov
>Assignee: Alexander Menshikov
>Priority: Minor
> Fix For: 2.6
>
>
> Operation can fails with RuntimeException when node is stoped in other 
> thread. 
> It is not clear from javadoc that operation can throws RuntimeException.
>  We should add it to javadoc or e.g. throws IllegalStateException which 
> already present in java cache api javadoc.
> Failure in thread: Thread [id=3484, name=updater-2]
> java.lang.RuntimeException: Failed to perform cache update: node is stopping.
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1350)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:1685)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:796)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:197)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:834)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheGateway.leaveNoLock(GridCacheGateway.java:240)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheGateway.leave(GridCacheGateway.java:225)
>  at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.onLeave(GatewayProtectedCacheProxy.java:1708)
>  at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.putAll(GatewayProtectedCacheProxy.java:945)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.IgnitePdsContinuousRestartTest$1.call(IgnitePdsContinuousRestartTest.java:261)
>  at org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)



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

[jira] [Commented] (IGNITE-7917) Thin client: document missing data types

[Igor Sapego (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480609#comment-16480609
 ] 

Igor Sapego commented on IGNITE-7917:
-

Yeah, I've covered all the types in the new page.

> Thin client: document missing data types
> 
>
> Key: IGNITE-7917
> URL: https://issues.apache.org/jira/browse/IGNITE-7917
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, thin client
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.5
>
>
> Docs page: 
> https://apacheignite.readme.io/docs/binary-client-protocol#data-format
> Missing data types:
> COL = 24
> ENUM = 28
> ENUM_ARR = 29
> DECIMAL = 30
> DECIMAL_ARR = 31
> TIMESTAMP = 33
> TIMESTAMP_ARR = 34
> TIME = 36
> TIME_ARR = 37



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

[jira] [Commented] (IGNITE-8528) Peer deployment does not work for continuous query transformers

[Nikolay Izhikov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480604#comment-16480604
 ] 

Nikolay Izhikov commented on IGNITE-8528:
-

Team City Examples - 
https://ci.ignite.apache.org/viewLog.html?buildId=1310357=queuedBuildOverviewTab

> Peer deployment does not work for continuous query transformers
> ---
>
> Key: IGNITE-8528
> URL: https://issues.apache.org/jira/browse/IGNITE-8528
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Alexey Goncharuk
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.6
>
>
> Build local Ignite distribution using
> {code}
> mvn clean install -Pall-java,all-scala,licenses -DskipTests
> mvn initialize -Prelease
> {code}
> Start one node in console and run continuous query with transformer example 
> in IDE. I am getting the following exception:
> {code}
> [15:30:43] To start Console Management & Monitoring run 
> ignitevisorcmd.{sh|bat}
> [15:30:43] 
> [15:30:43] Ignite node started OK (id=f1356a5b)
> [15:30:43] Topology snapshot [ver=1, servers=1, clients=0, CPUs=16, 
> offheap=19.0GB, heap=2.0GB]
> [15:30:43]   ^-- Node [id=F1356A5B-4CDB-4480-A64F-35BF2C96DBB5, 
> clusterState=ACTIVE]
> [15:30:43] Data Regions Configured:
> [15:30:43]   ^-- default [initSize=256.0 MiB, maxSize=18.9 GiB, 
> persistenceEnabled=false]
> [15:30:52] Topology snapshot [ver=2, servers=2, clients=0, CPUs=16, 
> offheap=38.0GB, heap=3.0GB]
> [15:30:52]   ^-- Node [id=F1356A5B-4CDB-4480-A64F-35BF2C96DBB5, 
> clusterState=ACTIVE]
> [15:30:52] Data Regions Configured:
> [15:30:52]   ^-- default [initSize=256.0 MiB, maxSize=18.9 GiB, 
> persistenceEnabled=false]
> [15:30:53,065][SEVERE][tcp-disco-msg-worker-#2][BinaryContext] Failed to 
> deserialize object [typeName=java.lang.invoke.SerializedLambda]
> class org.apache.ignite.binary.BinaryObjectException: Failed to read field 
> [name=capturingClass]
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:870)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1982)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:698)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:183)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:870)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>   at 
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:310)
>   at 
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:99)
>   at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9962)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9991)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryDeployableObject.unmarshal(CacheContinuousQueryDeployableObject.java:94)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandlerV3.p2pUnmarshal(CacheContinuousQueryHandlerV3.java:155)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1327)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$400(GridContinuousProcessor.java:108)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:200)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:191)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:707)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:589)
>   at 
> 

[jira] [Assigned] (IGNITE-8528) Peer deployment does not work for continuous query transformers

[Nikolay Izhikov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikolay Izhikov reassigned IGNITE-8528:
---

Assignee: Nikolay Izhikov

> Peer deployment does not work for continuous query transformers
> ---
>
> Key: IGNITE-8528
> URL: https://issues.apache.org/jira/browse/IGNITE-8528
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Alexey Goncharuk
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.6
>
>
> Build local Ignite distribution using
> {code}
> mvn clean install -Pall-java,all-scala,licenses -DskipTests
> mvn initialize -Prelease
> {code}
> Start one node in console and run continuous query with transformer example 
> in IDE. I am getting the following exception:
> {code}
> [15:30:43] To start Console Management & Monitoring run 
> ignitevisorcmd.{sh|bat}
> [15:30:43] 
> [15:30:43] Ignite node started OK (id=f1356a5b)
> [15:30:43] Topology snapshot [ver=1, servers=1, clients=0, CPUs=16, 
> offheap=19.0GB, heap=2.0GB]
> [15:30:43]   ^-- Node [id=F1356A5B-4CDB-4480-A64F-35BF2C96DBB5, 
> clusterState=ACTIVE]
> [15:30:43] Data Regions Configured:
> [15:30:43]   ^-- default [initSize=256.0 MiB, maxSize=18.9 GiB, 
> persistenceEnabled=false]
> [15:30:52] Topology snapshot [ver=2, servers=2, clients=0, CPUs=16, 
> offheap=38.0GB, heap=3.0GB]
> [15:30:52]   ^-- Node [id=F1356A5B-4CDB-4480-A64F-35BF2C96DBB5, 
> clusterState=ACTIVE]
> [15:30:52] Data Regions Configured:
> [15:30:52]   ^-- default [initSize=256.0 MiB, maxSize=18.9 GiB, 
> persistenceEnabled=false]
> [15:30:53,065][SEVERE][tcp-disco-msg-worker-#2][BinaryContext] Failed to 
> deserialize object [typeName=java.lang.invoke.SerializedLambda]
> class org.apache.ignite.binary.BinaryObjectException: Failed to read field 
> [name=capturingClass]
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:870)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1982)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:698)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:183)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:870)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>   at 
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:310)
>   at 
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:99)
>   at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9962)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9991)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryDeployableObject.unmarshal(CacheContinuousQueryDeployableObject.java:94)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandlerV3.p2pUnmarshal(CacheContinuousQueryHandlerV3.java:155)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1327)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$400(GridContinuousProcessor.java:108)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:200)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:191)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:707)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:589)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5479)
>   at 
> 

[jira] [Commented] (IGNITE-8528) Peer deployment does not work for continuous query transformers

[Nikolay Izhikov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480596#comment-16480596
 ] 

Nikolay Izhikov commented on IGNITE-8528:
-

[~agoncharuk] Fixed. Please, take a look at my changes

https://github.com/apache/ignite/pull/4025

> Peer deployment does not work for continuous query transformers
> ---
>
> Key: IGNITE-8528
> URL: https://issues.apache.org/jira/browse/IGNITE-8528
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Alexey Goncharuk
>Priority: Major
> Fix For: 2.6
>
>
> Build local Ignite distribution using
> {code}
> mvn clean install -Pall-java,all-scala,licenses -DskipTests
> mvn initialize -Prelease
> {code}
> Start one node in console and run continuous query with transformer example 
> in IDE. I am getting the following exception:
> {code}
> [15:30:43] To start Console Management & Monitoring run 
> ignitevisorcmd.{sh|bat}
> [15:30:43] 
> [15:30:43] Ignite node started OK (id=f1356a5b)
> [15:30:43] Topology snapshot [ver=1, servers=1, clients=0, CPUs=16, 
> offheap=19.0GB, heap=2.0GB]
> [15:30:43]   ^-- Node [id=F1356A5B-4CDB-4480-A64F-35BF2C96DBB5, 
> clusterState=ACTIVE]
> [15:30:43] Data Regions Configured:
> [15:30:43]   ^-- default [initSize=256.0 MiB, maxSize=18.9 GiB, 
> persistenceEnabled=false]
> [15:30:52] Topology snapshot [ver=2, servers=2, clients=0, CPUs=16, 
> offheap=38.0GB, heap=3.0GB]
> [15:30:52]   ^-- Node [id=F1356A5B-4CDB-4480-A64F-35BF2C96DBB5, 
> clusterState=ACTIVE]
> [15:30:52] Data Regions Configured:
> [15:30:52]   ^-- default [initSize=256.0 MiB, maxSize=18.9 GiB, 
> persistenceEnabled=false]
> [15:30:53,065][SEVERE][tcp-disco-msg-worker-#2][BinaryContext] Failed to 
> deserialize object [typeName=java.lang.invoke.SerializedLambda]
> class org.apache.ignite.binary.BinaryObjectException: Failed to read field 
> [name=capturingClass]
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:870)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1982)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:698)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:183)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:870)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>   at 
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:310)
>   at 
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:99)
>   at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9962)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9991)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryDeployableObject.unmarshal(CacheContinuousQueryDeployableObject.java:94)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandlerV3.p2pUnmarshal(CacheContinuousQueryHandlerV3.java:155)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1327)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$400(GridContinuousProcessor.java:108)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:200)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:191)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:707)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:589)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5479)
>   at 
> 

[jira] [Commented] (IGNITE-8266) Remove afterTestsStopped method due to stopAllGrids by default

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480592#comment-16480592
 ] 

Dmitriy Pavlov commented on IGNITE-8266:


Yes, my picture illustrates history of all runs, each vertical line is 1 run.

Last run may be better than previous because of randomized nature of failure.

> Remove afterTestsStopped method due to stopAllGrids by default
> --
>
> Key: IGNITE-8266
> URL: https://issues.apache.org/jira/browse/IGNITE-8266
> Project: Ignite
>  Issue Type: Sub-task
>Affects Versions: 2.5
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
>  Labels: test
> Fix For: 2.6
>
> Attachments: screenshot-1.png
>
>
> Remove this types of method from test in whole ignite-core module.
> {code:java}
> @Override protected void afterTestsStopped() throws Exception {
> super.afterTestsStopped();
> stopAllGrids();
> }{code}



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

[jira] [Commented] (IGNITE-8528) Peer deployment does not work for continuous query transformers

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480593#comment-16480593
 ] 

ASF GitHub Bot commented on IGNITE-8528:


GitHub user nizhikov opened a pull request:

https://github.com/apache/ignite/pull/4025

IGNITE-8528: Example fixed



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nizhikov/ignite IGNITE-8528

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4025.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4025


commit 2d3f5f66650f4f3e3a8af2ee013b8e0958209fb1
Author: Nikolay Izhikov 
Date:   2018-05-18T12:27:10Z

IGNITE-8528: Example fixed

commit c620b76efc45db6231ffaf2911e1b60d6909c5fe
Author: Nikolay Izhikov 
Date:   2018-05-18T12:27:39Z

IGNITE-8528: Example fixed




> Peer deployment does not work for continuous query transformers
> ---
>
> Key: IGNITE-8528
> URL: https://issues.apache.org/jira/browse/IGNITE-8528
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Alexey Goncharuk
>Priority: Major
> Fix For: 2.6
>
>
> Build local Ignite distribution using
> {code}
> mvn clean install -Pall-java,all-scala,licenses -DskipTests
> mvn initialize -Prelease
> {code}
> Start one node in console and run continuous query with transformer example 
> in IDE. I am getting the following exception:
> {code}
> [15:30:43] To start Console Management & Monitoring run 
> ignitevisorcmd.{sh|bat}
> [15:30:43] 
> [15:30:43] Ignite node started OK (id=f1356a5b)
> [15:30:43] Topology snapshot [ver=1, servers=1, clients=0, CPUs=16, 
> offheap=19.0GB, heap=2.0GB]
> [15:30:43]   ^-- Node [id=F1356A5B-4CDB-4480-A64F-35BF2C96DBB5, 
> clusterState=ACTIVE]
> [15:30:43] Data Regions Configured:
> [15:30:43]   ^-- default [initSize=256.0 MiB, maxSize=18.9 GiB, 
> persistenceEnabled=false]
> [15:30:52] Topology snapshot [ver=2, servers=2, clients=0, CPUs=16, 
> offheap=38.0GB, heap=3.0GB]
> [15:30:52]   ^-- Node [id=F1356A5B-4CDB-4480-A64F-35BF2C96DBB5, 
> clusterState=ACTIVE]
> [15:30:52] Data Regions Configured:
> [15:30:52]   ^-- default [initSize=256.0 MiB, maxSize=18.9 GiB, 
> persistenceEnabled=false]
> [15:30:53,065][SEVERE][tcp-disco-msg-worker-#2][BinaryContext] Failed to 
> deserialize object [typeName=java.lang.invoke.SerializedLambda]
> class org.apache.ignite.binary.BinaryObjectException: Failed to read field 
> [name=capturingClass]
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:870)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1982)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:698)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:183)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:870)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>   at 
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:310)
>   at 
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:99)
>   at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9962)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9991)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryDeployableObject.unmarshal(CacheContinuousQueryDeployableObject.java:94)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandlerV3.p2pUnmarshal(CacheContinuousQueryHandlerV3.java:155)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1327)
>   at 
> 

[jira] [Commented] (IGNITE-605) [Test] TODO in GridAbstractTest w/ comment "propose another way to avoid network overhead in tests"

[Maxim Muzafarov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480591#comment-16480591
 ] 

Maxim Muzafarov commented on IGNITE-605:


[~dpavlov],

Should we also delete this TODO item? -- 
[GridAbstractTest.java#L1036|https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/GridAbstractTest.java#L1036]

> [Test] TODO in GridAbstractTest w/ comment "propose another way to avoid 
> network overhead in tests"
> ---
>
> Key: IGNITE-605
> URL: https://issues.apache.org/jira/browse/IGNITE-605
> Project: Ignite
>  Issue Type: Bug
>Reporter: Artem Shutak
>Priority: Major
>  Labels: Muted_test
>
> See GG-4048



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

[jira] [Commented] (IGNITE-7818) Incorrect assertion in PDS page eviction method

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480589#comment-16480589
 ] 

ASF GitHub Bot commented on IGNITE-7818:


GitHub user 1vanan opened a pull request:

https://github.com/apache/ignite/pull/4024

IGNITE-7818



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/1vanan/ignite IGNITE-7818

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4024.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4024


commit bd5fce8c99477abaabe5d3242d5a95c5b7988920
Author: Fedotov 
Date:   2018-05-08T09:21:05Z

change javaDoc in IgniteDataStreamer

commit 833a468aa5a05c478bf1231f313692d496f879c1
Author: Fedotov 
Date:   2018-05-18T12:18:24Z

remove assertion




> Incorrect assertion in PDS page eviction method
> ---
>
> Key: IGNITE-7818
> URL: https://issues.apache.org/jira/browse/IGNITE-7818
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Aleksey Plekhanov
>Assignee: Ivan Fedotov
>Priority: Major
>
> There is an assertion in the method 
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.Segment#removePageForReplacement:
>  
> {code:java}
> assert relRmvAddr != INVALID_REL_PTR;{code}
> Which seems potentially dangerous. In some rare cases, when count of 
> interations more then 40% of allocated pages and all processed pages are 
> aquired, the {{relRmvAddr}} variable will be uninitialized and 
> {{AssertionException}} will be thrown. But it's a correct case and page to 
> evict can be found later in the method {{tryToFindSequentially.}}
>  



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

[jira] [Commented] (IGNITE-8266) Remove afterTestsStopped method due to stopAllGrids by default

[Maxim Muzafarov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480586#comment-16480586
 ] 

Maxim Muzafarov commented on IGNITE-8266:
-

Folks,

This Run:All looks much better – [#1706 (17 May 18 
17:10)|https://ci.ignite.apache.org/viewLog.html?buildId=1304850=buildResultsDiv=IgniteTests24Java8_RunAll]
Since timeouts in Cache 6 Suite is a known issue -- 
[IGNITE-8509|https://issues.apache.org/jira/browse/IGNITE-8509].

> Remove afterTestsStopped method due to stopAllGrids by default
> --
>
> Key: IGNITE-8266
> URL: https://issues.apache.org/jira/browse/IGNITE-8266
> Project: Ignite
>  Issue Type: Sub-task
>Affects Versions: 2.5
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
>  Labels: test
> Fix For: 2.6
>
> Attachments: screenshot-1.png
>
>
> Remove this types of method from test in whole ignite-core module.
> {code:java}
> @Override protected void afterTestsStopped() throws Exception {
> super.afterTestsStopped();
> stopAllGrids();
> }{code}



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

[jira] [Commented] (IGNITE-605) [Test] TODO in GridAbstractTest w/ comment "propose another way to avoid network overhead in tests"

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480584#comment-16480584
 ] 

Dmitriy Pavlov commented on IGNITE-605:
---

[~Mmuzaf], My opinion: Won't fix. I would like all Igniters start reporing 
clear issues, with description of steps to reporoduce.

Otherwise 'won't fix' is natural end of life for unclear task.

> [Test] TODO in GridAbstractTest w/ comment "propose another way to avoid 
> network overhead in tests"
> ---
>
> Key: IGNITE-605
> URL: https://issues.apache.org/jira/browse/IGNITE-605
> Project: Ignite
>  Issue Type: Bug
>Reporter: Artem Shutak
>Priority: Major
>  Labels: Muted_test
>
> See GG-4048



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

[jira] [Reopened] (IGNITE-5011) Add validation of input params of disco command

[Dmitriy Pavlov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov reopened IGNITE-5011:


> Add validation of input params of disco command
> ---
>
> Key: IGNITE-5011
> URL: https://issues.apache.org/jira/browse/IGNITE-5011
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Trivial
> Fix For: 2.6
>
>
> {code}
> visor> disco -t=0h
> java.lang.IllegalArgumentException: Time frame size is not positive in: 0h
> at org.apache.ignite.visor.visor$.timeFilter(visor.scala:2671)
> at 
> org.apache.ignite.visor.commands.disco.VisorDiscoveryCommand.disco(VisorDiscoveryCommand.scala:127)
> at 
> org.apache.ignite.visor.commands.disco.VisorDiscoveryCommand$$anonfun$4.apply(VisorDiscoveryCommand.scala:282)
> at 
> org.apache.ignite.visor.commands.disco.VisorDiscoveryCommand$$anonfun$4.apply(VisorDiscoveryCommand.scala:282)
> at 
> org.apache.ignite.visor.commands.VisorConsole.mainLoop(VisorConsole.scala:217)
> at 
> org.apache.ignite.visor.commands.VisorConsole$.delayedEndpoint$org$apache$ignite$visor$commands$VisorConsole$1(VisorConsole.scala:329)
> at 
> org.apache.ignite.visor.commands.VisorConsole$delayedInit$body.apply(VisorConsole.scala:318)
> at scala.Function0$class.apply$mcV$sp(Function0.scala:34)
> at 
> scala.runtime.AbstractFunction0.apply$mcV$sp(AbstractFunction0.scala:12)
> at scala.App$$anonfun$main$1.apply(App.scala:76)
> at scala.App$$anonfun$main$1.apply(App.scala:76)
> at scala.collection.immutable.List.foreach(List.scala:381)
> at 
> scala.collection.generic.TraversableForwarder$class.foreach(TraversableForwarder.scala:35)
> at scala.App$class.main(App.scala:76)
> at 
> org.apache.ignite.visor.commands.VisorConsole$.main(VisorConsole.scala:318)
> at 
> org.apache.ignite.visor.commands.VisorConsole.main(VisorConsole.scala)
> (wrn) : Invalid command name: 'disco -t=0h'
> (wrn) : Type 'help' to print commands list.
> {code}



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

[jira] [Commented] (IGNITE-605) [Test] TODO in GridAbstractTest w/ comment "propose another way to avoid network overhead in tests"

[Maxim Muzafarov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480575#comment-16480575
 ] 

Maxim Muzafarov commented on IGNITE-605:


[~dpavlov],

Hello, can we add more info this this issue or close it as "won't fix" ?

> [Test] TODO in GridAbstractTest w/ comment "propose another way to avoid 
> network overhead in tests"
> ---
>
> Key: IGNITE-605
> URL: https://issues.apache.org/jira/browse/IGNITE-605
> Project: Ignite
>  Issue Type: Bug
>Reporter: Artem Shutak
>Priority: Major
>  Labels: Muted_test
>
> See GG-4048



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

[jira] [Commented] (IGNITE-5990) IgniteCachePutAllRestartTest.testStopOriginatingNode fails on TC sometimes

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480572#comment-16480572
 ] 

ASF GitHub Bot commented on IGNITE-5990:


GitHub user voipp opened a pull request:

https://github.com/apache/ignite/pull/4023

IGNITE-5990



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/voipp/ignite IGNITE-5990

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4023.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4023


commit d8896a9d7548a1f9c3ca1228629d7e1790e68303
Author: voipp 
Date:   2018-05-18T12:10:24Z

IGNITE-5990




>  IgniteCachePutAllRestartTest.testStopOriginatingNode fails on TC sometimes
> ---
>
> Key: IGNITE-5990
> URL: https://issues.apache.org/jira/browse/IGNITE-5990
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Ilya Lantukh
>Assignee: Alexey Kuznetsov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, test-failure
> Attachments: dump.txt
>
>
> Could not reproduce locally. Test fails due to timeout. Thread dump attached.



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

[jira] [Commented] (IGNITE-5011) Add validation of input params of disco command

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480567#comment-16480567
 ] 

Dmitriy Pavlov commented on IGNITE-5011:


Was PR 1917 merged? 

I don't see comment from committer about merge.

If PR is not merged, Resolved status is not best option.

> Add validation of input params of disco command
> ---
>
> Key: IGNITE-5011
> URL: https://issues.apache.org/jira/browse/IGNITE-5011
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Trivial
> Fix For: 2.6
>
>
> {code}
> visor> disco -t=0h
> java.lang.IllegalArgumentException: Time frame size is not positive in: 0h
> at org.apache.ignite.visor.visor$.timeFilter(visor.scala:2671)
> at 
> org.apache.ignite.visor.commands.disco.VisorDiscoveryCommand.disco(VisorDiscoveryCommand.scala:127)
> at 
> org.apache.ignite.visor.commands.disco.VisorDiscoveryCommand$$anonfun$4.apply(VisorDiscoveryCommand.scala:282)
> at 
> org.apache.ignite.visor.commands.disco.VisorDiscoveryCommand$$anonfun$4.apply(VisorDiscoveryCommand.scala:282)
> at 
> org.apache.ignite.visor.commands.VisorConsole.mainLoop(VisorConsole.scala:217)
> at 
> org.apache.ignite.visor.commands.VisorConsole$.delayedEndpoint$org$apache$ignite$visor$commands$VisorConsole$1(VisorConsole.scala:329)
> at 
> org.apache.ignite.visor.commands.VisorConsole$delayedInit$body.apply(VisorConsole.scala:318)
> at scala.Function0$class.apply$mcV$sp(Function0.scala:34)
> at 
> scala.runtime.AbstractFunction0.apply$mcV$sp(AbstractFunction0.scala:12)
> at scala.App$$anonfun$main$1.apply(App.scala:76)
> at scala.App$$anonfun$main$1.apply(App.scala:76)
> at scala.collection.immutable.List.foreach(List.scala:381)
> at 
> scala.collection.generic.TraversableForwarder$class.foreach(TraversableForwarder.scala:35)
> at scala.App$class.main(App.scala:76)
> at 
> org.apache.ignite.visor.commands.VisorConsole$.main(VisorConsole.scala:318)
> at 
> org.apache.ignite.visor.commands.VisorConsole.main(VisorConsole.scala)
> (wrn) : Invalid command name: 'disco -t=0h'
> (wrn) : Type 'help' to print commands list.
> {code}



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

[jira] [Updated] (IGNITE-8530) Exchange hangs during start/stop stress test

[Mikhail Cherkasov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Cherkasov updated IGNITE-8530:
--
Summary: Exchange hangs during start/stop stress test  (was: Exchange hangs 
during start/restart stress test)

> Exchange hangs during start/stop stress test
> 
>
> Key: IGNITE-8530
> URL: https://issues.apache.org/jira/browse/IGNITE-8530
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Mikhail Cherkasov
>Priority: Major
> Attachments: LocalRunner.java, Main2.java
>
>
> Please see attached test, it starts N_CORES*2+2 nodes first and after this 
> starts N_CORES*2 threads with while(true) cycle in which closes and starts 
> nodes with small random pause.
> After couple minutes it hangs with Failed to wait for partition map exchange.
>  



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

[jira] [Created] (IGNITE-8531) NPE is thrown on destroying empty partition

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-8531:
---

 Summary: NPE is thrown on destroying empty partition
 Key: IGNITE-8531
 URL: https://issues.apache.org/jira/browse/IGNITE-8531
 Project: Ignite
  Issue Type: Bug
  Components: persistence
Reporter: Sergey Chugunov
Assignee: Pavel Kovalenko


Improvement IGNITE-8320 introduced situation when NPE may happen: in case of 
destroying empty partition checkpoint record isn't logged to WAL but code 
attempts to create checkpoint marker anyway which leads to NPE.

We need to allow checkpointing empty partitions.



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

[jira] [Commented] (IGNITE-6538) Ignite Activate/Deactivate Cluster suite: After tests validation improvements test became flaky on TC

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480543#comment-16480543
 ] 

Dmitriy Pavlov commented on IGNITE-6538:


It is quite possible, so lets wait resolution for [IGNITE-8469]

> Ignite Activate/Deactivate Cluster suite: After tests validation improvements 
> test became flaky on TC
> -
>
> Key: IGNITE-6538
> URL: https://issues.apache.org/jira/browse/IGNITE-6538
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.6
>
>
> https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-238119157387028099=testDetails_Ignite20Tests=%3Cdefault%3E
> recent changes from [IGNITE-6124] which probably showed this problem is 
> following 
> {noformat}
>  fail("Activation should fail");
> {noformat}
> org.apache.ignite.internal.processors.cache.persistence.standbycluster.IgniteChangeGlobalStateTest#testActivateAfterFailGetLock
> Locally fail can be also reproduced, 6 from 20 failures.



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

[jira] [Commented] (IGNITE-8320) Page corruption during the rebalancing cache.

[Alexey Goncharuk (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480541#comment-16480541
 ] 

Alexey Goncharuk commented on IGNITE-8320:
--

Cherry-picked to ignite-2.5 as per discussion on the dev list.

> Page corruption during the rebalancing cache.
> -
>
> Key: IGNITE-8320
> URL: https://issues.apache.org/jira/browse/IGNITE-8320
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.4
>Reporter: Vyacheslav Koptilin
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.5
>
>
> Cache rebalance may result in page memory corruption.
> {noformat}
> [2018-04-18T14:33:23,260][ERROR][sys-#54][GridCacheIoManager] Failed 
> processing message [senderId=95f06c25-e6bb-48f7-a3e5-4c05fc1c49be, 
> msg=GridDhtPartitionSupplyMessage [rebalanceId=37, 
> topVer=AffinityTopologyVersion [topVer=53, minorTopVer=1], missed=null, 
> clean=null, msgSize=525350, estimatedKeysCnt=1690216, size=2, parts=[1, 2], 
> super=GridCacheGroupIdMessage [grpId=-1831596270]]]
>  org.apache.ignite.IgniteException: Runtime failure on row: Row@33b6805c[ 
> key:  [idHash=773709078, hash=-630455542, ...], val:  
> [idHash=1309051286, hash=-1321165334, ver: GridCacheVersion 
> [topVer=135435024, order=1523963943331, nodeOrder=4] ]
>  at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2102)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2049)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:247)
>  ~[ignite-indexing-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:454)
>  ~[ignite-indexing-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:653)
>  ~[ignite-indexing-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1866)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:407)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:1391)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1255)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1451)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:352)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:3527)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:2735)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.preloadEntry(GridDhtPartitionDemander.java:823)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.handleSupplyMessage(GridDhtPartitionDemander.java:704)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleSupplyMessage(GridDhtPreloader.java:347)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:365)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:355)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
>  [ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
>  [ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$700(GridCacheIoManager.java:99)
>  [ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  

[jira] [Updated] (IGNITE-8320) Page corruption during the rebalancing cache.

[Alexey Goncharuk (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Goncharuk updated IGNITE-8320:
-
Fix Version/s: (was: 2.6)
   2.5

> Page corruption during the rebalancing cache.
> -
>
> Key: IGNITE-8320
> URL: https://issues.apache.org/jira/browse/IGNITE-8320
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.4
>Reporter: Vyacheslav Koptilin
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.5
>
>
> Cache rebalance may result in page memory corruption.
> {noformat}
> [2018-04-18T14:33:23,260][ERROR][sys-#54][GridCacheIoManager] Failed 
> processing message [senderId=95f06c25-e6bb-48f7-a3e5-4c05fc1c49be, 
> msg=GridDhtPartitionSupplyMessage [rebalanceId=37, 
> topVer=AffinityTopologyVersion [topVer=53, minorTopVer=1], missed=null, 
> clean=null, msgSize=525350, estimatedKeysCnt=1690216, size=2, parts=[1, 2], 
> super=GridCacheGroupIdMessage [grpId=-1831596270]]]
>  org.apache.ignite.IgniteException: Runtime failure on row: Row@33b6805c[ 
> key:  [idHash=773709078, hash=-630455542, ...], val:  
> [idHash=1309051286, hash=-1321165334, ver: GridCacheVersion 
> [topVer=135435024, order=1523963943331, nodeOrder=4] ]
>  at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2102)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2049)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:247)
>  ~[ignite-indexing-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:454)
>  ~[ignite-indexing-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:653)
>  ~[ignite-indexing-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1866)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:407)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:1391)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1255)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1451)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:352)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:3527)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:2735)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.preloadEntry(GridDhtPartitionDemander.java:823)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.handleSupplyMessage(GridDhtPartitionDemander.java:704)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleSupplyMessage(GridDhtPreloader.java:347)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:365)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:355)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
>  [ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
>  [ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$700(GridCacheIoManager.java:99)
>  [ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> 

[jira] [Commented] (IGNITE-8491) Add JMX flag: Is the node in baseline or not?

[Vladislav Pyatkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480510#comment-16480510
 ] 

Vladislav Pyatkov commented on IGNITE-8491:
---

[~ivan.glukos] please, look at this patch.

> Add JMX flag: Is the node in baseline or not?
> -
>
> Key: IGNITE-8491
> URL: https://issues.apache.org/jira/browse/IGNITE-8491
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
>
> Need to add a baseline flag on JMX.
> {code}
> public interface IgniteMXBean {
> /**
>  * Gets a flag is node in baseline.
>  *
>  * @return Return a baseline flag.
>  */
> @MXBeanDescription("Baseline node flag.")
> public boolean isNodeInBaseline();
> {code}



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

[jira] [Updated] (IGNITE-7883) Cluster can have inconsistent affinity configuration

[Alexand Polyakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexand Polyakov updated IGNITE-7883:
-
Attachment: TC recheck 04.png

> Cluster can have inconsistent affinity configuration 
> -
>
> Key: IGNITE-7883
> URL: https://issues.apache.org/jira/browse/IGNITE-7883
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Alexand Polyakov
>Priority: Major
> Fix For: 2.6
>
> Attachments: TC recheck 01.png, TC recheck 02.png, TC recheck 03.png, 
> TC recheck 04.png, TC.png
>
>
> A cluster can have inconsistent affinity configuration if you created two 
> nodes, one with affinity key configuration and other without it(in IgniteCfg 
> or CacheCfg),  both nodes will work fine with no exceptions, but in the same 
> time they will apply different affinity rules to keys:
>  
> {code:java}
> package affinity;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheKeyConfiguration;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.affinity.Affinity;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import java.util.Arrays;
> public class Test {
> private static int id = 0;
> public static void main(String[] args) {
> Ignite ignite = Ignition.start(getConfiguration(true, false));
> Ignite ignite2 = Ignition.start(getConfiguration(false, false));
> Affinity affinity = ignite.affinity("TEST");
> Affinity affinity2 = ignite2.affinity("TEST");
> for (int i = 0; i < 1_000_000; i++) {
> AKey key = new AKey(i);
> if(affinity.partition(key) != affinity2.partition(key))
> System.out.println("FAILED for: " + key);
> }
> System.out.println("DONE");
> }
> private static IgniteConfiguration getConfiguration(boolean 
> withAffinityCfg, boolean client) {
> IgniteConfiguration cfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
> finder.setAddresses(Arrays.asList("localhost:47500..47600"));
> cfg.setClientMode(client);
> cfg.setIgniteInstanceName("test" + id++);
> CacheConfiguration cacheCfg = new CacheConfiguration("TEST");
> cacheCfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cacheCfg.setCacheMode(CacheMode.PARTITIONED);
> if(withAffinityCfg) {
> cacheCfg.setKeyConfiguration(new 
> CacheKeyConfiguration("affinity.AKey", "a"));
> }
> cfg.setCacheConfiguration(cacheCfg);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(finder));
> return cfg;
> }
> }
> class AKey {
> int a;
> public AKey(int a) {
> this.a = a;
> }
> @Override public String toString() {
> return "AKey{" +
> "a=" + a +
> '}';
> }
> }
> {code}



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

[jira] [Updated] (IGNITE-7883) Cluster can have inconsistent affinity configuration

[Alexand Polyakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexand Polyakov updated IGNITE-7883:
-
Attachment: TC recheck 03.png

> Cluster can have inconsistent affinity configuration 
> -
>
> Key: IGNITE-7883
> URL: https://issues.apache.org/jira/browse/IGNITE-7883
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Alexand Polyakov
>Priority: Major
> Fix For: 2.6
>
> Attachments: TC recheck 01.png, TC recheck 02.png, TC recheck 03.png, 
> TC.png
>
>
> A cluster can have inconsistent affinity configuration if you created two 
> nodes, one with affinity key configuration and other without it(in IgniteCfg 
> or CacheCfg),  both nodes will work fine with no exceptions, but in the same 
> time they will apply different affinity rules to keys:
>  
> {code:java}
> package affinity;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheKeyConfiguration;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.affinity.Affinity;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import java.util.Arrays;
> public class Test {
> private static int id = 0;
> public static void main(String[] args) {
> Ignite ignite = Ignition.start(getConfiguration(true, false));
> Ignite ignite2 = Ignition.start(getConfiguration(false, false));
> Affinity affinity = ignite.affinity("TEST");
> Affinity affinity2 = ignite2.affinity("TEST");
> for (int i = 0; i < 1_000_000; i++) {
> AKey key = new AKey(i);
> if(affinity.partition(key) != affinity2.partition(key))
> System.out.println("FAILED for: " + key);
> }
> System.out.println("DONE");
> }
> private static IgniteConfiguration getConfiguration(boolean 
> withAffinityCfg, boolean client) {
> IgniteConfiguration cfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
> finder.setAddresses(Arrays.asList("localhost:47500..47600"));
> cfg.setClientMode(client);
> cfg.setIgniteInstanceName("test" + id++);
> CacheConfiguration cacheCfg = new CacheConfiguration("TEST");
> cacheCfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cacheCfg.setCacheMode(CacheMode.PARTITIONED);
> if(withAffinityCfg) {
> cacheCfg.setKeyConfiguration(new 
> CacheKeyConfiguration("affinity.AKey", "a"));
> }
> cfg.setCacheConfiguration(cacheCfg);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(finder));
> return cfg;
> }
> }
> class AKey {
> int a;
> public AKey(int a) {
> this.a = a;
> }
> @Override public String toString() {
> return "AKey{" +
> "a=" + a +
> '}';
> }
> }
> {code}



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

[jira] [Updated] (IGNITE-7883) Cluster can have inconsistent affinity configuration

[Alexand Polyakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexand Polyakov updated IGNITE-7883:
-
Attachment: TC recheck 02.png

> Cluster can have inconsistent affinity configuration 
> -
>
> Key: IGNITE-7883
> URL: https://issues.apache.org/jira/browse/IGNITE-7883
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Alexand Polyakov
>Priority: Major
> Fix For: 2.6
>
> Attachments: TC recheck 01.png, TC recheck 02.png, TC.png
>
>
> A cluster can have inconsistent affinity configuration if you created two 
> nodes, one with affinity key configuration and other without it(in IgniteCfg 
> or CacheCfg),  both nodes will work fine with no exceptions, but in the same 
> time they will apply different affinity rules to keys:
>  
> {code:java}
> package affinity;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheKeyConfiguration;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.affinity.Affinity;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import java.util.Arrays;
> public class Test {
> private static int id = 0;
> public static void main(String[] args) {
> Ignite ignite = Ignition.start(getConfiguration(true, false));
> Ignite ignite2 = Ignition.start(getConfiguration(false, false));
> Affinity affinity = ignite.affinity("TEST");
> Affinity affinity2 = ignite2.affinity("TEST");
> for (int i = 0; i < 1_000_000; i++) {
> AKey key = new AKey(i);
> if(affinity.partition(key) != affinity2.partition(key))
> System.out.println("FAILED for: " + key);
> }
> System.out.println("DONE");
> }
> private static IgniteConfiguration getConfiguration(boolean 
> withAffinityCfg, boolean client) {
> IgniteConfiguration cfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
> finder.setAddresses(Arrays.asList("localhost:47500..47600"));
> cfg.setClientMode(client);
> cfg.setIgniteInstanceName("test" + id++);
> CacheConfiguration cacheCfg = new CacheConfiguration("TEST");
> cacheCfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cacheCfg.setCacheMode(CacheMode.PARTITIONED);
> if(withAffinityCfg) {
> cacheCfg.setKeyConfiguration(new 
> CacheKeyConfiguration("affinity.AKey", "a"));
> }
> cfg.setCacheConfiguration(cacheCfg);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(finder));
> return cfg;
> }
> }
> class AKey {
> int a;
> public AKey(int a) {
> this.a = a;
> }
> @Override public String toString() {
> return "AKey{" +
> "a=" + a +
> '}';
> }
> }
> {code}



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

[jira] [Updated] (IGNITE-7883) Cluster can have inconsistent affinity configuration

[Alexand Polyakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexand Polyakov updated IGNITE-7883:
-
Attachment: TC recheck 01.png

> Cluster can have inconsistent affinity configuration 
> -
>
> Key: IGNITE-7883
> URL: https://issues.apache.org/jira/browse/IGNITE-7883
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Alexand Polyakov
>Priority: Major
> Fix For: 2.6
>
> Attachments: TC recheck 01.png, TC.png
>
>
> A cluster can have inconsistent affinity configuration if you created two 
> nodes, one with affinity key configuration and other without it(in IgniteCfg 
> or CacheCfg),  both nodes will work fine with no exceptions, but in the same 
> time they will apply different affinity rules to keys:
>  
> {code:java}
> package affinity;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheKeyConfiguration;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.affinity.Affinity;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import java.util.Arrays;
> public class Test {
> private static int id = 0;
> public static void main(String[] args) {
> Ignite ignite = Ignition.start(getConfiguration(true, false));
> Ignite ignite2 = Ignition.start(getConfiguration(false, false));
> Affinity affinity = ignite.affinity("TEST");
> Affinity affinity2 = ignite2.affinity("TEST");
> for (int i = 0; i < 1_000_000; i++) {
> AKey key = new AKey(i);
> if(affinity.partition(key) != affinity2.partition(key))
> System.out.println("FAILED for: " + key);
> }
> System.out.println("DONE");
> }
> private static IgniteConfiguration getConfiguration(boolean 
> withAffinityCfg, boolean client) {
> IgniteConfiguration cfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
> finder.setAddresses(Arrays.asList("localhost:47500..47600"));
> cfg.setClientMode(client);
> cfg.setIgniteInstanceName("test" + id++);
> CacheConfiguration cacheCfg = new CacheConfiguration("TEST");
> cacheCfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cacheCfg.setCacheMode(CacheMode.PARTITIONED);
> if(withAffinityCfg) {
> cacheCfg.setKeyConfiguration(new 
> CacheKeyConfiguration("affinity.AKey", "a"));
> }
> cfg.setCacheConfiguration(cacheCfg);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(finder));
> return cfg;
> }
> }
> class AKey {
> int a;
> public AKey(int a) {
> this.a = a;
> }
> @Override public String toString() {
> return "AKey{" +
> "a=" + a +
> '}';
> }
> }
> {code}



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

[jira] [Updated] (IGNITE-7883) Cluster can have inconsistent affinity configuration

[Alexand Polyakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexand Polyakov updated IGNITE-7883:
-
Attachment: TC.png

> Cluster can have inconsistent affinity configuration 
> -
>
> Key: IGNITE-7883
> URL: https://issues.apache.org/jira/browse/IGNITE-7883
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Alexand Polyakov
>Priority: Major
> Fix For: 2.6
>
> Attachments: TC.png
>
>
> A cluster can have inconsistent affinity configuration if you created two 
> nodes, one with affinity key configuration and other without it(in IgniteCfg 
> or CacheCfg),  both nodes will work fine with no exceptions, but in the same 
> time they will apply different affinity rules to keys:
>  
> {code:java}
> package affinity;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheKeyConfiguration;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.affinity.Affinity;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import java.util.Arrays;
> public class Test {
> private static int id = 0;
> public static void main(String[] args) {
> Ignite ignite = Ignition.start(getConfiguration(true, false));
> Ignite ignite2 = Ignition.start(getConfiguration(false, false));
> Affinity affinity = ignite.affinity("TEST");
> Affinity affinity2 = ignite2.affinity("TEST");
> for (int i = 0; i < 1_000_000; i++) {
> AKey key = new AKey(i);
> if(affinity.partition(key) != affinity2.partition(key))
> System.out.println("FAILED for: " + key);
> }
> System.out.println("DONE");
> }
> private static IgniteConfiguration getConfiguration(boolean 
> withAffinityCfg, boolean client) {
> IgniteConfiguration cfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
> finder.setAddresses(Arrays.asList("localhost:47500..47600"));
> cfg.setClientMode(client);
> cfg.setIgniteInstanceName("test" + id++);
> CacheConfiguration cacheCfg = new CacheConfiguration("TEST");
> cacheCfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cacheCfg.setCacheMode(CacheMode.PARTITIONED);
> if(withAffinityCfg) {
> cacheCfg.setKeyConfiguration(new 
> CacheKeyConfiguration("affinity.AKey", "a"));
> }
> cfg.setCacheConfiguration(cacheCfg);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(finder));
> return cfg;
> }
> }
> class AKey {
> int a;
> public AKey(int a) {
> this.a = a;
> }
> @Override public String toString() {
> return "AKey{" +
> "a=" + a +
> '}';
> }
> }
> {code}



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

[jira] [Commented] (IGNITE-8266) Remove afterTestsStopped method due to stopAllGrids by default

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480494#comment-16480494
 ] 

Dmitriy Pavlov commented on IGNITE-8266:


I've attached screenshot with graphical interpretation of failures, black is 
timeout and red is test failure, green - suite passed

!screenshot-1.png!


> Remove afterTestsStopped method due to stopAllGrids by default
> --
>
> Key: IGNITE-8266
> URL: https://issues.apache.org/jira/browse/IGNITE-8266
> Project: Ignite
>  Issue Type: Sub-task
>Affects Versions: 2.5
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
>  Labels: test
> Fix For: 2.6
>
> Attachments: screenshot-1.png
>
>
> Remove this types of method from test in whole ignite-core module.
> {code:java}
> @Override protected void afterTestsStopped() throws Exception {
> super.afterTestsStopped();
> stopAllGrids();
> }{code}



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

[jira] [Updated] (IGNITE-8266) Remove afterTestsStopped method due to stopAllGrids by default

[Dmitriy Pavlov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov updated IGNITE-8266:
---
Attachment: screenshot-1.png

> Remove afterTestsStopped method due to stopAllGrids by default
> --
>
> Key: IGNITE-8266
> URL: https://issues.apache.org/jira/browse/IGNITE-8266
> Project: Ignite
>  Issue Type: Sub-task
>Affects Versions: 2.5
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
>  Labels: test
> Fix For: 2.6
>
> Attachments: screenshot-1.png
>
>
> Remove this types of method from test in whole ignite-core module.
> {code:java}
> @Override protected void afterTestsStopped() throws Exception {
> super.afterTestsStopped();
> stopAllGrids();
> }{code}



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

[jira] [Assigned] (IGNITE-7441) Drop IGNITE_SERVICES_COMPATIBILITY_MODE system property

[Amelchev Nikita (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amelchev Nikita reassigned IGNITE-7441:
---

Assignee: (was: Amelchev Nikita)

> Drop IGNITE_SERVICES_COMPATIBILITY_MODE system property
> ---
>
> Key: IGNITE-7441
> URL: https://issues.apache.org/jira/browse/IGNITE-7441
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Mekhanikov
>Priority: Minor
>
> IGNITE_SERVICES_COMPATIBILITY_MODE system property was introduced to 
> configure backward compatibility mode for service configuration classes. But 
> since it was done in 1.9 and current version is completely incompatible with 
> it, there is no point in keeping this property. 
> Moreover, it is ignored after IGNITE-5145.



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

[jira] [Commented] (IGNITE-8266) Remove afterTestsStopped method due to stopAllGrids by default

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480488#comment-16480488
 ] 

Dmitriy Pavlov commented on IGNITE-8266:


Test failures occurred in Run All does not indicate that something was broken 
by this change.

In the same time I also confused by the number of timeouts in Cache 6 , Hadoop, 
and IGFS suites.

Could we double check if there is no dangerous changes in these suites related 
tests?

> Remove afterTestsStopped method due to stopAllGrids by default
> --
>
> Key: IGNITE-8266
> URL: https://issues.apache.org/jira/browse/IGNITE-8266
> Project: Ignite
>  Issue Type: Sub-task
>Affects Versions: 2.5
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
>  Labels: test
> Fix For: 2.6
>
>
> Remove this types of method from test in whole ignite-core module.
> {code:java}
> @Override protected void afterTestsStopped() throws Exception {
> super.afterTestsStopped();
> stopAllGrids();
> }{code}



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

[jira] [Commented] (IGNITE-7793) SQL does not work if value has index filed which name equals to affinity key name

[JIRA]

[ 
https://issues.apache.org/jira/browse/IGNITE-7793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480486#comment-16480486
 ] 

Michał Warecki commented on IGNITE-7793:


Applies also to 2.4.0.

> SQL does not work if value has index filed which name equals to affinity key 
> name
> -
>
> Key: IGNITE-7793
> URL: https://issues.apache.org/jira/browse/IGNITE-7793
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Priority: Blocker
> Fix For: 2.6
>
>
> SQL does not work if value has index filed which name equals to affinity key 
> name:
> {code:java}
> public class AKey {
> @AffinityKeyMapped
> int a;
> public AKey(int a) {
> this.a = a;
> }
> }
> public class AVal {
> @QuerySqlField
> int a;
> public AVal(int a) {
> this.a = a;
> }
> }
> AKey aKey = new AKey(1);
> AVal aVal = new AVal(0);
> IgniteCache cache = ignite.cache("Instrument");
> cache.put(aKey, aVal);
> SqlFieldsQuery query = new SqlFieldsQuery("select * from \"Instrument\".AVal 
> it where it.a=?");
> List res = cache.query(query.setArgs(0)).getAll();
> if(res.isEmpty()) {
> System.out.println("! FAILED !!!");
> }
> {code}



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

[jira] [Created] (IGNITE-8530) Exchange hangs during start/restart stress test

[Mikhail Cherkasov (JIRA)]

Mikhail Cherkasov created IGNITE-8530:
-

 Summary: Exchange hangs during start/restart stress test
 Key: IGNITE-8530
 URL: https://issues.apache.org/jira/browse/IGNITE-8530
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.4
Reporter: Mikhail Cherkasov
 Attachments: LocalRunner.java, Main2.java

Please see attached test, it starts N_CORES*2+2 nodes first and after this 
starts N_CORES*2 threads with while(true) cycle in which closes and starts 
nodes with small random pause.

After couple minutes it hangs with Failed to wait for partition map exchange.

 



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

[jira] [Updated] (IGNITE-8529) Implement testing framework for checking WAL delta records consistency

[Ivan Rakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Rakov updated IGNITE-8529:
---
Description: 
We use sharp checkpointing of page memory in persistent mode. That implies that 
we write two types of record to write-ahead log: logical (e.g. data records) 
and phyisical (page snapshots + binary delta records). Physical records are 
applied only when node crashes/stops during ongoing checkpoint. We have the 
following invariant: checkpoint #(n-1) + all physical records = checkpoint #n.
If correctness of physical records is broken, Ignite node may recover with 
incorrect page memory state, which in turn can bring unexpected delayed errors. 
However, consistency of physical records is poorly tested: only small part of 
our autotests perform node restarts, and even less part of them perform node 
stop when ongoing checkpoint is running.
We should implement abstract test that:
1. Enforces checkpoint, freezes memory state at the moment of checkpoint.
2. Performs necessary test load.
3. Enforces checkpoint again, replays WAL and checks that page store at the 
moment of previous checkpoint with all applied physical records exactly equals 
to current checkpoint state.
Except for checking correctness, test framework should do the following:
1. Gather statistics (like histogram) for types of wriiten physical records. 
That will help us to know what types of physical records are covered by test.
2. Visualize expected and actual page state (with all applied physical records) 
if incorrect page state is detected.
Regarding implementation, I suppose we can use checkpoint listener mechanism to 
freeze page memory state at the moment of checkpoint.

  was:
We use sharp checkpointing of page memory in persistent mode. That implies that 
we write two types of record to write-ahead log: logical (e.g. data records) 
and phyisical (page snapshots + binary delta records). Physical records are 
applied only when node crashes/stops during ongoing checkpoint. We have the 
following invariant: checkpoint #(n-1) + all physical records = checkpoint #n.
If correctness of physical records is broken, Ignite node may recover with 
incorrect page memory state, which in turn can bring unexpected delayed errors. 
However, consistency of physical records is poorly tested: only small part of 
our autotests perform node restarts, and even less part of them performs node 
stop when ongoing checkpoint is running.
We should implement abstract test that:
1. Enforces checkpoint, freezes memory state at the moment of checkpoint.
2. Performs necessary test load.
3. Enforces checkpoint again, replays WAL and checks that page store at the 
moment of previous checkpoint with all applied physical records exactly equals 
to current checkpoint state.
Except for checking correctness, test framework should do the following:
1. Gather statistics (like histogram) for types of wriiten physical records. 
That will help us to know what types of physical records are covered by test.
2. Visualize expected and actual page state (with all applied physical records) 
if incorrect page state is detected.
Regarding implementation, I suppose we can use checkpoint listener mechanism to 
freeze page memory state at the moment of checkpoint.


> Implement testing framework for checking WAL delta records consistency
> --
>
> Key: IGNITE-8529
> URL: https://issues.apache.org/jira/browse/IGNITE-8529
> Project: Ignite
>  Issue Type: New Feature
>  Components: persistence
>Reporter: Ivan Rakov
>Priority: Major
>
> We use sharp checkpointing of page memory in persistent mode. That implies 
> that we write two types of record to write-ahead log: logical (e.g. data 
> records) and phyisical (page snapshots + binary delta records). Physical 
> records are applied only when node crashes/stops during ongoing checkpoint. 
> We have the following invariant: checkpoint #(n-1) + all physical records = 
> checkpoint #n.
> If correctness of physical records is broken, Ignite node may recover with 
> incorrect page memory state, which in turn can bring unexpected delayed 
> errors. However, consistency of physical records is poorly tested: only small 
> part of our autotests perform node restarts, and even less part of them 
> perform node stop when ongoing checkpoint is running.
> We should implement abstract test that:
> 1. Enforces checkpoint, freezes memory state at the moment of checkpoint.
> 2. Performs necessary test load.
> 3. Enforces checkpoint again, replays WAL and checks that page store at the 
> moment of previous checkpoint with all applied physical records exactly 
> equals to current checkpoint state.
> Except for checking correctness, test framework should do the following:
> 1. Gather statistics (like histogram) 

[jira] [Updated] (IGNITE-8529) Implement testing framework for checking WAL delta records consistency

[Ivan Rakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Rakov updated IGNITE-8529:
---
Summary: Implement testing framework for checking WAL delta records 
consistency  (was: Implement testing framework for checking delta records 
consistency)

> Implement testing framework for checking WAL delta records consistency
> --
>
> Key: IGNITE-8529
> URL: https://issues.apache.org/jira/browse/IGNITE-8529
> Project: Ignite
>  Issue Type: New Feature
>  Components: persistence
>Reporter: Ivan Rakov
>Priority: Major
>
> We use sharp checkpointing of page memory in persistent mode. That implies 
> that we write two types of record to write-ahead log: logical (e.g. data 
> records) and phyisical (page snapshots + binary delta records). Physical 
> records are applied only when node crashes/stops during ongoing checkpoint. 
> We have the following invariant: checkpoint #(n-1) + all physical records = 
> checkpoint #n.
> If correctness of physical records is broken, Ignite node may recover with 
> incorrect page memory state, which in turn can bring unexpected delayed 
> errors. However, consistency of physical records is poorly tested: only small 
> part of our autotests perform node restarts, and even less part of them 
> performs node stop when ongoing checkpoint is running.
> We should implement abstract test that:
> 1. Enforces checkpoint, freezes memory state at the moment of checkpoint.
> 2. Performs necessary test load.
> 3. Enforces checkpoint again, replays WAL and checks that page store at the 
> moment of previous checkpoint with all applied physical records exactly 
> equals to current checkpoint state.
> Except for checking correctness, test framework should do the following:
> 1. Gather statistics (like histogram) for types of wriiten physical records. 
> That will help us to know what types of physical records are covered by test.
> 2. Visualize expected and actual page state (with all applied physical 
> records) if incorrect page state is detected.
> Regarding implementation, I suppose we can use checkpoint listener mechanism 
> to freeze page memory state at the moment of checkpoint.



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

[jira] [Created] (IGNITE-8529) Implement testing framework for checking delta records consistency

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-8529:
--

 Summary: Implement testing framework for checking delta records 
consistency
 Key: IGNITE-8529
 URL: https://issues.apache.org/jira/browse/IGNITE-8529
 Project: Ignite
  Issue Type: New Feature
  Components: persistence
Reporter: Ivan Rakov


We use sharp checkpointing of page memory in persistent mode. That implies that 
we write two types of record to write-ahead log: logical (e.g. data records) 
and phyisical (page snapshots + binary delta records). Physical records are 
applied only when node crashes/stops during ongoing checkpoint. We have the 
following invariant: checkpoint #(n-1) + all physical records = checkpoint #n.
If correctness of physical records is broken, Ignite node may recover with 
incorrect page memory state, which in turn can bring unexpected delayed errors. 
However, consistency of physical records is poorly tested: only small part of 
our autotests perform node restarts, and even less part of them performs node 
stop when ongoing checkpoint is running.
We should implement abstract test that:
1. Enforces checkpoint, freezes memory state at the moment of checkpoint.
2. Performs necessary test load.
3. Enforces checkpoint again, replays WAL and checks that page store at the 
moment of previous checkpoint with all applied physical records exactly equals 
to current checkpoint state.
Except for checking correctness, test framework should do the following:
1. Gather statistics (like histogram) for types of wriiten physical records. 
That will help us to know what types of physical records are covered by test.
2. Visualize expected and actual page state (with all applied physical records) 
if incorrect page state is detected.
Regarding implementation, I suppose we can use checkpoint listener mechanism to 
freeze page memory state at the moment of checkpoint.



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

[jira] [Commented] (IGNITE-4575) Implement wrapper for enums based on H2 user value type

[Andrew Mashenkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480455#comment-16480455
 ] 

Andrew Mashenkov commented on IGNITE-4575:
--

H2 guys has fixed an issue in latest 1.4.197 that can block this ticket until 
H2 dependency upgrade:
PR #970: Added support for ENUM in prepared statement where clause

> Implement wrapper for enums based on H2 user value type
> ---
>
> Key: IGNITE-4575
> URL: https://issues.apache.org/jira/browse/IGNITE-4575
> Project: Ignite
>  Issue Type: New Feature
>  Components: sql
>Reporter: Alexander Paschenko
>Assignee: Sergey Kalashnikov
>Priority: Major
>  Labels: sql-engine
> Fix For: 2.6
>
>




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

[jira] [Comment Edited] (IGNITE-4575) Implement wrapper for enums based on H2 user value type

[Andrew Mashenkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480455#comment-16480455
 ] 

Andrew Mashenkov edited comment on IGNITE-4575 at 5/18/18 10:11 AM:


H2 guys has fixed an issue in latest 1.4.197 which can block this ticket until 
H2 dependency upgrade:
 PR #970: Added support for ENUM in prepared statement where clause


was (Author: amashenkov):
H2 guys has fixed an issue in latest 1.4.197 that can block this ticket until 
H2 dependency upgrade:
PR #970: Added support for ENUM in prepared statement where clause

> Implement wrapper for enums based on H2 user value type
> ---
>
> Key: IGNITE-4575
> URL: https://issues.apache.org/jira/browse/IGNITE-4575
> Project: Ignite
>  Issue Type: New Feature
>  Components: sql
>Reporter: Alexander Paschenko
>Assignee: Sergey Kalashnikov
>Priority: Major
>  Labels: sql-engine
> Fix For: 2.6
>
>




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

[jira] [Commented] (IGNITE-7642) Ignite fails with OOM if query has "NULLS LAST"

[Andrew Mashenkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480446#comment-16480446
 ] 

Andrew Mashenkov commented on IGNITE-7642:
--

H2 has an Issue #699: When using an index for sorting, the index is ignored 
when also using NULLS LAST/FIRST.
This issue is fixed in the latest h2-1.4.197 version.

Seems, we have to upgrade H2 dependency first. 

> Ignite fails with OOM if query has "NULLS LAST"
> ---
>
> Key: IGNITE-7642
> URL: https://issues.apache.org/jira/browse/IGNITE-7642
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Priority: Major
> Fix For: 2.6
>
> Attachments: OrderByNullsLastTest.java
>
>
> I have an index for "a" filed of "A" type and the following SQL works fine:
> SELECT * FROM A ORDER BY a LIMIT 0 + 50
>  
> but as soon as I added "NULLS LAST" it starts to fail with OOM error:
> SELECT * FROM A ORDER BY a NULLS LAST LIMIT 0 + 50
> However for both queries, EXPLAIN says that it the uses index, I don't see 
> why it should fail, but looks like ignite tryes to load all memory into heap 
> and sort there, and this leads to OOM.
>  
> A reproducer is attached.



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

[jira] [Comment Edited] (IGNITE-8476) AssertionError exception occurs when trying to remove node from baseline under loading

[Ivan Rakov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480443#comment-16480443
 ] 

Ivan Rakov edited comment on IGNITE-8476 at 5/18/18 9:59 AM:
-

I can't reproduce the issue so far. I've prepared a pull request with test that 
covers described scenario. Test stably passes.
Test contains cases with replicated/partitioned, atomic/tx caches, cross-cache 
transactions. There are no any AssertionErrors in log and loader threads don't 
hang.
[~qvad], please provide more precise conditions to reproduce the bug. If 
possible, please fix test in PR if it misses something.


was (Author: ivan.glukos):
I can't reproduce the issue so far. I've prepared a pull request with test of 
described scenario. Test stably passes.
Test contains cases with replicated/partitioned, atomic/tx caches, cross-cache 
transactions. There are no any AssertionErrors in log and loader threads don't 
hang.
[~qvad], please provide more precise conditions to reproduce the bug. If 
possible, please fix test in PR if it misses something.

> AssertionError exception occurs when trying to remove node from baseline 
> under loading
> --
>
> Key: IGNITE-8476
> URL: https://issues.apache.org/jira/browse/IGNITE-8476
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Assignee: Ivan Rakov
>Priority: Blocker
>
> Run 6 nodes, start loading (8 threads, 1000 2x cache.get() and 2x cache.put() 
> in each thread per second)
> Kill 2 nodes and try to remove one node from baseline using
> control.sh --baseline remove node1
>  control.sh --baseline version TOPOLOGY_VERSION
>  
> Utility hangs or connected client may hangs, this assertion appears in log 
> For transactional cache:
> {code:java}
> [16:32:58,960][SEVERE][sys-stripe-14-#15][G] Failed to execute runnable.
> java.lang.AssertionError: localNode = be945692-c750-4d72-b9a1-9ac4170ff125, 
> dhtNodes = [ZookeeperClusterNode [id=810226e6-656a-460d-8069-ca7d2dd294ef, 
> addrs=[172.17.0.1, 0:0:0:0:0:0:0:1%lo, 172.25.1.28, 127.0.0.1], order=1, 
> loc=false, client=false], ZookeeperClusterNode 
> [id=be945692-c750-4d72-b9a1-9ac4170ff125, addrs=[172.17.0.1, 172.25.1.28, 
> 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=3, loc=true, client=false], 
> ZookeeperClusterNode [id=db4503f6-9185-4673-b38c-8890dfa69511, 
> addrs=[172.17.0.1, 172.25.1.37, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=5, 
> loc=false, client=false], ZookeeperClusterNode 
> [id=3b8d8d4f-3513-4d39-a1fd-7ec5b15fc653, addrs=[172.17.0.1, 172.25.1.37, 
> 127.0.0.1, 0:0:0:0:0:0:0:1%lo], order=4, loc=false, client=false], 
> ZookeeperClusterNode [id=2bfc8c2e-2f47-4126-9cc4-6f017ce7efde, 
> addrs=[172.17.0.1, 172.25.1.37, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=6, 
> loc=false, client=false]]
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.map(GridDhtTxPrepareFuture.java:1520)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1239)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:671)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1048)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:397)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:516)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:150)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:135)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:97)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:177)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:175)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> at 
> 

[jira] [Commented] (IGNITE-8476) AssertionError exception occurs when trying to remove node from baseline under loading

[Ivan Rakov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480443#comment-16480443
 ] 

Ivan Rakov commented on IGNITE-8476:


I can't reproduce the issue so far. I've prepared a pull request with test of 
described scenario. Test stably passes.
Test contains cases with replicated/partitioned, atomic/tx caches, cross-cache 
transactions. There are no any AssertionErrors in log and loader threads don't 
hang.
[~qvad], please provide more precise conditions to reproduce the bug. If 
possible, please fix test in PR if it misses something.

> AssertionError exception occurs when trying to remove node from baseline 
> under loading
> --
>
> Key: IGNITE-8476
> URL: https://issues.apache.org/jira/browse/IGNITE-8476
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Assignee: Ivan Rakov
>Priority: Blocker
>
> Run 6 nodes, start loading (8 threads, 1000 2x cache.get() and 2x cache.put() 
> in each thread per second)
> Kill 2 nodes and try to remove one node from baseline using
> control.sh --baseline remove node1
>  control.sh --baseline version TOPOLOGY_VERSION
>  
> Utility hangs or connected client may hangs, this assertion appears in log 
> For transactional cache:
> {code:java}
> [16:32:58,960][SEVERE][sys-stripe-14-#15][G] Failed to execute runnable.
> java.lang.AssertionError: localNode = be945692-c750-4d72-b9a1-9ac4170ff125, 
> dhtNodes = [ZookeeperClusterNode [id=810226e6-656a-460d-8069-ca7d2dd294ef, 
> addrs=[172.17.0.1, 0:0:0:0:0:0:0:1%lo, 172.25.1.28, 127.0.0.1], order=1, 
> loc=false, client=false], ZookeeperClusterNode 
> [id=be945692-c750-4d72-b9a1-9ac4170ff125, addrs=[172.17.0.1, 172.25.1.28, 
> 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=3, loc=true, client=false], 
> ZookeeperClusterNode [id=db4503f6-9185-4673-b38c-8890dfa69511, 
> addrs=[172.17.0.1, 172.25.1.37, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=5, 
> loc=false, client=false], ZookeeperClusterNode 
> [id=3b8d8d4f-3513-4d39-a1fd-7ec5b15fc653, addrs=[172.17.0.1, 172.25.1.37, 
> 127.0.0.1, 0:0:0:0:0:0:0:1%lo], order=4, loc=false, client=false], 
> ZookeeperClusterNode [id=2bfc8c2e-2f47-4126-9cc4-6f017ce7efde, 
> addrs=[172.17.0.1, 172.25.1.37, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=6, 
> loc=false, client=false]]
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.map(GridDhtTxPrepareFuture.java:1520)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1239)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:671)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1048)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:397)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:516)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:150)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:135)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:97)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:177)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:175)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
> at 
> 

[jira] [Commented] (IGNITE-8476) AssertionError exception occurs when trying to remove node from baseline under loading

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480439#comment-16480439
 ] 

ASF GitHub Bot commented on IGNITE-8476:


GitHub user glukos opened a pull request:

https://github.com/apache/ignite/pull/4022

IGNITE-8476 added covering test



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-8476-test

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4022.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4022


commit a70cfc938de4433aa8dbf488d9d87c37dd7a4f55
Author: Ivan Rakov 
Date:   2018-05-18T09:47:28Z

IGNITE-8476 added covering test




> AssertionError exception occurs when trying to remove node from baseline 
> under loading
> --
>
> Key: IGNITE-8476
> URL: https://issues.apache.org/jira/browse/IGNITE-8476
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Assignee: Ivan Rakov
>Priority: Blocker
>
> Run 6 nodes, start loading (8 threads, 1000 2x cache.get() and 2x cache.put() 
> in each thread per second)
> Kill 2 nodes and try to remove one node from baseline using
> control.sh --baseline remove node1
>  control.sh --baseline version TOPOLOGY_VERSION
>  
> Utility hangs or connected client may hangs, this assertion appears in log 
> For transactional cache:
> {code:java}
> [16:32:58,960][SEVERE][sys-stripe-14-#15][G] Failed to execute runnable.
> java.lang.AssertionError: localNode = be945692-c750-4d72-b9a1-9ac4170ff125, 
> dhtNodes = [ZookeeperClusterNode [id=810226e6-656a-460d-8069-ca7d2dd294ef, 
> addrs=[172.17.0.1, 0:0:0:0:0:0:0:1%lo, 172.25.1.28, 127.0.0.1], order=1, 
> loc=false, client=false], ZookeeperClusterNode 
> [id=be945692-c750-4d72-b9a1-9ac4170ff125, addrs=[172.17.0.1, 172.25.1.28, 
> 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=3, loc=true, client=false], 
> ZookeeperClusterNode [id=db4503f6-9185-4673-b38c-8890dfa69511, 
> addrs=[172.17.0.1, 172.25.1.37, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=5, 
> loc=false, client=false], ZookeeperClusterNode 
> [id=3b8d8d4f-3513-4d39-a1fd-7ec5b15fc653, addrs=[172.17.0.1, 172.25.1.37, 
> 127.0.0.1, 0:0:0:0:0:0:0:1%lo], order=4, loc=false, client=false], 
> ZookeeperClusterNode [id=2bfc8c2e-2f47-4126-9cc4-6f017ce7efde, 
> addrs=[172.17.0.1, 172.25.1.37, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=6, 
> loc=false, client=false]]
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.map(GridDhtTxPrepareFuture.java:1520)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1239)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:671)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1048)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:397)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:516)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:150)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:135)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:97)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:177)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:175)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> at 
> 

[jira] [Updated] (IGNITE-8528) Peer deployment does not work for continuous query transformers

[Alexey Goncharuk (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Goncharuk updated IGNITE-8528:
-
Affects Version/s: 2.5

> Peer deployment does not work for continuous query transformers
> ---
>
> Key: IGNITE-8528
> URL: https://issues.apache.org/jira/browse/IGNITE-8528
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Alexey Goncharuk
>Priority: Major
> Fix For: 2.6
>
>
> Build local Ignite distribution using
> {code}
> mvn clean install -Pall-java,all-scala,licenses -DskipTests
> mvn initialize -Prelease
> {code}
> Start one node in console and run continuous query with transformer example 
> in IDE. I am getting the following exception:
> {code}
> [15:30:43] To start Console Management & Monitoring run 
> ignitevisorcmd.{sh|bat}
> [15:30:43] 
> [15:30:43] Ignite node started OK (id=f1356a5b)
> [15:30:43] Topology snapshot [ver=1, servers=1, clients=0, CPUs=16, 
> offheap=19.0GB, heap=2.0GB]
> [15:30:43]   ^-- Node [id=F1356A5B-4CDB-4480-A64F-35BF2C96DBB5, 
> clusterState=ACTIVE]
> [15:30:43] Data Regions Configured:
> [15:30:43]   ^-- default [initSize=256.0 MiB, maxSize=18.9 GiB, 
> persistenceEnabled=false]
> [15:30:52] Topology snapshot [ver=2, servers=2, clients=0, CPUs=16, 
> offheap=38.0GB, heap=3.0GB]
> [15:30:52]   ^-- Node [id=F1356A5B-4CDB-4480-A64F-35BF2C96DBB5, 
> clusterState=ACTIVE]
> [15:30:52] Data Regions Configured:
> [15:30:52]   ^-- default [initSize=256.0 MiB, maxSize=18.9 GiB, 
> persistenceEnabled=false]
> [15:30:53,065][SEVERE][tcp-disco-msg-worker-#2][BinaryContext] Failed to 
> deserialize object [typeName=java.lang.invoke.SerializedLambda]
> class org.apache.ignite.binary.BinaryObjectException: Failed to read field 
> [name=capturingClass]
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:870)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1982)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:698)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:183)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:870)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>   at 
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:310)
>   at 
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:99)
>   at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9962)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9991)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryDeployableObject.unmarshal(CacheContinuousQueryDeployableObject.java:94)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandlerV3.p2pUnmarshal(CacheContinuousQueryHandlerV3.java:155)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1327)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$400(GridContinuousProcessor.java:108)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:200)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:191)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:707)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:589)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5479)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5305)
>   at 
> 

[jira] [Updated] (IGNITE-8528) Peer deployment does not work for continuous query transformers

[Alexey Goncharuk (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Goncharuk updated IGNITE-8528:
-
Description: 
Build local Ignite distribution using
{code}
mvn clean install -Pall-java,all-scala,licenses -DskipTests
mvn initialize -Prelease
{code}

Start one node in console and run continuous query with transformer example in 
IDE. I am getting the following exception:

{code}
[15:30:43] To start Console Management & Monitoring run ignitevisorcmd.{sh|bat}
[15:30:43] 
[15:30:43] Ignite node started OK (id=f1356a5b)
[15:30:43] Topology snapshot [ver=1, servers=1, clients=0, CPUs=16, 
offheap=19.0GB, heap=2.0GB]
[15:30:43]   ^-- Node [id=F1356A5B-4CDB-4480-A64F-35BF2C96DBB5, 
clusterState=ACTIVE]
[15:30:43] Data Regions Configured:
[15:30:43]   ^-- default [initSize=256.0 MiB, maxSize=18.9 GiB, 
persistenceEnabled=false]
[15:30:52] Topology snapshot [ver=2, servers=2, clients=0, CPUs=16, 
offheap=38.0GB, heap=3.0GB]
[15:30:52]   ^-- Node [id=F1356A5B-4CDB-4480-A64F-35BF2C96DBB5, 
clusterState=ACTIVE]
[15:30:52] Data Regions Configured:
[15:30:52]   ^-- default [initSize=256.0 MiB, maxSize=18.9 GiB, 
persistenceEnabled=false]
[15:30:53,065][SEVERE][tcp-disco-msg-worker-#2][BinaryContext] Failed to 
deserialize object [typeName=java.lang.invoke.SerializedLambda]
class org.apache.ignite.binary.BinaryObjectException: Failed to read field 
[name=capturingClass]
at 
org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
at 
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:870)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1982)
at 
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:698)
at 
org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:183)
at 
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:870)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
at 
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:310)
at 
org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:99)
at 
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
at 
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9962)
at 
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9991)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryDeployableObject.unmarshal(CacheContinuousQueryDeployableObject.java:94)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandlerV3.p2pUnmarshal(CacheContinuousQueryHandlerV3.java:155)
at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1327)
at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$400(GridContinuousProcessor.java:108)
at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:200)
at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:191)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:707)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:589)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5479)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5305)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2765)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
Caused by: class 

[jira] [Updated] (IGNITE-8528) Peer deployment does not work for continuous query transformers

[Alexey Goncharuk (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Goncharuk updated IGNITE-8528:
-
Fix Version/s: 2.6

> Peer deployment does not work for continuous query transformers
> ---
>
> Key: IGNITE-8528
> URL: https://issues.apache.org/jira/browse/IGNITE-8528
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Alexey Goncharuk
>Priority: Major
> Fix For: 2.6
>
>
> Build local Ignite distribution using
> {code}
> mvn clean install -Pall-java,all-scala,licenses -DskipTests
> mvn initialize -Prelease
> {code}
> Start one node in console and run continuous query with transformer example 
> in IDE. I am getting the following exception:
> {code}
> [15:30:43] To start Console Management & Monitoring run 
> ignitevisorcmd.{sh|bat}
> [15:30:43] 
> [15:30:43] Ignite node started OK (id=f1356a5b)
> [15:30:43] Topology snapshot [ver=1, servers=1, clients=0, CPUs=16, 
> offheap=19.0GB, heap=2.0GB]
> [15:30:43]   ^-- Node [id=F1356A5B-4CDB-4480-A64F-35BF2C96DBB5, 
> clusterState=ACTIVE]
> [15:30:43] Data Regions Configured:
> [15:30:43]   ^-- default [initSize=256.0 MiB, maxSize=18.9 GiB, 
> persistenceEnabled=false]
> [15:30:52] Topology snapshot [ver=2, servers=2, clients=0, CPUs=16, 
> offheap=38.0GB, heap=3.0GB]
> [15:30:52]   ^-- Node [id=F1356A5B-4CDB-4480-A64F-35BF2C96DBB5, 
> clusterState=ACTIVE]
> [15:30:52] Data Regions Configured:
> [15:30:52]   ^-- default [initSize=256.0 MiB, maxSize=18.9 GiB, 
> persistenceEnabled=false]
> [15:30:53,065][SEVERE][tcp-disco-msg-worker-#2][BinaryContext] Failed to 
> deserialize object [typeName=java.lang.invoke.SerializedLambda]
> class org.apache.ignite.binary.BinaryObjectException: Failed to read field 
> [name=capturingClass]
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:870)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1982)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:698)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:183)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:870)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>   at 
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:310)
>   at 
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:99)
>   at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9962)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9991)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryDeployableObject.unmarshal(CacheContinuousQueryDeployableObject.java:94)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandlerV3.p2pUnmarshal(CacheContinuousQueryHandlerV3.java:155)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1327)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$400(GridContinuousProcessor.java:108)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:200)
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:191)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:707)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:589)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5479)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5305)
>   at 
> 

[jira] [Created] (IGNITE-8528) Peer deployment does not work for continuous query transformers

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-8528:


 Summary: Peer deployment does not work for continuous query 
transformers
 Key: IGNITE-8528
 URL: https://issues.apache.org/jira/browse/IGNITE-8528
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexey Goncharuk






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

[jira] [Updated] (IGNITE-8527) Show actual rebalance starting in logs

[Pavel Kovalenko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Kovalenko updated IGNITE-8527:

Fix Version/s: 2.6

> Show actual rebalance starting in logs
> --
>
> Key: IGNITE-8527
> URL: https://issues.apache.org/jira/browse/IGNITE-8527
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Trivial
> Fix For: 2.6
>
>
> We should increase level of logging from DEBUG to INFO for message:
> {noformat}
> if (log.isDebugEnabled())
> log.debug("Requested rebalancing [from node=" 
> + node.id() + ", listener index=" + topicId + " " + demandMsg.rebalanceId() + 
> ", partitions count=" + stripePartitions.get(topicId).size() + " (" + 
> stripePartitions.get(topicId).partitionsList() + ")]");
> {noformat}
> to have actual rebalancing start time.



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