[jira] [Updated] (IGNITE-7958) Web Console: Optimize on-focus-out directive.

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-7958:
-
Fix Version/s: 2.5

> Web Console: Optimize on-focus-out directive.
> -
>
> Key: IGNITE-7958
> URL: https://issues.apache.org/jira/browse/IGNITE-7958
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> on-focus-out directive can produce significant GC pressure and make UI 
> unresponsive.
>  



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

[jira] [Updated] (IGNITE-7958) Web Console: Optimize on-focus-out directive.

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-7958:
-
Component/s: wizards

> Web Console: Optimize on-focus-out directive.
> -
>
> Key: IGNITE-7958
> URL: https://issues.apache.org/jira/browse/IGNITE-7958
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> on-focus-out directive can produce significant GC pressure and make UI 
> unresponsive.
>  



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

[jira] [Created] (IGNITE-7958) Web Console: Optimize on-focus-out directive.

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-7958:


 Summary: Web Console: Optimize on-focus-out directive.
 Key: IGNITE-7958
 URL: https://issues.apache.org/jira/browse/IGNITE-7958
 Project: Ignite
  Issue Type: Task
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov


on-focus-out directive can produce significant GC pressure and make UI 
unresponsive.

 



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

[jira] [Commented] (IGNITE-7916) GA Grid examples should be ready for auto run on TeamCity

[Turik Campbell (JIRA)]

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

Turik Campbell commented on IGNITE-7916:


[~dpavlov], Let me know if the respective GA Grid tests located here:

modules\ml\src\test\java\org\apache\ignite\ml\genetic

should also be handled in a similar manner.

Please advise.

 

> GA Grid examples should be ready for auto run on TeamCity
> -
>
> Key: IGNITE-7916
> URL: https://issues.apache.org/jira/browse/IGNITE-7916
> Project: Ignite
>  Issue Type: Bug
>  Components: examples, ml
>Reporter: Yury Babak
>Assignee: Turik Campbell
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
>
> If we start examples MovieGAExample or OptimizeMakeChangeGAExample on TC, 
> this examples will return exit code 1. TeamCity think that it's a error and 
> mark stop whole build of examples package.
> That behavior should be changed. If we don't have required system properties 
> we should not return exit code 1 or maybe set and use some default values.



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

[jira] [Commented] (IGNITE-7916) GA Grid examples should be ready for auto run on TeamCity

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7916:


GitHub user techbysample opened a pull request:

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

IGNITE-7916: GA Grid examples should be ready for auto run on TeamCity

 Removed Ignition.stop(true) to prevent shutdown of examples within build.


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

$ git pull https://github.com/techbysample/ignite ignite-7916

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

https://github.com/apache/ignite/pull/3638.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 #3638


commit 6da25a491721121490a5b868295e5496392fed22
Author: Turik Campbell 
Date:   2018-03-14T23:15:04Z

IGNITE-7916: Removed Ignition.stop(true) to prevent shutdown of examples 
within build.

commit 7d5e74eb97e8a5ebbe9f2a640f9f36aae5adb2be
Author: Turik Campbell 
Date:   2018-03-14T23:19:16Z

IGNITE-7916: Merge branch 'master' into ignite-7916




> GA Grid examples should be ready for auto run on TeamCity
> -
>
> Key: IGNITE-7916
> URL: https://issues.apache.org/jira/browse/IGNITE-7916
> Project: Ignite
>  Issue Type: Bug
>  Components: examples, ml
>Reporter: Yury Babak
>Assignee: Turik Campbell
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
>
> If we start examples MovieGAExample or OptimizeMakeChangeGAExample on TC, 
> this examples will return exit code 1. TeamCity think that it's a error and 
> mark stop whole build of examples package.
> That behavior should be changed. If we don't have required system properties 
> we should not return exit code 1 or maybe set and use some default values.



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

[jira] [Commented] (IGNITE-7727) IgniteRDDSpec. Failing tests

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7727:


Github user asfgit closed the pull request at:

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


> IgniteRDDSpec. Failing tests
> 
>
> Key: IGNITE-7727
> URL: https://issues.apache.org/jira/browse/IGNITE-7727
> Project: Ignite
>  Issue Type: Bug
>  Components: spark
>Affects Versions: 2.4
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Two spark tests are broken.
> Need to fix it.
> 1. IgniteRDDSpec.IgniteRDD should successfully store data to ignite using 
> saveValues  
> 2. IgniteRDDSpec.IgniteRDD should successfully store data to ignite using 
> saveValues with inline transformation



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

[jira] [Commented] (IGNITE-7727) IgniteRDDSpec. Failing tests

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7727:


GitHub user nizhikov opened a pull request:

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

IGNITE-7727: Test unmuted. Fixed by #70ca86a



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

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

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

https://github.com/apache/ignite/pull/3637.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 #3637


commit fbc554ca46056d2e869c989a4ad64b4294106784
Author: Nikolay Izhikov 
Date:   2018-03-14T19:44:07Z

IGNITE-7727: Test unmuted. Fixed by #70ca86a




> IgniteRDDSpec. Failing tests
> 
>
> Key: IGNITE-7727
> URL: https://issues.apache.org/jira/browse/IGNITE-7727
> Project: Ignite
>  Issue Type: Bug
>  Components: spark
>Affects Versions: 2.4
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Two spark tests are broken.
> Need to fix it.
> 1. IgniteRDDSpec.IgniteRDD should successfully store data to ignite using 
> saveValues  
> 2. IgniteRDDSpec.IgniteRDD should successfully store data to ignite using 
> saveValues with inline transformation



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

[jira] [Commented] (IGNITE-7756) Streamer fails if IgniteUuid is indexed

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7756:


Github user asfgit closed the pull request at:

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


> Streamer fails if IgniteUuid is indexed
> ---
>
> Key: IGNITE-7756
> URL: https://issues.apache.org/jira/browse/IGNITE-7756
> Project: Ignite
>  Issue Type: Bug
>  Components: streaming
>Affects Versions: 2.3
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Minor
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> IgniteDataStreamer are failed to put data to the cache if IgniteUuid is 
> IndexedType.
> Spark tests in IGNITE-7227 are failed because of this issue.
> Reproducer:
> {code:java}
> public void testStreamer() throws Exception {
> Ignite client = grid("client");
> CacheConfiguration ccfg = new CacheConfiguration("UUID_CACHE");
> ccfg.setIndexedTypes(IgniteUuid.class, String.class);
> client.createCache(ccfg);
> try(IgniteDataStreamer cache =
> client.dataStreamer("UUID_CACHE")) {
> for(Integer i=0; i<2; i++)
> cache.addData(IgniteUuid.randomUuid(), i.toString());
> }
> }
> {code}
> Exception stack trace:
> {noformat}
> [23:43:35] (err) Failed to execute compound future reducer: 
> GridCompoundFuture [rdc=null, initFlag=1, lsnrCalls=0, done=false, 
> cancelled=false, err=null, futs=[true, true]][23:43:35] (err) Failed to 
> execute compound future reducer: GridCompoundFuture [rdc=null, initFlag=1, 
> lsnrCalls=0, done=false, cancelled=false, err=null, futs=[true, true]]class 
> org.apache.ignite.IgniteCheckedException: DataStreamer request failed 
> [node=57961924-82ec-4d56-81eb-1a4109a0]
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.onResponse(DataStreamerImpl.java:1900)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$3.onMessage(DataStreamerImpl.java:344)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1554)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1182)
>   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:1089)
>   at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:499)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteException: Failed to set initial 
> value for cache entry
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$IsolatedUpdater.receive(DataStreamerImpl.java:2135)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.call(DataStreamerUpdateJob.java:140)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.localUpdate(DataStreamProcessor.java:397)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.processRequest(DataStreamProcessor.java:302)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.access$000(DataStreamProcessor.java:59)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor$1.onMessage(DataStreamProcessor.java:89)
>   ... 6 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update 
> index, incorrect key class [expCls=org.apache.ignite.lang.IgniteUuid, 
> actualCls=org.apache.ignite.internal.binary.BinaryObjectImpl]
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.typeByValue(GridQueryProcessor.java:1954)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1877)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:403)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:1343)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1207)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:345)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:3527)
>   at 
> 

[jira] [Commented] (IGNITE-7692) affinityCall and affinityRun may execute code on backup partitions

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7692:


[~agoncharuk], [~vozerov], it seems we don't need to run not-priority tests at 
all. Why then did we created it?

> affinityCall and affinityRun may execute code on backup partitions
> --
>
> Key: IGNITE-7692
> URL: https://issues.apache.org/jira/browse/IGNITE-7692
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test, usability
> Fix For: 2.5
>
>
> Apparently, the affinityCall and affinityRun methods reserve partitions and 
> check their state to be OWNING, however, if topology changes and partition 
> role is changed to backup from primary, the code is still executed.
> This can be an issue if a user executes a local SQL query inside the 
> affinityCall runnable. In this case, the query result may return null.
> This can be observed in the 
> IgniteCacheLockPartitionOnAffinityRunTest#getPersonsCountSingleCache - note 
> an additional check I've added to make the test pass.
> I think it is ok to have an old semantics for the API, because in some cases 
> (scan query, local gets) a backup OWNER is enough. However, it looks like we 
> need to add another API method to enforce that affinity run be executed on 
> primary nodes and forbid primary role change.
> Another option is to detect a topology version of the affinity run and use 
> that version for local SQL queries.



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

[jira] [Comment Edited] (IGNITE-7834) Ignite Queries 2 fail rate is more than 95%: DynamicColumnsAbstractConcurrentSelfTest and its subclasses are flaky

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov edited comment on IGNITE-7834 at 3/14/18 6:13 PM:
-

[~vozerov], then is it ok to exclude queries 2 from run-all and from monitoring 
process?

whole suite can't pass because of these tests.


was (Author: dpavlov):
[~vozerov], then is it ok to exclude queries 2 from run-all and monitoring than?

whole suite can't pass because of these tests.

