[jira] [Commented] (IGNITE-12068) puzzling select result

2019-08-15 Thread Ignite TC Bot (JIRA)


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

Ignite TC Bot commented on IGNITE-12068:


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

> puzzling select result
> --
>
> Key: IGNITE-12068
> URL: https://issues.apache.org/jira/browse/IGNITE-12068
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.7.5
> Environment: System version: CentOS Linux release 7.6.1810 (Core)
> Apache Ignite version: apache-ignite-2.7.5-1.noarch
>Reporter: JerryKwan
>Assignee: Ivan Pavlukhin
>Priority: Blocker
> Fix For: 2.7.6
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> select using the first primary key only returns one record, but it should 
> return more records.
> The following is how to reproduce this problem
> 1, create a table using
> CREATE TABLE IF NOT EXISTS Person(
>  id int,
>  city_id int,
>  name varchar,
>  age int, 
>  company varchar,
>  PRIMARY KEY (id, city_id)
> );
> 2, insert some records
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Doe', 3);
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Dean', 4);
> INSERT INTO Person (id, name, city_id) VALUES (2, 'Alex', 4);
> 3, query using 'select * from Person' show all of the records, expected
> [http://www.passimage.in/i/03da31c8f23cf64580d5.png]
> 4, query using 'select * from Person where id=1', only get one record, NOT 
> expected
> [http://www.passimage.in/i/f5491491a70c5d796823.png]
> 5, query using 'select * from Person where city_id=4' get  two records, 
> expected
> [http://www.passimage.in/i/ff0ee4f5e882983d779d.png]
> Why  'select * from Person where id=1', only get one record? and how to fix 
> this? Is there any special operations/configurations to do?



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (IGNITE-12061) Silently fail while try to recreate already existing index with differ inline_size.

2019-08-15 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin updated IGNITE-12061:

Reviewer: Yury Gerzhedovich

> Silently fail while try to recreate already existing index with differ 
> inline_size.
> ---
>
> Key: IGNITE-12061
> URL: https://issues.apache.org/jira/browse/IGNITE-12061
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.5, 2.7, 2.7.5
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.7.6
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> INLINE_SIZE differ from previous value is  not correctly sets.
> 1. create index idx0(c1, c2)
> 2. drop idx0
> 3. create index idx0(c1, c2) inline_size 100;
> inline_size remains the same, in this case default = 10.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12068) puzzling select result

2019-08-15 Thread JerryKwan (JIRA)


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

JerryKwan commented on IGNITE-12068:


[~dmagda], What's the ETA of version of 2.7.6?

> puzzling select result
> --
>
> Key: IGNITE-12068
> URL: https://issues.apache.org/jira/browse/IGNITE-12068
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.7.5
> Environment: System version: CentOS Linux release 7.6.1810 (Core)
> Apache Ignite version: apache-ignite-2.7.5-1.noarch
>Reporter: JerryKwan
>Assignee: Ivan Pavlukhin
>Priority: Blocker
> Fix For: 2.7.6
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> select using the first primary key only returns one record, but it should 
> return more records.
> The following is how to reproduce this problem
> 1, create a table using
> CREATE TABLE IF NOT EXISTS Person(
>  id int,
>  city_id int,
>  name varchar,
>  age int, 
>  company varchar,
>  PRIMARY KEY (id, city_id)
> );
> 2, insert some records
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Doe', 3);
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Dean', 4);
> INSERT INTO Person (id, name, city_id) VALUES (2, 'Alex', 4);
> 3, query using 'select * from Person' show all of the records, expected
> [http://www.passimage.in/i/03da31c8f23cf64580d5.png]
> 4, query using 'select * from Person where id=1', only get one record, NOT 
> expected
> [http://www.passimage.in/i/f5491491a70c5d796823.png]
> 5, query using 'select * from Person where city_id=4' get  two records, 
> expected
> [http://www.passimage.in/i/ff0ee4f5e882983d779d.png]
> Why  'select * from Person where id=1', only get one record? and how to fix 
> this? Is there any special operations/configurations to do?



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (IGNITE-12059) DiskPageCompressionConfigValidationTest.testIncorrectStaticCacheConfiguration fails

2019-08-15 Thread Ivan Rakov (JIRA)


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

Ivan Rakov updated IGNITE-12059:

Fix Version/s: (was: 2.7.6)

> DiskPageCompressionConfigValidationTest.testIncorrectStaticCacheConfiguration 
> fails
> ---
>
> Key: IGNITE-12059
> URL: https://issues.apache.org/jira/browse/IGNITE-12059
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.8
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> DiskPageCompressionConfigValidationTest.testIncorrectStaticCacheConfiguration 
> fails because validation was removed in IGNITE-9562.
> Need to restore this validation.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12061) Silently fail while try to recreate already existing index with differ inline_size.

2019-08-15 Thread Dmitriy Pavlov (JIRA)


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

Dmitriy Pavlov commented on IGNITE-12061:
-

[~Pavlukhin] could you please merge it if you agree?

> Silently fail while try to recreate already existing index with differ 
> inline_size.
> ---
>
> Key: IGNITE-12061
> URL: https://issues.apache.org/jira/browse/IGNITE-12061
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.5, 2.7, 2.7.5
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.7.6
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> INLINE_SIZE differ from previous value is  not correctly sets.
> 1. create index idx0(c1, c2)
> 2. drop idx0
> 3. create index idx0(c1, c2) inline_size 100;
> inline_size remains the same, in this case default = 10.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Reopened] (IGNITE-9562) Destroyed cache that resurrected on an old offline node breaks PME

2019-08-15 Thread Ivan Rakov (JIRA)


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

Ivan Rakov reopened IGNITE-9562:


> Destroyed cache that resurrected on an old offline node breaks PME
> --
>
> Key: IGNITE-9562
> URL: https://issues.apache.org/jira/browse/IGNITE-9562
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Eduard Shangareev
>Priority: Critical
> Fix For: 2.8, 2.7.6
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Given:
> 2 nodes, persistence enabled.
> 1) Stop 1 node
> 2) Destroy cache through client
> 3) Start stopped node
> When the stopped node joins to cluster it starts all caches that it has seen 
> before stopping.
> If that cache was cluster-widely destroyed it leads to breaking the crash 
> recovery process or PME.
> Root cause - we don't start/collect caches from the stopped node on another 
> part of a cluster.
> In case of PARTITIONED cache mode that scenario breaks crash recovery:
> {noformat}
> java.lang.AssertionError: AffinityTopologyVersion [topVer=-1, minorTopVer=0]
>   at 
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:696)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.updateLocal(GridDhtPartitionTopologyImpl.java:2449)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.afterStateRestored(GridDhtPartitionTopologyImpl.java:679)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restorePartitionStates(GridCacheDatabaseSharedManager.java:2445)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLastUpdates(GridCacheDatabaseSharedManager.java:2321)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1568)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java:1308)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1255)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:766)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2577)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2457)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> In case of REPLICATED cache mode that scenario breaks PME coordinator process:
> {noformat}
> [2018-09-12 
> 18:50:36,407][ERROR][sys-#148%distributed.CacheStopAndRessurectOnOldNodeTest0%][GridCacheIoManager]
>  Failed to process message [senderId=4b6fd0d4-b756-4a9f-90ca-f0ee2511, 
> messageType=class 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsSingleMessage]
> java.lang.AssertionError: 3080586
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.clientTopology(GridCachePartitionExchangeManager.java:815)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.updatePartitionSingleMap(GridDhtPartitionsExchangeFuture.java:3621)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2439)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:137)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2261)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2249)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
>   at 
> 

[jira] [Updated] (IGNITE-12077) Improve Checkstyle or other inspections profile to avoid using GG- reference in Ignite code base

2019-08-15 Thread Dmitriy Pavlov (JIRA)


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

Dmitriy Pavlov updated IGNITE-12077:

Ignite Flags:   (was: Docs Required)

> Improve Checkstyle or other inspections profile to avoid using GG- reference 
> in Ignite code base
> 
>
> Key: IGNITE-12077
> URL: https://issues.apache.org/jira/browse/IGNITE-12077
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Priority: Major
>
> Time to time tests are Ignored or todo added with reference to 
>  GG-  tickets "
> For example here
> https://github.com/apache/ignite/pull/6748/files#diff-2dd1dad039cddd36610c62a3dc2c1a28R223
> It is suggested to add some inspection check on TC to reject patches if there 
> is a line 
> containing: 
> - ": //ggsystems.atlassian.net/" 
> - or at the same time Ignore or todo and "GG- [0-9] *" 



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Created] (IGNITE-12077) Improve Checkstyle or other inspections profile to avoid using GG- reference in Ignite code base

2019-08-15 Thread Dmitriy Pavlov (JIRA)
Dmitriy Pavlov created IGNITE-12077:
---

 Summary: Improve Checkstyle or other inspections profile to avoid 
using GG- reference in Ignite code base
 Key: IGNITE-12077
 URL: https://issues.apache.org/jira/browse/IGNITE-12077
 Project: Ignite
  Issue Type: Test
Reporter: Dmitriy Pavlov


Time to time tests are Ignored or todo added with reference to 
 GG-  tickets "
For example here
https://github.com/apache/ignite/pull/6748/files#diff-2dd1dad039cddd36610c62a3dc2c1a28R223

It is suggested to add some inspection check on TC to reject patches if there 
is a line 
containing: 
- ": //ggsystems.atlassian.net/" 
- or at the same time Ignore or todo and "GG- [0-9] *" 



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12061) Silently fail while try to recreate already existing index with differ inline_size.

2019-08-15 Thread Yury Gerzhedovich (JIRA)


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

