[jira] [Commented] (IGNITE-6804) Print a warning if HashMap is passed into bulk update operations

2019-10-16 Thread Denis A. Magda (Jira) 


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

Denis A. Magda commented on IGNITE-6804:


[~ilyak], thanks for taking over this task. I suggested some edits in PR.

> Print a warning if HashMap is passed into bulk update operations
> 
>
> Key: IGNITE-6804
> URL: https://issues.apache.org/jira/browse/IGNITE-6804
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Denis A. Magda
>Assignee: Ilya Kasnacheev
>Priority: Critical
>  Labels: usability
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Ignite newcomers tend to stumble on deadlocks simply because the keys are 
> passed in an unordered HashMap. Propose to do the following:
> * update bulk operations Java docs.
> * print out a warning if not SortedMap (e.g. HashMap, 
> Weak/Identity/Concurrent/Linked HashMap etc) is passed into
> a bulk method (instead of SortedMap) and contains more than 1 element. 
> However, we should make sure that we only print that warning once and not 
> every time the API is called.
> * do not produce warning for explicit optimistic transactions
> More details are here:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-Ignite-2-0-0-GridUnsafe-unmonitor-td23706.html



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-10226) Partition may restore wrong MOVING state during crash recovery

2019-10-16 Thread Pavel Kovalenko (Jira) 


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

Pavel Kovalenko commented on IGNITE-10226:
--

[~matijap] Look like detect lost partitions is not invoked during cluster 
activation, which is definitely a bug. I've filed corresponding ticket 
https://issues.apache.org/jira/browse/IGNITE-12297
Yes in 1 node cluster and partition in MOVING state resetLostPartitions will 
not have an effect. However, you can return back partition to OWNING state with 
the following trick:
1) Start another node, this is a topology event that will trigger detecting 
lost partitions.
2) Stop started node
3) If you have partition loss policy != IGNORE trigger explicitly 
`resetLostPartitions`
It should help to return back partition to OWNING state.


> Partition may restore wrong MOVING state during crash recovery
> --
>
> Key: IGNITE-10226
> URL: https://issues.apache.org/jira/browse/IGNITE-10226
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.4
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.8
>
>
> The way to get it exists only in versions that don't have IGNITE-9420:
> 1) Start cache, upload some data to partitions, forceCheckpoint
> 2) Start uploading additional data. Kill node. Node should be killed with 
> skipping last checkpoint, or during checkpoint mark phase.
> 3) Re-start node. The crash recovery process for partitions started. When we 
> create partition during crash recovery (topology().forceCreatePartition()) we 
> log it's initial state to WAL. If we have any logical update relates to 
> partition we'll log wrong MOVING state to the end of current WAL. This state 
> will be considered as last valid when we process PartitionMetaStateRecord 
> record's during logical recovery. In "restorePartitionsState" phase this 
> state will be chosen as final and the partition will change to MOVING, even 
> in page memory it has OWNING or something else.
> To fix this problem in 2.4 - 2.7 versions, additional logging partition state 
> change to WAL during crash recovery (logical recovery) should be removed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-12297) Detect lost partitions is not happened during cluster activation

2019-10-16 Thread Pavel Kovalenko (Jira) 
Pavel Kovalenko created IGNITE-12297:


 Summary: Detect lost partitions is not happened during cluster 
activation
 Key: IGNITE-12297
 URL: https://issues.apache.org/jira/browse/IGNITE-12297
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.4
Reporter: Pavel Kovalenko
 Fix For: 2.8


We invoke `detectLostPartitions` during PME only if there is a server join or 
server left.
However,  we can activate a persistent cluster where a partition may have 
MOVING status on all nodes. In this case, a partition may stay in MOVING state 
forever before any other topology event. 





--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-12282) Access restriction to the internal package of Ignite

2019-10-16 Thread Denis Garus (Jira) 


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

Denis Garus updated IGNITE-12282:
-
Labels: iep-38  (was: )

> Access restriction to the internal package of Ignite
> 
>
> Key: IGNITE-12282
> URL: https://issues.apache.org/jira/browse/IGNITE-12282
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Garus
>Priority: Major
>  Labels: iep-38
>
> A user-defined code shouldn't have access to _org.apache.ignite.internal_.* 
> that is the internal package of Ignite.
> To restrict a user-defined code, we need to set the package name to the 
> _package.access_ security property.
> To grand access to a package, we have to use _accessClassInPackage.\{package 
> name}_ runtime permission.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-12283) Access restriction to IgniteKernal