> Ignite Queries 2 fail rate is more than 95%: 
> DynamicColumnsAbstractConcurrentSelfTest and its subclasses are flaky
> --
>
> Key: IGNITE-7834
> URL: https://issues.apache.org/jira/browse/IGNITE-7834
> Project: Ignite
>  Issue Type: Test
>  Components: sql
>Reporter: Dmitriy Pavlov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Queries 2 suite has unstable tests DynamicColumns...
> Initially contrubuted by [~al.psc] in [IGNITE-5572]
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgniteQueries2=%3Cdefault%3E=buildTypeStatusDiv
> Last 10 runs statistics:
> {noformat}
> Ignite Queries 2 [ tests 16 ]
>  [2] IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testNodeJoinOnPendingAddOperation
>  (fail rate 5,8%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalReplicatedSelfTest.testAddColumnCoordinatorChange
>  (fail rate 5,8%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalReplicatedSelfTest.testNodeJoinOnPendingAddOperation
>  (fail rate 5,8%) 
>  [2] IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentAtomicPartitionedSelfTest.testDropColumnCoordinatorChange
>  (fail rate 3,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentAtomicPartitionedSelfTest.testNodeJoinOnPendingDropOperation
>  (fail rate 3,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentAtomicReplicatedSelfTest.testNodeJoinOnPendingAddOperation
>  (fail rate 3,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicIndexPartitionedAtomicConcurrentSelfTest.testClientReconnectWithCacheRestart
>  (fail rate 3,6%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testConcurrentOperationsAndNodeStartStopMultithreaded
>  (fail rate 2,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentAtomicReplicatedSelfTest.testDropConcurrentCacheDestroy
>  (fail rate 2,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testAddConcurrentRebalance
>  (fail rate 2,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicIndexReplicatedTransactionalConcurrentSelfTest.testClientReconnectWithCacheRestart
>  (fail rate 2,5%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentAtomicReplicatedSelfTest.testConcurrentPutRemove 
> (fail rate 2,2%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalReplicatedSelfTest.testDropConcurrentRebalance
>  (fail rate 1,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testClientReconnectWithCacheRestart
>  (fail rate 1,8%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testDropConcurrentCacheDestroy
>  (fail rate 1,0%) 
> IgniteBinaryCacheQueryTestSuite2: 
> DynamicIndexReplicatedTransactionalConcurrentSelfTest.testClientReconnect 
> (fail rate 0,4%) 
> {noformat}



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

[jira] [Commented] (IGNITE-7834) Ignite Queries 2 fail rate is more than 95%: DynamicColumnsAbstractConcurrentSelfTest and its subclasses are flaky

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7834:


[~vozerov], then is it ok to exclude queries 2 from run-all and monitoring than?

whole suite can't pass because of these tests.

> Ignite Queries 2 fail rate is more than 95%: 
> DynamicColumnsAbstractConcurrentSelfTest and its subclasses are flaky
> --
>
> Key: IGNITE-7834
> URL: https://issues.apache.org/jira/browse/IGNITE-7834
> Project: Ignite
>  Issue Type: Test
>  Components: sql
>Reporter: Dmitriy Pavlov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Queries 2 suite has unstable tests DynamicColumns...
> Initially contrubuted by [~al.psc] in [IGNITE-5572]
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgniteQueries2=%3Cdefault%3E=buildTypeStatusDiv
> Last 10 runs statistics:
> {noformat}
> Ignite Queries 2 [ tests 16 ]
>  [2] IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testNodeJoinOnPendingAddOperation
>  (fail rate 5,8%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalReplicatedSelfTest.testAddColumnCoordinatorChange
>  (fail rate 5,8%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalReplicatedSelfTest.testNodeJoinOnPendingAddOperation
>  (fail rate 5,8%) 
>  [2] IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentAtomicPartitionedSelfTest.testDropColumnCoordinatorChange
>  (fail rate 3,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentAtomicPartitionedSelfTest.testNodeJoinOnPendingDropOperation
>  (fail rate 3,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentAtomicReplicatedSelfTest.testNodeJoinOnPendingAddOperation
>  (fail rate 3,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicIndexPartitionedAtomicConcurrentSelfTest.testClientReconnectWithCacheRestart
>  (fail rate 3,6%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testConcurrentOperationsAndNodeStartStopMultithreaded
>  (fail rate 2,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentAtomicReplicatedSelfTest.testDropConcurrentCacheDestroy
>  (fail rate 2,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testAddConcurrentRebalance
>  (fail rate 2,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicIndexReplicatedTransactionalConcurrentSelfTest.testClientReconnectWithCacheRestart
>  (fail rate 2,5%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentAtomicReplicatedSelfTest.testConcurrentPutRemove 
> (fail rate 2,2%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalReplicatedSelfTest.testDropConcurrentRebalance
>  (fail rate 1,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testClientReconnectWithCacheRestart
>  (fail rate 1,8%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testDropConcurrentCacheDestroy
>  (fail rate 1,0%) 
> IgniteBinaryCacheQueryTestSuite2: 
> DynamicIndexReplicatedTransactionalConcurrentSelfTest.testClientReconnect 
> (fail rate 0,4%) 
> {noformat}



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

[jira] [Commented] (IGNITE-7912) control.sh script should show used WAL-segments

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7912:


GitHub user ivandasch opened a pull request:

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

IGNITE-7912 First stage of unused WAL segments command. Now print

from all nodes.

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

$ git pull https://github.com/ivandasch/ignite ignite-7912

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

https://github.com/apache/ignite/pull/3636.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 #3636


commit 76817db04de34c85d9fd78a33f1f26657ab91e7b
Author: Ivan Daschinskiy 
Date:   2018-03-14T17:43:34Z

IGNITE-7912 First stage of unused WAL segments command. Now print
from all nodes.




> control.sh script should show used WAL-segments
> ---
>
> Key: IGNITE-7912
> URL: https://issues.apache.org/jira/browse/IGNITE-7912
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Sergey Filatov
>Assignee: Ivan Daschinskiy
>Priority: Minor
>
> We have to erase wal archive because wal archive can grow large and we must 
> have safe way to remove unused segments to free disk space.



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

[jira] [Commented] (IGNITE-7756) Streamer fails if IgniteUuid is indexed

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-7756:
-

[~NIzhikov], [~dpavlov], looks good to me.

> Streamer fails if IgniteUuid is indexed
> ---
>
> Key: IGNITE-7756
> URL: https://issues.apache.org/jira/browse/IGNITE-7756
> Project: Ignite
>  Issue Type: Bug
>  Components: streaming
>Affects Versions: 2.3
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Minor
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> IgniteDataStreamer are failed to put data to the cache if IgniteUuid is 
> IndexedType.
> Spark tests in IGNITE-7227 are failed because of this issue.
> Reproducer:
> {code:java}
> public void testStreamer() throws Exception {
> Ignite client = grid("client");
> CacheConfiguration ccfg = new CacheConfiguration("UUID_CACHE");
> ccfg.setIndexedTypes(IgniteUuid.class, String.class);
> client.createCache(ccfg);
> try(IgniteDataStreamer cache =
> client.dataStreamer("UUID_CACHE")) {
> for(Integer i=0; i<2; i++)
> cache.addData(IgniteUuid.randomUuid(), i.toString());
> }
> }
> {code}
> Exception stack trace:
> {noformat}
> [23:43:35] (err) Failed to execute compound future reducer: 
> GridCompoundFuture [rdc=null, initFlag=1, lsnrCalls=0, done=false, 
> cancelled=false, err=null, futs=[true, true]][23:43:35] (err) Failed to 
> execute compound future reducer: GridCompoundFuture [rdc=null, initFlag=1, 
> lsnrCalls=0, done=false, cancelled=false, err=null, futs=[true, true]]class 
> org.apache.ignite.IgniteCheckedException: DataStreamer request failed 
> [node=57961924-82ec-4d56-81eb-1a4109a0]
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.onResponse(DataStreamerImpl.java:1900)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$3.onMessage(DataStreamerImpl.java:344)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1554)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1182)
>   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:1089)
>   at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:499)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteException: Failed to set initial 
> value for cache entry
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$IsolatedUpdater.receive(DataStreamerImpl.java:2135)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.call(DataStreamerUpdateJob.java:140)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.localUpdate(DataStreamProcessor.java:397)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.processRequest(DataStreamProcessor.java:302)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.access$000(DataStreamProcessor.java:59)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor$1.onMessage(DataStreamProcessor.java:89)
>   ... 6 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update 
> index, incorrect key class [expCls=org.apache.ignite.lang.IgniteUuid, 
> actualCls=org.apache.ignite.internal.binary.BinaryObjectImpl]
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.typeByValue(GridQueryProcessor.java:1954)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1877)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:403)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:1343)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1207)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:345)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:3527)
>   at 
> 

[jira] [Commented] (IGNITE-7834) Ignite Queries 2 fail rate is more than 95%: DynamicColumnsAbstractConcurrentSelfTest and its subclasses are flaky

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-7834:
-

[~dpavlov], we should not remove or mute these tests. While being flaky, they 
still pass in the most cases and test important piece of functionallity.

> Ignite Queries 2 fail rate is more than 95%: 
> DynamicColumnsAbstractConcurrentSelfTest and its subclasses are flaky
> --
>
> Key: IGNITE-7834
> URL: https://issues.apache.org/jira/browse/IGNITE-7834
> Project: Ignite
>  Issue Type: Test
>  Components: sql
>Reporter: Dmitriy Pavlov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Queries 2 suite has unstable tests DynamicColumns...
> Initially contrubuted by [~al.psc] in [IGNITE-5572]
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgniteQueries2=%3Cdefault%3E=buildTypeStatusDiv
> Last 10 runs statistics:
> {noformat}
> Ignite Queries 2 [ tests 16 ]
>  [2] IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testNodeJoinOnPendingAddOperation
>  (fail rate 5,8%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalReplicatedSelfTest.testAddColumnCoordinatorChange
>  (fail rate 5,8%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalReplicatedSelfTest.testNodeJoinOnPendingAddOperation
>  (fail rate 5,8%) 
>  [2] IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentAtomicPartitionedSelfTest.testDropColumnCoordinatorChange
>  (fail rate 3,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentAtomicPartitionedSelfTest.testNodeJoinOnPendingDropOperation
>  (fail rate 3,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentAtomicReplicatedSelfTest.testNodeJoinOnPendingAddOperation
>  (fail rate 3,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicIndexPartitionedAtomicConcurrentSelfTest.testClientReconnectWithCacheRestart
>  (fail rate 3,6%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testConcurrentOperationsAndNodeStartStopMultithreaded
>  (fail rate 2,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentAtomicReplicatedSelfTest.testDropConcurrentCacheDestroy
>  (fail rate 2,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testAddConcurrentRebalance
>  (fail rate 2,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicIndexReplicatedTransactionalConcurrentSelfTest.testClientReconnectWithCacheRestart
>  (fail rate 2,5%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentAtomicReplicatedSelfTest.testConcurrentPutRemove 
> (fail rate 2,2%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalReplicatedSelfTest.testDropConcurrentRebalance
>  (fail rate 1,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testClientReconnectWithCacheRestart
>  (fail rate 1,8%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testDropConcurrentCacheDestroy
>  (fail rate 1,0%) 
> IgniteBinaryCacheQueryTestSuite2: 
> DynamicIndexReplicatedTransactionalConcurrentSelfTest.testClientReconnect 
> (fail rate 0,4%) 
> {noformat}



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

[jira] [Commented] (IGNITE-7692) affinityCall and affinityRun may execute code on backup partitions

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-7692:
-

[~agoncharuk], this issue is not on my radar. No priority from SQL perspective.

> affinityCall and affinityRun may execute code on backup partitions
> --
>
> Key: IGNITE-7692
> URL: https://issues.apache.org/jira/browse/IGNITE-7692
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test, usability
> Fix For: 2.5
>
>
> Apparently, the affinityCall and affinityRun methods reserve partitions and 
> check their state to be OWNING, however, if topology changes and partition 
> role is changed to backup from primary, the code is still executed.
> This can be an issue if a user executes a local SQL query inside the 
> affinityCall runnable. In this case, the query result may return null.
> This can be observed in the 
> IgniteCacheLockPartitionOnAffinityRunTest#getPersonsCountSingleCache - note 
> an additional check I've added to make the test pass.
> I think it is ok to have an old semantics for the API, because in some cases 
> (scan query, local gets) a backup OWNER is enough. However, it looks like we 
> need to add another API method to enforce that affinity run be executed on 
> primary nodes and forbid primary role change.
> Another option is to detect a topology version of the affinity run and use 
> that version for local SQL queries.



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

[jira] [Updated] (IGNITE-7957) TestDistributedJoins fails in CPP Win32 suite

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-7957:
---
Description: 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=417754190398412=%3Cdefault%3E=testDetails

   Ignite Platform CPP Win32 [ tests 1 TC_EXIT_CODE ]  
  IgniteOdbcTest: QueriesTestSuite: TestDistributedJoins (fail rate 9,8%) 

{noformat}
check env != 0 passed
check dbc != 0 passed
check stmt != 0 passed
check rowsNum > 0 passed
check rowsNum < entriesNum passed
check env != 0 passed
check dbc != 0 passed
check stmt != 0 passed
check rowsNum == entriesNum failed [2565 != 1000]
{noformat}

  was:
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=417754190398412=%3Cdefault%3E=testDetails

   Ignite Platform CPP Win32 [ tests 1 TC_EXIT_CODE ]  
  IgniteOdbcTest: QueriesTestSuite: TestDistributedJoins (fail rate 9,8%) 



> TestDistributedJoins fails in CPP Win32 suite
> -
>
> Key: IGNITE-7957
> URL: https://issues.apache.org/jira/browse/IGNITE-7957
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Reporter: Dmitriy Pavlov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=417754190398412=%3Cdefault%3E=testDetails
>Ignite Platform CPP Win32 [ tests 1 TC_EXIT_CODE ]  
>   IgniteOdbcTest: QueriesTestSuite: TestDistributedJoins (fail rate 9,8%) 
> {noformat}
> check env != 0 passed
> check dbc != 0 passed
> check stmt != 0 passed
> check rowsNum > 0 passed
> check rowsNum < entriesNum passed
> check env != 0 passed
> check dbc != 0 passed
> check stmt != 0 passed
> check rowsNum == entriesNum failed [2565 != 1000]
> {noformat}



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

[jira] [Created] (IGNITE-7957) TestDistributedJoins fails in CPP Win32 suite

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-7957:
--

 Summary: TestDistributedJoins fails in CPP Win32 suite
 Key: IGNITE-7957
 URL: https://issues.apache.org/jira/browse/IGNITE-7957
 Project: Ignite
  Issue Type: Task
  Components: platforms
Reporter: Dmitriy Pavlov


https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=417754190398412=%3Cdefault%3E=testDetails

   Ignite Platform CPP Win32 [ tests 1 TC_EXIT_CODE ]  
  IgniteOdbcTest: QueriesTestSuite: TestDistributedJoins (fail rate 9,8%) 




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

[jira] [Created] (IGNITE-7956) MVCC TX: cache eviction operations for key-value API

[Alexander Paschenko (JIRA)]

Alexander Paschenko created IGNITE-7956:
---

 Summary: MVCC TX: cache eviction operations for key-value API
 Key: IGNITE-7956
 URL: https://issues.apache.org/jira/browse/IGNITE-7956
 Project: Ignite
  Issue Type: Task
  Components: cache
Reporter: Alexander Paschenko
 Fix For: 2.5


We need to implement MVCC-compatible cache eviction operations for key-value 
API.



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

[jira] [Created] (IGNITE-7955) MVCC TX: cache peek for key-value API

[Alexander Paschenko (JIRA)]

Alexander Paschenko created IGNITE-7955:
---

 Summary: MVCC TX: cache peek for key-value API
 Key: IGNITE-7955
 URL: https://issues.apache.org/jira/browse/IGNITE-7955
 Project: Ignite
  Issue Type: Task
  Components: cache
Reporter: Alexander Paschenko
 Fix For: 2.5


We need to implement MVCC-compatible cache peek operation for key-value API.



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

[jira] [Commented] (IGNITE-7581) TxPessimisticDeadlockDetectionTest.testDeadlocksLocal hangs on TC

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov commented on IGNITE-7581:
-

[~dpavlov], I'll take a look at this soon.

> TxPessimisticDeadlockDetectionTest.testDeadlocksLocal hangs on TC
> -
>
> Key: IGNITE-7581
> URL: https://issues.apache.org/jira/browse/IGNITE-7581
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> The test hangs because the ConcurrentModificationException happens:
> {code}
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:502)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject.onTimeout(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:163)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.lang.Thread.run(Thread.java:745)
> [10:33:20]W:   [org.apache.ignite:ignite-core] 
> java.util.ConcurrentModificationException
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.util.ArrayList$Itr.next(ArrayList.java:851)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture.undoLocks(GridLocalLockFuture.java:297)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture.onComplete(GridLocalLockFuture.java:437)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture.access$700(GridLocalLockFuture.java:57)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:510)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject.onTimeout(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:163)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.lang.Thread.run(Thread.java:745)
> [10:33:20]W:   [org.apache.ignite:ignite-core] [2018-01-31 
> 07:33:20,502][ERROR][grid-timeout-worker-#1556%transactions.TxPessimisticDeadlockDetectionTest0%][GridTimeoutProcessor]
>  Error when executing timeout callback: LockTimeoutObject []
> [10:33:20]W:   [org.apache.ignite:ignite-core] 
> java.util.ConcurrentModificationException
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> [10:33:20]W:   

[jira] [Commented] (IGNITE-7890) Node start with corrupted pds hangs indefinitely.

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny commented on IGNITE-7890:


And about case of such problem shoot in already running node?
I observe situation while node is starting ok, no "Failed to get page IO 
instance " errors and after 1 hour of work i`w got:

{code:java}
Caused by: java.lang.IllegalStateException: Failed to get page IO instance 
(page content is corrupted)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.IOVersions.forVersion(IOVersions.java:83)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.IOVersions.forPage(IOVersions.java:95)
at 
org.apache.ignite.internal.processors.cache.tree.CacheDataTree.compareKeys(CacheDataTree.java:167)
{code}


> Node start with corrupted pds hangs indefinitely.
> -
>
> Key: IGNITE-7890
> URL: https://issues.apache.org/jira/browse/IGNITE-7890
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
>
> Starting node with corrupted PDS + WAL leads to cluster-wide hang-up.



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

[jira] [Commented] (IGNITE-7898) IgniteCachePartitionLossPolicySelfTest is flaky on TC

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7898:


Github user asfgit closed the pull request at:

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


> IgniteCachePartitionLossPolicySelfTest is flaky on TC
> -
>
> Key: IGNITE-7898
> URL: https://issues.apache.org/jira/browse/IGNITE-7898
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.4
>Reporter: Pavel Kovalenko
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Affected tests:
> testReadOnlyAll
> testReadWriteSafe
> Exception:
> {code:java}
> junit.framework.AssertionFailedError: Failed to find expected lost partition 
> [exp=0, lost=[]]
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteCachePartitionLossPolicySelfTest.verifyCacheOps(IgniteCachePartitionLossPolicySelfTest.java:219)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteCachePartitionLossPolicySelfTest.checkLostPartition(IgniteCachePartitionLossPolicySelfTest.java:166)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteCachePartitionLossPolicySelfTest.testReadWriteSafe(IgniteCachePartitionLossPolicySelfTest.java:114)
> {code}
> The problem of failure:
> After we prepare topology and shutdown the node containing lost partition we 
> start to check it immediately on all nodes (cache.lostPartitions() method). 
> Sometimes we invoke this method on client node where last PME is not even 
> started and getting empty list of lost partitions because we haven't received 
> it yet on PME.
> Possible solution:
> Wait for PME finishing on all nodes (including client) before start to check 
> for lost partitions.



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

[jira] [Commented] (IGNITE-7947) Not all OWNING partitions saved in PartitionAllocationMap during checkpoint

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7947:


Github user asfgit closed the pull request at:

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


> Not all OWNING partitions saved in PartitionAllocationMap during checkpoint
> ---
>
> Key: IGNITE-7947
> URL: https://issues.apache.org/jira/browse/IGNITE-7947
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.5
>
>
> In checkpoint begin listeners we collect PartitionAllocationMap in offheap 
> managers. 
> But if rowStore is null than we ignore this partition in any case even if we 
> own it.



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

[jira] [Commented] (IGNITE-7879) SQL query with group by and distinct in subquery produces JdbcSQLException

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-7879:
--

[~vozerov], please review the changes ([~sergi.vladykin] has approved the fix).


> SQL query with group by and distinct in subquery produces JdbcSQLException
> --
>
> Key: IGNITE-7879
> URL: https://issues.apache.org/jira/browse/IGNITE-7879
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1, 2.3
>Reporter: Pavel Vinokurov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.5
>
>
> SQL initial script:
> CREATE TABLE Person(id INTEGER PRIMARY KEY, company_id INTEGER);
> CREATE TABLE Company(id INTEGER PRIMARY KEY, name VARCHAR);
> INSERT INTO Person(id,company_id) VALUES (1, 1), (2, 2), (3, 3);
> INSERT INTO Company(id,name) VALUES (1,'n1'), (2,'n2'), (3,'n3');
> SQL query:
> SELECT p.id,sum(p.id) FROM person p
> LEFT JOIN (select DISTINCT id from company) as c on c.id=p.company_id
> group by p.id
> Result:
> Caused by: org.h2.jdbc.JdbcSQLException: Column "P__Z0.ID" must be in the 
> GROUP BY list; SQL statement:
> SELECT
> P__Z0.ID __C0_0,
> P__Z0.COMPANY_ID __C0_1,
> SUM(P__Z0.ID) __C0_2
> FROM PUBLIC.PERSON P__Z0 [90016-195]
>  
>  



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

[jira] [Updated] (IGNITE-7879) SQL query with group by and distinct in subquery produces JdbcSQLException

[Taras Ledkov (JIRA)]

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

Taras Ledkov updated IGNITE-7879:
-
Fix Version/s: 2.5

> SQL query with group by and distinct in subquery produces JdbcSQLException
> --
>
> Key: IGNITE-7879
> URL: https://issues.apache.org/jira/browse/IGNITE-7879
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1, 2.3
>Reporter: Pavel Vinokurov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.5
>
>
> SQL initial script:
> CREATE TABLE Person(id INTEGER PRIMARY KEY, company_id INTEGER);
> CREATE TABLE Company(id INTEGER PRIMARY KEY, name VARCHAR);
> INSERT INTO Person(id,company_id) VALUES (1, 1), (2, 2), (3, 3);
> INSERT INTO Company(id,name) VALUES (1,'n1'), (2,'n2'), (3,'n3');
> SQL query:
> SELECT p.id,sum(p.id) FROM person p
> LEFT JOIN (select DISTINCT id from company) as c on c.id=p.company_id
> group by p.id
> Result:
> Caused by: org.h2.jdbc.JdbcSQLException: Column "P__Z0.ID" must be in the 
> GROUP BY list; SQL statement:
> SELECT
> P__Z0.ID __C0_0,
> P__Z0.COMPANY_ID __C0_1,
> SUM(P__Z0.ID) __C0_2
> FROM PUBLIC.PERSON P__Z0 [90016-195]
>  
>  



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

[jira] [Commented] (IGNITE-7879) SQL query with group by and distinct in subquery produces JdbcSQLException

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-7879:
--

*Root cause*: push down expression, that contains aggregate function.

> SQL query with group by and distinct in subquery produces JdbcSQLException
> --
>
> Key: IGNITE-7879
> URL: https://issues.apache.org/jira/browse/IGNITE-7879
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1, 2.3
>Reporter: Pavel Vinokurov
>Assignee: Taras Ledkov
>Priority: Major
>
> SQL initial script:
> CREATE TABLE Person(id INTEGER PRIMARY KEY, company_id INTEGER);
> CREATE TABLE Company(id INTEGER PRIMARY KEY, name VARCHAR);
> INSERT INTO Person(id,company_id) VALUES (1, 1), (2, 2), (3, 3);
> INSERT INTO Company(id,name) VALUES (1,'n1'), (2,'n2'), (3,'n3');
> SQL query:
> SELECT p.id,sum(p.id) FROM person p
> LEFT JOIN (select DISTINCT id from company) as c on c.id=p.company_id
> group by p.id
> Result:
> Caused by: org.h2.jdbc.JdbcSQLException: Column "P__Z0.ID" must be in the 
> GROUP BY list; SQL statement:
> SELECT
> P__Z0.ID __C0_0,
> P__Z0.COMPANY_ID __C0_1,
> SUM(P__Z0.ID) __C0_2
> FROM PUBLIC.PERSON P__Z0 [90016-195]
>  
>  



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

[jira] [Assigned] (IGNITE-7822) SQL Query with union and left join produces "Column not found" error

[Taras Ledkov (JIRA)]

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

Taras Ledkov reassigned IGNITE-7822:


Assignee: Taras Ledkov

> SQL Query with union and left join produces "Column not found" error
> 
>
> Key: IGNITE-7822
> URL: https://issues.apache.org/jira/browse/IGNITE-7822
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1, 2.3
>Reporter: Pavel Vinokurov
>Assignee: Taras Ledkov
>Priority: Major
>
>  
>  
> Initial script:
>  
> CREATE TABLE Person (id INTEGER PRIMARY KEY, company_id INTEGER, salary 
> DECIMAL);
> CREATE TABLE Company (id INTEGER PRIMARY KEY, name VARCHAR);
> CREATE TABLE Company_Value (id INTEGER PRIMARY KEY, company_id INTEGER, 
> market_value DECIMAL);
> INSERT INTO Person (id, company_id, salary) VALUES (1, 1, 100), (2, 2, 200), 
> (3, 3, 300);
> INSERT INTO Company (id, name) VALUES (1, 'n1'), (2, 'n2'), (3, 'n3');
> INSERT INTO Company_Value (id, company_id, market_value) VALUES (1, 1, 
> 1), (2, 2, 2), (3, 3, 3); CREATE TABLE Address (id INTEGER 
> PRIMARY KEY, person_id INTEGER, city VARCHAR);INSERT INTO Person (id, 
> company_id, salary) VALUES (1, 1, 100), (2, 2, 200), (3, 3, 300);INSERT INTO 
> Address (id, person_id, city) VALUES (1, 1, 'san francisco'), (2, 2, 
> 'paris'), (3, 3, 'new york');INSERT INTO Company (id, name) VALUES (1, 'n1'), 
> (2, 'n2'), (3, 'n3');INSERT INTO Company_Value (id, company_id, market_value) 
> VALUES (1, 1, 1), (2, 2, 2), (3, 3, 3);
>  
> Query:
> SELECT a.idFROM  (SELECT     p1.id as pid,     p1.salary,     p1.company_id   
> FROM Person p1   WHERE p1.id = 1   UNION   SELECT     p2.id as pid,     
> p2.salary,     p2.company_id   FROM Person p2   WHERE p2.id = 2)  p  LEFT 
> JOIN Company c ON p.company_id = c.id  LEFT JOIN Company_Value cv ON c.id = 
> cv.company_id  LEFT JOIN Address a ON a.person_id = p.pid;
>  
> Result:
> Exception:Caused by: org.h2.jdbc.JdbcSQLException: Column "P__Z2.ID" not 
> found; SQL statement:SELECTC__Z3.ID __C2_0FROM PUBLIC.COMPANY C__Z3  LEFT 
> OUTER JOIN PUBLIC.COMPANY_VALUE CV__Z4  ON C__Z3.ID = CV__Z4.COMPANY_ID  LEFT 
> OUTER JOIN PUBLIC.ADDRESS A__Z5  ON A__Z5.PERSON_ID = P__Z2.IDORDER BY 1 
> [42122-195]
>  



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

[jira] [Resolved] (IGNITE-7785) SQL query with COUNT and UNION in sub-query produces JdbcSQLException

[Taras Ledkov (JIRA)]

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

Taras Ledkov resolved IGNITE-7785.
--
Resolution: Duplicate

> SQL query with COUNT and UNION in sub-query produces JdbcSQLException
> -
>
> Key: IGNITE-7785
> URL: https://issues.apache.org/jira/browse/IGNITE-7785
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1, 2.3
>Reporter: Pavel Vinokurov
>Priority: Major
>
> SQL initial script:
> CREATE TABLE Person(id INTEGER PRIMARY KEY, company_id INTEGER);
>  CREATE TABLE Company(id INTEGER PRIMARY KEY, name VARCHAR);
>  INSERT INTO Person(id,company_id) VALUES (1, 1), (2, 2), (3, 3);
>  INSERT INTO Company(id,name) VALUES (1,'n1'), (2,'n2'), (3,'n3');
> SQL Query:
> SELECT count(1) FROM person p
>  LEFT JOIN (select id from company union select id from company) as c on 
> c.id=p.company_id
> JDBC Exception:
> Caused by: org.h2.jdbc.JdbcSQLException: Column "P__Z0.COMPANY_ID" must be in 
> the GROUP BY list; SQL statement:
> SELECT
> P__Z0.COMPANY_ID __C0_0,
> COUNT(1) __C0_1
> FROM PUBLIC.PERSON P__Z0 [90016-195]
>  



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

[jira] [Commented] (IGNITE-7947) Not all OWNING partitions saved in PartitionAllocationMap during checkpoint

[Dmitriy Govorukhin (JIRA)]

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

Dmitriy Govorukhin commented on IGNITE-7947:


[~EdShangGG] Looks good for me, thanks! [~agoncharuk] Could you please merge 
this changes to master?

> Not all OWNING partitions saved in PartitionAllocationMap during checkpoint
> ---
>
> Key: IGNITE-7947
> URL: https://issues.apache.org/jira/browse/IGNITE-7947
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.5
>
>
> In checkpoint begin listeners we collect PartitionAllocationMap in offheap 
> managers. 
> But if rowStore is null than we ignore this partition in any case even if we 
> own it.



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

[jira] [Commented] (IGNITE-7879) SQL query with group by and distinct in subquery produces JdbcSQLException

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7879:


GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-7879: Don't push down expressions with aggregate function



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

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

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

https://github.com/apache/ignite/pull/3634.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 #3634


commit 7b5a3423886fe0de68362fce679d7bc32f0c78f6
Author: tledkov-gridgain 
Date:   2018-03-07T13:35:21Z

IGNITE-7879: Don't push down expressions with aggregate function




> SQL query with group by and distinct in subquery produces JdbcSQLException
> --
>
> Key: IGNITE-7879
> URL: https://issues.apache.org/jira/browse/IGNITE-7879
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1, 2.3
>Reporter: Pavel Vinokurov
>Assignee: Taras Ledkov
>Priority: Major
>
> SQL initial script:
> CREATE TABLE Person(id INTEGER PRIMARY KEY, company_id INTEGER);
> CREATE TABLE Company(id INTEGER PRIMARY KEY, name VARCHAR);
> INSERT INTO Person(id,company_id) VALUES (1, 1), (2, 2), (3, 3);
> INSERT INTO Company(id,name) VALUES (1,'n1'), (2,'n2'), (3,'n3');
> SQL query:
> SELECT p.id,sum(p.id) FROM person p
> LEFT JOIN (select DISTINCT id from company) as c on c.id=p.company_id
> group by p.id
> Result:
> Caused by: org.h2.jdbc.JdbcSQLException: Column "P__Z0.ID" must be in the 
> GROUP BY list; SQL statement:
> SELECT
> P__Z0.ID __C0_0,
> P__Z0.COMPANY_ID __C0_1,
> SUM(P__Z0.ID) __C0_2
> FROM PUBLIC.PERSON P__Z0 [90016-195]
>  
>  



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

[jira] [Commented] (IGNITE-7916) GA Grid examples should be ready for auto run on TeamCity

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7916:


[~chief], [~netmille], is there any progress on fixing the Ignite Examples test?

it is still failing, 
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgniteExamples_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv

Unfortunately I can't mute just 1 failed test because this issue fails whole 
suite.

> GA Grid examples should be ready for auto run on TeamCity
> -
>
> Key: IGNITE-7916
> URL: https://issues.apache.org/jira/browse/IGNITE-7916
> Project: Ignite
>  Issue Type: Bug
>  Components: examples, ml
>Reporter: Yury Babak
>Assignee: Turik Campbell
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
>
> If we start examples MovieGAExample or OptimizeMakeChangeGAExample on TC, 
> this examples will return exit code 1. TeamCity think that it's a error and 
> mark stop whole build of examples package.
> That behavior should be changed. If we don't have required system properties 
> we should not return exit code 1 or maybe set and use some default values.



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

[jira] [Commented] (IGNITE-7916) GA Grid examples should be ready for auto run on TeamCity

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7916:


Hi [~netmille], probably it will be matched by TC. It may be checked on changes 
tab for next commits. If TC will report changes came from unknown user, than it 
will be required to click 'Its Me' or setup username manually in 
https://ci.ignite.apache.org/profile.html?item=vcsUsernames

> GA Grid examples should be ready for auto run on TeamCity
> -
>
> Key: IGNITE-7916
> URL: https://issues.apache.org/jira/browse/IGNITE-7916
> Project: Ignite
>  Issue Type: Bug
>  Components: examples, ml
>Reporter: Yury Babak
>Assignee: Turik Campbell
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
>
> If we start examples MovieGAExample or OptimizeMakeChangeGAExample on TC, 
> this examples will return exit code 1. TeamCity think that it's a error and 
> mark stop whole build of examples package.
> That behavior should be changed. If we don't have required system properties 
> we should not return exit code 1 or maybe set and use some default values.



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

[jira] [Created] (IGNITE-7954) MVCC TX: cache load routines for key-value API

[Alexander Paschenko (JIRA)]

Alexander Paschenko created IGNITE-7954:
---

 Summary: MVCC TX: cache load routines for key-value API
 Key: IGNITE-7954
 URL: https://issues.apache.org/jira/browse/IGNITE-7954
 Project: Ignite
  Issue Type: Task
  Components: cache
Reporter: Alexander Paschenko
 Fix For: 2.5


We need to implement MVCC-compatible cache load operations for key-value API.



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

[jira] [Created] (IGNITE-7953) MVCC TX: continuous queries

[Alexander Paschenko (JIRA)]

Alexander Paschenko created IGNITE-7953:
---

 Summary: MVCC TX: continuous queries
 Key: IGNITE-7953
 URL: https://issues.apache.org/jira/browse/IGNITE-7953
 Project: Ignite
  Issue Type: Task
  Components: cache
Reporter: Alexander Paschenko
 Fix For: 2.5


We need to implement MVCC-compatible continuous queries.



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

[jira] [Updated] (IGNITE-7952) MVCC TX: cache clear routines for key-value API

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko updated IGNITE-7952:

Description: We need to implement MVCC-compatible cache clear operations 
for Key-Value API.

> MVCC TX: cache clear routines for key-value API
> ---
>
> Key: IGNITE-7952
> URL: https://issues.apache.org/jira/browse/IGNITE-7952
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Alexander Paschenko
>Priority: Major
> Fix For: 2.5
>
>
> We need to implement MVCC-compatible cache clear operations for Key-Value API.



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

[jira] [Comment Edited] (IGNITE-7581) TxPessimisticDeadlockDetectionTest.testDeadlocksLocal hangs on TC

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov edited comment on IGNITE-7581 at 3/14/18 12:46 PM:
--

[~sergey-chugunov], could I ask you to take a look to this issue?


was (Author: dpavlov):
[~sergey-chugunov], could I ask to to take a look to this issue?

> TxPessimisticDeadlockDetectionTest.testDeadlocksLocal hangs on TC
> -
>
> Key: IGNITE-7581
> URL: https://issues.apache.org/jira/browse/IGNITE-7581
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> The test hangs because the ConcurrentModificationException happens:
> {code}
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:502)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject.onTimeout(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:163)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.lang.Thread.run(Thread.java:745)
> [10:33:20]W:   [org.apache.ignite:ignite-core] 
> java.util.ConcurrentModificationException
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.util.ArrayList$Itr.next(ArrayList.java:851)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture.undoLocks(GridLocalLockFuture.java:297)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture.onComplete(GridLocalLockFuture.java:437)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture.access$700(GridLocalLockFuture.java:57)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:510)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject.onTimeout(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:163)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.lang.Thread.run(Thread.java:745)
> [10:33:20]W:   [org.apache.ignite:ignite-core] [2018-01-31 
> 07:33:20,502][ERROR][grid-timeout-worker-#1556%transactions.TxPessimisticDeadlockDetectionTest0%][GridTimeoutProcessor]
>  Error when executing timeout callback: LockTimeoutObject []
> [10:33:20]W:   [org.apache.ignite:ignite-core] 
> java.util.ConcurrentModificationException
> 

[jira] [Commented] (IGNITE-7581) TxPessimisticDeadlockDetectionTest.testDeadlocksLocal hangs on TC

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7581:


[~sergey-chugunov], could I ask to to take a look to this issue?

> TxPessimisticDeadlockDetectionTest.testDeadlocksLocal hangs on TC
> -
>
> Key: IGNITE-7581
> URL: https://issues.apache.org/jira/browse/IGNITE-7581
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> The test hangs because the ConcurrentModificationException happens:
> {code}
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:502)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject.onTimeout(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:163)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.lang.Thread.run(Thread.java:745)
> [10:33:20]W:   [org.apache.ignite:ignite-core] 
> java.util.ConcurrentModificationException
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.util.ArrayList$Itr.next(ArrayList.java:851)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture.undoLocks(GridLocalLockFuture.java:297)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture.onComplete(GridLocalLockFuture.java:437)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture.access$700(GridLocalLockFuture.java:57)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:510)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject.onTimeout(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:163)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.lang.Thread.run(Thread.java:745)
> [10:33:20]W:   [org.apache.ignite:ignite-core] [2018-01-31 
> 07:33:20,502][ERROR][grid-timeout-worker-#1556%transactions.TxPessimisticDeadlockDetectionTest0%][GridTimeoutProcessor]
>  Error when executing timeout callback: LockTimeoutObject []
> [10:33:20]W:   [org.apache.ignite:ignite-core] 
> java.util.ConcurrentModificationException
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> [10:33:20]W:   

[jira] [Created] (IGNITE-7952) MVCC TX: cache clear routines for key-value API

[Alexander Paschenko (JIRA)]

Alexander Paschenko created IGNITE-7952:
---

 Summary: MVCC TX: cache clear routines for key-value API
 Key: IGNITE-7952
 URL: https://issues.apache.org/jira/browse/IGNITE-7952
 Project: Ignite
  Issue Type: Task
  Components: cache
Reporter: Alexander Paschenko
 Fix For: 2.5






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

[jira] [Created] (IGNITE-7951) Add metrics for remains to evict keys/partitions

[Alexander Belyak (JIRA)]

Alexander Belyak created IGNITE-7951:


 Summary: Add metrics for remains to evict keys/partitions
 Key: IGNITE-7951
 URL: https://issues.apache.org/jira/browse/IGNITE-7951
 Project: Ignite
  Issue Type: New Feature
  Components: general
Affects Versions: 2.4
Reporter: Alexander Belyak


Need to add some metrics for remains to evict keys/partitions to indicate total 
amount of evicting work. In some cases we have synchronous eviction and it's 
critically important to know how many keys need to be evicted before exchange 
process end and cluster became working again. In some other cases we just wanna 
know what happens in cluster now (background eviction without workload) and 
when cluster will became 100% healthy. 



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

[jira] [Commented] (IGNITE-7692) affinityCall and affinityRun may execute code on backup partitions

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-7692:
--

[~vozerov] Should we fix this in 2.5?

> affinityCall and affinityRun may execute code on backup partitions
> --
>
> Key: IGNITE-7692
> URL: https://issues.apache.org/jira/browse/IGNITE-7692
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test, usability
> Fix For: 2.5
>
>
> Apparently, the affinityCall and affinityRun methods reserve partitions and 
> check their state to be OWNING, however, if topology changes and partition 
> role is changed to backup from primary, the code is still executed.
> This can be an issue if a user executes a local SQL query inside the 
> affinityCall runnable. In this case, the query result may return null.
> This can be observed in the 
> IgniteCacheLockPartitionOnAffinityRunTest#getPersonsCountSingleCache - note 
> an additional check I've added to make the test pass.
> I think it is ok to have an old semantics for the API, because in some cases 
> (scan query, local gets) a backup OWNER is enough. However, it looks like we 
> need to add another API method to enforce that affinity run be executed on 
> primary nodes and forbid primary role change.
> Another option is to detect a topology version of the affinity run and use 
> that version for local SQL queries.



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

[jira] [Commented] (IGNITE-7581) TxPessimisticDeadlockDetectionTest.testDeadlocksLocal hangs on TC

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-7581:
--

>From the stacktrace the cause is a ConcurrentModificationException, it should 
>be relatively easy to fix, so I cannot say it requires a specific knowledge.

> TxPessimisticDeadlockDetectionTest.testDeadlocksLocal hangs on TC
> -
>
> Key: IGNITE-7581
> URL: https://issues.apache.org/jira/browse/IGNITE-7581
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> The test hangs because the ConcurrentModificationException happens:
> {code}
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:502)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject.onTimeout(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:163)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.lang.Thread.run(Thread.java:745)
> [10:33:20]W:   [org.apache.ignite:ignite-core] 
> java.util.ConcurrentModificationException
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.util.ArrayList$Itr.next(ArrayList.java:851)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture.undoLocks(GridLocalLockFuture.java:297)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture.onComplete(GridLocalLockFuture.java:437)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture.access$700(GridLocalLockFuture.java:57)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:510)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject.onTimeout(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:163)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.lang.Thread.run(Thread.java:745)
> [10:33:20]W:   [org.apache.ignite:ignite-core] [2018-01-31 
> 07:33:20,502][ERROR][grid-timeout-worker-#1556%transactions.TxPessimisticDeadlockDetectionTest0%][GridTimeoutProcessor]
>  Error when executing timeout callback: LockTimeoutObject []
> [10:33:20]W:   [org.apache.ignite:ignite-core] 
> java.util.ConcurrentModificationException
> [10:33:20]W:   [org.apache.ignite:ignite-core] 

[jira] [Commented] (IGNITE-7727) IgniteRDDSpec. Failing tests

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-7727:
-

Hello, [~dpavlov]. 

Yes, this issue depends on IGNITE-7756.
Tests will become green when we merge IGNITE-7756

> IgniteRDDSpec. Failing tests
> 
>
> Key: IGNITE-7727
> URL: https://issues.apache.org/jira/browse/IGNITE-7727
> Project: Ignite
>  Issue Type: Bug
>  Components: spark
>Affects Versions: 2.4
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Two spark tests are broken.
> Need to fix it.
> 1. IgniteRDDSpec.IgniteRDD should successfully store data to ignite using 
> saveValues  
> 2. IgniteRDDSpec.IgniteRDD should successfully store data to ignite using 
> saveValues with inline transformation



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

[jira] [Commented] (IGNITE-7692) affinityCall and affinityRun may execute code on backup partitions

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7692:


Who can help with this issue? Is it a priority?

> affinityCall and affinityRun may execute code on backup partitions
> --
>
> Key: IGNITE-7692
> URL: https://issues.apache.org/jira/browse/IGNITE-7692
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test, usability
> Fix For: 2.5
>
>
> Apparently, the affinityCall and affinityRun methods reserve partitions and 
> check their state to be OWNING, however, if topology changes and partition 
> role is changed to backup from primary, the code is still executed.
> This can be an issue if a user executes a local SQL query inside the 
> affinityCall runnable. In this case, the query result may return null.
> This can be observed in the 
> IgniteCacheLockPartitionOnAffinityRunTest#getPersonsCountSingleCache - note 
> an additional check I've added to make the test pass.
> I think it is ok to have an old semantics for the API, because in some cases 
> (scan query, local gets) a backup OWNER is enough. However, it looks like we 
> need to add another API method to enforce that affinity run be executed on 
> primary nodes and forbid primary role change.
> Another option is to detect a topology version of the affinity run and use 
> that version for local SQL queries.



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

[jira] [Assigned] (IGNITE-6600) Web Console: Make a design of 403 and 404 pages

[Vica Abramova (JIRA)]

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

Vica Abramova reassigned IGNITE-6600:
-

Assignee: Ilya Borisov  (was: Vica Abramova)

> Web Console: Make a design of 403 and 404 pages
> ---
>
> Key: IGNITE-6600
> URL: https://issues.apache.org/jira/browse/IGNITE-6600
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Reporter: Vica Abramova
>Assignee: Ilya Borisov
>Priority: Minor
> Fix For: 2.5
>
> Attachments: 403-page.png, 404-page.png
>
>




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

[jira] [Commented] (IGNITE-7727) IgniteRDDSpec. Failing tests

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7727:


Is it still blocked by IGNITE-7756 - Streamer fails if IgniteUuid is indexed?

> IgniteRDDSpec. Failing tests
> 
>
> Key: IGNITE-7727
> URL: https://issues.apache.org/jira/browse/IGNITE-7727
> Project: Ignite
>  Issue Type: Bug
>  Components: spark
>Affects Versions: 2.4
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Two spark tests are broken.
> Need to fix it.
> 1. IgniteRDDSpec.IgniteRDD should successfully store data to ignite using 
> saveValues  
> 2. IgniteRDDSpec.IgniteRDD should successfully store data to ignite using 
> saveValues with inline transformation



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

[jira] [Updated] (IGNITE-6600) Web Console: Make a design of 403 and 404 pages

[Vica Abramova (JIRA)]

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

Vica Abramova updated IGNITE-6600:
--
Attachment: 404-page.png
403-page.png

> Web Console: Make a design of 403 and 404 pages
> ---
>
> Key: IGNITE-6600
> URL: https://issues.apache.org/jira/browse/IGNITE-6600
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Reporter: Vica Abramova
>Assignee: Vica Abramova
>Priority: Minor
> Fix For: 2.5
>
> Attachments: 403-page.png, 404-page.png
>
>




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

[jira] [Commented] (IGNITE-7756) Streamer fails if IgniteUuid is indexed

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7756:


Hi [~vozerov], we would like to hear your expert opinion here.

> Streamer fails if IgniteUuid is indexed
> ---
>
> Key: IGNITE-7756
> URL: https://issues.apache.org/jira/browse/IGNITE-7756
> Project: Ignite
>  Issue Type: Bug
>  Components: streaming
>Affects Versions: 2.3
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Minor
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> IgniteDataStreamer are failed to put data to the cache if IgniteUuid is 
> IndexedType.
> Spark tests in IGNITE-7227 are failed because of this issue.
> Reproducer:
> {code:java}
> public void testStreamer() throws Exception {
> Ignite client = grid("client");
> CacheConfiguration ccfg = new CacheConfiguration("UUID_CACHE");
> ccfg.setIndexedTypes(IgniteUuid.class, String.class);
> client.createCache(ccfg);
> try(IgniteDataStreamer cache =
> client.dataStreamer("UUID_CACHE")) {
> for(Integer i=0; i<2; i++)
> cache.addData(IgniteUuid.randomUuid(), i.toString());
> }
> }
> {code}
> Exception stack trace:
> {noformat}
> [23:43:35] (err) Failed to execute compound future reducer: 
> GridCompoundFuture [rdc=null, initFlag=1, lsnrCalls=0, done=false, 
> cancelled=false, err=null, futs=[true, true]][23:43:35] (err) Failed to 
> execute compound future reducer: GridCompoundFuture [rdc=null, initFlag=1, 
> lsnrCalls=0, done=false, cancelled=false, err=null, futs=[true, true]]class 
> org.apache.ignite.IgniteCheckedException: DataStreamer request failed 
> [node=57961924-82ec-4d56-81eb-1a4109a0]
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.onResponse(DataStreamerImpl.java:1900)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$3.onMessage(DataStreamerImpl.java:344)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1554)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1182)
>   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:1089)
>   at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:499)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteException: Failed to set initial 
> value for cache entry
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$IsolatedUpdater.receive(DataStreamerImpl.java:2135)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.call(DataStreamerUpdateJob.java:140)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.localUpdate(DataStreamProcessor.java:397)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.processRequest(DataStreamProcessor.java:302)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.access$000(DataStreamProcessor.java:59)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor$1.onMessage(DataStreamProcessor.java:89)
>   ... 6 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update 
> index, incorrect key class [expCls=org.apache.ignite.lang.IgniteUuid, 
> actualCls=org.apache.ignite.internal.binary.BinaryObjectImpl]
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.typeByValue(GridQueryProcessor.java:1954)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1877)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:403)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:1343)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1207)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:345)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:3527)
>   at 
> 

[jira] [Commented] (IGNITE-7766) Ignite Queries 2: Test always failed IgniteCacheQueryNodeRestartTxSelfTest.testRestarts

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7766:


[~ascherbakov], are there any news here? What do you think about removal this 
test from run until it is re-engeneered as stable?

> Ignite Queries 2: Test always failed 
> IgniteCacheQueryNodeRestartTxSelfTest.testRestarts
> ---
>
> Key: IGNITE-7766
> URL: https://issues.apache.org/jira/browse/IGNITE-7766
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Dmitriy Pavlov
>Assignee: Alexei Scherbakov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
>Ignite Queries 2  
>  IgniteBinaryCacheQueryTestSuite2: 
> IgniteCacheQueryNodeRestartTxSelfTest.testRestarts (fail rate 76,1%) 
> IgniteCacheQueryNodeRestartTxSelfTest.testRestarts
>   Current failure:refs/heads/master   #345No changes  
> 11 Feb 18 03:03
>
> junit.framework.AssertionFailedError: On large page size must retry.
>  
> Last runs fails with 100% probability.



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

[jira] [Updated] (IGNITE-6600) Web Console: Make a design of 403 and 404 pages

[Vica Abramova (JIRA)]

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

Vica Abramova updated IGNITE-6600:
--
Attachment: (was: 404.png)

> Web Console: Make a design of 403 and 404 pages
> ---
>
> Key: IGNITE-6600
> URL: https://issues.apache.org/jira/browse/IGNITE-6600
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Reporter: Vica Abramova
>Assignee: Vica Abramova
>Priority: Minor
> Fix For: 2.5
>
>




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

[jira] [Updated] (IGNITE-6600) Web Console: Make a design of 403 and 404 pages

[Vica Abramova (JIRA)]

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

Vica Abramova updated IGNITE-6600:
--
Attachment: (was: 403.png)

> Web Console: Make a design of 403 and 404 pages
> ---
>
> Key: IGNITE-6600
> URL: https://issues.apache.org/jira/browse/IGNITE-6600
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Reporter: Vica Abramova
>Assignee: Vica Abramova
>Priority: Minor
> Fix For: 2.5
>
>




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

[jira] [Updated] (IGNITE-6600) Web Console: Make a design of 403 and 404 pages

[Vica Abramova (JIRA)]

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

Vica Abramova updated IGNITE-6600:
--
Attachment: (was: Снимок экрана 2018-03-14 в 15.01.13.png)

> Web Console: Make a design of 403 and 404 pages
> ---
>
> Key: IGNITE-6600
> URL: https://issues.apache.org/jira/browse/IGNITE-6600
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Reporter: Vica Abramova
>Assignee: Vica Abramova
>Priority: Minor
> Fix For: 2.5
>
> Attachments: 403.png, 404.png
>
>




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

[jira] [Updated] (IGNITE-6600) Web Console: Make a design of 403 and 404 pages

[Vica Abramova (JIRA)]

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

Vica Abramova updated IGNITE-6600:
--
Attachment: 403.png
404.png

> Web Console: Make a design of 403 and 404 pages
> ---
>
> Key: IGNITE-6600
> URL: https://issues.apache.org/jira/browse/IGNITE-6600
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Reporter: Vica Abramova
>Assignee: Vica Abramova
>Priority: Minor
> Fix For: 2.5
>
> Attachments: 403.png, 404.png
>
>




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

[jira] [Updated] (IGNITE-6600) Web Console: Make a design of 403 and 404 pages

[Vica Abramova (JIRA)]

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

Vica Abramova updated IGNITE-6600:
--
Attachment: (was: Снимок экрана 2018-03-14 в 15.01.27.png)

> Web Console: Make a design of 403 and 404 pages
> ---
>
> Key: IGNITE-6600
> URL: https://issues.apache.org/jira/browse/IGNITE-6600
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Reporter: Vica Abramova
>Assignee: Vica Abramova
>Priority: Minor
> Fix For: 2.5
>
> Attachments: 403.png, 404.png
>
>




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

[jira] [Updated] (IGNITE-6600) Web Console: Make a design of 403 and 404 pages

[Vica Abramova (JIRA)]

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

Vica Abramova updated IGNITE-6600:
--
Attachment: Снимок экрана 2018-03-14 в 15.01.13.png
Снимок экрана 2018-03-14 в 15.01.27.png

> Web Console: Make a design of 403 and 404 pages
> ---
>
> Key: IGNITE-6600
> URL: https://issues.apache.org/jira/browse/IGNITE-6600
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Reporter: Vica Abramova
>Assignee: Vica Abramova
>Priority: Minor
> Fix For: 2.5
>
> Attachments: Снимок экрана 2018-03-14 в 15.01.13.png, Снимок экрана 
> 2018-03-14 в 15.01.27.png
>
>




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

[jira] [Commented] (IGNITE-7814) Lost scala211.library.version parameter

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7814:


[~akalashnikov] do we have something to merge to make this test better?

> Lost scala211.library.version parameter
> ---
>
> Key: IGNITE-7814
> URL: https://issues.apache.org/jira/browse/IGNITE-7814
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> How we can see in test 
> https://ci.ignite.apache.org/viewLog.html?buildId=1109854#testNameId451522206339372479.
>  We use
> scala211.library.version but I see that some time ago it was renamed to 
> scala.library.version at determination place.
> I think we can't use scala.library.version parameter and we will should 
> return scala211.library.version parameter because it is using at specific 
> place for scala2.11 .



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

[jira] [Commented] (IGNITE-7834) Ignite Queries 2 fail rate is more than 95%: DynamicColumnsAbstractConcurrentSelfTest and its subclasses are flaky

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7834:


[~vozerov], do you mind removing Dynamic*Test suites from Queries 2 run? Seems 
this failures are not important as there is no response.

> Ignite Queries 2 fail rate is more than 95%: 
> DynamicColumnsAbstractConcurrentSelfTest and its subclasses are flaky
> --
>
> Key: IGNITE-7834
> URL: https://issues.apache.org/jira/browse/IGNITE-7834
> Project: Ignite
>  Issue Type: Test
>  Components: sql
>Reporter: Dmitriy Pavlov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Queries 2 suite has unstable tests DynamicColumns...
> Initially contrubuted by [~al.psc] in [IGNITE-5572]
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgniteQueries2=%3Cdefault%3E=buildTypeStatusDiv
> Last 10 runs statistics:
> {noformat}
> Ignite Queries 2 [ tests 16 ]
>  [2] IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testNodeJoinOnPendingAddOperation
>  (fail rate 5,8%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalReplicatedSelfTest.testAddColumnCoordinatorChange
>  (fail rate 5,8%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalReplicatedSelfTest.testNodeJoinOnPendingAddOperation
>  (fail rate 5,8%) 
>  [2] IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentAtomicPartitionedSelfTest.testDropColumnCoordinatorChange
>  (fail rate 3,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentAtomicPartitionedSelfTest.testNodeJoinOnPendingDropOperation
>  (fail rate 3,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentAtomicReplicatedSelfTest.testNodeJoinOnPendingAddOperation
>  (fail rate 3,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicIndexPartitionedAtomicConcurrentSelfTest.testClientReconnectWithCacheRestart
>  (fail rate 3,6%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testConcurrentOperationsAndNodeStartStopMultithreaded
>  (fail rate 2,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentAtomicReplicatedSelfTest.testDropConcurrentCacheDestroy
>  (fail rate 2,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testAddConcurrentRebalance
>  (fail rate 2,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicIndexReplicatedTransactionalConcurrentSelfTest.testClientReconnectWithCacheRestart
>  (fail rate 2,5%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentAtomicReplicatedSelfTest.testConcurrentPutRemove 
> (fail rate 2,2%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalReplicatedSelfTest.testDropConcurrentRebalance
>  (fail rate 1,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testClientReconnectWithCacheRestart
>  (fail rate 1,8%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testDropConcurrentCacheDestroy
>  (fail rate 1,0%) 
> IgniteBinaryCacheQueryTestSuite2: 
> DynamicIndexReplicatedTransactionalConcurrentSelfTest.testClientReconnect 
> (fail rate 0,4%) 
> {noformat}



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

[jira] [Commented] (IGNITE-7581) TxPessimisticDeadlockDetectionTest.testDeadlocksLocal hangs on TC

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7581:


[~agoncharuk], who we can ask to look to this issue? is it a priority?

> TxPessimisticDeadlockDetectionTest.testDeadlocksLocal hangs on TC
> -
>
> Key: IGNITE-7581
> URL: https://issues.apache.org/jira/browse/IGNITE-7581
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> The test hangs because the ConcurrentModificationException happens:
> {code}
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:502)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject.onTimeout(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:163)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.lang.Thread.run(Thread.java:745)
> [10:33:20]W:   [org.apache.ignite:ignite-core] 
> java.util.ConcurrentModificationException
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.util.ArrayList$Itr.next(ArrayList.java:851)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture.undoLocks(GridLocalLockFuture.java:297)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture.onComplete(GridLocalLockFuture.java:437)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture.access$700(GridLocalLockFuture.java:57)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:510)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject.onTimeout(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:163)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.lang.Thread.run(Thread.java:745)
> [10:33:20]W:   [org.apache.ignite:ignite-core] [2018-01-31 
> 07:33:20,502][ERROR][grid-timeout-worker-#1556%transactions.TxPessimisticDeadlockDetectionTest0%][GridTimeoutProcessor]
>  Error when executing timeout callback: LockTimeoutObject []
> [10:33:20]W:   [org.apache.ignite:ignite-core] 
> java.util.ConcurrentModificationException
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> 

[jira] [Commented] (IGNITE-7933) The error writing wal point to cp/node-start file can lead to the inability to start node

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7933:


GitHub user Jokser opened a pull request:

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

IGNITE-7933 Checkpoint markers writing issues

* Write checkpoint markers through temporary files
* Stop node if markCheckpointBegin is failed
* Reduced stop timeout
* Use Runtime.halt() to kill JVM if node is not stopped within timeout

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

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

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

https://github.com/apache/ignite/pull/3633.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 #3633


commit c9138c3ea9d6d79141aeedf02c7e27c3e2a487fe
Author: Pavel Kovalenko 
Date:   2018-03-14T11:51:01Z

IGNITE-7933 Checkpoint markers writing issues:
* Write checkpoint markers through temporary files
* Stop node if markCheckpointBegin is failed
* Reduced stop timeout
* Use Runtime.halt() to kill JVM if node is not stopped within timeout




> The error writing wal point to cp/node-start file can lead to the inability 
> to start node
> -
>
> Key: IGNITE-7933
> URL: https://issues.apache.org/jira/browse/IGNITE-7933
> Project: Ignite
>  Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Pavel Kovalenko
>Priority: Major
>  Labels: newbie
> Fix For: 2.5
>
>
> The problem is that the file exists on the disk but file content corrupted.
> Neet to write content via .tmp files.
> See:
> - writeCheckpointEntry
> - nodeStart



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

[jira] [Commented] (IGNITE-4229) Loading configuration from XML into Web Console for further editing

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-4229:
--

Lets prototype the following:

1) Create XML with help of Web Console.

2) Save it.

3) Try to load it back.

Lets skip errors, unknown beans and properties for now.

Also lets skip muli-files configs (with imports).

> Loading configuration from XML into Web Console for further editing
> ---
>
> Key: IGNITE-4229
> URL: https://issues.apache.org/jira/browse/IGNITE-4229
> Project: Ignite
>  Issue Type: Wish
>  Components: wizards
>Reporter: Alexandr Kuramshin
>Assignee: Ilya Borisov
>Priority: Minor
>  Labels: console
>
> It would be great to have ability of loading an external XML into Console as 
> the initial configuration and then get editing.
> At this point it's only allowed to create a configuration from scratch and 
> then export to the XML.



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

[jira] [Updated] (IGNITE-7671) Fix '.gitignore files are tracked' error

[Peter Ivanov (JIRA)]

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

Peter Ivanov updated IGNITE-7671:
-
Summary: Fix '.gitignore files are tracked' error  (was: Fix .gitignore 
files are tracked error)

> Fix '.gitignore files are tracked' error
> 
>
> Key: IGNITE-7671
> URL: https://issues.apache.org/jira/browse/IGNITE-7671
> Project: Ignite
>  Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Major
>
> Current {{.gitignore}} has definitions of files to ignore, which are already 
> under the version control system (some *.sh scripts for example). It needs to 
> be fixed.



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

[jira] [Updated] (IGNITE-7647) Apache Ignite RPM packages (Stage II)

[Peter Ivanov (JIRA)]

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

Peter Ivanov updated IGNITE-7647:
-
Summary: Apache Ignite RPM packages (Stage II)  (was: Apache Ignite RPM 
packages)

> Apache Ignite RPM packages (Stage II)
> -
>
> Key: IGNITE-7647
> URL: https://issues.apache.org/jira/browse/IGNITE-7647
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Fix For: 2.5
>
>
> # Repack RPM specification to:
> #* be able to build package from source code
> #* divide single package into multiple packages (core + optional).
> # Introduce process of PRM building in release procedure.
> # Introduce repository update scheme.



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

[jira] [Updated] (IGNITE-7950) SQL: Add upload benchmarks for sql streamer feature

[Pavel Kuznetsov (JIRA)]

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

Pavel Kuznetsov updated IGNITE-7950:

Description: 
IGNITE-7253 introduces streaming mode. 
We need to update/create benchmarks to measure total upload time using single 
and batched inserts
Data model remains the same as in IGNITE-7531 : incrementaly generated long 
primary key, 5 long and 5 strings (contains random long value in string 
representation)

  was:
IGNITE-7253 introduces streaming mode. 
We need to update/create benchmarks to measure total upload time.
Data model remains the same as in IGNITE-7531 : incrementaly generated long 
primary key, 5 long and 5 strings (contains random long value in string 
representation)


> SQL: Add upload benchmarks for sql streamer feature
> ---
>
> Key: IGNITE-7950
> URL: https://issues.apache.org/jira/browse/IGNITE-7950
> Project: Ignite
>  Issue Type: Task
>  Components: sql, yardstick
>Reporter: Pavel Kuznetsov
>Assignee: Pavel Kuznetsov
>Priority: Major
>
> IGNITE-7253 introduces streaming mode. 
> We need to update/create benchmarks to measure total upload time using single 
> and batched inserts
> Data model remains the same as in IGNITE-7531 : incrementaly generated long 
> primary key, 5 long and 5 strings (contains random long value in string 
> representation)



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

[jira] [Created] (IGNITE-7950) SQL: Add upload benchmarks for sql streamer feature

[Pavel Kuznetsov (JIRA)]

Pavel Kuznetsov created IGNITE-7950:
---

 Summary: SQL: Add upload benchmarks for sql streamer feature
 Key: IGNITE-7950
 URL: https://issues.apache.org/jira/browse/IGNITE-7950
 Project: Ignite
  Issue Type: Task
  Components: sql, yardstick
Reporter: Pavel Kuznetsov
Assignee: Pavel Kuznetsov


IGNITE-7253 introduces streaming mode. 
We need to update/create benchmarks to measure total upload time.
Data model remains the same as in IGNITE-7531 : incrementaly generated long 
primary key, 5 long and 5 strings (contains random long value in string 
representation)



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

[jira] [Commented] (IGNITE-7946) IgniteCacheClientQueryReplicatedNodeRestartSelfTest#testRestarts can hang on TC

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7946:


Github user asfgit closed the pull request at:

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


> IgniteCacheClientQueryReplicatedNodeRestartSelfTest#testRestarts can hang on 
> TC
> ---
>
> Key: IGNITE-7946
> URL: https://issues.apache.org/jira/browse/IGNITE-7946
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.4
>Reporter: Pavel Kovalenko
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> According to test logs there can be unfinished rebalance:
> {noformat}
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,327][INFO 
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
>  Cancelled rebalancing from all nodes [topology=AffinityTopologyVersion 
> [topVer=103, minorTopVer=0]]
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,327][INFO 
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
>  Completed rebalance future: RebalanceFuture [grp=CacheGroupContext [grp=pr], 
> topVer=AffinityTopologyVersion [topVer=103, minorTopVer=0], rebalanceId=1]
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,328][INFO 
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridCachePartitionExchangeManager]
>  Rebalancing scheduled [order=[pe, pr]]
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,328][INFO 
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridCachePartitionExchangeManager]
>  Rebalancing started [top=AffinityTopologyVersion [topVer=104, 
> minorTopVer=0], evt=NODE_LEFT, node=04d02ea1-286c-4d8c-8870-e147c552]
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,328][INFO 
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
>  Starting rebalancing [grp=pe, mode=SYNC, 
> fromNode=31193890-bf8f-4c85-af76-342efb31, partitionsCount=15, 
> topology=AffinityTopologyVersion [topVer=104, minorTopVer=0], rebalanceId=2]
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,328][INFO 
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
>  Starting rebalancing [grp=pe, mode=SYNC, 
> fromNode=517f4efb-4433-489a-8c8e-e91f9e70, partitionsCount=16, 
> topology=AffinityTopologyVersion [topVer=104, minorTopVer=0], rebalanceId=2]
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,328][INFO 
> ][exchange-worker-#455983%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest0%][GridCachePartitionExchangeManager]
>  Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion 
> [topVer=104, minorTopVer=0], evt=NODE_LEFT, 
> node=04d02ea1-286c-4d8c-8870-e147c552]
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,332][INFO 
> ][sys-#456730%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
>  Completed rebalancing [fromNode=517f4efb-4433-489a-8c8e-e91f9e70, 
> cacheOrGroup=pe, topology=AffinityTopologyVersion [topVer=104, 
> minorTopVer=0], time=0 ms]
> {noformat}
> It can be cause of test hanging.
> {noformat}
> "restart-thread-2" #441778 prio=5 os_prio=0 tid=0x7fd030003800 nid=0x3b8c 
> waiting on condition [0x7fce5092f000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:861)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1059)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1973)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
> - locked <0x00070d8a1830> (a 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:849)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:833)
> at 
> 

[jira] [Updated] (IGNITE-6600) Web Console: Make a design of 403 and 404 pages

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-6600:
-
Fix Version/s: 2.5

> Web Console: Make a design of 403 and 404 pages
> ---
>
> Key: IGNITE-6600
> URL: https://issues.apache.org/jira/browse/IGNITE-6600
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Reporter: Vica Abramova
>Assignee: Vica Abramova
>Priority: Minor
> Fix For: 2.5
>
>




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

[jira] [Created] (IGNITE-7949) Web Console: Refactor post validation on sign in / sign up.

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-7949:


 Summary: Web Console: Refactor post validation on sign in / sign 
up.
 Key: IGNITE-7949
 URL: https://issues.apache.org/jira/browse/IGNITE-7949
 Project: Ignite
  Issue Type: Task
  Components: wizards
Reporter: Alexey Kuznetsov
Assignee: Ilya Borisov
 Fix For: 2.5


In current implementation we show ugly popover in case of server error or when 
backend unavailable at all.

 

Lets show errors as we do for input validation errors.

And when server not available lets show proper message.



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

[jira] [Updated] (IGNITE-7946) IgniteCacheClientQueryReplicatedNodeRestartSelfTest#testRestarts can hang on TC

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-7946:
-
Fix Version/s: 2.5

> IgniteCacheClientQueryReplicatedNodeRestartSelfTest#testRestarts can hang on 
> TC
> ---
>
> Key: IGNITE-7946
> URL: https://issues.apache.org/jira/browse/IGNITE-7946
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.4
>Reporter: Pavel Kovalenko
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> According to test logs there can be unfinished rebalance:
> {noformat}
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,327][INFO 
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
>  Cancelled rebalancing from all nodes [topology=AffinityTopologyVersion 
> [topVer=103, minorTopVer=0]]
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,327][INFO 
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
>  Completed rebalance future: RebalanceFuture [grp=CacheGroupContext [grp=pr], 
> topVer=AffinityTopologyVersion [topVer=103, minorTopVer=0], rebalanceId=1]
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,328][INFO 
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridCachePartitionExchangeManager]
>  Rebalancing scheduled [order=[pe, pr]]
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,328][INFO 
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridCachePartitionExchangeManager]
>  Rebalancing started [top=AffinityTopologyVersion [topVer=104, 
> minorTopVer=0], evt=NODE_LEFT, node=04d02ea1-286c-4d8c-8870-e147c552]
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,328][INFO 
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
>  Starting rebalancing [grp=pe, mode=SYNC, 
> fromNode=31193890-bf8f-4c85-af76-342efb31, partitionsCount=15, 
> topology=AffinityTopologyVersion [topVer=104, minorTopVer=0], rebalanceId=2]
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,328][INFO 
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
>  Starting rebalancing [grp=pe, mode=SYNC, 
> fromNode=517f4efb-4433-489a-8c8e-e91f9e70, partitionsCount=16, 
> topology=AffinityTopologyVersion [topVer=104, minorTopVer=0], rebalanceId=2]
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,328][INFO 
> ][exchange-worker-#455983%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest0%][GridCachePartitionExchangeManager]
>  Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion 
> [topVer=104, minorTopVer=0], evt=NODE_LEFT, 
> node=04d02ea1-286c-4d8c-8870-e147c552]
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,332][INFO 
> ][sys-#456730%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
>  Completed rebalancing [fromNode=517f4efb-4433-489a-8c8e-e91f9e70, 
> cacheOrGroup=pe, topology=AffinityTopologyVersion [topVer=104, 
> minorTopVer=0], time=0 ms]
> {noformat}
> It can be cause of test hanging.
> {noformat}
> "restart-thread-2" #441778 prio=5 os_prio=0 tid=0x7fd030003800 nid=0x3b8c 
> waiting on condition [0x7fce5092f000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:861)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1059)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1973)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
> - locked <0x00070d8a1830> (a 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:849)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:833)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:821)
> at 
> 

[jira] [Commented] (IGNITE-7947) Not all OWNING partitions saved in PartitionAllocationMap during checkpoint

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev commented on IGNITE-7947:
---

PR: https://github.com/apache/ignite/pull/3632
TC Run: https://ci.ignite.apache.org/viewQueued.html?itemId=1136349

> Not all OWNING partitions saved in PartitionAllocationMap during checkpoint
> ---
>
> Key: IGNITE-7947
> URL: https://issues.apache.org/jira/browse/IGNITE-7947
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.5
>
>
> In checkpoint begin listeners we collect PartitionAllocationMap in offheap 
> managers. 
> But if rowStore is null than we ignore this partition in any case even if we 
> own it.



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

[jira] [Commented] (IGNITE-7947) Not all OWNING partitions saved in PartitionAllocationMap during checkpoint

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7947:


GitHub user EdShangGG opened a pull request:

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

IGNITE-7947 Not all OWNING partitions saved in PartitionAllocationMap…

… during checkpoint

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

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

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

https://github.com/apache/ignite/pull/3632.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 #3632


commit f7f419c42e9bb6d2b9e72c2fe1b8e007c82655fc
Author: Eduard Shangareev 
Date:   2018-03-14T10:56:24Z

IGNITE-7947 Not all OWNING partitions saved in PartitionAllocationMap 
during checkpoint




> Not all OWNING partitions saved in PartitionAllocationMap during checkpoint
> ---
>
> Key: IGNITE-7947
> URL: https://issues.apache.org/jira/browse/IGNITE-7947
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.5
>
>
> In checkpoint begin listeners we collect PartitionAllocationMap in offheap 
> managers. 
> But if rowStore is null than we ignore this partition in any case even if we 
> own it.



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

[jira] [Created] (IGNITE-7948) SQL: read only necessary fields into the row when possible

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-7948:
---

 Summary: SQL: read only necessary fields into the row when possible
 Key: IGNITE-7948
 URL: https://issues.apache.org/jira/browse/IGNITE-7948
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov


When H2 row is read, we always fill it with data eagerly through link 
materialization. Materialization is performed under page "read lock" what 
guarantees row-level consistency. This may lead to excessive memory pressure 
due to memory copying. For example, consider a class with 50 fields and a query 
which reads only 2 of them. 48 other fields will be copied without a reason. 
Lazy initialization is not an option because it will only defer memcpy, but not 
eliminate it. 

Instead we can try using H2. It passes {{TableFilter}} class to some of index 
access methods*. We can analyze this class and create the list of required 
fields. Then we can read these fields under read lock from offheap and put them 
to the row.

In addition to saved memcpy this could give us more benefits:
1) No more need for field cache ({{GridH2KeyValueRowOnheap#valCache}})
2) No more need to read {{_VER}} column and possibly {{_KEY}} or {{_VAL}}

But there are a number of drawbacks as well. E.g. it is impossible to read 
strings from offheap efficiently, so queries with VARCHAR will definitely 
suffer from this change.

\* {{org.h2.index.Index#find(org.h2.table.TableFilter, org.h2.result.SearchRow, 
org.h2.result.SearchRow)}}



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

[jira] [Created] (IGNITE-7947) Not all OWNING partitions saved in PartitionAllocationMap during checkpoint

[Eduard Shangareev (JIRA)]

Eduard Shangareev created IGNITE-7947:
-

 Summary: Not all OWNING partitions saved in PartitionAllocationMap 
during checkpoint
 Key: IGNITE-7947
 URL: https://issues.apache.org/jira/browse/IGNITE-7947
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.4
Reporter: Eduard Shangareev
Assignee: Eduard Shangareev
 Fix For: 2.5


In checkpoint begin listeners we collect PartitionAllocationMap in offheap 
managers. 
But if rowStore is null than we ignore this partition in any case even if we 
own it.



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

[jira] [Commented] (IGNITE-7774) Missing Google Cloud libraries at binary release

[Roman Guseinov (JIRA)]

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

Roman Guseinov commented on IGNITE-7774:


[~vveider] , thanks for your comments. I will check the IGNITE-7862 branch and 
try to add maven-dependency-plugin

> Missing Google Cloud libraries at binary release
> 
>
> Key: IGNITE-7774
> URL: https://issues.apache.org/jira/browse/IGNITE-7774
> Project: Ignite
>  Issue Type: Bug
>  Components: build
>Affects Versions: 2.3
> Environment: * Ubuntu 16.04.3 LTS
> * Apache Ignite 2.3.0
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
>  Labels: build
> Fix For: 2.5
>
>
> It looks like following libraries aren't included in the build:
>  * google-http-client-1.22.0.jar
>  * google-http-client-jackson2-1.22.0.jar
>  * google-oauth-client-1.22.0.jar
> Steps to reproduce:
> 1. Download apache-ignite-fabric-2.3.0-bin.zip 
> ([http://apache-mirror.rbc.ru/pub/apache//ignite/2.3.0/apache-ignite-fabric-2.3.0-bin.zip]).
> 2. Unzip archive.
> 3. Move ignite-rest-http from /libs/optional to /libs
> 4. Move ignite-gce from /libs/optional to /libs
> 5. Update IgniteConfiguration in default-config.xml:
> {code:xml}
> 
>   
> 
>class="org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder">
> 
> 
> 
>  value="discovery-sp...@apache-ignite.iam.gserviceaccount.com"/>
>   
> 
>   
> 
> {code}
> 6. Copy  into $IGNITE_HOME
> 7. Run bin/ignite.sh
> 8. Log:
> {code:java}
> class org.apache.ignite.IgniteException: Failed to instantiate Spring XML 
> application context (make sure all classes used in Spring configuration are 
> present at CLASSPATH) 
> [springUrl=file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]
>  at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:966)
>  at org.apache.ignite.Ignition.start(Ignition.java:350)
>  at 
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to 
> instantiate Spring XML application context (make sure all classes used in 
> Spring configuration are present at CLASSPATH) 
> [springUrl=file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.applicationContext(IgniteSpringHelperImpl.java:387)
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:104)
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:98)
>  at 
> org.apache.ignite.internal.IgnitionEx.loadConfigurations(IgnitionEx.java:673)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:874)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:783)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:653)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:622)
>  at org.apache.ignite.Ignition.start(Ignition.java:347)
>  ... 1 more
> Caused by: org.springframework.beans.factory.BeanCreationException: Error 
> creating bean with name 
> 'org.apache.ignite.configuration.IgniteConfiguration#0' defined in URL 
> [file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]:
>  Cannot create inner bean 
> 'org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi#65e2dbf3' of type 
> [org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi] while setting bean 
> property 'discoverySpi'; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi#65e2dbf3' 
> defined in URL 
> [file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]:
>  Cannot create inner bean 
> 'org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder#1d16f93d'
>  of type 
> [org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder]
>  while setting bean property 'ipFinder'; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 
> 'org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder#1d16f93d'
>  defined in URL 
> [file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]:
>  Instantiation of bean failed; nested exception is 
> org.springframework.beans.BeanInstantiationException: Failed to instantiate 
> 

[jira] [Commented] (IGNITE-7946) IgniteCacheClientQueryReplicatedNodeRestartSelfTest#testRestarts can hang on TC

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7946:


GitHub user Jokser opened a pull request:

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

IGNITE-7946 Fail test with known issue



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

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

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

https://github.com/apache/ignite/pull/3631.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 #3631


commit 2dbc5efe69a02a07f670149c7ed2acfe507d6e9c
Author: Pavel Kovalenko 
Date:   2018-03-14T10:32:23Z

IGNITE-7946 Fail test with known issue




> IgniteCacheClientQueryReplicatedNodeRestartSelfTest#testRestarts can hang on 
> TC
> ---
>
> Key: IGNITE-7946
> URL: https://issues.apache.org/jira/browse/IGNITE-7946
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.4
>Reporter: Pavel Kovalenko
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> According to test logs there can be unfinished rebalance:
> {noformat}
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,327][INFO 
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
>  Cancelled rebalancing from all nodes [topology=AffinityTopologyVersion 
> [topVer=103, minorTopVer=0]]
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,327][INFO 
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
>  Completed rebalance future: RebalanceFuture [grp=CacheGroupContext [grp=pr], 
> topVer=AffinityTopologyVersion [topVer=103, minorTopVer=0], rebalanceId=1]
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,328][INFO 
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridCachePartitionExchangeManager]
>  Rebalancing scheduled [order=[pe, pr]]
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,328][INFO 
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridCachePartitionExchangeManager]
>  Rebalancing started [top=AffinityTopologyVersion [topVer=104, 
> minorTopVer=0], evt=NODE_LEFT, node=04d02ea1-286c-4d8c-8870-e147c552]
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,328][INFO 
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
>  Starting rebalancing [grp=pe, mode=SYNC, 
> fromNode=31193890-bf8f-4c85-af76-342efb31, partitionsCount=15, 
> topology=AffinityTopologyVersion [topVer=104, minorTopVer=0], rebalanceId=2]
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,328][INFO 
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
>  Starting rebalancing [grp=pe, mode=SYNC, 
> fromNode=517f4efb-4433-489a-8c8e-e91f9e70, partitionsCount=16, 
> topology=AffinityTopologyVersion [topVer=104, minorTopVer=0], rebalanceId=2]
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,328][INFO 
> ][exchange-worker-#455983%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest0%][GridCachePartitionExchangeManager]
>  Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion 
> [topVer=104, minorTopVer=0], evt=NODE_LEFT, 
> node=04d02ea1-286c-4d8c-8870-e147c552]
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,332][INFO 
> ][sys-#456730%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
>  Completed rebalancing [fromNode=517f4efb-4433-489a-8c8e-e91f9e70, 
> cacheOrGroup=pe, topology=AffinityTopologyVersion [topVer=104, 
> minorTopVer=0], time=0 ms]
> {noformat}
> It can be cause of test hanging.
> {noformat}
> "restart-thread-2" #441778 prio=5 os_prio=0 tid=0x7fd030003800 nid=0x3b8c 
> waiting on condition [0x7fce5092f000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:861)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1059)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1973)
> at 
> 

[jira] [Updated] (IGNITE-7946) IgniteCacheClientQueryReplicatedNodeRestartSelfTest#testRestarts can hang on TC

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-7946:
---
Labels: MakeTeamcityGreenAgain  (was: )

> IgniteCacheClientQueryReplicatedNodeRestartSelfTest#testRestarts can hang on 
> TC
> ---
>
> Key: IGNITE-7946
> URL: https://issues.apache.org/jira/browse/IGNITE-7946
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.4
>Reporter: Pavel Kovalenko
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> According to test logs there can be unfinished rebalance:
> {noformat}
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,327][INFO 
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
>  Cancelled rebalancing from all nodes [topology=AffinityTopologyVersion 
> [topVer=103, minorTopVer=0]]
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,327][INFO 
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
>  Completed rebalance future: RebalanceFuture [grp=CacheGroupContext [grp=pr], 
> topVer=AffinityTopologyVersion [topVer=103, minorTopVer=0], rebalanceId=1]
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,328][INFO 
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridCachePartitionExchangeManager]
>  Rebalancing scheduled [order=[pe, pr]]
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,328][INFO 
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridCachePartitionExchangeManager]
>  Rebalancing started [top=AffinityTopologyVersion [topVer=104, 
> minorTopVer=0], evt=NODE_LEFT, node=04d02ea1-286c-4d8c-8870-e147c552]
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,328][INFO 
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
>  Starting rebalancing [grp=pe, mode=SYNC, 
> fromNode=31193890-bf8f-4c85-af76-342efb31, partitionsCount=15, 
> topology=AffinityTopologyVersion [topVer=104, minorTopVer=0], rebalanceId=2]
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,328][INFO 
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
>  Starting rebalancing [grp=pe, mode=SYNC, 
> fromNode=517f4efb-4433-489a-8c8e-e91f9e70, partitionsCount=16, 
> topology=AffinityTopologyVersion [topVer=104, minorTopVer=0], rebalanceId=2]
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,328][INFO 
> ][exchange-worker-#455983%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest0%][GridCachePartitionExchangeManager]
>  Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion 
> [topVer=104, minorTopVer=0], evt=NODE_LEFT, 
> node=04d02ea1-286c-4d8c-8870-e147c552]
> [01:21:23] :   [Step 4/5] [2018-03-13 22:21:23,332][INFO 
> ][sys-#456730%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
>  Completed rebalancing [fromNode=517f4efb-4433-489a-8c8e-e91f9e70, 
> cacheOrGroup=pe, topology=AffinityTopologyVersion [topVer=104, 
> minorTopVer=0], time=0 ms]
> {noformat}
> It can be cause of test hanging.
> {noformat}
> "restart-thread-2" #441778 prio=5 os_prio=0 tid=0x7fd030003800 nid=0x3b8c 
> waiting on condition [0x7fce5092f000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:861)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1059)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1973)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
> - locked <0x00070d8a1830> (a 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:849)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:833)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:821)
> at 
> 