Yury Gerzhedovich commented on IGNITE-12061:


[~zstan], patch look good for me. Let's merge it.

> Silently fail while try to recreate already existing index with differ 
> inline_size.
> ---
>
> Key: IGNITE-12061
> URL: https://issues.apache.org/jira/browse/IGNITE-12061
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.5, 2.7, 2.7.5
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.7.6
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> INLINE_SIZE differ from previous value is  not correctly sets.
> 1. create index idx0(c1, c2)
> 2. drop idx0
> 3. create index idx0(c1, c2) inline_size 100;
> inline_size remains the same, in this case default = 10.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-11736) Make the TeamCity console quiet.

2019-08-15 Thread Dmitriy Pavlov (JIRA)


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

Dmitriy Pavlov commented on IGNITE-11736:
-

Cherry-picked to 2.7.6, 
https://github.com/apache/ignite/commit/891e49fe1eeb28bc6b655024086c3f4d1324fda4

> Make the TeamCity console quiet.
> 
>
> Key: IGNITE-11736
> URL: https://issues.apache.org/jira/browse/IGNITE-11736
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Stepachev Maksim
>Assignee: Stepachev Maksim
>Priority: Major
> Fix For: 2.7.6
>
> Attachments: quiet-console-checkbox.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> As a result of this discussion: 
> [https://lists.apache.org/list.html?d...@ignite.apache.org:lte=1M:Make%20the%20TeamCity%20console%20quiet.]
>  
>  # Rollover will be locked. Pros: Only one big file in an archive. Cons: Max 
> size of the file isn't limited. 2. Run all will contain a parameter for 
> switch off the quiet mode. 3. New config: log4j-tc-test.xml for TeamCity 
> environment.
> TC fixes:
> Add a checkbox into the general run window. *By default* the checkbox *is 
> active*. If the checkbox is *active*, the TeamCity adds next params for java 
> run: *-DIGNITE_TEST_PROP_LOG4J_FILE=log4j-tc-test.xml -DIGNITE_QUIET=true* 
> otherwise *empty params*.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (IGNITE-11736) Make the TeamCity console quiet.

2019-08-15 Thread Dmitriy Pavlov (JIRA)


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

Dmitriy Pavlov updated IGNITE-11736:

Fix Version/s: 2.7.6

> Make the TeamCity console quiet.
> 
>
> Key: IGNITE-11736
> URL: https://issues.apache.org/jira/browse/IGNITE-11736
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Stepachev Maksim
>Assignee: Stepachev Maksim
>Priority: Major
> Fix For: 2.7.6
>
> Attachments: quiet-console-checkbox.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> As a result of this discussion: 
> [https://lists.apache.org/list.html?d...@ignite.apache.org:lte=1M:Make%20the%20TeamCity%20console%20quiet.]
>  
>  # Rollover will be locked. Pros: Only one big file in an archive. Cons: Max 
> size of the file isn't limited. 2. Run all will contain a parameter for 
> switch off the quiet mode. 3. New config: log4j-tc-test.xml for TeamCity 
> environment.
> TC fixes:
> Add a checkbox into the general run window. *By default* the checkbox *is 
> active*. If the checkbox is *active*, the TeamCity adds next params for java 
> run: *-DIGNITE_TEST_PROP_LOG4J_FILE=log4j-tc-test.xml -DIGNITE_QUIET=true* 
> otherwise *empty params*.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (IGNITE-12032) Server node prints exception when ODBC driver disconnects

2019-08-15 Thread Dmitriy Pavlov (JIRA)


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

Dmitriy Pavlov updated IGNITE-12032:

Fix Version/s: (was: 2.7.6)
   2.8

> Server node prints exception when ODBC driver disconnects
> -
>
> Key: IGNITE-12032
> URL: https://issues.apache.org/jira/browse/IGNITE-12032
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.7.5
>Reporter: Evgenii Zhuravlev
>Priority: Major
>  Labels: newbie, usability
> Fix For: 2.8
>
>
> Whenever a process using ODBC clients is finished, it's printing in the 
> node logs this exception: 
> {code:java}
> *[07:45:19,559][SEVERE][grid-nio-worker-client-listener-1-#30][ClientListenerProcessor]
>  
> Failed to process selector key [s 
> es=GridSelectorNioSessionImpl [worker=ByteBufferNioClientWorker 
> [readBuf=java.nio.HeapByteBuffer[pos=0 lim=8192 cap=8192 
> ], super=AbstractNioClientWorker [idx=1, bytesRcvd=0, bytesSent=0, 
> bytesRcvd0=0, bytesSent0=0, select=true, super=GridWo 
> rker [name=grid-nio-worker-client-listener-1, igniteInstanceName=null, 
> finished=false, heartbeatTs=1564289118230, hashCo 
> de=1829856117, interrupted=false, 
> runner=grid-nio-worker-client-listener-1-#30]]], writeBuf=null, 
> readBuf=null, inRecove 
> ry=null, outRecovery=null, super=GridNioSessionImpl 
> [locAddr=/0:0:0:0:0:0:0:1:10800, rmtAddr=/0:0:0:0:0:0:0:1:63697, cre 
> ateTime=1564289116225, closeTime=0, bytesSent=1346, bytesRcvd=588, 
> bytesSent0=0, bytesRcvd0=0, sndSchedTime=156428911623 
> 5, lastSndTime=1564289116235, lastRcvTime=1564289116235, readsPaused=false, 
> filterChain=FilterChain[filters=[GridNioAsyn 
> cNotifyFilter, GridNioCodecFilter [parser=ClientListenerBufferedParser, 
> directMode=false]], accepted=true, markedForClos 
> e=false]]] 
> java.io.IOException: An existing connection was forcibly closed by the 
> remote host 
> at sun.nio.ch.SocketDispatcher.read0(Native Method) 
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43) 
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) 
> at sun.nio.ch.IOUtil.read(IOUtil.java:197) 
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380) 
> at 
> org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:11
>  
> 04) 
> at 
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNi
>  
> oServer.java:2389) 
> at 
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:215
>  
> 6) 
> at 
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1797)
>  
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) 
> at java.lang.Thread.run(Thread.java:748)* 
> {code}
> It's absolutely normal behavior when ODBC client disconnects from the node, 
> so, we shouldn't print exception in the log. We should replace it with 
> something like INFO message about ODBC client disconnection.
> Thread from user list: 
> http://apache-ignite-users.70518.x6.nabble.com/exceptions-in-Ignite-node-when-a-thin-client-process-ends-td28970.html



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-11803) Re-balancing is cancelled if client node joins, reinvestigate.

2019-08-15 Thread Maxim Muzafarov (JIRA)


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

Maxim Muzafarov commented on IGNITE-11803:
--

[~zstan]

yes, I have a plan to do this, but it's every time postpone by other activities.
Is it a critical issue? Should we raise the priority and include it, for 
example, in 2.8 Ignite release?

