[jira] [Updated] (IGNITE-10640) Create cluster-wide MetaStorage analogue

2019-01-09 Thread Ivan Bessonov (JIRA) 


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

Ivan Bessonov updated IGNITE-10640:
---
Labels: IEP-4 Phase-2  (was: )

> Create cluster-wide MetaStorage analogue
> 
>
> Key: IGNITE-10640
> URL: https://issues.apache.org/jira/browse/IGNITE-10640
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
>  Labels: IEP-4, Phase-2
>
> Issues like IGNITE-8571 require the ability to store and update some 
> properties consistently on the whole cluster. It is proposed to implement 
> generic way of doing this. Main requirements are:
>  * read / write / delete;
>  * surviving node / cluster restart;
>  * consistency;
>  * ability to add listeners on changing properties.
> First implementation is going to be based on local MetaStorage to guarantee 
> data persistence. Existing MetaStorage API is a subject to change as well.



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

[jira] [Assigned] (IGNITE-10756) MVCC: Query trackers are not released sometimes

2019-01-09 Thread Roman Kondakov (JIRA) 


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

Roman Kondakov reassigned IGNITE-10756:
---

Assignee: Roman Kondakov

> MVCC: Query trackers are not released sometimes 
> 
>
> Key: IGNITE-10756
> URL: https://issues.apache.org/jira/browse/IGNITE-10756
> Project: Ignite
>  Issue Type: Bug
>  Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
>  Labels: CQ, MakeTeamcityGreenAgain, mvcc_stabilization_stage_1, 
> transactions
> Fix For: 2.8
>
>
> Sometimes query trackers are not released when error occurs during iterating 
> over {{QueryCursor}}. It may be already fixed in IGNITE-10448. Need to check.
> Affected tests:
> * {{CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedPartitioned}}



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

[jira] [Assigned] (IGNITE-10768) MVCC: CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned may hang

2019-01-09 Thread Roman Kondakov (JIRA) 


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

Roman Kondakov reassigned IGNITE-10768:
---

Assignee: (was: Roman Kondakov)

> MVCC: 
> CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned
>  may hang
> -
>
> Key: IGNITE-10768
> URL: https://issues.apache.org/jira/browse/IGNITE-10768
> Project: Ignite
>  Issue Type: Bug
>  Components: mvcc
>Reporter: Roman Kondakov
>Priority: Major
>  Labels: CQ, mvcc_stabilization_stage_1
> Fix For: 2.8
>
>
> Test 
> {{CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned}}
>  may hang sometimes.
>  
> {noformat}
> Thread [name="test-runner-#209301%mvcc.CacheMvccBasicContinuousQueryTest%", 
> id=228123, state=WAITING, blockCnt=5, waitCnt=89]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:179)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:142)
> at 
> o.a.i.i.processors.cache.mvcc.CacheMvccBasicContinuousQueryTest.checkUpdateCountersGapIsProcessedSimple(CacheMvccBasicContinuousQueryTest.java:346)
> at 
> o.a.i.i.processors.cache.mvcc.CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned(CacheMvccBasicContinuousQueryTest.java:257)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at 
> o.a.i.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2121)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}



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

[jira] [Assigned] (IGNITE-10768) MVCC: CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned may hang

2019-01-09 Thread Roman Kondakov (JIRA) 


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

Roman Kondakov reassigned IGNITE-10768:
---

Assignee: Roman Kondakov

> MVCC: 
> CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned
>  may hang
> -
>
> Key: IGNITE-10768
> URL: https://issues.apache.org/jira/browse/IGNITE-10768
> Project: Ignite
>  Issue Type: Bug
>  Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
>  Labels: CQ, mvcc_stabilization_stage_1
> Fix For: 2.8
>
>
> Test 
> {{CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned}}
>  may hang sometimes.
>  
> {noformat}
> Thread [name="test-runner-#209301%mvcc.CacheMvccBasicContinuousQueryTest%", 
> id=228123, state=WAITING, blockCnt=5, waitCnt=89]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:179)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:142)
> at 
> o.a.i.i.processors.cache.mvcc.CacheMvccBasicContinuousQueryTest.checkUpdateCountersGapIsProcessedSimple(CacheMvccBasicContinuousQueryTest.java:346)
> at 
> o.a.i.i.processors.cache.mvcc.CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned(CacheMvccBasicContinuousQueryTest.java:257)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at 
> o.a.i.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2121)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}



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

[jira] [Commented] (IGNITE-10873) CorruptedTreeException during simultaneous cache put operations

2019-01-09 Thread Alexey Goncharuk (JIRA) 


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

Alexey Goncharuk commented on IGNITE-10873:
---

Need to look into on-heap cache. If on-heap cache is disabled, then reproducer 
passes, otherwise "Duplicate row in index" error occurs.

> CorruptedTreeException during simultaneous cache put operations
> ---
>
> Key: IGNITE-10873
> URL: https://issues.apache.org/jira/browse/IGNITE-10873
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, persistence, sql
>Affects Versions: 2.7
>Reporter: Pavel Vinokurov
>Priority: Critical
>
> {code}
> [2019-01-09 20:47:04,376][ERROR][pool-9-thread-9][GridDhtAtomicCache]  
> Unexpected exception during cache update
> org.h2.message.DbException: General error: "class 
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
>  Runtime failure on row: Row@780acfb4[ key: .. ][ GTEST, null, 254, null, 
> null, null, null, 0, null, null, null, null, null, null, null, 0, 0, 0, null, 
> 0, 0, 0, 0, 0, 0, 0, null, 0, 0, null, 0, null, 0, null, 0, null, null, null, 
> 0, 0, 0, 0, 0, 0, null, null, null, null, null, null, null, 0.0, 0, 0.0, 0, 
> 0.0, 0, null, 0, 0, 0, 0, null, null, null, null, null, null, null, null, 
> null, null, null, null, null, null, null, null ]" [5-197]
>   at org.h2.message.DbException.get(DbException.java:168)
>   at org.h2.message.DbException.convert(DbException.java:307)
>   at 
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:302)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.addToIndex(GridH2Table.java:546)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:479)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:768)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1905)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:404)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:2633)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1646)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1621)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1935)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:428)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2295)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2494)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1951)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1780)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1668)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1153)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:611)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2449)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2426)

[jira] [Updated] (IGNITE-10877) GridAffinityAssignment.initPrimaryBackupMaps memory pressure

2019-01-09 Thread Pavel Voronkin (JIRA) 


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

Pavel Voronkin updated IGNITE-10877:

Description: 
Whie running tests with JFR we observe huge memory allocation pressure produced 
by:

*Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)*

java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784 100
 java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044 
784 100
 java.util.HashMap.put(Object, Object) 481 298 044 784 100
 java.util.HashSet.add(Object) 480 297 221 040 99,724
 
org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps()
 1 823 744 0,276

org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion,
 List, List) 1 823 744 0,276

*Allocation stats*

Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB 
Size(bytes) Total TLAB Size(bytes) Pressure(%)
 java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876
 java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687
 java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864 
11,341
 java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654
 java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198

 

I think we need to improve memory efficiency by switching from from Sets to 
BitSets

 

JFR attached

 

 

 

  was:
Whie running tests with JFR we observe huge memory allocation pressure produced 
by:

*Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)*

java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784 100
 java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044 
784 100
 java.util.HashMap.put(Object, Object) 481 298 044 784 100
 java.util.HashSet.add(Object) 480 297 221 040 99,724
 
org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps()
 1 823 744 0,276

org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion,
 List, List) 1 823 744 0,276

*Allocation stats*

Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB 
Size(bytes) Total TLAB Size(bytes) Pressure(%)
java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876
java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687
java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864 11,341
java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654
java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198

 

I think we need to improve memory efficiency by switching from from Sets to 
BitSets

 

 

 


> GridAffinityAssignment.initPrimaryBackupMaps memory pressure
> 
>
> Key: IGNITE-10877
> URL: https://issues.apache.org/jira/browse/IGNITE-10877
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Voronkin
>Priority: Major
> Attachments: grid.srv.node.1.0-29.12.2018-12.50.15.jfr
>
>
> Whie running tests with JFR we observe huge memory allocation pressure 
> produced by:
> *Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)*
> java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784 
> 100
>  java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044 
> 784 100
>  java.util.HashMap.put(Object, Object) 481 298 044 784 100
>  java.util.HashSet.add(Object) 480 297 221 040 99,724
>  
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps()
>  1 823 744 0,276
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion,
>  List, List) 1 823 744 0,276
> *Allocation stats*
> Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB 
> Size(bytes) Total TLAB Size(bytes) Pressure(%)
>  java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876
>  java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687
>  java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864 
> 11,341
>  java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654
>  java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198
>  
> I think we need to improve memory efficiency by switching from from Sets to 
> BitSets
>  
> JFR attached
>  
>  
>  



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

[jira] [Updated] (IGNITE-10877) GridAffinityAssignment.initPrimaryBackupMaps memory pressure

2019-01-09 Thread Pavel Voronkin (JIRA) 


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

Pavel Voronkin updated IGNITE-10877:

Description: 
Whie running tests with JFR we observe huge memory allocation pressure produced 
by:

*Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)*

java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784 100
 java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044 
784 100
 java.util.HashMap.put(Object, Object) 481 298 044 784 100
 java.util.HashSet.add(Object) 480 297 221 040 99,724
 
org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps()
 1 823 744 0,276

org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion,
 List, List) 1 823 744 0,276

*Allocation stats*

Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB 
Size(bytes) Total TLAB Size(bytes) Pressure(%)
 java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876
 java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687
 java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864 
11,341
 java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654
 java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198

 

I think we need to improve memory efficiency by switching from from Sets to 
BitSets

 

JFR attached, see Allocations in 12:50:28 - 12:50:29

 

 

 

  was:
Whie running tests with JFR we observe huge memory allocation pressure produced 
by:

*Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)*

java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784 100
 java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044 
784 100
 java.util.HashMap.put(Object, Object) 481 298 044 784 100
 java.util.HashSet.add(Object) 480 297 221 040 99,724
 
org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps()
 1 823 744 0,276

org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion,
 List, List) 1 823 744 0,276

*Allocation stats*

Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB 
Size(bytes) Total TLAB Size(bytes) Pressure(%)
 java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876
 java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687
 java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864 
11,341
 java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654
 java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198

 

I think we need to improve memory efficiency by switching from from Sets to 
BitSets

 

JFR attached

 

 

 


> GridAffinityAssignment.initPrimaryBackupMaps memory pressure
> 
>
> Key: IGNITE-10877
> URL: https://issues.apache.org/jira/browse/IGNITE-10877
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Voronkin
>Priority: Major
> Attachments: grid.srv.node.1.0-29.12.2018-12.50.15.jfr
>
>
> Whie running tests with JFR we observe huge memory allocation pressure 
> produced by:
> *Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)*
> java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784 
> 100
>  java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044 
> 784 100
>  java.util.HashMap.put(Object, Object) 481 298 044 784 100
>  java.util.HashSet.add(Object) 480 297 221 040 99,724
>  
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps()
>  1 823 744 0,276
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion,
>  List, List) 1 823 744 0,276
> *Allocation stats*
> Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB 
> Size(bytes) Total TLAB Size(bytes) Pressure(%)
>  java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876
>  java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687
>  java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864 
> 11,341
>  java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654
>  java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198
>  
> I think we need to improve memory efficiency by switching from from Sets to 
> BitSets
>  
> JFR attached, see Allocations in 12:50:28 - 12:50:29
>  
>  
>  



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

[jira] [Updated] (IGNITE-10877) GridAffinityAssignment.initPrimaryBackupMaps memory pressure

2019-01-09 Thread Pavel Voronkin (JIRA) 


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

Pavel Voronkin updated IGNITE-10877:

Attachment: grid.srv.node.1.0-29.12.2018-12.50.15.jfr

> GridAffinityAssignment.initPrimaryBackupMaps memory pressure
> 
>
> Key: IGNITE-10877
> URL: https://issues.apache.org/jira/browse/IGNITE-10877
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Voronkin
>Priority: Major
> Attachments: grid.srv.node.1.0-29.12.2018-12.50.15.jfr
>
>
> Whie running tests with JFR we observe huge memory allocation pressure 
> produced by:
> *Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)*
> java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784 
> 100
>  java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044 
> 784 100
>  java.util.HashMap.put(Object, Object) 481 298 044 784 100
>  java.util.HashSet.add(Object) 480 297 221 040 99,724
>  
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps()
>  1 823 744 0,276
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion,
>  List, List) 1 823 744 0,276
> *Allocation stats*
> Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB 
> Size(bytes) Total TLAB Size(bytes) Pressure(%)
>  java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876
>  java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687
>  java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864 
> 11,341
>  java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654
>  java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198
>  
> I think we need to improve memory efficiency by switching from from Sets to 
> BitSets
>  
> JFR attached
>  
>  
>  



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

[jira] [Assigned] (IGNITE-10363) Web console: unexpected unsaved changes confirmation

2019-01-09 Thread Pavel Konstantinov (JIRA) 


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

Pavel Konstantinov reassigned IGNITE-10363:
---

Assignee: Vasiliy Sisko  (was: Pavel Konstantinov)

> Web console: unexpected unsaved changes confirmation
> 
>
> Key: IGNITE-10363
> URL: https://issues.apache.org/jira/browse/IGNITE-10363
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Vasiliy Sisko
>Priority: Major
> Attachments: image-2018-11-21-17-33-17-545.png
>
>
> # create a new cluster
> # do not save
> # click Import form DB
> # go through all steps
> # Save
>  !image-2018-11-21-17-33-17-545.png! 
> To prevent this situation we should check unsaved changes before starting the 
> import.



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

[jira] [Commented] (IGNITE-10363) Web console: unexpected unsaved changes confirmation

2019-01-09 Thread Pavel Konstantinov (JIRA) 


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

Pavel Konstantinov commented on IGNITE-10363:
-

I was able to reproduce on the master. Please fix.

> Web console: unexpected unsaved changes confirmation
> 
>
> Key: IGNITE-10363
> URL: https://issues.apache.org/jira/browse/IGNITE-10363
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Major
> Attachments: image-2018-11-21-17-33-17-545.png
>
>
> # create a new cluster
> # do not save
> # click Import form DB
> # go through all steps
> # Save
>  !image-2018-11-21-17-33-17-545.png! 
> To prevent this situation we should check unsaved changes before starting the 
> import.



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

[jira] [Updated] (IGNITE-10877) GridAffinityAssignment.initPrimaryBackupMaps memory pressure

2019-01-09 Thread Pavel Voronkin (JIRA) 


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

Pavel Voronkin updated IGNITE-10877:

Description: 
Whie running tests with JFR we observe huge memory allocation pressure produced 
by:

*Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)*

java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784 100
 java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044 
784 100
 java.util.HashMap.put(Object, Object) 481 298 044 784 100
 java.util.HashSet.add(Object) 480 297 221 040 99,724
 
org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps()
 1 823 744 0,276

org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion,
 List, List) 1 823 744 0,276

*Allocation stats*

Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB 
Size(bytes) Total TLAB Size(bytes) Pressure(%)
java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876
java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687
java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864 11,341
java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654
java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198

 

I think we need to improve memory efficiency by switching from from Sets to 
BitSets

 

 

 

> GridAffinityAssignment.initPrimaryBackupMaps memory pressure
> 
>
> Key: IGNITE-10877
> URL: https://issues.apache.org/jira/browse/IGNITE-10877
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Voronkin
>Priority: Major
>
> Whie running tests with JFR we observe huge memory allocation pressure 
> produced by:
> *Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)*
> java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784 
> 100
>  java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044 
> 784 100
>  java.util.HashMap.put(Object, Object) 481 298 044 784 100
>  java.util.HashSet.add(Object) 480 297 221 040 99,724
>  
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps()
>  1 823 744 0,276
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion,
>  List, List) 1 823 744 0,276
> *Allocation stats*
> Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB 
> Size(bytes) Total TLAB Size(bytes) Pressure(%)
> java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876
> java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687
> java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864 
> 11,341
> java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654
> java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198
>  
> I think we need to improve memory efficiency by switching from from Sets to 
> BitSets
>  
>  
>  



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

[jira] [Created] (IGNITE-10877) GridAffinityAssignment.initPrimaryBackupMaps memory pressure

2019-01-09 Thread Pavel Voronkin (JIRA) 
Pavel Voronkin created IGNITE-10877:
---

 Summary: GridAffinityAssignment.initPrimaryBackupMaps memory 
pressure
 Key: IGNITE-10877
 URL: https://issues.apache.org/jira/browse/IGNITE-10877
 Project: Ignite
  Issue Type: Improvement
Reporter: Pavel Voronkin






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

[jira] [Updated] (IGNITE-10876) "Affinity changes (coordinator) applied" can be executed in parallel

2019-01-09 Thread Pavel Voronkin (JIRA) 


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

Pavel Voronkin updated IGNITE-10876:

Summary: "Affinity changes (coordinator) applied" can be executed in 
parallel  (was: "Affinity changes (coordinator) applied" can be executed in 
parallel execution)

> "Affinity changes (coordinator) applied" can be executed in parallel
> 
>
> Key: IGNITE-10876
> URL: https://issues.apache.org/jira/browse/IGNITE-10876
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Voronkin
>Priority: Major
>
> There is for loop over all cache groups which execution N*P operations in 
> exchange worker where N is number of cache groups, P is number of partitions.
> We spend 80% of time in a loop
> for (CacheGroupContext grp : cctx.cache().cacheGroups()) {
> GridDhtPartitionTopology top = grp != null
>  ? grp.topology()
>  : cctx.exchange().clientTopology(grp.groupId(), events().discoveryCache());
>  top.beforeExchange(this, true, true);
> }
>  
> I believe we can execute it in parallel



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

[jira] [Updated] (IGNITE-10876) "Affinity changes (coordinator) applied" can be executed in parallel

2019-01-09 Thread Pavel Voronkin (JIRA) 


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

Pavel Voronkin updated IGNITE-10876:

Description: 
There is for loop over all cache groups which execution N*P operations in 
exchange worker where N is number of cache groups, P is number of partitions.

We spend 80% of time in a loop

for (CacheGroupContext grp : cctx.cache().cacheGroups()){

GridDhtPartitionTopology top = grp != null ? grp.topology() : 
cctx.exchange().clientTopology(grp.groupId(), events().discoveryCache());

top.beforeExchange(this, true, true);

} 

I believe we can execute it in parallel

  was:
There is for loop over all cache groups which execution N*P operations in 
exchange worker where N is number of cache groups, P is number of partitions.

We spend 80% of time in a loop

for (CacheGroupContext grp : cctx.cache().cacheGroups()) {
GridDhtPartitionTopology top = grp != null
 ? grp.topology()
 : cctx.exchange().clientTopology(grp.groupId(), events().discoveryCache());

 top.beforeExchange(this, true, true);
}

 

I believe we can execute it in parallel


> "Affinity changes (coordinator) applied" can be executed in parallel
> 
>
> Key: IGNITE-10876
> URL: https://issues.apache.org/jira/browse/IGNITE-10876
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Voronkin
>Priority: Major
>
> There is for loop over all cache groups which execution N*P operations in 
> exchange worker where N is number of cache groups, P is number of partitions.
> We spend 80% of time in a loop
> for (CacheGroupContext grp : cctx.cache().cacheGroups()){
> GridDhtPartitionTopology top = grp != null ? grp.topology() : 
> cctx.exchange().clientTopology(grp.groupId(), events().discoveryCache());
> top.beforeExchange(this, true, true);
> } 
> I believe we can execute it in parallel



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