[jira] [Updated] (IGNITE-7946) IgniteCacheClientQueryReplicatedNodeRestartSelfTest#testRestarts can hang on TC

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko updated IGNITE-7946:

Description: 
According to test logs there can be unfinished rebalance:
{noformat}
[01:21:23] : [Step 4/5] [2018-03-13 22:21:23,327][INFO 
][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
 Cancelled rebalancing from all nodes [topology=AffinityTopologyVersion 
[topVer=103, minorTopVer=0]]
[01:21:23] : [Step 4/5] [2018-03-13 22:21:23,327][INFO 
][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
 Completed rebalance future: RebalanceFuture [grp=CacheGroupContext [grp=pr], 
topVer=AffinityTopologyVersion [topVer=103, minorTopVer=0], rebalanceId=1]
[01:21:23] : [Step 4/5] [2018-03-13 22:21:23,328][INFO 
][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridCachePartitionExchangeManager]
 Rebalancing scheduled [order=[pe, pr]]
[01:21:23] : [Step 4/5] [2018-03-13 22:21:23,328][INFO 
][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridCachePartitionExchangeManager]
 Rebalancing started [top=AffinityTopologyVersion [topVer=104, minorTopVer=0], 
evt=NODE_LEFT, node=04d02ea1-286c-4d8c-8870-e147c552]
[01:21:23] : [Step 4/5] [2018-03-13 22:21:23,328][INFO 
][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
 Starting rebalancing [grp=pe, mode=SYNC, 
fromNode=31193890-bf8f-4c85-af76-342efb31, partitionsCount=15, 
topology=AffinityTopologyVersion [topVer=104, minorTopVer=0], rebalanceId=2]
[01:21:23] : [Step 4/5] [2018-03-13 22:21:23,328][INFO 
][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
 Starting rebalancing [grp=pe, mode=SYNC, 
fromNode=517f4efb-4433-489a-8c8e-e91f9e70, partitionsCount=16, 
topology=AffinityTopologyVersion [topVer=104, minorTopVer=0], rebalanceId=2]
[01:21:23] : [Step 4/5] [2018-03-13 22:21:23,328][INFO 
][exchange-worker-#455983%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest0%][GridCachePartitionExchangeManager]
 Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion 
[topVer=104, minorTopVer=0], evt=NODE_LEFT, 
node=04d02ea1-286c-4d8c-8870-e147c552]
[01:21:23] : [Step 4/5] [2018-03-13 22:21:23,332][INFO 
][sys-#456730%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
 Completed rebalancing [fromNode=517f4efb-4433-489a-8c8e-e91f9e70, 
cacheOrGroup=pe, topology=AffinityTopologyVersion [topVer=104, minorTopVer=0], 
time=0 ms]

{noformat}
It can be cause of test hanging.

{noformat}
"restart-thread-2" #441778 prio=5 os_prio=0 tid=0x7fd030003800 nid=0x3b8c 
waiting on condition [0x7fce5092f000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:861)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1059)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1973)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
- locked <0x00070d8a1830> (a 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:849)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:833)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:821)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:787)
at 
org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest.access$600(IgniteCacheClientQueryReplicatedNodeRestartSelfTest.java:60)
at 
org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest$3.call(IgniteCacheClientQueryReplicatedNodeRestartSelfTest.java:352)
at 
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
"restart-thread-1" #441777 prio=5 os_prio=0 tid=0x7fd03000b800 nid=0x3b8b 
waiting on condition [0x7fce50a31000]
   java.lang.Thread.State: WAITING 

