[jira] [Updated] (IGNITE-5754) Web Console: Web agent should use POST instead of GET to get topology

[Andrey Novikov (JIRA)]

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

Andrey Novikov updated IGNITE-5754:
---
Fix Version/s: (was: 2.1)
   2.2

> Web Console: Web agent should use POST instead of GET to get topology
> -
>
> Key: IGNITE-5754
> URL: https://issues.apache.org/jira/browse/IGNITE-5754
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Andrey Novikov
> Fix For: 2.2
>
>
> On large topology Web Agent generate very long GET request and node that 
> handle that request throw error: "URI is too large > 8192"



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

[jira] [Updated] (IGNITE-4728) Web Console: Remember the screen from which user has left the previous session.

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-4728:
-
Fix Version/s: 2.2

> Web Console: Remember the screen from which user has left the previous 
> session.
> ---
>
> Key: IGNITE-4728
> URL: https://issues.apache.org/jira/browse/IGNITE-4728
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Reporter: Vica Abramova
>Assignee: Dmitriy Shabalin
> Fix For: 2.2
>
> Attachments: ignite-4728.png
>
>
> Don't save latest state for demo mode.



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

[jira] [Created] (IGNITE-5754) Web Console: Web agent should use POST instead of GET to get topology

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-5754:


 Summary: Web Console: Web agent should use POST instead of GET to 
get topology
 Key: IGNITE-5754
 URL: https://issues.apache.org/jira/browse/IGNITE-5754
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Alexey Kuznetsov
Assignee: Andrey Novikov
 Fix For: 2.1


On large topology Web Agent generate very long GET request and node that handle 
that request throw error: "URI is too large > 8192"



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

[jira] [Assigned] (IGNITE-5677) Document affinity-related SQL optimizations

[Denis Magda (JIRA)]

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

Denis Magda reassigned IGNITE-5677:
---

Assignee: Vladimir Ozerov  (was: Denis Magda)

> Document affinity-related SQL optimizations
> ---
>
> Key: IGNITE-5677
> URL: https://issues.apache.org/jira/browse/IGNITE-5677
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Vladimir Ozerov
> Fix For: 2.1
>
>
> Refer to the ticket below for details on what has been done:
> https://issues.apache.org/jira/browse/IGNITE-4509



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

[jira] [Commented] (IGNITE-5677) Document affinity-related SQL optimizations

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-5677:
-

[~vozerov], could you help to describe the affinity-related optimizations on 
the performance related page?
https://apacheignite.readme.io/v2.1/docs/sql-performance-and-debugging

A good solution would be to show an exemplary SQL query that will be optimized 
by SQL engine when some of the conditions are met.

> Document affinity-related SQL optimizations
> ---
>
> Key: IGNITE-5677
> URL: https://issues.apache.org/jira/browse/IGNITE-5677
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 2.1
>
>
> Refer to the ticket below for details on what has been done:
> https://issues.apache.org/jira/browse/IGNITE-4509



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

[jira] [Comment Edited] (IGNITE-4191) Transactional support at the level of Ignite drivers and DML

[David Robinson (JIRA)]

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

David Robinson edited comment on IGNITE-4191 at 7/13/17 8:59 PM:
-

Same problem as reported in this defect occurs when trying to use Sqoop to pull 
data from Ignite.
Same problem as reported in this defect occurs when trying to use DbSchema to 
connect and work with Ignite (http://www.dbschema.com/)


was (Author: drobin1437):
Same problem as reported in this defect occurs when trying to use Sqoop to pull 
data from Ignite.

> Transactional support at the level of Ignite drivers and DML
> 
>
> Key: IGNITE-4191
> URL: https://issues.apache.org/jira/browse/IGNITE-4191
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Denis Magda
> Fix For: 2.2
>
>
> Presently there is no any way to execute data modification statements and 
> SELECT queries in a transactional fashion using our JDBC/ODBC drivers and DML 
> API.
> This can be fully supported once MVCC is ready and released.



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

[jira] [Commented] (IGNITE-4191) Transactional support at the level of Ignite drivers and DML

[David Robinson (JIRA)]

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

David Robinson commented on IGNITE-4191:


Same problem as reported in this defect occurs when trying to use Sqoop to pull 
data from Ignite.

> Transactional support at the level of Ignite drivers and DML
> 
>
> Key: IGNITE-4191
> URL: https://issues.apache.org/jira/browse/IGNITE-4191
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Denis Magda
> Fix For: 2.2
>
>
> Presently there is no any way to execute data modification statements and 
> SELECT queries in a transactional fashion using our JDBC/ODBC drivers and DML 
> API.
> This can be fully supported once MVCC is ready and released.



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

[jira] [Comment Edited] (IGNITE-3878) Add isPrimary() and isBackup() methods on CacheQUeryEntryEvent

[Maksim Kozlov (JIRA)]

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

Maksim Kozlov edited comment on IGNITE-3878 at 7/13/17 7:21 PM:


[~ntikho...@apache.org] Please review. 
[TeamCity|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests_Ignite20Tests=pull%2F1393%2Fhead]


was (Author: dreamx):
[~ntikho...@apache.org] Please 
review.[ci|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests_Ignite20Tests=pull%2F1393%2Fhead]

> Add isPrimary() and isBackup() methods on CacheQUeryEntryEvent
> --
>
> Key: IGNITE-3878
> URL: https://issues.apache.org/jira/browse/IGNITE-3878
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 1.7
>Reporter: Nikolay Tikhonov
>Assignee: Maksim Kozlov
>Priority: Minor
> Fix For: 2.2
>
>
> In some cases useful know where (on primary or backup nodes) was invoked  a 
> continuous query filter.



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

[jira] [Comment Edited] (IGNITE-3878) Add isPrimary() and isBackup() methods on CacheQUeryEntryEvent

[Maksim Kozlov (JIRA)]

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

Maksim Kozlov edited comment on IGNITE-3878 at 7/13/17 7:20 PM:


[~ntikho...@apache.org] Please 
review.[ci|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests_Ignite20Tests=pull%2F1393%2Fhead]


was (Author: dreamx):
[~ntikho...@apache.org] Please review.

> Add isPrimary() and isBackup() methods on CacheQUeryEntryEvent
> --
>
> Key: IGNITE-3878
> URL: https://issues.apache.org/jira/browse/IGNITE-3878
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 1.7
>Reporter: Nikolay Tikhonov
>Assignee: Maksim Kozlov
>Priority: Minor
> Fix For: 2.2
>
>
> In some cases useful know where (on primary or backup nodes) was invoked  a 
> continuous query filter.



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

[jira] [Updated] (IGNITE-5751) In TcpCommunicationSpi.createTcpClient U.filterReachable waits all addresses to check if they are reachable

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-5751:
-
Fix Version/s: 2.2

> In TcpCommunicationSpi.createTcpClient U.filterReachable waits all addresses 
> to check if they are reachable
> ---
>
> Key: IGNITE-5751
> URL: https://issues.apache.org/jira/browse/IGNITE-5751
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Priority: Critical
> Fix For: 2.2
>
>
> In TcpCommunicationSpi.createTcpClient replace U.filterReachable with 
> filtering first reachable address



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

[jira] [Commented] (IGNITE-5751) In TcpCommunicationSpi.createTcpClient U.filterReachable waits all addresses to check if they are reachable

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-5751:
--

1. Seems, we should use SocketConnectTimeout instead of hardcoded 2 sec timeout.
2. Looks like there is no need to wait for all addressed to be checked, but 
only the first one 
and may be wait a little bit more to allow to check some more addresses.

We have to check here if using first reachable address approach is correct as
JDK classes is used to check host reachability, but there is no check  
preformed for port reachability. 
Have I missed smth?

> In TcpCommunicationSpi.createTcpClient U.filterReachable waits all addresses 
> to check if they are reachable
> ---
>
> Key: IGNITE-5751
> URL: https://issues.apache.org/jira/browse/IGNITE-5751
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Priority: Critical
> Fix For: 2.2
>
>
> In TcpCommunicationSpi.createTcpClient replace U.filterReachable with 
> filtering first reachable address



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

[jira] [Updated] (IGNITE-5751) In TcpCommunicationSpi.createTcpClient U.filterReachable waits all addresses to check if they are reachable

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-5751:
-
Component/s: general

> In TcpCommunicationSpi.createTcpClient U.filterReachable waits all addresses 
> to check if they are reachable
> ---
>
> Key: IGNITE-5751
> URL: https://issues.apache.org/jira/browse/IGNITE-5751
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Priority: Critical
>
> In TcpCommunicationSpi.createTcpClient replace U.filterReachable with 
> filtering first reachable address



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

[jira] [Updated] (IGNITE-5751) In TcpCommunicationSpi.createTcpClient U.filterReachable waits all addresses to check if they are reachable

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-5751:
-
Affects Version/s: (was: 1.9)
   2.1

> In TcpCommunicationSpi.createTcpClient U.filterReachable waits all addresses 
> to check if they are reachable
> ---
>
> Key: IGNITE-5751
> URL: https://issues.apache.org/jira/browse/IGNITE-5751
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Priority: Critical
>
> In TcpCommunicationSpi.createTcpClient replace U.filterReachable with 
> filtering first reachable address



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

[jira] [Commented] (IGNITE-5753) CPP: Memory leak on argument cleaning for SqlQuery and SqlFieldsQuery

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5753:


GitHub user isapego opened a pull request:

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

IGNITE-5753: Memory leak fixed



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

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

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

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


commit d982a4534d825ba63f8cca8c3f48fb925dbc0c8c
Author: Igor Sapego 
Date:   2017-07-13T18:09:34Z

IGNITE-5753: Memory leak fixed




> CPP: Memory leak on argument cleaning for SqlQuery and SqlFieldsQuery
> -
>
> Key: IGNITE-5753
> URL: https://issues.apache.org/jira/browse/IGNITE-5753
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 2.2
>
>
> There is a memory leak in {{SqlQuery::ClearArguments()}} and 
> {{SqlFieldsQuery::ClearArguments()}}.



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

[jira] [Updated] (IGNITE-5553) Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov updated IGNITE-5553:

Description: 
h2. Notes-4435
When IgniteSet is restored from persistence, size of set is always 0, [link to 
test 
history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-7043871603266099589=testDetails].

h2. Detailed description
Unlike *IgniteQueue* which uses separate cache key to store its size 
*IgniteSet* stores it in a field of some class.
Test from the link above shows very clearly that after restoring memory state 
from PDS all set values are restored correctly but size is lost.

h2. Proposed solution
One possible solution might be to do the same thing as *IgniteQueue* does: size 
of *IgniteSet* must be stored is cache instead of volatile in-memory fields of 
random classes.

  was:
h2. Notes
When IgniteSet is restored from persistence, size of set is always 0, [link to 
test 
history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-7043871603266099589=testDetails].

h2. Detailed description
Unlike *IgniteQueue* which uses separate cache key to store its size 
*IgniteSet* stores it in a field of some class.
Test from the link above shows very clearly that after restoring memory state 
from PDS all set values are restored correctly but size is lost.

h2. Proposed solution
One possible solution might be to do the same thing as *IgniteQueue* does: size 
of *IgniteSet* must be stored is cache instead of volatile in-memory fields of 
random classes.


> Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error
> -
>
> Key: IGNITE-5553
> URL: https://issues.apache.org/jira/browse/IGNITE-5553
> Project: Ignite
>  Issue Type: Bug
>  Components: data structures, persistence
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Priority: Critical
>  Labels: test-fail
> Fix For: 2.2
>
>
> h2. Notes-4435
> When IgniteSet is restored from persistence, size of set is always 0, [link 
> to test 
> history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-7043871603266099589=testDetails].
> h2. Detailed description
> Unlike *IgniteQueue* which uses separate cache key to store its size 
> *IgniteSet* stores it in a field of some class.
> Test from the link above shows very clearly that after restoring memory state 
> from PDS all set values are restored correctly but size is lost.
> h2. Proposed solution
> One possible solution might be to do the same thing as *IgniteQueue* does: 
> size of *IgniteSet* must be stored is cache instead of volatile in-memory 
> fields of random classes.



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

[jira] [Commented] (IGNITE-5330) .NET: Peer assembly loading documentation

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5330:


Done: https://apacheignite-net.readme.io/v2.1/docs/zero-deployment
[~dmagda] please have a look.

> .NET: Peer assembly loading documentation
> -
>
> Key: IGNITE-5330
> URL: https://issues.apache.org/jira/browse/IGNITE-5330
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.1
>
>
> Document peer assembly loading on https://apacheignite-net.readme.io/
> Update existing docs about {{-assembly}} switch, etc.



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

[jira] [Commented] (IGNITE-5752) Fix stale sequence updates for local partition map

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5752:


GitHub user Jokser opened a pull request:

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

IGNITE-5752 Fixed GridDhtPartitionMap updateSequence modifying



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

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

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

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


commit 707c454ad9c3b4132e2d0a20d15dc1eb2ed295b0
Author: Alexey Goncharuk 
Date:   2017-07-12T07:53:46Z

Corrected fix for REST processor wrt authentication

commit f3828261b30c12d5aa181914033afe46c787f87e
Author: Alexey Kuznetsov 
Date:   2017-07-12T07:57:50Z

IGNITE-5639 Added duration for empty result set.

commit 5859b192ba28d53e1bccb01ce3005821e26b5347
Author: devozerov 
Date:   2017-07-12T09:46:42Z

AI 2.1 release notes.

commit 8afdc7baae73ecba67e0735baa97d03f2c4fc715
Author: devozerov 
Date:   2017-07-12T10:51:43Z

Removed CacheBinaryAutoStoreExample and relevant bean "h2-example-db" from 
example-default.xml because example duplicated existing CacheAutoStoreExample.

commit c6ee085b8a1321ce7fa15f8adf74fa7a01f7a445
Author: Dmitriy Govorukhin 
Date:   2017-07-12T11:22:03Z

Fixed page acquire during checkpoint

commit 0cb6ac06a43ac72c707b29d7216bd4cb711a
Author: Oleg Ostanin 
Date:   2017-07-12T12:57:40Z

IGNITE-5740 - Added transaction load timing benchmark

commit 3787181310597b7a6e633e745ba08209abd038a9
Author: Alexey Goncharuk 
Date:   2017-07-12T15:28:57Z

More verbose logging

commit 21964fb5f6fb6fee891283332202cbc9ed5ac3f3
Author: Dmitry Pavlov 
Date:   2017-07-12T15:59:10Z

Optimized snapshot progress tracking

commit 689b1b6e9c3e723cf394c7ff2427097b21d96ce3
Author: Alexey Goncharuk 
Date:   2017-07-13T07:12:01Z

IGNITE-5479 - Cleanup public API for PersistentStoreConfiguration

commit 3c1749da82e663500e45a34369eac48dbbc62bdc
Author: Alexander Paschenko 
Date:   2017-07-13T08:25:55Z

IGNITE-5744 Ignore non user caches when automatically choosing a queryable 
cache inside JDBC driver

commit 9d4e5fdf915109c3938226cfcf70b9b091449db2
Author: Pavel Kovalenko 
Date:   2017-07-13T15:08:37Z

IGNITE-5752 Fixed updateSequence updating in GridDhtPartitionMap.




> Fix stale sequence updates for local partition map
> --
>
> Key: IGNITE-5752
> URL: https://issues.apache.org/jira/browse/IGNITE-5752
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Critical
> Fix For: 2.2
>
>
> Sometimes cache group start/stop operation leads to stale sequence updates 
> for local partition maps during partitions map exchange.
> {noformat}
> Exception in thread "sys-#17801%database.IgniteDbSnapshotSelfMultiNodeTest0%" 
> java.lang.AssertionError
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.update(GridDhtPartitionTopologyImpl.java:1230)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processFullPartitionUpdate(GridCachePartitionExchangeManager.java:1334)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1000(GridCachePartitionExchangeManager.java:125)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$3.onMessage(GridCachePartitionExchangeManager.java:297)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$3.onMessage(GridCachePartitionExchangeManager.java:295)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2243)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2225)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1042)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561)
> at 
> 

