[jira] [Commented] (IGNITE-6190) SQL query fails silently if Set is passed as a parameter

[Roman Shtykh (JIRA)]

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

Roman Shtykh commented on IGNITE-6190:
--

[~sergi.vladykin] May I ask you to review this pr?

> SQL query fails silently if Set is passed as a parameter
> 
>
> Key: IGNITE-6190
> URL: https://issues.apache.org/jira/browse/IGNITE-6190
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Denis Magda
>Assignee: Roman Shtykh
>  Labels: usability
> Attachments: TestIgniteQuery.zip
>
>
> Seems like the SqlQuery API does not like {{Set}} as the input parameter. 
> While this query doesn't work (the Set is used as an input):
> {code}
> public Map getAccountsForLe(Set leId) {
> SqlQuery query =
> new SqlQuery(Account.class, "from Account join 
> table(id varchar = ?) i on Account.clientLegalEntityId = i.id")
> .setArgs(leId);
> Map results = new HashMap<>();
> _cache.query(query).getAll().stream().forEach(e -> 
> results.put(e.getKey(), e.getValue()));
> return results;
> }
> {code}
> This one works well (the Set is converted to Array explicitly):
> {code}
> public Map getAccountsForLe(Set leId) {
> SqlQuery query =
> new SqlQuery(Account.class, "from Account join 
> table(id varchar = ?) i on Account.clientLegalEntityId = i.id")
> .setArgs(leId.toArray());
> Map results = new HashMap<>();
> _cache.query(query).getAll().stream().forEach(e -> 
> results.put(e.getKey(), e.getValue()));
> return results;
> }
> {code}
> The fact that it fails silently is an issue. IMHO there should be some 
> validation to alert the calling code that the type specified is not valid or 
> the set has to be transformed to the array on the fly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6526) Ignite 2.x capacity planning guide

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan updated IGNITE-6526:
--
Fix Version/s: 2.3

> Ignite 2.x capacity planning guide
> --
>
> Key: IGNITE-6526
> URL: https://issues.apache.org/jira/browse/IGNITE-6526
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>  Labels: documentaion
> Fix For: 2.3
>
>
> Current capacity planning guide [1] is too high level and should be 
> elaborated considering durable memory's internals:
> - memory pages overhead.
> - per-entry overhead 
> (http://apache-ignite-users.70518.x6.nabble.com/Re-Memory-Overhead-per-entry-in-Apache-Ignite-td9498.html).
> - space occupied for indexing needs.
> - free lists
> - etc.
> The page has to include estimates for the Ignite Native Persistence:
> - entry size and its overheads.
> - index size and overheads.
> - data files overheads.
> - estimated WAL size and how to shrink it basing on checkpointing settings.
> [1] https://apacheignite.readme.io/docs/capacity-planning



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6526) Ignite 2.x capacity planning guide

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan updated IGNITE-6526:
--
Labels: documentaion  (was: )

> Ignite 2.x capacity planning guide
> --
>
> Key: IGNITE-6526
> URL: https://issues.apache.org/jira/browse/IGNITE-6526
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>  Labels: documentaion
> Fix For: 2.3
>
>
> Current capacity planning guide [1] is too high level and should be 
> elaborated considering durable memory's internals:
> - memory pages overhead.
> - per-entry overhead 
> (http://apache-ignite-users.70518.x6.nabble.com/Re-Memory-Overhead-per-entry-in-Apache-Ignite-td9498.html).
> - space occupied for indexing needs.
> - free lists
> - etc.
> The page has to include estimates for the Ignite Native Persistence:
> - entry size and its overheads.
> - index size and overheads.
> - data files overheads.
> - estimated WAL size and how to shrink it basing on checkpointing settings.
> [1] https://apacheignite.readme.io/docs/capacity-planning



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6527) Deadlock detection works incorrectly with some timeouts that haven't caused by deadlocks.

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov commented on IGNITE-6527:
--

Hi, [~agura].
I'll ask you to see when my solutions are ready. 

> Deadlock detection works incorrectly with some timeouts that haven't caused 
> by deadlocks.
> -
>
> Key: IGNITE-6527
> URL: https://issues.apache.org/jira/browse/IGNITE-6527
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
> Attachments: TxOptimisticDeadlockDetectionIncorrectMessageTest.java
>
>
> Deadlock detection works incorrectly with timeouts that haven't caused by 
> deadlocks. In case of a deadlock in future. Or can detect another deadlock 
> which was not the cause of timeout.
> *requested keys:* keys primary for the same node and blocking in sequential 
> order during the timeout (or all keys that haven't locked by an optimistic 
> transaction in case of near cache).
> *candidates:* keys candidates to be locked on a primary node (entries 
> contains in  GridDhtTxLocal). 
> In the process of updating the Wait-For-Graph requested keys used as 
> candidates.  But "TxDeadlock.toString" method use candidates which were 
> received from messages. 
> 1) It causes an incorrect error message.
> Example: 
> K1: TX1 holds lock, TX2 waits lock.
> K2: TX3 holds lock, TX1 waits lock.
> Transactions:
> TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
> TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
> TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457]
> Keys:
> K1 [key=6, cache=cache]
> K2 [key=1, cache=cache]
> 2) DD can detect another deadlock which was not the cause of timeout but it 
> would be the cause if the current deadlock did not happen.
> These are very rare situations, but they can happen.
> I see several solutions:
> * Just make a correct message.
> * log warn and continue detecting.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6502) Need to output warning if -Djava.net.preferIPv4Stack=true is not set

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6502:


GitHub user vk23 opened a pull request:

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

IGNITE-6502: Print warning if -Djava.net.preferIPv4Stack=true is not set

Print warning if -Djava.net.preferIPv4Stack=true is not set

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

$ git pull https://github.com/vk23/ignite ignite-6502

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

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

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

This closes #2776


commit 294ab1c55d086ed42a92133463d373f5ae90807f
Author: vk 
Date:   2017-09-28T19:37:33Z

IGNITE-6502: Print warning if -Djava.net.preferIPv4Stack=true is not set




> Need to output warning if -Djava.net.preferIPv4Stack=true is not set
> 
>
> Key: IGNITE-6502
> URL: https://issues.apache.org/jira/browse/IGNITE-6502
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: vk
>  Labels: usability
> Fix For: 2.3
>
>
> Some issues were reported on dev/user list that may be caused by ipv6 usage. 
> I am not sure if Ignite can properly work with ipv6 networks. This needs to 
> be tested and another issue has been filed - 
> https://issues.apache.org/jira/browse/IGNITE-6503.
> For now it seems to be pretty handy just to have warning on node start:
> {noformat}
> Please set system property '-Djava.net.preferIPv4Stack=true' to avoid 
> possible problems in mixed environments.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6530) Supposed deadlock with persistent store

[Joel Lang (JIRA)]

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

Joel Lang updated IGNITE-6530:
--
Summary: Supposed deadlock with persistent store  (was: Deadlock in 
checkpointReadLock method in GridCacheDatabaseSharedManager)