[jira] [Updated] (IGNITE-10876) "Affinity changes (coordinator) applied" can be executed in parallel execution

2019-01-09 Thread Pavel Voronkin (JIRA) 


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

Pavel Voronkin updated IGNITE-10876:

Description: 
There is for loop over all cache groups which execution N*P operations in 
exchange worker where N is number of cache groups, P is number of partitions.

We spend 80% of time in a loop

for (CacheGroupContext grp : cctx.cache().cacheGroups()) {
GridDhtPartitionTopology top = grp != null
 ? grp.topology()
 : cctx.exchange().clientTopology(grp.groupId(), events().discoveryCache());

 top.beforeExchange(this, true, true);
}

 

I believe we can execute it in parallel

  was:
There is for loop over all cache groups which execution N*P operations in 
exchange worker where N is number of cache groups, P is number of partitions.

We spend 


> "Affinity changes (coordinator) applied" can be executed in parallel execution
> --
>
> Key: IGNITE-10876
> URL: https://issues.apache.org/jira/browse/IGNITE-10876
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Voronkin
>Priority: Major
>
> There is for loop over all cache groups which execution N*P operations in 
> exchange worker where N is number of cache groups, P is number of partitions.
> We spend 80% of time in a loop
> for (CacheGroupContext grp : cctx.cache().cacheGroups()) {
> GridDhtPartitionTopology top = grp != null
>  ? grp.topology()
>  : cctx.exchange().clientTopology(grp.groupId(), events().discoveryCache());
>  top.beforeExchange(this, true, true);
> }
>  
> I believe we can execute it in parallel



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

[jira] [Commented] (IGNITE-10778) MVCC: Invoke request may hang sometimes

2019-01-09 Thread Roman Kondakov (JIRA) 


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

Roman Kondakov commented on IGNITE-10778:
-

[~gvvinblade], I've replaced test iterations count with a fixed test time 
interval. TC run looks good (Mvcc/Cache4 suites). Please review,

> MVCC: Invoke request may hang sometimes
> ---
>
> Key: IGNITE-10778
> URL: https://issues.apache.org/jira/browse/IGNITE-10778
> Project: Ignite
>  Issue Type: Bug
>  Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
>  Labels: Hanging, mvcc_stabilization_stage_1
> Fix For: 2.8
>
>
> Invoke request may hang sometimes. Reproducer: 
> {{GridCacheMultinodeUpdateSelfTest.testInvoke}} with enabled MVCC.
> Stacktrace:
> {noformat}
> Thread [name="invoke-3", id=447, state=WAITING, blockCnt=0, waitCnt=1745]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at 
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.rollback(GridNearTxLocal.java:3792)
> at 
> o.a.i.i.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4256)
> at 
> o.a.i.i.processors.cache.GridCacheAdapter.invoke0(GridCacheAdapter.java:2608)
> at 
> o.a.i.i.processors.cache.GridCacheAdapter.invoke(GridCacheAdapter.java:2586)
> at 
> o.a.i.i.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1437)
> at 
> o.a.i.i.processors.cache.GatewayProtectedCacheProxy.invoke(GatewayProtectedCacheProxy.java:1204)
> at 
> o.a.i.i.processors.cache.GridCacheMultinodeUpdateAbstractSelfTest$1.call(GridCacheMultinodeUpdateAbstractSelfTest.java:111)
> at 
> o.a.i.i.processors.cache.GridCacheMultinodeUpdateAbstractSelfTest$1.call(GridCacheMultinodeUpdateAbstractSelfTest.java:100)
> at o.a.i.testframework.GridTestThread.run(GridTestThread.java:84)
> Thread [name="invoke-2", id=446, state=WAITING, blockCnt=0, waitCnt=1738]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at 
> o.a.i.i.processors.cache.mvcc.MvccUtils.requestSnapshot(MvccUtils.java:841)
> at 
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.mvccPutAllAsync0(GridNearTxLocal.java:723)
> at 
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.putAsync0(GridNearTxLocal.java:578)
> at 
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.invokeAsync(GridNearTxLocal.java:467)
> at 
> o.a.i.i.processors.cache.GridCacheAdapter$25.op(GridCacheAdapter.java:2620)
> at 
> o.a.i.i.processors.cache.GridCacheAdapter$25.op(GridCacheAdapter.java:2608)
> at 
> o.a.i.i.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4244)
> at 
> o.a.i.i.processors.cache.GridCacheAdapter.invoke0(GridCacheAdapter.java:2608)
> at 
> o.a.i.i.processors.cache.GridCacheAdapter.invoke(GridCacheAdapter.java:2586)
> at 
> o.a.i.i.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1437)
> at 
> o.a.i.i.processors.cache.GatewayProtectedCacheProxy.invoke(GatewayProtectedCacheProxy.java:1204)
> at 
> o.a.i.i.processors.cache.GridCacheMultinodeUpdateAbstractSelfTest$1.call(GridCacheMultinodeUpdateAbstractSelfTest.java:111)
> at 
> o.a.i.i.processors.cache.GridCacheMultinodeUpdateAbstractSelfTest$1.call(GridCacheMultinodeUpdateAbstractSelfTest.java:100)
> at o.a.i.testframework.GridTestThread.run(GridTestThread.java:84)
> Thread [name="invoke-1", id=445, state=WAITING, blockCnt=0, waitCnt=1916]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at 
> o.a.i.i.processors.cache.GridCacheAdapter$25.op(GridCacheAdapter.java:2626)
> at 
> o.a.i.i.processors.cache.GridCacheAdapter$25.op(GridCacheAdapter.java:2608)
> at 
> o.a.i.i.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4244)
> at 
> o.a.i.i.processors.cache.GridCacheAdapter.invoke0(GridCacheAdapter.java:2608)
> at 
>

[jira] [Updated] (IGNITE-10876) "Affinity changes (coordinator) applied" can be executed in parallel execution

2019-01-09 Thread Pavel Voronkin (JIRA) 


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

Pavel Voronkin updated IGNITE-10876:

Summary: "Affinity changes (coordinator) applied" can be executed in 
parallel execution  (was: Affinity changes (coordinator) applied can be 
executed in parallel execution)

> "Affinity changes (coordinator) applied" can be executed in parallel execution
> --
>
> Key: IGNITE-10876
> URL: https://issues.apache.org/jira/browse/IGNITE-10876
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Voronkin
>Priority: Major
>
> There is for loop over all cache groups which execution N*P operations in 
> exchange worker where N is number of cache groups, P is number of partitions.
> We spend 



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

[jira] [Updated] (IGNITE-10876) Affinity changes (coordinator) applied can be executed in parallel execution

2019-01-09 Thread Pavel Voronkin (JIRA) 


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

Pavel Voronkin updated IGNITE-10876:

Summary: Affinity changes (coordinator) applied can be executed in parallel 
execution  (was: finishExchangeOnCoordinator() parallel execution)

> Affinity changes (coordinator) applied can be executed in parallel execution
> 
>
> Key: IGNITE-10876
> URL: https://issues.apache.org/jira/browse/IGNITE-10876
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Voronkin
>Priority: Major
>
> There is for loop over all cache groups which execution N*P operations in 
> exchange worker where N is number of cache groups, P is number of partitions.
> We spend 



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

[jira] [Updated] (IGNITE-10876) finishExchangeOnCoordinator() parallel execution

2019-01-09 Thread Pavel Voronkin (JIRA) 


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

Pavel Voronkin updated IGNITE-10876:

Description: 
There is for loop over all cache groups which execution N*P operations in 
exchange worker where N is number of cache groups, P is number of partitions.

We spend 

> finishExchangeOnCoordinator() parallel execution
> 
>
> Key: IGNITE-10876
> URL: https://issues.apache.org/jira/browse/IGNITE-10876
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Voronkin
>Priority: Major
>
> There is for loop over all cache groups which execution N*P operations in 
> exchange worker where N is number of cache groups, P is number of partitions.
> We spend 



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

[jira] [Updated] (IGNITE-10876) finishExchangeOnCoordinator() parallel execution

2019-01-09 Thread Pavel Voronkin (JIRA) 


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

Pavel Voronkin updated IGNITE-10876:

Summary: finishExchangeOnCoordinator() parallel execution  (was: 
finishExchangeOnCoordinator() parallel execurtion)

> finishExchangeOnCoordinator() parallel execution
> 
>
> Key: IGNITE-10876
> URL: https://issues.apache.org/jira/browse/IGNITE-10876
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Voronkin
>Priority: Major
>




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

[jira] [Created] (IGNITE-10876) finishExchangeOnCoordinator parallelization

2019-01-09 Thread Pavel Voronkin (JIRA) 
Pavel Voronkin created IGNITE-10876:
---

 Summary: finishExchangeOnCoordinator parallelization
 Key: IGNITE-10876
 URL: https://issues.apache.org/jira/browse/IGNITE-10876
 Project: Ignite
  Issue Type: Improvement
Reporter: Pavel Voronkin






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

[jira] [Updated] (IGNITE-10876) finishExchangeOnCoordinator() parallel execurtion

2019-01-09 Thread Pavel Voronkin (JIRA) 


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

Pavel Voronkin updated IGNITE-10876:

Summary: finishExchangeOnCoordinator() parallel execurtion  (was: 
finishExchangeOnCoordinator parallelization)

> finishExchangeOnCoordinator() parallel execurtion
> -
>
> Key: IGNITE-10876
> URL: https://issues.apache.org/jira/browse/IGNITE-10876
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Voronkin
>Priority: Major
>




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

[jira] [Closed] (IGNITE-10875) Web Console: Update tooltip

2019-01-09 Thread Alexey Kuznetsov (JIRA) 


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

Alexey Kuznetsov closed IGNITE-10875.
-

> Web Console: Update tooltip
> ---
>
> Key: IGNITE-10875
> URL: https://issues.apache.org/jira/browse/IGNITE-10875
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> Old: This setting is needed to hide and show tooltips with hints.
> New: Use this setting to hide or show tooltips with hints.



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

[jira] [Resolved] (IGNITE-10875) Web Console: Update tooltip

2019-01-09 Thread Alexey Kuznetsov (JIRA) 


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

Alexey Kuznetsov resolved IGNITE-10875.
---
Resolution: Fixed

Merged to master.

> Web Console: Update tooltip
> ---
>
> Key: IGNITE-10875
> URL: https://issues.apache.org/jira/browse/IGNITE-10875
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> Old: This setting is needed to hide and show tooltips with hints.
> New: Use this setting to hide or show tooltips with hints.



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

[jira] [Updated] (IGNITE-10875) Web Console: Update tooltip

2019-01-09 Thread Alexey Kuznetsov (JIRA) 


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

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

> Web Console: Update tooltip
> ---
>
> Key: IGNITE-10875
> URL: https://issues.apache.org/jira/browse/IGNITE-10875
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> Old: This setting is needed to hide and show tooltips with hints.
> New: Use this setting to hide or show tooltips with hints.



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

[jira] [Updated] (IGNITE-10875) Web Console: Update tooltip

2019-01-09 Thread Alexey Kuznetsov (JIRA) 


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

Alexey Kuznetsov updated IGNITE-10875:
--
Fix Version/s: 2.8

> Web Console: Update tooltip
> ---
>
> Key: IGNITE-10875
> URL: https://issues.apache.org/jira/browse/IGNITE-10875
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> Old: This setting is needed to hide and show tooltips with hints.
> New: Use this setting to hide or show tooltips with hints.



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

[jira] [Assigned] (IGNITE-10875) Web Console: Update tooltip

2019-01-09 Thread Alexey Kuznetsov (JIRA) 


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

Alexey Kuznetsov reassigned IGNITE-10875:
-

Assignee: Alexey Kuznetsov

> Web Console: Update tooltip
> ---
>
> Key: IGNITE-10875
> URL: https://issues.apache.org/jira/browse/IGNITE-10875
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
>
> Old: This setting is needed to hide and show tooltips with hints.
> New: Use this setting to hide or show tooltips with hints.



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

[jira] [Created] (IGNITE-10875) Web Console: Update tooltip

2019-01-09 Thread Alexey Kuznetsov (JIRA) 
Alexey Kuznetsov created IGNITE-10875:
-

 Summary: Web Console: Update tooltip
 Key: IGNITE-10875
 URL: https://issues.apache.org/jira/browse/IGNITE-10875
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexey Kuznetsov


Old: This setting is needed to hide and show tooltips with hints.

New: Use this setting to hide or show tooltips with hints.



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

[jira] [Updated] (IGNITE-10875) Web Console: Update tooltip

2019-01-09 Thread Alexey Kuznetsov (JIRA) 


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

Alexey Kuznetsov updated IGNITE-10875:
--
Ignite Flags:   (was: Docs Required)

> Web Console: Update tooltip
> ---
>
> Key: IGNITE-10875
> URL: https://issues.apache.org/jira/browse/IGNITE-10875
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
>
> Old: This setting is needed to hide and show tooltips with hints.
> New: Use this setting to hide or show tooltips with hints.



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

[jira] [Updated] (IGNITE-9845) Web Console: Add support of two way ssl authentication in Web Console agent

2019-01-09 Thread Alexey Kuznetsov (JIRA) 


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

Alexey Kuznetsov updated IGNITE-9845:
-
Description: 
RestExecutor should not be shared between different users requests in case of 
two way ssl authentication:
 * For each token with ssl we need create separated RestExecutor and set up 
socketFactory and trustManager.
 * RestExecutor should be removed if token expired.

Add program arguments for passing client certificate, client password, trust 
store, trust store password for ignite node connection and web console backend. 