[jira] [Commented] (IGNITE-5482) Implement basic caching of query results

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-5482:
-

[~al.psc], my comments:
1) Unused imports
2) {{IgniteH2Indexing.store|remove}} - looks like cache is cleared before 
update. It means, that you can re-cache stale data before update, and thus get 
stale results.
3) Should state be cleared during DDL commands execution?
4) I think it is better to have boolean flag on per-query basis, rather than 
global configuration. It should be {{false}} by default.
5) Looks like {{AtomicReference}} is not needed. Instead, we should iterate 
over wrappers and mark them invalid.
6) I do not understand the purpose of {{GridMapQueryExecutor#absolute}} method. 
All we need is to track current position, and simply copy some rows from 
existing List with results to passed List, aren't we?
7) You never clear the cache except of updates. This is a memory leak. At the 
moment cached query result should be cleared when there are no more active 
readers. It should work as follows:
- Initially RS is created with counter == 1
- If another reader joins, it is CAS from positiive value to value+1;
- When reader finishes, counter is decremented
- Or when remote node reading result leaves topology, counter is decremented
- When counter reaches zero, try CASing it from 0 to -1. If successful - result 
set can be removed from the map

> Implement basic caching of query results
> 
>
> Key: IGNITE-5482
> URL: https://issues.apache.org/jira/browse/IGNITE-5482
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
>  Labels: important
> Fix For: 2.2
>
>
> Sergi suggested that we reuse results of the same queries running 
> simultaneously - i.e. if a query is being executed with the same arguments 
> and flags again and again, there's no need to do actual querying of data, 
> instead we can really run query once while other simultaneous runs will wait 
> for those results.
> This strategy will be implemented on MAP stage of distributed query.



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

[jira] [Created] (IGNITE-5752) Fix stale sequence updates for local partition map

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-5752:
---

 Summary: Fix stale sequence updates for local partition map
 Key: IGNITE-5752
 URL: https://issues.apache.org/jira/browse/IGNITE-5752
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko
Priority: Critical
 Fix For: 2.2


Sometimes cache group start/stop operation leads to stale sequence updates for 
local partition maps during partitions map exchange.

{noformat}
Exception in thread "sys-#17801%database.IgniteDbSnapshotSelfMultiNodeTest0%" 
java.lang.AssertionError
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.update(GridDhtPartitionTopologyImpl.java:1230)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processFullPartitionUpdate(GridCachePartitionExchangeManager.java:1334)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1000(GridCachePartitionExchangeManager.java:125)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$3.onMessage(GridCachePartitionExchangeManager.java:297)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$3.onMessage(GridCachePartitionExchangeManager.java:295)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2243)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2225)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1042)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
[08:51:19,289][ERROR][exchange-worker-#17673%database.IgniteDbSnapshotSelfMultiNodeTest0%][GridDhtPartitionsExchangeFuture]
 Failed to reinitialize local partitions (preloading will be stopped): 
GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=4, 
minorTopVer=11], nodeId=4e129187, evt=DISCOVERY_CUSTOM_EVT]
java.lang.AssertionError: Invalid update sequence [cur=23, new=2]
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap.updateSequence(GridDhtPartitionMap.java:207)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.updateLocal(GridDhtPartitionTopologyImpl.java:1901)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.initPartitions0(GridDhtPartitionTopologyImpl.java:345)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.beforeExchange(GridDhtPartitionTopologyImpl.java:507)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:991)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:632)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1901)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:745){noformat}




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

[jira] [Commented] (IGNITE-5452) Tx with timeout can make node can hang on stop.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-5452:
--

[~VitaliyB]

See my comments in UpSource.
Please, check all you tests are present in TestSuites and run TC tests [1] 
after all issues will be fixed.

[1] 
http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests_Ignite20Tests=pull%2F2279%2Fhead

> Tx with timeout can make node can hang on stop.
> ---
>
> Key: IGNITE-5452
> URL: https://issues.apache.org/jira/browse/IGNITE-5452
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.0
>Reporter: Andrew Mashenkov
>Assignee: Vitaliy Biryukov 
> Fix For: 2.2
>
> Attachments: LockTimeoutFailedOnStop.java
>
>
> PFA repro attached.
> Actually, there are 2 issue.
> 1. GridTimeoutProcessor can't be stopped if TimeoutObject eats 
> InterruptedException. We should handle this correctly.
> 2. TX use TimeoutObjects to be rolled back by timeout.  However, TXs doesn't 
> remove their TimeoutObjects on node stop. 
> Possible, TimeoutObject doesn't removed on TX rollback and this should be 
> investigated.



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