> Re-balancing is cancelled if client node joins, reinvestigate.
> --
>
> Key: IGNITE-11803
> URL: https://issues.apache.org/jira/browse/IGNITE-11803
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Stanilovsky Evgeny
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: rebalance
>
> Improvement [1] looks needs to be solved this problem, but in logs i see 
> different behavior. 
> {code:java}
> 2019-04-23 15:22:56.351[INFO 
> ][disco-event-worker-#159%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDiscoveryManager]
>  Added new node to topology: TcpDiscoveryNode 
> [id=4c9427d7-5d06-4460-98ad-6586cf177192, addrs=ArrayList [], sockAddrs=
> HashSet [, discPort=0, order=159, intOrder=159, 
> lastExchangeTime=1556022094000, loc=false, ver=2.5.1#20190327-sha1:6edfea1b, 
> isClient=true]
> 2019-04-23 15:22:56.353[INFO 
> ][disco-event-worker-#159%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDiscoveryManager]
>  Topology snapshot [ver=159, servers=, clients=1, CPUs=8848, 
> offheap=19.0GB, heap=4900.0GB]
> 2019-04-23 15:22:56.353[INFO 
> ][disco-event-worker-#159%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDiscoveryManager]
>^-- Node [id=80FC83EB-F125-48F0-ACBE-8ADB80A065A3, clusterState=ACTIVE]
> 2019-04-23 15:22:56.353[INFO 
> ][disco-event-worker-#159%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDiscoveryManager]
>^-- Baseline [id=0, size=158, online=158, offline=0]
> 2019-04-23 15:22:56.353[INFO 
> ][disco-event-worker-#159%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDiscoveryManager]
>  Data Regions Configured:
> 2019-04-23 15:22:56.353[INFO 
> ][disco-event-worker-#159%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDiscoveryManager]
>^-- dpl_mem_plc [initSize=256.0 MiB, maxSize=592.0 GiB, 
> persistenceEnabled=true]
> 2019-04-23 15:22:56.353[INFO 
> ][disco-event-worker-#159%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDiscoveryManager]
>^-- not-persisted [initSize=256.0 MiB, maxSize=576.0 GiB, 
> persistenceEnabled=false]
> 2019-04-23 15:22:56.356[INFO 
> ][exchange-worker-#160%DPL_GRID%DplGridNodeName%][o.a.ignite.internal.exchange.time]
>  Started exchange init [topVer=AffinityTopologyVersion [topVer=159, 
> minorTopVer=0], crd=false, evt=NODE_JOINED, evtNode=4c9427d7-5d06
> -4460-98ad-6586cf177192, customEvt=null, allowMerge=true]
> 2019-04-23 15:22:56.393[INFO 
> ][exchange-worker-#160%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionsExchangeFuture]
>  Finish exchange future [startVer=AffinityTopologyVersion [topVer=159, 
> minorTopVer=0], resVer=AffinityTopologyVersion
>  [topVer=159, minorTopVer=0], err=null]
> 2019-04-23 15:22:56.417[INFO 
> ][exchange-worker-#160%DPL_GRID%DplGridNodeName%][o.a.ignite.internal.exchange.time]
>  Finished exchange init [topVer=AffinityTopologyVersion [topVer=159, 
> minorTopVer=0], crd=false]
> 2019-04-23 15:22:56.637[INFO 
> ][wal-file-archiver%DPL_GRID%DplGridNodeName-#188%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.p.w.FileWriteAheadLogManager]
>  Copied file 
> [src=/gridgain/ssd/data/wal/10_124_133_10_47500/0008.wal, 
> dst=/gridgain/sa
> s/wal_archive/10_124_133_10_47500/0008.wal]
> 2019-04-23 15:22:57.442[INFO 
> ][exchange-worker-#160%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionDemander]
>  Cancelled rebalancing from all nodes 
> [grp=SYSTEM_CACHEGROUP_DTR_union-module, topVer=AffinityTopologyVersion 
> [topVer=158, minorTopVer=6]]
> 2019-04-23 15:22:57.443[INFO 
> ][exchange-worker-#160%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionDemander]
>  Completed rebalance future: RebalanceFuture [grp=CacheGroupContext 
> [grp=SYSTEM_CACHEGROUP_DTR_union-module], topVer=AffinityTopologyVersion 
> [topVer=158, minorTopVer=6], rebalanceId=1003, routines=3]
> 2019-04-23 15:22:57.443[INFO 
> ][exchange-worker-#160%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionDemander]
>  Cancelled rebalancing from all nodes [grp=CACHEGROUP_SYSTEM_COMPONENT, 
> topVer=AffinityTopologyVersion [topVer=158, minorTopVer=6]]
> 2019-04-23 15:22:57.444[INFO 
> ][exchange-worker-#160%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionDemander]
>  Completed rebalance future: RebalanceFuture [grp=CacheGroupContext 
> [grp=CACHEGROUP_SYSTEM_COMPONENT], topVer=AffinityTopologyVersion [
> {code}
> [1] https://issues.apache.org/jira/browse/IGNITE-7165
> [~Mmuzaf] [~v.pyatkov] do u have 

[jira] [Updated] (IGNITE-11767) GridDhtPartitionsFullMessage retains huge maps on heap in exchange history

2019-08-15 Thread Dmitriy Pavlov (JIRA)


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

Dmitriy Pavlov updated IGNITE-11767:

Fix Version/s: 2.7.6

> GridDhtPartitionsFullMessage retains huge maps on heap in exchange history
> --
>
> Key: IGNITE-11767
> URL: https://issues.apache.org/jira/browse/IGNITE-11767
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Blocker
> Fix For: 2.8, 2.7.6
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> ExchangeHistory keeps a FinishState for every topology version.
> FinishState contains msg, which contains at least two huge maps:
> partCntrs2 and partsSizesBytes.
> We should probably strip msg, removing those two data structures before 
> putting msg in exchFuts linked list to be stowed away.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-11953) BTree corruption caused by byte array values

2019-08-15 Thread Dmitriy Pavlov (JIRA)


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

Dmitriy Pavlov commented on IGNITE-11953:
-

Agreed in private with Dmitriy G. that this issue is more generic than 
https://issues.apache.org/jira/browse/IGNITE-12060

I've returned it to assigned on 2.8. 
 

> BTree corruption caused by byte array values
> 
>
> Key: IGNITE-11953
> URL: https://issues.apache.org/jira/browse/IGNITE-11953
> Project: Ignite
>  Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
>
> In some cases for caches with cache group, we can get BTree corruption 
> exception.
> {code}
> 09:53:58,890][SEVERE][sys-stripe-10-#11][] Critical system error detected. 
> Will be handled accordingly to configured handler [hnd=CustomFailureHandler 
> [ignoreCriticalErrors=false, disabled=false][StopNodeOrHaltFailureHandler 
> [tryStop=false, timeout=0]], failureCtx=FailureContext [type=CRITICAL_ERROR, 
> err=class o.a.i.i.transactions.IgniteTxHeuristicCheckedException: Committing 
> a transaction has produced runtime exception]]class 
> org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException: 
> Committing a transaction has produced runtime exception
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.heuristicException(IgniteTxAdapter.java:800)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:922)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocalAdapter.localFinish(GridDhtTxLocalAdapter.java:799)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.localFinish(GridDhtTxLocal.java:608)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.finishTx(GridDhtTxLocal.java:478)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.commitDhtLocalAsync(GridDhtTxLocal.java:535)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:1055)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:931)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:887)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$200(IgniteTxHandler.java:117)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:209)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:207)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1129)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:594)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:393)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1568)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1196)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1092)
>   at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:504)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: class 
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
>  Runtime failure on search row: SearchRow [key=KeyCacheObjectImpl [part=427, 
> val=Grkg1DUF3yQE6tC9Se50mi5w.T, hasValBytes=true], hash=1872857770, 
> cacheId=-420893003]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1811)
>   at 
> 

[jira] [Updated] (IGNITE-11953) BTree corruption caused by byte array values

2019-08-15 Thread Dmitriy Pavlov (JIRA)


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

Dmitriy Pavlov updated IGNITE-11953:

Fix Version/s: (was: 2.7.6)
   2.8

> BTree corruption caused by byte array values
> 
>
> Key: IGNITE-11953
> URL: https://issues.apache.org/jira/browse/IGNITE-11953
> Project: Ignite
>  Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
>
> In some cases for caches with cache group, we can get BTree corruption 
> exception.
> {code}
> 09:53:58,890][SEVERE][sys-stripe-10-#11][] Critical system error detected. 
> Will be handled accordingly to configured handler [hnd=CustomFailureHandler 
> [ignoreCriticalErrors=false, disabled=false][StopNodeOrHaltFailureHandler 
> [tryStop=false, timeout=0]], failureCtx=FailureContext [type=CRITICAL_ERROR, 
> err=class o.a.i.i.transactions.IgniteTxHeuristicCheckedException: Committing 
> a transaction has produced runtime exception]]class 
> org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException: 
> Committing a transaction has produced runtime exception
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.heuristicException(IgniteTxAdapter.java:800)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:922)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocalAdapter.localFinish(GridDhtTxLocalAdapter.java:799)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.localFinish(GridDhtTxLocal.java:608)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.finishTx(GridDhtTxLocal.java:478)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.commitDhtLocalAsync(GridDhtTxLocal.java:535)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:1055)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:931)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:887)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$200(IgniteTxHandler.java:117)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:209)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:207)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1129)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:594)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:393)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1568)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1196)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1092)
>   at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:504)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: class 
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
>  Runtime failure on search row: SearchRow [key=KeyCacheObjectImpl [part=427, 
> val=Grkg1DUF3yQE6tC9Se50mi5w.T, hasValBytes=true], hash=1872857770, 
> cacheId=-420893003]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1811)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1620)
>   at 
> 

[jira] [Commented] (IGNITE-11289) BPlusTree.AbstractForwardCursor can use obsolete page

2019-08-15 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-11289:
-

Some debugging were done in:
* https://github.com/apache/ignite/pull/6066
* https://github.com/apache/ignite/pull/6064

> BPlusTree.AbstractForwardCursor can use obsolete page
> -
>
> Key: IGNITE-11289
> URL: https://issues.apache.org/jira/browse/IGNITE-11289
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.7
>Reporter: Ivan Pavlukhin
>Priority: Major
>
> There is a possibility that {{AbstractForwardCursor.nextPageId}} refers to a 
> page which was already excluded from the tree. The problem reproduces with a 
> scan query execution with put/remove load in background.
> Linked PR contains a reproducer and some tricks allowing to reproduce the 
> problem more often (it is still possible to reproduce it without tricks but 
> likelihood is significantly lower). The problem becomes evident when a 
> problematic page is taken from REUSE_BUCKET. But there could be other hidden 
> problems which do not cause any runtime errors but lead to data inconsistency.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-11803) Re-balancing is cancelled if client node joins, reinvestigate.

2019-08-15 Thread Stanilovsky Evgeny (JIRA)


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

Stanilovsky Evgeny commented on IGNITE-11803:
-

[~Mmuzaf] do you plan to proceed with this ticket ? thanks !