> Supposed deadlock with persistent store
> ---
>
> Key: IGNITE-6530
> URL: https://issues.apache.org/jira/browse/IGNITE-6530
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.2
>Reporter: Joel Lang
>
> Just started receiving a great deal of warnings about possible starvation in 
> stripped pool.
> The stack trace shows it happens in checkpointReadLock() in 
> GridCacheDatabaseSharedManager.
> Here are the log messages:
> {noformat}
> 2017-09-28 12:08:09 [grid-timeout-worker-#15%mbe%] WARN  
> o.apache.ignite.internal.diagnostic - Found long running cache future 
> [startTime=12:05:12.016, curTime=12:08:09.947, fut=GridNearAtomicUpdateFuture 
> [mappings={922dc862-feed-4245-a014-fde00f21eac1=Primary 
> [id=922dc862-feed-4245-a014-fde00f21eac1, opRes=true, expCnt=-1, rcvdCnt=0, 
> primaryRes=true, done=true, waitFor=null, rcvd=null], 
> 592ff27f-e7d2-45c0-8415-4cca0ce8e11e=Primary 
> [id=592ff27f-e7d2-45c0-8415-4cca0ce8e11e, opRes=false, expCnt=-1, rcvdCnt=0, 
> primaryRes=false, done=false, waitFor=null, rcvd=null]}, remapKeys=null, 
> singleReq=null, resCnt=1, super=GridNearAtomicAbstractUpdateFuture 
> [remapCnt=100, topVer=AffinityTopologyVersion [topVer=2, minorTopVer=2], 
> remapTopVer=null, err=null, futId=655361, super=GridFutureAdapter 
> [ignoreInterrupts=false, state=INIT, res=null, hash=1699524044
> 2017-09-28 12:08:09 [grid-timeout-worker-#15%mbe%] WARN  
> o.apache.ignite.internal.diagnostic - Found long running cache future 
> [startTime=12:05:12.054, curTime=12:08:09.947, fut=GridNearAtomicUpdateFuture 
> [mappings={592ff27f-e7d2-45c0-8415-4cca0ce8e11e=Primary 
> [id=592ff27f-e7d2-45c0-8415-4cca0ce8e11e, opRes=false, expCnt=-1, rcvdCnt=0, 
> primaryRes=false, done=false, waitFor=null, rcvd=null], 
> 922dc862-feed-4245-a014-fde00f21eac1=Primary 
> [id=922dc862-feed-4245-a014-fde00f21eac1, opRes=true, expCnt=-1, rcvdCnt=0, 
> primaryRes=true, done=true, waitFor=null, rcvd=null]}, remapKeys=null, 
> singleReq=null, resCnt=1, super=GridNearAtomicAbstractUpdateFuture 
> [remapCnt=100, topVer=AffinityTopologyVersion [topVer=2, minorTopVer=2], 
> remapTopVer=null, err=null, futId=671745, super=GridFutureAdapter 
> [ignoreInterrupts=false, state=INIT, res=null, hash=1175088539
> 2017-09-28 12:08:10 [grid-timeout-worker-#15%mbe%] WARN  
> o.a.ignite.internal.util.typedef.G - >>> Possible starvation in striped pool.
> Thread name: sys-stripe-0-#1%mbe%
> Queue: [Message closure [msg=GridIoMessage [plc=2, topic=TOPIC_CACHE, 
> topicOrd=8, ordered=false, timeout=0, skipOnTimeout=false, 
> msg=GridNearAtomicSingleUpdateRequest [key=BinaryObjectImpl [arr= true, 
> ctx=false, start=0], parent=GridNearAtomicAbstractUpdateRequest [res=null, 
> flags=, Message closure [msg=GridIoMessage [plc=2, topic=TOPIC_CACHE, 
> topicOrd=8, ordered=false, timeout=0, skipOnTimeout=false, 
> msg=GridNearAtomicSingleUpdateRequest [key=KeyCacheObjectImpl [part=0, 
> val=null, hasValBytes=true], parent=GridNearAtomicAbstractUpdateRequest 
> [res=null, flags=, Message closure [msg=GridIoMessage [plc=2, 
> topic=TOPIC_CACHE, topicOrd=8, ordered=false, timeout=0, skipOnTimeout=false, 
> msg=GridNearAtomicSingleUpdateRequest [key=KeyCacheObjectImpl [part=0, 
> val=null, hasValBytes=true], parent=GridNearAtomicAbstractUpdateRequest 
> [res=null, flags=]
> Deadlock: true
> Completed: 3174
> Thread [name="sys-stripe-0-#1%mbe%", id=15, state=WAITING, blockCnt=4, 
> waitCnt=5789]
> Lock 
> [object=java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@2e1993dd,
>  ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(Unknown Source)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(Unknown
>  Source)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(Unknown 
> Source)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(Unknown 
> Source)
> at 
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(Unknown 
> Source)
> at 
> o.a.i.i.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:847)
> at 
> o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1770)
> at 
> 

[jira] [Updated] (IGNITE-6530) Deadlock in checkpointReadLock method in GridCacheDatabaseSharedManager

[Joel Lang (JIRA)]

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

Joel Lang updated IGNITE-6530:
--
Description: 
Just started receiving a great deal of warnings about possible starvation in 
stripped pool.

The stack trace shows it happens in checkpointReadLock() in 
GridCacheDatabaseSharedManager.

Here are the log messages:


{noformat}
2017-09-28 12:08:09 [grid-timeout-worker-#15%mbe%] WARN  
o.apache.ignite.internal.diagnostic - Found long running cache future 
[startTime=12:05:12.016, curTime=12:08:09.947, fut=GridNearAtomicUpdateFuture 
[mappings={922dc862-feed-4245-a014-fde00f21eac1=Primary 
[id=922dc862-feed-4245-a014-fde00f21eac1, opRes=true, expCnt=-1, rcvdCnt=0, 
primaryRes=true, done=true, waitFor=null, rcvd=null], 
592ff27f-e7d2-45c0-8415-4cca0ce8e11e=Primary 
[id=592ff27f-e7d2-45c0-8415-4cca0ce8e11e, opRes=false, expCnt=-1, rcvdCnt=0, 
primaryRes=false, done=false, waitFor=null, rcvd=null]}, remapKeys=null, 
singleReq=null, resCnt=1, super=GridNearAtomicAbstractUpdateFuture 
[remapCnt=100, topVer=AffinityTopologyVersion [topVer=2, minorTopVer=2], 
remapTopVer=null, err=null, futId=655361, super=GridFutureAdapter 
[ignoreInterrupts=false, state=INIT, res=null, hash=1699524044
2017-09-28 12:08:09 [grid-timeout-worker-#15%mbe%] WARN  
o.apache.ignite.internal.diagnostic - Found long running cache future 
[startTime=12:05:12.054, curTime=12:08:09.947, fut=GridNearAtomicUpdateFuture 
[mappings={592ff27f-e7d2-45c0-8415-4cca0ce8e11e=Primary 
[id=592ff27f-e7d2-45c0-8415-4cca0ce8e11e, opRes=false, expCnt=-1, rcvdCnt=0, 
primaryRes=false, done=false, waitFor=null, rcvd=null], 
922dc862-feed-4245-a014-fde00f21eac1=Primary 
[id=922dc862-feed-4245-a014-fde00f21eac1, opRes=true, expCnt=-1, rcvdCnt=0, 
primaryRes=true, done=true, waitFor=null, rcvd=null]}, remapKeys=null, 
singleReq=null, resCnt=1, super=GridNearAtomicAbstractUpdateFuture 
[remapCnt=100, topVer=AffinityTopologyVersion [topVer=2, minorTopVer=2], 
remapTopVer=null, err=null, futId=671745, super=GridFutureAdapter 
[ignoreInterrupts=false, state=INIT, res=null, hash=1175088539
2017-09-28 12:08:10 [grid-timeout-worker-#15%mbe%] WARN  
o.a.ignite.internal.util.typedef.G - >>> Possible starvation in striped pool.
Thread name: sys-stripe-0-#1%mbe%
Queue: [Message closure [msg=GridIoMessage [plc=2, topic=TOPIC_CACHE, 
topicOrd=8, ordered=false, timeout=0, skipOnTimeout=false, 
msg=GridNearAtomicSingleUpdateRequest [key=BinaryObjectImpl [arr= true, 
ctx=false, start=0], parent=GridNearAtomicAbstractUpdateRequest [res=null, 
flags=, Message closure [msg=GridIoMessage [plc=2, topic=TOPIC_CACHE, 
topicOrd=8, ordered=false, timeout=0, skipOnTimeout=false, 
msg=GridNearAtomicSingleUpdateRequest [key=KeyCacheObjectImpl [part=0, 
val=null, hasValBytes=true], parent=GridNearAtomicAbstractUpdateRequest 
[res=null, flags=, Message closure [msg=GridIoMessage [plc=2, 
topic=TOPIC_CACHE, topicOrd=8, ordered=false, timeout=0, skipOnTimeout=false, 
msg=GridNearAtomicSingleUpdateRequest [key=KeyCacheObjectImpl [part=0, 
val=null, hasValBytes=true], parent=GridNearAtomicAbstractUpdateRequest 
[res=null, flags=]
Deadlock: true
Completed: 3174
Thread [name="sys-stripe-0-#1%mbe%", id=15, state=WAITING, blockCnt=4, 
waitCnt=5789]
Lock 
[object=java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@2e1993dd, 
ownerName=null, ownerId=-1]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(Unknown Source)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(Unknown
 Source)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(Unknown 
Source)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(Unknown 
Source)
at 
java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(Unknown Source)
at 
o.a.i.i.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:847)
at 
o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1770)
at 
o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1686)
at 
o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3063)
at 
o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:129)
at 
o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:265)
at 
o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:260)
at 
o.a.i.i.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1042)
at 

[jira] [Created] (IGNITE-6530) Deadlock in checkpointReadLock method in GridCacheDatabaseSharedManager

[Joel Lang (JIRA)]

Joel Lang created IGNITE-6530:
-

 Summary: Deadlock in checkpointReadLock method in 
GridCacheDatabaseSharedManager
 Key: IGNITE-6530
 URL: https://issues.apache.org/jira/browse/IGNITE-6530
 Project: Ignite
  Issue Type: Bug
  Components: persistence
Affects Versions: 2.2
Reporter: Joel Lang


Just started receiving a great deal of warnings about possible starvation in 
stripped pool.

The stack trace shows it happens in checkpointReadLock() in 
GridCacheDatabaseSharedManager.

Here are the log messages:

{noformat}
2017-09-28 13:15:12 [grid-timeout-worker-#15%mbe%] WARN  
o.a.ignite.internal.util.typedef.G - >>> Possible starvation in striped pool.
Thread name: sys-stripe-4-#5%mbe%
Queue: [Message closure [msg=GridIoMessage [plc=2, topic=TOPIC_CACHE, 
topicOrd=8, ordered=false, timeout=0, skipOnTimeout=false, 
msg=GridNearAtomicSingleUpdateRequest [key=BinaryObjectImpl [arr= true, 
ctx=false, start=0], parent=GridNearAtomicAbstractUpdateRequest [res=null, 
flags=]
Deadlock: true
Completed: 3212
Thread [name="sys-stripe-4-#5%mbe%", id=19, state=WAITING, blockCnt=12, 
waitCnt=5835]
Lock 
[object=java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@2e1993dd, 
ownerName=null, ownerId=-1]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(Unknown Source)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(Unknown
 Source)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(Unknown 
Source)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(Unknown 
Source)
at 
java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(Unknown Source)
at 
o.a.i.i.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:847)
at 
o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1770)
at 
o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1686)
at 
o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3063)
at 
o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:129)
at 
o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:265)
at 
o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:260)
at 
o.a.i.i.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1042)
at 
o.a.i.i.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561)
at 
o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at 
o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at 
o.a.i.i.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at 
o.a.i.i.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at 
o.a.i.i.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at 
o.a.i.i.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at 
o.a.i.i.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
at 
o.a.i.i.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
at o.a.i.i.util.StripedExecutor$Stripe.run(StripedExecutor.java:483)
at java.lang.Thread.run(Unknown Source)

2017-09-28 13:15:12 [grid-timeout-worker-#15%mbe%] WARN  
o.a.ignite.internal.util.typedef.G - >>> Possible starvation in striped pool.
Thread name: sys-stripe-5-#6%mbe%
Queue: [Message closure [msg=GridIoMessage [plc=2, topic=TOPIC_CACHE, 
topicOrd=8, ordered=false, timeout=0, skipOnTimeout=false, 
msg=GridNearAtomicSingleUpdateRequest [key=BinaryObjectImpl [arr= true, 
ctx=false, start=0], parent=GridNearAtomicAbstractUpdateRequest [res=null, 
flags=]
Deadlock: true
Completed: 3524
Thread [name="sys-stripe-5-#6%mbe%", id=20, state=WAITING, blockCnt=3, 
waitCnt=6730]
Lock 
[object=java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@2e1993dd, 
ownerName=null, ownerId=-1]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(Unknown Source)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(Unknown
 Source)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(Unknown 
Source)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(Unknown 
Source)
 

[jira] [Comment Edited] (IGNITE-6512) Add an option to start caches in inactive state

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev edited comment on IGNITE-6512 at 9/28/17 6:17 PM:


PR:
https://github.com/apache/ignite/pull/2772

Test run:
https://ci.ignite.apache.org/viewQueued.html?itemId=860474


was (Author: edshanggg):
PR:
https://github.com/apache/ignite/pull/2772

Test run:
https://ci.ignite.apache.org/viewQueued.html?itemId=859830

> Add an option to start caches in inactive state
> ---
>
> Key: IGNITE-6512
> URL: https://issues.apache.org/jira/browse/IGNITE-6512
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>
> Now we always discard restarting state on cache while it is starting.
> But sometimes we need extra steps before making caches available from public 
> API.
> So, I suggest adding a new method which would be called when we want to make 
> caches available for public API clients.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6416) SQL: DDL tests should not check internal structures, but rather rely on expected public behavior

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6416:


GitHub user alexpaschenko opened a pull request:

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

IGNITE-6416



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

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

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

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

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

This closes #2774


commit 52d9168e5879470161b4a72735bfcd849dfa13c6
Author: Alexander Paschenko 
Date:   2017-09-28T17:56:23Z

IGNITE-6416 Dynamic columns tests refactoring.

commit e7d3eec3b7ff5dcefc396ffab62455271db70618
Author: Alexander Paschenko 
Date:   2017-09-28T18:00:21Z

Minor.




> SQL: DDL tests should not check internal structures, but rather rely on 
> expected public behavior
> 
>
> Key: IGNITE-6416
> URL: https://issues.apache.org/jira/browse/IGNITE-6416
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>
> We need to review our DDL tests. Looks like there are a lot waits in the 
> tests which mask concurrency bugs (e.g. see IGNITE-6403). Instead, we should 
> do the following:
> 1) If we want to tests asynchronous propagation of changes to clients, 
> separate test should be created for this
> 2) For all other cases we should not use private API at all, and do not 
> perform any waits.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6285) Enhance persistent store paths logging on start

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6285:


Github user dspavlov closed the pull request at:

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


> Enhance persistent store paths logging on start
> ---
>
> Key: IGNITE-6285
> URL: https://issues.apache.org/jira/browse/IGNITE-6285
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Yakov Zhdanov
>Assignee: Dmitriy Pavlov
>Priority: Blocker
>  Labels: documentation, important, usability
> Fix For: 2.3
>
>
> As per this thread - 
> http://apache-ignite-users.70518.x6.nabble.com/Specifying-location-of-persistent-storage-location-td16636i20.html
> Ignite may switch storage path in case of changing DHCP lease or similar 
> which can lead to consistent ID change.
> In order to help user in spotting the issue Ignite may output the following 
> to the logs:
> # Output the store path and tell its (1) size or state that it is empty and 
> (2) last data file modification date.
> # Output warning if there are other non-empty storage folders under work 
> directory with their sizes and dates.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6529) JDBC drivers don't provide correct metadata about columns' nullability

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko updated IGNITE-6529:

Fix Version/s: 2.3

> JDBC drivers don't provide correct metadata about  columns' nullability
> ---
>
> Key: IGNITE-6529
> URL: https://issues.apache.org/jira/browse/IGNITE-6529
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc, sql
>Reporter: Alexander Paschenko
> Fix For: 2.3
>
>
> For complete implementation of IGNITE-5648, we have to make JDBC drivers 
> return correct nullability flag for {{NOT NULL}} columns - currently 
> corresponding param of {{QueryField}} is ignored.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-2092) Ignite does not recognize the right number of CPU cores when running under Docker

[Maxim Neverov (JIRA)]

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

Maxim Neverov commented on IGNITE-2092:
---

[~ntikhonov],
sorry to pester you about this, but is anything I can do to get this ticket 
merged and closed?

> Ignite does not recognize the right number of CPU cores when running under 
> Docker
> -
>
> Key: IGNITE-2092
> URL: https://issues.apache.org/jira/browse/IGNITE-2092
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Maxim Neverov
>  Labels: newbie
> Fix For: 2.3
>
> Attachments: ignite_boot_log.txt
>
>
> Run Ignite under a Docker container.
> Limit Ignite from using all CPUs by way of Docker settings (which internally 
> uses Linux CGROUPS). 
> Ignite will still report that all available CPUs are used ignoring Docker 
> settings.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6529) JDBC drivers don't provide correct metadata about columns' nullability

[Alexander Paschenko (JIRA)]

Alexander Paschenko created IGNITE-6529:
---

 Summary: JDBC drivers don't provide correct metadata about  
columns' nullability
 Key: IGNITE-6529
 URL: https://issues.apache.org/jira/browse/IGNITE-6529
 Project: Ignite
  Issue Type: Bug
  Components: jdbc, sql
Reporter: Alexander Paschenko


For complete implementation of IGNITE-5648, we have to make JDBC drivers return 
correct nullability flag for {{NOT NULL}} columns - currently corresponding 
param of {{QueryField}} is ignored.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[Mikhail Cherkasov (JIRA)]

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

Mikhail Cherkasov updated IGNITE-6528:
--
Fix Version/s: 2.3

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



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[Mikhail Cherkasov (JIRA)]

Mikhail Cherkasov created IGNITE-6528:
-

 Summary: Warning if no table for BinaryObject
 Key: IGNITE-6528
 URL: https://issues.apache.org/jira/browse/IGNITE-6528
 Project: Ignite
  Issue Type: Improvement
  Components: binary, cache, sql
Reporter: Mikhail Cherkasov


I've seen several times that due wrong cache configuration people can't find 
data in cache and blame Ignite that it's buggy and doesn't work.

And it's very difficult to find an error in the code, especially if you don't 
have reach experience with Ignite.

The problem is that we don't have strong typing when defining QueryEntriy and a 
user can use an arbitrary string id to
define a type, but he should use the same string id to obtain binary object 
builder, however, people sometimes confusing this.
So the user can define QueryEntity with value type:  
queryEntity.setValueType("MyCoolName") and 
later put to cache the following binary object: ignite.binary.toBinary(value), 
but this object won't be indexed, because
ignite.binary.toBinary uses class name as string id while indexing expects to 
find "MyCoolName" as id.

The example is simple and the error is obvious when you see this two lines 
close to each other, however, in real life, cache definition and data ingestion 
are separated by tons of code.

We can save a lot of man-hours for our users if Ignite will print a warning If 
a cache has a configured QE and user puts BinaryObject with typeName which 
doesn't correspond to any QE.

The warning should be printed only once, something like:
[WARN] No table is found for %typeName% binary object.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6005) [Test failed] GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6005:


GitHub user nizhikov opened a pull request:

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

IGNITE-6005: Add ability to close datastructure in interrupted thread.



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

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

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

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

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

This closes #2773


commit cee2914a07e84740ba8502f26b5d3bb266b9fc2f
Author: Nikolay Izhikov 
Date:   2017-09-28T16:50:36Z

IGNITE-6005: Add ability to close datastructure in interrupted thread.




> [Test failed] 
> GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe
> -
>
> Key: IGNITE-6005
> URL: https://issues.apache.org/jira/browse/IGNITE-6005
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Nikolay Izhikov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
>
> Example of fail
> https://ci.ignite.apache.org/viewLog.html?buildId=762788=buildResultsDiv=Ignite20Tests_IgniteDataStrucutures
> Typical problem is 
> {code}
> org.apache.ignite.IgniteInterruptedException: Failed to wait for asynchronous 
> operation permit (thread got interrupted).
> at 
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:805)
> at 
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:803)
> at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:961)
> at 
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.close(GridCacheSemaphoreImpl.java:1026)
> at 
> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:458)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.InterruptedException: null
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1301)
> at java.util.concurrent.Semaphore.acquire(Semaphore.java:317)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOpAcquire(GridCacheAdapter.java:4314)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOp(GridCacheAdapter.java:4177)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.getAsync(GridDhtColocatedCache.java:196)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4509)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4490)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1324)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.get(GridCacheProxyImpl.java:329)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor$5.applyx(DataStructuresProcessor.java:635)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.retryTopologySafe(DataStructuresProcessor.java:1519)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.removeDataStructure(DataStructuresProcessor.java:629)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.removeSemaphore(DataStructuresProcessor.java:1188)
> at 
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.close(GridCacheSemaphoreImpl.java:1023)
> at 
> 

[jira] [Resolved] (IGNITE-6516) .NET: PersistentStoreConfiguration.WriteThrottlingEnabled

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-6516.

Resolution: Fixed

> .NET: PersistentStoreConfiguration.WriteThrottlingEnabled
> -
>
> Key: IGNITE-6516
> URL: https://issues.apache.org/jira/browse/IGNITE-6516
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Add {{PersistentStoreConfiguration.WriteThrottlingEnabled}} to .NET.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6516) .NET: PersistentStoreConfiguration.WriteThrottlingEnabled

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-6516:


Merged to master: {{5d6ff970d733adec934825556856d319cfba196d}}.

> .NET: PersistentStoreConfiguration.WriteThrottlingEnabled
> -
>
> Key: IGNITE-6516
> URL: https://issues.apache.org/jira/browse/IGNITE-6516
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Add {{PersistentStoreConfiguration.WriteThrottlingEnabled}} to .NET.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6005) [Test failed] GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov reassigned IGNITE-6005:
---

Assignee: Nikolay Izhikov  (was: Pavel Pereslegin)

> [Test failed] 
> GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe
> -
>
> Key: IGNITE-6005
> URL: https://issues.apache.org/jira/browse/IGNITE-6005
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Nikolay Izhikov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
>
> Example of fail
> https://ci.ignite.apache.org/viewLog.html?buildId=762788=buildResultsDiv=Ignite20Tests_IgniteDataStrucutures
> Typical problem is 
> {code}
> org.apache.ignite.IgniteInterruptedException: Failed to wait for asynchronous 
> operation permit (thread got interrupted).
> at 
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:805)
> at 
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:803)
> at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:961)
> at 
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.close(GridCacheSemaphoreImpl.java:1026)
> at 
> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:458)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.InterruptedException: null
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1301)
> at java.util.concurrent.Semaphore.acquire(Semaphore.java:317)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOpAcquire(GridCacheAdapter.java:4314)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOp(GridCacheAdapter.java:4177)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.getAsync(GridDhtColocatedCache.java:196)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4509)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4490)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1324)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.get(GridCacheProxyImpl.java:329)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor$5.applyx(DataStructuresProcessor.java:635)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.retryTopologySafe(DataStructuresProcessor.java:1519)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.removeDataStructure(DataStructuresProcessor.java:629)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.removeSemaphore(DataStructuresProcessor.java:1188)
> at 
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.close(GridCacheSemaphoreImpl.java:1023)
> at 
> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:458)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at 
> 

[jira] [Updated] (IGNITE-6527) Deadlock detection works incorrectly with some timeouts that haven't caused by deadlocks.

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov updated IGNITE-6527:
-
Summary: Deadlock detection works incorrectly with some timeouts that 
haven't caused by deadlocks.  (was: Deadlock detection works incorrectly with 
timeouts that haven't caused by deadlocks.)

> Deadlock detection works incorrectly with some timeouts that haven't caused 
> by deadlocks.
> -
>
> Key: IGNITE-6527
> URL: https://issues.apache.org/jira/browse/IGNITE-6527
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
> Attachments: TxOptimisticDeadlockDetectionIncorrectMessageTest.java
>
>
> Deadlock detection works incorrectly with timeouts that haven't caused by 
> deadlocks. In case of a deadlock in future. Or can detect another deadlock 
> which was not the cause of timeout.
> *requested keys:* keys primary for the same node and blocking in sequential 
> order during the timeout (or all keys that haven't locked by an optimistic 
> transaction in case of near cache).
> *candidates:* keys candidates to be locked on a primary node (entries 
> contains in  GridDhtTxLocal). 
> In the process of updating the Wait-For-Graph requested keys used as 
> candidates.  But "TxDeadlock.toString" method use candidates which were 
> received from messages. 
> 1) It causes an incorrect error message.
> Example: 
> K1: TX1 holds lock, TX2 waits lock.
> K2: TX3 holds lock, TX1 waits lock.
> Transactions:
> TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
> TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
> TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457]
> Keys:
> K1 [key=6, cache=cache]
> K2 [key=1, cache=cache]
> 2) DD can detect another deadlock which was not the cause of timeout but it 
> would be the cause if the current deadlock did not happen.
> These are very rare situations, but they can happen.
> I see several solutions:
> * Just make a correct message.
> * log warn and continue detecting.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6512) Add an option to start caches in inactive state

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev commented on IGNITE-6512:
---

PR:
https://github.com/apache/ignite/pull/2772

Test run:
https://ci.ignite.apache.org/viewQueued.html?itemId=859830

> Add an option to start caches in inactive state
> ---
>
> Key: IGNITE-6512
> URL: https://issues.apache.org/jira/browse/IGNITE-6512
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>
> Now we always discard restarting state on cache while it is starting.
> But sometimes we need extra steps before making caches available from public 
> API.
> So, I suggest adding a new method which would be called when we want to make 
> caches available for public API clients.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6527) Deadlock detection works incorrectly with timeouts that haven't caused by deadlocks.

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov updated IGNITE-6527:
-
Description: 
Deadlock detection works incorrectly with timeouts that haven't caused by 
deadlocks. In case of a deadlock in future. Or can detect another deadlock 
which was not the cause of timeout.

*requested keys:* keys primary for the same node and blocking in sequential 
order during the timeout (or all keys that haven't locked by an optimistic 
transaction in case of near cache).

*candidates:* keys candidates to be locked on a primary node (entries contains 
in  GridDhtTxLocal). 

In the process of updating the Wait-For-Graph requested keys used as 
candidates.  But "TxDeadlock.toString" method use candidates which were 
received from messages. 

1) It causes an incorrect error message.

Example: 
K1: TX1 holds lock, TX2 waits lock.
K2: TX3 holds lock, TX1 waits lock.

Transactions:

TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457]

Keys:

K1 [key=6, cache=cache]
K2 [key=1, cache=cache]

2) DD can detect another deadlock which was not the cause of timeout but it 
would be the cause if the current deadlock did not happen.

These are very rare situations, but they can happen.

I see several solutions:
* Just make a correct message.
* log warn and continue detecting.




  was:
Deadlock detection works incorrectly with timeouts that haven't caused by 
deadlocks. In case of a deadlock in future. Or can detect another deadlock 
which was not the cause of timeout.

*requested keys:* keys primary for the same node and blocking in sequential 
order during the timeout (or all keys that haven't locked by an optimistic 
transaction in case of near cache).

*candidates:* keys candidates to be locked on a primary node (entries contains 
in  GridDhtTxLocal). 

In the process of updating the Wait-For-Graph requested keys used as 
candidates.  But "TxDeadlock.toString" method use candidates which were 
received from messages. 

1) It causes an incorrect error message.

Example: 
K1: TX1 holds lock, TX2 waits lock.
K2: TX3 holds lock, TX1 waits lock.

Transactions:

TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457]

Keys:

K1 [key=6, cache=cache]
K2 [key=1, cache=cache]

2) It can detect another deadlock which was not the cause of timeout but it 
would be the cause if the current deadlock did not happen.