[jira] [Assigned] (IGNITE-5750) Format of uptime for metrics

[Yevgeniy Ignatyev (JIRA)]

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

Yevgeniy Ignatyev reassigned IGNITE-5750:
-

Assignee: Yevgeniy Ignatyev

> Format of uptime for metrics
> 
>
> Key: IGNITE-5750
> URL: https://issues.apache.org/jira/browse/IGNITE-5750
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.0
>Reporter: Alexandr Kuramshin
>Assignee: Yevgeniy Ignatyev
>Priority: Trivial
>  Labels: newbie
> Fix For: 2.1
>
>
> Metrics for local node shows uptime formatted as 00:00:00:000
> But the last colon should be changed to the dot.
> Right format is 00:00:00.000



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

[jira] [Created] (IGNITE-5751) In TcpCommunicationSpi.createTcpClient U.filterReachable waits all addresses to check if they are reachable

[Evgenii Zhuravlev (JIRA)]

Evgenii Zhuravlev created IGNITE-5751:
-

 Summary: In TcpCommunicationSpi.createTcpClient U.filterReachable 
waits all addresses to check if they are reachable
 Key: IGNITE-5751
 URL: https://issues.apache.org/jira/browse/IGNITE-5751
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.9
Reporter: Evgenii Zhuravlev
Priority: Critical


In TcpCommunicationSpi.createTcpClient replace U.filterReachable with filtering 
first reachable address



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

[jira] [Commented] (IGNITE-4648) IgniteInternalTx.prepare() does not wait for async operations to complete

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4648:


[~yzhdanov] I've updated .NET tests to check async operations within 
{{TransactionScope}}. These tests hang or fail in master, but work fine in this 
branch.

> IgniteInternalTx.prepare() does not wait for async operations to complete
> -
>
> Key: IGNITE-4648
> URL: https://issues.apache.org/jira/browse/IGNITE-4648
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7
>Reporter: Pavel Tupitsyn
>Assignee: Ryabov Dmitrii
>Priority: Minor
> Fix For: 2.2
>
>
> {{commit}} and {{rollback}} wait for async operations by calling 
> {{tx.txState().awaitLastFut();}} (see {{GridCacheSharedContext}}).
> There is no such thing in {{IgniteInternalTx.prepare()}} implementations.
> Since {{prepare}} is an internal method, this is not an issue mostly, except 
> for two things:
> * JTA. {{CacheJtaResource}} calls {{prepare()}} explicitly. 
> * .NET {{TransactionScope}} API. Same thing as JTA, basically. 
> {{PlatformTransactions}} call {{prepare()}} as well.
> As a result, if user starts an async operation within JTA transaction and 
> then completes the tx, undefined behavior is possible.



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

[jira] [Created] (IGNITE-5750) Format of uptime for metrics

[Alexandr Kuramshin (JIRA)]

Alexandr Kuramshin created IGNITE-5750:
--

 Summary: Format of uptime for metrics
 Key: IGNITE-5750
 URL: https://issues.apache.org/jira/browse/IGNITE-5750
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.0
Reporter: Alexandr Kuramshin
Priority: Trivial
 Fix For: 2.1


Metrics for local node shows uptime formatted as 00:00:00:000

But the last colon should be changed to the dot.

Right format is 00:00:00.000



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

[jira] [Commented] (IGNITE-2313) Need to add a mode to fail atomic operations within a transaction

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-2313:
--

[~SomeFire], 

Looks good to me.

[~sboikov], 

Please make final check.

> Need to add a mode to fail atomic operations within a transaction
> -
>
> Key: IGNITE-2313
> URL: https://issues.apache.org/jira/browse/IGNITE-2313
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Dmitriy Setrakyan
>Assignee: Ryabov Dmitrii
> Fix For: 2.2
>
>
> Currently atomic operations within a transaction succeed without alarming a 
> user that no transaction really occurs. We should add a mode to fail such 
> operations (such mode should be turned off by default).
> New transaction configuration flag (default is {{false}}):
> {code}TransactionConfiguration.isAllowAtomicUpdatesInTransaction(){code}
> If the flag is violated, we should throw an exception with the following 
> error message: {{Transaction spans operations on atomic cache (consider 
> setting TransactionConfiguration.isAllowAttomicUpdatesInTransaction() flag to 
> true)}}



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

[jira] [Commented] (IGNITE-4648) IgniteInternalTx.prepare() does not wait for async operations to complete

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii commented on IGNITE-4648:


[~yzhdanov], TC tests are in progress (I let you know results when they 
finish), but I though test method for this ticket must have separate "prepare" 
call.