2019-10-16 Thread Denis Garus (Jira) 


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

Denis Garus updated IGNITE-12283:
-
Labels: iep-38  (was: )

> Access restriction to IgniteKernal
> --
>
> Key: IGNITE-12283
> URL: https://issues.apache.org/jira/browse/IGNITE-12283
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Garus
>Priority: Major
>  Labels: iep-38
>
> IgniteKernal allows a user-defined code to get access to the internal 
> features of Ignite. That behavior leads to security lack.
> We must encapsulate _IgniteKernal_ to restrict access to it from user-defined 
> code.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-11410) Sandbox for user-defined code

2019-10-16 Thread Denis Garus (Jira) 


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

Denis Garus updated IGNITE-11410:
-
Labels: iep-38  (was: )

> Sandbox for user-defined code
> -
>
> Key: IGNITE-11410
> URL: https://issues.apache.org/jira/browse/IGNITE-11410
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Denis Garus
>Priority: Major
>  Labels: iep-38
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> We should provide a restricted environment (sandbox) in which to run 
> user-defined code securely. To get it done, we would use the java sandbox 
> model.
>  The java sandbox model allows restricting access from user-defined code to 
> the system resources or security-sensitive feature of java, for example, 
> reflection.
> The user-defined code contains:
>  - StreamReceiver for DataStreamer:
>  - EntryProcessor;
>  - ComputeJob;
>  - filter and transformer for ScanQuery.
> The user-defined code will get permissions from GridSecuerityProcessor 
> (security plugin).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (IGNITE-10226) Partition may restore wrong MOVING state during crash recovery

2019-10-16 Thread Matija Polajnar (Jira) 


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

Matija Polajnar edited comment on IGNITE-10226 at 10/16/19 11:25 AM:
-

On development environments (for now, luckily) we sometimes get errors like 
this one:
{code:java}
...
Caused by: javax.cache.CacheException: class 
org.apache.ignite.cluster.ClusterTopologyException: Cannot run update query. 
Node must own all the necessary partitions.
at 
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.IgniteCacheFutureImpl.convertException(IgniteCacheFutureImpl.java:62)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.util.future.IgniteFutureImpl.get(IgniteFutureImpl.java:137)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
com.marand.thinkehr.tasks.common.ignite.IgniteCompletableFuture.lambda$new$2ae3f52e$1(IgniteCompletableFuture.java:25)
 ~[classes/:?]
at 
org.apache.ignite.internal.util.future.IgniteFutureImpl$InternalFutureListener.apply(IgniteFutureImpl.java:215)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.util.future.IgniteFutureImpl$InternalFutureListener.apply(IgniteFutureImpl.java:179)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:385)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:355)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.util.future.IgniteFutureImpl.listen(IgniteFutureImpl.java:71)
 ~[ignite-core-2.7.0.jar:2.7.0]
...
Caused by: org.apache.ignite.cluster.ClusterTopologyException: Cannot run 
update query. Node must own all the necessary partitions.
at 
org.apache.ignite.internal.util.IgniteUtils$7.apply(IgniteUtils.java:888) 
~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.util.IgniteUtils$7.apply(IgniteUtils.java:886) 
~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.IgniteCacheFutureImpl.convertException(IgniteCacheFutureImpl.java:62)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.util.future.IgniteFutureImpl.get(IgniteFutureImpl.java:137)
 ~[ignite-core-2.7.0.jar:2.7.0]
...
Caused by: org.apache.ignite.internal.cluster.ClusterTopologyCheckedException: 
Cannot run update query. Node must own all the necessary partitions.
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.checkPartitions(GridDhtTxAbstractEnlistFuture.java:922)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.init(GridDhtTxAbstractEnlistFuture.java:336)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistFuture.enlistLocal(GridNearTxEnlistFuture.java:518)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistFuture.sendBatch(GridNearTxEnlistFuture.java:413)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistFuture.sendNextBatches(GridNearTxEnlistFuture.java:168)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistFuture.map(GridNearTxEnlistFuture.java:144)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxAbstractEnlistFuture.init(GridNearTxAbstractEnlistFuture.java:241)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.updateAsync(GridNearTxLocal.java:2099)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.mvccRemoveAllAsync0(GridNearTxLocal.java:1976)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.removeAllAsync0(GridNearTxLocal.java:1689)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.removeAllAsync(GridNearTxLocal.java:554)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter$40.op(GridCacheAdapter.java:3174)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter$AsyncOp.op(GridCacheAdapter.java:5288)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache

[jira] [Commented] (IGNITE-10226) Partition may restore wrong MOVING state during crash recovery

2019-10-16 Thread Matija Polajnar (Jira) 


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

Matija Polajnar commented on IGNITE-10226:
--

On development environments (for now, luckily) we sometimes get errors like 
this one:
{code:java}
...
Caused by: javax.cache.CacheException: class 
org.apache.ignite.cluster.ClusterTopologyException: Cannot run update query. 
Node must own all the necessary partitions.
at 
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.IgniteCacheFutureImpl.convertException(IgniteCacheFutureImpl.java:62)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.util.future.IgniteFutureImpl.get(IgniteFutureImpl.java:137)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
com.marand.thinkehr.tasks.common.ignite.IgniteCompletableFuture.lambda$new$2ae3f52e$1(IgniteCompletableFuture.java:25)
 ~[classes/:?]
at 
org.apache.ignite.internal.util.future.IgniteFutureImpl$InternalFutureListener.apply(IgniteFutureImpl.java:215)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.util.future.IgniteFutureImpl$InternalFutureListener.apply(IgniteFutureImpl.java:179)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:385)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:355)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.util.future.IgniteFutureImpl.listen(IgniteFutureImpl.java:71)
 ~[ignite-core-2.7.0.jar:2.7.0]
...
Caused by: org.apache.ignite.cluster.ClusterTopologyException: Cannot run 
update query. Node must own all the necessary partitions.
at 
org.apache.ignite.internal.util.IgniteUtils$7.apply(IgniteUtils.java:888) 
~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.util.IgniteUtils$7.apply(IgniteUtils.java:886) 
~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.IgniteCacheFutureImpl.convertException(IgniteCacheFutureImpl.java:62)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.util.future.IgniteFutureImpl.get(IgniteFutureImpl.java:137)
 ~[ignite-core-2.7.0.jar:2.7.0]
...
Caused by: org.apache.ignite.internal.cluster.ClusterTopologyCheckedException: 
Cannot run update query. Node must own all the necessary partitions.
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.checkPartitions(GridDhtTxAbstractEnlistFuture.java:922)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.init(GridDhtTxAbstractEnlistFuture.java:336)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistFuture.enlistLocal(GridNearTxEnlistFuture.java:518)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistFuture.sendBatch(GridNearTxEnlistFuture.java:413)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistFuture.sendNextBatches(GridNearTxEnlistFuture.java:168)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistFuture.map(GridNearTxEnlistFuture.java:144)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxAbstractEnlistFuture.init(GridNearTxAbstractEnlistFuture.java:241)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.updateAsync(GridNearTxLocal.java:2099)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.mvccRemoveAllAsync0(GridNearTxLocal.java:1976)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.removeAllAsync0(GridNearTxLocal.java:1689)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.removeAllAsync(GridNearTxLocal.java:554)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter$40.op(GridCacheAdapter.java:3174)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter$AsyncOp.op(GridCacheAdapter.java:5288)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOp(GridCacheAdapter.java:4450)

[jira] [Updated] (IGNITE-12296) .NET: Implement Log Throttle and print warning for unsafe PutAll ops

2019-10-16 Thread Pavel Tupitsyn (Jira) 


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

Pavel Tupitsyn updated IGNITE-12296:

Fix Version/s: 2.8

> .NET: Implement Log Throttle and print warning for unsafe PutAll ops
> 
>
> Key: IGNITE-12296
> URL: https://issues.apache.org/jira/browse/IGNITE-12296
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.8
>
>
> Right now it's not possible to do one-time developer warnings in .Net as 
> there is no Log Throttle. Please implement one. Please also issue warning if 
> random-order collection is passed to PutAll, InvokeAll, RemoveAll, as it is 
> prime source for deadlocks and developer frustration.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-12296) .NET: Implement Log Throttle and print warning for unsafe PutAll ops