These are very rare situations, but they can happen.

I see several solutions:
* Just make a correct message.
* log warn and continue detecting.





> Deadlock detection works incorrectly with timeouts that haven't caused by 
> deadlocks.
> 
>
> Key: IGNITE-6527
> URL: https://issues.apache.org/jira/browse/IGNITE-6527
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
> Attachments: TxOptimisticDeadlockDetectionIncorrectMessageTest.java
>
>
> Deadlock detection works incorrectly with timeouts that haven't caused by 
> deadlocks. In case of a deadlock in future. Or can detect another deadlock 
> which was not the cause of timeout.
> *requested keys:* keys primary for the same node and blocking in sequential 
> order during the timeout (or all keys that haven't locked by an optimistic 
> transaction in case of near cache).
> *candidates:* keys candidates to be locked on a primary node (entries 
> contains in  GridDhtTxLocal). 
> In the process of updating the Wait-For-Graph requested keys used as 
> candidates.  But "TxDeadlock.toString" method use candidates which were 
> received from messages. 
> 1) It causes an incorrect error message.
> Example: 
> K1: TX1 holds lock, TX2 waits lock.
> K2: TX3 holds lock, TX1 waits lock.
> Transactions:
> TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
> TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
> TX3 [txId=GridCacheVersion 

[jira] [Updated] (IGNITE-6512) Add an option to start caches in inactive state

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev updated IGNITE-6512:
--
Summary: Add an option to start caches in inactive state  (was: Need a 
possibility to start caches without discarding their 'restarting' state)

> Add an option to start caches in inactive state
> ---
>
> Key: IGNITE-6512
> URL: https://issues.apache.org/jira/browse/IGNITE-6512
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>
> Now we always discard restarting state on cache while it is starting.
> But sometimes we need extra steps before making caches available from public 
> API.
> So, I suggest adding a new method which would be called when we want to make 
> caches available for public API clients.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6527) Deadlock detection works incorrectly with timeouts that haven't caused by deadlocks.

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov updated IGNITE-6527:
-
Description: 
Deadlock detection works incorrectly with timeouts that haven't caused by 
deadlocks. In case of a deadlock in future. Or can detect another deadlock 
which was not the cause of timeout.

*requested keys:* keys primary for the same node and blocking in sequential 
order during the timeout (or all keys that haven't locked by an optimistic 
transaction in case of near cache).

*candidates:* keys candidates to be locked on a primary node (entries contains 
in  GridDhtTxLocal). 

In the process of updating the Wait-For-Graph requested keys used as 
candidates.  But "TxDeadlock.toString" method use candidates which were 
received from messages. 

1) It causes an incorrect error message.

Example: 
K1: TX1 holds lock, TX2 waits lock.
K2: TX3 holds lock, TX1 waits lock.

Transactions:

TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457]

Keys:

K1 [key=6, cache=cache]
K2 [key=1, cache=cache]

2) It can detect another deadlock which was not the cause of timeout but it 
would be the cause if the current deadlock did not happen.

These are very rare situations, but they can happen.

I see several solutions:
* Just make a correct message.
* log warn and continue detecting.




  was:
Deadlock detection works incorrectly with timeouts that haven't caused by 
deadlocks. In case of a deadlock in future. Or can detect another deadlock 
which was not the cause of timeout.

*requested keys:* keys primary for the same node and blocking in sequential 
order during the timeout (or all keys that haven't locked by an optimistic 
transaction in case of near cache).

*candidates:* keys candidates to be locked on a primary node (entries contains 
in  GridDhtTxLocal). 

In the process of updating the Wait-For-Graph requested keys used as 
candidates.  But "TxDeadlock.toString" method use candidates which were 
received from messages. 

1) It causes an incorrect error message.

Example: 
K1: TX1 holds lock, TX2 waits lock.
K2: TX3 holds lock, TX1 waits lock.

Transactions:

TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457]

Keys:

K1 [key=6, cache=cache]
K2 [key=1, cache=cache]




> Deadlock detection works incorrectly with timeouts that haven't caused by 
> deadlocks.
> 
>
> Key: IGNITE-6527
> URL: https://issues.apache.org/jira/browse/IGNITE-6527
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
> Attachments: TxOptimisticDeadlockDetectionIncorrectMessageTest.java
>
>
> Deadlock detection works incorrectly with timeouts that haven't caused by 
> deadlocks. In case of a deadlock in future. Or can detect another deadlock 
> which was not the cause of timeout.
> *requested keys:* keys primary for the same node and blocking in sequential 
> order during the timeout (or all keys that haven't locked by an optimistic 
> transaction in case of near cache).
> *candidates:* keys candidates to be locked on a primary node (entries 
> contains in  GridDhtTxLocal). 
> In the process of updating the Wait-For-Graph requested keys used as 
> candidates.  But "TxDeadlock.toString" method use candidates which were 
> received from messages. 
> 1) It causes an incorrect error message.
> Example: 
> K1: TX1 holds lock, TX2 waits lock.
> K2: TX3 holds lock, TX1 waits lock.
> Transactions:
> TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
> TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
> TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457]
> Keys:
> K1 [key=6, cache=cache]
> K2 [key=1, cache=cache]
> 2) It can detect another deadlock which was not the cause of timeout but it 
> would be the cause if the current deadlock 

[jira] [Updated] (IGNITE-6527) Deadlock detection works incorrectly with deadlocks that are not the cause of the timeout.

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov updated IGNITE-6527:
-
Description: 
*requested keys:* keys primary for the same node and blocking in sequential 
order during the timeout (or all keys that haven't locked by an optimistic 
transaction in case of near cache).

*candidates:* keys candidates to be locked on a primary node (entries contains 
in  GridDhtTxLocal). 

In the process of updating the Wait-For-Graph requested keys used as 
candidates.  But "TxDeadlock.toString" method use candidates which were 
received from messages. 

1) It causes an incorrect error message.

Example: 
K1: TX1 holds lock, TX2 waits lock.
K2: TX3 holds lock, TX1 waits lock.

Transactions:

TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457]

Keys:

K1 [key=6, cache=cache]
K2 [key=1, cache=cache]



  was:
*requested keys:* keys primary for the same node and blocking in sequential 
order during the timeout (or all keys that haven't locked by an optimistic 
transaction in case of near cache).

*candidates:* keys candidates to be locked on a primary node (entries contains 
in  GridDhtTxLocal). 

In the process of updating the Wait-For-Graph requested keys used as 
candidates.  But "TxDeadlock.toString" method use candidates which were 
received from messages. It causes an incorrect error message.

Example: 
K1: TX1 holds lock, TX2 waits lock.
K2: TX3 holds lock, TX1 waits lock.

Transactions:

TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457]

Keys:

K1 [key=6, cache=cache]
K2 [key=1, cache=cache]




> Deadlock detection works incorrectly with deadlocks that are not the cause of 
> the timeout.
> --
>
> Key: IGNITE-6527
> URL: https://issues.apache.org/jira/browse/IGNITE-6527
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>
> *requested keys:* keys primary for the same node and blocking in sequential 
> order during the timeout (or all keys that haven't locked by an optimistic 
> transaction in case of near cache).
> *candidates:* keys candidates to be locked on a primary node (entries 
> contains in  GridDhtTxLocal). 
> In the process of updating the Wait-For-Graph requested keys used as 
> candidates.  But "TxDeadlock.toString" method use candidates which were 
> received from messages. 
> 1) It causes an incorrect error message.
> Example: 
> K1: TX1 holds lock, TX2 waits lock.
> K2: TX3 holds lock, TX1 waits lock.
> Transactions:
> TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
> TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
> TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457]
> Keys:
> K1 [key=6, cache=cache]
> K2 [key=1, cache=cache]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6512) Need a possibility to start caches without discarding their 'restarting' state

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev reassigned IGNITE-6512:
-

Assignee: Eduard Shangareev

> Need a possibility to start caches without discarding their 'restarting' state
> --
>
> Key: IGNITE-6512
> URL: https://issues.apache.org/jira/browse/IGNITE-6512
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>
> Now we always discard restarting state on cache while it is starting.
> But sometimes we need extra steps before making caches available from public 
> API.
> So, I suggest adding a new method which would be called when we want to make 
> caches available for public API clients.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6507) Commit can be lost in network split scenario

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov updated IGNITE-6507:
--
Description: 
Commit can be lost in network split scenario

Reproducer:

https://github.com/ascherbakoff/ignite/blob/ignite-6507/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/distributed/dht/IgniteCacheTopologySplitTxConsistencyTest.java

If routing will be switched to second data center, new transactions will no see 
commited state.

  was:
Commit can be lost in network split scenario

{noformat}
/*
 * Licensed to the Apache Software Foundation (ASF) under one or more
 * contributor license agreements. See the NOTICE file distributed with
 * this work for additional information regarding copyright ownership.
 * The ASF licenses this file to You under the Apache License, Version 2.0
 * (the "License"); you may not use this file except in compliance with
 * the License. You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package org.apache.ignite.internal.processors.cache.distributed.dht;

import org.apache.ignite.IgniteCache;
import org.apache.ignite.cache.affinity.Affinity;
import org.apache.ignite.cache.affinity.rendezvous.RendezvousAffinityFunction;
import org.apache.ignite.configuration.BinaryConfiguration;
import org.apache.ignite.configuration.CacheConfiguration;
import org.apache.ignite.configuration.IgniteConfiguration;
import org.apache.ignite.configuration.MemoryConfiguration;
import org.apache.ignite.internal.IgniteEx;
import org.apache.ignite.internal.IgniteInternalFuture;
import org.apache.ignite.internal.TestRecordingCommunicationSpi;
import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
import org.apache.ignite.spi.discovery.tcp.ipfinder.TcpDiscoveryIpFinder;
import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
import org.apache.ignite.testframework.GridTestUtils;
import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;

import static org.apache.ignite.cache.CacheAtomicityMode.TRANSACTIONAL;
import static org.apache.ignite.cache.CacheWriteSynchronizationMode.FULL_SYNC;

/**
 * Tests commit consitency in split-brain scenario.
 */