[jira] [Assigned] (IGNITE-7944) Disconnected client node tries to send JOB_CANCEL message

[Roman Guseinov (JIRA)]

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

Roman Guseinov reassigned IGNITE-7944:
--

Assignee: Roman Guseinov

> Disconnected client node tries to send JOB_CANCEL message
> -
>
> Key: IGNITE-7944
> URL: https://issues.apache.org/jira/browse/IGNITE-7944
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.9, 2.3
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
> Attachments: Reproducer7944.java
>
>
> In case the network is blocked (socket connections not closed) and failure is 
> detected, tcp-client-disco-msg-worker thread can be stuck in process of 
> TcpClient creating:
> {code:java}
> "tcp-client-disco-msg-worker-#4%wd5prsvtots0016a-tg-QueryFabric%" #494 prio=5 
> os_prio=0 tid=0x7f94c067c800 nid=0x2bdf runnable [0x7f960ecf1000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.Net.poll(Native Method)
> at sun.nio.ch.SocketChannelImpl.poll(SocketChannelImpl.java:954)
> - locked <0x7fa140f520c0> (a java.lang.Object)
> at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:110)
> - locked <0x7fa140f520b0> (a java.lang.Object)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2950)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2681)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2568)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2429)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2393)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1590)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1659)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.cancelChildren(GridTaskWorker.java:1305)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1609)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1581)
> at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.onDisconnected(GridTaskProcessor.java:168)
> at 
> org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:3460)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:601)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2407)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2386)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1714)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> It looks like msg-worker is trying to send JOB_CANCEL message for each job 
> with timeout equals failureDetectionTimeout.
> Reproducer is attached.



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