I created separate ticket for test coverage - [IGNITE-5748 Extend JTA test 
coverage|https://issues.apache.org/jira/browse/IGNITE-5748].

> IgniteInternalTx.prepare() does not wait for async operations to complete
> -
>
> Key: IGNITE-4648
> URL: https://issues.apache.org/jira/browse/IGNITE-4648
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7
>Reporter: Pavel Tupitsyn
>Assignee: Ryabov Dmitrii
>Priority: Minor
> Fix For: 2.2
>
>
> {{commit}} and {{rollback}} wait for async operations by calling 
> {{tx.txState().awaitLastFut();}} (see {{GridCacheSharedContext}}).
> There is no such thing in {{IgniteInternalTx.prepare()}} implementations.
> Since {{prepare}} is an internal method, this is not an issue mostly, except 
> for two things:
> * JTA. {{CacheJtaResource}} calls {{prepare()}} explicitly. 
> * .NET {{TransactionScope}} API. Same thing as JTA, basically. 
> {{PlatformTransactions}} call {{prepare()}} as well.
> As a result, if user starts an async operation within JTA transaction and 
> then completes the tx, undefined behavior is possible.



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

[jira] [Commented] (IGNITE-5597) Wrong javadoc in Affinity and AffinityFunction for REPLICATED cache

[Evgenii Zhuravlev (JIRA)]

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

Evgenii Zhuravlev commented on IGNITE-5597:
---

Thanks for contribution!

> Wrong javadoc in Affinity and AffinityFunction for REPLICATED cache
> ---
>
> Key: IGNITE-5597
> URL: https://issues.apache.org/jira/browse/IGNITE-5597
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Evgenii Zhuravlev
>Assignee: Andrei Yakushin
>  Labels: javadoc
> Fix For: 2.2
>
>
> RendezvousAffinityFunction.getPartitions() Javadoc says:
> {code:java}
>  * Note that for fully replicated caches this method should always
>  * return {@code 1}.
> {code}
> but it's not true, it works the same as PARTITIONED cache.
> Affinity.mapKeyToNode(K key) javadoc says:
> {code:java}
>  * 
>  *  For fully replicated caches first node ID returned by {@link 
> AffinityFunction}
>  *  is returned.
>  * 
>  * For partitioned caches, primary node for the given key is 
> returned.
> {code}
> it looks confusing, while REPLICATED cache has primary nodes for keys as 
> PRATITIONED.
> Also,  
> {code:java}
> * Provides affinity information to detect which node is primary and which 
> nodes are
>  * backups for a partitioned cache.
> {code}
> Affinity matter for REPLICATED cache too.



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

[jira] [Commented] (IGNITE-5597) Wrong javadoc in Affinity and AffinityFunction for REPLICATED cache

[Dmitry Karachentsev (JIRA)]

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

Dmitry Karachentsev commented on IGNITE-5597:
-

Merged to master.

> Wrong javadoc in Affinity and AffinityFunction for REPLICATED cache
> ---
>
> Key: IGNITE-5597
> URL: https://issues.apache.org/jira/browse/IGNITE-5597
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Evgenii Zhuravlev
>Assignee: Andrei Yakushin
>  Labels: javadoc
> Fix For: 2.2
>
>
> RendezvousAffinityFunction.getPartitions() Javadoc says:
> {code:java}
>  * Note that for fully replicated caches this method should always
>  * return {@code 1}.
> {code}
> but it's not true, it works the same as PARTITIONED cache.
> Affinity.mapKeyToNode(K key) javadoc says:
> {code:java}
>  * 
>  *  For fully replicated caches first node ID returned by {@link 
> AffinityFunction}
>  *  is returned.
>  * 
>  * For partitioned caches, primary node for the given key is 
> returned.
> {code}
> it looks confusing, while REPLICATED cache has primary nodes for keys as 
> PRATITIONED.
> Also,  
> {code:java}
> * Provides affinity information to detect which node is primary and which 
> nodes are
>  * backups for a partitioned cache.
> {code}
> Affinity matter for REPLICATED cache too.



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

[jira] [Commented] (IGNITE-5749) SQL: add ANY condition support.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-5749:
--

[~sergi.vladykin]
Please, take a look. If it is possible to fix it for collocated data at least.

> SQL: add ANY condition support.
> ---
>
> Key: IGNITE-5749
> URL: https://issues.apache.org/jira/browse/IGNITE-5749
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Andrew Mashenkov
> Fix For: 2.2
>
>
> H2 supports ALL,ANY,SOME (same as ANY) conditions.
> Ignite seems supports ANY condition as well and rewrite it with IN condition.
> But using ALL condition results with a error.
> Seems, we can add support of ALL condition for queries with collocated flag 
> without serious changes in code. 



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

[jira] [Commented] (IGNITE-5749) SQL: add ANY condition support.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-5749:
--

Assume, there is some difficulties to support ALL condition for non-collocated 
data and such queries can be very slow.
Looks like in case of non-collocated data IGNITE-5359 should be done at first.

> SQL: add ANY condition support.
> ---
>
> Key: IGNITE-5749
> URL: https://issues.apache.org/jira/browse/IGNITE-5749
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Andrew Mashenkov
> Fix For: 2.2
>
>
> H2 supports ALL,ANY,SOME (same as ANY) conditions.
> Ignite seems supports ANY condition as well and rewrite it with IN condition.
> But using ALL condition results with a error.
> Seems, we can add support of ALL condition for queries with collocated flag 
> without serious changes in code. 



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

[jira] [Created] (IGNITE-5749) SQL: add ANY condition support.

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-5749:


 Summary: SQL: add ANY condition support.
 Key: IGNITE-5749
 URL: https://issues.apache.org/jira/browse/IGNITE-5749
 Project: Ignite
  Issue Type: Bug
  Components: sql
Reporter: Andrew Mashenkov
 Fix For: 2.2


H2 supports ALL,ANY,SOME (same as ANY) conditions.
Ignite seems supports ANY condition as well and rewrite it with IN condition.
But using ALL condition results with a error.

Seems, we can add support of ALL condition for queries with collocated flag 
without serious changes in code. 




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

[jira] [Commented] (IGNITE-5735) NPE during populated data (CacheQueryDdlExample)

[Alex Volkov (JIRA)]

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

Alex Volkov commented on IGNITE-5735:
-

Works fine on build 3c1749da. No any exceptions on the remote nodes.

> NPE during populated data (CacheQueryDdlExample)
> 
>
> Key: IGNITE-5735
> URL: https://issues.apache.org/jira/browse/IGNITE-5735
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Ilya Suntsov
>Assignee: Vladimir Ozerov
> Fix For: 2.1
>
>
> Steps for reproduce:
> 1. Start 2 nodes with *examples/config/example-ignite.xml*
> 2. Start *CacheQueryDdlExample*
> Result:
> Om example node:
> {noformat}
> [10:19:17]__   
> [10:19:17]   /  _/ ___/ |/ /  _/_  __/ __/ 
> [10:19:17]  _/ // (7 7// /  / / / _/   
> [10:19:17] /___/\___/_/|_/___/ /_/ /___/  
> [10:19:17] 
> [10:19:17] ver. 2.1.2#20170711-sha1:2a2c8030
> [10:19:17] 2017 Copyright(C) Apache Software Foundation
> [10:19:17] 
> [10:19:17] Ignite documentation: http://ignite.apache.org
> [10:19:17] 
> [10:19:17] Quiet mode.
> [10:19:17]   ^-- Logging to file 
> '/Users/gridgain/Downloads/gridgain-enterprise-fabric-8.1.2/work/log/ignite-9ef688f8.log'
> [10:19:17]   ^-- To see **FULL** console log here add -DIGNITE_QUIET=false or 
> "-v" to ignite.{sh|bat}
> [10:19:17] 
> [10:19:17] OS: Mac OS X 10.10.5 x86_64
> [10:19:17] VM information: Java(TM) SE Runtime Environment 1.8.0_45-b14 
> Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 25.45-b02
> [10:19:17] Initial heap size is 256MB (should be no less than 512MB, use 
> -Xms512m -Xmx512m).
> [10:19:17] Configured plugins:
> [10:19:17]   ^-- GridGain 8.1.2#20170711-sha1:ff30520a
> [10:19:17]   ^-- 2017 Copyright(C) GridGain Systems
> [10:19:17] 
> [10:19:17] Message queue limit is set to 0 which may lead to potential OOMEs 
> when running cache operations in FULL_ASYNC or PRIMARY_SYNC modes due to 
> message queues growth on sender and receiver sides.
> [10:19:17] Security status [authentication=off, tls/ssl=off]
> [10:19:18] Rolling updates are disabled. GridGain version update will require 
> full cluster restart. Consider changing 
> 'GridGainConfiguration.rollingUpdatesEnabled' configuration property.
> [2017-07-12 10:19:20,162][ERROR][main][GridEntLicenseProcessor] License 
> violation detected:
>   ^-- Maximum number of nodes (3/2) is exceeded.
> [2017-07-12 10:19:20,162][ERROR][main][GridEntLicenseProcessor] Contact 
> sa...@gridgain.com for further assistance. Make sure to include your license 
> ID: 9D50E008-472D-430F-8B2D-CFB8A3894C0D
> [2017-07-12 10:19:20,163][ERROR][main][GridEntLicenseProcessor] License 
> grace/burst period - left 1 hour.
> [10:19:20] Performance suggestions for grid  (fix if possible)
> [10:19:20] To disable, set -DIGNITE_PERFORMANCE_SUGGESTIONS_DISABLED=true
> [10:19:20]   ^-- Disable grid events (remove 'includeEventTypes' from 
> configuration)
> [10:19:20]   ^-- Enable G1 Garbage Collector (add '-XX:+UseG1GC' to JVM 
> options)
> [10:19:20]   ^-- Specify JVM heap max size (add '-Xmx[g|G|m|M|k|K]' to 
> JVM options)
> [10:19:20]   ^-- Set max direct memory size if getting 'OOME: Direct buffer 
> memory' (add '-XX:MaxDirectMemorySize=[g|G|m|M|k|K]' to JVM options)
> [10:19:20]   ^-- Disable processing of calls to System.gc() (add 
> '-XX:+DisableExplicitGC' to JVM options)
> [10:19:20] Refer to this page for more performance suggestions: 
> https://apacheignite.readme.io/docs/jvm-and-system-tuning
> [10:19:20] 
> [10:19:20] To start Console Management & Monitoring run 
> ignitevisorcmd.{sh|bat}
> [10:19:20] 
> [10:19:20] Ignite node started OK (id=9ef688f8)
> [10:19:20] Topology snapshot [ver=3, servers=3, clients=0, CPUs=8, heap=5.6GB]
> >>> Cache query DDL example started.
> >>> Created database objects.
> >>> Populated data.
> {noformat}
> On remote nodes;
> {noformat}
> SEVERE: Failed to read message [msg=GridIoMessage [plc=0, topic=null, 
> topicOrd=-1, ordered=false, timeout=0, skipOnTimeout=false, msg=null], 
> buf=java.nio.DirectByteBuffer[pos=4 lim=10001 cap=32768], 
> reader=DirectMessageReader [state=DirectMessageState [pos=0, stack=[StateItem 
> [stream=DirectByteBufferStreamImplV2 [baseOff=140343292566528, arrOff=-1, 
> tmpArrOff=0, tmpArrBytes=0, msgTypeDone=false, msg=null, mapIt=null, it=null, 
> arrPos=-1, keyDone=false, readSize=-1, readItems=0, prim=0, primShift=0, 
> uuidState=0, uuidMost=0, uuidLeast=0, uuidLocId=0, lastFinished=true], 
> state=0], null, null, null, null, null, null, null, null, null]], 
> lastRead=false], ses=GridSelectorNioSessionImpl [worker=DirectNioClientWorker 
> [super=AbstractNioClientWorker [idx=2, bytesRcvd=117764, bytesSent=5240, 
> bytesRcvd0=20086, bytesSent0=56, select=true, super=GridWorker 
> 

[jira] [Assigned] (IGNITE-5648) NOT NULL constraint support for CREATE TABLE operator

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov reassigned IGNITE-5648:
--

Assignee: Sergey Kalashnikov

> NOT NULL constraint support for CREATE TABLE operator
> -
>
> Key: IGNITE-5648
> URL: https://issues.apache.org/jira/browse/IGNITE-5648
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Sergey Kalashnikov
> Fix For: 2.3
>
>
> This is an umbrella ticket intended to aggregate all the activities related 
> to {{NOT NULL}} constraint support for {{CREATE TABLE}} commands.
> {code}
> CREATE TABLE legs(legid INT NOT NULL);
> {code}
> Ignite must prevent setting {{legid}} to {{null}} value.
> The feature has to be supported for:
> * ODBC and JDBC drivers.
> * Native APIs (Java, .NET, C++)



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

[jira] [Created] (IGNITE-5748) Extend JTA test coverage

[Ryabov Dmitrii (JIRA)]

Ryabov Dmitrii created IGNITE-5748:
--

 Summary: Extend JTA test coverage
 Key: IGNITE-5748
 URL: https://issues.apache.org/jira/browse/IGNITE-5748
 Project: Ignite
  Issue Type: Test
Reporter: Ryabov Dmitrii
Priority: Minor


The goal is to have every method of CacheJtaResource called inside tests. 
Please add tests that will enlist fake XA resources to transaction (to the one 
enlisted for proper cache tx). You can use this snippet:

{code:java}
jotm.getTransactionManager().getTransaction().enlistResource(new XAResource() 
{.. });
{code}

We need to do this because with only one resource transaction manager calls 
commit() without calling prepare(). Therefore, a lot of code is not covered 
with tests. Please add them and add invocations counters and asserts for them.

[Task 
source.|https://issues.apache.org/jira/browse/IGNITE-4648?focusedCommentId=16085532=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16085532]



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

[jira] [Commented] (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:comment-tabpanel=16085618#comment-16085618
 ] 

Vladimir Ozerov commented on IGNITE-5571:
-

[~al.psc], my comments:
1) {{AffinityTopologyVersion}} is never passed from DML processor. Looks like a 
bug to me. IMO, we should not pass it to {{querySqlFields}} at all. Instead, we 
should ask {{GridQueryProcessor}} for backup filter when we understand it is 
needed. Let's remove {{AffinityTopologyVersion}} argument.
2) Please no {{T*}} classes. This is antipattern. Normal value class should be 
created instead.
3) {{IgniteH2Indexing:1376}} - incorrect {{distributedJoins}} is set here. I do 
not know whether it has any adverse affects, but let's make this code cleaner. 
We do not need {{GridH2QueryContext}} at this point. Let's set only after we 
calculated final value for {{distributedJoins}} flag.

> 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.2
>
>
> 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] [Assigned] (IGNITE-5747) GridCommonAbstractTest.startGridsMultiThreaded works very slowly if persistence is enabled

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev reassigned IGNITE-5747:
-

Assignee: Alexey Goncharuk

Patch is trivial.
https://github.com/apache/ignite/pull/2294

> GridCommonAbstractTest.startGridsMultiThreaded works very slowly if 
> persistence is enabled
> --
>
> Key: IGNITE-5747
> URL: https://issues.apache.org/jira/browse/IGNITE-5747
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Eduard Shangareev
>Assignee: Alexey Goncharuk
> Fix For: 2.1
>
>
> GridCommonAbstractTest.startGridsMultiThreaded takes 2 minutes for 4 nodes if 
> persistence is enabled because we wait for topology update in affinity, but 
> it's not working while cluster is not active.



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

[jira] [Updated] (IGNITE-5747) GridCommonAbstractTest.startGridsMultiThreaded works very slowly if persistence is enabled

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev updated IGNITE-5747:
--
Summary: GridCommonAbstractTest.startGridsMultiThreaded works very slowly 
if persistence is enabled  (was: GridCommonAbstractTest.startGridsMultiThreaded 
works very slowly if persistence enabled)

> GridCommonAbstractTest.startGridsMultiThreaded works very slowly if 
> persistence is enabled
> --
>
> Key: IGNITE-5747
> URL: https://issues.apache.org/jira/browse/IGNITE-5747
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Eduard Shangareev
> Fix For: 2.1
>
>
> GridCommonAbstractTest.startGridsMultiThreaded takes 2 minutes for 4 nodes if 
> persistence is enabled because we wait for topology update in affinity, but 
> it's not working while cluster is not active.



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

[jira] [Created] (IGNITE-5747) GridCommonAbstractTest.startGridsMultiThreaded works very slowly if persistence enabled

[Eduard Shangareev (JIRA)]

Eduard Shangareev created IGNITE-5747:
-

 Summary: GridCommonAbstractTest.startGridsMultiThreaded works very 
slowly if persistence enabled
 Key: IGNITE-5747
 URL: https://issues.apache.org/jira/browse/IGNITE-5747
 Project: Ignite
  Issue Type: Bug
  Components: general
Reporter: Eduard Shangareev
 Fix For: 2.1


GridCommonAbstractTest.startGridsMultiThreaded takes 2 minutes for 4 nodes if 
persistence is enabled because we wait for topology update in affinity, but 
it's not working while cluster is not active.



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

[jira] [Commented] (IGNITE-5729) IgniteCacheProxy instances from "with..." methods are not reusable

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5729:


GitHub user Jokser opened a pull request:

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

IGNITE-5729 Reworked and cleaned up IgniteCacheProxy



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

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

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

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


commit 707c454ad9c3b4132e2d0a20d15dc1eb2ed295b0
Author: Alexey Goncharuk 
Date:   2017-07-12T07:53:46Z

Corrected fix for REST processor wrt authentication

commit f3828261b30c12d5aa181914033afe46c787f87e
Author: Alexey Kuznetsov 
Date:   2017-07-12T07:57:50Z

IGNITE-5639 Added duration for empty result set.

commit 5859b192ba28d53e1bccb01ce3005821e26b5347
Author: devozerov 
Date:   2017-07-12T09:46:42Z

AI 2.1 release notes.

commit 8afdc7baae73ecba67e0735baa97d03f2c4fc715
Author: devozerov 
Date:   2017-07-12T10:51:43Z

Removed CacheBinaryAutoStoreExample and relevant bean "h2-example-db" from 
example-default.xml because example duplicated existing CacheAutoStoreExample.

commit c6ee085b8a1321ce7fa15f8adf74fa7a01f7a445
Author: Dmitriy Govorukhin 
Date:   2017-07-12T11:22:03Z

Fixed page acquire during checkpoint

commit 0cb6ac06a43ac72c707b29d7216bd4cb711a
Author: Oleg Ostanin 
Date:   2017-07-12T12:57:40Z

IGNITE-5740 - Added transaction load timing benchmark

commit 3787181310597b7a6e633e745ba08209abd038a9
Author: Alexey Goncharuk 
Date:   2017-07-12T15:28:57Z

More verbose logging

commit 21964fb5f6fb6fee891283332202cbc9ed5ac3f3
Author: Dmitry Pavlov 
Date:   2017-07-12T15:59:10Z

Optimized snapshot progress tracking

commit 689b1b6e9c3e723cf394c7ff2427097b21d96ce3
Author: Alexey Goncharuk 
Date:   2017-07-13T07:12:01Z

IGNITE-5479 - Cleanup public API for PersistentStoreConfiguration

commit 3c1749da82e663500e45a34369eac48dbbc62bdc
Author: Alexander Paschenko 
Date:   2017-07-13T08:25:55Z

IGNITE-5744 Ignore non user caches when automatically choosing a queryable 
cache inside JDBC driver

commit f73a6eff4232c60e0eb16f0cbefdd57a3eed2386
Author: Pavel Kovalenko 
Date:   2017-07-13T11:14:58Z

IGNITE-5729 Split IgniteCacheProxy. Fixed unhandled CacheStoppedException 
during exchange init.

commit d4f489b4a0d38c919ab0db28b255a904fa39d5cc
Author: Pavel Kovalenko 
Date:   2017-07-13T11:19:05Z

Merge branch 'ignite-2.1.2' into ignite-5729

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/IgniteCacheProxy.java




> IgniteCacheProxy instances from "with..." methods are not reusable
> --
>
> Key: IGNITE-5729
> URL: https://issues.apache.org/jira/browse/IGNITE-5729
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
> Fix For: 2.2
>
>
> On cache restart all IgniteCacheProxy instances must be reset in order to 
> reuse them.
> But bunch of methods in IgniteCache interface including withKeepBinary create 
> new instances of proxy for each call and these instances are not reset on 
> cache restart. 
> E.g. it leads to CacheStoppedException when reusing them after restoring from 
> snapshot.



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

[jira] [Commented] (IGNITE-4756) Print info about partition distribution to log

[Vadim Opolski (JIRA)]

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

Vadim Opolski commented on IGNITE-4756:
---

[~tledkov-gridgain] [~avinogradov] Added local node filtering in calculating 
statistics.

> Print info about partition distribution to log 
> ---
>
> Key: IGNITE-4756
> URL: https://issues.apache.org/jira/browse/IGNITE-4756
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Reporter: Taras Ledkov
>Assignee: Vadim Opolski
>Priority: Minor
>  Labels: newbie
> Fix For: 2.2
>
>
> Summarize discussions:
> Add log message in case partitions distribution is not close to even 
> distribution:
> # Add system property IGNITE_PART_DISTRIBUTION_WARN_THRESHOLD with default 
> value 0.1 to print warn message only when nodes count differs more then 
> threshold;
> # The statistic is calculated and printed only for the local node;
> # Statistic is placed at the {{GridAffinityAssignmentCache#calculate}} and 
> calculated for new {{idealAssignment}}.
> # Message format is
> {noformat}
> Local node affinity assignment distribution is not ideal [cache=, 
> expectedPrimary=, 
> exectedBackups=, 
> primary=, backups=].
> {noformat}
> e.g. for cache with name "test", 2 backups, 4 partition, 3 nodes:
> {noformat}
> Local node affinity assignment distribution is not ideal [cache=test, 
> expectedPrimary=1.33 (33.3%), exectedBackups=2.66 (66.66%), primary=1 (25%), 
> backups=3(75%)].
> {noformat}



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

[jira] [Commented] (IGNITE-4648) IgniteInternalTx.prepare() does not wait for async operations to complete

[Yakov Zhdanov (JIRA)]

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

Yakov Zhdanov commented on IGNITE-4648:
---

[~SomeFire] [~ptupitsyn]

Guys, I have pushed my changes to origin/ignite-4648

Dmitry, please review my changes and rerun TC for them. Please let us know 
about TC results here. 

I would also ask you to extend JTA test coverage (you can file in another 
ticket). The goal is to have every method of CacheJtaResource called  inside 
your tests. Please add tests that will enlist fake XA resources to transaction 
(to the one enlisted for proper cache tx). You can use this snippet:
{noformat}
jotm.getTransactionManager().getTransaction().enlistResource(new XAResource() 
{.. });
{noformat}

We need to do this because with only one resource transaction manager calls 
commit() without calling prepare(). Therefore, a lot of code is not covered 
with tests. Please add them and add invocations counters and asserts for them.

Pavel, please see my changes to CacheJtaResource and change 
PlatformTransactions accordingly. I want you to add more tests for platform tx 
that would at least check async operations that should have been failed before 
changes to this ticket.

> IgniteInternalTx.prepare() does not wait for async operations to complete
> -
>
> Key: IGNITE-4648
> URL: https://issues.apache.org/jira/browse/IGNITE-4648
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7
>Reporter: Pavel Tupitsyn
>Assignee: Ryabov Dmitrii
>Priority: Minor
> Fix For: 2.2
>
>
> {{commit}} and {{rollback}} wait for async operations by calling 
> {{tx.txState().awaitLastFut();}} (see {{GridCacheSharedContext}}).
> There is no such thing in {{IgniteInternalTx.prepare()}} implementations.
> Since {{prepare}} is an internal method, this is not an issue mostly, except 
> for two things:
> * JTA. {{CacheJtaResource}} calls {{prepare()}} explicitly. 
> * .NET {{TransactionScope}} API. Same thing as JTA, basically. 
> {{PlatformTransactions}} call {{prepare()}} as well.
> As a result, if user starts an async operation within JTA transaction and 
> then completes the tx, undefined behavior is possible.



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

[jira] [Closed] (IGNITE-5538) NPE (PersistentStoreExample)

[Ilya Suntsov (JIRA)]

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

Ilya Suntsov closed IGNITE-5538.


Fix confirmed

> NPE (PersistentStoreExample)
> 
>
> Key: IGNITE-5538
> URL: https://issues.apache.org/jira/browse/IGNITE-5538
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Ilya Suntsov
>Assignee: Alexey Goncharuk
> Fix For: 2.1
>
> Attachments: PersistentStoreExampleNode.txt, 
> PersistentStoreExample.txt
>
>
> Steps to reproduce:
> 1. Start *PersistentStoreExampleNodeStartup*
> 2. Start *PersistentStoreExample* (UPLOAD=true)
> Result:
> 1. Topology snapshot [ver=2, servers=1, clients=1, CPUs=8, heap=7.1GB]
> 2. Started preloading
> 3. On ExampleNode got exception:
> {noformat}
> [2017-06-19 13:11:28,545][WARN 
> ][grid-nio-worker-tcp-comm-3-#20%null%][TcpCommunicationSpi] Failed to 
> process selector key (will close): GridSelectorNioSessionImpl 
> [worker=DirectNioClientWorker [super=AbstractNioClientWorker [idx=3, 
> bytesRcvd=2052, bytesSent=252, bytesRcvd0=228, bytesSent0=28, select=true, 
> super=GridWorker [name=grid-nio-worker-tcp-comm-3, igniteInstanceName=null, 
> finished=false, hashCode=1279096191, interrupted=false, 
> runner=grid-nio-worker-tcp-comm-3-#20%null%]]], 
> writeBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768], 
> readBuf=java.nio.DirectByteBuffer[pos=4 lim=186 cap=32768], 
> inRecovery=GridNioRecoveryDescriptor [acked=103, resendCnt=0, rcvCnt=104, 
> sentCnt=103, reserved=true, lastAck=96, nodeLeft=false, node=TcpDiscoveryNode 
> [id=be66eae2-3986-4772-b02b-bf2813370a15, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
> 172.25.4.115, 172.25.4.116, 2001:db8:85a3:0:0:8a2e:370:7334], 
> sockAddrs=[/0:0:0:0:0:0:0:1:0, /127.0.0.1:0, /172.25.4.115:0, 
> /172.25.4.116:0, /2001:db8:85a3:0:0:8a2e:370:7334:0], discPort=0, order=2, 
> intOrder=2, lastExchangeTime=1497867042970, loc=false, 
> ver=2.1.1#20170618-sha1:09ce29e0, isClient=true], connected=true, 
> connectCnt=1, queueLimit=4096, reserveCnt=35, pairedConnections=false], 
> outRecovery=GridNioRecoveryDescriptor [acked=103, resendCnt=0, rcvCnt=104, 
> sentCnt=103, reserved=true, lastAck=96, nodeLeft=false, node=TcpDiscoveryNode 
> [id=be66eae2-3986-4772-b02b-bf2813370a15, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
> 172.25.4.115, 172.25.4.116, 2001:db8:85a3:0:0:8a2e:370:7334], 
> sockAddrs=[/0:0:0:0:0:0:0:1:0, /127.0.0.1:0, /172.25.4.115:0, 
> /172.25.4.116:0, /2001:db8:85a3:0:0:8a2e:370:7334:0], discPort=0, order=2, 
> intOrder=2, lastExchangeTime=1497867042970, loc=false, 
> ver=2.1.1#20170618-sha1:09ce29e0, isClient=true], connected=true, 
> connectCnt=1, queueLimit=4096, reserveCnt=35, pairedConnections=false], 
> super=GridNioSessionImpl [locAddr=/0:0:0:0:0:0:0:1:47100, 
> rmtAddr=/0:0:0:0:0:0:0:1:60813, createTime=1497867087529, closeTime=0, 
> bytesSent=28, bytesRcvd=228, bytesSent0=28, bytesRcvd0=228, 
> sndSchedTime=1497867087529, lastSndTime=1497867087529, 
> lastRcvTime=1497867087541, readsPaused=false, 
> filterChain=FilterChain[filters=[GridNioCodecFilter 
> [parser=o.a.i.i.util.nio.GridDirectParser@7a94a8f6, directMode=true], 
> GridConnectionBytesVerifyFilter], accepted=true]]
> [2017-06-19 
> 13:11:28,545][ERROR][grid-nio-worker-tcp-comm-3-#20%null%][TcpCommunicationSpi]
>  Closing NIO session because of unhandled exception.
> class org.apache.ignite.internal.util.nio.GridNioException: null
>   at 
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2199)
>   at 
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:1968)
>   at 
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1669)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.ignite.internal.managers.communication.GridIoMessageFactory.create(GridIoMessageFactory.java:879)
>   at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$9.create(TcpCommunicationSpi.java:2134)
>   at 
> org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.readMessage(DirectByteBufferStreamImplV2.java:1154)
>   at 
> org.apache.ignite.internal.direct.DirectMessageReader.readMessage(DirectMessageReader.java:311)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoMessage.readFrom(GridIoMessage.java:261)
>   at 
> org.apache.ignite.internal.util.nio.GridDirectParser.decode(GridDirectParser.java:90)
>   at 
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:114)
>   at 

[jira] [Commented] (IGNITE-5706) Redis FLUSHDB command support

[Roman Shtykh (JIRA)]

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

Roman Shtykh commented on IGNITE-5706:
--

Hi [~anovikov],

Yes, let's have {{FLUSHALL}} too. Do you think I can add {{CACHE_CLEAR_ALL}} 
command in REST implementation and have a ComputeJob over nodes? It might be 
useful for over-http-commands too.

> Redis FLUSHDB command support
> -
>
> Key: IGNITE-5706
> URL: https://issues.apache.org/jira/browse/IGNITE-5706
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> https://redis.io/commands/flushdb



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

[jira] [Commented] (IGNITE-5649) REST API, metadata command always returns list of cache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5649:


GitHub user shroman opened a pull request:

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

IGNITE-5649: Get meta for the specified cache.



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

$ git pull https://github.com/shroman/ignite IGNITE-5649

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

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


commit e22e658c862baeaea733644c4dc027cf02c9f748
Author: shroman 
Date:   2017-07-03T08:58:26Z

IGNITE-5649: Get meta for the specified cache.

commit d7f1503a31ba77468a8e193d0a14e8af69db3683
Author: shroman 
Date:   2017-07-03T09:40:16Z

IGNITE-5649: Get meta for the specified cache. Tests.

commit d672623488f5e67f3bcb9e3bb559b2b79fe58a5f
Author: shroman 
Date:   2017-07-12T04:03:57Z

IGNITE-5649: Get meta for the specified cache.

commit c8315be9116e2339385337e7bd4bc84ea2e61be0
Author: shroman 
Date:   2017-07-13T10:24:55Z

IGNITE-5649: Get meta for the specified cache.

commit e8669cfd842a271878ee8d620742ecc12e44
Author: shroman 
Date:   2017-07-13T10:29:46Z

IGNITE-5649: Get meta for the specified cache. Formatted.




> REST API, metadata command always returns list of cache
> ---
>
> Key: IGNITE-5649
> URL: https://issues.apache.org/jira/browse/IGNITE-5649
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Aleksandr
>Assignee: Roman Shtykh
>
> How to reproduce:
> 1) start Ignite server with example config with Person and Organization.
> 2) run:
> curl http://localhost:8080/ignite?cmd=metadata=Person
> curl http://localhost:8080/ignite?cmd=metadata=Organization
> curl http://localhost:8080/ignite?cmd=metadata=blablabla
> Ignite always returns list of cache instead of information about selected 
> cache or error



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

[jira] [Updated] (IGNITE-5330) .NET: Peer assembly loading documentation

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-5330:
---
Description: 
Document peer assembly loading on https://apacheignite-net.readme.io/

Update existing docs about {{-assembly}} switch, etc.

  was:Document peer assembly loading on https://apacheignite-net.readme.io/


> .NET: Peer assembly loading documentation
> -
>
> Key: IGNITE-5330
> URL: https://issues.apache.org/jira/browse/IGNITE-5330
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.1
>
>
> Document peer assembly loading on https://apacheignite-net.readme.io/
> Update existing docs about {{-assembly}} switch, etc.



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

[jira] [Commented] (IGNITE-5330) .NET: Peer assembly loading documentation

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5330:


See https://apacheignite.readme.io/docs/zero-deployment

> .NET: Peer assembly loading documentation
> -
>
> Key: IGNITE-5330
> URL: https://issues.apache.org/jira/browse/IGNITE-5330
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.1
>
>
> Document peer assembly loading on https://apacheignite-net.readme.io/



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

[jira] [Commented] (IGNITE-5682) GridCacheRabalancingDelayedPartitionMapExchangeSelfTest fails

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-5682:


[~agoncharuk], could you please review my changes?

https://github.com/apache/ignite/pull/2274
http://ci.ignite.apache.org/viewLog.html?buildId=721846=buildResultsDiv=Ignite20Tests_RunAll


> GridCacheRabalancingDelayedPartitionMapExchangeSelfTest fails
> -
>
> Key: IGNITE-5682
> URL: https://issues.apache.org/jira/browse/IGNITE-5682
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Vladimir Ozerov
>Assignee: Dmitriy Pavlov
>  Labels: test-fail
> Fix For: 2.2
>
> Attachments: ignite-5682.dump.txt
>
>
> This appears to be a regression introduced during persistent store migration. 
> {code}
> class org.apache.ignite.IgniteException: Timeout of waiting for topology map 
> update 
> [igniteInstanceName=rebalancing.GridCacheRabalancingDelayedPartitionMapExchangeSelfTest1,
>  cache=default, cacheId=1544803905, topVer=AffinityTopologyVersion 
> [topVer=10, minorTopVer=0], p=0, readVer=AffinityTopologyVersion [topVer=10, 
> minorTopVer=0], locNode=TcpDiscoveryNode 
> [id=c53cc66c-05ea-4441-825c-23d99ef1, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47501], discPort=47501, order=2, intOrder=2, 
> lastExchangeTime=1499156862204, loc=true, ver=2.1.0#19700101-sha1:, 
> isClient=false]]
>   at 
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:698)
>   at 
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:532)
>   at 
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:517)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.rebalancing.GridCacheRabalancingDelayedPartitionMapExchangeSelfTest.test(GridCacheRabalancingDelayedPartitionMapExchangeSelfTest.java:154)
>   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:1997)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1912)
>   at java.lang.Thread.run(Thread.java:745)
> {code}



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