Example on okhttp: 
[https://github.com/square/okhttp/blob/cd872fd83824512c128dcd80c04d445c8a2fc8eb/okhttp-tests/src/test/java/okhttp3/internal/tls/ClientAuthTest.java]

Upgrade socket-io from 1.x to 2.x.

Add support for SSL cipher suites

Add tests.

---

*How to do local testing:*

On Windows
 # Download Open SSL:  Download Open SSL for Windows from 
[https://wiki.openssl.org/index.php/Binaries]
 # Unpack it.

On Linux - it is usually built-in.

Generate keys with provided script (see attached generate.bat, it could be 
easily adapted for Linux).

 

Add to etc/hosts: 

    127.0.0.1 localhost console.test.local

 

After that configure SSL for:
 # Web Console back-end.
 # Web Agent.
 # Cluster.

*Configure Web Console back-end settings:*

  "ssl": true,
   "key": "some_path/server.key",
   "cert": "some_path/server.crt",
   "ca": "some_path/ca.crt",
   "keyPassphrase": "p123456",

*Configure Web Agent parameters (see parameters descriptions):*

-t your_token

-s [https://console.test.local:3000|https://console.test.local:3000/] -n 
[https://console.test.local:11443|https://console.test.local:11443/]
 -nks client.jks -nkp p123456
 -nts ca.jks -ntp p123456
 -sks client.jks -skp p123456
 -sts ca.jks -stp p123456

 *Configure cluster JETTY config (see FULL config attached):*


   https
   
   true
   true
     
 


   some_path/server.jks
   p123456
   some_path/ca.jks
   p123456
   true
 

*How to start secure web console in direct install edition in Ubuntu:*
 # Download ignite web console direct install for linux ZIP archive .
 # Unpack downloaded archive to goal folder.
 # Generate SSL certificates.
 # Copy generated certificates to folder with unpacked web console direct 
install.
 # Open terminal and navigate to folder with unpacked web console direct 
install.
 # Run web console with the next command:

{code:java}
 ignite-web-console-linux --server:port 11443 --server:ssl true 
--server:requestCert true --server:key "server.key" --server:cert "server.crt" 
--server:ca "ca.crt" --server:passphrase "p123456"{code}
  7. Import client.p12 certificate into your browser. See attached 
screenstot in Chrome browser.

 

  was:
RestExecutor should not be shared between different users requests in case of 
two way ssl authentication:
 * For each token with ssl we need create separated RestExecutor and set up 
socketFactory and trustManager.
 * RestExecutor should be removed if token expired.

Add program arguments for passing client certificate, client password, trust 
store, trust store password for ignite node connection and web console backend. 

Example on okhttp: 
[https://github.com/square/okhttp/blob/cd872fd83824512c128dcd80c04d445c8a2fc8eb/okhttp-tests/src/test/java/okhttp3/internal/tls/ClientAuthTest.java]

Upgrade socket-io from 1.x to 2.x.

Add support for SSL cipher suites

Add tests.

---

*How to do local testing:*

On Windows
 # Download Open SSL:  Download Open SSL for Windows from 
[https://wiki.openssl.org/index.php/Binaries]
 # Unpack it.

On Linux - it is usually built-in.

Generate keys with provided script (see attached generate.bat, it could be 
easily adapted for Linux).

 

Add to etc/hosts: 

    127.0.0.1 localhost console.test.local

 

After that configure SSL for:
 # Web Console back-end.
 # Web Agent.
 # Cluster.

*Configure Web Console back-end settings:*

  "ssl": true,
   "key": "some_path/server.key",
   "cert": "some_path/server.crt",
   "ca": "some_path/ca.crt",
   "keyPassphrase": "p123456",

*Configure Web Agent parameters (see parameters descriptions):*

-t your_token

-s [https://console.test.local:3000|https://console.test.local:3000/] -n 
[https://console.test.local:11443|https://console.test.local:11443/]
 -nks client.jks -nkp p123456
 -nts ca.jks -ntp p123456
 -sks client.jks -skp p123456
 -sts ca.jks -stp p123456

 *Configure cluster JETTY config:*


   https
   
   true
   true
     
 


   some_path/server.jks
   p123456
   some_path/ca.jks
   p123456
   true
 

*How to start secure web console in direct install edition in Ubuntu:*
 # Download ignite web console direct install for linux ZIP archive .
 # Unpack downloaded archive to goal folder.
 # Generate SSL certificates.
 # Copy generated certificates to folder

[jira] [Updated] (IGNITE-8245) Web console: "Warning" icon is displayed above "secured key" icon.

2019-01-09 Thread Pavel Konstantinov (JIRA) 


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

Pavel Konstantinov updated IGNITE-8245:
---
Attachment: Снимок экрана 2019-01-10 в 10.11.28.png

> Web console: "Warning" icon is displayed above "secured key" icon.
> --
>
> Key: IGNITE-8245
> URL: https://issues.apache.org/jira/browse/IGNITE-8245
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.4
>Reporter: Andrey Novikov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.8
>
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, 
> warning_icon.png, Снимок экрана 2019-01-10 в 10.11.28.png
>
>
> See attachment. Reproduced in Safari.
> Make the actual input borderless, move the border to outer element, shrink 
> the input element when an error notification has to be shown.



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

[jira] [Updated] (IGNITE-9845) Web Console: Add support of two way ssl authentication in Web Console agent

2019-01-09 Thread Alexey Kuznetsov (JIRA) 


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

Alexey Kuznetsov updated IGNITE-9845:
-
Attachment: jetty-with-ssl.xml

> Web Console: Add support of two way ssl authentication in Web Console agent
> ---
>
> Key: IGNITE-9845
> URL: https://issues.apache.org/jira/browse/IGNITE-9845
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Affects Versions: 2.6
>Reporter: Andrey Novikov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
> Attachments: Selection_274.png, generate.bat, generate.sh, 
> jetty-with-ssl.xml, ssl.pdf
>
>
> RestExecutor should not be shared between different users requests in case of 
> two way ssl authentication:
>  * For each token with ssl we need create separated RestExecutor and set up 
> socketFactory and trustManager.
>  * RestExecutor should be removed if token expired.
> Add program arguments for passing client certificate, client password, trust 
> store, trust store password for ignite node connection and web console 
> backend. 
> Example on okhttp: 
> [https://github.com/square/okhttp/blob/cd872fd83824512c128dcd80c04d445c8a2fc8eb/okhttp-tests/src/test/java/okhttp3/internal/tls/ClientAuthTest.java]
> Upgrade socket-io from 1.x to 2.x.
> Add support for SSL cipher suites
> Add tests.
> ---
> *How to do local testing:*
> On Windows
>  # Download Open SSL:  Download Open SSL for Windows from 
> [https://wiki.openssl.org/index.php/Binaries]
>  # Unpack it.
> On Linux - it is usually built-in.
> Generate keys with provided script (see attached generate.bat, it could be 
> easily adapted for Linux).
>  
> Add to etc/hosts: 
>     127.0.0.1 localhost console.test.local
>  
> After that configure SSL for:
>  # Web Console back-end.
>  # Web Agent.
>  # Cluster.
> *Configure Web Console back-end settings:*
>   "ssl": true,
>    "key": "some_path/server.key",
>    "cert": "some_path/server.crt",
>    "ca": "some_path/ca.crt",
>    "keyPassphrase": "p123456",
> *Configure Web Agent parameters (see parameters descriptions):*
> -t your_token
> -s [https://console.test.local:3000|https://console.test.local:3000/] -n 
> [https://console.test.local:11443|https://console.test.local:11443/]
>  -nks client.jks -nkp p123456
>  -nts ca.jks -ntp p123456
>  -sks client.jks -skp p123456
>  -sts ca.jks -stp p123456
>  *Configure cluster JETTY config (see FULL config attached):*
> 
>    https
>     default="11443"/>
>    true
>    true
>       class="org.eclipse.jetty.server.SecureRequestCustomizer"/>
>  
>  class="org.eclipse.jetty.util.ssl.SslContextFactory">
>    some_path/server.jks
>    p123456
>    some_path/ca.jks
>    p123456
>    true
>  
> *How to start secure web console in direct install edition in Ubuntu:*
>  # Download ignite web console direct install for linux ZIP archive .
>  # Unpack downloaded archive to goal folder.
>  # Generate SSL certificates.
>  # Copy generated certificates to folder with unpacked web console direct 
> install.
>  # Open terminal and navigate to folder with unpacked web console direct 
> install.
>  # Run web console with the next command:
> {code:java}
>  ignite-web-console-linux --server:port 11443 --server:ssl true 
> --server:requestCert true --server:key "server.key" --server:cert 
> "server.crt" --server:ca "ca.crt" --server:passphrase "p123456"{code}
>   7. Import client.p12 certificate into your browser. See attached 
> screenstot in Chrome browser.
>  



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

[jira] [Comment Edited] (IGNITE-8245) Web console: "Warning" icon is displayed above "secured key" icon.

2019-01-09 Thread Pavel Konstantinov (JIRA) 


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

Pavel Konstantinov edited comment on IGNITE-8245 at 1/10/19 3:30 AM:
-

To reproduce try to enter incorrect value several times.
Here is an example from the Safari.
 !Снимок экрана 2019-01-10 в 10.11.28.png! 


was (Author: pkonstantinov):
To reproduce try to enter incorrect value several times.
 !Снимок экрана 2019-01-10 в 10.11.28.png! 

> Web console: "Warning" icon is displayed above "secured key" icon.
> --
>
> Key: IGNITE-8245
> URL: https://issues.apache.org/jira/browse/IGNITE-8245
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.4
>Reporter: Andrey Novikov
>Assignee: Ilya Borisov
>Priority: Minor
> Fix For: 2.8
>
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, 
> warning_icon.png, Снимок экрана 2019-01-10 в 10.11.28.png
>
>
> See attachment. Reproduced in Safari.
> Make the actual input borderless, move the border to outer element, shrink 
> the input element when an error notification has to be shown.



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

[jira] [Assigned] (IGNITE-8245) Web console: "Warning" icon is displayed above "secured key" icon.

2019-01-09 Thread Pavel Konstantinov (JIRA) 


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

Pavel Konstantinov reassigned IGNITE-8245:
--

Assignee: Ilya Borisov  (was: Pavel Konstantinov)

> Web console: "Warning" icon is displayed above "secured key" icon.
> --
>
> Key: IGNITE-8245
> URL: https://issues.apache.org/jira/browse/IGNITE-8245
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.4
>Reporter: Andrey Novikov
>Assignee: Ilya Borisov
>Priority: Minor
> Fix For: 2.8
>
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, 
> warning_icon.png, Снимок экрана 2019-01-10 в 10.11.28.png
>
>
> See attachment. Reproduced in Safari.
> Make the actual input borderless, move the border to outer element, shrink 
> the input element when an error notification has to be shown.



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

[jira] [Updated] (IGNITE-10867) Document work-around JDK upgrade against command-line parsing bug on Windows

2019-01-09 Thread Denis Magda (JIRA) 


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

Denis Magda updated IGNITE-10867:
-
Priority: Critical  (was: Major)

> Document work-around JDK upgrade against command-line parsing bug on Windows
> 
>
> Key: IGNITE-10867
> URL: https://issues.apache.org/jira/browse/IGNITE-10867
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Assignee: Prachi Garg
>Priority: Critical
>  Labels: windows
>




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

[jira] [Assigned] (IGNITE-10867) Document work-around JDK upgrade against command-line parsing bug on Windows

2019-01-09 Thread Denis Magda (JIRA) 


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

Denis Magda reassigned IGNITE-10867:


Assignee: Prachi Garg  (was: Denis Magda)

> Document work-around JDK upgrade against command-line parsing bug on Windows
> 
>
> Key: IGNITE-10867
> URL: https://issues.apache.org/jira/browse/IGNITE-10867
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Assignee: Prachi Garg
>Priority: Major
>  Labels: windows
>




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

[jira] [Comment Edited] (IGNITE-8245) Web console: "Warning" icon is displayed above "secured key" icon.

2019-01-09 Thread Pavel Konstantinov (JIRA) 


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

Pavel Konstantinov edited comment on IGNITE-8245 at 1/10/19 3:19 AM:
-

To reproduce try to enter incorrect value several times.
 !Снимок экрана 2019-01-10 в 10.11.28.png! 


was (Author: pkonstantinov):
 !Снимок экрана 2019-01-10 в 10.11.28.png! 

> Web console: "Warning" icon is displayed above "secured key" icon.
> --
>
> Key: IGNITE-8245
> URL: https://issues.apache.org/jira/browse/IGNITE-8245
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.4
>Reporter: Andrey Novikov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.8
>
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, 
> warning_icon.png, Снимок экрана 2019-01-10 в 10.11.28.png
>
>
> See attachment. Reproduced in Safari.
> Make the actual input borderless, move the border to outer element, shrink 
> the input element when an error notification has to be shown.



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

[jira] [Commented] (IGNITE-8245) Web console: "Warning" icon is displayed above "secured key" icon.

2019-01-09 Thread Pavel Konstantinov (JIRA) 


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

Pavel Konstantinov commented on IGNITE-8245:


 !Снимок экрана 2019-01-10 в 10.11.28.png! 

> Web console: "Warning" icon is displayed above "secured key" icon.
> --
>
> Key: IGNITE-8245
> URL: https://issues.apache.org/jira/browse/IGNITE-8245
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.4
>Reporter: Andrey Novikov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.8
>
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, 
> warning_icon.png, Снимок экрана 2019-01-10 в 10.11.28.png
>
>
> See attachment. Reproduced in Safari.
> Make the actual input borderless, move the border to outer element, shrink 
> the input element when an error notification has to be shown.



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

[jira] [Closed] (IGNITE-9699) Web console: Mutual authentication on Web Console isn't supported

2019-01-09 Thread Alexey Kuznetsov (JIRA) 


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

Alexey Kuznetsov closed IGNITE-9699.


> Web console: Mutual authentication on Web Console isn't supported
> -
>
> Key: IGNITE-9699
> URL: https://issues.apache.org/jira/browse/IGNITE-9699
> Project: Ignite
>  Issue Type: New Feature
>  Components: UI
>Affects Versions: 2.6
>Reporter: Andrey Aleksandrov
>Assignee: Alexey Kuznetsov
>Priority: Critical
> Fix For: 2.8
>
>
> Ignite has a possibility to configure SSL connection with Certificate 
> Authority. But in the web console, we are able to use only one certificate 
> used in web console agent. It could be a problem when a lot of users will use 
> the same web console and have different certificates for validation.
> We require to allow the user to pick his own certificate for SSL connection 
> to the grid.
>  



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

[jira] [Resolved] (IGNITE-9699) Web console: Mutual authentication on Web Console isn't supported

2019-01-09 Thread Alexey Kuznetsov (JIRA) 


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

Alexey Kuznetsov resolved IGNITE-9699.
--
Resolution: Duplicate

Duplicate of IGNITE-9845

> Web console: Mutual authentication on Web Console isn't supported
> -
>
> Key: IGNITE-9699
> URL: https://issues.apache.org/jira/browse/IGNITE-9699
> Project: Ignite
>  Issue Type: New Feature
>  Components: UI
>Affects Versions: 2.6
>Reporter: Andrey Aleksandrov
>Assignee: Alexey Kuznetsov
>Priority: Critical
> Fix For: 2.8
>
>
> Ignite has a possibility to configure SSL connection with Certificate 
> Authority. But in the web console, we are able to use only one certificate 
> used in web console agent. It could be a problem when a lot of users will use 
> the same web console and have different certificates for validation.
> We require to allow the user to pick his own certificate for SSL connection 
> to the grid.
>  



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

[jira] [Updated] (IGNITE-9699) Web console: Mutual authentication on Web Console isn't supported

2019-01-09 Thread Alexey Kuznetsov (JIRA) 


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

Alexey Kuznetsov updated IGNITE-9699:
-
Ignite Flags:   (was: Docs Required)

> Web console: Mutual authentication on Web Console isn't supported
> -
>
> Key: IGNITE-9699
> URL: https://issues.apache.org/jira/browse/IGNITE-9699
> Project: Ignite
>  Issue Type: New Feature
>  Components: UI
>Affects Versions: 2.6
>Reporter: Andrey Aleksandrov
>Priority: Critical
> Fix For: 2.8
>
>
> Ignite has a possibility to configure SSL connection with Certificate 
> Authority. But in the web console, we are able to use only one certificate 
> used in web console agent. It could be a problem when a lot of users will use 
> the same web console and have different certificates for validation.
> We require to allow the user to pick his own certificate for SSL connection 
> to the grid.
>  



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

[jira] [Assigned] (IGNITE-9699) Web console: Mutual authentication on Web Console isn't supported

2019-01-09 Thread Alexey Kuznetsov (JIRA) 


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

Alexey Kuznetsov reassigned IGNITE-9699:


Assignee: Alexey Kuznetsov

> Web console: Mutual authentication on Web Console isn't supported
> -
>
> Key: IGNITE-9699
> URL: https://issues.apache.org/jira/browse/IGNITE-9699
> Project: Ignite
>  Issue Type: New Feature
>  Components: UI
>Affects Versions: 2.6
>Reporter: Andrey Aleksandrov
>Assignee: Alexey Kuznetsov
>Priority: Critical
> Fix For: 2.8
>
>
> Ignite has a possibility to configure SSL connection with Certificate 
> Authority. But in the web console, we are able to use only one certificate 
> used in web console agent. It could be a problem when a lot of users will use 
> the same web console and have different certificates for validation.
> We require to allow the user to pick his own certificate for SSL connection 
> to the grid.
>  



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

[jira] [Updated] (IGNITE-8245) Web console: "Warning" icon is displayed above "secured key" icon.

2019-01-09 Thread Ilya Borisov (JIRA) 


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

Ilya Borisov updated IGNITE-8245:
-
Priority: Minor  (was: Major)

> Web console: "Warning" icon is displayed above "secured key" icon.
> --
>
> Key: IGNITE-8245
> URL: https://issues.apache.org/jira/browse/IGNITE-8245
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.4
>Reporter: Andrey Novikov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.8
>
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, 
> warning_icon.png
>
>
> See attachment. Reproduced in Safari.
> Make the actual input borderless, move the border to outer element, shrink 
> the input element when an error notification has to be shown.



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

[jira] [Comment Edited] (IGNITE-10874) JDBC thin driver metadata misses caches with queryEntities and names containing underscores

2019-01-09 Thread Pavel Kuznetsov (JIRA) 


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

Pavel Kuznetsov edited comment on IGNITE-10874 at 1/10/19 12:14 AM:


This issue seems to be "brother" of odbc ticket IGNITE-10009

So we need to handle search patterns like 
{noformat}
MY\_TABLE
and
MY\%TABLE
{noformat}
to matche '_' and '%' literally, not as wildcards.


was (Author: pkouznet):
This issue seems to be "brother" of odbc ticket IGNITE-10009

So we need to handle search patterns like {{MY\}}{{_TABLE}} and 
{{MY\}}{{%TABLE}} to matche '_' and '%' literally, not as wildcards.

> JDBC thin driver metadata misses caches with queryEntities and names 
> containing underscores
> ---
>
> Key: IGNITE-10874
> URL: https://issues.apache.org/jira/browse/IGNITE-10874
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc
>Affects Versions: 2.7
>Reporter: Alexey Kukushkin
>Priority: Major
>
> +*Steps to reproduce*+
> 1) Build and run this app: 
> {code:java}
> public class App {
> public static void main(String[] ags) {
> try (Ignite ignite = Ignition.start(
> new IgniteConfiguration()
> .setDiscoverySpi(
> new TcpDiscoverySpi()
> .setIpFinder(
> new 
> TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500"))
> )
> )
> )) {
> final String NAME = "V_MODELS_SHORT";
> ignite.getOrCreateCache(
> new CacheConfiguration<>()
> .setName(NAME)
> .setCacheMode(CacheMode.PARTITIONED)
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
> .setQueryEntities(Collections.singleton(
> new QueryEntity()
> .setKeyType(Integer.class.getTypeName())
> .setValueType(NAME)
> .setKeyFieldName("VMS_ID")
> .setFields(
> Stream.of(
> new AbstractMap.SimpleEntry<>("VMS_ID", 
> Integer.class.getTypeName()),
> new 
> AbstractMap.SimpleEntry<>("VMS_HASVERSION", Boolean.class.getTypeName())
> ).collect(Collectors.toMap(
> AbstractMap.SimpleEntry::getKey,
> AbstractMap.SimpleEntry::getValue,
> (u, v) -> {
> throw new 
> IllegalStateException(String.format("Duplicate key %s", u));
> },
> LinkedHashMap::new
> ))
> )
> ))
> );
> System.in.read();
> }
> }
> }
> {code}
> 2) While the app is running use a JDBC database management tool like DBeaver 
> to open a JDBC thin driver connection to Ignite.
> 3) Check table "V_MODELS_SHORT" under schema "V_MODELS_SHORT"
> +*Expected*+
> 3) Table "V_MODELS_SHORT" is visible under  schema "V_MODELS_SHORT"
> +*Actual*+
>  3) There is no table "V_MODELS_SHORT" under  schema "V_MODELS_SHORT"
> +*Notes*+
> You still can run queries on table V_MODELS_SHORT in DBeaver. For example, 
> these queries work fine:
> {code:java}
> INSERT INTO V_MODELS_SHORT.V_MODELS_SHORT VALUES (1, 'false');
> SELECT * FROM V_MODELS_SHORT.V_MODELS_SHORT;
> {code}
>  



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

[jira] [Comment Edited] (IGNITE-10874) JDBC thin driver metadata misses caches with queryEntities and names containing underscores

2019-01-09 Thread Pavel Kuznetsov (JIRA) 


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

Pavel Kuznetsov edited comment on IGNITE-10874 at 1/10/19 12:14 AM:


This issue seems to be "brother" of odbc ticket IGNITE-10009

So we need search patterns like 
{noformat}
MY\_TABLE
and
MY\%TABLE
{noformat}
to match '_' and '%' literally, not as wildcards.


was (Author: pkouznet):
This issue seems to be "brother" of odbc ticket IGNITE-10009

So we need to handle search patterns like 
{noformat}
MY\_TABLE
and
MY\%TABLE
{noformat}
to matche '_' and '%' literally, not as wildcards.

> JDBC thin driver metadata misses caches with queryEntities and names 
> containing underscores
> ---
>
> Key: IGNITE-10874
> URL: https://issues.apache.org/jira/browse/IGNITE-10874
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc
>Affects Versions: 2.7
>Reporter: Alexey Kukushkin
>Priority: Major
>
> +*Steps to reproduce*+
> 1) Build and run this app: 
> {code:java}
> public class App {
> public static void main(String[] ags) {
> try (Ignite ignite = Ignition.start(
> new IgniteConfiguration()
> .setDiscoverySpi(
> new TcpDiscoverySpi()
> .setIpFinder(
> new 
> TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500"))
> )
> )
> )) {
> final String NAME = "V_MODELS_SHORT";
> ignite.getOrCreateCache(
> new CacheConfiguration<>()
> .setName(NAME)
> .setCacheMode(CacheMode.PARTITIONED)
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
> .setQueryEntities(Collections.singleton(
> new QueryEntity()
> .setKeyType(Integer.class.getTypeName())
> .setValueType(NAME)
> .setKeyFieldName("VMS_ID")
> .setFields(
> Stream.of(
> new AbstractMap.SimpleEntry<>("VMS_ID", 
> Integer.class.getTypeName()),
> new 
> AbstractMap.SimpleEntry<>("VMS_HASVERSION", Boolean.class.getTypeName())
> ).collect(Collectors.toMap(
> AbstractMap.SimpleEntry::getKey,
> AbstractMap.SimpleEntry::getValue,
> (u, v) -> {
> throw new 
> IllegalStateException(String.format("Duplicate key %s", u));
> },
> LinkedHashMap::new
> ))
> )
> ))
> );
> System.in.read();
> }
> }
> }
> {code}
> 2) While the app is running use a JDBC database management tool like DBeaver 
> to open a JDBC thin driver connection to Ignite.
> 3) Check table "V_MODELS_SHORT" under schema "V_MODELS_SHORT"
> +*Expected*+
> 3) Table "V_MODELS_SHORT" is visible under  schema "V_MODELS_SHORT"
> +*Actual*+
>  3) There is no table "V_MODELS_SHORT" under  schema "V_MODELS_SHORT"
> +*Notes*+
> You still can run queries on table V_MODELS_SHORT in DBeaver. For example, 
> these queries work fine:
> {code:java}
> INSERT INTO V_MODELS_SHORT.V_MODELS_SHORT VALUES (1, 'false');
> SELECT * FROM V_MODELS_SHORT.V_MODELS_SHORT;
> {code}
>  



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

[jira] [Comment Edited] (IGNITE-10874) JDBC thin driver metadata misses caches with queryEntities and names containing underscores

2019-01-09 Thread Pavel Kuznetsov (JIRA) 


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

Pavel Kuznetsov edited comment on IGNITE-10874 at 1/10/19 12:13 AM:


This issue seems to be "brother" of odbc ticket IGNITE-10009

So we need to handle search patterns like {{MY\}}{{_TABLE}} and 
{{MY\}}{{%TABLE}} to matche '_' and '%' literally, not as wildcards.


was (Author: pkouznet):
This issue seems to be "brother" of odbc ticket IGNITE-10009

So we need to handle search patterns like {{MY_TABLE}} and {{MY\}}{{%TABLE}} to 
matche '_' and '%' literally, not as wildcards.

> JDBC thin driver metadata misses caches with queryEntities and names 
> containing underscores
> ---
>
> Key: IGNITE-10874
> URL: https://issues.apache.org/jira/browse/IGNITE-10874
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc
>Affects Versions: 2.7
>Reporter: Alexey Kukushkin
>Priority: Major
>
> +*Steps to reproduce*+
> 1) Build and run this app: 
> {code:java}
> public class App {
> public static void main(String[] ags) {
> try (Ignite ignite = Ignition.start(
> new IgniteConfiguration()
> .setDiscoverySpi(
> new TcpDiscoverySpi()
> .setIpFinder(
> new 
> TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500"))
> )
> )
> )) {
> final String NAME = "V_MODELS_SHORT";
> ignite.getOrCreateCache(
> new CacheConfiguration<>()
> .setName(NAME)
> .setCacheMode(CacheMode.PARTITIONED)
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
> .setQueryEntities(Collections.singleton(
> new QueryEntity()
> .setKeyType(Integer.class.getTypeName())
> .setValueType(NAME)
> .setKeyFieldName("VMS_ID")
> .setFields(
> Stream.of(
> new AbstractMap.SimpleEntry<>("VMS_ID", 
> Integer.class.getTypeName()),
> new 
> AbstractMap.SimpleEntry<>("VMS_HASVERSION", Boolean.class.getTypeName())
> ).collect(Collectors.toMap(
> AbstractMap.SimpleEntry::getKey,
> AbstractMap.SimpleEntry::getValue,
> (u, v) -> {
> throw new 
> IllegalStateException(String.format("Duplicate key %s", u));
> },
> LinkedHashMap::new
> ))
> )
> ))
> );
> System.in.read();
> }
> }
> }
> {code}
> 2) While the app is running use a JDBC database management tool like DBeaver 
> to open a JDBC thin driver connection to Ignite.
> 3) Check table "V_MODELS_SHORT" under schema "V_MODELS_SHORT"
> +*Expected*+
> 3) Table "V_MODELS_SHORT" is visible under  schema "V_MODELS_SHORT"
> +*Actual*+
>  3) There is no table "V_MODELS_SHORT" under  schema "V_MODELS_SHORT"
> +*Notes*+
> You still can run queries on table V_MODELS_SHORT in DBeaver. For example, 
> these queries work fine:
> {code:java}
> INSERT INTO V_MODELS_SHORT.V_MODELS_SHORT VALUES (1, 'false');
> SELECT * FROM V_MODELS_SHORT.V_MODELS_SHORT;
> {code}
>  



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