[jira] [Created] (IGNITE-7946) IgniteCacheClientQueryReplicatedNodeRestartSelfTest#testRestarts can hang on TC

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-7946:
---

 Summary: 
IgniteCacheClientQueryReplicatedNodeRestartSelfTest#testRestarts can hang on TC
 Key: IGNITE-7946
 URL: https://issues.apache.org/jira/browse/IGNITE-7946
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.4
Reporter: Pavel Kovalenko


According to test logs there can be unfinished rebalance:

{noformat}
[01:21:23] : [Step 4/5] [2018-03-13 22:21:23,327][INFO 
][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
 Cancelled rebalancing from all nodes [topology=AffinityTopologyVersion 
[topVer=103, minorTopVer=0]]
[01:21:23] : [Step 4/5] [2018-03-13 22:21:23,327][INFO 
][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
 Completed rebalance future: RebalanceFuture [grp=CacheGroupContext [grp=pr], 
topVer=AffinityTopologyVersion [topVer=103, minorTopVer=0], rebalanceId=1]
[01:21:23] : [Step 4/5] [2018-03-13 22:21:23,328][INFO 
][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridCachePartitionExchangeManager]
 Rebalancing scheduled [order=[pe, pr]]
[01:21:23] : [Step 4/5] [2018-03-13 22:21:23,328][INFO 
][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridCachePartitionExchangeManager]
 Rebalancing started [top=AffinityTopologyVersion [topVer=104, minorTopVer=0], 
evt=NODE_LEFT, node=04d02ea1-286c-4d8c-8870-e147c552]
[01:21:23] : [Step 4/5] [2018-03-13 22:21:23,328][INFO 
][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
 Starting rebalancing [grp=pe, mode=SYNC, 
fromNode=31193890-bf8f-4c85-af76-342efb31, partitionsCount=15, 
topology=AffinityTopologyVersion [topVer=104, minorTopVer=0], rebalanceId=2]
[01:21:23] : [Step 4/5] [2018-03-13 22:21:23,328][INFO 
][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
 Starting rebalancing [grp=pe, mode=SYNC, 
fromNode=517f4efb-4433-489a-8c8e-e91f9e70, partitionsCount=16, 
topology=AffinityTopologyVersion [topVer=104, minorTopVer=0], rebalanceId=2]
[01:21:23] : [Step 4/5] [2018-03-13 22:21:23,328][INFO 
][exchange-worker-#455983%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest0%][GridCachePartitionExchangeManager]
 Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion 
[topVer=104, minorTopVer=0], evt=NODE_LEFT, 
node=04d02ea1-286c-4d8c-8870-e147c552]
[01:21:23] : [Step 4/5] [2018-03-13 22:21:23,332][INFO 
][sys-#456730%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
 Completed rebalancing [fromNode=517f4efb-4433-489a-8c8e-e91f9e70, 
cacheOrGroup=pe, topology=AffinityTopologyVersion [topVer=104, minorTopVer=0], 
time=0 ms]

{noformat}


It can be cause of test hanging.



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

[jira] [Created] (IGNITE-7945) Apache Ignite nightly releases

[Peter Ivanov (JIRA)]

Peter Ivanov created IGNITE-7945:


 Summary: Apache Ignite nightly releases
 Key: IGNITE-7945
 URL: https://issues.apache.org/jira/browse/IGNITE-7945
 Project: Ignite
  Issue Type: Task
Reporter: Peter Ivanov
Assignee: Peter Ivanov


# As discussed 
[here|http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-nightly-release-builds-td27966.html],
 it is necessary to prepare build on [AI TeamCity|ttps://ci.ignite.apache.org] 
which will run every night and will build release binaries for *{{master}}* 
branch.
# Prepare corresponding [Apache Ignite 
Documentation|https://ignite.apache.org/download.cgi] section for link to 
latest nightly release binaries.



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

[jira] [Updated] (IGNITE-7944) Disconnected client node tries to send JOB_CANCEL message

[Roman Guseinov (JIRA)]

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

Roman Guseinov updated IGNITE-7944:
---
Description: 
In case the network is blocked (socket connections not closed) and failure is 
detected, tcp-client-disco-msg-worker thread can be stuck in process of 
TcpClient creating:
{code:java}
"tcp-client-disco-msg-worker-#4%wd5prsvtots0016a-tg-QueryFabric%" #494 prio=5 
os_prio=0 tid=0x7f94c067c800 nid=0x2bdf runnable [0x7f960ecf1000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.Net.poll(Native Method)
at sun.nio.ch.SocketChannelImpl.poll(SocketChannelImpl.java:954)
- locked <0x7fa140f520c0> (a java.lang.Object)
at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:110)
- locked <0x7fa140f520b0> (a java.lang.Object)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2950)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2681)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2568)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2429)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2393)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1590)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1659)
at 
org.apache.ignite.internal.processors.task.GridTaskWorker.cancelChildren(GridTaskWorker.java:1305)
at 
org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1609)
at 
org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1581)
at 
org.apache.ignite.internal.processors.task.GridTaskProcessor.onDisconnected(GridTaskProcessor.java:168)
at 
org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:3460)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:601)
at 
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2407)
at 
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2386)
at 
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1714)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
{code}
It looks like msg-worker is trying to send JOB_CANCEL message for each job with 
timeout equals failureDetectionTimeout.