[jira] [Commented] (IGNITE-5712) Context switching for optimistic transactions

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-5712:
--

[~agoncharuk] Yeah, it was fixed yesterday. Assertion was moved to 
TransactionProxyImpl.enter() so only executions by user thread is checked for 
thread id. No internal executions is checked.

> Context switching for optimistic transactions
> -
>
> Key: IGNITE-5712
> URL: https://issues.apache.org/jira/browse/IGNITE-5712
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>
> Implement context switching between threads for optimistic transactions
> http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests_Ignite20Tests=pull%2F2257%2Fhead



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

[jira] [Commented] (IGNITE-5683) Web Console: missing fully qualified name for generated indexed types on Models Screen

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-5683:


Tested.

> Web Console: missing fully qualified name for generated indexed types on 
> Models Screen
> --
>
> Key: IGNITE-5683
> URL: https://issues.apache.org/jira/browse/IGNITE-5683
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
> Fix For: 2.1
>
>
> https://stackoverflow.com/questions/44468342/automatic-persistence-unable-to-bring-up-cache-with-web-console-generated-mode



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

[jira] [Closed] (IGNITE-5683) Web Console: missing fully qualified name for generated indexed types on Models Screen

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov closed IGNITE-5683.
--

> Web Console: missing fully qualified name for generated indexed types on 
> Models Screen
> --
>
> Key: IGNITE-5683
> URL: https://issues.apache.org/jira/browse/IGNITE-5683
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
> Fix For: 2.1
>
>
> https://stackoverflow.com/questions/44468342/automatic-persistence-unable-to-bring-up-cache-with-web-console-generated-mode



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