[jira] [Comment Edited] (IGNITE-10874) JDBC thin driver metadata misses caches with queryEntities and names containing underscores

2019-01-09 Thread Pavel Kuznetsov (JIRA) 


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

Pavel Kuznetsov edited comment on IGNITE-10874 at 1/10/19 12:11 AM:


This issue seems to be "brother" of odbc ticket IGNITE-10009

So we need to handle search patterns like {{MY_TABLE}} and {{MY\}}{{%TABLE}} to 
matche '_' and '%' literally, not as wildcards.


was (Author: pkouznet):
This issue seems to be "brother" of odbc ticket IGNITE-10009

So we need to handle search patterns like {{MY\\_TABLE}} and {{MY\\%TABLE}} to 
matche '_' and '%' literally, not as wildcards.


> JDBC thin driver metadata misses caches with queryEntities and names 
> containing underscores
> ---
>
> Key: IGNITE-10874
> URL: https://issues.apache.org/jira/browse/IGNITE-10874
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc
>Affects Versions: 2.7
>Reporter: Alexey Kukushkin
>Priority: Major
>
> +*Steps to reproduce*+
> 1) Build and run this app: 
> {code:java}
> public class App {
> public static void main(String[] ags) {
> try (Ignite ignite = Ignition.start(
> new IgniteConfiguration()
> .setDiscoverySpi(
> new TcpDiscoverySpi()
> .setIpFinder(
> new 
> TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500"))
> )
> )
> )) {
> final String NAME = "V_MODELS_SHORT";
> ignite.getOrCreateCache(
> new CacheConfiguration<>()
> .setName(NAME)
> .setCacheMode(CacheMode.PARTITIONED)
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
> .setQueryEntities(Collections.singleton(
> new QueryEntity()
> .setKeyType(Integer.class.getTypeName())
> .setValueType(NAME)
> .setKeyFieldName("VMS_ID")
> .setFields(
> Stream.of(
> new AbstractMap.SimpleEntry<>("VMS_ID", 
> Integer.class.getTypeName()),
> new 
> AbstractMap.SimpleEntry<>("VMS_HASVERSION", Boolean.class.getTypeName())
> ).collect(Collectors.toMap(
> AbstractMap.SimpleEntry::getKey,
> AbstractMap.SimpleEntry::getValue,
> (u, v) -> {
> throw new 
> IllegalStateException(String.format("Duplicate key %s", u));
> },
> LinkedHashMap::new
> ))
> )
> ))
> );
> System.in.read();
> }
> }
> }
> {code}
> 2) While the app is running use a JDBC database management tool like DBeaver 
> to open a JDBC thin driver connection to Ignite.
> 3) Check table "V_MODELS_SHORT" under schema "V_MODELS_SHORT"
> +*Expected*+
> 3) Table "V_MODELS_SHORT" is visible under  schema "V_MODELS_SHORT"
> +*Actual*+
>  3) There is no table "V_MODELS_SHORT" under  schema "V_MODELS_SHORT"
> +*Notes*+
> You still can run queries on table V_MODELS_SHORT in DBeaver. For example, 
> these queries work fine:
> {code:java}
> INSERT INTO V_MODELS_SHORT.V_MODELS_SHORT VALUES (1, 'false');
> SELECT * FROM V_MODELS_SHORT.V_MODELS_SHORT;
> {code}
>  



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

[jira] [Comment Edited] (IGNITE-10874) JDBC thin driver metadata misses caches with queryEntities and names containing underscores

2019-01-09 Thread Pavel Kuznetsov (JIRA) 


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

Pavel Kuznetsov edited comment on IGNITE-10874 at 1/10/19 12:10 AM:


This issue seems to be "brother" of odbc ticket IGNITE-10009

So we need to handle search patterns like {{MY\\_TABLE}} and {{MY\\%TABLE}} to 
matche '_' and '%' literally, not as wildcards.



was (Author: pkouznet):
This issue seems to be "brother" of odbc ticket IGNITE-10009

So we need to handle search patterns that matches '_' and '%' literally 
{{MY\_TABLE}} and {{MY\%TABLE}}


> JDBC thin driver metadata misses caches with queryEntities and names 
> containing underscores
> ---
>
> Key: IGNITE-10874
> URL: https://issues.apache.org/jira/browse/IGNITE-10874
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc
>Affects Versions: 2.7
>Reporter: Alexey Kukushkin
>Priority: Major
>
> +*Steps to reproduce*+
> 1) Build and run this app: 
> {code:java}
> public class App {
> public static void main(String[] ags) {
> try (Ignite ignite = Ignition.start(
> new IgniteConfiguration()
> .setDiscoverySpi(
> new TcpDiscoverySpi()
> .setIpFinder(
> new 
> TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500"))
> )
> )
> )) {
> final String NAME = "V_MODELS_SHORT";
> ignite.getOrCreateCache(
> new CacheConfiguration<>()
> .setName(NAME)
> .setCacheMode(CacheMode.PARTITIONED)
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
> .setQueryEntities(Collections.singleton(
> new QueryEntity()
> .setKeyType(Integer.class.getTypeName())
> .setValueType(NAME)
> .setKeyFieldName("VMS_ID")
> .setFields(
> Stream.of(
> new AbstractMap.SimpleEntry<>("VMS_ID", 
> Integer.class.getTypeName()),
> new 
> AbstractMap.SimpleEntry<>("VMS_HASVERSION", Boolean.class.getTypeName())
> ).collect(Collectors.toMap(
> AbstractMap.SimpleEntry::getKey,
> AbstractMap.SimpleEntry::getValue,
> (u, v) -> {
> throw new 
> IllegalStateException(String.format("Duplicate key %s", u));
> },
> LinkedHashMap::new
> ))
> )
> ))
> );
> System.in.read();
> }
> }
> }
> {code}
> 2) While the app is running use a JDBC database management tool like DBeaver 
> to open a JDBC thin driver connection to Ignite.
> 3) Check table "V_MODELS_SHORT" under schema "V_MODELS_SHORT"
> +*Expected*+
> 3) Table "V_MODELS_SHORT" is visible under  schema "V_MODELS_SHORT"
> +*Actual*+
>  3) There is no table "V_MODELS_SHORT" under  schema "V_MODELS_SHORT"
> +*Notes*+
> You still can run queries on table V_MODELS_SHORT in DBeaver. For example, 
> these queries work fine:
> {code:java}
> INSERT INTO V_MODELS_SHORT.V_MODELS_SHORT VALUES (1, 'false');
> SELECT * FROM V_MODELS_SHORT.V_MODELS_SHORT;
> {code}
>  



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

[jira] [Comment Edited] (IGNITE-10874) JDBC thin driver metadata misses caches with queryEntities and names containing underscores

2019-01-09 Thread Pavel Kuznetsov (JIRA) 


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

Pavel Kuznetsov edited comment on IGNITE-10874 at 1/10/19 12:08 AM:


This issue seems to be "brother" of odbc ticket IGNITE-10009

So we need to handle search patterns that matches '_' and '%' literally 
{{MY\_TABLE}} and {{MY\%TABLE}}



was (Author: pkouznet):
This issue seems to be "brother" of odbc ticket IGNITE-10009

> JDBC thin driver metadata misses caches with queryEntities and names 
> containing underscores
> ---
>
> Key: IGNITE-10874
> URL: https://issues.apache.org/jira/browse/IGNITE-10874
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc
>Affects Versions: 2.7
>Reporter: Alexey Kukushkin
>Priority: Major
>
> +*Steps to reproduce*+
> 1) Build and run this app: 
> {code:java}
> public class App {
> public static void main(String[] ags) {
> try (Ignite ignite = Ignition.start(
> new IgniteConfiguration()
> .setDiscoverySpi(
> new TcpDiscoverySpi()
> .setIpFinder(
> new 
> TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500"))
> )
> )
> )) {
> final String NAME = "V_MODELS_SHORT";
> ignite.getOrCreateCache(
> new CacheConfiguration<>()
> .setName(NAME)
> .setCacheMode(CacheMode.PARTITIONED)
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
> .setQueryEntities(Collections.singleton(
> new QueryEntity()
> .setKeyType(Integer.class.getTypeName())
> .setValueType(NAME)
> .setKeyFieldName("VMS_ID")
> .setFields(
> Stream.of(
> new AbstractMap.SimpleEntry<>("VMS_ID", 
> Integer.class.getTypeName()),
> new 
> AbstractMap.SimpleEntry<>("VMS_HASVERSION", Boolean.class.getTypeName())
> ).collect(Collectors.toMap(
> AbstractMap.SimpleEntry::getKey,
> AbstractMap.SimpleEntry::getValue,
> (u, v) -> {
> throw new 
> IllegalStateException(String.format("Duplicate key %s", u));
> },
> LinkedHashMap::new
> ))
> )
> ))
> );
> System.in.read();
> }
> }
> }
> {code}
> 2) While the app is running use a JDBC database management tool like DBeaver 
> to open a JDBC thin driver connection to Ignite.
> 3) Check table "V_MODELS_SHORT" under schema "V_MODELS_SHORT"
> +*Expected*+
> 3) Table "V_MODELS_SHORT" is visible under  schema "V_MODELS_SHORT"
> +*Actual*+
>  3) There is no table "V_MODELS_SHORT" under  schema "V_MODELS_SHORT"
> +*Notes*+
> You still can run queries on table V_MODELS_SHORT in DBeaver. For example, 
> these queries work fine:
> {code:java}
> INSERT INTO V_MODELS_SHORT.V_MODELS_SHORT VALUES (1, 'false');
> SELECT * FROM V_MODELS_SHORT.V_MODELS_SHORT;
> {code}
>  



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

[jira] [Commented] (IGNITE-10874) JDBC thin driver metadata misses caches with queryEntities and names containing underscores

2019-01-09 Thread Pavel Kuznetsov (JIRA) 


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

Pavel Kuznetsov commented on IGNITE-10874:
--

This issue seems to be "brother" of odbc ticket IGNITE-10009

> JDBC thin driver metadata misses caches with queryEntities and names 
> containing underscores
> ---
>
> Key: IGNITE-10874
> URL: https://issues.apache.org/jira/browse/IGNITE-10874
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc
>Affects Versions: 2.7
>Reporter: Alexey Kukushkin
>Priority: Major
>
> +*Steps to reproduce*+
> 1) Build and run this app: 
> {code:java}
> public class App {
> public static void main(String[] ags) {
> try (Ignite ignite = Ignition.start(
> new IgniteConfiguration()
> .setDiscoverySpi(
> new TcpDiscoverySpi()
> .setIpFinder(
> new 
> TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500"))
> )
> )
> )) {
> final String NAME = "V_MODELS_SHORT";
> ignite.getOrCreateCache(
> new CacheConfiguration<>()
> .setName(NAME)
> .setCacheMode(CacheMode.PARTITIONED)
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
> .setQueryEntities(Collections.singleton(
> new QueryEntity()
> .setKeyType(Integer.class.getTypeName())
> .setValueType(NAME)
> .setKeyFieldName("VMS_ID")
> .setFields(
> Stream.of(
> new AbstractMap.SimpleEntry<>("VMS_ID", 
> Integer.class.getTypeName()),
> new 
> AbstractMap.SimpleEntry<>("VMS_HASVERSION", Boolean.class.getTypeName())
> ).collect(Collectors.toMap(
> AbstractMap.SimpleEntry::getKey,
> AbstractMap.SimpleEntry::getValue,
> (u, v) -> {
> throw new 
> IllegalStateException(String.format("Duplicate key %s", u));
> },
> LinkedHashMap::new
> ))
> )
> ))
> );
> System.in.read();
> }
> }
> }
> {code}
> 2) While the app is running use a JDBC database management tool like DBeaver 
> to open a JDBC thin driver connection to Ignite.
> 3) Check table "V_MODELS_SHORT" under schema "V_MODELS_SHORT"
> +*Expected*+
> 3) Table "V_MODELS_SHORT" is visible under  schema "V_MODELS_SHORT"
> +*Actual*+
>  3) There is no table "V_MODELS_SHORT" under  schema "V_MODELS_SHORT"
> +*Notes*+
> You still can run queries on table V_MODELS_SHORT in DBeaver. For example, 
> these queries work fine:
> {code:java}
> INSERT INTO V_MODELS_SHORT.V_MODELS_SHORT VALUES (1, 'false');
> SELECT * FROM V_MODELS_SHORT.V_MODELS_SHORT;
> {code}
>  



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

[jira] [Assigned] (IGNITE-10777) Cleanup remainders of JUnit4TestAdapter and other JUnit 3 API involving test suites

2019-01-09 Thread Oleg Ignatenko (JIRA) 


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

Oleg Ignatenko reassigned IGNITE-10777:
---

Assignee: Oleg Ignatenko

> Cleanup remainders of JUnit4TestAdapter and other JUnit 3 API involving test 
> suites
> ---
>
> Key: IGNITE-10777
> URL: https://issues.apache.org/jira/browse/IGNITE-10777
> Project: Ignite
>  Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> This task is to cleanup remainders of JUnit4TestAdapter and other JUnit 3 API 
> involving test suites that may be missed in prior sub-tasks under the parent 
> task.
> If needed, refer to parent task comments for more details.



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

[jira] [Commented] (IGNITE-10775) Migrate from JUnit 3 to 4 test suites of simple dynamic lists that use addTestIfNeeded API

2019-01-09 Thread Ignite TC Bot (JIRA) 


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

Ignite TC Bot commented on IGNITE-10775:


{panel:title=-- Run :: All: No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2755810buildTypeId=IgniteTests24Java8_RunAll]

> Migrate from JUnit 3 to 4 test suites of simple dynamic lists that use 
> addTestIfNeeded API
> --
>
> Key: IGNITE-10775
> URL: https://issues.apache.org/jira/browse/IGNITE-10775
> Project: Ignite
>  Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> This task is to migrate from JUnit 3 to 4 test suites of simple dynamic lists 
> that use {{GridTestUtils.addTestIfNeeded}} API.
> If needed, refer parent task comments for more details.



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

[jira] [Commented] (IGNITE-10796) Migrate from JUnit 3 to 4 suites involving IgniteTestSuite

2019-01-09 Thread Ignite TC Bot (JIRA) 


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

Ignite TC Bot commented on IGNITE-10796:


{panel:title=-- Run :: All (Nightly): No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All (Nightly)* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2754876buildTypeId=IgniteTests24Java8_RunAllNightly]

> Migrate from JUnit 3 to 4 suites involving IgniteTestSuite
> --
>
> Key: IGNITE-10796
> URL: https://issues.apache.org/jira/browse/IGNITE-10796
> Project: Ignite
>  Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This task is to migrate from JUnit 3 to 4 test suites suites involving 
> {{IgniteTestSuite}} API that was introduced per IGNITE-3658.
> If needed, refer parent task comments for more details.



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

[jira] [Updated] (IGNITE-10874) JDBC thin driver metadata misses caches with queryEntities and names containing underscores

2019-01-09 Thread Alexey Kukushkin (JIRA) 


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

Alexey Kukushkin updated IGNITE-10874:
--
Description: 
+*Steps to reproduce*+

1) Build and run this app: 
{code:java}
public class App {
public static void main(String[] ags) {
try (Ignite ignite = Ignition.start(
new IgniteConfiguration()
.setDiscoverySpi(
new TcpDiscoverySpi()
.setIpFinder(
new 
TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500"))
)
)
)) {
final String NAME = "V_MODELS_SHORT";

ignite.getOrCreateCache(
new CacheConfiguration<>()
.setName(NAME)
.setCacheMode(CacheMode.PARTITIONED)
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setQueryEntities(Collections.singleton(
new QueryEntity()
.setKeyType(Integer.class.getTypeName())
.setValueType(NAME)
.setKeyFieldName("VMS_ID")
.setFields(
Stream.of(
new AbstractMap.SimpleEntry<>("VMS_ID", 
Integer.class.getTypeName()),
new 
AbstractMap.SimpleEntry<>("VMS_HASVERSION", Boolean.class.getTypeName())
).collect(Collectors.toMap(
AbstractMap.SimpleEntry::getKey,
AbstractMap.SimpleEntry::getValue,
(u, v) -> {
throw new 
IllegalStateException(String.format("Duplicate key %s", u));
},
LinkedHashMap::new
))
)
))
);

System.in.read();
}
}
}
{code}
2) While the app is running use a JDBC database management tool like DBeaver to 
open a JDBC thin driver connection to Ignite.