public class GridCacheGridSplitTxConsistencyTest extends GridCommonAbstractTest 
{
/** */
private static final TcpDiscoveryIpFinder IP_FINDER = new 
TcpDiscoveryVmIpFinder(true);

/**
 * {@inheritDoc}
 */
@Override protected void afterTest() throws Exception {
super.afterTest();

stopAllGrids();

GridTestUtils.deleteDbFiles();
}

/**
 * {@inheritDoc}
 */
@Override protected IgniteConfiguration getConfiguration(String gridName) 
throws Exception {
IgniteConfiguration cfg = super.getConfiguration(gridName);

cfg.setCommunicationSpi(new TestRecordingCommunicationSpi());

cfg.setConsistentId(gridName);

MemoryConfiguration memCfg = new MemoryConfiguration();
memCfg.setPageSize(1024);
memCfg.setDefaultMemoryPolicySize(100 * 1024 * 1024);

cfg.setMemoryConfiguration(memCfg);

((TcpDiscoverySpi) cfg.getDiscoverySpi()).setIpFinder(IP_FINDER);

CacheConfiguration ccfg = new CacheConfiguration();
ccfg.setName(DEFAULT_CACHE_NAME);
ccfg.setAtomicityMode(TRANSACTIONAL);
ccfg.setWriteSynchronizationMode(FULL_SYNC);
ccfg.setAffinity(new RendezvousAffinityFunction(false, 3));
ccfg.setBackups(2);

cfg.setCacheConfiguration(ccfg);

return cfg;
}

/**
 * Tests if commits are working as expected.
 * @throws Exception
 */
public void testSplitTxConsistency() throws Exception {
IgniteEx grid0 = startGrid(0);
grid0.active(true);

IgniteEx grid1 = startGrid(1);
IgniteEx grid2 = startGrid(2);

int key = 0;

Affinity aff = grid0.affinity(DEFAULT_CACHE_NAME);
assertTrue(aff.isPrimary(grid0.localNode(), key));
assertTrue(aff.isBackup(grid1.localNode(), key));
assertTrue(aff.isBackup(grid2.localNode(), key));

final TestRecordingCommunicationSpi spi0 = 
(TestRecordingCommunicationSpi) grid0.configuration().getCommunicationSpi();

spi0.blockMessages(GridDhtTxFinishRequest.class, grid1.name());
spi0.blockMessages(GridDhtTxFinishRequest.class, grid2.name());

IgniteInternalFuture fut = multithreadedAsync(new Runnable() {
@Override public void run() {
try {
spi0.waitForBlocked();

[jira] [Commented] (IGNITE-5784) .NET: QueryIndex.InlineSize

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5784:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-5784 .NET: QueryIndex.InlineSize



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

$ git pull https://github.com/ptupitsyn/ignite ignite-5784

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

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

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

This closes #2771


commit 0a0966926882185d8bc3f1a127331d78cbd885f2
Author: Pavel Tupitsyn 
Date:   2017-09-28T12:24:27Z

IGNITE-5784 .NET: QueryIndex.InlineSize

commit 4e3ccc50fe982ec1087e8f4b768f86458bdbba78
Author: Pavel Tupitsyn 
Date:   2017-09-28T12:47:28Z

wip

commit 6c7bdcdfad5730ea4a1770372eb00c285522851d
Author: Pavel Tupitsyn 
Date:   2017-09-28T12:49:23Z

wip

commit 47e15e593d4c9618953c3bc6c2c4d07114769ec1
Author: Pavel Tupitsyn 
Date:   2017-09-28T12:51:06Z

Read-write properties

commit c080958789377b97e07ada313c5ee03bcc18a236
Author: Pavel Tupitsyn 
Date:   2017-09-28T12:52:25Z

fix propagation

commit 31e3982a24e941064c3373de1f958373ef1a00eb
Author: Pavel Tupitsyn 
Date:   2017-09-28T12:56:32Z

wip

commit 19cdb384debec83cf3937a141105eca31f918b2a
Author: Pavel Tupitsyn 
Date:   2017-09-28T13:30:56Z

read-write Java

commit aaf286d8179438262bad87dd4ffca10ce7344d49
Author: Pavel Tupitsyn 
Date:   2017-09-28T13:41:27Z

wip tests

commit f7c3130481cd4edbc35b85bf853d199b6ab82be4
Author: Pavel Tupitsyn 
Date:   2017-09-28T13:56:24Z

Fix attributes

commit e36b2fa4b27ae60f3a12c6fd026a621d38c0a7c5
Author: Pavel Tupitsyn 
Date:   2017-09-28T13:58:02Z

cleanup

commit 57c9a39fae4399fa1993cdce356b42882c0545f9
Author: Pavel Tupitsyn 
Date:   2017-09-28T14:56:55Z

wip tests

commit 99027190b57d4923c03d775a47dae3ec8cc28bec
Author: Pavel Tupitsyn 
Date:   2017-09-28T15:02:08Z

Extract predefined config to a file

commit 5eca207b1d9e8697eddfbffeae795f9da01a950e
Author: Pavel Tupitsyn 
Date:   2017-09-28T15:07:24Z

wip tests

commit d8f0e58d23f41df7dc0764c6a803b4705f07b4f1
Author: Pavel Tupitsyn 
Date:   2017-09-28T15:09:38Z

wip schema

commit 5a12ae1382ef0f31689be2f7c7872d8c81a4c7a1
Author: Pavel Tupitsyn 
Date:   2017-09-28T15:10:53Z

wip tests

commit 19c888f54704fd15b277dd45697dcec61ed81c76
Author: Pavel Tupitsyn 
Date:   2017-09-28T15:27:22Z

all done




> .NET: QueryIndex.InlineSize
> ---
>
> Key: IGNITE-5784
> URL: https://issues.apache.org/jira/browse/IGNITE-5784
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> {{QueryIndex.InlineSize}} controls index payload when it is stored in Ignite 
> page memory.
> Also add {{QuerySqlField.IndexInlineSize}} and 
> {{CacheConfiguration.SqlIndexMaxInlineSize}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6452) Invocation of getAll() through cache proxy during cache restart can throw unexpected CacheException

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev updated IGNITE-6452:
--
Description: 
Instead of expected IgniteCacheRestartingException, load test shows the 
following exception sometimes:
{noformat}
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: 
Failed to find message handler for message: GridNearGetRequest 
[futId=6fc73459e51-84b93e3c-47e1-433c-8a91-0700f131c617, 
miniId=27d73459e51-84b93e3c-47e1-433c-8a91-0700f131c617, ver=null, keyMap=null, 
flags=1, topVer=AffinityTopologyVersion [topVer=4, minorTopVer=32], 
subjId=080177d4-b78e-4f6f-a386-77be8830, taskNameHash=0, createTtl=-1, 
accessTtl=-1]

at 
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1285)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1648)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.getAll(IgniteCacheProxyImpl.java:873)
at 
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.getAll(GatewayProtectedCacheProxy.java:718)
at 
org.gridgain.grid.internal.processors.cache.database.IgniteDbSnapshotSelfTest$15.apply(IgniteDbSnapshotSelfTest.java:1911)
at 
org.gridgain.grid.internal.processors.cache.database.IgniteDbSnapshotSelfTest$15.apply(IgniteDbSnapshotSelfTest.java:1904)
at 
org.gridgain.grid.internal.processors.cache.database.IgniteDbSnapshotSelfTest.testReuseCacheProxyAfterRestore(IgniteDbSnapshotSelfTest.java:1796)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
at java.lang.Thread.run(Thread.java:745)
{noformat}


Also, there is an issue with the case when we start cache operation during the 
exchange which will start cache. 
{code}
Caused by: java.lang.IllegalStateException: Getting affinity for topology 
version earlier than affinity is calculated [locNode=TcpDiscoveryNode 
[id=21b13959-8579-47dd-86c8-b16ec850, addrs=[127.0.0.1], 
sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
lastExchangeTime=1506550922327, loc=true, ver=2.3.0#19700101-sha1:, 
isClient=false], grp=cache1, topVer=AffinityTopologyVersion [topVer=3, 
minorTopVer=3], head=AffinityTopologyVersion [topVer=3, minorTopVer=4], 
history=[AffinityTopologyVersion [topVer=3, minorTopVer=4]]]
at 
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:519)
at 
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.nodes(GridAffinityAssignmentCache.java:419)
at 
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.nodesByPartition(GridCacheAffinityManager.java:220)
at 
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByPartition(GridCacheAffinityManager.java:256)
at 
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:247)
at 
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:271)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.entryExx(GridDhtColocatedCache.java:156)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.entryEx(GridNearTxLocal.java:3699)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.enlistWriteEntry(GridNearTxLocal.java:1136)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.enlistWrite(GridNearTxLocal.java:855)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAsync0(GridNearTxLocal.java:533)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAsync(GridNearTxLocal.java:385)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter$22.op(GridCacheAdapter.java:2359)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter$22.op(GridCacheAdapter.java:2357)
at 

[jira] [Updated] (IGNITE-5652) Print slow query warnings on client node

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5652:

Labels: usability  (was: )

> Print slow query warnings on client node
> 
>
> Key: IGNITE-5652
> URL: https://issues.apache.org/jira/browse/IGNITE-5652
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
> Environment: Currently, only worker (MAP) nodes of the query print 
> long query execution time warning to their console, for usability it would be 
> nice to propagate this to the client node as well.
>Reporter: Alexander Paschenko
>  Labels: usability
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5699) Auto registration of keyFieldName and valueFieldName in queryFields

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5699:

Labels: usability  (was: )

> Auto registration of keyFieldName and valueFieldName in queryFields
> ---
>
> Key: IGNITE-5699
> URL: https://issues.apache.org/jira/browse/IGNITE-5699
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Vasiliy Sisko
>  Labels: usability
>
> Now in QueryEntity when keyFieldName and valueFieldName fields are configured 
> they should be described in fields map too. This action is misleading and 
> badly described in documentation. 
> We have all information to auto registration of that aliases in fields map. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6507) Commit can be lost in network split scenario

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov commented on IGNITE-6507:
---

Added split emulation in reproducer.

> Commit can be lost in network split scenario
> 
>
> Key: IGNITE-6507
> URL: https://issues.apache.org/jira/browse/IGNITE-6507
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.1
>Reporter: Alexei Scherbakov
>Priority: Critical
>  Labels: important
> Fix For: 2.4
>
>
> Commit can be lost in network split scenario
> Reproducer:
> https://github.com/ascherbakoff/ignite/blob/ignite-6507/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/distributed/dht/IgniteCacheTopologySplitTxConsistencyTest.java
> If routing will be switched to second data center, new transactions will no 
> see commited state.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6054) SQL: Add option to store primitive keys in plain form for CREATE TABLE

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-6054:
---

Assignee: Vladimir Ozerov

> SQL: Add option to store primitive keys in plain form for CREATE TABLE
> --
>
> Key: IGNITE-6054
> URL: https://issues.apache.org/jira/browse/IGNITE-6054
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.3
>
>
> Currently we create separate internal type for primary key columns. This is 
> necessary to avoid clashes between keys of the same type within the same 
> caches (ironically, we do not allow multiple dynamic tables per cache).
> The most widely used PK is single-column key of {{Long}} or {{String}} data 
> type. If we store a key plain {{long}}, it will consume 9 bytes. If we store 
> it as an object with long field, it will consume 24 + 9 = 33 bytes. What is 
> worse, in the latter case we will have to copy key object back and forth 
> between page memory and application code many times, while for plain long key 
> we simply do {{Unsafe.getLong}}.
> For this reason, it makes sense to introduce special mode for {{CREATE 
> TABLE}} command, when key will not be wrapped into a class, and will be 
> stored as is. Let's name it {{plainPrimaryKey}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6190) SQL query fails silently if Set is passed as a parameter

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6190:

Labels: usability  (was: )

> SQL query fails silently if Set is passed as a parameter
> 
>
> Key: IGNITE-6190
> URL: https://issues.apache.org/jira/browse/IGNITE-6190
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Denis Magda
>Assignee: Roman Shtykh
>  Labels: usability
> Attachments: TestIgniteQuery.zip
>
>
> Seems like the SqlQuery API does not like {{Set}} as the input parameter. 
> While this query doesn't work (the Set is used as an input):
> {code}
> public Map getAccountsForLe(Set leId) {
> SqlQuery query =
> new SqlQuery(Account.class, "from Account join 
> table(id varchar = ?) i on Account.clientLegalEntityId = i.id")
> .setArgs(leId);
> Map results = new HashMap<>();
> _cache.query(query).getAll().stream().forEach(e -> 
> results.put(e.getKey(), e.getValue()));
> return results;
> }
> {code}
> This one works well (the Set is converted to Array explicitly):
> {code}
> public Map getAccountsForLe(Set leId) {
> SqlQuery query =
> new SqlQuery(Account.class, "from Account join 
> table(id varchar = ?) i on Account.clientLegalEntityId = i.id")
> .setArgs(leId.toArray());
> Map results = new HashMap<>();
> _cache.query(query).getAll().stream().forEach(e -> 
> results.put(e.getKey(), e.getValue()));
> return results;
> }
> {code}
> The fact that it fails silently is an issue. IMHO there should be some 
> validation to alert the calling code that the type specified is not valid or 
> the set has to be transformed to the array on the fly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6527) Deadlock detection works incorrectly with timeouts that haven't caused by deadlocks.

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov updated IGNITE-6527:
-
Attachment: TxOptimisticDeadlockDetectionIncorrectMessageTest.java

> Deadlock detection works incorrectly with timeouts that haven't caused by 
> deadlocks.
> 
>
> Key: IGNITE-6527
> URL: https://issues.apache.org/jira/browse/IGNITE-6527
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
> Attachments: TxOptimisticDeadlockDetectionIncorrectMessageTest.java
>
>
> Deadlock detection works incorrectly with timeouts that haven't caused by 
> deadlocks. In case of a deadlock in future. Or can detect another deadlock 
> which was not the cause of timeout.
> *requested keys:* keys primary for the same node and blocking in sequential 
> order during the timeout (or all keys that haven't locked by an optimistic 
> transaction in case of near cache).
> *candidates:* keys candidates to be locked on a primary node (entries 
> contains in  GridDhtTxLocal). 
> In the process of updating the Wait-For-Graph requested keys used as 
> candidates.  But "TxDeadlock.toString" method use candidates which were 
> received from messages. 
> 1) It causes an incorrect error message.
> Example: 
> K1: TX1 holds lock, TX2 waits lock.
> K2: TX3 holds lock, TX1 waits lock.
> Transactions:
> TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
> TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
> TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457]
> Keys:
> K1 [key=6, cache=cache]
> K2 [key=1, cache=cache]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6054) SQL: Add option to store primitive keys in plain form for CREATE TABLE

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6054:

Fix Version/s: 2.3

> SQL: Add option to store primitive keys in plain form for CREATE TABLE
> --
>
> Key: IGNITE-6054
> URL: https://issues.apache.org/jira/browse/IGNITE-6054
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.3
>
>
> Currently we create separate internal type for primary key columns. This is 
> necessary to avoid clashes between keys of the same type within the same 
> caches (ironically, we do not allow multiple dynamic tables per cache).
> The most widely used PK is single-column key of {{Long}} or {{String}} data 
> type. If we store a key plain {{long}}, it will consume 9 bytes. If we store 
> it as an object with long field, it will consume 24 + 9 = 33 bytes. What is 
> worse, in the latter case we will have to copy key object back and forth 
> between page memory and application code many times, while for plain long key 
> we simply do {{Unsafe.getLong}}.
> For this reason, it makes sense to introduce special mode for {{CREATE 
> TABLE}} command, when key will not be wrapped into a class, and will be 
> stored as is. Let's name it {{plainPrimaryKey}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (IGNITE-5319) Fix schema handling in deprecated "thin" driver.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-5319.
---

> Fix schema handling in deprecated "thin" driver.
> 
>
> Key: IGNITE-5319
> URL: https://issues.apache.org/jira/browse/IGNITE-5319
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>
> Currently both drivers behave as follows: when schema is changed, it is 
> converted to cache name automatically. This is wrong. We should do the 
> following:
> 1) Decouple schema name from cache name. Schema name should be separate 
> field. No conversion.
> 2) When JDBC driver is connected, schema is set to the schema target cache 
> belongs to
> 3) Cache name cannot be changed
> 4) Cache name is always passed to all tasks as before
> 5) Schema name is added to these tasks and propagated to respective 
> {{SqlFieldsQuery}}. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6044) SQL insert waits for transaction commit, but it must be executed right away

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6044:

Labels: usability  (was: )

> SQL insert waits for transaction commit, but it must be executed right away
> ---
>
> Key: IGNITE-6044
> URL: https://issues.apache.org/jira/browse/IGNITE-6044
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Mikhail Cherkasov
>Assignee: Sergey Kalashnikov
>Priority: Critical
>  Labels: usability
> Fix For: 2.4
>
>
> Doc says:
> ""Presently, DML supports the atomic mode only meaning that if there is a DML 
> query that is executed as a part of an Ignite transaction then it will not be 
> enlisted in the transaction's writing queue and will be executed right away.""
> https://apacheignite.readme.io/docs/dml#section-transactional-support
> However the data will be added to cache only after transaction commit.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6054) SQL: Add option to store primitive keys in plain form for CREATE TABLE

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-6054:
---

Assignee: Alexander Paschenko  (was: Vladimir Ozerov)

> SQL: Add option to store primitive keys in plain form for CREATE TABLE
> --
>
> Key: IGNITE-6054
> URL: https://issues.apache.org/jira/browse/IGNITE-6054
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>  Labels: performance
> Fix For: 2.3
>
>
> Currently we create separate internal type for primary key columns. This is 
> necessary to avoid clashes between keys of the same type within the same 
> caches (ironically, we do not allow multiple dynamic tables per cache).
> The most widely used PK is single-column key of {{Long}} or {{String}} data 
> type. If we store a key plain {{long}}, it will consume 9 bytes. If we store 
> it as an object with long field, it will consume 24 + 9 = 33 bytes. What is 
> worse, in the latter case we will have to copy key object back and forth 
> between page memory and application code many times, while for plain long key 
> we simply do {{Unsafe.getLong}}.
> For this reason, it makes sense to introduce special mode for {{CREATE 
> TABLE}} command, when key will not be wrapped into a class, and will be 
> stored as is. Let's name it {{plainPrimaryKey}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5650) Add convenient API for getting column values

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5650:

Labels: usability  (was: )

> Add convenient API for getting column values
> 
>
> Key: IGNITE-5650
> URL: https://issues.apache.org/jira/browse/IGNITE-5650
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Alexander Paschenko
>  Labels: usability
>
> It's desirable to have some API for getting column values from query results 
> as current API operates only rows (raw Lists).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (IGNITE-5319) Fix schema handling in deprecated "thin" driver.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-5319.
-
Resolution: Won't Fix

Driver is deprecated, so no changes are needed.

> Fix schema handling in deprecated "thin" driver.
> 
>
> Key: IGNITE-5319
> URL: https://issues.apache.org/jira/browse/IGNITE-5319
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>
> Currently both drivers behave as follows: when schema is changed, it is 
> converted to cache name automatically. This is wrong. We should do the 
> following:
> 1) Decouple schema name from cache name. Schema name should be separate 
> field. No conversion.
> 2) When JDBC driver is connected, schema is set to the schema target cache 
> belongs to
> 3) Cache name cannot be changed
> 4) Cache name is always passed to all tasks as before
> 5) Schema name is added to these tasks and propagated to respective 
> {{SqlFieldsQuery}}. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6527) Deadlock detection works incorrectly with timeouts that haven't caused by deadlocks.

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov updated IGNITE-6527:
-
Description: 
Deadlock detection works incorrectly with timeouts that haven't caused by 
deadlocks. In case of deadlok 