2019-10-16 Thread Pavel Tupitsyn (Jira) 


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

Pavel Tupitsyn updated IGNITE-12296:

Summary: .NET: Implement Log Throttle and print warning for unsafe PutAll 
ops  (was: Implement Log Throttle in .Net and print warning for unsafe PutAll 
ops.)

> .NET: Implement Log Throttle and print warning for unsafe PutAll ops
> 
>
> Key: IGNITE-12296
> URL: https://issues.apache.org/jira/browse/IGNITE-12296
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Tupitsyn
>Priority: Major
>
> Right now it's not possible to do one-time developer warnings in .Net as 
> there is no Log Throttle. Please implement one. Please also issue warning if 
> random-order collection is passed to PutAll, InvokeAll, RemoveAll, as it is 
> prime source for deadlocks and developer frustration.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-12296) .NET: Implement Log Throttle and print warning for unsafe PutAll ops

2019-10-16 Thread Pavel Tupitsyn (Jira) 


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

Pavel Tupitsyn updated IGNITE-12296:

Labels: .NET  (was: )

> .NET: Implement Log Throttle and print warning for unsafe PutAll ops
> 
>
> Key: IGNITE-12296
> URL: https://issues.apache.org/jira/browse/IGNITE-12296
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
>
> Right now it's not possible to do one-time developer warnings in .Net as 
> there is no Log Throttle. Please implement one. Please also issue warning if 
> random-order collection is passed to PutAll, InvokeAll, RemoveAll, as it is 
> prime source for deadlocks and developer frustration.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-10226) Partition may restore wrong MOVING state during crash recovery

2019-10-16 Thread Pavel Kovalenko (Jira) 


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

Pavel Kovalenko commented on IGNITE-10226:
--

[~matijap] How did you identify that you faced with the issue? If partition 
restored to MOVED state and if you have backup factor for cache > 0 this 
partition will be automatically rebalanced from the existing owner. If there 
are no backups it can be marked as LOST if you have partitions lost policy != 
IGNORE. In the worst case, if you still have LOST partition you can reset its 
state to OWNING calling:
{noformat}
org.apache.ignite.Ignite#resetLostPartitions
{noformat}


> Partition may restore wrong MOVING state during crash recovery
> --
>
> Key: IGNITE-10226
> URL: https://issues.apache.org/jira/browse/IGNITE-10226
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.4
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.8
>
>
> The way to get it exists only in versions that don't have IGNITE-9420:
> 1) Start cache, upload some data to partitions, forceCheckpoint
> 2) Start uploading additional data. Kill node. Node should be killed with 
> skipping last checkpoint, or during checkpoint mark phase.
> 3) Re-start node. The crash recovery process for partitions started. When we 
> create partition during crash recovery (topology().forceCreatePartition()) we 
> log it's initial state to WAL. If we have any logical update relates to 
> partition we'll log wrong MOVING state to the end of current WAL. This state 
> will be considered as last valid when we process PartitionMetaStateRecord 
> record's during logical recovery. In "restorePartitionsState" phase this 
> state will be chosen as final and the partition will change to MOVING, even 
> in page memory it has OWNING or something else.
> To fix this problem in 2.4 - 2.7 versions, additional logging partition state 
> change to WAL during crash recovery (logical recovery) should be removed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-12296) Implement Log Throttle in .Net and print warning for unsafe PutAll ops.

2019-10-16 Thread Ilya Kasnacheev (Jira) 
Ilya Kasnacheev created IGNITE-12296:


 Summary: Implement Log Throttle in .Net and print warning for 
unsafe PutAll ops.
 Key: IGNITE-12296
 URL: https://issues.apache.org/jira/browse/IGNITE-12296
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Ilya Kasnacheev
Assignee: Pavel Tupitsyn


Right now it's not possible to do one-time developer warnings in .Net as there 
is no Log Throttle. Please implement one. Please also issue warning if 
random-order collection is passed to PutAll, InvokeAll, RemoveAll, as it is 
prime source for deadlocks and developer frustration.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-11898) Java Thin: Implement Best Effort Affinity

2019-10-16 Thread Pavel Tupitsyn (Jira) 


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

Pavel Tupitsyn commented on IGNITE-11898:
-