Reproducer is attached.

> Disconnected client node tries to send JOB_CANCEL message
> -
>
> Key: IGNITE-7944
> URL: https://issues.apache.org/jira/browse/IGNITE-7944
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.9, 2.3
>Reporter: Roman Guseinov
>Priority: Major
> Attachments: Reproducer7944.java
>
>
> In case the network is blocked (socket connections not closed) and failure is 
> detected, tcp-client-disco-msg-worker thread can be stuck in process of 
> TcpClient creating:
> {code:java}
> "tcp-client-disco-msg-worker-#4%wd5prsvtots0016a-tg-QueryFabric%" #494 prio=5 
> os_prio=0 tid=0x7f94c067c800 nid=0x2bdf runnable [0x7f960ecf1000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.Net.poll(Native Method)
> at sun.nio.ch.SocketChannelImpl.poll(SocketChannelImpl.java:954)
> - locked <0x7fa140f520c0> (a java.lang.Object)
> at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:110)
> - locked <0x7fa140f520b0> (a java.lang.Object)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2950)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2681)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2568)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2429)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2393)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1590)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1659)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.cancelChildren(GridTaskWorker.java:1305)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1609)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1581)
> at 
> 

[jira] [Updated] (IGNITE-7944) Disconnected client node tries to send JOB_CANCEL message