3) Check table "V_MODELS_SHORT" under schema "V_MODELS_SHORT"

+*Expected*+

3) Table "V_MODELS_SHORT" is visible under  schema "V_MODELS_SHORT"

+*Actual*+

 3) There is no table "V_MODELS_SHORT" under  schema "V_MODELS_SHORT"

+*Notes*+

You still can run queries on table V_MODELS_SHORT in DBeaver. For example, 
these queries work fine:
{code:java}
INSERT INTO V_MODELS_SHORT.V_MODELS_SHORT VALUES (1, 'false');

SELECT * FROM V_MODELS_SHORT.V_MODELS_SHORT;
{code}
 

  was:
+*Steps to reproduce*+

1) Build and run this app:

 
{code:java}
public class App {
public static void main(String[] ags) {
try (Ignite ignite = Ignition.start(
new IgniteConfiguration()
.setDiscoverySpi(
new TcpDiscoverySpi()
.setIpFinder(
new 
TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500"))
)
)
)) {
final String NAME = "V_MODELS_SHORT";

ignite.getOrCreateCache(
new CacheConfiguration<>()
.setName(NAME)
.setCacheMode(CacheMode.PARTITIONED)
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setQueryEntities(Collections.singleton(
new QueryEntity()
.setKeyType(Integer.class.getTypeName())
.setValueType(NAME)
.setKeyFieldName("VMS_ID")
.setFields(
Stream.of(
new AbstractMap.SimpleEntry<>("VMS_ID", 
Integer.class.getTypeName()),
new 
AbstractMap.SimpleEntry<>("VMS_HASVERSION", Boolean.class.getTypeName())
).collect(Collectors.toMap(
AbstractMap.SimpleEntry::getKey,
AbstractMap.SimpleEntry::getValue,
(u, v) -> {
throw new 
IllegalStateException(String.format("Duplicate key %s", u));
},
LinkedHashMap::new
))
)
))
);

System.in.read();
}
}
}
{code}
2) While the app is running use a JDBC database management tool like DBeaver to 
open a JDBC thin driver connection to Ignite.

3) Check table "V_MODELS_SHORT" under schema "V_MODELS_SHORT"

[jira] [Created] (IGNITE-10874) JDBC thin driver metadata misses caches with queryEntities and names containing underscores

2019-01-09 Thread Alexey Kukushkin (JIRA) 
Alexey Kukushkin created IGNITE-10874:
-

 Summary: JDBC thin driver metadata misses caches with 
queryEntities and names containing underscores
 Key: IGNITE-10874
 URL: https://issues.apache.org/jira/browse/IGNITE-10874
 Project: Ignite
  Issue Type: Improvement
  Components: jdbc
Affects Versions: 2.7
Reporter: Alexey Kukushkin


+*Steps to reproduce*+

1) Build and run this app:

 
{code:java}
public class App {
public static void main(String[] ags) {
try (Ignite ignite = Ignition.start(
new IgniteConfiguration()
.setDiscoverySpi(
new TcpDiscoverySpi()
.setIpFinder(
new 
TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500"))
)
)
)) {
final String NAME = "V_MODELS_SHORT";

ignite.getOrCreateCache(
new CacheConfiguration<>()
.setName(NAME)
.setCacheMode(CacheMode.PARTITIONED)
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setQueryEntities(Collections.singleton(
new QueryEntity()
.setKeyType(Integer.class.getTypeName())
.setValueType(NAME)
.setKeyFieldName("VMS_ID")
.setFields(
Stream.of(
new AbstractMap.SimpleEntry<>("VMS_ID", 
Integer.class.getTypeName()),
new 
AbstractMap.SimpleEntry<>("VMS_HASVERSION", Boolean.class.getTypeName())
).collect(Collectors.toMap(
AbstractMap.SimpleEntry::getKey,
AbstractMap.SimpleEntry::getValue,
(u, v) -> {
throw new 
IllegalStateException(String.format("Duplicate key %s", u));
},
LinkedHashMap::new
))
)
))
);

System.in.read();
}
}
}
{code}
2) While the app is running use a JDBC database management tool like DBeaver to 
open a JDBC thin driver connection to Ignite.

3) Check table "V_MODELS_SHORT" under schema "V_MODELS_SHORT"

+*Expected*+

3) Table "V_MODELS_SHORT" is visible under  schema "V_MODELS_SHORT"

+*Actual*+

 

3) There is no table "V_MODELS_SHORT" under  schema "V_MODELS_SHORT"

+*Notes*+

You still can run queries on table V_MODELS_SHORT in DBeaver. For example, 
these queries work fine:
{code:java}
INSERT INTO V_MODELS_SHORT.V_MODELS_SHORT VALUES (1, 'false');

SELECT * FROM V_MODELS_SHORT.V_MODELS_SHORT;
{code}
 



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

[jira] [Commented] (IGNITE-7198) Integrate with Apache Beam

2019-01-09 Thread Jun Wan (JIRA) 


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

Jun Wan commented on IGNITE-7198:
-

Hi, any progress on this? I see the Priority is marked Critical. Thanks!

> Integrate with Apache Beam 
> ---
>
> Key: IGNITE-7198
> URL: https://issues.apache.org/jira/browse/IGNITE-7198
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Priority: Critical
>
> Apache Beam (https://beam.apache.org/) provides a unified API for batch and 
> streaming processing. It can be seen as a generic/portable API with multiple 
> implementations (Spark, Flink, etc.).
> Apache Ignite perfectly fits Beam architecture as a Runner:
> https://beam.apache.org/contribute/runner-guide/
> Here is Beam's capability matrix. Let's support as much as we're capable of:
> https://beam.apache.org/documentation/runners/capability-matrix/
> Most likely the integration should go to Beam's repository:
> https://github.com/apache/beam/tree/master/runners
> Discussion on the dev list: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-as-a-distributed-processing-back-ends-td25122.html



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

[jira] [Updated] (IGNITE-10873) CorruptedTreeException during simultaneous cache put operations

2019-01-09 Thread Eduard Shangareev (JIRA) 


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

Eduard Shangareev updated IGNITE-10873:
---
Description: 
{code}
[2019-01-09 20:47:04,376][ERROR][pool-9-thread-9][GridDhtAtomicCache]  
Unexpected exception during cache update
org.h2.message.DbException: General error: "class 
org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
 Runtime failure on row: Row@780acfb4[ key: .. ][ GTEST, null, 254, null, 
null, null, null, 0, null, null, null, null, null, null, null, 0, 0, 0, null, 
0, 0, 0, 0, 0, 0, 0, null, 0, 0, null, 0, null, 0, null, 0, null, null, null, 
0, 0, 0, 0, 0, 0, null, null, null, null, null, null, null, 0.0, 0, 0.0, 0, 
0.0, 0, null, 0, 0, 0, 0, null, null, null, null, null, null, null, null, null, 
null, null, null, null, null, null, null ]" [5-197]
at org.h2.message.DbException.get(DbException.java:168)
at org.h2.message.DbException.convert(DbException.java:307)
at 
org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:302)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.addToIndex(GridH2Table.java:546)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:479)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:768)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1905)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:404)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:2633)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1646)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1621)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1935)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:428)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2295)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2494)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1951)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1780)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1668)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1153)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:611)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2449)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2426)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1105)
at 
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:820)
at IndexCorruptionReproducer$1.run(IndexCorruptionReproducer.java:43)
at 
java.util.concurrent.Executors$RunnableAdapter.call$$$capture(Executors.java:511)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java)
at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266)
at java.util.concurrent.FutureTask.run(FutureTask.java)
at

[jira] [Updated] (IGNITE-10873) CorruptedTreeException during simultaneous cache put operations

2019-01-09 Thread Pavel Vinokurov (JIRA) 


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

Pavel Vinokurov updated IGNITE-10873:
-
Component/s: sql

> CorruptedTreeException during simultaneous cache put operations
> ---
>
> Key: IGNITE-10873
> URL: https://issues.apache.org/jira/browse/IGNITE-10873
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, persistence, sql
>Affects Versions: 2.7
>Reporter: Pavel Vinokurov
>Priority: Critical
>
> [2019-01-09 20:47:04,376][ERROR][pool-9-thread-9][GridDhtAtomicCache]  
> Unexpected exception during cache update
> org.h2.message.DbException: General error: "class 
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
>  Runtime failure on row: Row@780acfb4[ key: .. ][ GTEST, null, 254, null, 
> null, null, null, 0, null, null, null, null, null, null, null, 0, 0, 0, null, 
> 0, 0, 0, 0, 0, 0, 0, null, 0, 0, null, 0, null, 0, null, 0, null, null, null, 
> 0, 0, 0, 0, 0, 0, null, null, null, null, null, null, null, 0.0, 0, 0.0, 0, 
> 0.0, 0, null, 0, 0, 0, 0, null, null, null, null, null, null, null, null, 
> null, null, null, null, null, null, null, null ]" [5-197]
>   at org.h2.message.DbException.get(DbException.java:168)
>   at org.h2.message.DbException.convert(DbException.java:307)
>   at 
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:302)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.addToIndex(GridH2Table.java:546)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:479)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:768)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1905)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:404)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:2633)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1646)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1621)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1935)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:428)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2295)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2494)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1951)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1780)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1668)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1153)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:611)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2449)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2426)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1105)
>   at 
>

[jira] [Updated] (IGNITE-10873) CorruptedTreeException during simultaneous cache put operations

2019-01-09 Thread Pavel Vinokurov (JIRA) 


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

Pavel Vinokurov updated IGNITE-10873:
-
Description: 
[2019-01-09 20:47:04,376][ERROR][pool-9-thread-9][GridDhtAtomicCache]  
Unexpected exception during cache update
org.h2.message.DbException: General error: "class 
org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
 Runtime failure on row: Row@780acfb4[ key: .. ][ GTEST, null, 254, null, 
null, null, null, 0, null, null, null, null, null, null, null, 0, 0, 0, null, 
0, 0, 0, 0, 0, 0, 0, null, 0, 0, null, 0, null, 0, null, 0, null, null, null, 
0, 0, 0, 0, 0, 0, null, null, null, null, null, null, null, 0.0, 0, 0.0, 0, 
0.0, 0, null, 0, 0, 0, 0, null, null, null, null, null, null, null, null, null, 
null, null, null, null, null, null, null ]" [5-197]
at org.h2.message.DbException.get(DbException.java:168)
at org.h2.message.DbException.convert(DbException.java:307)
at 
org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:302)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.addToIndex(GridH2Table.java:546)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:479)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:768)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1905)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:404)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:2633)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1646)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1621)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1935)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:428)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2295)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2494)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1951)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1780)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1668)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1153)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:611)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2449)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2426)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1105)
at 
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:820)
at IndexCorruptionReproducer$1.run(IndexCorruptionReproducer.java:43)
at 
java.util.concurrent.Executors$RunnableAdapter.call$$$capture(Executors.java:511)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java)
at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266)
at java.util.concurrent.FutureTask.run(FutureTask.java)
at

[jira] [Created] (IGNITE-10873) CorruptedTreeException during simultaneous cache put operations

2019-01-09 Thread Pavel Vinokurov (JIRA) 
Pavel Vinokurov created IGNITE-10873:


 Summary: CorruptedTreeException during simultaneous cache put 
operations
 Key: IGNITE-10873
 URL: https://issues.apache.org/jira/browse/IGNITE-10873
 Project: Ignite
  Issue Type: Bug
  Components: cache, persistence
Affects Versions: 2.7
Reporter: Pavel Vinokurov


[2019-01-09 20:47:04,376][ERROR][pool-9-thread-9][GridDhtAtomicCache] 
 Unexpected exception during cache update
org.h2.message.DbException: General error: "class 
org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
 Runtime failure on row: Row@780acfb4[ key: model.TbclsrInputKey 
[idHash=1823856383, hash=275143246, clsbInputRef=GTEST, firstInputFlag=254], 
val: model.TbclsrInput [idHash=708235920, hash=-19147671, clsbMatchRef=null, 
origBic=null, desStlmtMbrBic=null, cpBic=null, cpDesSmBic=null, 
desSmManuAuth=0, origRef=null, relatedRef=null, commonRef=null, 
clsbTransRef=null, lastAmdSendRef=null, branchId=null, inputType=null, 
formatType=0, sourceType=0, sourceId=0, operType=null, fwdBookFlag=0, 
possDupFlag=0, sameDayFlag=0, pendingFlag=0, rescOrigSmFlag=0, 
rescCpCpsmFlag=0, stlmtEligFlag=0, authTms=null, ntfId=0, inputStatus=0, 
lastActionTms=null, ofacStatus=0, ofacTms=null, prevInputStatus=0, 
prevTms=null, cpOfacStatus=0, sentDt=null, valueDt=null, tradeDt=null, 
origSuspFlag=0, origSmSuspFlag=0, cpSuspFlag=0, cpSmSuspFlag=0, currSuspFlag=0, 
tpIndicatorFlag=0, tpBic=null, tpReference=null, tpFreeText=null, 
tpFurtherRef=null, tpCustIntRef=null, tpMbrField1=null, tpMbrField2=null, 
exchRate=0.0, currIdBuy=0, volBuy=0.0, currIdSell=0, volSell=0.0, 
inputVersionId=0, versionId=null, grpQueueOrderNo=0, queueOrderNo=0, 
originalGroupId=0, groupStatus=0, usi=null, prevUsi=null, origLei=null, 
cpLei=null, fundLei=null, reportJuris=null, execVenue=null, execTms=null, 
execTmsUtcoff=null, mappingRule=null, reportJuris2=null, usi2=null, 
prevUsi2=null, reportJuris3=null, usi3=null, prevUsi3=null], ver: 
GridCacheVersion [topVer=158536014, order=1547056011256, nodeOrder=1] ][ GTEST, 
null, 254, null, null, null, null, 0, null, null, null, null, null, null, null, 
0, 0, 0, null, 0, 0, 0, 0, 0, 0, 0, null, 0, 0, null, 0, null, 0, null, 0, 
null, null, null, 0, 0, 0, 0, 0, 0, null, null, null, null, null, null, null, 
0.0, 0, 0.0, 0, 0.0, 0, null, 0, 0, 0, 0, null, null, null, null, null, null, 
null, null, null, null, null, null, null, null, null, null ]" [5-197]
at org.h2.message.DbException.get(DbException.java:168)
at org.h2.message.DbException.convert(DbException.java:307)
at 
org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:302)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.addToIndex(GridH2Table.java:546)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:479)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:768)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1905)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:404)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:2633)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1646)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1621)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1935)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:428)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2295)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2494)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1951)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1780)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1668)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)

[jira] [Commented] (IGNITE-10732) Incorrect file.encoding leads to inconsistent SqlFieldsQuery results between nodes

2019-01-09 Thread Pavel Tupitsyn (JIRA) 


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

Pavel Tupitsyn commented on IGNITE-10732:
-

[~ilyak] please revert changes from {{OrdinalIgnoreCase}} to {{Ordinal}}, this 
breaks compatibility.
Otherwise .NET part looks good to me.

> Incorrect file.encoding leads to inconsistent SqlFieldsQuery results between 
> nodes
> --
>
> Key: IGNITE-10732
> URL: https://issues.apache.org/jira/browse/IGNITE-10732
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.4
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Critical
>  Labels: windows
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> When doing 
> {code}
> cache.query(new SqlFieldsQuery("SELECT _key FROM Cache"))
> {code}
> resulting Unicode values may be different when coming from Windows or Linux 
> node.
> Linux nodes will mostly use UTF-8 but Windows nodes will use local Cp 
> encoding to encode query results, as bizzare as it may sound.
> Windows < - > Windows and Linux < - > Linux will get correct result but 
> Windows < - > Linux will get broken strings.
> Note that if cluster has Windows and Linux nodes and cache is REPLICATED, 
> results will be different for subsequent queries!
> There is a workaround for this: set -Dfile.encoding=UTF-8 JVM arg on Windows.
> There is probably an underlying problem in H2 but since non-UTF-8 
> file.encoding is dangerous (it affects String.getBytes()) I think we should 
> peg it to UTF-8.



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

[jira] [Commented] (IGNITE-10732) Incorrect file.encoding leads to inconsistent SqlFieldsQuery results between nodes

2019-01-09 Thread Ignite TC Bot (JIRA) 


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

Ignite TC Bot commented on IGNITE-10732:


{panel:title=-- Run :: All: Possible 
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache (Restarts) 1{color} [[tests 
4|https://ci.ignite.apache.org/viewLog.html?buildId=2752954]]
* IgniteCacheRestartTestSuite: 
GridCacheReplicatedNodeRestartSelfTest.testRestartWithPutFourNodesNoBackups - 
0,0% fails in last 521 master runs.
* IgniteCacheRestartTestSuite: 
GridCachePartitionedNodeRestartTest.testRestartWithTxTwoNodesOneBackup - 0,0% 
fails in last 521 master runs.

{color:#d04437}Cache (Restarts) 2{color} [[tests 
3|https://ci.ignite.apache.org/viewLog.html?buildId=2752955]]
* IgniteCacheRestartTestSuite2: 
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithPutTenNodesTwoBackups
 - 0,0% fails in last 565 master runs.
* IgniteCacheRestartTestSuite2: 
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithPutFourNodesNoBackups
 - 0,0% fails in last 565 master runs.
* IgniteCacheRestartTestSuite2: 
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithTxPutAllTenNodesTwoBackups
 - 0,0% fails in last 565 master runs.

{color:#d04437}Data Structures{color} [[tests 
4|https://ci.ignite.apache.org/viewLog.html?buildId=2752969]]
* IgniteCacheDataStructuresSelfTestSuite: 
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithTxPutAllTenNodesTwoBackups
 - 0,0% fails in last 560 master runs.
* IgniteCacheDataStructuresSelfTestSuite: 
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithPutSixNodesTwoBackups
 - 0,0% fails in last 560 master runs.
* IgniteCacheDataStructuresSelfTestSuite: 
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithPutTenNodesTwoBackups
 - 0,0% fails in last 560 master runs.
* IgniteCacheDataStructuresSelfTestSuite: 
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithPutFourNodesNoBackups
 - 0,0% fails in last 560 master runs.

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

> Incorrect file.encoding leads to inconsistent SqlFieldsQuery results between 
> nodes
> --
>
> Key: IGNITE-10732
> URL: https://issues.apache.org/jira/browse/IGNITE-10732
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.4
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Critical
>  Labels: windows
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> When doing 
> {code}
> cache.query(new SqlFieldsQuery("SELECT _key FROM Cache"))
> {code}
> resulting Unicode values may be different when coming from Windows or Linux 
> node.
> Linux nodes will mostly use UTF-8 but Windows nodes will use local Cp 
> encoding to encode query results, as bizzare as it may sound.
> Windows < - > Windows and Linux < - > Linux will get correct result but 
> Windows < - > Linux will get broken strings.
> Note that if cluster has Windows and Linux nodes and cache is REPLICATED, 
> results will be different for subsequent queries!
> There is a workaround for this: set -Dfile.encoding=UTF-8 JVM arg on Windows.
> There is probably an underlying problem in H2 but since non-UTF-8 
> file.encoding is dangerous (it affects String.getBytes()) I think we should 
> peg it to UTF-8.



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

[jira] [Commented] (IGNITE-10796) Migrate from JUnit 3 to 4 suites involving IgniteTestSuite

2019-01-09 Thread Oleg Ignatenko (JIRA) 


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

Oleg Ignatenko commented on IGNITE-10796:
-

(/) After thoroughly stripping unused stuff it turned out that only useful code 
(for suites that expect {{ignoredOnly}} to be {{false}}) looks as follows...
{code}public class IgniteTestSuite extends TestSuite {
  /**
   * Constructor.
   *
   * @param name Name.
   */
  public IgniteTestSuite(String name) {
  if (name != null)
  setName(name);
  }

  /** {@inheritDoc} */
  @Override public void addTest(Test test) {
  // Ignore empty test suites.
  if (test instanceof IgniteTestSuite) {
  IgniteTestSuite suite = (IgniteTestSuite)test;

  if (suite.testCount() == 0)
  return;
  }

  super.addTest(test);
  }
  }{code}
...which makes its functionality fully covered by plain 
{{junit.framework.TestSuite}} and as such, a subject for same rework as was 
previously done per IGNITE-10774 and IGNITE-10775. As for the class 
{{IgniteTestSuite}}, it should be just removed.

The key parts of above simplification were first, to extract code working with 
suites assuming {{ignoredOnly}} to be {{true}} into separate class (along with 
replacing this obscure parameter with respective constants) and second, 
observing that remaining part invokes constructor with parameter {{Class}} always being null. After the code expecting non-null value 
of this parameter was stripped out from constructor, the rest was only a matter 
of following IDE automatically suggesting removal of unused private methods.

> Migrate from JUnit 3 to 4 suites involving IgniteTestSuite
> --
>
> Key: IGNITE-10796
> URL: https://issues.apache.org/jira/browse/IGNITE-10796
> Project: Ignite
>  Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
>
> This task is to migrate from JUnit 3 to 4 test suites suites involving 
> {{IgniteTestSuite}} API that was introduced per IGNITE-3658.
> If needed, refer parent task comments for more details.



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

[jira] [Updated] (IGNITE-10872) Graceful Shutdowns as Default

2019-01-09 Thread Gabriel Jimenez (JIRA) 


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

Gabriel Jimenez updated IGNITE-10872:
-
Issue Type: Bug  (was: Improvement)

> Graceful Shutdowns as Default
> -
>
> Key: IGNITE-10872
> URL: https://issues.apache.org/jira/browse/IGNITE-10872
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Gabriel Jimenez
>Priority: Major
>
> Our *issue to solve* was to have the grid complete any waiting and currently 
> executing tasks on any termination where the signal was not KILL. With 
> current behavior our tenants were losing data to corruption or incomplete 
> requests due to job/task interruption on shutdown.
> Part of the functionality we were looking for is already exposed in the sense 
> that the kill/stop functions within org.apache.ignite.Ignition already have 
> the 'cancel' flag parameter. However this flag is hardcoded as 'true' in 
> org.apache.ignite.internal.IgnitionEx's default shutdown hook (meaning 
> jobs/tasks will be interrupted). Line in question: 
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/IgnitionEx.java#L2103
>  .
> *Solution:* Currently we have changed IgnitionEx's implementation to depend 
> on an ignite system variable, and set default behavior to drain on 
> termination with any signal other than KILL. Additional Questions:
> Was there an existing solution/approach to our '*issue to solve*' that did 
> not involved changing the codebase?
> Is there another preferred solution for our issue to solve? 



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

[jira] [Updated] (IGNITE-10872) Graceful Shutdowns as Default

2019-01-09 Thread Gabriel Jimenez (JIRA) 


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

Gabriel Jimenez updated IGNITE-10872:
-
Description: 
Our *issue to solve* was to have the grid complete any waiting and currently 
executing tasks on any termination where the signal was not KILL. With current 
behavior our tenants were losing data to corruption or incomplete requests due 
to job/task interruption on shutdown.

Part of the functionality we were looking for is already exposed in the sense 
that the kill/stop functions within org.apache.ignite.Ignition already have the 
'cancel' flag parameter. However this flag is hardcoded as 'true' in 
org.apache.ignite.internal.IgnitionEx's default shutdown hook (meaning 
jobs/tasks will be interrupted). Line in question: 
[https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/IgnitionEx.java#L2103]
 .

*Solution:* Currently we have changed IgnitionEx's implementation to depend on 
an ignite system variable, and set default behavior to drain on termination 
with any signal other than KILL.

Additional Questions:

Was there an existing solution/approach to our '*issue to solve*' that did not 
involved changing the codebase?

Is there another preferred solution for our issue to solve? 

  was:
Our *issue to solve* was to have the grid complete any waiting and currently 
executing tasks on any termination where the signal was not KILL. With current 
behavior our tenants were losing data to corruption or incomplete requests due 
to job/task interruption on shutdown.

Part of the functionality we were looking for is already exposed in the sense 
that the kill/stop functions within org.apache.ignite.Ignition already have the 
'cancel' flag parameter. However this flag is hardcoded as 'true' in 
org.apache.ignite.internal.IgnitionEx's default shutdown hook (meaning 
jobs/tasks will be interrupted). Line in question: 
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/IgnitionEx.java#L2103
 .

*Solution:* Currently we have changed IgnitionEx's implementation to depend on 
an ignite system variable, and set default behavior to drain on termination 
with any signal other than KILL. Additional Questions:

Was there an existing solution/approach to our '*issue to solve*' that did not 
involved changing the codebase?

Is there another preferred solution for our issue to solve? 


> Graceful Shutdowns as Default
> -
>
> Key: IGNITE-10872
> URL: https://issues.apache.org/jira/browse/IGNITE-10872
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Gabriel Jimenez
>Priority: Major
>
> Our *issue to solve* was to have the grid complete any waiting and currently 
> executing tasks on any termination where the signal was not KILL. With 
> current behavior our tenants were losing data to corruption or incomplete 
> requests due to job/task interruption on shutdown.
> Part of the functionality we were looking for is already exposed in the sense 
> that the kill/stop functions within org.apache.ignite.Ignition already have 
> the 'cancel' flag parameter. However this flag is hardcoded as 'true' in 
> org.apache.ignite.internal.IgnitionEx's default shutdown hook (meaning 
> jobs/tasks will be interrupted). Line in question: 
> [https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/IgnitionEx.java#L2103]
>  .
> *Solution:* Currently we have changed IgnitionEx's implementation to depend 
> on an ignite system variable, and set default behavior to drain on 
> termination with any signal other than KILL.
> Additional Questions:
> Was there an existing solution/approach to our '*issue to solve*' that did 
> not involved changing the codebase?
> Is there another preferred solution for our issue to solve? 



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

[jira] [Updated] (IGNITE-10872) Graceful Shutdowns as Default

2019-01-09 Thread Gabriel Jimenez (JIRA) 


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

Gabriel Jimenez updated IGNITE-10872:
-
Description: 
Our *issue to solve* was to have the grid complete any waiting and currently 
executing tasks on any termination where the signal was not KILL. With current 
behavior our tenants were losing data to corruption or incomplete requests due 
to job/task interruption on shutdown.

Part of the functionality we were looking for is already exposed in the sense 
that the kill/stop functions within org.apache.ignite.Ignition already have the 
'cancel' flag parameter. However this flag is hardcoded as 'true' in 
org.apache.ignite.internal.IgnitionEx's default shutdown hook (meaning 
jobs/tasks will be interrupted). Line in question: 
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/IgnitionEx.java#L2103
 .

*Solution:* Currently we have changed IgnitionEx's implementation to depend on 
an ignite system variable, and set default behavior to drain on termination 
with any signal other than KILL. Additional Questions:

Was there an existing solution/approach to our '*issue to solve*' that did not 
involved changing the codebase?

Is there another preferred solution for our issue to solve? 

  was:
Our *issue to solve* was to have the grid complete any waiting and currently 
executing tasks on any termination where the signal was not KILL. With current 
behavior our tenants were losing data to corruption or incomplete requests due 
to job/task interruption on shutdown.

 Part of the functionality we were looking for is already exposed in the sense 
that the kill/stop functions within org.apache.ignite.Ignition already have the 
'cancel' flag parameter. However this flag is hardcoded as 'true' in 
org.apache.ignite.internal.IgnitionEx's default shutdown hook (meaning 
jobs/tasks will be interrupted). Currently we have changed IgnitionEx's 
implementation to depend on an ignite system variable, and set default behavior 
to drain on termination with any signal other than KILL. Additional Questions: 

Was there an existing solution/approach to our '*issue to solve*' that did not 
involved changing the codebase? 

Is there another preferred solution for our issue to solve? 


> Graceful Shutdowns as Default
> -
>
> Key: IGNITE-10872
> URL: https://issues.apache.org/jira/browse/IGNITE-10872
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Reporter: Gabriel Jimenez
>Priority: Major
>
> Our *issue to solve* was to have the grid complete any waiting and currently 
> executing tasks on any termination where the signal was not KILL. With 
> current behavior our tenants were losing data to corruption or incomplete 
> requests due to job/task interruption on shutdown.
> Part of the functionality we were looking for is already exposed in the sense 
> that the kill/stop functions within org.apache.ignite.Ignition already have 
> the 'cancel' flag parameter. However this flag is hardcoded as 'true' in 
> org.apache.ignite.internal.IgnitionEx's default shutdown hook (meaning 
> jobs/tasks will be interrupted). Line in question: 
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/IgnitionEx.java#L2103
>  .
> *Solution:* Currently we have changed IgnitionEx's implementation to depend 
> on an ignite system variable, and set default behavior to drain on 
> termination with any signal other than KILL. Additional Questions:
> Was there an existing solution/approach to our '*issue to solve*' that did 
> not involved changing the codebase?
> Is there another preferred solution for our issue to solve? 



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

[jira] [Created] (IGNITE-10872) Queue Draining on Graceful Shutdowns

2019-01-09 Thread Gabriel Jimenez (JIRA) 
Gabriel Jimenez created IGNITE-10872:


 Summary: Queue Draining on Graceful Shutdowns
 Key: IGNITE-10872
 URL: https://issues.apache.org/jira/browse/IGNITE-10872
 Project: Ignite
  Issue Type: Improvement
  Components: general
Reporter: Gabriel Jimenez


Our *issue to solve* was to have the grid complete any waiting and currently 
executing tasks on any termination where the signal was not KILL. With current 
behavior our tenants were losing data to corruption or incomplete requests due 
to job/task interruption on shutdown.

 Part of the functionality we were looking for is already exposed in the sense 
that the kill/stop functions within org.apache.ignite.Ignition already have the 
'cancel' flag parameter. However this flag is hardcoded as 'true' in 
org.apache.ignite.internal.IgnitionEx's default shutdown hook (meaning 
jobs/tasks will be interrupted). Currently we have changed IgnitionEx's 
implementation to depend on an ignite system variable, and set default behavior 
to drain on termination with any signal other than KILL. Additional Questions: 

Was there an existing solution/approach to our '*issue to solve*' that did not 
involved changing the codebase? 

Is there another preferred solution for our issue to solve? 



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

[jira] [Updated] (IGNITE-10872) Graceful Shutdowns as Default

2019-01-09 Thread Gabriel Jimenez (JIRA) 


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

Gabriel Jimenez updated IGNITE-10872:
-
Summary: Graceful Shutdowns as Default  (was: Queue Draining on Graceful 
Shutdowns)

> Graceful Shutdowns as Default
> -
>
> Key: IGNITE-10872
> URL: https://issues.apache.org/jira/browse/IGNITE-10872
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Reporter: Gabriel Jimenez
>Priority: Major
>
> Our *issue to solve* was to have the grid complete any waiting and currently 
> executing tasks on any termination where the signal was not KILL. With 
> current behavior our tenants were losing data to corruption or incomplete 
> requests due to job/task interruption on shutdown.
>  Part of the functionality we were looking for is already exposed in the 
> sense that the kill/stop functions within org.apache.ignite.Ignition already 
> have the 'cancel' flag parameter. However this flag is hardcoded as 'true' in 
> org.apache.ignite.internal.IgnitionEx's default shutdown hook (meaning 
> jobs/tasks will be interrupted). Currently we have changed IgnitionEx's 
> implementation to depend on an ignite system variable, and set default 
> behavior to drain on termination with any signal other than KILL. Additional 
> Questions: 
> Was there an existing solution/approach to our '*issue to solve*' that did 
> not involved changing the codebase? 
> Is there another preferred solution for our issue to solve? 



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

[jira] [Updated] (IGNITE-9459) MVCC Cache.size corner cases

2019-01-09 Thread Roman Kondakov (JIRA) 


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

Roman Kondakov updated IGNITE-9459:
---
Labels:   (was: mvcc_stabilization_stage_1)