[~alex_pl] please see one comment on GitHub

> Java Thin: Implement Best Effort Affinity
> -
>
> Key: IGNITE-11898
> URL: https://issues.apache.org/jira/browse/IGNITE-11898
> Project: Ignite
>  Issue Type: New Feature
>  Components: thin client
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: iep-23
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> See linked IEP-23.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-12295) Faster index eviction

2019-10-16 Thread Sergey Kalashnikov (Jira) 
Sergey Kalashnikov created IGNITE-12295:
---

 Summary: Faster index eviction
 Key: IGNITE-12295
 URL: https://issues.apache.org/jira/browse/IGNITE-12295
 Project: Ignite
  Issue Type: Sub-task
Reporter: Sergey Kalashnikov
Assignee: Sergey Kalashnikov


For the file-based rebalancing approach, it seems feasible to avoid iterating 
the old partition data in order to clear the indexes.
One can independently clear the shared index structures of all the rows 
referencing entries from moving partitions by deducing partition id from the 
links in the leaf pages.

The proposed algorithm is simple and takes the set of integer partition ids as 
an input:
1. Iterate over leaf pages of the index and remove items attributed to any of 
indicated partitions, unless it is the only or the rightmost item on a page.
2. If the rightmost item (or the only item) on a page happens to belong to any 
of the indicated partitions, employ a regular remove algorithm (descending from 
the root) so that inner pages get correctly updated.
Restart iteration from the leaf page where the removed item would be inserted 
(descend from the root to find it).

The use of such algorithm can be justified (as having performance advantage) 
when the number of keys that'd be removed is bigger than the number of leaf 
pages in the index.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-10226) Partition may restore wrong MOVING state during crash recovery

2019-10-16 Thread Matija Polajnar (Jira) 


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

Matija Polajnar commented on IGNITE-10226:
--

We're using version 2.7.6 and I believe we've been struck by this issue; is 
there any way for us to recover into normal working state?

> Partition may restore wrong MOVING state during crash recovery
> --
>
> Key: IGNITE-10226
> URL: https://issues.apache.org/jira/browse/IGNITE-10226
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.4
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.8
>
>
> The way to get it exists only in versions that don't have IGNITE-9420:
> 1) Start cache, upload some data to partitions, forceCheckpoint
> 2) Start uploading additional data. Kill node. Node should be killed with 
> skipping last checkpoint, or during checkpoint mark phase.
> 3) Re-start node. The crash recovery process for partitions started. When we 
> create partition during crash recovery (topology().forceCreatePartition()) we 
> log it's initial state to WAL. If we have any logical update relates to 
> partition we'll log wrong MOVING state to the end of current WAL. This state 
> will be considered as last valid when we process PartitionMetaStateRecord 
> record's during logical recovery. In "restorePartitionsState" phase this 
> state will be chosen as final and the partition will change to MOVING, even 
> in page memory it has OWNING or something else.
> To fix this problem in 2.4 - 2.7 versions, additional logging partition state 
> change to WAL during crash recovery (logical recovery) should be removed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-6804) Print a warning if HashMap is passed into bulk update operations

2019-10-16 Thread Ilya Kasnacheev (Jira) 


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

Ilya Kasnacheev commented on IGNITE-6804:
-

[~ptupitsyn]If you have exactly the same number of same keys every time, it 
will work. If you have different sets of keys, deadlock.

> Print a warning if HashMap is passed into bulk update operations
> 
>
> Key: IGNITE-6804
> URL: https://issues.apache.org/jira/browse/IGNITE-6804
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Denis A. Magda
>Assignee: Ilya Kasnacheev
>Priority: Critical
>  Labels: usability
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Ignite newcomers tend to stumble on deadlocks simply because the keys are 
> passed in an unordered HashMap. Propose to do the following:
> * update bulk operations Java docs.
> * print out a warning if not SortedMap (e.g. HashMap, 
> Weak/Identity/Concurrent/Linked HashMap etc) is passed into
> a bulk method (instead of SortedMap) and contains more than 1 element. 
> However, we should make sure that we only print that warning once and not 
> every time the API is called.
> * do not produce warning for explicit optimistic transactions
> More details are here:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-Ignite-2-0-0-GridUnsafe-unmonitor-td23706.html



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (IGNITE-12294) .NET Inspections failure on TC