*requested keys:* keys primary for the same node and blocking in sequential 
order during the timeout (or all keys that haven't locked by an optimistic 
transaction in case of near cache).

*candidates:* keys candidates to be locked on a primary node (entries contains 
in  GridDhtTxLocal). 

In the process of updating the Wait-For-Graph requested keys used as 
candidates.  But "TxDeadlock.toString" method use candidates which were 
received from messages. 

1) It causes an incorrect error message.

Example: 
K1: TX1 holds lock, TX2 waits lock.
K2: TX3 holds lock, TX1 waits lock.

Transactions:

TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457]

Keys:

K1 [key=6, cache=cache]
K2 [key=1, cache=cache]



  was:
*requested keys:* keys primary for the same node and blocking in sequential 
order during the timeout (or all keys that haven't locked by an optimistic 
transaction in case of near cache).

*candidates:* keys candidates to be locked on a primary node (entries contains 
in  GridDhtTxLocal). 

In the process of updating the Wait-For-Graph requested keys used as 
candidates.  But "TxDeadlock.toString" method use candidates which were 
received from messages. 

1) It causes an incorrect error message.

Example: 
K1: TX1 holds lock, TX2 waits lock.
K2: TX3 holds lock, TX1 waits lock.

Transactions:

TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457]

Keys:

K1 [key=6, cache=cache]
K2 [key=1, cache=cache]




> Deadlock detection works incorrectly with timeouts that haven't caused by 
> deadlocks.
> 
>
> Key: IGNITE-6527
> URL: https://issues.apache.org/jira/browse/IGNITE-6527
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>
> Deadlock detection works incorrectly with timeouts that haven't caused by 
> deadlocks. In case of deadlok 
> *requested keys:* keys primary for the same node and blocking in sequential 
> order during the timeout (or all keys that haven't locked by an optimistic 
> transaction in case of near cache).
> *candidates:* keys candidates to be locked on a primary node (entries 
> contains in  GridDhtTxLocal). 
> In the process of updating the Wait-For-Graph requested keys used as 
> candidates.  But "TxDeadlock.toString" method use candidates which were 
> received from messages. 
> 1) It causes an incorrect error message.
> Example: 
> K1: TX1 holds lock, TX2 waits lock.
> K2: TX3 holds lock, TX1 waits lock.
> Transactions:
> TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
> TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
> TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457]
> Keys:
> K1 [key=6, cache=cache]
> K2 [key=1, cache=cache]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6527) Deadlock detection works incorrectly with timeouts that haven't caused by deadlocks.

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov updated IGNITE-6527:
-
Description: 
Deadlock detection works incorrectly with timeouts that haven't caused by 
deadlocks. In case of a deadlock in future. Or can detect another deadlock 
which was not the cause of timeout.

*requested keys:* keys primary for the same node and blocking in sequential 
order during the timeout (or all keys that haven't locked by an optimistic 
transaction in case of near cache).

*candidates:* keys candidates to be locked on a primary node (entries contains 
in  GridDhtTxLocal). 

In the process of updating the Wait-For-Graph requested keys used as 
candidates.  But "TxDeadlock.toString" method use candidates which were 
received from messages. 

1) It causes an incorrect error message.

Example: 
K1: TX1 holds lock, TX2 waits lock.
K2: TX3 holds lock, TX1 waits lock.

Transactions:

TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457]

Keys:

K1 [key=6, cache=cache]
K2 [key=1, cache=cache]



  was:
Deadlock detection works incorrectly with timeouts that haven't caused by 
deadlocks. In case of a deadlock in future.

*requested keys:* keys primary for the same node and blocking in sequential 
order during the timeout (or all keys that haven't locked by an optimistic 
transaction in case of near cache).

*candidates:* keys candidates to be locked on a primary node (entries contains 
in  GridDhtTxLocal). 

In the process of updating the Wait-For-Graph requested keys used as 
candidates.  But "TxDeadlock.toString" method use candidates which were 
received from messages. 

1) It causes an incorrect error message.

Example: 
K1: TX1 holds lock, TX2 waits lock.
K2: TX3 holds lock, TX1 waits lock.

Transactions:

TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457]

Keys:

K1 [key=6, cache=cache]
K2 [key=1, cache=cache]




> Deadlock detection works incorrectly with timeouts that haven't caused by 
> deadlocks.
> 
>
> Key: IGNITE-6527
> URL: https://issues.apache.org/jira/browse/IGNITE-6527
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>
> Deadlock detection works incorrectly with timeouts that haven't caused by 
> deadlocks. In case of a deadlock in future. Or can detect another deadlock 
> which was not the cause of timeout.
> *requested keys:* keys primary for the same node and blocking in sequential 
> order during the timeout (or all keys that haven't locked by an optimistic 
> transaction in case of near cache).
> *candidates:* keys candidates to be locked on a primary node (entries 
> contains in  GridDhtTxLocal). 
> In the process of updating the Wait-For-Graph requested keys used as 
> candidates.  But "TxDeadlock.toString" method use candidates which were 
> received from messages. 
> 1) It causes an incorrect error message.
> Example: 
> K1: TX1 holds lock, TX2 waits lock.
> K2: TX3 holds lock, TX1 waits lock.
> Transactions:
> TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
> TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
> TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457]
> Keys:
> K1 [key=6, cache=cache]
> K2 [key=1, cache=cache]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-4701) New SQL API

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4701:

Labels: important usability  (was: important)

> New SQL API 
> 
>
> Key: IGNITE-4701
> URL: https://issues.apache.org/jira/browse/IGNITE-4701
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: important, usability
>
> Ticket is created as a result of the following discussion: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Rethink-native-SQL-API-in-Apache-Ignite-2-0-td14335.html
> We need new SQL API which will be able to handle new SQL features such as 
> DML, DDL, batching, streaming, in a clean and consistent way. Old {{Query}} 
> API is not suitable for this.
> Example of a usability issue the API can help to solve: 
> http://apache-ignite-developers.2346864.n4.nabble.com/CREATE-TABLE-usage-from-Java-API-NET-C-td21455.html
> Final API design still to be proposed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6148) JDBC thin: improve error handling, support categorized SQLExceptions

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6148:

Labels: usability  (was: )

> JDBC thin: improve error handling, support categorized SQLExceptions
> 
>
> Key: IGNITE-6148
> URL: https://issues.apache.org/jira/browse/IGNITE-6148
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>  Labels: usability
>
> Current implementation of the JDBC thin driver throws pure SQLException with 
> string message only. Appropriate subclasses of SQLException must be thrown in 
> special cases.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6527) Deadlock detection works incorrectly with timeouts that haven't caused by deadlocks.

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov updated IGNITE-6527:
-
Description: 
Deadlock detection works incorrectly with timeouts that haven't caused by 
deadlocks. In case of a deadlock in future.

*requested keys:* keys primary for the same node and blocking in sequential 
order during the timeout (or all keys that haven't locked by an optimistic 
transaction in case of near cache).

*candidates:* keys candidates to be locked on a primary node (entries contains 
in  GridDhtTxLocal). 

In the process of updating the Wait-For-Graph requested keys used as 
candidates.  But "TxDeadlock.toString" method use candidates which were 
received from messages. 

1) It causes an incorrect error message.

Example: 
K1: TX1 holds lock, TX2 waits lock.
K2: TX3 holds lock, TX1 waits lock.

Transactions:

TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457]

Keys:

K1 [key=6, cache=cache]
K2 [key=1, cache=cache]



  was:
Deadlock detection works incorrectly with timeouts that haven't caused by 
deadlocks. In case of deadlok 

*requested keys:* keys primary for the same node and blocking in sequential 
order during the timeout (or all keys that haven't locked by an optimistic 
transaction in case of near cache).

*candidates:* keys candidates to be locked on a primary node (entries contains 
in  GridDhtTxLocal). 

In the process of updating the Wait-For-Graph requested keys used as 
candidates.  But "TxDeadlock.toString" method use candidates which were 
received from messages. 

1) It causes an incorrect error message.

Example: 
K1: TX1 holds lock, TX2 waits lock.
K2: TX3 holds lock, TX1 waits lock.

Transactions:

TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457]

Keys:

K1 [key=6, cache=cache]
K2 [key=1, cache=cache]




> Deadlock detection works incorrectly with timeouts that haven't caused by 
> deadlocks.
> 
>
> Key: IGNITE-6527
> URL: https://issues.apache.org/jira/browse/IGNITE-6527
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>
> Deadlock detection works incorrectly with timeouts that haven't caused by 
> deadlocks. In case of a deadlock in future.
> *requested keys:* keys primary for the same node and blocking in sequential 
> order during the timeout (or all keys that haven't locked by an optimistic 
> transaction in case of near cache).
> *candidates:* keys candidates to be locked on a primary node (entries 
> contains in  GridDhtTxLocal). 
> In the process of updating the Wait-For-Graph requested keys used as 
> candidates.  But "TxDeadlock.toString" method use candidates which were 
> received from messages. 
> 1) It causes an incorrect error message.
> Example: 
> K1: TX1 holds lock, TX2 waits lock.
> K2: TX3 holds lock, TX1 waits lock.
> Transactions:
> TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
> TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
> TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457]
> Keys:
> K1 [key=6, cache=cache]
> K2 [key=1, cache=cache]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6527) Deadlock detection works incorrectly with timeouts that haven't caused by deadlocks.

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov updated IGNITE-6527:
-
Summary: Deadlock detection works incorrectly with timeouts that haven't 
caused by deadlocks.  (was: Deadlock detection works incorrectly with deadlocks 
that are not the cause of the timeout.)

> Deadlock detection works incorrectly with timeouts that haven't caused by 
> deadlocks.
> 
>
> Key: IGNITE-6527
> URL: https://issues.apache.org/jira/browse/IGNITE-6527
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>
> *requested keys:* keys primary for the same node and blocking in sequential 
> order during the timeout (or all keys that haven't locked by an optimistic 
> transaction in case of near cache).
> *candidates:* keys candidates to be locked on a primary node (entries 
> contains in  GridDhtTxLocal). 
> In the process of updating the Wait-For-Graph requested keys used as 
> candidates.  But "TxDeadlock.toString" method use candidates which were 
> received from messages. 
> 1) It causes an incorrect error message.
> Example: 
> K1: TX1 holds lock, TX2 waits lock.
> K2: TX3 holds lock, TX1 waits lock.
> Transactions:
> TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
> TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
> TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457]
> Keys:
> K1 [key=6, cache=cache]
> K2 [key=1, cache=cache]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6527) Deadlock detection works incorrectly with deadlocks that are not the cause of the timeout.

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov updated IGNITE-6527:
-
Description: 
*requested keys:* keys primary for the same node and blocking in sequential 
order during the timeout (or all keys that haven't locked by an optimistic 
transaction in case of near cache).

*candidates:* keys candidates to be locked on a primary node (entries contains 
in  GridDhtTxLocal). 

In the process of updating the Wait-For-Graph requested keys used as 
candidates.  But "TxDeadlock.toString" method use candidates which were 
received from messages. It causes an incorrect error message.

Example: 
K1: TX1 holds lock, TX2 waits lock.
K2: TX3 holds lock, TX1 waits lock.

Transactions:

TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457]

Keys:

K1 [key=6, cache=cache]
K2 [key=1, cache=cache]



  was:
*requested keys:* keys primary for the same node and blocking in sequential 
order during the timeout (or all keys that haven't locked by an optimistic 
transaction in case of near cache).

*candidates: * keys candidates to be locked on a primary node (entries contains 
in  GridDhtTxLocal). 

In the process of updating the Wait-For-Graph requested keys used as 
candidates.  But "TxDeadlock.toString" method use candidates which were 
received from messages. It causes an incorrect error message.

Example: 
K1: TX1 holds lock, TX2 waits lock.
K2: TX3 holds lock, TX1 waits lock.

Transactions:

TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457]

Keys:

K1 [key=6, cache=cache]
K2 [key=1, cache=cache]




> Deadlock detection works incorrectly with deadlocks that are not the cause of 
> the timeout.
> --
>
> Key: IGNITE-6527
> URL: https://issues.apache.org/jira/browse/IGNITE-6527
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>
> *requested keys:* keys primary for the same node and blocking in sequential 
> order during the timeout (or all keys that haven't locked by an optimistic 
> transaction in case of near cache).
> *candidates:* keys candidates to be locked on a primary node (entries 
> contains in  GridDhtTxLocal). 
> In the process of updating the Wait-For-Graph requested keys used as 
> candidates.  But "TxDeadlock.toString" method use candidates which were 
> received from messages. It causes an incorrect error message.
> Example: 
> K1: TX1 holds lock, TX2 waits lock.
> K2: TX3 holds lock, TX1 waits lock.
> Transactions:
> TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
> TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
> TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457]
> Keys:
> K1 [key=6, cache=cache]
> K2 [key=1, cache=cache]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5571) Make sure that cache-less execution works as good as cache-based

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5571:

Fix Version/s: (was: 2ю4)
   2.4

> Make sure that cache-less execution works as good as cache-based
> 
>
> Key: IGNITE-5571
> URL: https://issues.apache.org/jira/browse/IGNITE-5571
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Critical
> Fix For: 2.4
>
>
> Compare the following two methods:
> 1) {{GridQueryProcessor.querySqlFields}} - old good entry point for query 
> execution;
> 2) {{GridQueryProcessor.querySqlFieldsNoCache}} - new method for "cache-less" 
> execution.
> Note how cache context is used in the first method:
> 1) First, it helps determine whether query can be converted to "local"
> 2) Second, it gets query parallelism of current cache, and if it differs from 
> {{1}}, then it turns on {{distributedJoins}}.
> Neither of this happens in the second implementation. Moreover, I had to 
> throw an exception for local queries, as I didn't know how to handle them 
> properly.
> We need to investigate and fix these two deficiencies somehow. Probably some 
> inputs from [~sergi.vladykin] would be required, to understand what is going 
> on.
> Our ultimate goal is to make "cache-less" execution as good as the old one.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6527) Deadlock detection works incorrectly with deadlocks that are not the cause of the timeout.

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov updated IGNITE-6527:
-
Description: 
*requested keys:* keys primary for the same node and blocking in sequential 
order during the timeout (or all keys that haven't locked by an optimistic 
transaction in case of near cache).

*candidates: * keys candidates to be locked on a primary node (entries contains 
in  GridDhtTxLocal). 

In the process of updating the Wait-For-Graph requested keys used as 
candidates.  But "TxDeadlock.toString" method use candidates which were 
received from messages. It causes an incorrect error message.

Example: 
K1: TX1 holds lock, TX2 waits lock.
K2: TX3 holds lock, TX1 waits lock.

Transactions:

TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457]

Keys:

K1 [key=6, cache=cache]
K2 [key=1, cache=cache]



> Deadlock detection works incorrectly with deadlocks that are not the cause of 
> the timeout.
> --
>
> Key: IGNITE-6527
> URL: https://issues.apache.org/jira/browse/IGNITE-6527
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>
> *requested keys:* keys primary for the same node and blocking in sequential 
> order during the timeout (or all keys that haven't locked by an optimistic 
> transaction in case of near cache).
> *candidates: * keys candidates to be locked on a primary node (entries 
> contains in  GridDhtTxLocal). 
> In the process of updating the Wait-For-Graph requested keys used as 
> candidates.  But "TxDeadlock.toString" method use candidates which were 
> received from messages. It causes an incorrect error message.
> Example: 
> K1: TX1 holds lock, TX2 waits lock.
> K2: TX3 holds lock, TX1 waits lock.
> Transactions:
> TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
> TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
> TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457]
> Keys:
> K1 [key=6, cache=cache]
> K2 [key=1, cache=cache]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5571) Make sure that cache-less execution works as good as cache-based

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5571:

Fix Version/s: (was: 2.3)
   2ю4