> Re-balancing is cancelled if client node joins, reinvestigate.
> --
>
> Key: IGNITE-11803
> URL: https://issues.apache.org/jira/browse/IGNITE-11803
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Stanilovsky Evgeny
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: rebalance
>
> Improvement [1] looks needs to be solved this problem, but in logs i see 
> different behavior. 
> {code:java}
> 2019-04-23 15:22:56.351[INFO 
> ][disco-event-worker-#159%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDiscoveryManager]
>  Added new node to topology: TcpDiscoveryNode 
> [id=4c9427d7-5d06-4460-98ad-6586cf177192, addrs=ArrayList [], sockAddrs=
> HashSet [, discPort=0, order=159, intOrder=159, 
> lastExchangeTime=1556022094000, loc=false, ver=2.5.1#20190327-sha1:6edfea1b, 
> isClient=true]
> 2019-04-23 15:22:56.353[INFO 
> ][disco-event-worker-#159%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDiscoveryManager]
>  Topology snapshot [ver=159, servers=, clients=1, CPUs=8848, 
> offheap=19.0GB, heap=4900.0GB]
> 2019-04-23 15:22:56.353[INFO 
> ][disco-event-worker-#159%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDiscoveryManager]
>^-- Node [id=80FC83EB-F125-48F0-ACBE-8ADB80A065A3, clusterState=ACTIVE]
> 2019-04-23 15:22:56.353[INFO 
> ][disco-event-worker-#159%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDiscoveryManager]
>^-- Baseline [id=0, size=158, online=158, offline=0]
> 2019-04-23 15:22:56.353[INFO 
> ][disco-event-worker-#159%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDiscoveryManager]
>  Data Regions Configured:
> 2019-04-23 15:22:56.353[INFO 
> ][disco-event-worker-#159%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDiscoveryManager]
>^-- dpl_mem_plc [initSize=256.0 MiB, maxSize=592.0 GiB, 
> persistenceEnabled=true]
> 2019-04-23 15:22:56.353[INFO 
> ][disco-event-worker-#159%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDiscoveryManager]
>^-- not-persisted [initSize=256.0 MiB, maxSize=576.0 GiB, 
> persistenceEnabled=false]
> 2019-04-23 15:22:56.356[INFO 
> ][exchange-worker-#160%DPL_GRID%DplGridNodeName%][o.a.ignite.internal.exchange.time]
>  Started exchange init [topVer=AffinityTopologyVersion [topVer=159, 
> minorTopVer=0], crd=false, evt=NODE_JOINED, evtNode=4c9427d7-5d06
> -4460-98ad-6586cf177192, customEvt=null, allowMerge=true]
> 2019-04-23 15:22:56.393[INFO 
> ][exchange-worker-#160%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionsExchangeFuture]
>  Finish exchange future [startVer=AffinityTopologyVersion [topVer=159, 
> minorTopVer=0], resVer=AffinityTopologyVersion
>  [topVer=159, minorTopVer=0], err=null]
> 2019-04-23 15:22:56.417[INFO 
> ][exchange-worker-#160%DPL_GRID%DplGridNodeName%][o.a.ignite.internal.exchange.time]
>  Finished exchange init [topVer=AffinityTopologyVersion [topVer=159, 
> minorTopVer=0], crd=false]
> 2019-04-23 15:22:56.637[INFO 
> ][wal-file-archiver%DPL_GRID%DplGridNodeName-#188%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.p.w.FileWriteAheadLogManager]
>  Copied file 
> [src=/gridgain/ssd/data/wal/10_124_133_10_47500/0008.wal, 
> dst=/gridgain/sa
> s/wal_archive/10_124_133_10_47500/0008.wal]
> 2019-04-23 15:22:57.442[INFO 
> ][exchange-worker-#160%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionDemander]
>  Cancelled rebalancing from all nodes 
> [grp=SYSTEM_CACHEGROUP_DTR_union-module, topVer=AffinityTopologyVersion 
> [topVer=158, minorTopVer=6]]
> 2019-04-23 15:22:57.443[INFO 
> ][exchange-worker-#160%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionDemander]
>  Completed rebalance future: RebalanceFuture [grp=CacheGroupContext 
> [grp=SYSTEM_CACHEGROUP_DTR_union-module], topVer=AffinityTopologyVersion 
> [topVer=158, minorTopVer=6], rebalanceId=1003, routines=3]
> 2019-04-23 15:22:57.443[INFO 
> ][exchange-worker-#160%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionDemander]
>  Cancelled rebalancing from all nodes [grp=CACHEGROUP_SYSTEM_COMPONENT, 
> topVer=AffinityTopologyVersion [topVer=158, minorTopVer=6]]
> 2019-04-23 15:22:57.444[INFO 
> ][exchange-worker-#160%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionDemander]
>  Completed rebalance future: RebalanceFuture [grp=CacheGroupContext 
> [grp=CACHEGROUP_SYSTEM_COMPONENT], topVer=AffinityTopologyVersion [
> {code}
> [1] https://issues.apache.org/jira/browse/IGNITE-7165
> [~Mmuzaf] [~v.pyatkov] do u have ideas? thanks !



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-11767) GridDhtPartitionsFullMessage retains huge maps on heap in exchange history

2019-08-15 Thread Dmitriy Pavlov (JIRA)


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

Dmitriy Pavlov commented on IGNITE-11767:
-

[~ilyak] thank you, I've created https://github.com/apache/ignite/pull/6780 for 
check PR using AI TC Bot

> GridDhtPartitionsFullMessage retains huge maps on heap in exchange history
> --
>
> Key: IGNITE-11767
> URL: https://issues.apache.org/jira/browse/IGNITE-11767
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Blocker
> Fix For: 2.8
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> ExchangeHistory keeps a FinishState for every topology version.
> FinishState contains msg, which contains at least two huge maps:
> partCntrs2 and partsSizesBytes.
> We should probably strip msg, removing those two data structures before 
> putting msg in exchFuts linked list to be stowed away.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Comment Edited] (IGNITE-9562) Destroyed cache that resurrected on an old offline node breaks PME

2019-08-15 Thread Dmitriy Pavlov (JIRA)


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

Dmitriy Pavlov edited comment on IGNITE-9562 at 8/15/19 2:06 PM:
-

[~ivan.glukos], could you please cherry-pick commit to Ignite 2.7.6 branch once 
all tests are fixed in master 
?https://github.com/apache/ignite/commit/27e9f705c1f65baae20b7dc3c03e988217dbe3f6


was (Author: dpavlov):
Could you please cherry-pick commit to Ignite 2.7.6 branch once all tests are 
fixed in master 
?https://github.com/apache/ignite/commit/27e9f705c1f65baae20b7dc3c03e988217dbe3f6

> Destroyed cache that resurrected on an old offline node breaks PME
> --
>
> Key: IGNITE-9562
> URL: https://issues.apache.org/jira/browse/IGNITE-9562
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Eduard Shangareev
>Priority: Critical
> Fix For: 2.8, 2.7.6
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Given:
> 2 nodes, persistence enabled.
> 1) Stop 1 node
> 2) Destroy cache through client
> 3) Start stopped node
> When the stopped node joins to cluster it starts all caches that it has seen 
> before stopping.
> If that cache was cluster-widely destroyed it leads to breaking the crash 
> recovery process or PME.
> Root cause - we don't start/collect caches from the stopped node on another 
> part of a cluster.
> In case of PARTITIONED cache mode that scenario breaks crash recovery:
> {noformat}
> java.lang.AssertionError: AffinityTopologyVersion [topVer=-1, minorTopVer=0]
>   at 
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:696)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.updateLocal(GridDhtPartitionTopologyImpl.java:2449)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.afterStateRestored(GridDhtPartitionTopologyImpl.java:679)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restorePartitionStates(GridCacheDatabaseSharedManager.java:2445)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLastUpdates(GridCacheDatabaseSharedManager.java:2321)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1568)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java:1308)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1255)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:766)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2577)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2457)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> In case of REPLICATED cache mode that scenario breaks PME coordinator process:
> {noformat}
> [2018-09-12 
> 18:50:36,407][ERROR][sys-#148%distributed.CacheStopAndRessurectOnOldNodeTest0%][GridCacheIoManager]
>  Failed to process message [senderId=4b6fd0d4-b756-4a9f-90ca-f0ee2511, 
> messageType=class 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsSingleMessage]
> java.lang.AssertionError: 3080586
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.clientTopology(GridCachePartitionExchangeManager.java:815)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.updatePartitionSingleMap(GridDhtPartitionsExchangeFuture.java:3621)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2439)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:137)
>   at 
> 

[jira] [Commented] (IGNITE-11767) GridDhtPartitionsFullMessage retains huge maps on heap in exchange history

2019-08-15 Thread Ilya Kasnacheev (JIRA)


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

Ilya Kasnacheev commented on IGNITE-11767:
--

Let's watch https://ci.ignite.apache.org/viewQueued.html?itemId=4502528

> GridDhtPartitionsFullMessage retains huge maps on heap in exchange history
> --
>
> Key: IGNITE-11767
> URL: https://issues.apache.org/jira/browse/IGNITE-11767
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Blocker
> Fix For: 2.8
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> ExchangeHistory keeps a FinishState for every topology version.
> FinishState contains msg, which contains at least two huge maps:
> partCntrs2 and partsSizesBytes.
> We should probably strip msg, removing those two data structures before 
> putting msg in exchFuts linked list to be stowed away.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Assigned] (IGNITE-11094) Add SSL support for ignite zookeeper SPI

2019-08-15 Thread Ryabov Dmitrii (JIRA)


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

Ryabov Dmitrii reassigned IGNITE-11094:
---

Assignee: Ryabov Dmitrii

> Add SSL support for ignite zookeeper SPI
> 
>
> Key: IGNITE-11094
> URL: https://issues.apache.org/jira/browse/IGNITE-11094
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Assignee: Ryabov Dmitrii
>Priority: Major
> Fix For: 2.8
>
>
> ZK 3.5.4-beta is already supporting SSL [1]. We should add SSL support to ZK 
> server connections  if Zookeeper SPI used.
> 1. 
> https://cwiki.apache.org/confluence/display/ZOOKEEPER/ZooKeeper+SSL+User+Guide



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (IGNITE-9562) Destroyed cache that resurrected on an old offline node breaks PME

2019-08-15 Thread Dmitriy Pavlov (JIRA)


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

Dmitriy Pavlov updated IGNITE-9562:
---
Fix Version/s: 2.7.6

> Destroyed cache that resurrected on an old offline node breaks PME
> --
>
> Key: IGNITE-9562
> URL: https://issues.apache.org/jira/browse/IGNITE-9562
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Eduard Shangareev
>Priority: Critical
> Fix For: 2.8, 2.7.6
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Given:
> 2 nodes, persistence enabled.
> 1) Stop 1 node
> 2) Destroy cache through client
> 3) Start stopped node
> When the stopped node joins to cluster it starts all caches that it has seen 
> before stopping.
> If that cache was cluster-widely destroyed it leads to breaking the crash 
> recovery process or PME.
> Root cause - we don't start/collect caches from the stopped node on another 
> part of a cluster.
> In case of PARTITIONED cache mode that scenario breaks crash recovery:
> {noformat}
> java.lang.AssertionError: AffinityTopologyVersion [topVer=-1, minorTopVer=0]
>   at 
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:696)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.updateLocal(GridDhtPartitionTopologyImpl.java:2449)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.afterStateRestored(GridDhtPartitionTopologyImpl.java:679)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restorePartitionStates(GridCacheDatabaseSharedManager.java:2445)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLastUpdates(GridCacheDatabaseSharedManager.java:2321)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1568)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java:1308)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1255)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:766)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2577)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2457)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> In case of REPLICATED cache mode that scenario breaks PME coordinator process:
> {noformat}
> [2018-09-12 
> 18:50:36,407][ERROR][sys-#148%distributed.CacheStopAndRessurectOnOldNodeTest0%][GridCacheIoManager]
>  Failed to process message [senderId=4b6fd0d4-b756-4a9f-90ca-f0ee2511, 
> messageType=class 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsSingleMessage]
> java.lang.AssertionError: 3080586
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.clientTopology(GridCachePartitionExchangeManager.java:815)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.updatePartitionSingleMap(GridDhtPartitionsExchangeFuture.java:3621)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2439)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:137)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2261)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2249)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
>   at 
> 