2019-10-16 Thread Pavel Tupitsyn (Jira) 


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

Pavel Tupitsyn resolved IGNITE-12294.
-
Resolution: Fixed

Merged to master: ce6d66cfe4ff8b6e882784160b99701f3c1b42e3

> .NET Inspections failure on TC
> --
>
> Key: IGNITE-12294
> URL: https://issues.apache.org/jira/browse/IGNITE-12294
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.8
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.8
>
>
> New R# version detected a new problem:
> {code}
> BinaryUtils.cs (1)
> 625:  Actual shift count equals zero. Left operand will remain unchanged
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-12294) .NET Inspections failure on TC

2019-10-16 Thread Pavel Tupitsyn (Jira) 
Pavel Tupitsyn created IGNITE-12294:
---

 Summary: .NET Inspections failure on TC
 Key: IGNITE-12294
 URL: https://issues.apache.org/jira/browse/IGNITE-12294
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 2.8
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.8


New R# version detected a new problem:

{code}
BinaryUtils.cs (1)
625:  Actual shift count equals zero. Left operand will remain unchanged
{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-11898) Java Thin: Implement Best Effort Affinity

2019-10-16 Thread Ignite TC Bot (Jira) 


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

Ignite TC Bot commented on IGNITE-11898:


{panel:title=Branch: [pull/6980/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: Basic Tests* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4700942&buildTypeId=IgniteTests24Java8_RunBasicTests]

> Java Thin: Implement Best Effort Affinity
> -
>
> Key: IGNITE-11898
> URL: https://issues.apache.org/jira/browse/IGNITE-11898
> Project: Ignite
>  Issue Type: New Feature
>  Components: thin client
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: iep-23
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> See linked IEP-23.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12252) Unchecked exceptions during rebalancing should be handled

2019-10-16 Thread Anton Vinogradov (Jira) 


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

Anton Vinogradov commented on IGNITE-12252:
---

[~alex_pl], just a foolproof proposal ;) ++

Ok, let's keep semantic.

 

[~zzzadruga], seems we just have to provide proper catch instead of handlers 
improvements.

> Unchecked exceptions during rebalancing should be handled
> -
>
> Key: IGNITE-12252
> URL: https://issues.apache.org/jira/browse/IGNITE-12252
> Project: Ignite
>  Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Nikolai Kulagin
>Priority: Critical
> Fix For: 2.8
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Rebalancing should handle unchecked exceptions by failure handler. In current 
> implementation unchecked exceptions just ignored. They were handled by IO 
> worker before IGNITE-3195.
> Reproducer:
> {code:java}
> @Test
> public void testRebalanceUncheckedError() throws Exception {
> IgniteEx ignite0 = startGrid(new 
> IgniteConfiguration().setIgniteInstanceName("ignite0"));
> IgniteCache cache = 
> ignite0.getOrCreateCache(DEFAULT_CACHE_NAME);
> IgniteDataStreamer streamer = 
> ignite0.dataStreamer(DEFAULT_CACHE_NAME);
> for (int i = 0; i < 100_000; i++)
> streamer.addData(i, i);
> streamer.flush();
> IgniteEx ignite1 = startGrid(new 
> IgniteConfiguration().setIgniteInstanceName("ignite1")
> 
> .setIncludeEventTypes(EventType.EVT_CACHE_REBALANCE_OBJECT_LOADED));
> ignite1.events().localListen(e -> {
> throw new Error();
> }, EventType.EVT_CACHE_REBALANCE_OBJECT_LOADED);
> awaitPartitionMapExchange();
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (IGNITE-12252) Unchecked exceptions during rebalancing should be handled

2019-10-16 Thread Anton Vinogradov (Jira) 


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

Anton Vinogradov edited comment on IGNITE-12252 at 10/16/19 8:00 AM:
-

[~alex_pl], just a foolproof proposal ;) 

Ok, let's keep semantic.

 

[~zzzadruga], seems we just have to provide proper catch instead of handlers 
improvements.


was (Author: avinogradov):
[~alex_pl], just a foolproof proposal ;) ++

Ok, let's keep semantic.

 

[~zzzadruga], seems we just have to provide proper catch instead of handlers 
improvements.