> Make sure that cache-less execution works as good as cache-based
> 
>
> Key: IGNITE-5571
> URL: https://issues.apache.org/jira/browse/IGNITE-5571
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Critical
> Fix For: 2.4
>
>
> Compare the following two methods:
> 1) {{GridQueryProcessor.querySqlFields}} - old good entry point for query 
> execution;
> 2) {{GridQueryProcessor.querySqlFieldsNoCache}} - new method for "cache-less" 
> execution.
> Note how cache context is used in the first method:
> 1) First, it helps determine whether query can be converted to "local"
> 2) Second, it gets query parallelism of current cache, and if it differs from 
> {{1}}, then it turns on {{distributedJoins}}.
> Neither of this happens in the second implementation. Moreover, I had to 
> throw an exception for local queries, as I didn't know how to handle them 
> properly.
> We need to investigate and fix these two deficiencies somehow. Probably some 
> inputs from [~sergi.vladykin] would be required, to understand what is going 
> on.
> Our ultimate goal is to make "cache-less" execution as good as the old one.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii edited comment on IGNITE-602 at 9/28/17 3:02 PM:


Ok, I'll think about test changes on weekend. But I think we don't need 
anything like ByteBuffer in return of toString() method. Even 
GridNioServer.ByteBufferNioClientWorker, which I annotated, doesn't have this 
buffer in it's own toString Implementation. May be add ByteBuffer or Buffer as 
exception in GridToStringBuilder (like arrays)? But I'd prefer to place 
annotation.


was (Author: somefire):
Ok, I'll think about test changes.

> [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by 
> infinite recursion
> 
>
> Key: IGNITE-602
> URL: https://issues.apache.org/jira/browse/IGNITE-602
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Artem Shutak
>Assignee: Ryabov Dmitrii
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.4
>
>
> See test 
> org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention
>  and related TODO in same source file.
> Also take a look at 
> http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring
> Test should be unmuted on TC after fix.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6513) Add ability manage version of WAL serializer via system properties

[Dmitriy Govorukhin (JIRA)]

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

Dmitriy Govorukhin updated IGNITE-6513:
---
Component/s: persistence

> Add ability manage version of WAL serializer via system properties
> --
>
> Key: IGNITE-6513
> URL: https://issues.apache.org/jira/browse/IGNITE-6513
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.0, 2.1, 2.2, 2.3
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
> Fix For: 2.4
>
>
> An example: -DIGNITE_WAL_SERIALIZER_VERSION=2



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6527) Deadlock detection works incorrectly with deadlocks that are not the cause of the timeout.

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-6527:
-

Hi, [~VitaliyB].

I don't understand how timeout can cause deadlocks. At present deadlock 
detection triggers only by transaction timeout and tries detect only deadlock 
which involves current transaction.
Could you please describe problem in more details?

> Deadlock detection works incorrectly with deadlocks that are not the cause of 
> the timeout.
> --
>
> Key: IGNITE-6527
> URL: https://issues.apache.org/jira/browse/IGNITE-6527
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6527) Deadlock detection works incorrect with deadlocks that are not the cause of the timeout.

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov updated IGNITE-6527:
-
Summary: Deadlock detection works incorrect with deadlocks that are not the 
cause of the timeout.  (was: Deadlock detection work incorrect with deadlocks 
that are not the cause of the timeout.)

> Deadlock detection works incorrect with deadlocks that are not the cause of 
> the timeout.
> 
>
> Key: IGNITE-6527
> URL: https://issues.apache.org/jira/browse/IGNITE-6527
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6527) Deadlock detection work incorrect with deadlocks that are not the cause of the timeout.

[Vitaliy Biryukov (JIRA)]

Vitaliy Biryukov created IGNITE-6527:


 Summary: Deadlock detection work incorrect with deadlocks that are 
not the cause of the timeout.
 Key: IGNITE-6527
 URL: https://issues.apache.org/jira/browse/IGNITE-6527
 Project: Ignite
  Issue Type: Bug
Reporter: Vitaliy Biryukov
Assignee: Vitaliy Biryukov






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii commented on IGNITE-602:
---

Ok, I'll think about test changes.

> [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by 
> infinite recursion
> 
>
> Key: IGNITE-602
> URL: https://issues.apache.org/jira/browse/IGNITE-602
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Artem Shutak
>Assignee: Ryabov Dmitrii
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.4
>
>
> See test 
> org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention
>  and related TODO in same source file.
> Also take a look at 
> http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring
> Test should be unmuted on TC after fix.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6527) Deadlock detection works incorrectly with deadlocks that are not the cause of the timeout.

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov updated IGNITE-6527:
-
Summary: Deadlock detection works incorrectly with deadlocks that are not 
the cause of the timeout.  (was: Deadlock detection works incorrect with 
deadlocks that are not the cause of the timeout.)

> Deadlock detection works incorrectly with deadlocks that are not the cause of 
> the timeout.
> --
>
> Key: IGNITE-6527
> URL: https://issues.apache.org/jira/browse/IGNITE-6527
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6526) Ignite 2.x capacity planning guide

[Denis Magda (JIRA)]

Denis Magda created IGNITE-6526:
---

 Summary: Ignite 2.x capacity planning guide
 Key: IGNITE-6526
 URL: https://issues.apache.org/jira/browse/IGNITE-6526
 Project: Ignite
  Issue Type: Task
Reporter: Denis Magda


Current capacity planning guide [1] is too high level and should be elaborated 
considering durable memory's internals:
- memory pages overhead.
- per-entry overhead 
(http://apache-ignite-users.70518.x6.nabble.com/Re-Memory-Overhead-per-entry-in-Apache-Ignite-td9498.html).
- space occupied for indexing needs.
- free lists
- etc.

The page has to include estimates for the Ignite Native Persistence:
- entry size and its overheads.
- index size and overheads.
- data files overheads.
- estimated WAL size and how to shrink it basing on checkpointing settings.


[1] https://apacheignite.readme.io/docs/capacity-planning



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6525) .NET: BinaryObject.Deserialize to custom type

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-6525:
--

 Summary: .NET: BinaryObject.Deserialize to custom type
 Key: IGNITE-6525
 URL: https://issues.apache.org/jira/browse/IGNITE-6525
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn


Current {{BinaryObject.Deserialize()}}  method takes a generic argument, but 
only uses it to cast the final result. Actual type is determined according to 
{{typeId}}.

Add {{forceType}} argument to override {{typeId}} logic and use the provided 
type instead.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6469) SQL: NOT NULL fields validation for values provided by cache interceptor

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6469:

Issue Type: Task  (was: Bug)

> SQL: NOT NULL fields validation for values provided by cache interceptor
> 
>
> Key: IGNITE-6469
> URL: https://issues.apache.org/jira/browse/IGNITE-6469
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Sergey Kalashnikov
>Assignee: Sergey Kalashnikov
> Fix For: 2.3
>
>
> In case {{CacheInterceptor}} is configured, the method 
> {{CacheInterceptor.onBeforePut}} may produce the value that violates the NOT 
> NULL constraint configured by the cache's QueryEntity.
> The value returned by {{onBeforePut}} must also be validated with regards to 
> configured NOT NULL constraints.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6351) SQL: Forbid NOT NULL constraints usage for a cache with configured conflict resolver

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6351:

Issue Type: Task  (was: Bug)

> SQL: Forbid NOT NULL constraints usage for a cache with configured conflict 
> resolver
> 
>
> Key: IGNITE-6351
> URL: https://issues.apache.org/jira/browse/IGNITE-6351
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Sergey Kalashnikov
>Assignee: Sergey Kalashnikov
> Fix For: 2.3
>
>
> We need to throw an exception when user attempts to create or alter a table 
> with a field declared as NOT NULL in a case the conflict resolver is enabled 
> for the cache.
> These features seem to not fit together quite well, so we skip the support at 
> the moment and the check will keep things consistent.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6387) SQL: NOT NULL fields validation with read-through cache store

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6387:

Issue Type: Task  (was: Bug)

> SQL: NOT NULL fields validation with read-through cache store
> -
>
> Key: IGNITE-6387
> URL: https://issues.apache.org/jira/browse/IGNITE-6387
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Sergey Kalashnikov
>Assignee: Sergey Kalashnikov
> Fix For: 2.3
>
>
> There is a case left unsolved during implementation of SQL NOT NULL 
> constraints feature.
> It may happen so that cache update operation fails and the value loaded from 
> store is put into cache.
> This value must also be validated with regards to configured NOT NULL 
> constraints.
> See {{CacheConfiguration.setCacheStoreFactory()}}, 
> {{CacheConfiguration.setReadThrough()}}, {{QueryEntity.setNotNullFields()}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (IGNITE-6350) SQL: Forbid NOT NULL constraints usage for a cache with configured read-through cache store

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-6350.
---

> SQL: Forbid NOT NULL constraints usage for a cache with configured 
> read-through cache store
> ---
>
> Key: IGNITE-6350
> URL: https://issues.apache.org/jira/browse/IGNITE-6350
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Sergey Kalashnikov
>Assignee: Sergey Kalashnikov
> Fix For: 2.3
>
>
> We need to throw an exception when user attempts to create or alter a table 
> with a field declared as NOT NULL in a case the corresponding cache 
> configuration employs read-through cache store 
> {{CacheConfiguration.setReadThrough()}}.
> These features seem to not fit together quite well, so we skip the support at 
> the moment and the check will keep things consistent.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (IGNITE-6349) SQL: Forbid NOT NULL constraints usage for a cache with configured interceptor

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-6349.
---

> SQL: Forbid NOT NULL constraints usage for a cache with configured interceptor
> --
>
> Key: IGNITE-6349
> URL: https://issues.apache.org/jira/browse/IGNITE-6349
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Sergey Kalashnikov
>Assignee: Sergey Kalashnikov
>
> We need to throw an exception when user attempts to create or alter a table 
> with a field declared as NOT NULL in a case the corresponding cache 
> configuration employs cache interceptor 
> {{CacheConfiguration.setInterceptor()}}.
> These features seem to not fit together quite well, so we skip the support at 
> the moment and the check will keep things consistent.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6349) SQL: Forbid NOT NULL constraints usage for a cache with configured interceptor

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6349:

Fix Version/s: (was: 2.3)

> SQL: Forbid NOT NULL constraints usage for a cache with configured interceptor
> --
>
> Key: IGNITE-6349
> URL: https://issues.apache.org/jira/browse/IGNITE-6349
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Sergey Kalashnikov
>Assignee: Sergey Kalashnikov
>
> We need to throw an exception when user attempts to create or alter a table 
> with a field declared as NOT NULL in a case the corresponding cache 
> configuration employs cache interceptor 
> {{CacheConfiguration.setInterceptor()}}.
> These features seem to not fit together quite well, so we skip the support at 
> the moment and the check will keep things consistent.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-602:


I agree with fixes for particular test but I'm against change of 
{{GridNioServer}} class.

> [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by 
> infinite recursion
> 
>
> Key: IGNITE-602
> URL: https://issues.apache.org/jira/browse/IGNITE-602
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Artem Shutak
>Assignee: Ryabov Dmitrii
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.3
>
>
> See test 
> org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention
>  and related TODO in same source file.
> Also take a look at 
> http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring
> Test should be unmuted on TC after fix.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6502) Need to output warning if -Djava.net.preferIPv4Stack=true is not set

[Yakov Zhdanov (JIRA)]

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

Yakov Zhdanov updated IGNITE-6502:
--
Description: 
Some issues were reported on dev/user list that may be caused by ipv6 usage. I 
am not sure if Ignite can properly work with ipv6 networks. This needs to be 
tested and another issue has been filed - 
https://issues.apache.org/jira/browse/IGNITE-6503.

For now it seems to be pretty handy just to have warning on node start:

{noformat}
Please set system property '-Djava.net.preferIPv4Stack=true' to avoid possible 
problems in mixed environments.
{noformat}


  was:
Some issues were reported on dev/user list that may be caused by ipv6 usage. I 
am not sure if Ignite can properly work with ipv6 networks. This needs to be 
tested and another issue has been filed - .

For now it seems to be pretty handy just to have warning on node start:

{noformat}
Please set system property '-Djava.net.preferIPv4Stack=true' to avoid possible 
problems in mixed environments.
{noformat}



> Need to output warning if -Djava.net.preferIPv4Stack=true is not set
> 
>
> Key: IGNITE-6502
> URL: https://issues.apache.org/jira/browse/IGNITE-6502
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: vk
>  Labels: usability
> Fix For: 2.3
>
>
> Some issues were reported on dev/user list that may be caused by ipv6 usage. 
> I am not sure if Ignite can properly work with ipv6 networks. This needs to 
> be tested and another issue has been filed - 
> https://issues.apache.org/jira/browse/IGNITE-6503.
> For now it seems to be pretty handy just to have warning on node start:
> {noformat}
> Please set system property '-Djava.net.preferIPv4Stack=true' to avoid 
> possible problems in mixed environments.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6524) .NET: Explicit dynamic type registration

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-6524:
--

 Summary: .NET: Explicit dynamic type registration
 Key: IGNITE-6524
 URL: https://issues.apache.org/jira/browse/IGNITE-6524
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn


Introduce {{IBinary.RegisterType(Type type)}} (similar to existing 
{{RegisterEnum}}) to allow explicit type registration in cluster.

This may be useful when we already have binary objects in cluster and want to 
start working with them in deserialized form for the first time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6502) Need to output warning if -Djava.net.preferIPv4Stack=true is not set

[Yakov Zhdanov (JIRA)]

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

Yakov Zhdanov updated IGNITE-6502:
--
Description: 
Some issues were reported on dev/user list that may be caused by ipv6 usage. I 
am not sure if Ignite can properly work with ipv6 networks. This needs to be 
tested and another issue has been filed - .

For now it seems to be pretty handy just to have warning on node start:

{noformat}
Please set system property '-Djava.net.preferIPv4Stack=true' to avoid possible 
problems in mixed environments.
{noformat}


  was:
Some issues were reported on dev/user list that may be caused by ipv6 usage. I 
am not sure if Ignite can properly work with ipv6 networks. This needs to be 
tested.

For now it seems to be pretty handy just to have warning on node start:

{noformat}
Please set system property '-Djava.net.preferIPv4Stack=true' to avoid possible 
problems in mixed environments.
{noformat}



> Need to output warning if -Djava.net.preferIPv4Stack=true is not set
> 
>
> Key: IGNITE-6502
> URL: https://issues.apache.org/jira/browse/IGNITE-6502
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: vk
>  Labels: usability
> Fix For: 2.3
>
>
> Some issues were reported on dev/user list that may be caused by ipv6 usage. 
> I am not sure if Ignite can properly work with ipv6 networks. This needs to 
> be tested and another issue has been filed - .
> For now it seems to be pretty handy just to have warning on node start:
> {noformat}
> Please set system property '-Djava.net.preferIPv4Stack=true' to avoid 
> possible problems in mixed environments.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6523) .NET: QueryField.NotNull

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-6523:
--

 Summary: .NET: QueryField.NotNull
 Key: IGNITE-6523
 URL: https://issues.apache.org/jira/browse/IGNITE-6523
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 2.3
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.3


Add {{QueryEntity.NotNull}} property to reflect changes in Java: IGNITE-6509



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6502) Need to output warning if -Djava.net.preferIPv4Stack=true is not set

[Yakov Zhdanov (JIRA)]

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

Yakov Zhdanov updated IGNITE-6502:
--
Description: 
Some issues were reported on dev/user list that may be caused by ipv6 usage. I 
am not sure if Ignite can properly work with ipv6 networks. This needs to be 
tested.

For now it seems to be pretty handy just to have warning on node start:

{noformat}
Please set system property '-Djava.net.preferIPv4Stack=true' to avoid possible 
problems in mixed environments.
{noformat}


  was:
Some issues were reported on dev/user list that may be caused by ipv6 usage. I 
am not sure if Ignite can properly work with ipv6 networks. This needs to be 
tested.

For now it seems to be pretty handy just to have warning on node start:

{{noformat}}
Please set system property '-Djava.net.preferIPv4Stack=true' to avoid possible 
problems in mixed environments.
{{noformat}}


> Need to output warning if -Djava.net.preferIPv4Stack=true is not set
> 
>
> Key: IGNITE-6502
> URL: https://issues.apache.org/jira/browse/IGNITE-6502
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: vk
>  Labels: usability
> Fix For: 2.3
>
>
> Some issues were reported on dev/user list that may be caused by ipv6 usage. 
> I am not sure if Ignite can properly work with ipv6 networks. This needs to 
> be tested.
> For now it seems to be pretty handy just to have warning on node start:
> {noformat}
> Please set system property '-Djava.net.preferIPv4Stack=true' to avoid 
> possible problems in mixed environments.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6509) SQL: Add NOT NULL support to QueryEntity API

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6509:

Component/s: sql

> SQL: Add NOT NULL support to QueryEntity API
> 
>
> Key: IGNITE-6509
> URL: https://issues.apache.org/jira/browse/IGNITE-6509
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: important
> Fix For: 2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6509) SQL: Add NOT NULL support to QueryEntity API

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6509:


Github user devozerov closed the pull request at:

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


> SQL: Add NOT NULL support to QueryEntity API
> 
>
> Key: IGNITE-6509
> URL: https://issues.apache.org/jira/browse/IGNITE-6509
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: important
> Fix For: 2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii commented on IGNITE-602:
---

Tests fails because they are broken by overflowed StringBuilder. I see 2 ways - 
decrease logs by annotation, and I made this change. Second way is to change 
whole tests, change their algorithm. I'm not sure it is good idea.

> [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by 
> infinite recursion
> 
>
> Key: IGNITE-602
> URL: https://issues.apache.org/jira/browse/IGNITE-602
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Artem Shutak
>Assignee: Ryabov Dmitrii
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.3
>
>
> See test 
> org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention
>  and related TODO in same source file.
> Also take a look at 
> http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring
> Test should be unmuted on TC after fix.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6437) DataStructure can not be obtained on client if it is created on server node.

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny reassigned IGNITE-6437:
--

Assignee: Stanilovsky Evgeny

> DataStructure can not be obtained on client if it is created on server node.
> 
>
> Key: IGNITE-6437
> URL: https://issues.apache.org/jira/browse/IGNITE-6437
> Project: Ignite
>  Issue Type: Bug
>  Components: data structures
>Affects Versions: 2.1
>Reporter: Mikhail Cherkasov
>Assignee: Stanilovsky Evgeny
>Priority: Critical
> Attachments: NoQueueOnClientNodeTest.java
>
>
> DataStructure can not be obtained on client if it is created on server node.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6469) SQL: NOT NULL fields validation for values provided by cache interceptor

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6469:

Fix Version/s: 2.3

> SQL: NOT NULL fields validation for values provided by cache interceptor
> 
>
> Key: IGNITE-6469
> URL: https://issues.apache.org/jira/browse/IGNITE-6469
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Sergey Kalashnikov
>Assignee: Sergey Kalashnikov
> Fix For: 2.3
>
>
> In case {{CacheInterceptor}} is configured, the method 
> {{CacheInterceptor.onBeforePut}} may produce the value that violates the NOT 
> NULL constraint configured by the cache's QueryEntity.
> The value returned by {{onBeforePut}} must also be validated with regards to 
> configured NOT NULL constraints.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-602:


I don't agree with this fix. It's very strange that some logging utils fix 
leads to changes in code that doesn't related directly with it. Is there 
another solution?

> [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by 
> infinite recursion
> 
>
> Key: IGNITE-602
> URL: https://issues.apache.org/jira/browse/IGNITE-602
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Artem Shutak
>Assignee: Ryabov Dmitrii
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.3
>
>
> See test 
> org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention
>  and related TODO in same source file.
> Also take a look at 
> http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring
> Test should be unmuted on TC after fix.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6442) Deadlock detection doesn't execute.

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-6442:
-

JFI: Commit message contains invalid issue number: 6445 instead of 6442.

> Deadlock detection doesn't execute.
> ---
>
> Key: IGNITE-6442
> URL: https://issues.apache.org/jira/browse/IGNITE-6442
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
> Fix For: 2.3
>
>
> In case of a configuration with near cache and if all entities of one of the 
> transactions involved in the deadlock are on the node being the initiator of 
> this transaction, then immediately after the timeout, the transaction rolls 
> back (without calling DD).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6442) Deadlock detection doesn't execute.

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-6442:
-

Thanks! Merged to master branch.

> Deadlock detection doesn't execute.
> ---
>
> Key: IGNITE-6442
> URL: https://issues.apache.org/jira/browse/IGNITE-6442
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
> Fix For: 2.3
>
>
> In case of a configuration with near cache and if all entities of one of the 
> transactions involved in the deadlock are on the node being the initiator of 
> this transaction, then immediately after the timeout, the transaction rolls 
> back (without calling DD).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-4188) Savepoints support inside of Ignite Transactions

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii commented on IGNITE-4188:


[~vozerov], 2.4.

[~sboikov], thank you for review.

* rmvLocks is needed to handle some races with concurrent locks/unlocks, since 
rollback to savepoint is synchronous operation there is no need to update 
rmvLocks in this case. So there is no need to add savepointOrder in 
GridCacheVersion, please revert this, just use 'forSavepoint' request flag to 
skip rmvLocks update
I removed savepointOrder, and tests don't fail. I found that hang doesn't 
happen because of clearing txMap, which I made after savepointOrpder. So there 
is no need to skip rmvLocks updates. At least not now.
* to add flags in messages we usually use byte, not boolean (look at 
GridDistributedTxPrepareRequest.flags)
Fixed.
* all new methods related to savepoint should be moved to GridNearTxLocal, not 
in IgniteTxLocalAdapter, also move awaitLastFuture there from 
TransactionProxyImp, TransactionProxyImp should be simple delegating facade
Fixed.
* it seems you copy/pasted SavepointUnlockFuture without understanding what 
this code is supposed to do. Why you need all these MiniFutures? why onResult 
method is never called? why deadlock detection is needed there?
Yes, i copy/pasted it and left some things for the later, if we will need them. 
I'll refactor this class and remove not used things.
* you implemented timeout support in SavepointUnlockFuture, please add 
corresponding test (to simulate timeout you can delay message using 
TestRecordingCommunicationSpi)
Ok, I'll do it.
* if I add 3 savepoints: 1, 2, 3, 4 and then rollback to 2, shouldn't we remove 
savepoints 2, 3, 4? are there such tests?
TxSavepointsSelfTest.testFailRollbackToSavepoint() tests this case. 
testOverwriteSavepoints() tests similar case when we overwrite old savepoint 
(and remove all afterward savepoints). testMultipleRollbackToSavepoint() tests 
when we want rollback to the same savepoint.
I made savepoints as in samples in ticket description, where savepoint stay 
alive after rollback and available to rollback again. My bad - I din't noticed 
this in description. But do we really need to destroy savepoint? If user 
created stable state by savepoint, why he should create another savepoint every 
time he rollback here?
* is there test which checks 'unlock' after key's primary or backup node failed?
* need add tests with near cache enabled
I'll do it.
* in tests you also need check that state was correctly restored using 
cache.get()
* Done.

> Savepoints support inside of Ignite Transactions
> 
>
> Key: IGNITE-4188
> URL: https://issues.apache.org/jira/browse/IGNITE-4188
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Assignee: Ryabov Dmitrii
> Fix For: 2.4
>
>
> A savepoint is a special mark inside a transaction that allows all commands 
> that are executed after it was established to be rolled back, restoring the 
> transaction state to what it was at the time of the savepoint.
> Here is a reference to the similar functionality implemented by some of RDBMs 
> vendors.
> https://www.postgresql.org/docs/8.1/static/sql-savepoint.html
> https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_10001.htm
> http://dev.mysql.com/doc/refman/5.7/en/savepoint.html
> Consider the following example.
> {code}
> BEGIN;
> INSERT INTO table1 VALUES (1); 
> SAVEPOINT my_savepoint; 
> INSERT INTO table1 VALUES (2); 
> ROLLBACK TO SAVEPOINT my_savepoint; 
> INSERT INTO table1 VALUES (3); 
> COMMIT;
> {code}
> The execution result must guarantee that only values 1 and 3 are inserted 
> into table1.
> In Ignite, it should be supported this way (preserving the same behavior as 
> above).
> {code}
> Ignite ignite = ;
> IgniteCache c = ;
> try (Transaction tx = ignite.transactions().txStart()) {
> c.put(1, 1);
> 
> tx.savepoint("mysavepoint");
> 
> c.put(2, 2);
> 
> tx.rollbackToSavepoint("mysavepoint");
> 
> c.put(3, 3);
> 
> tx.commit();
> }
> {code}
> As a summary the following has to be supported on Ignite side:
> - The {{savepoint}} method which will set a named transaction savepoint with 
> a name of an identifier.
> - Multiple savepoints defined within a transaction. The names of the 
> savepoints have to differ from each other. If the current transaction has a 
> savepoint with the same name, the old savepoint is deleted and a new one is 
> set.
> - The {{rollbackToSavepoint}} method that will roll back all the changes done 
> after a specific checkpoint establishment.
> - The {{releaseCheckpoint}} method that will destroy a savepoint, keeping the 
> effects of commands executed after it was established.
> - 

[jira] [Updated] (IGNITE-4188) Savepoints support inside of Ignite Transactions

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii updated IGNITE-4188:
---
Fix Version/s: (was: 2.3)
   2.4

> Savepoints support inside of Ignite Transactions
> 
>
> Key: IGNITE-4188
> URL: https://issues.apache.org/jira/browse/IGNITE-4188
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Assignee: Ryabov Dmitrii
> Fix For: 2.4
>
>
> A savepoint is a special mark inside a transaction that allows all commands 
> that are executed after it was established to be rolled back, restoring the 
> transaction state to what it was at the time of the savepoint.
> Here is a reference to the similar functionality implemented by some of RDBMs 
> vendors.
> https://www.postgresql.org/docs/8.1/static/sql-savepoint.html
> https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_10001.htm
> http://dev.mysql.com/doc/refman/5.7/en/savepoint.html
> Consider the following example.
> {code}
> BEGIN;
> INSERT INTO table1 VALUES (1); 
> SAVEPOINT my_savepoint; 
> INSERT INTO table1 VALUES (2); 
> ROLLBACK TO SAVEPOINT my_savepoint; 
> INSERT INTO table1 VALUES (3); 
> COMMIT;
> {code}
> The execution result must guarantee that only values 1 and 3 are inserted 
> into table1.
> In Ignite, it should be supported this way (preserving the same behavior as 
> above).
> {code}
> Ignite ignite = ;
> IgniteCache c = ;
> try (Transaction tx = ignite.transactions().txStart()) {
> c.put(1, 1);
> 
> tx.savepoint("mysavepoint");
> 
> c.put(2, 2);
> 
> tx.rollbackToSavepoint("mysavepoint");
> 
> c.put(3, 3);
> 
> tx.commit();
> }
> {code}
> As a summary the following has to be supported on Ignite side:
> - The {{savepoint}} method which will set a named transaction savepoint with 
> a name of an identifier.
> - Multiple savepoints defined within a transaction. The names of the 
> savepoints have to differ from each other. If the current transaction has a 
> savepoint with the same name, the old savepoint is deleted and a new one is 
> set.
> - The {{rollbackToSavepoint}} method that will roll back all the changes done 
> after a specific checkpoint establishment.
> - The {{releaseCheckpoint}} method that will destroy a savepoint, keeping the 
> effects of commands executed after it was established.
> - Full support of the behavior listed above at the level of ODBC and JDBC 
> drivers and DML (will be handled under separate tickets).
> - The behavior has to be support for all transactional modes.
> Original proposal on the dev list:
> http://apache-ignite-developers.2346864.n4.nabble.com/TX-savepoints-td12041.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-584) Need to make sure that scan query returns consistent results on topology changes

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny updated IGNITE-584:
--
Fix Version/s: 2.4

> Need to make sure that scan query returns consistent results on topology 
> changes
> 
>
> Key: IGNITE-584
> URL: https://issues.apache.org/jira/browse/IGNITE-584
> Project: Ignite
>  Issue Type: Sub-task
>  Components: data structures
>Affects Versions: 1.9, 2.0, 2.1
>Reporter: Artem Shutak
>Assignee: Semen Boikov
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.4
>
>
> Consistent results on topology changes was implemented for sql queries, but 
> looks like it still does not work for scan queries.
> This affects 'cache set' tests since set uses scan query for set iteration 
> (to be unmuted on TC): 
> GridCacheSetAbstractSelfTest testNodeJoinsAndLeaves and 
> testNodeJoinsAndLeavesCollocated; 
> Also see todos here GridCacheSetFailoverAbstractSelfTest



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-4188) Savepoints support inside of Ignite Transactions

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4188:
-

[~sboikov], [~SomeFire], 
Provided that Ignite 2.3 release is near, does it makes sense to fit it into 
2.3? Or may be it is better to move the ticket to 2.4?

> Savepoints support inside of Ignite Transactions
> 
>
> Key: IGNITE-4188
> URL: https://issues.apache.org/jira/browse/IGNITE-4188
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Assignee: Ryabov Dmitrii
> Fix For: 2.3
>
>
> A savepoint is a special mark inside a transaction that allows all commands 
> that are executed after it was established to be rolled back, restoring the 
> transaction state to what it was at the time of the savepoint.
> Here is a reference to the similar functionality implemented by some of RDBMs 
> vendors.
> https://www.postgresql.org/docs/8.1/static/sql-savepoint.html
> https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_10001.htm
> http://dev.mysql.com/doc/refman/5.7/en/savepoint.html
> Consider the following example.
> {code}
> BEGIN;
> INSERT INTO table1 VALUES (1); 
> SAVEPOINT my_savepoint; 
> INSERT INTO table1 VALUES (2); 
> ROLLBACK TO SAVEPOINT my_savepoint; 
> INSERT INTO table1 VALUES (3); 
> COMMIT;
> {code}
> The execution result must guarantee that only values 1 and 3 are inserted 
> into table1.
> In Ignite, it should be supported this way (preserving the same behavior as 
> above).
> {code}
> Ignite ignite = ;
> IgniteCache c = ;
> try (Transaction tx = ignite.transactions().txStart()) {
> c.put(1, 1);
> 
> tx.savepoint("mysavepoint");
> 
> c.put(2, 2);
> 
> tx.rollbackToSavepoint("mysavepoint");
> 
> c.put(3, 3);
> 
> tx.commit();
> }
> {code}
> As a summary the following has to be supported on Ignite side:
> - The {{savepoint}} method which will set a named transaction savepoint with 
> a name of an identifier.
> - Multiple savepoints defined within a transaction. The names of the 
> savepoints have to differ from each other. If the current transaction has a 
> savepoint with the same name, the old savepoint is deleted and a new one is 
> set.
> - The {{rollbackToSavepoint}} method that will roll back all the changes done 
> after a specific checkpoint establishment.
> - The {{releaseCheckpoint}} method that will destroy a savepoint, keeping the 
> effects of commands executed after it was established.
> - Full support of the behavior listed above at the level of ODBC and JDBC 
> drivers and DML (will be handled under separate tickets).
> - The behavior has to be support for all transactional modes.
> Original proposal on the dev list:
> http://apache-ignite-developers.2346864.n4.nabble.com/TX-savepoints-td12041.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-2539) NPE at RendezvousAffinityFunction

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2539:

Fix Version/s: (was: 2.3)
   2.4

> NPE at RendezvousAffinityFunction
> -
>
> Key: IGNITE-2539
> URL: https://issues.apache.org/jira/browse/IGNITE-2539
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ershov
>Assignee: Dmitriy Govorukhin
>Priority: Critical
> Fix For: 2.4
>
> Attachments: ignite.log
>
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> RendezvousAffinityFunction#assignPartition throws NPE, probably due to 
> simultaneous topology change and  cache stop. We should write a test and fix 
> this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-2539) NPE at RendezvousAffinityFunction

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-2539:
-

Moved to 2.4 due to inactivity.

> NPE at RendezvousAffinityFunction
> -
>
> Key: IGNITE-2539
> URL: https://issues.apache.org/jira/browse/IGNITE-2539
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ershov
>Assignee: Dmitriy Govorukhin
>Priority: Critical
> Fix For: 2.4
>
> Attachments: ignite.log
>
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> RendezvousAffinityFunction#assignPartition throws NPE, probably due to 
> simultaneous topology change and  cache stop. We should write a test and fix 
> this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-1678) IgniteAtomicSequence: make following reservations in advance

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-1678:

Fix Version/s: (was: 2.3)
   2.4