[Roman Guseinov (JIRA)]

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

Roman Guseinov updated IGNITE-7944:
---
Attachment: Reproducer7944.java

> Disconnected client node tries to send JOB_CANCEL message
> -
>
> Key: IGNITE-7944
> URL: https://issues.apache.org/jira/browse/IGNITE-7944
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.9, 2.3
> Environment: In case the network is blocked (socket connections not 
> closed) and failure is detected, tcp-client-disco-msg-worker thread can be 
> stuck in process of TcpClient creating:
> {code:java}
> "tcp-client-disco-msg-worker-#4%wd5prsvtots0016a-tg-QueryFabric%" #494 prio=5 
> os_prio=0 tid=0x7f94c067c800 nid=0x2bdf runnable [0x7f960ecf1000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.Net.poll(Native Method)
> at sun.nio.ch.SocketChannelImpl.poll(SocketChannelImpl.java:954)
> - locked <0x7fa140f520c0> (a java.lang.Object)
> at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:110)
> - locked <0x7fa140f520b0> (a java.lang.Object)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2950)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2681)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2568)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2429)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2393)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1590)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1659)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.cancelChildren(GridTaskWorker.java:1305)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1609)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1581)
> at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.onDisconnected(GridTaskProcessor.java:168)
> at 
> org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:3460)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:601)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2407)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2386)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1714)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> It looks like msg-worker is trying to send JOB_CANCEL message for each job 
> with timeout equals failureDetectionTimeout.
> Reproducer is attached.
>Reporter: Roman Guseinov
>Priority: Major
> Attachments: Reproducer7944.java
>
>




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

[jira] [Updated] (IGNITE-7944) Disconnected client node tries to send JOB_CANCEL message

[Roman Guseinov (JIRA)]

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

Roman Guseinov updated IGNITE-7944:
---
Environment: (was: In case the network is blocked (socket connections 
not closed) and failure is detected, tcp-client-disco-msg-worker thread can be 
stuck in process of TcpClient creating:
{code:java}
"tcp-client-disco-msg-worker-#4%wd5prsvtots0016a-tg-QueryFabric%" #494 prio=5 
os_prio=0 tid=0x7f94c067c800 nid=0x2bdf runnable [0x7f960ecf1000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.Net.poll(Native Method)
at sun.nio.ch.SocketChannelImpl.poll(SocketChannelImpl.java:954)
- locked <0x7fa140f520c0> (a java.lang.Object)
at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:110)
- locked <0x7fa140f520b0> (a java.lang.Object)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2950)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2681)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2568)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2429)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2393)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1590)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1659)
at 
org.apache.ignite.internal.processors.task.GridTaskWorker.cancelChildren(GridTaskWorker.java:1305)
at 
org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1609)
at 
org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1581)
at 
org.apache.ignite.internal.processors.task.GridTaskProcessor.onDisconnected(GridTaskProcessor.java:168)
at 
org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:3460)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:601)
at 
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2407)
at 
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2386)
at 
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1714)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
{code}
It looks like msg-worker is trying to send JOB_CANCEL message for each job with 
timeout equals failureDetectionTimeout.

Reproducer is attached.)

> Disconnected client node tries to send JOB_CANCEL message
> -
>
> Key: IGNITE-7944
> URL: https://issues.apache.org/jira/browse/IGNITE-7944
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.9, 2.3
>Reporter: Roman Guseinov
>Priority: Major
> Attachments: Reproducer7944.java
>
>




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

[jira] [Created] (IGNITE-7944) Disconnected client node tries to send JOB_CANCEL message

[Roman Guseinov (JIRA)]

Roman Guseinov created IGNITE-7944:
--

 Summary: Disconnected client node tries to send JOB_CANCEL message
 Key: IGNITE-7944
 URL: https://issues.apache.org/jira/browse/IGNITE-7944
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.3, 1.9
 Environment: In case the network is blocked (socket connections not 
closed) and failure is detected, tcp-client-disco-msg-worker thread can be 
stuck in process of TcpClient creating:
{code:java}
"tcp-client-disco-msg-worker-#4%wd5prsvtots0016a-tg-QueryFabric%" #494 prio=5 
os_prio=0 tid=0x7f94c067c800 nid=0x2bdf runnable [0x7f960ecf1000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.Net.poll(Native Method)
at sun.nio.ch.SocketChannelImpl.poll(SocketChannelImpl.java:954)
- locked <0x7fa140f520c0> (a java.lang.Object)
at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:110)
- locked <0x7fa140f520b0> (a java.lang.Object)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2950)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2681)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2568)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2429)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2393)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1590)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1659)
at 
org.apache.ignite.internal.processors.task.GridTaskWorker.cancelChildren(GridTaskWorker.java:1305)
at 
org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1609)
at 
org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1581)
at 
org.apache.ignite.internal.processors.task.GridTaskProcessor.onDisconnected(GridTaskProcessor.java:168)
at 
org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:3460)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:601)
at 
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2407)
at 
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2386)
at 
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1714)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
{code}
It looks like msg-worker is trying to send JOB_CANCEL message for each job with 
timeout equals failureDetectionTimeout.

Reproducer is attached.
Reporter: Roman Guseinov






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

[jira] [Commented] (IGNITE-7943) Node hangs on start after failing during checkpoint.

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7943:


Please note there is issue that indicates speed is very low for such case: 
https://issues.apache.org/jira/browse/IGNITE-7920

> Node hangs on start after failing during checkpoint. 
> -
>
> Key: IGNITE-7943
> URL: https://issues.apache.org/jira/browse/IGNITE-7943
> Project: Ignite
>  Issue Type: Bug
>Reporter: Oleg Ostanin
>Priority: Major
>
> Node can restart more than 20 minutes after failing in the middle of a 
> checkpoint.
>  



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

[jira] [Created] (IGNITE-7943) Node hangs on start after failing during checkpoint.

[Oleg Ostanin (JIRA)]

Oleg Ostanin created IGNITE-7943:


 Summary: Node hangs on start after failing during checkpoint. 
 Key: IGNITE-7943
 URL: https://issues.apache.org/jira/browse/IGNITE-7943
 Project: Ignite
  Issue Type: Bug
Reporter: Oleg Ostanin


Node can restart more than 20 minutes after failing in the middle of a 
checkpoint.

 



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

[jira] [Comment Edited] (IGNITE-4229) Loading configuration from XML into Web Console for further editing

[Ilya Borisov (JIRA)]

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

Ilya Borisov edited comment on IGNITE-4229 at 3/14/18 9:41 AM:
---

[~kuaw26] can you provide several examples of XML configurations? Also, please 
provide the minimal set of supported features we want to implement during this 
task.


was (Author: klaster_1):
[~kuaw26] can you provide several examples of XML configurations?

> Loading configuration from XML into Web Console for further editing
> ---
>
> Key: IGNITE-4229
> URL: https://issues.apache.org/jira/browse/IGNITE-4229
> Project: Ignite
>  Issue Type: Wish
>  Components: wizards
>Reporter: Alexandr Kuramshin
>Assignee: Ilya Borisov
>Priority: Minor
>  Labels: console
>
> It would be great to have ability of loading an external XML into Console as 
> the initial configuration and then get editing.
> At this point it's only allowed to create a configuration from scratch and 
> then export to the XML.



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