[jira] [Closed] (IGNITE-5639) Web Console: Need to printout time taken evenif result set is empty.

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov closed IGNITE-5639.
--

> Web Console: Need to printout time taken evenif result set is empty.
> 
>
> Key: IGNITE-5639
> URL: https://issues.apache.org/jira/browse/IGNITE-5639
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
> Fix For: 2.1
>
>




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

[jira] [Closed] (IGNITE-5726) Duplicate dependencies in POM

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov closed IGNITE-5726.
--

> Duplicate dependencies in POM
> -
>
> Key: IGNITE-5726
> URL: https://issues.apache.org/jira/browse/IGNITE-5726
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
> Fix For: 2.1
>
> Attachments: screenshot-1.png
>
>
> Import models from database
> Look at POM on Summary page



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

[jira] [Commented] (IGNITE-5726) Duplicate dependencies in POM

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-5726:


Tested.

> Duplicate dependencies in POM
> -
>
> Key: IGNITE-5726
> URL: https://issues.apache.org/jira/browse/IGNITE-5726
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
> Fix For: 2.1
>
> Attachments: screenshot-1.png
>
>
> Import models from database
> Look at POM on Summary page



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

[jira] [Assigned] (IGNITE-5735) NPE during populated data (CacheQueryDdlExample)