[jira] [Commented] (IGNITE-12061) Silently fail while try to recreate already existing index with differ inline_size.

2019-08-15 Thread Stanilovsky Evgeny (JIRA)


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

Stanilovsky Evgeny commented on IGNITE-12061:
-

[~jooger] [~taras.ledkov] guys, can someone review this ticket ?
thanks ! 

> Silently fail while try to recreate already existing index with differ 
> inline_size.
> ---
>
> Key: IGNITE-12061
> URL: https://issues.apache.org/jira/browse/IGNITE-12061
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.5, 2.7, 2.7.5
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.7.6
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> INLINE_SIZE differ from previous value is  not correctly sets.
> 1. create index idx0(c1, c2)
> 2. drop idx0
> 3. create index idx0(c1, c2) inline_size 100;
> inline_size remains the same, in this case default = 10.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (IGNITE-12033) .NET: Callbacks from striped pool due to async/await may hang cluster

2019-08-15 Thread Pavel Tupitsyn (JIRA)


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

Pavel Tupitsyn updated IGNITE-12033:

Fix Version/s: (was: 2.7.6)
   2.8

> .NET: Callbacks from striped pool due to async/await may hang cluster
> -
>
> Key: IGNITE-12033
> URL: https://issues.apache.org/jira/browse/IGNITE-12033
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, platforms
>Affects Versions: 2.7.5
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .net
> Fix For: 2.8
>
>
> http://apache-ignite-users.70518.x6.nabble.com/Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td27871.html#a28051
> There's a reproducer project. Long story short, .Net can invoke cache 
> operations with future callbacks, which will be invoked from striped pool. If 
> such callbacks are to use cache operations, those will be possibly sheduled 
> to the same stripe and cause a deadlock.
> The code is very simple:
> {code}
> Console.WriteLine("PutAsync");
> await cache.PutAsync(1, "Test");
> Console.WriteLine("Replace");
> cache.Replace(1, "Testing"); // Hangs here
> Console.WriteLine("Wait");
> await Task.Delay(Timeout.Infinite); 
> {code}
> async/await should absolutely not allow any client code to be run from 
> stripes.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12068) puzzling select result

2019-08-15 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-12068:
-

Work note. Release notes will be needed.

> puzzling select result
> --
>
> Key: IGNITE-12068
> URL: https://issues.apache.org/jira/browse/IGNITE-12068
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.7.5
> Environment: System version: CentOS Linux release 7.6.1810 (Core)
> Apache Ignite version: apache-ignite-2.7.5-1.noarch
>Reporter: JerryKwan
>Assignee: Ivan Pavlukhin
>Priority: Blocker
> Fix For: 2.7.6
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> select using the first primary key only returns one record, but it should 
> return more records.
> The following is how to reproduce this problem
> 1, create a table using
> CREATE TABLE IF NOT EXISTS Person(
>  id int,
>  city_id int,
>  name varchar,
>  age int, 
>  company varchar,
>  PRIMARY KEY (id, city_id)
> );
> 2, insert some records
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Doe', 3);
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Dean', 4);
> INSERT INTO Person (id, name, city_id) VALUES (2, 'Alex', 4);
> 3, query using 'select * from Person' show all of the records, expected
> [http://www.passimage.in/i/03da31c8f23cf64580d5.png]
> 4, query using 'select * from Person where id=1', only get one record, NOT 
> expected
> [http://www.passimage.in/i/f5491491a70c5d796823.png]
> 5, query using 'select * from Person where city_id=4' get  two records, 
> expected
> [http://www.passimage.in/i/ff0ee4f5e882983d779d.png]
> Why  'select * from Person where id=1', only get one record? and how to fix 
> this? Is there any special operations/configurations to do?



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-11953) BTree corruption caused by byte array values

2019-08-15 Thread Dmitriy Pavlov (JIRA)


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

Dmitriy Pavlov commented on IGNITE-11953:
-

[~DmitriyGovorukhin], kindly reminder, please respond

> BTree corruption caused by byte array values
> 
>
> Key: IGNITE-11953
> URL: https://issues.apache.org/jira/browse/IGNITE-11953
> Project: Ignite
>  Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.7.6
>
>
> In some cases for caches with cache group, we can get BTree corruption 
> exception.
> {code}
> 09:53:58,890][SEVERE][sys-stripe-10-#11][] Critical system error detected. 
> Will be handled accordingly to configured handler [hnd=CustomFailureHandler 
> [ignoreCriticalErrors=false, disabled=false][StopNodeOrHaltFailureHandler 
> [tryStop=false, timeout=0]], failureCtx=FailureContext [type=CRITICAL_ERROR, 
> err=class o.a.i.i.transactions.IgniteTxHeuristicCheckedException: Committing 
> a transaction has produced runtime exception]]class 
> org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException: 
> Committing a transaction has produced runtime exception
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.heuristicException(IgniteTxAdapter.java:800)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:922)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocalAdapter.localFinish(GridDhtTxLocalAdapter.java:799)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.localFinish(GridDhtTxLocal.java:608)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.finishTx(GridDhtTxLocal.java:478)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.commitDhtLocalAsync(GridDhtTxLocal.java:535)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:1055)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:931)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:887)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$200(IgniteTxHandler.java:117)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:209)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:207)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1129)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:594)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:393)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1568)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1196)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1092)
>   at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:504)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: class 
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
>  Runtime failure on search row: SearchRow [key=KeyCacheObjectImpl [part=427, 
> val=Grkg1DUF3yQE6tC9Se50mi5w.T, hasValBytes=true], hash=1872857770, 
> cacheId=-420893003]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1811)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1620)
>   at 
> 

[jira] [Updated] (IGNITE-12076) Optimistic transaction initiated from client node and parallel cache stop may lead to node hang on the final phase of PME.

2019-08-15 Thread Vyacheslav Koptilin (JIRA)


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

Vyacheslav Koptilin updated IGNITE-12076:
-
Description: 
It looks like the mentioned behavior was introduced by IGNITE-11592. The root 
cause of the hang is that optimistic transaction can be mapped on the topology 
version that corresponds to cache stop and is in progress.
{noformat}
"sys-#1" #108 prio=5 os_prio=0 tid=0x7f5328042000 nid=0x4fbc waiting on 
condition [0x7f5020ff3000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.rollbackTransactionsForCaches(IgniteTxManager.java:339)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.rollbackCoveredTx(GridCacheProcessor.java:3041)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onExchangeDone(GridCacheProcessor.java:3013)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:2169)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processFullMessage(GridDhtPartitionsExchangeFuture.java:4094)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$1600(GridDhtPartitionsExchangeFuture.java:140)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$5.apply(GridDhtPartitionsExchangeFuture.java:3787)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$5.apply(GridDhtPartitionsExchangeFuture.java:3775)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:385)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:355)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveFullMessage(GridDhtPartitionsExchangeFuture.java:3775)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processFullPartitionUpdate(GridCachePartitionExchangeManager.java:1778)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$3.onMessage(GridCachePartitionExchangeManager.java:423)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$3.onMessage(GridCachePartitionExchangeManager.java:410)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:3444)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:3423)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1077)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:587)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:386)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:312)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:102)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:301)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748){noformat}
{noformat}
 
"thread" #128 prio=5 os_prio=0 tid=0x7f67cca93800 nid=0x5132 waiting on 
condition [0x7f639f3b]
 java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native 
Method)
 at 

[jira] [Commented] (IGNITE-11848) [IEP-35] Monitoring Phase 1

2019-08-15 Thread Pavel Tupitsyn (JIRA)


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

Pavel Tupitsyn commented on IGNITE-11848:
-

[~NIzhikov] the idea behind parity tests was to track the differences between 
Java and .NET APIs.
If the new API is not supported in .NET for now, we should update the parity 
test accordingly.

Adding a public API that is useless does not make sense.

I've updated the code and tried to improve assertion message as well: 
089d3c2f96fefb7e65f4e6fba63d8bfd4473cda4