[jira] [Assigned] (IGNITE-4229) Loading configuration from XML into Web Console for further editing

[Ilya Borisov (JIRA)]

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

Ilya Borisov reassigned IGNITE-4229:


Assignee: Ilya Borisov  (was: Alexey Kuznetsov)

> Loading configuration from XML into Web Console for further editing
> ---
>
> Key: IGNITE-4229
> URL: https://issues.apache.org/jira/browse/IGNITE-4229
> Project: Ignite
>  Issue Type: Wish
>  Components: wizards
>Reporter: Alexandr Kuramshin
>Assignee: Ilya Borisov
>Priority: Minor
>  Labels: console
>
> It would be great to have ability of loading an external XML into Console as 
> the initial configuration and then get editing.
> At this point it's only allowed to create a configuration from scratch and 
> then export to the XML.



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

[jira] [Commented] (IGNITE-7253) JDBC thin driver: introduce streaming mode

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7253:


Github user asfgit closed the pull request at:

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


> JDBC thin driver: introduce streaming mode
> --
>
> Key: IGNITE-7253
> URL: https://issues.apache.org/jira/browse/IGNITE-7253
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Major
> Fix For: 2.5
>
> Attachments: IGNITE_7253.patch
>
>
> Should be done after IGNITE-6022. We should allow optional streaming mode for 
> JDBC driver. In this mode only INSERTs without SELECT should be possible. All 
> other DML operations should throw an exception. 
> Design considerations:
> 1) Add command {{SET STREAMING=1|ON|0|OFF}} which will enable or disable 
> streaming for connection.
> 2) Add command {{STREAMER FLUSH}} which will force data flush.
> 3) Only INSERT without SELECT works, all other DML statements should throw an 
> exception
> 4) It should be possible to stream into several tables simultaneously (i.e. 
> several streamers could be opened)
> 5) Any DDL statement should force flush of all currently opened streamers.



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

[jira] [Resolved] (IGNITE-7253) JDBC thin driver: introduce streaming mode

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-7253.
-
Resolution: Fixed

> JDBC thin driver: introduce streaming mode
> --
>
> Key: IGNITE-7253
> URL: https://issues.apache.org/jira/browse/IGNITE-7253
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Major
> Fix For: 2.5
>
> Attachments: IGNITE_7253.patch
>
>
> Should be done after IGNITE-6022. We should allow optional streaming mode for 
> JDBC driver. In this mode only INSERTs without SELECT should be possible. All 
> other DML operations should throw an exception. 
> Design considerations:
> 1) Add command {{SET STREAMING=1|ON|0|OFF}} which will enable or disable 
> streaming for connection.
> 2) Add command {{STREAMER FLUSH}} which will force data flush.
> 3) Only INSERT without SELECT works, all other DML statements should throw an 
> exception
> 4) It should be possible to stream into several tables simultaneously (i.e. 
> several streamers could be opened)
> 5) Any DDL statement should force flush of all currently opened streamers.



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

[jira] [Commented] (IGNITE-7831) Throw Exceptions instead of AssertionErrors when reading from corrupted persistence

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7831:


GitHub user alex-plekhanov opened a pull request:

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

IGNITE-7831 Throw Exceptions instead of AssertionErrors when reading from 
corrupted persistence



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

$ git pull https://github.com/alex-plekhanov/ignite ignite-7831

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

https://github.com/apache/ignite/pull/3630.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 #3630


commit 1698c15ce0d47d5fbb8dbc633fbf007fb5e7c0e3
Author: Aleksey Plekhanov 
Date:   2018-03-13T11:09:54Z

IGNITE-7831 Throw Exceptions instead of AssertionErrors when reading from 
corrupted persistence

commit 905a1a0065eb853f70e5bb86bb850c27707f4b8d
Author: Aleksey Plekhanov 
Date:   2018-03-13T11:46:10Z

IGNITE-7831 WIP

commit fd94878610d70697181e6ffcfe939073d8bc273f
Author: Aleksey Plekhanov 
Date:   2018-03-14T08:39:49Z

IGNITE-7831 WIP




> Throw Exceptions instead of AssertionErrors when reading from corrupted 
> persistence
> ---
>
> Key: IGNITE-7831
> URL: https://issues.apache.org/jira/browse/IGNITE-7831
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ilya Lantukh
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: iep-14
> Fix For: 2.5
>
>
> There are a few places in our code where we explicitly throw AssertionErrors 
> due to inability to correctly read data from persistence and many more places 
> where we make assertions based on read values.
> Assertions are used to indicate problems in internal logic, while persistence 
> might also get corrupted by various external reasons. It also makes uniform 
> handling of such issues considerably harder, because exception handling logic 
> in Ignite ignores Errors. If we want to improve stability and minimize 
> consequenses of pesistence corruption, we should replace all those 
> AssertionErrors and asserts with Exceptions, so that current exception 
> handling mechanisms could be reduce. In a number of situations it means that 
> instead of causing cluster-wide hang-up problematic node will be 
> automatically killed.



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

[jira] [Created] (IGNITE-7942) Document streaming in thin JDBC driver

[Alexander Paschenko (JIRA)]

Alexander Paschenko created IGNITE-7942:
---

 Summary: Document streaming in thin JDBC driver
 Key: IGNITE-7942
 URL: https://issues.apache.org/jira/browse/IGNITE-7942
 Project: Ignite
  Issue Type: Task
  Components: documentation, jdbc, sql
Reporter: Alexander Paschenko
 Fix For: 2.5






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

[jira] [Commented] (IGNITE-7421) Thin client Java API - data grid API

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-7421:
-

Comments on implementation:
6) {{ClientListenerNioListener.onHandshake}} - we should never rely on 
exception messages. Instead, special subclass should be created.
7) {{BinaryContext.metadata}} - let's use {{Collections.emptyList}} instead of 
{{new ArrayList<>()}}
8) {{SerDes}} - abbreviations are not allowed in class and method names. Let's 
rename it to {{ClientUtils}}.
9) {{SerDes}} - configuration serialization/deserialization is already 
implemented({{ClientCacheConfigurationSerializer}}). I think all we need is to 
implement converter from CacheConfiguration to ClientCacheConfiguration and 
vice versa.
10) {{ClientOperation}} and {{TcpClientCache}} - duplicates logic of 
{{ClientMessageParser}}. Let's simply add two new methods to decode response 
and encode request to this class, and remove all lambdas from 
{{TcpClientCache}} - we should not define the same format twice.
11) Looks like binary metadata handling is not implemented at all. Without it 
the client will not be able to understand how to deserialize objects. You 
should request this information from the server transparently (see .NET client 
for reference). Otherwise user will have to register all classes explicitly 
which is a huge usability issue.
12) {{ReliableChannel}} - I think it makes sense to randomize the very first 
picked {{primary}} address for every new connection. This way we will have a 
kind of sticky load balance. This is how we implement failover in JDBC and 
ODBC. 

> Thin client Java API - data grid API
> 
>
> Key: IGNITE-7421
> URL: https://issues.apache.org/jira/browse/IGNITE-7421
> Project: Ignite
>  Issue Type: New Feature
>  Components: thin client
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
>  Labels: data, java, thin
>
> Implement below Java bindings for the thin client protocol. The client 
> configuration must support failover and encryption.
> Cache
>      JCache (limited)
>          getName(): String
>          put(key, val)
>          get(key): V
>          getAll(keys: Set): Map
>          containsKey(key): boolean
>          getAndPut(key, val): V
>          getAndReplace(key, val): V
>          getAndRemove(key): V
>          putIfAbsent
>          replace(key, val)
>          replace(key, oldVal, newVal)
>          putAll
>          clear
>          remove(key)
>          remove(key, val)
>          removeAll()
>          removeAll(keys: Set)
>          getConfiguration(clazz): Configuration
>          close()
>      size(modes: CachePeekMode...)
>      query(qry: Query): QueryCursor
>      query(qry: SqlFieldsQuery): FieldsQueryCursor
>      withKeepBinary(): IgniteCache
>  Ignite
>      cache(name: String)
>      cacheNames(): Collection
>      binary(): IgniteBinary
>      createCache(name): Cache
>      getOrCreateCache(name): Cache
>      destroyCache(name)
>  Ignition
>      startClient(:ClientConfiguration): Ignite
>  ClientConfiguration(port, host, binaryConfiguration, sslConfiguration,
>  etc...)



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

[jira] [Commented] (IGNITE-4229) Loading configuration from XML into Web Console for further editing

[Ilya Borisov (JIRA)]

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

Ilya Borisov commented on IGNITE-4229:
--

[~kuaw26] can you provide several examples of XML configurations?

> Loading configuration from XML into Web Console for further editing
> ---
>
> Key: IGNITE-4229
> URL: https://issues.apache.org/jira/browse/IGNITE-4229
> Project: Ignite
>  Issue Type: Wish
>  Components: wizards
>Reporter: Alexandr Kuramshin
>Assignee: Alexey Kuznetsov
>Priority: Minor
>  Labels: console
>
> It would be great to have ability of loading an external XML into Console as 
> the initial configuration and then get editing.
> At this point it's only allowed to create a configuration from scratch and 
> then export to the XML.



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

[jira] [Commented] (IGNITE-3843) Web console: Not work basic validations.

[Ilya Borisov (JIRA)]

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

Ilya Borisov commented on IGNITE-3843:
--

[~kuaw26] please assign the correct status to the issue.

> Web console: Not work basic validations.
> 
>
> Key: IGNITE-3843
> URL: https://issues.apache.org/jira/browse/IGNITE-3843
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
>Priority: Major
>
> F.e. On cluster add empty Cache key configuration and try to save cluster.
> Also field with wrong value should be focused.



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

[jira] [Assigned] (IGNITE-3843) Web console: Not work basic validations.

[Ilya Borisov (JIRA)]

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

Ilya Borisov reassigned IGNITE-3843:


Assignee: Alexey Kuznetsov  (was: Ilya Borisov)

> Web console: Not work basic validations.
> 
>
> Key: IGNITE-3843
> URL: https://issues.apache.org/jira/browse/IGNITE-3843
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
>Priority: Major
>
> F.e. On cluster add empty Cache key configuration and try to save cluster.
> Also field with wrong value should be focused.



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

[jira] [Commented] (IGNITE-3843) Web console: Not work basic validations.

[Ilya Borisov (JIRA)]

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

Ilya Borisov commented on IGNITE-3843:
--

IGNITE-5466 does implement focus on invalid fields after form submit.

> Web console: Not work basic validations.
> 
>
> Key: IGNITE-3843
> URL: https://issues.apache.org/jira/browse/IGNITE-3843
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Vasiliy Sisko
>Assignee: Ilya Borisov
>Priority: Major
>
> F.e. On cluster add empty Cache key configuration and try to save cluster.
> Also field with wrong value should be focused.



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

[jira] [Assigned] (IGNITE-3843) Web console: Not work basic validations.

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-3843:


Assignee: Ilya Borisov  (was: Dmitriy Shabalin)

It seems that this issue is not actual any more?

As we completely reworked configuration in IGNITE-5466

> Web console: Not work basic validations.
> 
>
> Key: IGNITE-3843
> URL: https://issues.apache.org/jira/browse/IGNITE-3843
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Vasiliy Sisko
>Assignee: Ilya Borisov
>Priority: Major
>
> F.e. On cluster add empty Cache key configuration and try to save cluster.
> Also field with wrong value should be focused.



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

[jira] [Commented] (IGNITE-7421) Thin client Java API - data grid API

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-7421:
-

Last piece on public API:
1) {{SslProtocol}} - why do we need so many modes? General rule of thumb here - 
start from simple, then add more modes as needed. SSL is considered deprecated, 
I do not see why we need it in the first place.
2) {{ClientCacheConfiguration.qryEntities}} and {{keyCfg}} - I would avoid 
converting it to the list and back, this adds no value and exposes risk of NPE 
(e.g. if user is to call {{setQueryEntity(null)}}, he may receive an exception. 
This might be especially severe in frameworks like Spring.
3) {{ClientConfiguration.setAddresses}} - there should be no validation in 
config classes. This is just a container of properties. We should validate it 
only during client start. Also it is better to set {{addrs}} to {{null}}.
4) {{ClientConfiguration.tcpNoDelay}} - should be {{setTcpNoDelay}}.
5) {{SslProtocol}}, {{ClientCacheConfiguration}}, {{ClientConfiguration}} - 
here is no need to implement {{equals}} and {{hashCode}}. Normally we do not do 
this for configurations because some configuration objects might be stateful 
and we never use them in set structures. Boilerplate is another reason.

> Thin client Java API - data grid API
> 
>
> Key: IGNITE-7421
> URL: https://issues.apache.org/jira/browse/IGNITE-7421
> Project: Ignite
>  Issue Type: New Feature
>  Components: thin client
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
>  Labels: data, java, thin
>
> Implement below Java bindings for the thin client protocol. The client 
> configuration must support failover and encryption.
> Cache
>      JCache (limited)
>          getName(): String
>          put(key, val)
>          get(key): V
>          getAll(keys: Set): Map
>          containsKey(key): boolean
>          getAndPut(key, val): V
>          getAndReplace(key, val): V
>          getAndRemove(key): V
>          putIfAbsent
>          replace(key, val)
>          replace(key, oldVal, newVal)
>          putAll
>          clear
>          remove(key)
>          remove(key, val)
>          removeAll()
>          removeAll(keys: Set)
>          getConfiguration(clazz): Configuration
>          close()
>      size(modes: CachePeekMode...)
>      query(qry: Query): QueryCursor
>      query(qry: SqlFieldsQuery): FieldsQueryCursor
>      withKeepBinary(): IgniteCache
>  Ignite
>      cache(name: String)
>      cacheNames(): Collection
>      binary(): IgniteBinary
>      createCache(name): Cache
>      getOrCreateCache(name): Cache
>      destroyCache(name)
>  Ignition
>      startClient(:ClientConfiguration): Ignite
>  ClientConfiguration(port, host, binaryConfiguration, sslConfiguration,
>  etc...)



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

[jira] [Commented] (IGNITE-7421) Thin client Java API - data grid API

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-7421:
-

[~kukushal], our product has the following conventions regarding exceptions:
- user API never throw checked exceptions
- user API must always throw subclass of {{IgniteException}}
- checked exceptions are only used in private API and should be a sublass of 
{{IgniteCheckedException}}
- we do not have specific exception type for configuration exceptions

That said, correct public API should be:
1) {{ClientException extends IgniteException}}
2) {{ClientConnectionException extends ClientException}}
3) {{ClientAuthenticationException extends ClientException}}
4) {{ClientConfigurationException}} - remove

> Thin client Java API - data grid API
> 
>
> Key: IGNITE-7421
> URL: https://issues.apache.org/jira/browse/IGNITE-7421
> Project: Ignite
>  Issue Type: New Feature
>  Components: thin client
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
>  Labels: data, java, thin
>
> Implement below Java bindings for the thin client protocol. The client 
> configuration must support failover and encryption.
> Cache
>      JCache (limited)
>          getName(): String
>          put(key, val)
>          get(key): V
>          getAll(keys: Set): Map
>          containsKey(key): boolean
>          getAndPut(key, val): V
>          getAndReplace(key, val): V
>          getAndRemove(key): V
>          putIfAbsent
>          replace(key, val)
>          replace(key, oldVal, newVal)
>          putAll
>          clear
>          remove(key)
>          remove(key, val)
>          removeAll()
>          removeAll(keys: Set)
>          getConfiguration(clazz): Configuration
>          close()
>      size(modes: CachePeekMode...)
>      query(qry: Query): QueryCursor
>      query(qry: SqlFieldsQuery): FieldsQueryCursor
>      withKeepBinary(): IgniteCache
>  Ignite
>      cache(name: String)
>      cacheNames(): Collection
>      binary(): IgniteBinary
>      createCache(name): Cache
>      getOrCreateCache(name): Cache
>      destroyCache(name)
>  Ignition
>      startClient(:ClientConfiguration): Ignite
>  ClientConfiguration(port, host, binaryConfiguration, sslConfiguration,
>  etc...)



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