> Unchecked exceptions during rebalancing should be handled
> -
>
> Key: IGNITE-12252
> URL: https://issues.apache.org/jira/browse/IGNITE-12252
> Project: Ignite
>  Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Nikolai Kulagin
>Priority: Critical
> Fix For: 2.8
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Rebalancing should handle unchecked exceptions by failure handler. In current 
> implementation unchecked exceptions just ignored. They were handled by IO 
> worker before IGNITE-3195.
> Reproducer:
> {code:java}
> @Test
> public void testRebalanceUncheckedError() throws Exception {
> IgniteEx ignite0 = startGrid(new 
> IgniteConfiguration().setIgniteInstanceName("ignite0"));
> IgniteCache cache = 
> ignite0.getOrCreateCache(DEFAULT_CACHE_NAME);
> IgniteDataStreamer streamer = 
> ignite0.dataStreamer(DEFAULT_CACHE_NAME);
> for (int i = 0; i < 100_000; i++)
> streamer.addData(i, i);
> streamer.flush();
> IgniteEx ignite1 = startGrid(new 
> IgniteConfiguration().setIgniteInstanceName("ignite1")
> 
> .setIncludeEventTypes(EventType.EVT_CACHE_REBALANCE_OBJECT_LOADED));
> ignite1.events().localListen(e -> {
> throw new Error();
> }, EventType.EVT_CACHE_REBALANCE_OBJECT_LOADED);
> awaitPartitionMapExchange();
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12259) Create new module for support spring-5.2.X and spring-data-2.2.X

2019-10-16 Thread Ignite TC Bot (Jira) 


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

Ignite TC Bot commented on IGNITE-12259:


{panel:title=Branch: [pull/6978/head] Base: [master] : Possible Blockers 
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=4700852]]
* ZookeeperDiscoverySpiTestSuite1: 
ZookeeperDiscoveryConcurrentStartAndStartStopTest.testStartStop2 - Test has low 
fail rate in base branch 0,0% and is not flaky