> [IEP-35] Monitoring Phase 1
> --
>
> Key: IGNITE-11848
> URL: https://issues.apache.org/jira/browse/IGNITE-11848
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 2.7
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: IEP-35
> Fix For: 2.8
>
>  Time Spent: 7h
>  Remaining Estimate: 0h
>
> Umbrella ticket for the IEP-35. Monitoring and profiling.
> Phase 1 should include:
>  * NextGen monitoring subsystem implementation to manage
>  ** metrics
>  ** -lists- (will be implemented in the following tickets)
>  ** exporters
>  * JMX, SQLView, Log exporters
>  * Migration of existing metrics to new manager
>  * -Lists for all Ignite user API-



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Created] (IGNITE-12076) Optimistic transaction initiated from client node and parallel cache stop may lead to node hang on the final phase of PME.

2019-08-15 Thread Vyacheslav Koptilin (JIRA)
Vyacheslav Koptilin created IGNITE-12076:


 Summary: Optimistic transaction initiated from client node and 
parallel cache stop may lead to node hang on the final phase of PME.
 Key: IGNITE-12076
 URL: https://issues.apache.org/jira/browse/IGNITE-12076
 Project: Ignite
  Issue Type: Bug
Reporter: Vyacheslav Koptilin
Assignee: Vyacheslav Koptilin
 Fix For: 2.8


It looks like the mentioned behavior was introduced by IGNITE-11592. The root 
cause of the hang is that optimistic transaction can be mapped on the topology 
version that corresponds to cache stop and is in progress.
{noformat}
"sys-#1" #108 prio=5 os_prio=0 tid=0x7f5328042000 nid=0x4fbc waiting on 
condition [0x7f5020ff3000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.rollbackTransactionsForCaches(IgniteTxManager.java:339)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.rollbackCoveredTx(GridCacheProcessor.java:3041)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onExchangeDone(GridCacheProcessor.java:3013)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:2169)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processFullMessage(GridDhtPartitionsExchangeFuture.java:4094)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$1600(GridDhtPartitionsExchangeFuture.java:140)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$5.apply(GridDhtPartitionsExchangeFuture.java:3787)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$5.apply(GridDhtPartitionsExchangeFuture.java:3775)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:385)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:355)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveFullMessage(GridDhtPartitionsExchangeFuture.java:3775)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processFullPartitionUpdate(GridCachePartitionExchangeManager.java:1778)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$3.onMessage(GridCachePartitionExchangeManager.java:423)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$3.onMessage(GridCachePartitionExchangeManager.java:410)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:3444)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:3423)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1077)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:587)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:386)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:312)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:102)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:301)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at 

[jira] [Updated] (IGNITE-12054) Upgrade Spark module to 2.4

2019-08-15 Thread Dmitriy Pavlov (JIRA)


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

Dmitriy Pavlov updated IGNITE-12054:

Fix Version/s: (was: 2.7.6)
   2.8

> Upgrade Spark module to 2.4
> ---
>
> Key: IGNITE-12054
> URL: https://issues.apache.org/jira/browse/IGNITE-12054
> Project: Ignite
>  Issue Type: Task
>  Components: spark
>Affects Versions: 2.7.5
>Reporter: Denis Magda
>Assignee: Nikolay Izhikov
>Priority: Blocker
> Fix For: 2.8
>
>
> Users can't use APIs that are already available in Spark 2.4:
> https://stackoverflow.com/questions/57392143/persisting-spark-dataframe-to-ignite
> Let's upgrade Spark from 2.3 to 2.4 until we extract the Spark Integration as 
> a separate module that can support multiple Spark versions.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-11848) [IEP-35] Monitoring Phase 1

2019-08-15 Thread Nikolay Izhikov (JIRA)


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

Nikolay Izhikov commented on IGNITE-11848:
--

[~ptupitsyn] .Net tests require configuration equality in .Net in Java.
I don't mind if you remove {{IMetricExporterSpi}} from .Net part as long as it 
doesn't break tests.

> [IEP-35] Monitoring Phase 1
> --
>
> Key: IGNITE-11848
> URL: https://issues.apache.org/jira/browse/IGNITE-11848
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 2.7
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: IEP-35
> Fix For: 2.8
>
>  Time Spent: 7h
>  Remaining Estimate: 0h
>
> Umbrella ticket for the IEP-35. Monitoring and profiling.
> Phase 1 should include:
>  * NextGen monitoring subsystem implementation to manage
>  ** metrics
>  ** -lists- (will be implemented in the following tickets)
>  ** exporters
>  * JMX, SQLView, Log exporters
>  * Migration of existing metrics to new manager
>  * -Lists for all Ignite user API-



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-11848) [IEP-35] Monitoring Phase 1

2019-08-15 Thread Pavel Tupitsyn (JIRA)


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

Pavel Tupitsyn commented on IGNITE-11848:
-

[~NIzhikov], what's the idea behind .NET changes in this ticket? 
IMetricExporterSpi is empty and seemingly brings no value. I propose to remove 
it.

> [IEP-35] Monitoring Phase 1
> --
>
> Key: IGNITE-11848
> URL: https://issues.apache.org/jira/browse/IGNITE-11848
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 2.7
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: IEP-35
> Fix For: 2.8
>
>  Time Spent: 7h
>  Remaining Estimate: 0h
>
> Umbrella ticket for the IEP-35. Monitoring and profiling.
> Phase 1 should include:
>  * NextGen monitoring subsystem implementation to manage
>  ** metrics
>  ** -lists- (will be implemented in the following tickets)
>  ** exporters
>  * JMX, SQLView, Log exporters
>  * Migration of existing metrics to new manager
>  * -Lists for all Ignite user API-



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12042) Atempt to remove entries from fully populated data region may result in IgineOutOfMemoryException

2019-08-15 Thread Vyacheslav Koptilin (JIRA)


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

Vyacheslav Koptilin commented on IGNITE-12042:
--

Hi [~xtern],

Thank you for valuable feedback. Well, I would propose to merge this PR for now 
(yep, I agree with you that this workaround is not the best, obviously). The 
next step is trying to prepare a better solution that will overcome existing 
drawbacks.

> Atempt to remove entries from fully populated data region may result in 
> IgineOutOfMemoryException
> -
>
> Key: IGNITE-12042
> URL: https://issues.apache.org/jira/browse/IGNITE-12042
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Removing entries from non-persistent data region may require allocating a new 
> data page in order to move a tracked page from one bucket of the free-list to 
> another one.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (IGNITE-12075) Wrong table alias when SUM used inside CASE WHEN

2019-08-15 Thread Ilya Kasnacheev (JIRA)


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

Ilya Kasnacheev updated IGNITE-12075:
-
Description: 
https://stackoverflow.com/questions/57472293/ignite-failed-to-run-reduce-query-locally

Consider the following queries: 

{code}
create table user (id int primary key, name varchar);
SELECT CASE WHEN id = 2016 THEN SUM(id) END FROM user GROUP BY id;
{code}

Will cause splitter to try executing wrong SQL:

{code}
Caused by: org.h2.jdbc.JdbcSQLException: Столбец "__Z0.ID" не найден
Column "__Z0.ID" not found; SQL statement:
SELECT
CASE  WHEN (__Z0.ID = 2016) THEN SUM(__C0_0) END __C0_0
FROM PUBLIC.__T0 [42122-197]
{code}

  was:
https://stackoverflow.com/questions/57472293/ignite-failed-to-run-reduce-query-locally

Consider the following queries: 

{code}
create table user (id int primary key, name varchar);
SELECT CASE WHEN id = 2016 THEN SUM(id) END FROM user GROUP BY id;
{code}

Will cause splitter to try executing wrong SQL:

```Caused by: org.h2.jdbc.JdbcSQLException: Столбец "__Z0.ID" не найден
Column "__Z0.ID" not found; SQL statement:
SELECT
CASE  WHEN (__Z0.ID = 2016) THEN SUM(__C0_0) END __C0_0
FROM PUBLIC.__T0 [42122-197]```


> Wrong table alias when SUM used inside CASE WHEN
> 
>
> Key: IGNITE-12075
> URL: https://issues.apache.org/jira/browse/IGNITE-12075
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.7.5
>Reporter: Ilya Kasnacheev
>Priority: Major
>
> https://stackoverflow.com/questions/57472293/ignite-failed-to-run-reduce-query-locally
> Consider the following queries: 
> {code}
> create table user (id int primary key, name varchar);
> SELECT CASE WHEN id = 2016 THEN SUM(id) END FROM user GROUP BY id;
> {code}
> Will cause splitter to try executing wrong SQL:
> {code}
> Caused by: org.h2.jdbc.JdbcSQLException: Столбец "__Z0.ID" не найден
> Column "__Z0.ID" not found; SQL statement:
> SELECT
> CASE  WHEN (__Z0.ID = 2016) THEN SUM(__C0_0) END __C0_0
> FROM PUBLIC.__T0 [42122-197]
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Created] (IGNITE-12075) Wrong table alias when SUM used inside CASE WHEN

2019-08-15 Thread Ilya Kasnacheev (JIRA)
Ilya Kasnacheev created IGNITE-12075:


 Summary: Wrong table alias when SUM used inside CASE WHEN
 Key: IGNITE-12075
 URL: https://issues.apache.org/jira/browse/IGNITE-12075
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.7.5
Reporter: Ilya Kasnacheev


https://stackoverflow.com/questions/57472293/ignite-failed-to-run-reduce-query-locally

Consider the following queries: 

{code}
create table user (id int primary key, name varchar);
SELECT CASE WHEN id = 2016 THEN SUM(id) END FROM user GROUP BY id;
{code}

Will cause splitter to try executing wrong SQL:

```Caused by: org.h2.jdbc.JdbcSQLException: Столбец "__Z0.ID" не найден
Column "__Z0.ID" not found; SQL statement:
SELECT
CASE  WHEN (__Z0.ID = 2016) THEN SUM(__C0_0) END __C0_0
FROM PUBLIC.__T0 [42122-197]```



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-10808) Discovery message queue may build up with TcpDiscoveryMetricsUpdateMessage

2019-08-15 Thread Sergey Chugunov (JIRA)


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

Sergey Chugunov commented on IGNITE-10808:
--

[~DmitriyGovorukhin], [~dmekhanikov], sure, I'll take a look.

> Discovery message queue may build up with TcpDiscoveryMetricsUpdateMessage
> --
>
> Key: IGNITE-10808
> URL: https://issues.apache.org/jira/browse/IGNITE-10808
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Stanislav Lukyanov
>Assignee: Denis Mekhanikov
>Priority: Major
>  Labels: discovery
> Fix For: 2.8
>
> Attachments: IgniteMetricsOverflowTest.java
>
>
> A node receives a new metrics update message every `metricsUpdateFrequency` 
> milliseconds, and the message will be put at the top of the queue (because it 
> is a high priority message).
> If processing one message takes more than `metricsUpdateFrequency` then 
> multiple `TcpDiscoveryMetricsUpdateMessage` will be in the queue. A long 
> enough delay (e.g. caused by a network glitch or GC) may lead to the queue 
> building up tens of metrics update messages which are essentially useless to 
> be processed. Finally, if processing a message on average takes a little more 
> than `metricsUpdateFrequency` (even for a relatively short period of time, 
> say, for a minute due to network issues) then the message worker will end up 
> processing only the metrics updates and the cluster will essentially hang.
> Reproducer is attached. In the test, the queue first builds up and then very 
> slowly being teared down, causing "Failed to wait for PME" messages.
> Need to change ServerImpl's SocketReader not to put another metrics update 
> message to the top of the queue if it already has one (or replace the one at 
> the top with new one).



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Assigned] (IGNITE-12068) puzzling select result

2019-08-15 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin reassigned IGNITE-12068:
---

Assignee: Ivan Pavlukhin