[Ilya Suntsov (JIRA)]

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

Ilya Suntsov reassigned IGNITE-5735:


Assignee: Vladimir Ozerov  (was: Ilya Suntsov)

> NPE during populated data (CacheQueryDdlExample)
> 
>
> Key: IGNITE-5735
> URL: https://issues.apache.org/jira/browse/IGNITE-5735
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Ilya Suntsov
>Assignee: Vladimir Ozerov
> Fix For: 2.1
>
>
> Steps for reproduce:
> 1. Start 2 nodes with *examples/config/example-ignite.xml*
> 2. Start *CacheQueryDdlExample*
> Result:
> Om example node:
> {noformat}
> [10:19:17]__   
> [10:19:17]   /  _/ ___/ |/ /  _/_  __/ __/ 
> [10:19:17]  _/ // (7 7// /  / / / _/   
> [10:19:17] /___/\___/_/|_/___/ /_/ /___/  
> [10:19:17] 
> [10:19:17] ver. 2.1.2#20170711-sha1:2a2c8030
> [10:19:17] 2017 Copyright(C) Apache Software Foundation
> [10:19:17] 
> [10:19:17] Ignite documentation: http://ignite.apache.org
> [10:19:17] 
> [10:19:17] Quiet mode.
> [10:19:17]   ^-- Logging to file 
> '/Users/gridgain/Downloads/gridgain-enterprise-fabric-8.1.2/work/log/ignite-9ef688f8.log'
> [10:19:17]   ^-- To see **FULL** console log here add -DIGNITE_QUIET=false or 
> "-v" to ignite.{sh|bat}
> [10:19:17] 
> [10:19:17] OS: Mac OS X 10.10.5 x86_64
> [10:19:17] VM information: Java(TM) SE Runtime Environment 1.8.0_45-b14 
> Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 25.45-b02
> [10:19:17] Initial heap size is 256MB (should be no less than 512MB, use 
> -Xms512m -Xmx512m).
> [10:19:17] Configured plugins:
> [10:19:17]   ^-- GridGain 8.1.2#20170711-sha1:ff30520a
> [10:19:17]   ^-- 2017 Copyright(C) GridGain Systems
> [10:19:17] 
> [10:19:17] Message queue limit is set to 0 which may lead to potential OOMEs 
> when running cache operations in FULL_ASYNC or PRIMARY_SYNC modes due to 
> message queues growth on sender and receiver sides.
> [10:19:17] Security status [authentication=off, tls/ssl=off]
> [10:19:18] Rolling updates are disabled. GridGain version update will require 
> full cluster restart. Consider changing 
> 'GridGainConfiguration.rollingUpdatesEnabled' configuration property.
> [2017-07-12 10:19:20,162][ERROR][main][GridEntLicenseProcessor] License 
> violation detected:
>   ^-- Maximum number of nodes (3/2) is exceeded.
> [2017-07-12 10:19:20,162][ERROR][main][GridEntLicenseProcessor] Contact 
> sa...@gridgain.com for further assistance. Make sure to include your license 
> ID: 9D50E008-472D-430F-8B2D-CFB8A3894C0D
> [2017-07-12 10:19:20,163][ERROR][main][GridEntLicenseProcessor] License 
> grace/burst period - left 1 hour.
> [10:19:20] Performance suggestions for grid  (fix if possible)
> [10:19:20] To disable, set -DIGNITE_PERFORMANCE_SUGGESTIONS_DISABLED=true
> [10:19:20]   ^-- Disable grid events (remove 'includeEventTypes' from 
> configuration)
> [10:19:20]   ^-- Enable G1 Garbage Collector (add '-XX:+UseG1GC' to JVM 
> options)
> [10:19:20]   ^-- Specify JVM heap max size (add '-Xmx[g|G|m|M|k|K]' to 
> JVM options)
> [10:19:20]   ^-- Set max direct memory size if getting 'OOME: Direct buffer 
> memory' (add '-XX:MaxDirectMemorySize=[g|G|m|M|k|K]' to JVM options)
> [10:19:20]   ^-- Disable processing of calls to System.gc() (add 
> '-XX:+DisableExplicitGC' to JVM options)
> [10:19:20] Refer to this page for more performance suggestions: 
> https://apacheignite.readme.io/docs/jvm-and-system-tuning
> [10:19:20] 
> [10:19:20] To start Console Management & Monitoring run 
> ignitevisorcmd.{sh|bat}
> [10:19:20] 
> [10:19:20] Ignite node started OK (id=9ef688f8)
> [10:19:20] Topology snapshot [ver=3, servers=3, clients=0, CPUs=8, heap=5.6GB]
> >>> Cache query DDL example started.
> >>> Created database objects.
> >>> Populated data.
> {noformat}
> On remote nodes;
> {noformat}
> SEVERE: Failed to read message [msg=GridIoMessage [plc=0, topic=null, 
> topicOrd=-1, ordered=false, timeout=0, skipOnTimeout=false, msg=null], 
> buf=java.nio.DirectByteBuffer[pos=4 lim=10001 cap=32768], 
> reader=DirectMessageReader [state=DirectMessageState [pos=0, stack=[StateItem 
> [stream=DirectByteBufferStreamImplV2 [baseOff=140343292566528, arrOff=-1, 
> tmpArrOff=0, tmpArrBytes=0, msgTypeDone=false, msg=null, mapIt=null, it=null, 
> arrPos=-1, keyDone=false, readSize=-1, readItems=0, prim=0, primShift=0, 
> uuidState=0, uuidMost=0, uuidLeast=0, uuidLocId=0, lastFinished=true], 
> state=0], null, null, null, null, null, null, null, null, null]], 
> lastRead=false], ses=GridSelectorNioSessionImpl [worker=DirectNioClientWorker 
> [super=AbstractNioClientWorker [idx=2, bytesRcvd=117764, bytesSent=5240, 
> bytesRcvd0=20086, bytesSent0=56, select=true, super=GridWorker 
> [name=grid-nio-worker-tcp-comm-2, 

[jira] [Commented] (IGNITE-5452) Tx with timeout can make node can hang on stop.

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov  commented on IGNITE-5452:
---

[~amashenkov],
Done.

> Tx with timeout can make node can hang on stop.
> ---
>
> Key: IGNITE-5452
> URL: https://issues.apache.org/jira/browse/IGNITE-5452
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.0
>Reporter: Andrew Mashenkov
>Assignee: Vitaliy Biryukov 
> Fix For: 2.2
>
> Attachments: LockTimeoutFailedOnStop.java
>
>
> PFA repro attached.
> Actually, there are 2 issue.
> 1. GridTimeoutProcessor can't be stopped if TimeoutObject eats 
> InterruptedException. We should handle this correctly.
> 2. TX use TimeoutObjects to be rolled back by timeout.  However, TXs doesn't 
> remove their TimeoutObjects on node stop. 
> Possible, TimeoutObject doesn't removed on TX rollback and this should be 
> investigated.



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

[jira] [Commented] (IGNITE-5706) Redis FLUSHDB command support

[Andrey Novikov (JIRA)]

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

Andrey Novikov commented on IGNITE-5706:


Hi [~roman_s],

Should we also support FLUSHALL command (https://redis.io/commands/flushall) ?
Possibly we should rename {{GridRedisFlushDbCommandHandler}} to 
{{GridRedisFlushCommandHandler}}

Everything else looks good to me

> Redis FLUSHDB command support
> -
>
> Key: IGNITE-5706
> URL: https://issues.apache.org/jira/browse/IGNITE-5706
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> https://redis.io/commands/flushdb



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

[jira] [Updated] (IGNITE-5746) Node mustn't start if memory policy that set in cache is not configured

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-5746:
---
Summary: Node mustn't start if memory policy that set in cache is not 
configured  (was: Node mustn't start if memory policy is not configured)

> Node mustn't start if memory policy that set in cache is not configured
> ---
>
> Key: IGNITE-5746
> URL: https://issues.apache.org/jira/browse/IGNITE-5746
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>
> I faced with NPE in case if memory policy that set in cache is not configured
> {code}
> [11:27:30,979][SEVERE][srvc-deploy-#46%tester%][GridServiceProcessor] Failed 
> to do service reassignment (will retry): Test service: Key affinity singleton
> class org.apache.ignite.IgniteCheckedException: Failed to get affinity 
> mapping from node: TcpDiscoveryNode [id=0882b08d-21e8-4fd1-add0-91c48fc8a15a, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, 
> intOrder=1, lastExchangeTime=1499919956746, loc=true, 
> ver=2.1.2#20170712-sha1:0cb6ac06, isClient=false]
> at 
> org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.affinityCache(GridAffinityProcessor.java:476)
> at 
> org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.keysToNodes(GridAffinityProcessor.java:347)
> at 
> org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.mapKeyToNode(GridAffinityProcessor.java:259)
> at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.reassign(GridServiceProcessor.java:974)
> at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.onDeployment(GridServiceProcessor.java:1484)
> at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.processDeployment(GridServiceProcessor.java:1437)
> at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.onSystemCacheUpdated(GridServiceProcessor.java:1398)
> at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.access$300(GridServiceProcessor.java:119)
> at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor$ServiceEntriesListener$1.run0(GridServiceProcessor.java:1374)
> at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor$DepRunnable.run(GridServiceProcessor.java:1806)
> 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: null
> at 
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7229)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:258)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:170)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:139)
> at 
> org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.affinityInfoFromNode(GridAffinityProcessor.java:501)
> at 
> org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.affinityCache(GridAffinityProcessor.java:459)
> ... 12 more
> Caused by: java.lang.NullPointerException
> at 
> org.apache.ignite.internal.processors.affinity.GridAffinityUtils$AffinityJob.call(GridAffinityUtils.java:175)
> at 
> org.apache.ignite.internal.processors.affinity.GridAffinityUtils$AffinityJob.call(GridAffinityUtils.java:130)
> at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1847)
> at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:566)
> at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6608)
> at 
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:560)
> at 
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:489)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at 
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1115)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1385)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:640)
> at 
> 