{color:#d04437}Platform .NET (Inspections)*{color} [[tests 0 Failure on metric 
|https://ci.ignite.apache.org/viewLog.html?buildId=4700901]]

{panel}
[TeamCity *--> Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4700929&buildTypeId=IgniteTests24Java8_RunAll]

> Create new module for support spring-5.2.X and spring-data-2.2.X
> 
>
> Key: IGNITE-12259
> URL: https://issues.apache.org/jira/browse/IGNITE-12259
> Project: Ignite
>  Issue Type: Wish
>Reporter: Surkov Aleksandr
>Assignee: Surkov Aleksandr
>Priority: Minor
> Fix For: 2.8
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The actual spring version is 
> [5.2.0.RELEASE|https://mvnrepository.com/artifact/org.springframework/spring-context/5.2.0.RELEASE],
>  spring data version is 
> [2.2.0.RELEASE.|https://mvnrepository.com/artifact/org.springframework.data/spring-data-commons/2.2.0.RELEASE]
> It would be nice to add a module to support these versions.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12252) Unchecked exceptions during rebalancing should be handled

2019-10-16 Thread Aleksey Plekhanov (Jira) 


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

Aleksey Plekhanov commented on IGNITE-12252:


[~avinogradov], I do not fully understand your proposal. Why should we extend 
oomeHnd to handle any other errors? Why should we add an assertion? oomeHnd 
should only handle OOME and pass all other errors untouched (some of them can 
be expected, it depends on a worker).

> Unchecked exceptions during rebalancing should be handled
> -
>
> Key: IGNITE-12252
> URL: https://issues.apache.org/jira/browse/IGNITE-12252
> Project: Ignite
>  Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Nikolai Kulagin
>Priority: Critical
> Fix For: 2.8
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Rebalancing should handle unchecked exceptions by failure handler. In current 
> implementation unchecked exceptions just ignored. They were handled by IO 
> worker before IGNITE-3195.
> Reproducer:
> {code:java}
> @Test
> public void testRebalanceUncheckedError() throws Exception {
> IgniteEx ignite0 = startGrid(new 
> IgniteConfiguration().setIgniteInstanceName("ignite0"));
> IgniteCache cache = 
> ignite0.getOrCreateCache(DEFAULT_CACHE_NAME);
> IgniteDataStreamer streamer = 
> ignite0.dataStreamer(DEFAULT_CACHE_NAME);
> for (int i = 0; i < 100_000; i++)
> streamer.addData(i, i);
> streamer.flush();
> IgniteEx ignite1 = startGrid(new 
> IgniteConfiguration().setIgniteInstanceName("ignite1")
> 
> .setIncludeEventTypes(EventType.EVT_CACHE_REBALANCE_OBJECT_LOADED));
> ignite1.events().localListen(e -> {
> throw new Error();
> }, EventType.EVT_CACHE_REBALANCE_OBJECT_LOADED);
> awaitPartitionMapExchange();
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12240) ReadOnlyCollectionView2X fails on iterator.next

2019-10-16 Thread Venkata (Jira) 


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

Venkata commented on IGNITE-12240:
--

[~kcheng.mvp] i am new to ignite, i looked at the issue, and thought following 
can be the fix. let me know if you think the same.
{code:java}
// code placeholder
private Iterator it1 = c1.iterator();
private Iterator it2 = c2.iterator(); 
@Override 
public T next() {
return it1 != null ? it1.next() : it2.next();
}{code}
Here it1 will not be null as c1.iterator() will give a valid reference. So in 
the scenario it is giving that exception. the fix would be to check if the 
iterator hasNext() and then return the element.
{code:java}

public T next()  { 
   if ( null == it1 && null == it2) 
   return null;     
   if ( it1.hasNext()) {  
   return it1.next(); 
   } 
   else if (it2.hasNext()) { 
   return it2.Next(); 
   } 
   else { 
   return null; 
   }  
}
{code}

> ReadOnlyCollectionView2X fails on iterator.next
> ---
>
> Key: IGNITE-12240
> URL: https://issues.apache.org/jira/browse/IGNITE-12240
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.7.6
>Reporter: Nikolay Izhikov
>Assignee: kcheng.mvp
>Priority: Major
>  Labels: newbie
>
> Simple reproducer below will throw {{NoSuchElementException}}.
> Iterator only works if one call {{hasNext}} before {{next}}.
> {code:java}
> /** */
> @Test
> public void testReadOnlyCollection() throws Exception {
> Collection c1 = Collections.emptyList();
> Collection c2 = Arrays.asList("1");
> ReadOnlyCollectionView2X view = new 
> ReadOnlyCollectionView2X<>(c1, c2);
> assertEquals("1", view.iterator().next());
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12252) Unchecked exceptions during rebalancing should be handled

2019-10-16 Thread Anton Vinogradov (Jira) 


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

Anton Vinogradov commented on IGNITE-12252:
---

[~alex_pl], It looks like better case is to handle errors properly on workers' 
level, but also extend oomeHnd to handle any unhandled errors?

Also, we may add an assertion that only OOME is suitable at oomeHnd?

> Unchecked exceptions during rebalancing should be handled
> -
>
> Key: IGNITE-12252
> URL: https://issues.apache.org/jira/browse/IGNITE-12252
> Project: Ignite
>  Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Nikolai Kulagin
>Priority: Critical
> Fix For: 2.8
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Rebalancing should handle unchecked exceptions by failure handler. In current 
> implementation unchecked exceptions just ignored. They were handled by IO 
> worker before IGNITE-3195.
> Reproducer:
> {code:java}
> @Test
> public void testRebalanceUncheckedError() throws Exception {
> IgniteEx ignite0 = startGrid(new 
> IgniteConfiguration().setIgniteInstanceName("ignite0"));
> IgniteCache cache = 
> ignite0.getOrCreateCache(DEFAULT_CACHE_NAME);
> IgniteDataStreamer streamer = 
> ignite0.dataStreamer(DEFAULT_CACHE_NAME);
> for (int i = 0; i < 100_000; i++)
> streamer.addData(i, i);
> streamer.flush();
> IgniteEx ignite1 = startGrid(new 
> IgniteConfiguration().setIgniteInstanceName("ignite1")
> 
> .setIncludeEventTypes(EventType.EVT_CACHE_REBALANCE_OBJECT_LOADED));
> ignite1.events().localListen(e -> {
> throw new Error();
> }, EventType.EVT_CACHE_REBALANCE_OBJECT_LOADED);
> awaitPartitionMapExchange();
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)