> puzzling select result
> --
>
> Key: IGNITE-12068
> URL: https://issues.apache.org/jira/browse/IGNITE-12068
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.7.5
> Environment: System version: CentOS Linux release 7.6.1810 (Core)
> Apache Ignite version: apache-ignite-2.7.5-1.noarch
>Reporter: JerryKwan
>Assignee: Ivan Pavlukhin
>Priority: Blocker
> Fix For: 2.7.6
>
>
> select using the first primary key only returns one record, but it should 
> return more records.
> The following is how to reproduce this problem
> 1, create a table using
> CREATE TABLE IF NOT EXISTS Person(
>  id int,
>  city_id int,
>  name varchar,
>  age int, 
>  company varchar,
>  PRIMARY KEY (id, city_id)
> );
> 2, insert some records
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Doe', 3);
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Dean', 4);
> INSERT INTO Person (id, name, city_id) VALUES (2, 'Alex', 4);
> 3, query using 'select * from Person' show all of the records, expected
> [http://www.passimage.in/i/03da31c8f23cf64580d5.png]
> 4, query using 'select * from Person where id=1', only get one record, NOT 
> expected
> [http://www.passimage.in/i/f5491491a70c5d796823.png]
> 5, query using 'select * from Person where city_id=4' get  two records, 
> expected
> [http://www.passimage.in/i/ff0ee4f5e882983d779d.png]
> Why  'select * from Person where id=1', only get one record? and how to fix 
> this? Is there any special operations/configurations to do?



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (IGNITE-12068) puzzling select result

2019-08-15 Thread Denis Magda (JIRA)


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

Denis Magda updated IGNITE-12068:
-
Fix Version/s: 2.7.6

> puzzling select result
> --
>
> Key: IGNITE-12068
> URL: https://issues.apache.org/jira/browse/IGNITE-12068
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.7.5
> Environment: System version: CentOS Linux release 7.6.1810 (Core)
> Apache Ignite version: apache-ignite-2.7.5-1.noarch
>Reporter: JerryKwan
>Priority: Blocker
> Fix For: 2.7.6
>
>
> select using the first primary key only returns one record, but it should 
> return more records.
> The following is how to reproduce this problem
> 1, create a table using
> CREATE TABLE IF NOT EXISTS Person(
>  id int,
>  city_id int,
>  name varchar,
>  age int, 
>  company varchar,
>  PRIMARY KEY (id, city_id)
> );
> 2, insert some records
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Doe', 3);
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Dean', 4);
> INSERT INTO Person (id, name, city_id) VALUES (2, 'Alex', 4);
> 3, query using 'select * from Person' show all of the records, expected
> [http://www.passimage.in/i/03da31c8f23cf64580d5.png]
> 4, query using 'select * from Person where id=1', only get one record, NOT 
> expected
> [http://www.passimage.in/i/f5491491a70c5d796823.png]
> 5, query using 'select * from Person where city_id=4' get  two records, 
> expected
> [http://www.passimage.in/i/ff0ee4f5e882983d779d.png]
> Why  'select * from Person where id=1', only get one record? and how to fix 
> this? Is there any special operations/configurations to do?



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12068) puzzling select result

2019-08-15 Thread Denis Magda (JIRA)


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

Denis Magda commented on IGNITE-12068:
--

Raising to a blocker. Let's make it to 2.7.6.

> puzzling select result
> --
>
> Key: IGNITE-12068
> URL: https://issues.apache.org/jira/browse/IGNITE-12068
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.7.5
> Environment: System version: CentOS Linux release 7.6.1810 (Core)
> Apache Ignite version: apache-ignite-2.7.5-1.noarch
>Reporter: JerryKwan
>Priority: Blocker
>
> select using the first primary key only returns one record, but it should 
> return more records.
> The following is how to reproduce this problem
> 1, create a table using
> CREATE TABLE IF NOT EXISTS Person(
>  id int,
>  city_id int,
>  name varchar,
>  age int, 
>  company varchar,
>  PRIMARY KEY (id, city_id)
> );
> 2, insert some records
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Doe', 3);
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Dean', 4);
> INSERT INTO Person (id, name, city_id) VALUES (2, 'Alex', 4);
> 3, query using 'select * from Person' show all of the records, expected
> [http://www.passimage.in/i/03da31c8f23cf64580d5.png]
> 4, query using 'select * from Person where id=1', only get one record, NOT 
> expected
> [http://www.passimage.in/i/f5491491a70c5d796823.png]
> 5, query using 'select * from Person where city_id=4' get  two records, 
> expected
> [http://www.passimage.in/i/ff0ee4f5e882983d779d.png]
> Why  'select * from Person where id=1', only get one record? and how to fix 
> this? Is there any special operations/configurations to do?



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (IGNITE-12068) puzzling select result

2019-08-15 Thread Denis Magda (JIRA)


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

Denis Magda updated IGNITE-12068:
-
Priority: Blocker  (was: Critical)

> puzzling select result
> --
>
> Key: IGNITE-12068
> URL: https://issues.apache.org/jira/browse/IGNITE-12068
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.7.5
> Environment: System version: CentOS Linux release 7.6.1810 (Core)
> Apache Ignite version: apache-ignite-2.7.5-1.noarch
>Reporter: JerryKwan
>Priority: Blocker
>
> select using the first primary key only returns one record, but it should 
> return more records.
> The following is how to reproduce this problem
> 1, create a table using
> CREATE TABLE IF NOT EXISTS Person(
>  id int,
>  city_id int,
>  name varchar,
>  age int, 
>  company varchar,
>  PRIMARY KEY (id, city_id)
> );
> 2, insert some records
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Doe', 3);
> INSERT INTO Person (id, name, city_id) VALUES (1, 'John Dean', 4);
> INSERT INTO Person (id, name, city_id) VALUES (2, 'Alex', 4);
> 3, query using 'select * from Person' show all of the records, expected
> [http://www.passimage.in/i/03da31c8f23cf64580d5.png]
> 4, query using 'select * from Person where id=1', only get one record, NOT 
> expected
> [http://www.passimage.in/i/f5491491a70c5d796823.png]
> 5, query using 'select * from Person where city_id=4' get  two records, 
> expected
> [http://www.passimage.in/i/ff0ee4f5e882983d779d.png]
> Why  'select * from Person where id=1', only get one record? and how to fix 
> this? Is there any special operations/configurations to do?



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (IGNITE-12073) The doc should mention IGNITE_UPDATE_NOTIFIER has no effect if you're not the first node that started up

2019-08-15 Thread Artem Budnikov (JIRA)


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

Artem Budnikov updated IGNITE-12073:

Labels: javadoc  (was: )

> The doc should mention IGNITE_UPDATE_NOTIFIER has no effect if you're not the 
> first node that started up
> 
>
> Key: IGNITE-12073
> URL: https://issues.apache.org/jira/browse/IGNITE-12073
> Project: Ignite
>  Issue Type: Improvement
>Reporter: chin
>Priority: Major
>  Labels: javadoc
>
> It drove me crazy
> I wanted to disable the auto update check.
> I found this page
> [https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteSystemProperties.html#IGNITE_UPDATE_NOTIFIER]
>  
> spent a few hours trying to set the system property in different ways but 
> couldn't get the update notification to go away.
>  
> Then I found IGNITE-2350.
>  
> That info should be mentioned clearly in the docs.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (IGNITE-2350) Make IGNITE_UPDATE_NOTIFIER per cluster setting

2019-08-15 Thread Artem Budnikov (JIRA)


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

Artem Budnikov updated IGNITE-2350:
---
Labels: important  (was: important javadoc)

> Make IGNITE_UPDATE_NOTIFIER per cluster setting
> ---
>
> Key: IGNITE-2350
> URL: https://issues.apache.org/jira/browse/IGNITE-2350
> Project: Ignite
>  Issue Type: Task
>Reporter: Yakov Zhdanov
>Assignee: Ilya Suntsov
>Priority: Critical
>  Labels: important
> Fix For: 1.6
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We need to refactor update notification behavior to make it more transparent.
> # The first node (topVer=1) should behave in accordance to its local settings
> # The first node should set cluster-wide default which should survive its 
> (first node) exit.
> # Further nodes should ignore local setting and respect cluster wide value 
> set on cluster start



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (IGNITE-2350) Make IGNITE_UPDATE_NOTIFIER per cluster setting

2019-08-15 Thread Artem Budnikov (JIRA)


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

Artem Budnikov updated IGNITE-2350:
---
Labels: important javadoc  (was: important)

> Make IGNITE_UPDATE_NOTIFIER per cluster setting
> ---
>
> Key: IGNITE-2350
> URL: https://issues.apache.org/jira/browse/IGNITE-2350
> Project: Ignite
>  Issue Type: Task
>Reporter: Yakov Zhdanov
>Assignee: Ilya Suntsov
>Priority: Critical
>  Labels: important, javadoc
> Fix For: 1.6
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We need to refactor update notification behavior to make it more transparent.
> # The first node (topVer=1) should behave in accordance to its local settings
> # The first node should set cluster-wide default which should survive its 
> (first node) exit.
> # Further nodes should ignore local setting and respect cluster wide value 
> set on cluster start



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-12042) Atempt to remove entries from fully populated data region may result in IgineOutOfMemoryException

2019-08-15 Thread Ignite TC Bot (JIRA)


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

Ignite TC Bot commented on IGNITE-12042:


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

> Atempt to remove entries from fully populated data region may result in 
> IgineOutOfMemoryException
> -
>
> Key: IGNITE-12042
> URL: https://issues.apache.org/jira/browse/IGNITE-12042
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Removing entries from non-persistent data region may require allocating a new 
> data page in order to move a tracked page from one bucket of the free-list to 
> another one.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-7285) Add default query timeout

2019-08-15 Thread Ivan Pavlukhin (JIRA)


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

Ivan Pavlukhin commented on IGNITE-7285:


[~samaitra], from configuration standpoint changes look good. But a default 
value is not passed properly. Method {{GridCacheQueryAdapter#timeout(long)}} 
using _default timeout_ from configuration is never used in a production code, 
so I suppose that a timeout is not propagated properly. In API we have 2 types 
of queries supporting timeouts {{SqlFieldsQuery}} and {{SqlQuery}}. 
Mechanically {{QueryParameters#fromQuery}} looks as a good starting point to 
see how timeout is propagated from a user {{SqlFieldsQuery}} for an actual 
execution. Note, that timeout should be propagated to _map_ queries as well. 
Also, all behavior should be validated by tests, at least following execution 
modes should be covered:
* Distributed query against PARTITIONED cache.
* Distributed query against REPLICATED cache.
* Local query.


> Add default query timeout
> -
>
> Key: IGNITE-7285
> URL: https://issues.apache.org/jira/browse/IGNITE-7285
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Saikat Maitra
>Priority: Major
>  Labels: sql-stability
> Fix For: 2.8
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Currently it's possible to provide timeout only on query level. It would be 
> very useful to have default timeout value provided on cache startup. Let's 
> add {{CacheConfiguration#defaultQueryTimeout}} configuration property.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Assigned] (IGNITE-7369) .NET: Thin client: Transactions

2019-08-15 Thread Pavel Tupitsyn (JIRA)


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

Pavel Tupitsyn reassigned IGNITE-7369:
--

Assignee: Pavel Tupitsyn

> .NET: Thin client: Transactions
> ---
>
> Key: IGNITE-7369
> URL: https://issues.apache.org/jira/browse/IGNITE-7369
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, iep-34
> Fix For: 2.8
>
>
> Implement transactions in thin client protocol and .NET thin client.
> Main issue: Ignite transactions are tied to a specific thread.
> See how JDBC works around this by starting a dedicated thread.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-9410) Add transactions support to thin clients

2019-08-15 Thread Pavel Tupitsyn (JIRA)


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

Pavel Tupitsyn commented on IGNITE-9410:


[~alex_pl] looks good to me in general, great job!
Please see some comments on GitHub.
Main concern is a system property usage, I think we should move that to 
ClientConnectorConfiguration.

> Add transactions support to thin clients
> 
>
> Key: IGNITE-9410
> URL: https://issues.apache.org/jira/browse/IGNITE-9410
> Project: Ignite
>  Issue Type: Task
>  Components: mvcc, thin client
>Reporter: Vladimir Ozerov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: iep-34
> Fix For: 2.8
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Currently only ODBC and JDBC drivers support transactions and in not very 
> efficient way. We need to add transactional API to .NET, Java, CPP, NodeJS 
> and Python clients.
> Key pieces:
> # Add API to relevant clients
> # Review listener logic - currently we create separate threads. But is it 
> really needed? 
> ## If there is an implicit operation and no ongoing transaction, then 
> operation might be executed right away
> ## If cache operations are decoupled from threads, then we can resort to 
> reactive approach, when multiple transactions could be executed from the same 
> thread



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Comment Edited] (IGNITE-9410) Add transactions support to thin clients

2019-08-15 Thread Pavel Tupitsyn (JIRA)


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

Pavel Tupitsyn edited comment on IGNITE-9410 at 8/15/19 8:43 AM:
-

[~alex_pl] looks good to me in general, great job!
Please see some comments on GitHub.
Main concern is the system property usage, I think we should move that to 
ClientConnectorConfiguration.


was (Author: ptupitsyn):
[~alex_pl] looks good to me in general, great job!
Please see some comments on GitHub.
Main concern is a system property usage, I think we should move that to 
ClientConnectorConfiguration.

> Add transactions support to thin clients
> 
>
> Key: IGNITE-9410
> URL: https://issues.apache.org/jira/browse/IGNITE-9410
> Project: Ignite
>  Issue Type: Task
>  Components: mvcc, thin client
>Reporter: Vladimir Ozerov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: iep-34
> Fix For: 2.8
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Currently only ODBC and JDBC drivers support transactions and in not very 
> efficient way. We need to add transactional API to .NET, Java, CPP, NodeJS 
> and Python clients.
> Key pieces:
> # Add API to relevant clients
> # Review listener logic - currently we create separate threads. But is it 
> really needed? 
> ## If there is an implicit operation and no ongoing transaction, then 
> operation might be executed right away
> ## If cache operations are decoupled from threads, then we can resort to 
> reactive approach, when multiple transactions could be executed from the same 
> thread



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-11584) Implement batch insertion of new cache entries in FreeList to improve rebalancing

2019-08-15 Thread Pavel Pereslegin (JIRA)


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

Pavel Pereslegin commented on IGNITE-11584:
---

[~akalashnikov], thanks for your comments on upsource.
Upsource is experiencing some problems with email notifications and I missed 
them.
Could you look at my answers?

> Implement batch insertion of new cache entries in FreeList to improve 
> rebalancing
> -
>
> Key: IGNITE-11584
> URL: https://issues.apache.org/jira/browse/IGNITE-11584
> Project: Ignite
>  Issue Type: Sub-task
>Affects Versions: 2.7
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: iep-32
> Fix For: 2.8
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Main goals:
>  * Implement batch insert operation into FreeList - insert several data rows 
> at once
>  * Use batch insertion in the preloader
>   
> Implementation notes:
>  # Preloader cannot lock multiple cache entries at once, because this may 
> lead to a deadlock with concurrent batch updates. Therefore, it pre-creates 
> batch of data rows in the page memory, and then sequentially initializes the 
> cache entries one by one.
>  # Batch writing of data rows into data pages uses the free list as usual 
> because other approaches increase memory fragmentation (for example, using 
> only "reuse" or "most free" buckets).
>  # Eviction tracker assumes that only data pages with "heads" of fragmented 
> data row are tracked, so all other fragments of large data row should be 
> written on separate data pages (without other data rows which may cause page 
> tracking).



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Assigned] (IGNITE-7369) .NET: Thin client: Transactions

2019-08-15 Thread Aleksey Plekhanov (JIRA)


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

Aleksey Plekhanov reassigned IGNITE-7369:
-

Assignee: (was: Aleksey Plekhanov)

> .NET: Thin client: Transactions
> ---
>
> Key: IGNITE-7369
> URL: https://issues.apache.org/jira/browse/IGNITE-7369
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, iep-34
> Fix For: 2.8
>
>
> Implement transactions in thin client protocol and .NET thin client.
> Main issue: Ignite transactions are tied to a specific thread.
> See how JDBC works around this by starting a dedicated thread.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-7369) .NET: Thin client: Transactions

2019-08-15 Thread Aleksey Plekhanov (JIRA)


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

Aleksey Plekhanov commented on IGNITE-7369:
---

Protocol changes were implemented by IGNITE-9410.

This ticket should implement only support from .NET client side.

> .NET: Thin client: Transactions
> ---
>
> Key: IGNITE-7369
> URL: https://issues.apache.org/jira/browse/IGNITE-7369
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: .NET, iep-34
> Fix For: 2.8
>
>
> Implement transactions in thin client protocol and .NET thin client.
> Main issue: Ignite transactions are tied to a specific thread.
> See how JDBC works around this by starting a dedicated thread.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)