[jira] [Created] (IGNITE-5746) Node mustn't start if memory policy is not configured

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-5746:
--

 Summary: Node mustn't start if memory policy is not configured
 Key: IGNITE-5746
 URL: https://issues.apache.org/jira/browse/IGNITE-5746
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov


I faced with NPE in case if memory policy that set in cache is not configured
{code}
[11:27:30,979][SEVERE][srvc-deploy-#46%tester%][GridServiceProcessor] Failed to 
do service reassignment (will retry): Test service: Key affinity singleton
class org.apache.ignite.IgniteCheckedException: Failed to get affinity mapping 
from node: TcpDiscoveryNode [id=0882b08d-21e8-4fd1-add0-91c48fc8a15a, 
addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, 
intOrder=1, lastExchangeTime=1499919956746, loc=true, 
ver=2.1.2#20170712-sha1:0cb6ac06, isClient=false]
at 
org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.affinityCache(GridAffinityProcessor.java:476)
at 
org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.keysToNodes(GridAffinityProcessor.java:347)
at 
org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.mapKeyToNode(GridAffinityProcessor.java:259)
at 
org.apache.ignite.internal.processors.service.GridServiceProcessor.reassign(GridServiceProcessor.java:974)
at 
org.apache.ignite.internal.processors.service.GridServiceProcessor.onDeployment(GridServiceProcessor.java:1484)
at 
org.apache.ignite.internal.processors.service.GridServiceProcessor.processDeployment(GridServiceProcessor.java:1437)
at 
org.apache.ignite.internal.processors.service.GridServiceProcessor.onSystemCacheUpdated(GridServiceProcessor.java:1398)
at 
org.apache.ignite.internal.processors.service.GridServiceProcessor.access$300(GridServiceProcessor.java:119)
at 
org.apache.ignite.internal.processors.service.GridServiceProcessor$ServiceEntriesListener$1.run0(GridServiceProcessor.java:1374)
at 
org.apache.ignite.internal.processors.service.GridServiceProcessor$DepRunnable.run(GridServiceProcessor.java:1806)
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: null
at 
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7229)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:258)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:170)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:139)
at 
org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.affinityInfoFromNode(GridAffinityProcessor.java:501)
at 
org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.affinityCache(GridAffinityProcessor.java:459)
... 12 more
Caused by: java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.affinity.GridAffinityUtils$AffinityJob.call(GridAffinityUtils.java:175)
at 
org.apache.ignite.internal.processors.affinity.GridAffinityUtils$AffinityJob.call(GridAffinityUtils.java:130)
at 
org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1847)
at 
org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:566)
at 
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6608)
at 
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:560)
at 
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:489)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at 
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1115)
at 
org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1385)
at 
org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:640)
at 
org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:532)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at 
org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:749)
at 
org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:448)
at 
org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:428)
at 

[jira] [Commented] (IGNITE-5649) REST API, metadata command always returns list of cache

[Andrey Novikov (JIRA)]

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

Andrey Novikov commented on IGNITE-5649:


Hi [~roman_s],

Yes

My note about implementation:
If {{cacheName}} is not specified, metadata for all caches should be returned 
(now try to return metadata  for default cache)
{code}
final String cacheName = req0.cacheName() == null ? DFLT_CACHE_NAME : 
req0.cacheName();
...
case CACHE_METADATA: {
   fut = ctx.task().execute(MetadataTask.class, cacheName);
{code}

Need throw exception with correct message in case: cache with {{cacheName}} not 
exists, metadata for cache with {{cacheName}} not exists.


> REST API, metadata command always returns list of cache
> ---
>
> Key: IGNITE-5649
> URL: https://issues.apache.org/jira/browse/IGNITE-5649
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Aleksandr
>Assignee: Roman Shtykh
>
> How to reproduce:
> 1) start Ignite server with example config with Person and Organization.
> 2) run:
> curl http://localhost:8080/ignite?cmd=metadata=Person
> curl http://localhost:8080/ignite?cmd=metadata=Organization
> curl http://localhost:8080/ignite?cmd=metadata=blablabla
> Ignite always returns list of cache instead of information about selected 
> cache or error



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

[jira] [Created] (IGNITE-5745) Web console: Admin panel - add registration date and ability to filter by it

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-5745:


 Summary: Web console: Admin panel - add registration date and 
ability to filter by it
 Key: IGNITE-5745
 URL: https://issues.apache.org/jira/browse/IGNITE-5745
 Project: Ignite
  Issue Type: Task
  Components: wizards
Reporter: Alexey Kuznetsov
 Fix For: 2.2


Will be nice to track user registration date in order to see how many users 
registered each month.

Also period filtration should be configurable: use last activity date or 
registration date to see numbers.



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

[jira] [Commented] (IGNITE-5382) SQL: frequent switch between schemas cause severe slowdown

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5382:


GitHub user skalashnikov opened a pull request:

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

IGNITE-5382: SQL: Added per-schema connection lookup



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

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

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

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


commit 9b59c095cb368fee0fedcc0a2781fdc5b55a9951
Author: skalashnikov 
Date:   2017-07-13T06:21:52Z

IGNITE-5382: SQL: Added per-schema connection lookup




> SQL: frequent switch between schemas cause severe slowdown
> --
>
> Key: IGNITE-5382
> URL: https://issues.apache.org/jira/browse/IGNITE-5382
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Sergey Kalashnikov
>  Labels: important, performance
> Fix For: 2.2
>
>
> We have thread-bound cached connection to H2 database which is bound to 
> specific schema. See {{IgniteH2Indexing.connectionForThread}}.
> When query with different schema is executed, we call {{SET SCHEMA}} command, 
> which is rather expensive and may cause slowdown when queries form different 
> caches are executed.
> To avoid this we should maintain thread-local map of such connections. Be 
> careful with concurrency and resource leaks.



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

[jira] [Commented] (IGNITE-2313) Need to add a mode to fail atomic operations within a transaction

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii commented on IGNITE-2313:


[~avinogradov], I fixed metod which compare proxies, MultiJvm tests don't fail 
now.

> Need to add a mode to fail atomic operations within a transaction
> -
>
> Key: IGNITE-2313
> URL: https://issues.apache.org/jira/browse/IGNITE-2313
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Dmitriy Setrakyan
>Assignee: Ryabov Dmitrii
> Fix For: 2.2
>
>
> Currently atomic operations within a transaction succeed without alarming a 
> user that no transaction really occurs. We should add a mode to fail such 
> operations (such mode should be turned off by default).
> New transaction configuration flag (default is {{false}}):
> {code}TransactionConfiguration.isAllowAtomicUpdatesInTransaction(){code}
> If the flag is violated, we should throw an exception with the following 
> error message: {{Transaction spans operations on atomic cache (consider 
> setting TransactionConfiguration.isAllowAttomicUpdatesInTransaction() flag to 
> true)}}



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

[jira] [Commented] (IGNITE-5597) Wrong javadoc in Affinity and AffinityFunction for REPLICATED cache

[Andrei Yakushin (JIRA)]

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

Andrei Yakushin commented on IGNITE-5597:
-

fixed

> Wrong javadoc in Affinity and AffinityFunction for REPLICATED cache
> ---
>
> Key: IGNITE-5597
> URL: https://issues.apache.org/jira/browse/IGNITE-5597
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Evgenii Zhuravlev
>Assignee: Andrei Yakushin
>  Labels: javadoc
> Fix For: 2.2
>
>
> RendezvousAffinityFunction.getPartitions() Javadoc says:
> {code:java}
>  * Note that for fully replicated caches this method should always
>  * return {@code 1}.
> {code}
> but it's not true, it works the same as PARTITIONED cache.
> Affinity.mapKeyToNode(K key) javadoc says:
> {code:java}
>  * 
>  *  For fully replicated caches first node ID returned by {@link 
> AffinityFunction}
>  *  is returned.
>  * 
>  * For partitioned caches, primary node for the given key is 
> returned.
> {code}
> it looks confusing, while REPLICATED cache has primary nodes for keys as 
> PRATITIONED.
> Also,  
> {code:java}
> * Provides affinity information to detect which node is primary and which 
> nodes are
>  * backups for a partitioned cache.
> {code}
> Affinity matter for REPLICATED cache too.



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