> IgniteAtomicSequence: make following reservations in advance
> 
>
> Key: IGNITE-1678
> URL: https://issues.apache.org/jira/browse/IGNITE-1678
> Project: Ignite
>  Issue Type: Improvement
>  Components: data structures
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Dmitriy Govorukhin
> Fix For: 2.4
>
> Attachments: Screenshot from 2016-12-15 10-50-22.png
>
>
> In current implementation a new reservation is made when the current local 
> sequence boundary is exceeded.
> In cases when there are many nodes that use the same atomic sequence there 
> can be a situation when all the nodes start doing a new reservation at the 
> same time. This can lead to performance drops.
> As a performance optimization it makes sense to start reserving new sequence 
> slot in advance (in background), like when around 80% of current reservation 
> has already been used. Probably we should add a special parameter to 
> {{AtomicConfiguration}} that will manage such behavior.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-1678) IgniteAtomicSequence: make following reservations in advance

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-1678:
-

Moved to 2.4 due to inactivity.

> IgniteAtomicSequence: make following reservations in advance
> 
>
> Key: IGNITE-1678
> URL: https://issues.apache.org/jira/browse/IGNITE-1678
> Project: Ignite
>  Issue Type: Improvement
>  Components: data structures
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Dmitriy Govorukhin
> Fix For: 2.4
>
> Attachments: Screenshot from 2016-12-15 10-50-22.png
>
>
> In current implementation a new reservation is made when the current local 
> sequence boundary is exceeded.
> In cases when there are many nodes that use the same atomic sequence there 
> can be a situation when all the nodes start doing a new reservation at the 
> same time. This can lead to performance drops.
> As a performance optimization it makes sense to start reserving new sequence 
> slot in advance (in background), like when around 80% of current reservation 
> has already been used. Probably we should add a special parameter to 
> {{AtomicConfiguration}} that will manage such behavior.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-3195) Rebalancing: IgniteConfiguration.rebalanceThreadPoolSize is wrongly treated

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-3195:
-

Moved to 2.4 due to inactivity.

> Rebalancing: IgniteConfiguration.rebalanceThreadPoolSize is wrongly treated
> ---
>
> Key: IGNITE-3195
> URL: https://issues.apache.org/jira/browse/IGNITE-3195
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Denis Magda
>Assignee: Anton Vinogradov
> Fix For: 2.4
>
>
> Presently it's considered that the maximum number of threads that has to 
> process all demand and supply messages coming from all the nodes must not be 
> bigger than {{IgniteConfiguration.rebalanceThreadPoolSize}}.
> Current implementation relies on ordered messages functionality creating a 
> number of topics equal to {{IgniteConfiguration.rebalanceThreadPoolSize}}.
> However, the implementation doesn't take into account that ordered messages, 
> that correspond to a particular topic, are processed in parallel for 
> different nodes. Refer to the implementation of 
> {{GridIoManager.processOrderedMessage}} to see that for every topic there 
> will be a unique {{GridCommunicationMessageSet}} for every node.
> Also to prove that this is true you can refer to this execution stack 
> {noformat}
> java.lang.RuntimeException: HAPPENED DEMAND
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:378)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:364)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:622)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:320)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$300(GridCacheIoManager.java:81)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1125)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1219)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:105)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2456)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1179)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1900(GridIoManager.java:105)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:1148)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> All this means that in fact the number of threads that will be busy with 
> replication activity will be equal to 
> {{IgniteConfiguration.rebalanceThreadPoolSize}} x 
> number_of_nodes_participated_in_rebalancing



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-3195) Rebalancing: IgniteConfiguration.rebalanceThreadPoolSize is wrongly treated

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3195:

Fix Version/s: (was: 2.3)
   2.4

> Rebalancing: IgniteConfiguration.rebalanceThreadPoolSize is wrongly treated
> ---
>
> Key: IGNITE-3195
> URL: https://issues.apache.org/jira/browse/IGNITE-3195
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Denis Magda
>Assignee: Anton Vinogradov
> Fix For: 2.4
>
>
> Presently it's considered that the maximum number of threads that has to 
> process all demand and supply messages coming from all the nodes must not be 
> bigger than {{IgniteConfiguration.rebalanceThreadPoolSize}}.
> Current implementation relies on ordered messages functionality creating a 
> number of topics equal to {{IgniteConfiguration.rebalanceThreadPoolSize}}.
> However, the implementation doesn't take into account that ordered messages, 
> that correspond to a particular topic, are processed in parallel for 
> different nodes. Refer to the implementation of 
> {{GridIoManager.processOrderedMessage}} to see that for every topic there 
> will be a unique {{GridCommunicationMessageSet}} for every node.
> Also to prove that this is true you can refer to this execution stack 
> {noformat}
> java.lang.RuntimeException: HAPPENED DEMAND
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:378)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:364)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:622)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:320)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$300(GridCacheIoManager.java:81)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1125)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1219)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:105)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2456)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1179)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1900(GridIoManager.java:105)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:1148)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> All this means that in fact the number of threads that will be busy with 
> replication activity will be equal to 
> {{IgniteConfiguration.rebalanceThreadPoolSize}} x 
> number_of_nodes_participated_in_rebalancing



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5732) Provide API to test compatibility with old releases

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur commented on IGNITE-5732:


Hi, [~dpavlov], it's the known problem.
The reason is specific system environment at the start the test through Maven 
(mvn test).
It's fixed already by [the 
commit|https://github.com/apache/ignite/commit/507ac67568743cd0838d0822979022a698a79957].
Please rebase your branch on the master branch and try again.
If the problem still remains, please write here the links to the new failed 
builds. 

> Provide API to test compatibility with old releases
> ---
>
> Key: IGNITE-5732
> URL: https://issues.apache.org/jira/browse/IGNITE-5732
> Project: Ignite
>  Issue Type: New Feature
>Affects Versions: 2.1
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
> Fix For: 2.3
>
>
> Need to provide an opportunity to test compatibility with old releases.
> The main idea is the method {code}startGrid(ver){code} in the testing 
> framework, which would start an instance via downloaded "jar" from the Maven 
> repo.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5569) TCP Discovery SPI allows multiple NODE_JOINED / NODE_FAILED leading to a cluster DDoS

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-5569:
-

Moved to 2.4 due to inactivity.

> TCP Discovery SPI allows multiple NODE_JOINED / NODE_FAILED leading to a 
> cluster DDoS
> -
>
> Key: IGNITE-5569
> URL: https://issues.apache.org/jira/browse/IGNITE-5569
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.7
>Reporter: Alexey Goncharuk
>Assignee: Dmitry Karachentsev
> Fix For: 2.4
>
>
> A firewall configuration issue may effectively lead to a cluster DDoS. The 
> scheme is as follows:
> 1) A node G joins the cluster, and a firewall rule forbids incoming 
> connection from cluster to this node
> 2) Cluster successfully processes NodeAddedMesage and fires a discovery 
> NODE_JOINED event (not sure why?)
> 4) The last node in the ring fails to connect to the newly joined node and 
> generates NODE_FAILED event
> 5) Coordinator drops the connection, joining node attempts to connect again
> The issues I see here:
> 1) Neither coordinator nor joining node print out the reason why the joining 
> node failed / did not join. A slight hint (failed to send message to the next 
> node) is printed on the node with the largest order (the one that attempted 
> to close the ring), but the root cause (connection refused) is also not 
> printed
> 2) The joining node attempts to connect to the cluster with the same node ID. 
> This violates an invariant we heavily rely on that once a node ID leaves a 
> cluster, this ID never comes back again
> 3) Each discovery event leads to a partition exchange which blocks all cache 
> operations for a time interval equal at least to the full ring latency time. 
> If several nodes are started on a malicious host, this may lead to almost 
> full cluster degradation



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5569) TCP Discovery SPI allows multiple NODE_JOINED / NODE_FAILED leading to a cluster DDoS

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5569:

Fix Version/s: (was: 2.3)
   2.4

> TCP Discovery SPI allows multiple NODE_JOINED / NODE_FAILED leading to a 
> cluster DDoS
> -
>
> Key: IGNITE-5569
> URL: https://issues.apache.org/jira/browse/IGNITE-5569
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.7
>Reporter: Alexey Goncharuk
>Assignee: Dmitry Karachentsev
> Fix For: 2.4
>
>
> A firewall configuration issue may effectively lead to a cluster DDoS. The 
> scheme is as follows:
> 1) A node G joins the cluster, and a firewall rule forbids incoming 
> connection from cluster to this node
> 2) Cluster successfully processes NodeAddedMesage and fires a discovery 
> NODE_JOINED event (not sure why?)
> 4) The last node in the ring fails to connect to the newly joined node and 
> generates NODE_FAILED event
> 5) Coordinator drops the connection, joining node attempts to connect again
> The issues I see here:
> 1) Neither coordinator nor joining node print out the reason why the joining 
> node failed / did not join. A slight hint (failed to send message to the next 
> node) is printed on the node with the largest order (the one that attempted 
> to close the ring), but the root cause (connection refused) is also not 
> printed
> 2) The joining node attempts to connect to the cluster with the same node ID. 
> This violates an invariant we heavily rely on that once a node ID leaves a 
> cluster, this ID never comes back again
> 3) Each discovery event leads to a partition exchange which blocks all cache 
> operations for a time interval equal at least to the full ring latency time. 
> If several nodes are started on a malicious host, this may lead to almost 
> full cluster degradation



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6513) Add ability manage version of WAL serializer via system properties

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6513:


GitHub user DmitriyGovorukhin opened a pull request:

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

IGNITE-6513 introduce system property for manage wal serializer version

-DIGNITE_WAL_SERIALIZER_VERSION=2

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

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

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

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

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

This closes #2770


commit d921a453ed48681781c830bac56f73d33b3b3ca0
Author: Dmitriy Govorukhin 
Date:   2017-09-28T13:05:57Z

IGNITE-6513 introduce system property for manage wal serializer version 
(IGNITE_WAL_SERIALIZER_VERSION)




> Add ability manage version of WAL serializer via system properties
> --
>
> Key: IGNITE-6513
> URL: https://issues.apache.org/jira/browse/IGNITE-6513
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.0, 2.1, 2.2, 2.3
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
> Fix For: 2.4
>
>
> An example: -DIGNITE_WAL_SERIALIZER_VERSION=2



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6513) Add ability manage version of WAL serializer via system properties

[Dmitriy Govorukhin (JIRA)]

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

Dmitriy Govorukhin updated IGNITE-6513:
---
Description: An example: -DIGNITE_WAL_SERIALIZER_VERSION=2

> Add ability manage version of WAL serializer via system properties
> --
>
> Key: IGNITE-6513
> URL: https://issues.apache.org/jira/browse/IGNITE-6513
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.0, 2.1, 2.2, 2.3
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
> Fix For: 2.4
>
>
> An example: -DIGNITE_WAL_SERIALIZER_VERSION=2



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6046) Multiple SQL statements in one JDBC command do not work

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6046:


Github user asfgit closed the pull request at:

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


> Multiple SQL statements in one JDBC command do not work
> ---
>
> Key: IGNITE-6046
> URL: https://issues.apache.org/jira/browse/IGNITE-6046
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql
>Reporter: Dmitriy Setrakyan
>Assignee: Taras Ledkov
>  Labels: important, usability
> Fix For: 2.3
>
>
> I have connected to Ignite from DBeaver using our thin JDBC driver. When I 
> execute more than one statement from the SQL Editor, I get an error.
> For example, highlighting and executing these 2 statements gives an error:
> {code:sql}
> INSERT INTO city (id, name) VALUES (2, 'Forest Hill');
> INSERT INTO person (id, name, city_id) VALUES (2, 'John Doe', 3);
> {code}
> Here is the error I get:
> {code}
> [15:25:17,265][SEVERE][sql-connector-#150%null%][JdbcRequestHandler] Failed 
> to execute SQL query [reqId=26, req=JdbcQueryExecuteRequest [schemaName=null, 
> pageSize=1024, maxRows=0, sqlQry=INSERT INTO city (id, name) VALUES (2, 
> 'Forest Hill');
> INSERT INTO person (id, name, city_id) VALUES (2, 'John Doe', 3), args=[]]]
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: 
> Can not set org.h2.command.Prepared field 
> org.h2.command.CommandContainer.prepared to org.h2.command.CommandList
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1863)
> at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:188)
> at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:122)
> at 
> org.apache.ignite.internal.processors.odbc.SqlListenerNioListener.onMessage(SqlListenerNioListener.java:152)
> at 
> org.apache.ignite.internal.processors.odbc.SqlListenerNioListener.onMessage(SqlListenerNioListener.java:44)
> at 
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
> at 
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
> at 
> org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at 
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: class org.apache.ignite.IgniteCheckedException: Can not set 
> org.h2.command.Prepared field org.h2.command.CommandContainer.prepared to 
> org.h2.command.CommandList
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2316)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1860)
> ... 12 more
> Caused by: java.lang.IllegalArgumentException: Can not set 
> org.h2.command.Prepared field org.h2.command.CommandContainer.prepared to 
> org.h2.command.CommandList
> at 
> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:167)
> at 
> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:171)
> at 
> sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:58)
> at 
> sun.reflect.UnsafeObjectFieldAccessorImpl.get(UnsafeObjectFieldAccessorImpl.java:36)
> at java.lang.reflect.Field.get(Field.java:393)
> at 
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser$Getter.get(GridSqlQueryParser.java:1600)
> at 
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.prepared(GridSqlQueryParser.java:443)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1298)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1856)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1852)
> at 
> 

[jira] [Commented] (IGNITE-6509) SQL: Add NOT NULL support to QueryEntity API

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-6509:
-

Test run: 
https://ci.ignite.apache.org/viewQueued.html?itemId=859367=queuedBuildOverviewTab

> SQL: Add NOT NULL support to QueryEntity API
> 
>
> Key: IGNITE-6509
> URL: https://issues.apache.org/jira/browse/IGNITE-6509
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: important
> Fix For: 2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6509) SQL: Add NOT NULL support to QueryEntity API

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6509:


GitHub user devozerov opened a pull request:

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

IGNITE-6509



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

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

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

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

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

This closes #2769


commit 2ee59b208ac0c7d4665bf190c38bf7286aeffe3e
Author: devozerov 
Date:   2017-09-28T08:37:58Z

Returned not null field.




> SQL: Add NOT NULL support to QueryEntity API
> 
>
> Key: IGNITE-6509
> URL: https://issues.apache.org/jira/browse/IGNITE-6509
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: important
> Fix For: 2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6448) Select * doesn't return new field name after concurrent ALTER TABLE

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6448:

Fix Version/s: (was: 2.3)
   2.4

> Select * doesn't return new field name after concurrent ALTER TABLE 
> 
>
> Key: IGNITE-6448
> URL: https://issues.apache.org/jira/browse/IGNITE-6448
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Ilya Suntsov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.4
>
>
> Steps for reproduce:
> 1. Start 3 nodes
> 2. Execute 
> {noformat}CREATE TABLE person (id LONG, name VARCHAR, city_id LONG, PRIMARY 
> KEY (id, city_id)) {noformat}
> to create table Person
> 3. Connect to grid via sqlline (https://github.com/julianhyde/sqlline)
> {noformat}./sqlline -d org.apache.ignite.IgniteJdbcThinDriver --color=true 
> --verbose=true --showWarnings=true --showNestedErrs=true -u 
> jdbc:ignite:thin://127.0.0.1/{noformat}
> 4. Create one more connection {noformat}!connect 
> jdbc:ignite:thin://127.0.0.1/ {noformat}
> 5. Execute ALTER TABLE for both connections {noformat} !all alter table 
> person add field1 varchar;{noformat}
> Result:
> 1. Got exception on coordinator:
> {noformat}[10:59:15,805][SEVERE][client-connector-#55%null%][JdbcRequestHandler]
>  Failed to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest 
> [schemaName=PUBLIC, pageSize=1024, maxRows=0, sqlQry=alter table person add 
> field1 varchar, args=[], stmtType=ANY_STATEMENT_TYPE]]
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Column 
> already exists: FIELD1
>   at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.convert(DdlStatementsProcessor.java:329)
>   at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:273)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1383)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1918)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1914)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2396)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1922)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:286)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:149)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:141)
>   at 
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:40)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
>   at 
> org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at 
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> 2. When I try to get all data from Person:
> {noformat}select * from person;{noformat}
> I get the table without new field but if try to get only this field from 
> table it works.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)