> MVCC Cache.size corner cases
> 
>
> Key: IGNITE-9459
> URL: https://issues.apache.org/jira/browse/IGNITE-9459
> Project: Ignite
>  Issue Type: Bug
>  Components: mvcc
>Reporter: Ivan Pavlukhin
>Priority: Major
>
> During implementation of Cache.size for MVCC some corner cases were found. 
> Attention must be put on:
> {{org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManager#mvccRemoveAll}}
> {{org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManager#mvccInitialValue}}
> {{mvccRemoveAll}} could erroneously decrement size when deleting version 
> which was deleted (having {{newVersion}} committed).
> {{mvccInitialValue}} could increment value over already existing value from 
> history during rebalance.
> It worth carefully reproduce both cases before making any fixes.



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

[jira] [Updated] (IGNITE-9459) MVCC Cache.size corner cases

2019-01-09 Thread Roman Kondakov (JIRA) 


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

Roman Kondakov updated IGNITE-9459:
---
Labels: mvcc_stabilization_stage_1  (was: )

> MVCC Cache.size corner cases
> 
>
> Key: IGNITE-9459
> URL: https://issues.apache.org/jira/browse/IGNITE-9459
> Project: Ignite
>  Issue Type: Bug
>  Components: mvcc
>Reporter: Ivan Pavlukhin
>Priority: Major
>  Labels: mvcc_stabilization_stage_1
>
> During implementation of Cache.size for MVCC some corner cases were found. 
> Attention must be put on:
> {{org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManager#mvccRemoveAll}}
> {{org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManager#mvccInitialValue}}
> {{mvccRemoveAll}} could erroneously decrement size when deleting version 
> which was deleted (having {{newVersion}} committed).
> {{mvccInitialValue}} could increment value over already existing value from 
> history during rebalance.
> It worth carefully reproduce both cases before making any fixes.



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

[jira] [Updated] (IGNITE-10852) [Documentation] - Add details on to public API behaviour

2019-01-09 Thread Prachi Garg (JIRA) 


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

Prachi Garg updated IGNITE-10852:
-
Fix Version/s: 2.8

> [Documentation] - Add details on to public API behaviour
> 
>
> Key: IGNITE-10852
> URL: https://issues.apache.org/jira/browse/IGNITE-10852
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 2.4, 2.5, 2.6, 2.7
>Reporter: Alexander Gerus
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.8
>
>
> Current public API documentation has some specification gaps. In case if 
> method was not successfully executed, it is not clear what should be done by 
> user code.
> Good practice is to describe all API exceptions that can be processed by user 
> code and recommended actions



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

[jira] [Assigned] (IGNITE-10852) [Documentation] - Add details on to public API behaviour

2019-01-09 Thread Prachi Garg (JIRA) 


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

Prachi Garg reassigned IGNITE-10852:


Assignee: Prachi Garg

> [Documentation] - Add details on to public API behaviour
> 
>
> Key: IGNITE-10852
> URL: https://issues.apache.org/jira/browse/IGNITE-10852
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 2.4, 2.5, 2.6, 2.7
>Reporter: Alexander Gerus
>Assignee: Prachi Garg
>Priority: Major
>
> Current public API documentation has some specification gaps. In case if 
> method was not successfully executed, it is not clear what should be done by 
> user code.
> Good practice is to describe all API exceptions that can be processed by user 
> code and recommended actions



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

[jira] [Commented] (IGNITE-10856) cassandra-store seems to be broken by incorrect guava version

2019-01-09 Thread Ilya Kasnacheev (JIRA) 


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

Ilya Kasnacheev commented on IGNITE-10856:
--

[~samaitra] [~slukyanov] please see above

> cassandra-store seems to be broken by incorrect guava version
> -
>
> Key: IGNITE-10856
> URL: https://issues.apache.org/jira/browse/IGNITE-10856
> Project: Ignite
>  Issue Type: Bug
>Reporter: Stanislav Lukyanov
>Assignee: Saikat Maitra
>Priority: Blocker
> Fix For: 2.8
>
>
> IGNITE-9131 upgrade guava from 18 to 25.
> However, cassandra-driver-core:3.0 dependency of the Ignite's cassandra-store 
> requires guava 16-19.
> Need to fix the dependency conflict there.



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

[jira] [Commented] (IGNITE-10856) cassandra-store seems to be broken by incorrect guava version

2019-01-09 Thread Ilya Kasnacheev (JIRA) 


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

Ilya Kasnacheev commented on IGNITE-10856:
--

We seem to have further problems:

We are trying to start Cassandra Embedded, but only Cassandra 3.11.x is 
compatible with our version of Guava.
However, Cassandra driver 3.2.0 doesn't seem to be compatible with Cassandra 
(Embedded) 3.11.x.
Do we want to bump Cassandra driver version further?

> cassandra-store seems to be broken by incorrect guava version
> -
>
> Key: IGNITE-10856
> URL: https://issues.apache.org/jira/browse/IGNITE-10856
> Project: Ignite
>  Issue Type: Bug
>Reporter: Stanislav Lukyanov
>Assignee: Saikat Maitra
>Priority: Blocker
> Fix For: 2.8
>
>
> IGNITE-9131 upgrade guava from 18 to 25.
> However, cassandra-driver-core:3.0 dependency of the Ignite's cassandra-store 
> requires guava 16-19.
> Need to fix the dependency conflict there.



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

[jira] [Assigned] (IGNITE-10860) Exception on GridJobProcessor.stop()

2019-01-09 Thread Anton Kurbanov (JIRA) 


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

Anton Kurbanov reassigned IGNITE-10860:
---

Assignee: Anton Kurbanov

> Exception on GridJobProcessor.stop()
> 
>
> Key: IGNITE-10860
> URL: https://issues.apache.org/jira/browse/IGNITE-10860
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Kurbanov
>Assignee: Anton Kurbanov
>Priority: Minor
>
> IGNITE-9056 made calling clear() to throw UnsupportedOperationException from 
> org.jsr166.ConcurrentLinkedHashMap.
>  
> Need to verify all calls to .clear().
>  
> java.lang.UnsupportedOperationException: null
>  at 
> org.jsr166.ConcurrentLinkedHashMap.clear(ConcurrentLinkedHashMap.java:1551)
>  at 
> org.apache.ignite.internal.processors.job.GridJobProcessor.stop(GridJobProcessor.java:264)
>  at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2356)
>  at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2228)
>  at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2612)
>  at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2575)
>  at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:379)
>  at org.apache.ignite.Ignition.stop(Ignition.java:225)
>  at org.apache.ignite.internal.IgniteKernal.close(IgniteKernal.java:3568)



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

[jira] [Commented] (IGNITE-10377) MVCC: Incorrect exception is thrown if no data nodes found for a partition.

2019-01-09 Thread Andrew Mashenkov (JIRA) 


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

Andrew Mashenkov commented on IGNITE-10377:
---

[~rkondakov], this was partially resolved.

NotMappedPartitionInTxTest still fails due to unexpected exception message and 
requires trivial fix.
Also, this ticket is mentioned in number of TODO's in 
CacheMvccAbstractSqlCoordinatorFailoverTest.

Seems, we have to fix Exception handling for sql queries as well.
 

> MVCC: Incorrect exception is thrown if no data nodes found for a partition.
> ---
>
> Key: IGNITE-10377
> URL: https://issues.apache.org/jira/browse/IGNITE-10377
> Project: Ignite
>  Issue Type: Bug
>  Components: mvcc
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Major
>  Labels: mvcc_stabilization_stage_1, transactions
> Fix For: 2.8
>
>
> See NotMappedPartitionInTxTest.
> ClusterTopologyServerNotFoundException is expected, instead of 
> "ClusterTopologyCheckedException: Failed to get primary node" 



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

[jira] [Updated] (IGNITE-10871) MVCC: Fix SPI exception handling in mvcc mode.

2019-01-09 Thread Andrew Mashenkov (JIRA) 


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

Andrew Mashenkov updated IGNITE-10871:
--
Issue Type: Bug  (was: Task)

> MVCC: Fix SPI exception handling in mvcc mode.
> --
>
> Key: IGNITE-10871
> URL: https://issues.apache.org/jira/browse/IGNITE-10871
> Project: Ignite
>  Issue Type: Bug
>  Components: mvcc
>Reporter: Andrew Mashenkov
>Priority: Minor
>
> Next tests are failed due to wrong IgniteSpiException handling.
> GridCacheReplicatedTxExceptionSelfTest
> GridCacheColocatedTxExceptionSelfTest
>  
> TransactionHeuristicException expected, but CacheException is actually thrown.



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

[jira] [Commented] (IGNITE-6826) Change default DiscoverySpi ipFinder type for examples

2019-01-09 Thread Ignite TC Bot (JIRA) 


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

Ignite TC Bot commented on IGNITE-6826:
---

{panel:title=-- Run :: All: No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2750802buildTypeId=IgniteTests24Java8_RunAll]

> Change default DiscoverySpi ipFinder type for examples
> --
>
> Key: IGNITE-6826
> URL: https://issues.apache.org/jira/browse/IGNITE-6826
> Project: Ignite
>  Issue Type: Improvement
>  Components: examples
>Affects Versions: 2.3
>Reporter: Alexey Popov
>Assignee: Ryabov Dmitrii
>Priority: Major
>  Labels: newbie
> Fix For: 2.8
>
>
> It is better to change multicast ipFinder to static (vm) ipFinder for java 
> examples, .NET examples and C++ examples.
> http://apache-ignite-developers.2346864.n4.nabble.com/ipFinder-configuration-for-Samples-td23818.html



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

[jira] [Created] (IGNITE-10871) MVCC: Fix SPI exception handling in mvcc mode.

2019-01-09 Thread Andrew Mashenkov (JIRA) 
Andrew Mashenkov created IGNITE-10871:
-

 Summary: MVCC: Fix SPI exception handling in mvcc mode.
 Key: IGNITE-10871
 URL: https://issues.apache.org/jira/browse/IGNITE-10871
 Project: Ignite
  Issue Type: Task
  Components: mvcc
Reporter: Andrew Mashenkov


Next tests are failed due to wrong IgniteSpiException handling.

GridCacheReplicatedTxExceptionSelfTest
GridCacheColocatedTxExceptionSelfTest

 

TransactionHeuristicException expected, but CacheException is actually thrown.



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

[jira] [Updated] (IGNITE-10871) MVCC: Fix SPI exception handling in mvcc mode.

2019-01-09 Thread Andrew Mashenkov (JIRA) 


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

Andrew Mashenkov updated IGNITE-10871:
--
Labels: Transactions mvcc_stabilization_stage_1  (was: )

> MVCC: Fix SPI exception handling in mvcc mode.
> --
>
> Key: IGNITE-10871
> URL: https://issues.apache.org/jira/browse/IGNITE-10871
> Project: Ignite
>  Issue Type: Bug
>  Components: mvcc
>Reporter: Andrew Mashenkov
>Priority: Minor
>  Labels: Transactions, mvcc_stabilization_stage_1
>
> Next tests are failed due to wrong IgniteSpiException handling.
> GridCacheReplicatedTxExceptionSelfTest
> GridCacheColocatedTxExceptionSelfTest
>  
> TransactionHeuristicException expected, but CacheException is actually thrown.



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

[jira] [Created] (IGNITE-10869) [ML] Add MultiClass classification metrics

2019-01-09 Thread Aleksey Zinoviev (JIRA) 
Aleksey Zinoviev created IGNITE-10869:
-

 Summary: [ML] Add MultiClass classification metrics
 Key: IGNITE-10869
 URL: https://issues.apache.org/jira/browse/IGNITE-10869
 Project: Ignite
  Issue Type: Sub-task
  Components: ml
Affects Versions: 2.8
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev
 Fix For: 2.8


Add ability to calculate multiple metrics (as binary metrics) for multiclass 
classification

It can be merged with OneVsRest approach



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

[jira] [Created] (IGNITE-10870) [ML] Add an example for KNN/LogReg and multi-class task full Iris dataset

2019-01-09 Thread Aleksey Zinoviev (JIRA) 
Aleksey Zinoviev created IGNITE-10870:
-

 Summary: [ML] Add an example for KNN/LogReg and multi-class task 
full Iris dataset
 Key: IGNITE-10870
 URL: https://issues.apache.org/jira/browse/IGNITE-10870
 Project: Ignite
  Issue Type: Sub-task
  Components: ml
Affects Versions: 2.8
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev
 Fix For: 2.8


Add a one or two examples for KNN/LogReg and Iris dataset with 3 classes



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

[jira] [Commented] (IGNITE-10794) MVCC: RemoveAll is broken on unstable topology

2019-01-09 Thread Ignite TC Bot (JIRA) 


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

Ignite TC Bot commented on IGNITE-10794:


{panel:title=-- Run :: All: Possible 
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}ZooKeeper (Discovery) 3{color} [[tests 0 TIMEOUT , Exit Code 
|https://ci.ignite.apache.org/viewLog.html?buildId=2635928]]
* GridEventConsumeSelfTest.testStopByCallback (last started)

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

> MVCC: RemoveAll is broken on unstable topology
> --
>
> Key: IGNITE-10794
> URL: https://issues.apache.org/jira/browse/IGNITE-10794
> Project: Ignite
>  Issue Type: Bug
>  Components: mvcc
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Critical
>  Labels: Hanging, mvcc_stabilization_stage_1, transaction
> Fix For: 2.8
>
>
> Enlist batch holds key and values in arrays structures. This implies that 
> keys and vals arrays sizes should be equals.
> Also, we have an optimization and do not save 'null' vals for 'remove' 
> operation.
> This invariant can become broken on removeAll operation for 2 entries 
> belonging to partitions in different states (moving and owning). For the 
> first one, it's 'mvcc history' will be added to 'vals' array, but nothing 
> will be added for the second one.
> Reproducer IgniteCacheEntryProcessorNodeJoinTest.testEntryProcessorNodeLeave
> See stacktrace:
> {noformat}
> java.lang.AssertionError: 
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture$Batch.add(GridDhtTxAbstractEnlistFuture.java:1156)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.addToBatch(GridDhtTxAbstractEnlistFuture.java:705)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.processEntry(GridDhtTxAbstractEnlistFuture.java:650)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.continueLoop(GridDhtTxAbstractEnlistFuture.java:533)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.init(GridDhtTxAbstractEnlistFuture.java:362)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistFuture.enlistLocal(GridNearTxEnlistFuture.java:531)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistFuture.sendBatch(GridNearTxEnlistFuture.java:426)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistFuture.sendNextBatches(GridNearTxEnlistFuture.java:173)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistFuture.map(GridNearTxEnlistFuture.java:149)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxAbstractEnlistFuture.mapOnTopology(GridNearTxAbstractEnlistFuture.java:342)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxAbstractEnlistFuture.init(GridNearTxAbstractEnlistFuture.java:257)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.updateAsync(GridNearTxLocal.java:2074)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.mvccRemoveAllAsync0(GridNearTxLocal.java:1951)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.removeAllAsync0(GridNearTxLocal.java:1670)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.removeAllAsync(GridNearTxLocal.java:550)
> {noformat}



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

[jira] [Commented] (IGNITE-10421) MVCC: Assertion in checkpointer thread.

2019-01-09 Thread Ignite TC Bot (JIRA) 


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

Ignite TC Bot commented on IGNITE-10421:


{panel:title=-- Run :: All: No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2645104buildTypeId=IgniteTests24Java8_RunAll]

> MVCC: Assertion in checkpointer thread.
> ---
>
> Key: IGNITE-10421
> URL: https://issues.apache.org/jira/browse/IGNITE-10421
> Project: Ignite
>  Issue Type: Bug
>  Components: mvcc, persistence
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Critical
>  Labels: WAL, mvcc_stabilization_stage_1
> Fix For: 2.8
>
>
> Reproducers:
>  * {{WalModeChangeAdvancedSelfTest#testJoin}} with enabled MVCC.
>  * {{IgniteDynamicCacheStartFailWithPersistenceTest}}
> {noformat}
> [2018-11-27 
> 14:56:47,548][ERROR][db-checkpoint-thread-#358%srv_3%][IgniteTestResources] 
> Critical system error detected. Will be handled accordingly to configured 
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler 
> [ignoredFailureTypes=SingletonSet [SYSTEM_WORKER_BLOCKED]]], 
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class 
> o.a.i.IgniteCheckedException: Compound exception for CountDownFuture.]]
> class org.apache.ignite.IgniteCheckedException: Compound exception for 
> CountDownFuture.
>   at 
> org.apache.ignite.internal.util.future.CountDownFuture.addError(CountDownFuture.java:72)
>   at 
> org.apache.ignite.internal.util.future.CountDownFuture.onDone(CountDownFuture.java:46)
>   at 
> org.apache.ignite.internal.util.future.CountDownFuture.onDone(CountDownFuture.java:28)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:3957)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at java.lang.Thread.run(Thread.java:748)
>   Suppressed: java.lang.AssertionError: off=3000, 
> allocated=1000, pageId=00020002, 
> file=/home/gridgain/Documents/work/incubator-ignite/work/db/node02-20092321-f30d-498f-8609-21ff87e4d104/TxLog/index.bin
>   at 
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.write(FilePageStore.java:550)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.writeInternal(FilePageStoreManager.java:520)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.writePages(GridCacheDatabaseSharedManager.java:4022)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:3930)
>   ... 3 more
>   Suppressed: java.lang.AssertionError: off=4000, 
> allocated=1000, pageId=00020003, 
> file=/home/gridgain/Documents/work/incubator-ignite/work/db/node02-20092321-f30d-498f-8609-21ff87e4d104/TxLog/index.bin
>   at 
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.write(FilePageStore.java:550)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.writeInternal(FilePageStoreManager.java:520)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.writePages(GridCacheDatabaseSharedManager.java:4022)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:3930)
>   ... 3 more
>   Suppressed: java.lang.AssertionError: off=2000, 
> allocated=1000, pageId=00020001, 
> file=/home/gridgain/Documents/work/incubator-ignite/work/db/node02-20092321-f30d-498f-8609-21ff87e4d104/TxLog/index.bin
>   at 
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.write(FilePageStore.java:550)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.writeInternal(FilePageStoreManager.java:520)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.writePages(GridCacheDatabaseSharedManager.java:4022)

[jira] [Commented] (IGNITE-10864) JDK11: fix check jdk version at the ignite.bat

2019-01-09 Thread Vladimir Ozerov (JIRA) 


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

Vladimir Ozerov commented on IGNITE-10864:
--

[~tledkov-gridgain], looks good to me. But we need to perform excessive testing 
of {{ignite.bat}} functionality before merge.

> JDK11: fix check jdk version at the ignite.bat
> --
>
> Key: IGNITE-10864
> URL: https://issues.apache.org/jira/browse/IGNITE-10864
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.8
>
>
> The JDK version check is invalid at the ignite.bat.
> *Root cause:* trailing space at the parsed JDK version.



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

[jira] [Commented] (IGNITE-10580) H2 connection and statements are reused invalid for local sql queries

2019-01-09 Thread Ignite TC Bot (JIRA) 


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

Ignite TC Bot commented on IGNITE-10580:


{panel:title=-- Run :: All: No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2750699buildTypeId=IgniteTests24Java8_RunAll]

> H2 connection and statements are reused invalid for local sql queries
> -
>
> Key: IGNITE-10580
> URL: https://issues.apache.org/jira/browse/IGNITE-10580
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.7
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.8
>
>
> The threadlocal connection & statement cache is used invalid for local 
> queries.
> Steps to reproduce:
> # Open iterator for local query {{Query0}};
> # In the same thread open one more iterator for {{Query1}} (SQl statement 
> must be equals to {{Query0}} and doesn't contains query parameters);
> # Fetch from the first iterator.
> The exception {{The object is already closed [90007-197]}} will be thrown.



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

[jira] [Commented] (IGNITE-10778) MVCC: Invoke request may hang sometimes

2019-01-09 Thread Igor Seliverstov (JIRA) 


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

Igor Seliverstov commented on IGNITE-10778:
---

[~rkondakov], Timeout increasing doesn't look like good fix from my point of 
view. In case there is a kind of load testing here, lets just turn it into time 
based test instead of counting iterations - this should be more predictable

> MVCC: Invoke request may hang sometimes
> ---
>
> Key: IGNITE-10778
> URL: https://issues.apache.org/jira/browse/IGNITE-10778
> Project: Ignite
>  Issue Type: Bug
>  Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
>  Labels: Hanging, mvcc_stabilization_stage_1
> Fix For: 2.8
>
>
> Invoke request may hang sometimes. Reproducer: 
> {{GridCacheMultinodeUpdateSelfTest.testInvoke}} with enabled MVCC.
> Stacktrace:
> {noformat}
> Thread [name="invoke-3", id=447, state=WAITING, blockCnt=0, waitCnt=1745]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at 
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.rollback(GridNearTxLocal.java:3792)
> at 
> o.a.i.i.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4256)
> at 
> o.a.i.i.processors.cache.GridCacheAdapter.invoke0(GridCacheAdapter.java:2608)
> at 
> o.a.i.i.processors.cache.GridCacheAdapter.invoke(GridCacheAdapter.java:2586)
> at 
> o.a.i.i.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1437)
> at 
> o.a.i.i.processors.cache.GatewayProtectedCacheProxy.invoke(GatewayProtectedCacheProxy.java:1204)
> at 
> o.a.i.i.processors.cache.GridCacheMultinodeUpdateAbstractSelfTest$1.call(GridCacheMultinodeUpdateAbstractSelfTest.java:111)
> at 
> o.a.i.i.processors.cache.GridCacheMultinodeUpdateAbstractSelfTest$1.call(GridCacheMultinodeUpdateAbstractSelfTest.java:100)
> at o.a.i.testframework.GridTestThread.run(GridTestThread.java:84)
> Thread [name="invoke-2", id=446, state=WAITING, blockCnt=0, waitCnt=1738]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at 
> o.a.i.i.processors.cache.mvcc.MvccUtils.requestSnapshot(MvccUtils.java:841)
> at 
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.mvccPutAllAsync0(GridNearTxLocal.java:723)
> at 
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.putAsync0(GridNearTxLocal.java:578)
> at 
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.invokeAsync(GridNearTxLocal.java:467)
> at 
> o.a.i.i.processors.cache.GridCacheAdapter$25.op(GridCacheAdapter.java:2620)
> at 
> o.a.i.i.processors.cache.GridCacheAdapter$25.op(GridCacheAdapter.java:2608)
> at 
> o.a.i.i.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4244)
> at 
> o.a.i.i.processors.cache.GridCacheAdapter.invoke0(GridCacheAdapter.java:2608)
> at 
> o.a.i.i.processors.cache.GridCacheAdapter.invoke(GridCacheAdapter.java:2586)
> at 
> o.a.i.i.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1437)
> at 
> o.a.i.i.processors.cache.GatewayProtectedCacheProxy.invoke(GatewayProtectedCacheProxy.java:1204)
> at 
> o.a.i.i.processors.cache.GridCacheMultinodeUpdateAbstractSelfTest$1.call(GridCacheMultinodeUpdateAbstractSelfTest.java:111)
> at 
> o.a.i.i.processors.cache.GridCacheMultinodeUpdateAbstractSelfTest$1.call(GridCacheMultinodeUpdateAbstractSelfTest.java:100)
> at o.a.i.testframework.GridTestThread.run(GridTestThread.java:84)
> Thread [name="invoke-1", id=445, state=WAITING, blockCnt=0, waitCnt=1916]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at 
> o.a.i.i.processors.cache.GridCacheAdapter$25.op(GridCacheAdapter.java:2626)
> at 
> o.a.i.i.processors.cache.GridCacheAdapter$25.op(GridCacheAdapter.java:2608)
> at 
> o.a.i.i.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4244)
> at 
>

[jira] [Comment Edited] (IGNITE-10846) Improve docs for "Disabling WAL Archiving"

2019-01-09 Thread Artem Budnikov (JIRA) 


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

Artem Budnikov edited comment on IGNITE-10846 at 1/9/19 2:47 PM:
-

[~dmagda]

I don't think WAL archive can help to accelerate rebalancing when a new node 
joins the cluster. In this case, a number of partitions has to move to the new 
node and you can't help it. Correct me if I'm wrong.

Also, I think we should mention that if the WAL archive is disabled, the size 
of the WAL is not 10 segments but is defined by the 
`DataStorageConfiguration.maxWalArchiveSize` property.

Also, I encountered an issue: 
https://issues.apache.org/jira/browse/IGNITE-10868. If this behavior is 
expected, it should be documented.


was (Author: artem budnikov):
[~dmagda]

I don't think WAL archive can help to accelerate rebalancing when a new node 
joins the cluster. In this case, a number of partitions has to move to the new 
node and you can't help it. Correct me if I'm wrong.

Also, I think we should mention that if the WAL archive is disabled, the size 
of the WAL is not 10 segments but is defined by the 
`DataStorageConfiguration.maxWalArchiveSize` property.

> Improve docs for "Disabling WAL Archiving"
> --
>
> Key: IGNITE-10846
> URL: https://issues.apache.org/jira/browse/IGNITE-10846
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Prachi Garg
>Assignee: Artem Budnikov
>Priority: Critical
> Fix For: 2.8
>
>
> Provide pros and cons of disabling WAL Archiving.



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

[jira] [Comment Edited] (IGNITE-10846) Improve docs for "Disabling WAL Archiving"

2019-01-09 Thread Artem Budnikov (JIRA) 


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

Artem Budnikov edited comment on IGNITE-10846 at 1/9/19 2:39 PM:
-

[~dmagda]

I don't think WAL archive can help to accelerate rebalancing when a new node 
joins the cluster. In this case, a number of partitions has to move to the new 
node and you can't help it. Correct me if I'm wrong.

Also, I think we should mention that if the WAL archive is disabled, the size 
of the WAL is not 10 segments but is defined by the 
`DataStorageConfiguration.maxWalArchiveSize` property.


was (Author: artem budnikov):
[~dmagda] 

I don't think WAL archive can help to accelerate rebalancing when a new node 
joins the cluster. In this case, a number of partitions has to move to the new 
node and you can't help it.

Also, I think we should mention that if the WAL archive is disabled, the size 
of the WAL is not 10 segments but is defined by the 
`DataStorageConfiguration.maxWalArchiveSize` property.

> Improve docs for "Disabling WAL Archiving"
> --
>
> Key: IGNITE-10846
> URL: https://issues.apache.org/jira/browse/IGNITE-10846
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Prachi Garg
>Assignee: Artem Budnikov
>Priority: Critical
> Fix For: 2.8
>
>
> Provide pros and cons of disabling WAL Archiving.



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

[jira] [Commented] (IGNITE-10846) Improve docs for "Disabling WAL Archiving"

2019-01-09 Thread Artem Budnikov (JIRA) 


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

Artem Budnikov commented on IGNITE-10846:
-

[~dmagda] 

I don't think WAL archive can help to accelerate rebalancing when a new node 
joins the cluster. In this case, a number of partitions has to move to the new 
node and you can't help it.

Also, I think we should mention that if the WAL archive is disabled, the size 
of the WAL is not 10 segments but is defined by the 
`DataStorageConfiguration.maxWalArchiveSize` property.

> Improve docs for "Disabling WAL Archiving"
> --
>
> Key: IGNITE-10846
> URL: https://issues.apache.org/jira/browse/IGNITE-10846
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Prachi Garg
>Assignee: Artem Budnikov
>Priority: Critical
> Fix For: 2.8
>
>
> Provide pros and cons of disabling WAL Archiving.



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

[jira] [Commented] (IGNITE-10763) MVCC: Transaction already completed error in some tests

2019-01-09 Thread Igor Seliverstov (JIRA) 


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

Igor Seliverstov commented on IGNITE-10763:
---

[~Pavlukhin], could you move context reset into SFU future {{onDone()}} and 
{{GridNearTxLocal#updateAsync()}} methods?

> MVCC: Transaction already completed error in some tests
> ---
>
> Key: IGNITE-10763
> URL: https://issues.apache.org/jira/browse/IGNITE-10763
> Project: Ignite
>  Issue Type: Bug
>  Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Ivan Pavlukhin
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, mvcc_stabilization_stage_1, 
> transactions
> Fix For: 2.8
>
>
>  "Transaction is already completed" error occurs time to time in some tests. 
> Reproducer:
> {{CacheMvccReplicatedSqlTxQueriesTest.testReplicatedAndPartitionedUpdateSingleTransaction}}
> {{CacheMvccPartitionedSqlTxQueriesWithReducerTest.testQueryReducerDeadlockInsertWithTxTimeout}}
>  
> {noformat}
> class org.apache.ignite.internal.processors.query.IgniteSQLException: 
> Transaction is already completed.
>   at 
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.checkActive(MvccUtils.java:660)
>   at 
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.requestSnapshot(MvccUtils.java:832)
>   at 
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:813)
>   at 
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:796)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.runQueryTwoStep(IgniteH2Indexing.java:1131)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunDistributedQuery(IgniteH2Indexing.java:1990)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:1636)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1526)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$3.applyx(GridQueryProcessor.java:2167)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$3.applyx(GridQueryProcessor.java:2162)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2670)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$1(GridQueryProcessor.java:2176)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2196)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2157)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2118)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2091)
>   at 
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccReplicatedSqlTxQueriesTest.runSql(CacheMvccReplicatedSqlTxQueriesTest.java:234)
>   at 
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccReplicatedSqlTxQueriesTest.testReplicatedAndPartitionedUpdateSingleTransaction(CacheMvccReplicatedSqlTxQueriesTest.java:202)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2121)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}



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

[jira] [Updated] (IGNITE-10864) JDK11: fix check jdk version at the ignite.bat

2019-01-09 Thread Taras Ledkov (JIRA) 


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

Taras Ledkov updated IGNITE-10864:
--
Description: 
The JDK version check is invalid at the ignite.bat.
*Root cause:* trailing space at the parsed JDK version.

  was:
THe JDK version check is invalid at the ignite.bat.
*Root cause:* trailing space at the parsed JDK version.


> JDK11: fix check jdk version at the ignite.bat
> --
>
> Key: IGNITE-10864
> URL: https://issues.apache.org/jira/browse/IGNITE-10864
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.8
>
>
> The JDK version check is invalid at the ignite.bat.
> *Root cause:* trailing space at the parsed JDK version.



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

[jira] [Created] (IGNITE-10868) WAL segments are removed from WAL archive after each checkpoint

2019-01-09 Thread Artem Budnikov (JIRA) 
Artem Budnikov created IGNITE-10868:
---

 Summary: WAL segments are removed from WAL archive after each 
checkpoint
 Key: IGNITE-10868
 URL: https://issues.apache.org/jira/browse/IGNITE-10868
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.7
Reporter: Artem Budnikov
Assignee: Alexey Goncharuk


The WAL archive is cleaned up after each checkpoint. This does not cause issues 
for end users; however, an empty WAL archive won't help in case of historical 
rebalancing. But our documentation says that it does. Please investigate.



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

[jira] [Resolved] (IGNITE-8837) windows ignite.bat ignores command-line parameters with the count of arguments-J greater than 4

2019-01-09 Thread Ilya Kasnacheev (JIRA) 


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

Ilya Kasnacheev resolved IGNITE-8837.
-
Resolution: Invalid

This is not our bug, rather OpenJDK bug which is fixed in JDK9. Upgrade is 
recommended for those who is bitten. Not work-aroundable on our side.

> windows ignite.bat ignores command-line parameters with the count of 
> arguments-J greater than 4
> ---
>
> Key: IGNITE-8837
> URL: https://issues.apache.org/jira/browse/IGNITE-8837
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.5
> Environment: Windows 10
> java version "1.8.0_171"
> Java(TM) SE Runtime Environment (build 1.8.0_171-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.171-b11, mixed mode)
>Reporter: ARomantsov
>Assignee: Ilya Kasnacheev
>Priority: Major
> Fix For: 2.8
>
> Attachments: run_with_4arg-J.txt, run_with_5arg-J.txt
>
>
> Try to run 
> C:\Users\artur\Downloads\apache-ignite-fabric-2.5.0-bin\apache-ignite-fabric-2.5.0-bin>bin\ignite.bat
>  
> C:\Users\artur\Downloads\apache-ignite-fabric-2.5.0-bin\apache-ignite-fabric-2.5.0-bin\examples\config\example-data-regions.xml
>  -v -J-Da1=1 -J-Da2=2 -J-Da3=3 -J-DA4=4 > run_with_4arg-J.txt 2>&1
> *Run ok, take normal config*
> C:\Users\artur\Downloads\apache-ignite-fabric-2.5.0-bin\apache-ignite-fabric-2.5.0-bin>bin\ignite.bat
>  
> C:\Users\artur\Downloads\apache-ignite-fabric-2.5.0-bin\apache-ignite-fabric-2.5.0-bin\examples\config\example-data-regions.xml
>  -v -J-Da1=1 -J-Da2=2 -J-Da3=3 -J-DA4=4 -J-DA5=5 > run_with_5arg-J.txt
> *Run not ok, ignoring all options and take default config*
>  
>  



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

[jira] [Comment Edited] (IGNITE-10796) Migrate from JUnit 3 to 4 suites involving IgniteTestSuite

2019-01-09 Thread Oleg Ignatenko (JIRA) 


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

Oleg Ignatenko edited comment on IGNITE-10796 at 1/9/19 2:11 PM:
-

(i) Yet another thing I noticed after cleaning up as mentioned in prior comment 
is, there is something strange about {{ignoredOnly}} member value.

It looks like all testsuites except for two (more on these below) except this 
value to be always {{false}}. So far so good, okay...

Now, there are two suites that expect this value to be always {{true}}: 
IgniteIgnoredBinaryTestSuite and IgniteIgnoredBinarySimpleMapperTestSuite. This 
is also okay, except that the way how this value is set 
({{IgniteTestSuite.ignoreDefault(true)}}) would impact execution of all other 
suites in case if one of these happens to run in between these.

I re-checked with [~vozerov] who wrote mentioned suites per IGNITE-3980 and he 
suggests that undocumented assumption is that they are expected to be always 
executed separately from the rest. I plan to change code so that it is 
guaranteed that suites won't affect each other. Also, since these two special 
test suites appear to be somewhat complicate I plan to rework these separately 
from the rest, per IGNITE-10777.


was (Author: oignatenko):
(i) Yet another thing I noticed after cleaning up as mentioned in prior comment 
is, there is something strange about {{ignoredOnly}} member value.

It looks like all testsuites except for two (more on these below) except this 
value to be always {{false}}. So far so good, okay...

Now, there are two suites that expect this value to be always {{true}}: 
IgniteIgnoredBinaryTestSuite and IgniteIgnoredBinarySimpleMapperTestSuite. This 
is also okay, except that the way how this value is set 
({{IgniteTestSuite.ignoreDefault(true)}}) would impact execution of all other 
suites in case if one of these happens to run in between these.

I re-checked with [~vozerov] who wrote mentioned suites per IGNITE-3980 and he 
suggests that undocumented assumption is that they are expected to be always 
executed separately from the rest. I plan to change code so that it is 
guaranteed that suites won't affect each other.

> Migrate from JUnit 3 to 4 suites involving IgniteTestSuite
> --
>
> Key: IGNITE-10796
> URL: https://issues.apache.org/jira/browse/IGNITE-10796
> Project: Ignite
>  Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
>
> This task is to migrate from JUnit 3 to 4 test suites suites involving 
> {{IgniteTestSuite}} API that was introduced per IGNITE-3658.
> If needed, refer parent task comments for more details.



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

[jira] [Created] (IGNITE-10867) Document work-around JDK upgrade against command-line parsing bug on Windows

2019-01-09 Thread Ilya Kasnacheev (JIRA) 
Ilya Kasnacheev created IGNITE-10867:


 Summary: Document work-around JDK upgrade against command-line 
parsing bug on Windows
 Key: IGNITE-10867
 URL: https://issues.apache.org/jira/browse/IGNITE-10867
 Project: Ignite
  Issue Type: Task
  Components: documentation
Affects Versions: 2.5
Reporter: Ilya Kasnacheev
Assignee: Denis Magda






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

[jira] [Updated] (IGNITE-8837) windows ignite.bat ignores command-line parameters with the count of arguments-J greater than 4

2019-01-09 Thread Ilya Kasnacheev (JIRA) 


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

Ilya Kasnacheev updated IGNITE-8837:

Ignite Flags: Docs Required

> windows ignite.bat ignores command-line parameters with the count of 
> arguments-J greater than 4
> ---
>
> Key: IGNITE-8837
> URL: https://issues.apache.org/jira/browse/IGNITE-8837
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.5
> Environment: Windows 10
> java version "1.8.0_171"
> Java(TM) SE Runtime Environment (build 1.8.0_171-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.171-b11, mixed mode)
>Reporter: ARomantsov
>Assignee: Ilya Kasnacheev
>Priority: Major
> Attachments: run_with_4arg-J.txt, run_with_5arg-J.txt
>
>
> Try to run 
> C:\Users\artur\Downloads\apache-ignite-fabric-2.5.0-bin\apache-ignite-fabric-2.5.0-bin>bin\ignite.bat
>  
> C:\Users\artur\Downloads\apache-ignite-fabric-2.5.0-bin\apache-ignite-fabric-2.5.0-bin\examples\config\example-data-regions.xml
>  -v -J-Da1=1 -J-Da2=2 -J-Da3=3 -J-DA4=4 > run_with_4arg-J.txt 2>&1
> *Run ok, take normal config*
> C:\Users\artur\Downloads\apache-ignite-fabric-2.5.0-bin\apache-ignite-fabric-2.5.0-bin>bin\ignite.bat
>  
> C:\Users\artur\Downloads\apache-ignite-fabric-2.5.0-bin\apache-ignite-fabric-2.5.0-bin\examples\config\example-data-regions.xml
>  -v -J-Da1=1 -J-Da2=2 -J-Da3=3 -J-DA4=4 -J-DA5=5 > run_with_5arg-J.txt
> *Run not ok, ignoring all options and take default config*
>  
>  



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

[jira] [Updated] (IGNITE-8837) windows ignite.bat ignores command-line parameters with the count of arguments-J greater than 4

2019-01-09 Thread Ilya Kasnacheev (JIRA) 


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

Ilya Kasnacheev updated IGNITE-8837:

Fix Version/s: (was: 2.8)

> windows ignite.bat ignores command-line parameters with the count of 
> arguments-J greater than 4
> ---
>
> Key: IGNITE-8837
> URL: https://issues.apache.org/jira/browse/IGNITE-8837
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.5
> Environment: Windows 10
> java version "1.8.0_171"
> Java(TM) SE Runtime Environment (build 1.8.0_171-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.171-b11, mixed mode)
>Reporter: ARomantsov
>Assignee: Ilya Kasnacheev
>Priority: Major
> Attachments: run_with_4arg-J.txt, run_with_5arg-J.txt
>
>
> Try to run 
> C:\Users\artur\Downloads\apache-ignite-fabric-2.5.0-bin\apache-ignite-fabric-2.5.0-bin>bin\ignite.bat
>  
> C:\Users\artur\Downloads\apache-ignite-fabric-2.5.0-bin\apache-ignite-fabric-2.5.0-bin\examples\config\example-data-regions.xml
>  -v -J-Da1=1 -J-Da2=2 -J-Da3=3 -J-DA4=4 > run_with_4arg-J.txt 2>&1
> *Run ok, take normal config*
> C:\Users\artur\Downloads\apache-ignite-fabric-2.5.0-bin\apache-ignite-fabric-2.5.0-bin>bin\ignite.bat
>  
> C:\Users\artur\Downloads\apache-ignite-fabric-2.5.0-bin\apache-ignite-fabric-2.5.0-bin\examples\config\example-data-regions.xml
>  -v -J-Da1=1 -J-Da2=2 -J-Da3=3 -J-DA4=4 -J-DA5=5 > run_with_5arg-J.txt
> *Run not ok, ignoring all options and take default config*
>  
>  



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

[jira] [Commented] (IGNITE-10796) Migrate from JUnit 3 to 4 suites involving IgniteTestSuite

2019-01-09 Thread Oleg Ignatenko (JIRA) 


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

Oleg Ignatenko commented on IGNITE-10796:
-

(i) Yet another thing I noticed after cleaning up as mentioned in prior comment 
is, there is something strange about {{ignoredOnly}} member value.

It looks like all testsuites except for two (more on these below) except this 
value to be always {{false}}. So far so good, okay...

Now, there are two suites that expect this value to be always {{true}}: 
IgniteIgnoredBinaryTestSuite and IgniteIgnoredBinarySimpleMapperTestSuite. This 
is also okay, except that the way how this value is set 
({{IgniteTestSuite.ignoreDefault(true)}}) would impact execution of all other 
suites in case if one of these happens to run in between these.

I re-checked with [~vozerov] who wrote mentioned suites per IGNITE-3980 and he 
suggests that undocumented assumption is that they are expected to be always 
executed separately from the rest. I plan to change code so that it is 
guaranteed that suites won't affect each other.

> Migrate from JUnit 3 to 4 suites involving IgniteTestSuite
> --
>
> Key: IGNITE-10796
> URL: https://issues.apache.org/jira/browse/IGNITE-10796
> Project: Ignite
>  Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
>
> This task is to migrate from JUnit 3 to 4 test suites suites involving 
> {{IgniteTestSuite}} API that was introduced per IGNITE-3658.
> If needed, refer parent task comments for more details.



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

[jira] [Commented] (IGNITE-10316) control.sh --baseline remove outputs wrong error message when trying to remove node from baseline when cluster is inactive.

2019-01-09 Thread Sergey Antonov (JIRA) 


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

Sergey Antonov commented on IGNITE-10316:
-

[~v.pyatkov] changes Iooks good for me. Thank you for contibution!

> control.sh --baseline remove outputs wrong error message when trying to 
> remove node from baseline when cluster is inactive.
> ---
>
> Key: IGNITE-10316
> URL: https://issues.apache.org/jira/browse/IGNITE-10316
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Voronkin
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.8
>
>
> 1. start 2 nodes from clean lfs
> 2. grep node consistent ids
> {noformat}
> $ grep "Consistent ID" work/log/*.log
> work/log/ignite-15958745.0.log:[16:59:13,190][INFO][main][PdsFoldersResolver] 
> Consistent ID used for local node is [7ee8018b-3f5f-4c58-b6dd-f53ed7af2679] 
> according to persistence data storage folders
> work/log/ignite-300c7412.0.log:[16:59:15,678][INFO][main][PdsFoldersResolver] 
> Consistent ID used for local node is [5adcf3a1-7ad9-40fa-88ac-40b488dc6b34] 
> according to persistence data storage folders
> {noformat}
> 3. try to remove node from baseline
> expected: error message about cluster inactive state
> actual: error message about node id not found, BUG
> {noformat}
> Caused by: java.lang.IllegalStateException: Node not found for consistent ID: 
> 7ee8018b-3f5f-4c58-b6dd-f53ed7af2679
>  at 
> org.apache.ignite.internal.visor.baseline.VisorBaselineTask$VisorBaselineJob.remove(VisorBaselineTask.java:178)
>  at 
> org.apache.ignite.internal.visor.baseline.VisorBaselineTask$VisorBaselineJob.run(VisorBaselineTask.java:208)
>  at 
> org.apache.ignite.internal.visor.baseline.VisorBaselineTask$VisorBaselineJob.run(VisorBaselineTask.java:52)
>  at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
>  at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:568)
>  at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6726)
>  at 
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:562)
>  ... 19 more
> {noformat}
> however, when trying to add node to baseline, error message is correct:
> {noformat}
> Caused by: class org.apache.ignite.IgniteException: Changing BaselineTopology 
> on inactive cluster is not allowed.
>  at 
> org.apache.ignite.internal.cluster.IgniteClusterImpl.validateBeforeBaselineChange(IgniteClusterImpl.java:406)
>  at 
> org.apache.ignite.internal.cluster.IgniteClusterImpl.setBaselineTopology(IgniteClusterImpl.java:356)
>  at 
> org.apache.ignite.internal.visor.baseline.VisorBaselineTask$VisorBaselineJob.set0(VisorBaselineTask.java:87)
>  at 
> org.apache.ignite.internal.visor.baseline.VisorBaselineTask$VisorBaselineJob.add(VisorBaselineTask.java:162)
>  at 
> org.apache.ignite.internal.visor.baseline.VisorBaselineTask$VisorBaselineJob.run(VisorBaselineTask.java:205)
>  at 
> org.apache.ignite.internal.visor.baseline.VisorBaselineTask$VisorBaselineJob.run(VisorBaselineTask.java:52)
>  at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
>  at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:568)
>  at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6726)
>  at 
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:562)
>  at 
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:491)
>  at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>  at 
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1123)
>  at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1407)
>  at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:660)
>  at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:532)
>  ... 13 more
> {noformat}



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

  1   2   >