[jira] [Commented] (IGNITE-5979) [Test Failed] GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync

[Vadim Opolski (JIRA)]

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

Vadim Opolski commented on IGNITE-5979:
---

[~EdShangGG] is this test failed actual ? I cant recreate it.

> [Test Failed]  
> GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync 
> 
>
> Key: IGNITE-5979
> URL: https://issues.apache.org/jira/browse/IGNITE-5979
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Vadim Opolski
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
>
> Example of failing  - 
> http://ci.ignite.apache.org/viewLog.html?buildId=760709=buildResultsDiv=Ignite20Tests_IgniteDataGridFailover#testNameId6248548165747570497
> {noformat}
> junit.framework.AssertionFailedError: Failed to check value for key 
> [key=72625, node=0671e5c8-8bd5-4f2a-b1b8-9e945742, primary=false, 
> recNodeId=101770ef-a622-4f7c-b714-70ecf1f1] expected:<0> but 
> was:<-1994497644>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.TestCase.assertEquals(TestCase.java:244)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.checkRestarts(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:334)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:154)
> {noformat}



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

[jira] [Closed] (IGNITE-6223) Web console: Agent fail to send task result on job fail.

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov closed IGNITE-6223.
--

> Web console: Agent fail to send task result on job fail.
> 
>
> Key: IGNITE-6223
> URL: https://issues.apache.org/jira/browse/IGNITE-6223
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
> Fix For: 2.3
>
>
> On job fail Web agent return NPE instead of reason exception.



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

[jira] [Commented] (IGNITE-6223) Web console: Agent fail to send task result on job fail.

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-6223:


Tested.

> Web console: Agent fail to send task result on job fail.
> 
>
> Key: IGNITE-6223
> URL: https://issues.apache.org/jira/browse/IGNITE-6223
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
> Fix For: 2.3
>
>
> On job fail Web agent return NPE instead of reason exception.



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

[jira] [Closed] (IGNITE-6120) Web Console: Propagate "lazy" flag on Query screen

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov closed IGNITE-6120.
--

> Web Console: Propagate "lazy" flag on Query screen
> --
>
> Key: IGNITE-6120
> URL: https://issues.apache.org/jira/browse/IGNITE-6120
> Project: Ignite
>  Issue Type: Task
>  Components: sql, wizards
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
> Fix For: 2.3
>
>




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

[jira] [Resolved] (IGNITE-6120) Web Console: Propagate "lazy" flag on Query screen

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov resolved IGNITE-6120.

Resolution: Fixed

> Web Console: Propagate "lazy" flag on Query screen
> --
>
> Key: IGNITE-6120
> URL: https://issues.apache.org/jira/browse/IGNITE-6120
> Project: Ignite
>  Issue Type: Task
>  Components: sql, wizards
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
> Fix For: 2.3
>
>




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

[jira] [Commented] (IGNITE-6120) Web Console: Propagate "lazy" flag on Query screen

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-6120:


Tested.

> Web Console: Propagate "lazy" flag on Query screen
> --
>
> Key: IGNITE-6120
> URL: https://issues.apache.org/jira/browse/IGNITE-6120
> Project: Ignite
>  Issue Type: Task
>  Components: sql, wizards
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
> Fix For: 2.3
>
>




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

[jira] [Updated] (IGNITE-6252) Cassandra Cache Store Session does not retry if prepare statement failed

[Sunny Chan (JIRA)]

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

Sunny Chan updated IGNITE-6252:
---
Description: 
During our testing, we have found that certain warning about prepared statement:

2017-08-31 11:27:19.479 
org.apache.ignite.cache.store.cassandra.CassandraCacheStore 
flusher-0-#265%% WARN CassandraCacheStore - Prepared statement cluster 
error detected, refreshing Cassandra session
com.datastax.driver.core.exceptions.InvalidQueryException: Tried to execute 
unknown prepared query : 0xc7647611fd755386ef63478ee7de577b. You may have used 
a PreparedStatement that was created with another Cluster instance.

We notice that after this warning occurs some of the data didn't persist 
properly in cassandra cache. After further examining the Ignite's 
CassandraSessionImpl code in method execute(BatchExecutionAssistance,Iterable), 
we found that at around [line 
283|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L283],
 if the prepare statement fails in the asnyc call, it will not retry the 
operation as the error is stored in [line 
269|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L269]
 and cleared in [line 
277|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L277]
 but it was not checked again after going through the [ResultSetFuture 
|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L307].

I believe in line 307 you should check for error != null such that any failure 
will be retry.




  was:
During our testing, we have found that certain warning about prepared statement:

{{2017-08-31 11:27:19.479 
org.apache.ignite.cache.store.cassandra.CassandraCacheStore 
flusher-0-#265%% WARN CassandraCacheStore - Prepared statement cluster 
error detected, refreshing Cassandra session
com.datastax.driver.core.exceptions.InvalidQueryException: Tried to execute 
unknown prepared query : 0xc7647611fd755386ef63478ee7de577b. You may have used 
a PreparedStatement that was created with another Cluster instance.}}

We notice that after this warning occurs some of the data didn't persist 
properly in cassandra cache. After further examining the Ignite's 
CassandraSessionImpl code in method execute(BatchExecutionAssistance,Iterable), 
we found that at around [line 
283|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L283],
 if the prepare statement fails in the asnyc call, it will not retry the 
operation as the error is stored in [line 
269|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L269]
 and cleared in [line 
277|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L277]
 but it was not checked again after going through the [ResultSetFuture 
|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L307].

I believe in line 307 you should check for error != null such that any failure 
will be retry.





> Cassandra Cache Store Session does not retry if prepare statement failed
> 
>
> Key: IGNITE-6252
> URL: https://issues.apache.org/jira/browse/IGNITE-6252
> Project: Ignite
>  Issue Type: Bug
>  Components: cassandra
>Affects Versions: 2.0, 2.1
>Reporter: Sunny Chan
>
> During our testing, we have found that certain warning about prepared 
> statement:
> 2017-08-31 11:27:19.479 
> org.apache.ignite.cache.store.cassandra.CassandraCacheStore 
> flusher-0-#265%% WARN CassandraCacheStore - Prepared statement cluster 
> error detected, refreshing Cassandra session
> com.datastax.driver.core.exceptions.InvalidQueryException: Tried to execute 
> unknown prepared query : 0xc7647611fd755386ef63478ee7de577b. You may have 
> used a PreparedStatement that was created with another Cluster instance.
> We notice that after this warning occurs some of the data 

[jira] [Updated] (IGNITE-6252) Cassandra Cache Store Session does not retry if prepare statement failed

[Sunny Chan (JIRA)]

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

Sunny Chan updated IGNITE-6252:
---
Description: 
During our testing, we have found that certain warning about prepared statement:

{{2017-08-31 11:27:19.479 
org.apache.ignite.cache.store.cassandra.CassandraCacheStore 
flusher-0-#265%% WARN CassandraCacheStore - Prepared statement cluster 
error detected, refreshing Cassandra session
com.datastax.driver.core.exceptions.InvalidQueryException: Tried to execute 
unknown prepared query : 0xc7647611fd755386ef63478ee7de577b. You may have used 
a PreparedStatement that was created with another Cluster instance.}}

We notice that after this warning occurs some of the data didn't persist 
properly in cassandra cache. After further examining the Ignite's 
CassandraSessionImpl code in method execute(BatchExecutionAssistance,Iterable), 
we found that at around [line 
283|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L283],
 if the prepare statement fails in the asnyc call, it will not retry the 
operation as the error is stored in [line 
269|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L269]
 and cleared in [line 
277|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L277]
 but it was not checked again after going through the [ResultSetFuture 
|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L307].

I believe in line 307 you should check for error != null such that any failure 
will be retry.




  was:
During our testing, we have found that certain warning about prepared statement:

2017-08-31 11:27:19.479 
org.apache.ignite.cache.store.cassandra.CassandraCacheStore 
flusher-0-#265%% WARN CassandraCacheStore - Prepared statement cluster 
error detected, refreshing Cassandra session
com.datastax.driver.core.exceptions.InvalidQueryException: Tried to execute 
unknown prepared query : 0xc7647611fd755386ef63478ee7de577b. You may have used 
a PreparedStatement that was created with another Cluster instance.

We notice that after this warning occurs some of the data didn't persist 
properly in cassandra cache. After further examining the Ignite's 
CassandraSessionImpl code in method execute(BatchExecutionAssistance,Iterable), 
we found that at around [line 
283|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L283],
 if the prepare statement fails in the asnyc call, it will not retry the 
operation as the error is stored in [line 
269|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L269]
 and cleared in [line 
277|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L277]
 but it was not checked again after going through the [ResultSetFuture 
|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L307].

I believe in line 307 you should check for error != null such that any failure 
will be retry. Also potentially in line 312 we will need to check 
isTableAbsenceError(error).






> Cassandra Cache Store Session does not retry if prepare statement failed
> 
>
> Key: IGNITE-6252
> URL: https://issues.apache.org/jira/browse/IGNITE-6252
> Project: Ignite
>  Issue Type: Bug
>  Components: cassandra
>Affects Versions: 2.0, 2.1
>Reporter: Sunny Chan
>
> During our testing, we have found that certain warning about prepared 
> statement:
> {{2017-08-31 11:27:19.479 
> org.apache.ignite.cache.store.cassandra.CassandraCacheStore 
> flusher-0-#265%% WARN CassandraCacheStore - Prepared statement cluster 
> error detected, refreshing Cassandra session
> com.datastax.driver.core.exceptions.InvalidQueryException: Tried to execute 
> unknown prepared query : 0xc7647611fd755386ef63478ee7de577b. You may have 
> used a PreparedStatement that was created with 

[jira] [Assigned] (IGNITE-6261) ODBC support for Mac OSX

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan reassigned IGNITE-6261:
-

 Assignee: Igor Sapego
Fix Version/s: 2.3

> ODBC support for Mac OSX
> 
>
> Key: IGNITE-6261
> URL: https://issues.apache.org/jira/browse/IGNITE-6261
> Project: Ignite
>  Issue Type: Wish
>  Components: odbc
>Affects Versions: 2.1
> Environment: Analytics
>Reporter: Pranas Baliuka
>Assignee: Igor Sapego
>Priority: Critical
> Fix For: 2.3
>
>
> In order for Ignite to be useful in analytics environment (accessing data via 
> R / Most reporting engines), the ODBC access is required.
> Analyst do use Mac OSX (not only Linux/Windows).
> The current ODBC driver is not compilable on OSX due to 1-2 different kernel 
> API functions.
> Similar incompatibility issues are already resolved in similar projects using 
> conditional macros in C language. i.e. it may not be a big challenge to make 
> it work.
> Thanks for planning and considerations!
> PS:
> For my use case the issue is a Blocker, because rJAVA is dead (requires Java 
> 6 installation on Mac OSX) and even with rJAVA , the JDBC implementation is 
> not working for R (class cast exceptions).



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

[jira] [Created] (IGNITE-6261) ODBC support for Mac OSX

[Pranas Baliuka (JIRA)]

Pranas Baliuka created IGNITE-6261:
--

 Summary: ODBC support for Mac OSX
 Key: IGNITE-6261
 URL: https://issues.apache.org/jira/browse/IGNITE-6261
 Project: Ignite
  Issue Type: Wish
  Components: odbc
Affects Versions: 2.1
 Environment: Analytics
Reporter: Pranas Baliuka
Priority: Critical


In order for Ignite to be useful in analytics environment (accessing data via R 
/ Most reporting engines), the ODBC access is required.

Analyst do use Mac OSX (not only Linux/Windows).

The current ODBC driver is not compilable on OSX due to 1-2 different kernel 
API functions.
Similar incompatibility issues are already resolved in similar projects using 
conditional macros in C language. i.e. it may not be a big challenge to make it 
work.

Thanks for planning and considerations!

PS:
For my use case the issue is a Blocker, because rJAVA is dead (requires Java 6 
installation on Mac OSX) and even with rJAVA , the JDBC implementation is not 
working for R (class cast exceptions).



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

[jira] [Assigned] (IGNITE-5979) [Test Failed] GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync

[Vadim Opolski (JIRA)]

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

Vadim Opolski reassigned IGNITE-5979:
-

Assignee: Vadim Opolski

> [Test Failed]  
> GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync 
> 
>
> Key: IGNITE-5979
> URL: https://issues.apache.org/jira/browse/IGNITE-5979
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Vadim Opolski
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
>
> Example of failing  - 
> http://ci.ignite.apache.org/viewLog.html?buildId=760709=buildResultsDiv=Ignite20Tests_IgniteDataGridFailover#testNameId6248548165747570497
> {noformat}
> junit.framework.AssertionFailedError: Failed to check value for key 
> [key=72625, node=0671e5c8-8bd5-4f2a-b1b8-9e945742, primary=false, 
> recNodeId=101770ef-a622-4f7c-b714-70ecf1f1] expected:<0> but 
> was:<-1994497644>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.TestCase.assertEquals(TestCase.java:244)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.checkRestarts(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:334)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:154)
> {noformat}



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

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

[Maxim Neverov (JIRA)]

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

Maxim Neverov updated IGNITE-2092:
--
Attachment: ignite_boot_log.txt

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



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

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

[Maxim Neverov (JIRA)]

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

Maxim Neverov commented on IGNITE-2092:
---

This bug is not relevant any longer.
According to [this 
article|https://blogs.oracle.com/java-platform-group/java-se-support-for-docker-cpu-and-memory-limits]
 java can discover cpu limitation since 8u131.
Ignite uses java:8 image which is [now obsolete|https://hub.docker.com/_/java/] 
and tagged as 8u111.
I replaced java:8 with openjdk:8 in the root Dockerfile, built it and ran it 
with --cpuset-cpus="0". Ignite detected cpu limitation successfully (full boot 
log is attached):

{noformat}
Topology snapshot [ver=1, servers=1, clients=0, CPUs=1, heap=1.0GB]
{noformat}

So my proposal is to switch to newer jdk.

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



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

[jira] [Commented] (IGNITE-5703) Add CREATE TABLE param for cache write sync mode

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5703:


GitHub user alexpaschenko opened a pull request:

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

IGNITE-5703



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

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

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

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


commit 12fd63828d11311d2f5536f81e025c0f81e64a6a
Author: Alexander Paschenko 
Date:   2017-08-04T18:22:35Z

IGNITE-5703 Write sync mode in create table

commit 1974dc5c3ad439aed06461d48e8d9a55c0cf19fc
Author: Alexander Paschenko 
Date:   2017-08-07T17:06:36Z

minors

commit 83bfb008421dacc418534358ffbd27f0040a9829
Author: Alexander Paschenko 
Date:   2017-09-04T16:06:13Z

Merge remote-tracking branch 'apache/master' into ignite-5703

commit 98d6676f1a79280752fc055a651271357ca3c095
Author: Alexander Paschenko 
Date:   2017-09-04T17:55:02Z

IGNITE-5703 Added more tests




> Add CREATE TABLE param for cache write sync mode
> 
>
> Key: IGNITE-5703
> URL: https://issues.apache.org/jira/browse/IGNITE-5703
> Project: Ignite
>  Issue Type: Task
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 2.3
>
>
> Inspired by IGNITE-5702: instead of always enforcing {{FULL_SYNC}} mode, we 
> better give the user an opportunity to set it explicitly like we do with 
> other params (backups number, atomicity mode, etc.).



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

[jira] [Assigned] (IGNITE-6070) Infinite redirects at Spring Security Web Session Clustering with Tomcat

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev reassigned IGNITE-6070:
---

Assignee: Ilya Kasnacheev

> Infinite redirects at Spring Security Web Session Clustering with Tomcat
> 
>
> Key: IGNITE-6070
> URL: https://issues.apache.org/jira/browse/IGNITE-6070
> Project: Ignite
>  Issue Type: Bug
>  Components: websession
>Affects Versions: 2.1
> Environment: Spring Security, Apache Tomcat
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Minor
>  Labels: easyfix, newbie
> Attachments: IGNITE-6070.patch, webtest.zip
>
>
> See 
> https://stackoverflow.com/questions/45648884/apache-ignite-spring-secutiry-error
>  description.
> When Session comes from Ignite but its Authentication is anonymous, Spring 
> Security does the following check:
> {code}
> } else if (request.getRequestedSessionId() != null && 
> !request.isRequestedSessionIdValid()) {
> this.logger.debug("Requested session ID " + 
> request.getRequestedSessionId() + " is invalid.");
> 
> this.invalidSessionStrategy.onInvalidSessionDetected(request, response);
> }
> {code}
> The problem is, in Ignite we never override isRequestedSessionIdValid() in 
> our request wrappers, so it falls back to Tomcat's own (session) Manager, 
> which will then find that it has never seen this Session and it is therefore 
> invalid. Thus failover is triggered, and if there's "invalid-session-url" 
> clause in Spring Security config, redirect will be issued, possibly circular.
> I've attaching a sample Maven WAR project. It should be deployed to two 
> different Tomcat instances operating on two different ports of same machine, 
> e.g. 8080 and 8180, and then 
> http://localhost:PORT/webtest-1.0-SNAPSHOT/index.jsp should be opened in the 
> same Web Browser one after another for two ports. The second one should cause 
> infinite 302 Redirect to same URL.
> There's also a minor bug in the same code: see session.jsp in the example. It 
> will needlessly throw NPE in WebSessionFilter:1001 and confuse web server. 
> Should output "OK" when fixed.
> Discussion:
> By the way, letting the web server to get hold on Sessions that it creates 
> for us causes additional problems: it's going to store these sessions in 
> parallel with Ignite, consuming memory in the process that first saw a given 
> session. We should probably have (possibly a third party) an Ignite-using 
> Manager implementation for Tomcat specifically. It will be much simpler than 
> filter-based approach while performing better.
> Or maybe we should create our own Sessions that we never allow the web server 
> to see.



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

[jira] [Updated] (IGNITE-6245) ODBC: Driver should return affected rows number for non-batch DML queries as well.

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-6245:

Summary: ODBC: Driver should return affected rows number for non-batch DML 
queries as well.  (was: ODBC: update query should return affected rows number 
for non-batch queries as well.)

> ODBC: Driver should return affected rows number for non-batch DML queries as 
> well.
> --
>
> Key: IGNITE-6245
> URL: https://issues.apache.org/jira/browse/IGNITE-6245
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Andrew Mashenkov
>Assignee: Igor Sapego
> Fix For: 2.3
>
>
> Looks like OdbcQueryExecuteResult class doesn't have rowAffected field that 
> OdbcQueryExecuteBatchResult has.



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

[jira] [Commented] (IGNITE-5795) @AffinityKeyMapped ignored if QueryEntity used

[Alexey Kukushkin (JIRA)]

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

Alexey Kukushkin commented on IGNITE-5795:
--

Good point, will update Ignite public docs and close the ticket.

> @AffinityKeyMapped ignored if QueryEntity used
> --
>
> Key: IGNITE-5795
> URL: https://issues.apache.org/jira/browse/IGNITE-5795
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.0
>Reporter: Dmitry Karachentsev
>Assignee: Alexey Kukushkin
>  Labels: usability
> Fix For: 2.3
>
>
> When cache configured with QueryEntity and used key type with 
> @AffinityKeyMapped field, it will be ignored and wrong partition calculated. 
> This happens because QueryEntity processing precedes key type registering in 
> binary meta cache. On that step 
> CacheObjectBinaryProcessorImpl#affinityKeyField called and unable to resolve 
> type, so null returned and null putted in affKeyFields.
> On next put/get operation CacheObjectBinaryProcessorImpl#affinityKeyField 
> will return null from affKeyFields, but should be affinity key field.
> Test that reproduces problem in [PR 
> 2330|https://github.com/apache/ignite/pull/2330]
> To wrorkaround the issue, set IgniteConfiguration#setKeyConfiguration(), it 
> will force registering key.



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

[jira] [Updated] (IGNITE-6245) ODBC: Driver should return affected rows number for non-batch DML queries as well.

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-6245:

Description: Looks like {{OdbcQueryExecuteResult}} class doesn't have 
{{rowAffected}} field that {{OdbcQueryExecuteBatchResult}} has.  (was: Looks 
like OdbcQueryExecuteResult class doesn't have rowAffected field that 
OdbcQueryExecuteBatchResult has.)

> ODBC: Driver should return affected rows number for non-batch DML queries as 
> well.
> --
>
> Key: IGNITE-6245
> URL: https://issues.apache.org/jira/browse/IGNITE-6245
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Andrew Mashenkov
>Assignee: Igor Sapego
> Fix For: 2.3
>
>
> Looks like {{OdbcQueryExecuteResult}} class doesn't have {{rowAffected}} 
> field that {{OdbcQueryExecuteBatchResult}} has.



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

[jira] [Updated] (IGNITE-6245) ODBC: update query should return affected rows number for non-batch queries as well.

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-6245:

Affects Version/s: 2.1

> ODBC: update query should return affected rows number for non-batch queries 
> as well.
> 
>
> Key: IGNITE-6245
> URL: https://issues.apache.org/jira/browse/IGNITE-6245
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Andrew Mashenkov
>Assignee: Igor Sapego
> Fix For: 2.3
>
>
> Looks like OdbcQueryExecuteResult class doesn't have rowAffected field that 
> OdbcQueryExecuteBatchResult has.



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

[jira] [Updated] (IGNITE-6245) ODBC: update query should return affected rows number for non-batch queries as well.

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-6245:

Component/s: odbc

> ODBC: update query should return affected rows number for non-batch queries 
> as well.
> 
>
> Key: IGNITE-6245
> URL: https://issues.apache.org/jira/browse/IGNITE-6245
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Andrew Mashenkov
>Assignee: Igor Sapego
> Fix For: 2.3
>
>
> Looks like OdbcQueryExecuteResult class doesn't have rowAffected field that 
> OdbcQueryExecuteBatchResult has.



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

[jira] [Commented] (IGNITE-6182) Change default max memory size from 80% to 20%

[Sergey Kozlov (JIRA)]

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

Sergey Kozlov commented on IGNITE-6182:
---

The message is fixed now:
{noformat}
[18:39:12] Nodes started on local machine require more than 80% of physical RAM 
what can lead to significant slowdown du
e to swapping (please decrease JVM heap size, memory policy size or checkpoint 
buffer size) [required=13002MB, available
=16260MB]
{noformat}

> Change default max memory size from 80% to 20%
> --
>
> Key: IGNITE-6182
> URL: https://issues.apache.org/jira/browse/IGNITE-6182
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
>Priority: Blocker
> Fix For: 2.2
>
>
> Currently we can allocate up to 80% of available RAM by default. It could 
> lead to swap with potential risk of hang.
> In order to improve user experience, we need to do the following:
> 1) Decrease default to 20% 
> ({{MemoryConfiguration.DFLT_MEMORY_POLICY_FRACTION}})
> 2) When node starts it should sum max sizes of all memory regions plus Java's 
> XMX. If result is greater than 50% of total RAM, we should issue a warning 
> about potential swap.



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

[jira] [Assigned] (IGNITE-6245) ODBC: update query should return affected rows number for non-batch queries as well.

[Igor Sapego (JIRA)]

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

Igor Sapego reassigned IGNITE-6245:
---

Assignee: Igor Sapego

> ODBC: update query should return affected rows number for non-batch queries 
> as well.
> 
>
> Key: IGNITE-6245
> URL: https://issues.apache.org/jira/browse/IGNITE-6245
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrew Mashenkov
>Assignee: Igor Sapego
> Fix For: 2.3
>
>
> Looks like OdbcQueryExecuteResult class doesn't have rowAffected field that 
> OdbcQueryExecuteBatchResult has.



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

[jira] [Issue Comment Deleted] (IGNITE-4931) Safe way for deactivate cluster

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-4931:
-
Comment: was deleted

(was: [~DmitriyGovorukhin] In test _testDeactivationWithPendingTransaction_ we 
wait transaction to complete, and then proceed deactivation. If we activate 
clust after deactivation, the result of transaction must be seen (the key-value 
must exist in cache). 
After deactivation, all cache data got removed, so we must safe ongoing 
transactions before deactivation, and restart them after activation. Could you 
change the description of task. May be we should create another task - to 
restart transactions after re-activation ?)

> Safe way for deactivate cluster
> ---
>
> Key: IGNITE-4931
> URL: https://issues.apache.org/jira/browse/IGNITE-4931
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.0
>Reporter: Dmitriy Govorukhin
>Assignee: Alexey Kuznetsov
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.3
>
>
> We must provide safe way for deactivate cluster, i mean we must wait while 
> all cache operation, transaction and etc. comleted before start deactivation 
> process, in current implementation we do not wait while transaction comlete, 
> (forcibly stop cache during transaction).



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

[jira] [Commented] (IGNITE-5865) TxOptimisticDeadlockDetectionTest.testDeadlocksPartitioned is failing

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5865:


GitHub user BiryukovVA reopened a pull request:

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

IGNITE-5865: Test fixed.



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

$ git pull https://github.com/BiryukovVA/ignite IGNITE-5865

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

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


commit aedf1ca7dd9b71c923aba4254b93a9055c55bf22
Author: Vitaliy Biryukov 
Date:   2017-09-04T15:29:19Z

IGNITE-5865: Fixed wrong partitioning.




> TxOptimisticDeadlockDetectionTest.testDeadlocksPartitioned is failing
> -
>
> Key: IGNITE-5865
> URL: https://issues.apache.org/jira/browse/IGNITE-5865
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Pavel Kovalenko
>Assignee: Vitaliy Biryukov
>  Labels: MakeTeamcityGreenAgain, Muted_test, test-failure
> Fix For: 2.3
>
>
> Test is flaky.
> Also there is always failing test in suite: 
> TxOptimisticDeadlockDetectionTest.testDeadlocksPartitionedNear
> TC build result: 
> http://ci.ignite.apache.org/viewLog.html?buildId=744109=buildResultsDiv=Ignite20Tests_IgniteCacheDeadlockDetection
> Stacktrace: 
> {noformat}
> [2017-07-28 
> 03:31:52,827][ERROR][grid-timeout-worker-#31%transactions.TxOptimisticDeadlockDetectionTest0%][IgniteTxHandler]
>  Failed to prepare DHT transaction: GridDhtTxLocal 
> [nearNodeId=d005de76-4378-4cd5-ad7e-f00593a2, 
> nearFutId=aab9f378d51-37ca90c9-03f5-417c-9731-2c29810e3cc0, nearMiniId=1, 
> nearFinFutId=null, nearFinMiniId=0, nearXidVer=GridCacheVersion 
> [topVer=112692678, order=1501212673293, nodeOrder=3], 
> super=GridDhtTxLocalAdapter [nearOnOriginatingNode=false, nearNodes=[], 
> dhtNodes=[], explicitLock=false, super=IgniteTxLocalAdapter 
> [completedBase=null, sndTransformedVals=false, depEnabled=false, 
> txState=IgniteTxStateImpl [activeCacheIds=GridIntList [idx=1, 
> arr=[94416770]], recovery=false, txMap=[IgniteTxEntry 
> [key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=424974513, hash=-1228408719, id=1, name=KeyObject1], 
> cacheId=94416770, txKey=IgniteTxKey 
> [key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=424974513, hash=-1228408719, id=1, name=KeyObject1], 
> cacheId=94416770], val=[op=CREATE, val=CacheObjectImpl [val=null, 
> hasValBytes=true]], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null], 
> entryProcessorsCol=null, ttl=-1, conflictExpireTime=-1, conflictVer=null, 
> explicitVer=null, dhtVer=null, filters=[], filtersPassed=false, 
> filtersSet=false, entry=GridDhtCacheEntry [rdrs=[], part=694, 
> super=GridDistributedCacheEntry [super=GridCacheMapEntry 
> [key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=16030069, hash=-1228408719, id=1, name=KeyObject1], val=null, 
> startVer=1501212673290, ver=GridCacheVersion [topVer=112692678, 
> order=1501212673290, nodeOrder=1], hash=-1228408719, 
> extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc 
> [locs=[GridCacheMvccCandidate [nodeId=5d1c593f-e7b8-4672-9a3f-ff75dfe0, 
> ver=GridCacheVersion [topVer=112692678, order=1501212673287, nodeOrder=1], 
> threadId=846, id=520, topVer=AffinityTopologyVersion [topVer=8, 
> minorTopVer=8], reentry=null, 
> otherNodeId=5d1c593f-e7b8-4672-9a3f-ff75dfe0, otherVer=GridCacheVersion 
> [topVer=112692678, order=1501212673287, nodeOrder=1], mappedDhtNodes=null, 
> mappedNearNodes=null, ownerVer=null, serOrder=null, 
> key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=16030069, hash=-1228408719, id=1, name=KeyObject1], 
> masks=local=1|owner=1|ready=1|reentry=0|used=0|tx=1|single_implicit=0|dht_local=1|near_local=0|removed=0|read=0,
>  prevVer=null, nextVer=null], GridCacheMvccCandidate 
> [nodeId=5d1c593f-e7b8-4672-9a3f-ff75dfe0, ver=GridCacheVersion 
> [topVer=112692678, order=1501212673314, nodeOrder=1], threadId=847, id=521, 
> topVer=AffinityTopologyVersion [topVer=8, minorTopVer=8], reentry=null, 
> otherNodeId=d005de76-4378-4cd5-ad7e-f00593a2, otherVer=GridCacheVersion 
> [topVer=112692678, order=1501212673293, nodeOrder=3], mappedDhtNodes=null, 
> mappedNearNodes=null, ownerVer=GridCacheVersion [topVer=112692678, 
> order=1501212673287, nodeOrder=1], serOrder=null, 
> 

[jira] [Commented] (IGNITE-5865) TxOptimisticDeadlockDetectionTest.testDeadlocksPartitioned is failing

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5865:


Github user BiryukovVA closed the pull request at:

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


> TxOptimisticDeadlockDetectionTest.testDeadlocksPartitioned is failing
> -
>
> Key: IGNITE-5865
> URL: https://issues.apache.org/jira/browse/IGNITE-5865
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Pavel Kovalenko
>Assignee: Vitaliy Biryukov
>  Labels: MakeTeamcityGreenAgain, Muted_test, test-failure
> Fix For: 2.3
>
>
> Test is flaky.
> Also there is always failing test in suite: 
> TxOptimisticDeadlockDetectionTest.testDeadlocksPartitionedNear
> TC build result: 
> http://ci.ignite.apache.org/viewLog.html?buildId=744109=buildResultsDiv=Ignite20Tests_IgniteCacheDeadlockDetection
> Stacktrace: 
> {noformat}
> [2017-07-28 
> 03:31:52,827][ERROR][grid-timeout-worker-#31%transactions.TxOptimisticDeadlockDetectionTest0%][IgniteTxHandler]
>  Failed to prepare DHT transaction: GridDhtTxLocal 
> [nearNodeId=d005de76-4378-4cd5-ad7e-f00593a2, 
> nearFutId=aab9f378d51-37ca90c9-03f5-417c-9731-2c29810e3cc0, nearMiniId=1, 
> nearFinFutId=null, nearFinMiniId=0, nearXidVer=GridCacheVersion 
> [topVer=112692678, order=1501212673293, nodeOrder=3], 
> super=GridDhtTxLocalAdapter [nearOnOriginatingNode=false, nearNodes=[], 
> dhtNodes=[], explicitLock=false, super=IgniteTxLocalAdapter 
> [completedBase=null, sndTransformedVals=false, depEnabled=false, 
> txState=IgniteTxStateImpl [activeCacheIds=GridIntList [idx=1, 
> arr=[94416770]], recovery=false, txMap=[IgniteTxEntry 
> [key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=424974513, hash=-1228408719, id=1, name=KeyObject1], 
> cacheId=94416770, txKey=IgniteTxKey 
> [key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=424974513, hash=-1228408719, id=1, name=KeyObject1], 
> cacheId=94416770], val=[op=CREATE, val=CacheObjectImpl [val=null, 
> hasValBytes=true]], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null], 
> entryProcessorsCol=null, ttl=-1, conflictExpireTime=-1, conflictVer=null, 
> explicitVer=null, dhtVer=null, filters=[], filtersPassed=false, 
> filtersSet=false, entry=GridDhtCacheEntry [rdrs=[], part=694, 
> super=GridDistributedCacheEntry [super=GridCacheMapEntry 
> [key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=16030069, hash=-1228408719, id=1, name=KeyObject1], val=null, 
> startVer=1501212673290, ver=GridCacheVersion [topVer=112692678, 
> order=1501212673290, nodeOrder=1], hash=-1228408719, 
> extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc 
> [locs=[GridCacheMvccCandidate [nodeId=5d1c593f-e7b8-4672-9a3f-ff75dfe0, 
> ver=GridCacheVersion [topVer=112692678, order=1501212673287, nodeOrder=1], 
> threadId=846, id=520, topVer=AffinityTopologyVersion [topVer=8, 
> minorTopVer=8], reentry=null, 
> otherNodeId=5d1c593f-e7b8-4672-9a3f-ff75dfe0, otherVer=GridCacheVersion 
> [topVer=112692678, order=1501212673287, nodeOrder=1], mappedDhtNodes=null, 
> mappedNearNodes=null, ownerVer=null, serOrder=null, 
> key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=16030069, hash=-1228408719, id=1, name=KeyObject1], 
> masks=local=1|owner=1|ready=1|reentry=0|used=0|tx=1|single_implicit=0|dht_local=1|near_local=0|removed=0|read=0,
>  prevVer=null, nextVer=null], GridCacheMvccCandidate 
> [nodeId=5d1c593f-e7b8-4672-9a3f-ff75dfe0, ver=GridCacheVersion 
> [topVer=112692678, order=1501212673314, nodeOrder=1], threadId=847, id=521, 
> topVer=AffinityTopologyVersion [topVer=8, minorTopVer=8], reentry=null, 
> otherNodeId=d005de76-4378-4cd5-ad7e-f00593a2, otherVer=GridCacheVersion 
> [topVer=112692678, order=1501212673293, nodeOrder=3], mappedDhtNodes=null, 
> mappedNearNodes=null, ownerVer=GridCacheVersion [topVer=112692678, 
> order=1501212673287, nodeOrder=1], serOrder=null, 
> key=o.a.i.i.processors.cache.transactions.TxOptimisticDeadlockDetectionTest$KeyObject
>  [idHash=16030069, hash=-1228408719, id=1, name=KeyObject1], 
> masks=local=1|owner=0|ready=1|reentry=0|used=0|tx=1|single_implicit=0|dht_local=1|near_local=0|removed=0|read=0,
>  prevVer=null, nextVer=null]], rmts=null]], flags=2]]], prepared=1, 
> locked=false, nodeId=null, locMapped=false, expiryPlc=null, 
> transferExpiryPlc=false, flags=0, partUpdateCntr=0, serReadVer=null, 
> xidVer=null]]], super=IgniteTxAdapter [xidVer=GridCacheVersion 
> [topVer=112692678, order=1501212673314, nodeOrder=1], writeVer=null, 
> implicit=false, loc=true, 

[jira] [Updated] (IGNITE-6101) Try to improve local scans performance

[Igor Seliverstov (JIRA)]

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

Igor Seliverstov updated IGNITE-6101:
-
Fix Version/s: 2.3

> Try to improve local scans performance
> --
>
> Key: IGNITE-6101
> URL: https://issues.apache.org/jira/browse/IGNITE-6101
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.1
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
>  Labels: performance
> Fix For: 2.3
>
>
> Cutently local scan queries at least two times slower than direct iteration 
> over partition (using BTree cursor). Check if it's possible to decrease the 
> speed difference.



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

[jira] [Commented] (IGNITE-6255) .NET: Fix TestAffinityCall to take late affinity assignment into account

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6255:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-6255 .NET: Fix TestAffinityCall to take late affinity assignment 
into account



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

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

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

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


commit cf9ecf5b877208142275b8e8e8b17d25cc93a9ed
Author: Pavel Tupitsyn 
Date:   2017-09-04T15:01:26Z

IGNITE-6255 .NET: Fix TestAffinityCall to take late affinity assignment 
into account




> .NET: Fix TestAffinityCall to take late affinity assignment into account
> 
>
> Key: IGNITE-6255
> URL: https://issues.apache.org/jira/browse/IGNITE-6255
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, MakeTeamcityGreenAgain
> Fix For: 2.3
>
>
> {{ComputeApiTest.TestAffinityCall}} fails because affinity assignment changes 
> during test execution. Find a way to handle this (either retry the test, or 
> wait for some cache event).



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

[jira] [Assigned] (IGNITE-6256) When a node becomes segmented an AssertionError is thrown during GridDhtPartitionTopologyImpl.removeNode

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov reassigned IGNITE-6256:


Assignee: Andrew Mashenkov

> When a node becomes segmented an AssertionError is thrown during 
> GridDhtPartitionTopologyImpl.removeNode
> 
>
> Key: IGNITE-6256
> URL: https://issues.apache.org/jira/browse/IGNITE-6256
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.8
>Reporter: Alexandr Fedotov
>Assignee: Andrew Mashenkov
> Fix For: 2.3
>
>
> The assert is as follows:
> exception="java.lang.AssertionError: null
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.removeNode(GridDhtPartitionTopologyImpl.java:1422)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.beforeExchange(GridDhtPartitionTopologyImpl.java:490)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:769)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:504)
>  at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1689)
>  at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>  at java.lang.Thread.run(Thread.java:745)
> Below is the sequence of steps that leads to the assertion error:
> 1) A node becomes SEGMENTED when it's determined by SegmentCheckWorker, after 
> an EVT_NODE_FAILED has been received.
> 2) It gets visibleRemoteNodes from it's TcpDiscoveryNodesRing
> 3) Clears the TcpDiscoveryNodesRing leaving only self on the list. The node 
> ring is used to determine if a node is alive
> during DiscoCache creation
> 4) After that, the node initiates removal of all the nodes read in step 2
> 5) For each node, it sends an EVT_NODE_FAILED to the corresponding 
> DiscoverySpiListener
> providing a topology containing all the nodes except already processed
> 6) This event gets into GridDiscoveryManager 
> 7) The node gets removed from alive nodes for every DiscoCache in 
> discoCacheHist
> 8) Topology change is detected
> 9) Creation of a new DiscoCache is attempted. At this moment every remote 
> node is not available due to the
> TcpDiscoveryNodesRing has been cleared, thus resulting in a DiscoCache with 
> empty alives
> 10) The event with the created DiscoCache and the new topology version is 
> passed to DiscoveryWorker
> 11) The event is eventually handled by DiscoveryWorker and is recorded by 
> DiscoveryWorker#recordEvent
> 12) The recording is handled by GridEventStorageManager which notifies every 
> listener for this event type (EVT_NODE_FAILED)
> 13) One of the listeners is GridCachePartitionExchangeManager#discoLsnr
> It creates a new GridDhtPartitionsExchangeFuture with the empty DiscoCache 
> received with the event and enqueues it
> 14) The future gets eventually handled by GridDhtPartitionsExchangeFuture and 
> initialized
> 15) updateTopologies is called, which for each GridCacheContext gets its 
> topology (GridDhtPartitionTopology)
> and calls GridDhtPartitionTopology#updateTopologyVersion
> 16) DiscoCache for GridDhtPartitionTopology is assigned from the one of the 
> GridDhtPartitionsExchangeFuture.
> The assigned DiscoCache has empty alives at the moment
> 15) A distributed exchange is handled 
> (GridDhtPartitionsExchangeFuture#distributedExchange)
> 16) For each cache context GridCacheContext, for its topology 
> (GridDhtPartitionTopologyImpl) GridDhtPartitionTopologyImpl#beforeExchange is 
> called
> 17) The fact that the node has left is determined and 
> GridDhtPartitionTopologyImpl#removeNode is called to handle it
> 18) An attempt is made to get the alive coordinator node by calling 
> DiscoCache#oldestAliveServerNode
> 19) null is returned which results in an AssertionError
> The fix should probably prevent initiating exchange futures if a node has 
> segmented.



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

[jira] [Commented] (IGNITE-5817) Change checksum calculation methods

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5817:


GitHub user oleg-ostanin opened a pull request:

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

IGNITE-5817 Changed checksum calculation methods

(cherry picked from commit 28fb8c8)

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

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

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

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


commit 67a9efc492091a3e1aa49d15e7db2eb8acce6f51
Author: oleg-ostanin 
Date:   2017-08-29T14:25:36Z

IGNITE-5817 Changed checksum calculation methods

(cherry picked from commit 28fb8c8)




> Change checksum calculation methods
> ---
>
> Key: IGNITE-5817
> URL: https://issues.apache.org/jira/browse/IGNITE-5817
> Project: Ignite
>  Issue Type: Bug
>Reporter: Oleg Ostanin
>Assignee: Oleg Ostanin
>Priority: Blocker
> Fix For: 2.3
>
>
> Neither sha1 nor md5 are trustful checksum calculation methods. We should be 
> switching to at least sha265 or higher.



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

[jira] [Assigned] (IGNITE-6244) .NET: Thin client: ScanQuery

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev reassigned IGNITE-6244:
---

Assignee: Ilya Kasnacheev  (was: Pavel Tupitsyn)

> .NET: Thin client: ScanQuery
> 
>
> Key: IGNITE-6244
> URL: https://issues.apache.org/jira/browse/IGNITE-6244
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Ilya Kasnacheev
>  Labels: .NET
> Fix For: 2.3
>
>
> Implement ScanQuery in thin client.
> Challenges:
> * Query cursor. This will require some kind of HandleRegistry on Java side, 
> so we can pass an ID back to client (see {{OdbcRequestHandler.qryCursors}} as 
> an example).
> * Predicate. Thin client is not .NET-specific. We need a way to support 
> predicates in (at least) Java and .NET, there should be some platform id.



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

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

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-4756:
--

[~tledkov-gridgain], 
Please review.

> 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.3
>
>
> 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] [Assigned] (IGNITE-6244) .NET: Thin client: ScanQuery

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev reassigned IGNITE-6244:
---

Assignee: Pavel Tupitsyn  (was: Ilya Kasnacheev)

> .NET: Thin client: ScanQuery
> 
>
> Key: IGNITE-6244
> URL: https://issues.apache.org/jira/browse/IGNITE-6244
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Implement ScanQuery in thin client.
> Challenges:
> * Query cursor. This will require some kind of HandleRegistry on Java side, 
> so we can pass an ID back to client (see {{OdbcRequestHandler.qryCursors}} as 
> an example).
> * Predicate. Thin client is not .NET-specific. We need a way to support 
> predicates in (at least) Java and .NET, there should be some platform id.



--
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=16152677#comment-16152677
 ] 

Vadim Opolski commented on IGNITE-4756:
---

[~tledkov-gridgain] [~avinogradov] In my opinion tests look good. [TC 
#2557|https://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_RunAll_Ignite20Tests=pull%2F2557%2Fhead=buildTypeStatusDiv]

> 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.3
>
>
> 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] [Comment Edited] (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=16152677#comment-16152677
 ] 

Vadim Opolski edited comment on IGNITE-4756 at 9/4/17 2:51 PM:
---

[~tledkov-gridgain] [~avinogradov] In my opinion tests - [TC 
#2557|https://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_RunAll_Ignite20Tests=pull%2F2557%2Fhead=buildTypeStatusDiv]
 look good.


was (Author: javaller):
[~tledkov-gridgain] [~avinogradov] In my opinion tests look good. [TC 
#2557|https://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_RunAll_Ignite20Tests=pull%2F2557%2Fhead=buildTypeStatusDiv]

> 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.3
>
>
> 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] [Comment Edited] (IGNITE-6182) Change default max memory size from 80% to 20%

[Sergey Kozlov (JIRA)]

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

Sergey Kozlov edited comment on IGNITE-6182 at 9/4/17 2:39 PM:
---

Guys

I just have checked it and found that the warning is not clear yet. I started 3 
nodes and the thitd node printed out:
{noformat}
16:51:21] Attempting to start more nodes than physical RAM available on the 
host what can lead to significant slowdown
please decrease JVM heap size, memory policy size or checkpoint buffer size) 
[required=13002MB, available=16260MB]
{noformat}

Why the required size is less than the available size but node is still warning?



was (Author: skozlov):
Guys

I just have checked it and found that the warning is not clear yet. I started 3 
nodes and thrid node prined out:
{noformat}
16:51:21] Attempting to start more nodes than physical RAM available on the 
host what can lead to significant slowdown
please decrease JVM heap size, memory policy size or checkpoint buffer size) 
[required=13002MB, available=16260MB]
{noformat}

Why the required size is less than the available size but node is still warning?


> Change default max memory size from 80% to 20%
> --
>
> Key: IGNITE-6182
> URL: https://issues.apache.org/jira/browse/IGNITE-6182
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
>Priority: Blocker
> Fix For: 2.2
>
>
> Currently we can allocate up to 80% of available RAM by default. It could 
> lead to swap with potential risk of hang.
> In order to improve user experience, we need to do the following:
> 1) Decrease default to 20% 
> ({{MemoryConfiguration.DFLT_MEMORY_POLICY_FRACTION}})
> 2) When node starts it should sum max sizes of all memory regions plus Java's 
> XMX. If result is greater than 50% of total RAM, we should issue a warning 
> about potential swap.



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

[jira] [Created] (IGNITE-6260) Need to rename setDistributedJoins to setNonCollocatedJoins

[Dmitriy Setrakyan (JIRA)]

Dmitriy Setrakyan created IGNITE-6260:
-

 Summary: Need to rename setDistributedJoins to 
setNonCollocatedJoins
 Key: IGNITE-6260
 URL: https://issues.apache.org/jira/browse/IGNITE-6260
 Project: Ignite
  Issue Type: Improvement
  Components: jdbc, odbc, sql
Reporter: Dmitriy Setrakyan
 Fix For: 2.3


The name {{distributed join}} is very confusing, as all joins in Ignite are 
distributed. We should do the following:
* Deprecate {{setDistributedJoins(...)}} property (it should be removed in 3.0)
* Add {{setNonCollocatedJoins(...)}} property.




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

[jira] [Commented] (IGNITE-5653) Add to query execution plan debug data for joins

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan commented on IGNITE-5653:
---

Warning users about non-collocated joins and making sure that the returned data 
is correct would be a huge usability improvement. Hope it can make it to 2.3 
release.

> Add to query execution plan debug data for joins
> 
>
> Key: IGNITE-5653
> URL: https://issues.apache.org/jira/browse/IGNITE-5653
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
> Environment: Plan should output table type (replicated/partitioned) 
> and colocation information if possible. If we have this than we can warn (or 
> throw exception) if users try to join non colocated tables with local joins.
>Reporter: Alexander Paschenko
>  Labels: usability
> Fix For: 2.3
>
>




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

[jira] [Updated] (IGNITE-5653) Add to query execution plan debug data for joins

[Dmitriy Setrakyan (JIRA)]

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

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

> Add to query execution plan debug data for joins
> 
>
> Key: IGNITE-5653
> URL: https://issues.apache.org/jira/browse/IGNITE-5653
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
> Environment: Plan should output table type (replicated/partitioned) 
> and colocation information if possible. If we have this than we can warn (or 
> throw exception) if users try to join non colocated tables with local joins.
>Reporter: Alexander Paschenko
>  Labels: usability
> Fix For: 2.3
>
>




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

[jira] [Commented] (IGNITE-6182) Change default max memory size from 80% to 20%

[Sergey Kozlov (JIRA)]

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

Sergey Kozlov commented on IGNITE-6182:
---

Guys

I just have checked it and found that the warning is not clear yet. I started 3 
nodes and thrid node prined out:
{noformat}
16:51:21] Attempting to start more nodes than physical RAM available on the 
host what can lead to significant slowdown
please decrease JVM heap size, memory policy size or checkpoint buffer size) 
[required=13002MB, available=16260MB]
{noformat}

Why the required size is less than the available size but node is still warning?


> Change default max memory size from 80% to 20%
> --
>
> Key: IGNITE-6182
> URL: https://issues.apache.org/jira/browse/IGNITE-6182
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
>Priority: Blocker
> Fix For: 2.2
>
>
> Currently we can allocate up to 80% of available RAM by default. It could 
> lead to swap with potential risk of hang.
> In order to improve user experience, we need to do the following:
> 1) Decrease default to 20% 
> ({{MemoryConfiguration.DFLT_MEMORY_POLICY_FRACTION}})
> 2) When node starts it should sum max sizes of all memory regions plus Java's 
> XMX. If result is greater than 50% of total RAM, we should issue a warning 
> about potential swap.



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

[jira] [Updated] (IGNITE-3467) jdbc getTables() returns catalog as null

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3467:

Labels: usability  (was: )

> jdbc getTables() returns catalog as null
> 
>
> Key: IGNITE-3467
> URL: https://issues.apache.org/jira/browse/IGNITE-3467
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc
>Affects Versions: 1.6
>Reporter: Alexandre Boudnik
>  Labels: usability
>
> Then some jdbc query tool uses null values as catalog name. An H2 database 
> returns word "DATABASE" in CATALOG column, and then correctly resolves a 
> fully-qualified name. I would recommend to do the same for these metadata.



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

[jira] [Created] (IGNITE-6259) GridServiceProcessor may leave futures hanging on unstable topology

[Denis Mekhanikov (JIRA)]

Denis Mekhanikov created IGNITE-6259:


 Summary: GridServiceProcessor may leave futures hanging on 
unstable topology
 Key: IGNITE-6259
 URL: https://issues.apache.org/jira/browse/IGNITE-6259
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1, 2.0, 1.9, 1.8, 1.7
Reporter: Denis Mekhanikov


GridServiceProcessor subscribes to updates on the internal cache to get 
information about new deployments or cancellations of services. Some of such 
updates may be lost under conditions of unstable topology. It leads to services 
not being deployed and client futures infinitely hanging.



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

[jira] [Assigned] (IGNITE-5250) Unhelpful exception when value of wrong type is passed to H2

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-5250:
---

Assignee: (was: Alexander Paschenko)

> Unhelpful exception when value of wrong type is passed to H2
> 
>
> Key: IGNITE-5250
> URL: https://issues.apache.org/jira/browse/IGNITE-5250
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Denis Magda
>  Labels: usability
> Attachments: ExampleNodeStartup.java
>
>
> For instance, if an SQL schema defined this way:
> {code}
> cfg.setIndexedTypes(AffinityKey.class, Person.class);
> {code}
> and then, by some reason, the users confuses the type of the key passing 
> {{int}} instead of {{AffinityKey}}
> {code}
> SqlFieldsQuery query = new SqlFieldsQuery("INSERT INTO Person (_key, 
> id, name, country ) " +
> "VALUES ( ? , ? , ? , ?)");
> // Setting the key of a wrong type (AffinityKey instance must be used 
> instead).
> query.setArgs(100, 1000, "John", "Canada");
> // Getting not user friendly exception.
> cache.query(query).getAll();
> {code}
> he will get an exception that doesn't point out to the exact root cause:
> {noformat}
> Caused by: class org.apache.ignite.IgniteException: Failed to execute SQL 
> query.
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor$3.iterator(DmlStatementsProcessor.java:365)
>   at 
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:94)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.doInsert(DmlStatementsProcessor.java:836)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:378)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:173)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsTwoStep(DmlStatementsProcessor.java:207)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1657)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1701)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1699)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2129)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1706)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:783)
>   ... 6 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute 
> SQL query.
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:1224)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1276)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.access$1300(IgniteH2Indexing.java:239)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$4.iterator(IgniteH2Indexing.java:1079)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$4.iterator(IgniteH2Indexing.java:1067)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor$3.iterator(DmlStatementsProcessor.java:362)
>   ... 18 more
> Caused by: org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number 
> of characters: "100"; SQL statement:
> SELECT
> TABLE._KEY,
> TABLE.ID,
> TABLE.NAME,
> TABLE.COUNTRY
> FROM TABLE(_KEY OTHER=(?1,), ID BIGINT=(?2,), NAME VARCHAR=(?3,), COUNTRY 
> VARCHAR=(?4,)) [90003-195]
>   at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
>   at org.h2.message.DbException.get(DbException.java:179)
>   at org.h2.message.DbException.get(DbException.java:155)
>   at org.h2.util.StringUtils.convertHexToBytes(StringUtils.java:930)
>   at org.h2.value.Value.convertTo(Value.java:957)
>   at org.h2.table.Column.convert(Column.java:167)
>   at org.h2.expression.TableFunction.getTable(TableFunction.java:118)
>   at org.h2.expression.TableFunction.getValue(TableFunction.java:41)
>   at org.h2.table.FunctionTable.getValueResultSet(FunctionTable.java:218)
>   at org.h2.table.FunctionTable.getResult(FunctionTable.java:189)
>   at 

[jira] [Updated] (IGNITE-5250) Unhelpful exception when value of wrong type is passed to H2

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5250:

Fix Version/s: (was: 2.3)

> Unhelpful exception when value of wrong type is passed to H2
> 
>
> Key: IGNITE-5250
> URL: https://issues.apache.org/jira/browse/IGNITE-5250
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Denis Magda
>  Labels: usability
> Attachments: ExampleNodeStartup.java
>
>
> For instance, if an SQL schema defined this way:
> {code}
> cfg.setIndexedTypes(AffinityKey.class, Person.class);
> {code}
> and then, by some reason, the users confuses the type of the key passing 
> {{int}} instead of {{AffinityKey}}
> {code}
> SqlFieldsQuery query = new SqlFieldsQuery("INSERT INTO Person (_key, 
> id, name, country ) " +
> "VALUES ( ? , ? , ? , ?)");
> // Setting the key of a wrong type (AffinityKey instance must be used 
> instead).
> query.setArgs(100, 1000, "John", "Canada");
> // Getting not user friendly exception.
> cache.query(query).getAll();
> {code}
> he will get an exception that doesn't point out to the exact root cause:
> {noformat}
> Caused by: class org.apache.ignite.IgniteException: Failed to execute SQL 
> query.
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor$3.iterator(DmlStatementsProcessor.java:365)
>   at 
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:94)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.doInsert(DmlStatementsProcessor.java:836)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:378)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:173)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsTwoStep(DmlStatementsProcessor.java:207)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1657)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1701)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1699)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2129)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1706)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:783)
>   ... 6 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute 
> SQL query.
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:1224)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1276)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.access$1300(IgniteH2Indexing.java:239)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$4.iterator(IgniteH2Indexing.java:1079)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$4.iterator(IgniteH2Indexing.java:1067)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor$3.iterator(DmlStatementsProcessor.java:362)
>   ... 18 more
> Caused by: org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number 
> of characters: "100"; SQL statement:
> SELECT
> TABLE._KEY,
> TABLE.ID,
> TABLE.NAME,
> TABLE.COUNTRY
> FROM TABLE(_KEY OTHER=(?1,), ID BIGINT=(?2,), NAME VARCHAR=(?3,), COUNTRY 
> VARCHAR=(?4,)) [90003-195]
>   at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
>   at org.h2.message.DbException.get(DbException.java:179)
>   at org.h2.message.DbException.get(DbException.java:155)
>   at org.h2.util.StringUtils.convertHexToBytes(StringUtils.java:930)
>   at org.h2.value.Value.convertTo(Value.java:957)
>   at org.h2.table.Column.convert(Column.java:167)
>   at org.h2.expression.TableFunction.getTable(TableFunction.java:118)
>   at org.h2.expression.TableFunction.getValue(TableFunction.java:41)
>   at org.h2.table.FunctionTable.getValueResultSet(FunctionTable.java:218)
>   at org.h2.table.FunctionTable.getResult(FunctionTable.java:189)
>   at 

[jira] [Updated] (IGNITE-5250) Unhelpful exception when value of wrong type is passed to H2

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5250:

Labels: usability  (was: )

> Unhelpful exception when value of wrong type is passed to H2
> 
>
> Key: IGNITE-5250
> URL: https://issues.apache.org/jira/browse/IGNITE-5250
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>  Labels: usability
> Fix For: 2.3
>
> Attachments: ExampleNodeStartup.java
>
>
> For instance, if an SQL schema defined this way:
> {code}
> cfg.setIndexedTypes(AffinityKey.class, Person.class);
> {code}
> and then, by some reason, the users confuses the type of the key passing 
> {{int}} instead of {{AffinityKey}}
> {code}
> SqlFieldsQuery query = new SqlFieldsQuery("INSERT INTO Person (_key, 
> id, name, country ) " +
> "VALUES ( ? , ? , ? , ?)");
> // Setting the key of a wrong type (AffinityKey instance must be used 
> instead).
> query.setArgs(100, 1000, "John", "Canada");
> // Getting not user friendly exception.
> cache.query(query).getAll();
> {code}
> he will get an exception that doesn't point out to the exact root cause:
> {noformat}
> Caused by: class org.apache.ignite.IgniteException: Failed to execute SQL 
> query.
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor$3.iterator(DmlStatementsProcessor.java:365)
>   at 
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:94)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.doInsert(DmlStatementsProcessor.java:836)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:378)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:173)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsTwoStep(DmlStatementsProcessor.java:207)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1657)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1701)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1699)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2129)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1706)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:783)
>   ... 6 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute 
> SQL query.
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:1224)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1276)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.access$1300(IgniteH2Indexing.java:239)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$4.iterator(IgniteH2Indexing.java:1079)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$4.iterator(IgniteH2Indexing.java:1067)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor$3.iterator(DmlStatementsProcessor.java:362)
>   ... 18 more
> Caused by: org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number 
> of characters: "100"; SQL statement:
> SELECT
> TABLE._KEY,
> TABLE.ID,
> TABLE.NAME,
> TABLE.COUNTRY
> FROM TABLE(_KEY OTHER=(?1,), ID BIGINT=(?2,), NAME VARCHAR=(?3,), COUNTRY 
> VARCHAR=(?4,)) [90003-195]
>   at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
>   at org.h2.message.DbException.get(DbException.java:179)
>   at org.h2.message.DbException.get(DbException.java:155)
>   at org.h2.util.StringUtils.convertHexToBytes(StringUtils.java:930)
>   at org.h2.value.Value.convertTo(Value.java:957)
>   at org.h2.table.Column.convert(Column.java:167)
>   at org.h2.expression.TableFunction.getTable(TableFunction.java:118)
>   at org.h2.expression.TableFunction.getValue(TableFunction.java:41)
>   at org.h2.table.FunctionTable.getValueResultSet(FunctionTable.java:218)
>   at 

[jira] [Assigned] (IGNITE-6129) Implement date types comparison without deserialization

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-6129:
---

Assignee: (was: Sergey Kalashnikov)

> Implement date types comparison without deserialization
> ---
>
> Key: IGNITE-6129
> URL: https://issues.apache.org/jira/browse/IGNITE-6129
> Project: Ignite
>  Issue Type: Task
>  Components: general, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>  Labels: performance
>
> We need to implement the same optimization as was done for strings 
> (IGNITE-5918), but for date-time data types.



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

[jira] [Updated] (IGNITE-6047) Need to support "show" SQL commands

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6047:

Labels: usability  (was: )

> Need to support "show" SQL commands
> ---
>
> Key: IGNITE-6047
> URL: https://issues.apache.org/jira/browse/IGNITE-6047
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Dmitriy Setrakyan
>  Labels: usability
>
> I have connected to Ignite from DBeaver using our thin JDBC driver. When I 
> execute "show" commands, I get an error. 
> We need to support all or most {{SHOW}} commands in H2, as described here:
> http://www.h2database.com/html/grammar.html?highlight=show=show#show
> Also, ideally, if a user issues {{DESCRIBE}} or {{DESC}} commands, we should 
> give a message to use the {{SHOW}} command, if possible, and provide a link 
> to the correct syntax.



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

[jira] [Assigned] (IGNITE-6047) Need to support "show" SQL commands

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-6047:
---

Assignee: (was: Alexander Paschenko)

> Need to support "show" SQL commands
> ---
>
> Key: IGNITE-6047
> URL: https://issues.apache.org/jira/browse/IGNITE-6047
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Dmitriy Setrakyan
>
> I have connected to Ignite from DBeaver using our thin JDBC driver. When I 
> execute "show" commands, I get an error. 
> We need to support all or most {{SHOW}} commands in H2, as described here:
> http://www.h2database.com/html/grammar.html?highlight=show=show#show
> Also, ideally, if a user issues {{DESCRIBE}} or {{DESC}} commands, we should 
> give a message to use the {{SHOW}} command, if possible, and provide a link 
> to the correct syntax.



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

[jira] [Commented] (IGNITE-6253) .NET: Replace Doxygen with DocFX for API documentation generation

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-6253:


[~vozerov], please have a look: 
https://ptupitsyn.github.io/docfx-test/api/index.html

> .NET: Replace Doxygen with DocFX for API documentation generation
> -
>
> Key: IGNITE-6253
> URL: https://issues.apache.org/jira/browse/IGNITE-6253
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Doxygen has recently became very slow on our code base (can take up to 30 
> minutes), and there seems to be no solution to this problem. There are other 
> issues: documentation is a bit ugly, customization possibilities are limited, 
> C# is not a first-class citizen there.
> [DocFX|https://dotnet.github.io/docfx/] looks like an obvious replacement:
> * It is a go-to documentation generator for .NET (included in .NET Foundation)
> * Documentation looks nice (MSDN-like) out of the box
> * Migration seems to be easy enough



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

[jira] [Assigned] (IGNITE-6253) .NET: Replace Doxygen with DocFX for API documentation generation

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-6253:
--

Assignee: Vladimir Ozerov  (was: Pavel Tupitsyn)

> .NET: Replace Doxygen with DocFX for API documentation generation
> -
>
> Key: IGNITE-6253
> URL: https://issues.apache.org/jira/browse/IGNITE-6253
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, platforms
>Reporter: Pavel Tupitsyn
>Assignee: Vladimir Ozerov
>  Labels: .NET
> Fix For: 2.3
>
>
> Doxygen has recently became very slow on our code base (can take up to 30 
> minutes), and there seems to be no solution to this problem. There are other 
> issues: documentation is a bit ugly, customization possibilities are limited, 
> C# is not a first-class citizen there.
> [DocFX|https://dotnet.github.io/docfx/] looks like an obvious replacement:
> * It is a go-to documentation generator for .NET (included in .NET Foundation)
> * Documentation looks nice (MSDN-like) out of the box
> * Migration seems to be easy enough



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

[jira] [Commented] (IGNITE-6253) .NET: Replace Doxygen with DocFX for API documentation generation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6253:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-6253 .NET: Replace Doxygen with DocFX for API documentation



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

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

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

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


commit 040b8048d21cd62ee509795aca937c897b200e0b
Author: Pavel Tupitsyn 
Date:   2017-09-04T13:23:58Z

IGNITE-6253 .NET: Replace Doxygen with DocFX for API documentation 
generation




> .NET: Replace Doxygen with DocFX for API documentation generation
> -
>
> Key: IGNITE-6253
> URL: https://issues.apache.org/jira/browse/IGNITE-6253
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Doxygen has recently became very slow on our code base (can take up to 30 
> minutes), and there seems to be no solution to this problem. There are other 
> issues: documentation is a bit ugly, customization possibilities are limited, 
> C# is not a first-class citizen there.
> [DocFX|https://dotnet.github.io/docfx/] looks like an obvious replacement:
> * It is a go-to documentation generator for .NET (included in .NET Foundation)
> * Documentation looks nice (MSDN-like) out of the box
> * Migration seems to be easy enough



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

[jira] [Updated] (IGNITE-6253) .NET: Replace Doxygen with DocFX for API documentation generation

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-6253:
---
Description: 
Doxygen has recently became very slow on our code base (can take up to 30 
minutes), and there seems to be no solution to this problem. There are other 
issues: documentation is a bit ugly, customization possibilities are limited, 
C# is not a first-class citizen there.

[DocFX|https://dotnet.github.io/docfx/] looks like an obvious replacement:
* It is a go-to documentation generator for .NET (included in .NET Foundation)
* Documentation looks nice (MSDN-like) out of the box
* Migration seems to be easy enough

  was:
Doxygen has recently became very slow on our code base (can take up to 30 
minutes), and there seems to be no solution to this problem. There are other 
issues: documentation is a bit ugly, customization possibilities are limited, 
C# is not a first-class citizen there.

[DocFX|https://dotnet.github.io/docfx/] looks like an obvious replacement:
* It is a go-to documentation generator for .NET (included in .NET Foundation)
* Documentation looks nice (MSDN-like) out of the box
* Migration seems to be easy enough

To do:
* Remove {{Package-Info.cs}} files, they don't make sense


> .NET: Replace Doxygen with DocFX for API documentation generation
> -
>
> Key: IGNITE-6253
> URL: https://issues.apache.org/jira/browse/IGNITE-6253
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Doxygen has recently became very slow on our code base (can take up to 30 
> minutes), and there seems to be no solution to this problem. There are other 
> issues: documentation is a bit ugly, customization possibilities are limited, 
> C# is not a first-class citizen there.
> [DocFX|https://dotnet.github.io/docfx/] looks like an obvious replacement:
> * It is a go-to documentation generator for .NET (included in .NET Foundation)
> * Documentation looks nice (MSDN-like) out of the box
> * Migration seems to be easy enough



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

[jira] [Commented] (IGNITE-6253) .NET: Replace Doxygen with DocFX for API documentation generation

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-6253:


Let's keep doxygen stuff there for now, we can remove it as a separate task.

> .NET: Replace Doxygen with DocFX for API documentation generation
> -
>
> Key: IGNITE-6253
> URL: https://issues.apache.org/jira/browse/IGNITE-6253
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Doxygen has recently became very slow on our code base (can take up to 30 
> minutes), and there seems to be no solution to this problem. There are other 
> issues: documentation is a bit ugly, customization possibilities are limited, 
> C# is not a first-class citizen there.
> [DocFX|https://dotnet.github.io/docfx/] looks like an obvious replacement:
> * It is a go-to documentation generator for .NET (included in .NET Foundation)
> * Documentation looks nice (MSDN-like) out of the box
> * Migration seems to be easy enough
> To do:
> * Remove {{Package-Info.cs}} files, they don't make sense



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

[jira] [Updated] (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:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-5482:

Labels:   (was: important)

> 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
>
> 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] [Assigned] (IGNITE-5623) DDL needs to support DEFAULT operator

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-5623:
---

Assignee: (was: Alexander Paschenko)

> DDL needs to support DEFAULT operator 
> --
>
> Key: IGNITE-5623
> URL: https://issues.apache.org/jira/browse/IGNITE-5623
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Denis Magda
>
> There should be a way to set a default value for a column/field if the one is 
> not specified during an insert operation. In general, we need to support 
> {{ DEFAULT }} in a way it's show below:
> {code}
> CREATE TABLE Persons (
>   ID int,
>   FirstName varchar(255),
>   Age int,
>   City varchar(255) DEFAULT 'Sandnes'
> );
> {code}



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

[jira] [Updated] (IGNITE-5623) DDL needs to support DEFAULT operator

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5623:

Fix Version/s: (was: 2.3)

> DDL needs to support DEFAULT operator 
> --
>
> Key: IGNITE-5623
> URL: https://issues.apache.org/jira/browse/IGNITE-5623
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>
> There should be a way to set a default value for a column/field if the one is 
> not specified during an insert operation. In general, we need to support 
> {{ DEFAULT }} in a way it's show below:
> {code}
> CREATE TABLE Persons (
>   ID int,
>   FirstName varchar(255),
>   Age int,
>   City varchar(255) DEFAULT 'Sandnes'
> );
> {code}



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

[jira] [Assigned] (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:all-tabpanel
 ]

Vladimir Ozerov reassigned IGNITE-5482:
---

Assignee: (was: Alexander Paschenko)

> 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
>
> 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] [Updated] (IGNITE-5855) SQL: BigInteger support broken in SQL queries.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5855:

Fix Version/s: 2.3

> SQL: BigInteger support broken in SQL queries.
> --
>
> Key: IGNITE-5855
> URL: https://issues.apache.org/jira/browse/IGNITE-5855
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.0, 2.1
>Reporter: Andrew Mashenkov
>Assignee: Ilya Kasnacheev
> Fix For: 2.3
>
> Attachments: BigIntegerKeySqlTest.java
>
>
> Looks like BigInteger support in SQL was broken.
> It works fine on ignite-1.9
> PFA reproducer.



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

[jira] [Updated] (IGNITE-6248) Check Java 7 builds for compatibility with Ignite and update documentation

[Evgenii Zhuravlev (JIRA)]

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

Evgenii Zhuravlev updated IGNITE-6248:
--
Fix Version/s: (was: 2.2)
   2.3

> Check Java 7 builds for compatibility with Ignite and update documentation
> --
>
> Key: IGNITE-6248
> URL: https://issues.apache.org/jira/browse/IGNITE-6248
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Priority: Minor
> Fix For: 2.3
>
>
> According to these threads on SO and user list, some old Java 7 versions 
> doesn't compatible with Ignite since version 2.1 anymore:
> http://apache-ignite-users.70518.x6.nabble.com/Caused-by-org-h2-jdbc-JdbcSQLException-General-error-quot-java-lang-IllegalMonitorStateException-Attt-td15684.html
> https://stackoverflow.com/questions/45911616/datastreamer-does-not-work-well/45972341#45972341



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

[jira] [Updated] (IGNITE-6133) Add clearNodeLocalMap() to IgniteMXBean

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-6133:
-
Fix Version/s: (was: 2.2)

> Add clearNodeLocalMap() to IgniteMXBean
> ---
>
> Key: IGNITE-6133
> URL: https://issues.apache.org/jira/browse/IGNITE-6133
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Yakov Zhdanov
>Assignee: vk
>  Labels: newbie
> Fix For: 2.3
>
>
> Sometimes it is handy to clear node local map on Ignite nodes esp when 
> testing some functionality.



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

[jira] [Commented] (IGNITE-6253) .NET: Replace Doxygen with DocFX for API documentation generation

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-6253:


This mechanism is perfect for migrating from readme.io, by the way.

> .NET: Replace Doxygen with DocFX for API documentation generation
> -
>
> Key: IGNITE-6253
> URL: https://issues.apache.org/jira/browse/IGNITE-6253
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Doxygen has recently became very slow on our code base (can take up to 30 
> minutes), and there seems to be no solution to this problem. There are other 
> issues: documentation is a bit ugly, customization possibilities are limited, 
> C# is not a first-class citizen there.
> [DocFX|https://dotnet.github.io/docfx/] looks like an obvious replacement:
> * It is a go-to documentation generator for .NET (included in .NET Foundation)
> * Documentation looks nice (MSDN-like) out of the box
> * Migration seems to be easy enough
> To do:
> * Remove {{Package-Info.cs}} files, they don't make sense



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

[jira] [Commented] (IGNITE-6253) .NET: Replace Doxygen with DocFX for API documentation generation

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-6253:


DocFX has been set up, demo is here: 
https://ptupitsyn.github.io/docfx-test/api/index.html

> .NET: Replace Doxygen with DocFX for API documentation generation
> -
>
> Key: IGNITE-6253
> URL: https://issues.apache.org/jira/browse/IGNITE-6253
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Doxygen has recently became very slow on our code base (can take up to 30 
> minutes), and there seems to be no solution to this problem. There are other 
> issues: documentation is a bit ugly, customization possibilities are limited, 
> C# is not a first-class citizen there.
> [DocFX|https://dotnet.github.io/docfx/] looks like an obvious replacement:
> * It is a go-to documentation generator for .NET (included in .NET Foundation)
> * Documentation looks nice (MSDN-like) out of the box
> * Migration seems to be easy enough
> To do:
> * Remove {{Package-Info.cs}} files, they don't make sense



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

[jira] [Commented] (IGNITE-425) Introduce transformers for continuous queries

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-425:


Hello, [~ntikhonov] 

I discuss changes with community

http://apache-ignite-developers.2346864.n4.nabble.com/ContinuousQueryWithTransformer-implementation-questions-2-td21418.html#a21673

Decisions:

# Introduce base class for ContinuousQuery to prevent code duplication - 
\[DONE\]
# Keep current implementation of exception handling
## filter exception treats as `true`
## transformer exception treats as `null`
# Start another dev-list discussion to make exception handling clear both in 
regular ContinuousQuery and in ContinuousQueryWithTransformer.

Can you continue reviewing my PR?
Should I merge my PR with lates master?

> Introduce transformers for continuous queries
> -
>
> Key: IGNITE-425
> URL: https://issues.apache.org/jira/browse/IGNITE-425
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Reporter: Yakov Zhdanov
>Assignee: Nikolay Izhikov
>
> Currently if updated entry passes the filter, it is sent to node initiated 
> the query entirely. It would be good to provide user with the ability to 
> transform entry and, for example, select only fields that are important. This 
> may bring huge economy to traffic and lower GC pressure as well.
> Possible signatures will be:
> {noformat}
> public final class ContinuousQuery {..} // T is a type transformer 
> transforms to
> public ContinuousQuery setLocalListener(Listener locLsnr) {..} // 
> Probably, we will have to introduce new listener type, since user may want to 
> wipe out key as well.
> /* new method to add */
> public ContinuousQuery setRemoteTransformerFactory(Factory ContinuousQueryTransformer> factory) { ..}
> {noformat}



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

[jira] [Comment Edited] (IGNITE-425) Introduce transformers for continuous queries

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov edited comment on IGNITE-425 at 9/4/17 12:57 PM:
-

Hello, [~ntikhonov] 

I discuss changes with community

http://apache-ignite-developers.2346864.n4.nabble.com/ContinuousQueryWithTransformer-implementation-questions-2-td21418.html#a21673

Decisions:

# Introduce base class for ContinuousQuery to prevent code duplication - 
\[DONE\]
# Keep current implementation of exception handling
## filter exception treats as `true`
## transformer exception treats as `null`
# Start another dev-list discussion to make exception handling clear both in 
regular ContinuousQuery and in ContinuousQueryWithTransformer.

Can you continue reviewing my PR?
Should I merge my PR with latest master?


was (Author: nizhikov):
Hello, [~ntikhonov] 

I discuss changes with community

http://apache-ignite-developers.2346864.n4.nabble.com/ContinuousQueryWithTransformer-implementation-questions-2-td21418.html#a21673

Decisions:

# Introduce base class for ContinuousQuery to prevent code duplication - 
\[DONE\]
# Keep current implementation of exception handling
## filter exception treats as `true`
## transformer exception treats as `null`
# Start another dev-list discussion to make exception handling clear both in 
regular ContinuousQuery and in ContinuousQueryWithTransformer.

Can you continue reviewing my PR?
Should I merge my PR with lates master?

> Introduce transformers for continuous queries
> -
>
> Key: IGNITE-425
> URL: https://issues.apache.org/jira/browse/IGNITE-425
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Reporter: Yakov Zhdanov
>Assignee: Nikolay Izhikov
>
> Currently if updated entry passes the filter, it is sent to node initiated 
> the query entirely. It would be good to provide user with the ability to 
> transform entry and, for example, select only fields that are important. This 
> may bring huge economy to traffic and lower GC pressure as well.
> Possible signatures will be:
> {noformat}
> public final class ContinuousQuery {..} // T is a type transformer 
> transforms to
> public ContinuousQuery setLocalListener(Listener locLsnr) {..} // 
> Probably, we will have to introduce new listener type, since user may want to 
> wipe out key as well.
> /* new method to add */
> public ContinuousQuery setRemoteTransformerFactory(Factory ContinuousQueryTransformer> factory) { ..}
> {noformat}



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

[jira] [Commented] (IGNITE-2779) BinaryMarshaller caches must be cleaned during client reconnect.

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-2779:
--

[~NSAmelchev], 
Looks good to me.

[~vozerov],
Could you please make final review?

> BinaryMarshaller caches must be cleaned during client reconnect.
> 
>
> Key: IGNITE-2779
> URL: https://issues.apache.org/jira/browse/IGNITE-2779
> Project: Ignite
>  Issue Type: Task
>  Components: cache, general
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Amelchev Nikita
>  Labels: community
> Fix For: 2.3
>
> Attachments: IgniteProblemTest.java
>
>
> The problem is originally reported by Vinay Sharma here: 
> http://apache-ignite-users.70518.x6.nabble.com/changed-cache-configuration-and-restarted-server-nodes-Getting-exception-td3064.html#none
> *Root cause*:
> When client is reconnected to topology after full topology restart (i.e. all 
> server nodes were down), it doesn't re-send binary metadata to topology. As a 
> result, {{BinaryMarshaller}} exception occurs.
> *Steps to reproduce*
> Run attached code.
> *Proposed solution*
> Clean cached binary metadata during re-connect.



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

[jira] [Commented] (IGNITE-5998) Assertion during partition creation in tests

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-5998:
--

[~Alexey Kuznetsov],
This can be flaky. You need to check 2.1.

> Assertion during partition creation in tests
> 
>
> Key: IGNITE-5998
> URL: https://issues.apache.org/jira/browse/IGNITE-5998
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
>
> It was cause of hang of 
> DynamicIndexReplicatedAtomicConcurrentSelfTest.testQueryConsistencyMultithreaded
> {code}
> [2017-08-08 
> 19:02:01,877][ERROR][exchange-worker-#4300529%index.DynamicIndexReplicatedAtomicConcurrentSelfTest1%][CacheAffinitySharedManager]
>  Failed to initialize cache. Will try to rollback cache start routine. 
> [cacheName=cache]
> class org.apache.ignite.IgniteCheckedException: Failed to register MBean for 
> component: 
> org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl@4d0397a2
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.registerMbean(GridCacheProcessor.java:3624)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCache(GridCacheProcessor.java:1637)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1863)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:742)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:739)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:468)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1954)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.management.InstanceAlreadyExistsException: 
> org.apache:clsLdr=6d06d69c,igniteInstanceName=index.DynamicIndexReplicatedAtomicConcurrentSelfTest1,group=cache,name=org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl
>   at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.registerCacheMBean(IgniteUtils.java:4574)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.registerMbean(GridCacheProcessor.java:3620)
>   ... 8 more
> [2017-08-08 
> 19:02:01,878][ERROR][exchange-worker-#4300529%index.DynamicIndexReplicatedAtomicConcurrentSelfTest1%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=4, 
> minorTopVer=1], discoEvt=DiscoveryCustomEvent 
> [customMsg=DynamicCacheChangeBatch 
> [id=2490c129e51-bbb352cc-e911-41e1-afd6-67e8ed91809c, 
> reqs=[DynamicCacheChangeRequest [cacheName=cache, hasCfg=true, 
> nodeId=fdc8ffc4-3da3-470e-a8ac-5f8b4204, clientStartOnly=false, 
> stop=false, destroy=false]], exchangeActions=ExchangeActions 
> [startCaches=[cache], stopCaches=null, startGrps=[cache], stopGrps=[], 
> resetParts=null, stateChangeRequest=null], startCaches=false], 
> affTopVer=AffinityTopologyVersion [topVer=4, minorTopVer=1], 
> super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=fdc8ffc4-3da3-470e-a8ac-5f8b4204, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:0], discPort=0, order=4, intOrder=4, 
> lastExchangeTime=1502208121825, loc=false, ver=2.2.0#19700101-sha1:, 
> isClient=true], topVer=4, nodeId8=0e697ca6, msg=null, 
> type=DISCOVERY_CUSTOM_EVT, tstamp=1502208121873]], nodeId=fdc8ffc4, 
> evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError
>   at 
> 

[jira] [Created] (IGNITE-6258) .NET: Thin client: Define metadata exchange protocol

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-6258:
--

 Summary: .NET: Thin client: Define metadata exchange protocol
 Key: IGNITE-6258
 URL: https://issues.apache.org/jira/browse/IGNITE-6258
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.3


IGNITE-6236 introduced some metadata operations in client protocol.
Let's formalize these operations:
* Which operations should be present? PutMeta, PutMetas, GetMeta, GetSchema, 
etc.
* Do we need to retrieve schemas separately from entire metadata?
* Dynamic type registration



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

[jira] [Commented] (IGNITE-6236) .NET: Thin client: cache.Get and Put for user types

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-6236:


Separate ticket for proper metadata handling: IGNITE-6258

> .NET: Thin client: cache.Get and Put for user types
> ---
>
> Key: IGNITE-6236
> URL: https://issues.apache.org/jira/browse/IGNITE-6236
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Cache operations on user types require proper metadata handling. Make sure 
> dynamic type registration works.



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

[jira] [Commented] (IGNITE-5998) Assertion during partition creation in tests

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-5998:
--

as I can see this test is [green 
now|https://ci.ignite.apache.org/viewLog.html?buildId=807668=Ignite20Tests_IgniteQueries2=testsInfo]

> Assertion during partition creation in tests
> 
>
> Key: IGNITE-5998
> URL: https://issues.apache.org/jira/browse/IGNITE-5998
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
>
> It was cause of hang of 
> DynamicIndexReplicatedAtomicConcurrentSelfTest.testQueryConsistencyMultithreaded
> {code}
> [2017-08-08 
> 19:02:01,877][ERROR][exchange-worker-#4300529%index.DynamicIndexReplicatedAtomicConcurrentSelfTest1%][CacheAffinitySharedManager]
>  Failed to initialize cache. Will try to rollback cache start routine. 
> [cacheName=cache]
> class org.apache.ignite.IgniteCheckedException: Failed to register MBean for 
> component: 
> org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl@4d0397a2
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.registerMbean(GridCacheProcessor.java:3624)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCache(GridCacheProcessor.java:1637)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1863)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:742)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:739)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:468)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1954)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.management.InstanceAlreadyExistsException: 
> org.apache:clsLdr=6d06d69c,igniteInstanceName=index.DynamicIndexReplicatedAtomicConcurrentSelfTest1,group=cache,name=org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl
>   at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.registerCacheMBean(IgniteUtils.java:4574)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.registerMbean(GridCacheProcessor.java:3620)
>   ... 8 more
> [2017-08-08 
> 19:02:01,878][ERROR][exchange-worker-#4300529%index.DynamicIndexReplicatedAtomicConcurrentSelfTest1%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=4, 
> minorTopVer=1], discoEvt=DiscoveryCustomEvent 
> [customMsg=DynamicCacheChangeBatch 
> [id=2490c129e51-bbb352cc-e911-41e1-afd6-67e8ed91809c, 
> reqs=[DynamicCacheChangeRequest [cacheName=cache, hasCfg=true, 
> nodeId=fdc8ffc4-3da3-470e-a8ac-5f8b4204, clientStartOnly=false, 
> stop=false, destroy=false]], exchangeActions=ExchangeActions 
> [startCaches=[cache], stopCaches=null, startGrps=[cache], stopGrps=[], 
> resetParts=null, stateChangeRequest=null], startCaches=false], 
> affTopVer=AffinityTopologyVersion [topVer=4, minorTopVer=1], 
> super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=fdc8ffc4-3da3-470e-a8ac-5f8b4204, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:0], discPort=0, order=4, intOrder=4, 
> lastExchangeTime=1502208121825, loc=false, ver=2.2.0#19700101-sha1:, 
> isClient=true], topVer=4, nodeId8=0e697ca6, msg=null, 
> type=DISCOVERY_CUSTOM_EVT, tstamp=1502208121873]], nodeId=fdc8ffc4, 
> evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError
>   at 
> 

[jira] [Resolved] (IGNITE-6257) non thread safe assertion exception while processDhtTxFinishRequest

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny resolved IGNITE-6257.

Resolution: Duplicate

duplicate https://issues.apache.org/jira/browse/IGNITE-6254

> non thread safe assertion exception while processDhtTxFinishRequest
> ---
>
> Key: IGNITE-6257
> URL: https://issues.apache.org/jira/browse/IGNITE-6257
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.9
>Reporter: Stanilovsky Evgeny
>Assignee: Sergey Chugunov
>
> this place :
> {code}
> assert req.txState() != null || (ctx.tm().tx(req.version()) == null && 
> ctx.tm().nearTx(req.version()) == null);
> {code}
> additionally while this assert arise, condition not obviously can be 
> understand.



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

[jira] [Created] (IGNITE-6257) non thread safe assertion exception while processDhtTxFinishRequest

[Stanilovsky Evgeny (JIRA)]

Stanilovsky Evgeny created IGNITE-6257:
--

 Summary: non thread safe assertion exception while 
processDhtTxFinishRequest
 Key: IGNITE-6257
 URL: https://issues.apache.org/jira/browse/IGNITE-6257
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.9
Reporter: Stanilovsky Evgeny
Assignee: Sergey Chugunov


this place :

{code}
assert req.txState() != null || (ctx.tm().tx(req.version()) == null && 
ctx.tm().nearTx(req.version()) == null);
{code}

additionally while this assert arise, condition not obviously can be understand.



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

[jira] [Commented] (IGNITE-3987) ODBC: Improve error output when query parsing failed.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-3987:
-

[~isapego], looks good to me. Please go ahead with merge.

> ODBC: Improve error output when query parsing failed.
> -
>
> Key: IGNITE-3987
> URL: https://issues.apache.org/jira/browse/IGNITE-3987
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>Priority: Minor
>  Labels: usability
> Fix For: 2.3
>
>
> Currently if an error occurred we only prints the top-level message, like 
> "Failed to parse query ...". The problem is that we do not explain users why 
> exactly it failed.
> Looks like we need to add more info on Java side when sending error response.



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

[jira] [Assigned] (IGNITE-5999) Assertion fails: Moving partition is below zero

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh reassigned IGNITE-5999:


Assignee: Andrey Gura  (was: Ilya Lantukh)

[~agura],
Please review.

> Assertion fails: Moving partition is below zero
> ---
>
> Key: IGNITE-5999
> URL: https://issues.apache.org/jira/browse/IGNITE-5999
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Andrey Gura
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.3
>
>
> It was found during 
> org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheQueryNodeRestartSelfTest2#testRestarts
>  execution
> {code}
> java.lang.AssertionError: -10
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap.hasMovingPartitions(GridDhtPartitionMap.java:135)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.hasMovingPartitions(GridDhtPartitionTopologyImpl.java:2116)
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.hasMovingPartitions(GridReduceQueryExecutor.java:366)
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.isPreloadingActive(GridReduceQueryExecutor.java:354)
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:577)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1160)
>   at 
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
>   at 
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:114)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheQueryNodeRestartSelfTest2$1.applyx(IgniteCacheQueryNodeRestartSelfTest2.java:247)
>   at 
> org.apache.ignite.internal.util.lang.GridAbsClosureX.apply(GridAbsClosureX.java:35)
>   at 
> org.apache.ignite.internal.util.lang.GridAbsClosure.run(GridAbsClosure.java:50)
>   at 
> org.apache.ignite.testframework.GridTestUtils$9.call(GridTestUtils.java:1236)
>   at 
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {code}



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

[jira] [Updated] (IGNITE-3987) ODBC: Improve error output when query parsing failed.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3987:

Labels: usability  (was: )

> ODBC: Improve error output when query parsing failed.
> -
>
> Key: IGNITE-3987
> URL: https://issues.apache.org/jira/browse/IGNITE-3987
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>Priority: Minor
>  Labels: usability
> Fix For: 2.3
>
>
> Currently if an error occurred we only prints the top-level message, like 
> "Failed to parse query ...". The problem is that we do not explain users why 
> exactly it failed.
> Looks like we need to add more info on Java side when sending error response.



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

[jira] [Issue Comment Deleted] (IGNITE-4908) Ignite.reentrantLock looks much slower than IgniteCache.lock.

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov updated IGNITE-4908:

Comment: was deleted

(was: May be Later I will look at our lock implementations. Right now I wrote 
benchmark IgniteCache.lock(...) vs Ignite.reentrantLock(...). There are results:

//Ignite.reentrantLock(...)
Benchmark   (create)  (failoverSafe)  (fair)   Mode 
 Cnt Score Error  Units
JmhCacheLocksBenchmark.testIgniteLocks  truetruetrue  thrpt 
  10   873,775 ±  60,388  ops/s
JmhCacheLocksBenchmark.testIgniteLocks  truetrue   false  thrpt 
  10  1177,804 ± 162,082  ops/s
JmhCacheLocksBenchmark.testIgniteLocks  true   falsetrue  thrpt 
  10   915,579 ±  42,631  ops/s
JmhCacheLocksBenchmark.testIgniteLocks  true   false   false  thrpt 
  10  1176,044 ± 108,950  ops/s
JmhCacheLocksBenchmark.testIgniteLocks falsetruetrue  thrpt 
  10   926,890 ±  37,080  ops/s
JmhCacheLocksBenchmark.testIgniteLocks falsetrue   false  thrpt 
  10  1195,663 ±  73,578  ops/s
JmhCacheLocksBenchmark.testIgniteLocks false   falsetrue  thrpt 
  10   903,658 ±  78,483  ops/s
JmhCacheLocksBenchmark.testIgniteLocks false   false   false  thrpt 
  10  1159,586 ±  81,717  ops/s
//IgniteCache.lock(...)
Benchmark   Mode  Cnt Score Error  Units
JmhCacheLocksBenchmark.testCacheLocks  thrpt   10  8076,522 ± 786,153  ops/s

Looks like IgniteCache.lock(...) faster than Ignite.reentrantLock(...) at ~8 
times.
I will investigate the reason.)

> Ignite.reentrantLock looks much slower than IgniteCache.lock.
> -
>
> Key: IGNITE-4908
> URL: https://issues.apache.org/jira/browse/IGNITE-4908
> Project: Ignite
>  Issue Type: Improvement
>  Components: data structures
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Alexander Menshikov
> Fix For: 2.3
>
>
> Design discussed with Alexander:
> 1) Lock 
> Entry Processor (sync) -> 
> add candidate. 
> returns "added candidate at first position"
> retry failover -> 
> if already at first position -> return true
> In case lock not acquired, wait for acquire (AbstractQueuedSynchronizer 
> should be used).
> 2) Unlock 
> Entry Processor (async) -> 
> remove candidate at first position
> retry failover -> remove only if "candidate at first position" equals to 
> expected
> listener ->
> notify current "candidate at first position" it got lock
> 3)Failover
> 3.1) Originating node failed
> Failed node listener ->
> For each local(primary) lock ->
> Entry Processor (async) ->
> remove candidates related no failed node
> retry failover not needed
> listener -> 
> if "candidate at first position" removed ->
> notify current "candidate at first position" it got lock
> 3.2) Primary node failed
> After rebalancing schedule Callable ->
> For each local(primary) lock ->
> Entry Processor (async) ->
> remove candidates related to failed nodes
> retry failover not needed
> listener -> 
> notify current "candidate at first position" it got lock



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

[jira] [Updated] (IGNITE-6253) .NET: Replace Doxygen with DocFX for API documentation generation

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-6253:
---
Description: 
Doxygen has recently became very slow on our code base (can take up to 30 
minutes), and there seems to be no solution to this problem. There are other 
issues: documentation is a bit ugly, customization possibilities are limited, 
C# is not a first-class citizen there.

[DocFX|https://dotnet.github.io/docfx/] looks like an obvious replacement:
* It is a go-to documentation generator for .NET (included in .NET Foundation)
* Documentation looks nice (MSDN-like) out of the box
* Migration seems to be easy enough

To do:
* Remove {{Package-Info.cs}} files, they don't make sense

  was:
Doxygen has recently became very slow on our code base (can take up to 30 
minutes), and there seems to be no solution to this problem. There are other 
issues: documentation is a bit ugly, customization possibilities are limited, 
C# is not a first-class citizen there.

[DocFX|https://dotnet.github.io/docfx/] looks like an obvious replacement:
* It is a go-to documentation generator for .NET (included in .NET Foundation)
* Documentation looks nice (MSDN-like) out of the box
* Migration seems to be easy enough


> .NET: Replace Doxygen with DocFX for API documentation generation
> -
>
> Key: IGNITE-6253
> URL: https://issues.apache.org/jira/browse/IGNITE-6253
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Doxygen has recently became very slow on our code base (can take up to 30 
> minutes), and there seems to be no solution to this problem. There are other 
> issues: documentation is a bit ugly, customization possibilities are limited, 
> C# is not a first-class citizen there.
> [DocFX|https://dotnet.github.io/docfx/] looks like an obvious replacement:
> * It is a go-to documentation generator for .NET (included in .NET Foundation)
> * Documentation looks nice (MSDN-like) out of the box
> * Migration seems to be easy enough
> To do:
> * Remove {{Package-Info.cs}} files, they don't make sense



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

[jira] [Updated] (IGNITE-6256) When a node becomes segmented an AssertionError is thrown during GridDhtPartitionTopologyImpl.removeNode

[Alexandr Fedotov (JIRA)]

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

Alexandr Fedotov updated IGNITE-6256:
-
Description: 
The assert is as follows:

exception="java.lang.AssertionError: null
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.removeNode(GridDhtPartitionTopologyImpl.java:1422)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.beforeExchange(GridDhtPartitionTopologyImpl.java:490)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:769)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:504)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1689)
 at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
 at java.lang.Thread.run(Thread.java:745)

Below is the sequence of steps that leads to the assertion error:

1) A node becomes SEGMENTED when it's determined by SegmentCheckWorker, after 
an EVT_NODE_FAILED has been received.
2) It gets visibleRemoteNodes from it's TcpDiscoveryNodesRing
3) Clears the TcpDiscoveryNodesRing leaving only self on the list. The node 
ring is used to determine if a node is alive
during DiscoCache creation
4) After that, the node initiates removal of all the nodes read in step 2
5) For each node, it sends an EVT_NODE_FAILED to the corresponding 
DiscoverySpiListener
providing a topology containing all the nodes except already processed
6) This event gets into GridDiscoveryManager 
7) The node gets removed from alive nodes for every DiscoCache in discoCacheHist
8) Topology change is detected
9) Creation of a new DiscoCache is attempted. At this moment every remote node 
is not available due to the
TcpDiscoveryNodesRing has been cleared, thus resulting in a DiscoCache with 
empty alives
10) The event with the created DiscoCache and the new topology version is 
passed to DiscoveryWorker
11) The event is eventually handled by DiscoveryWorker and is recorded by 
DiscoveryWorker#recordEvent
12) The recording is handled by GridEventStorageManager which notifies every 
listener for this event type (EVT_NODE_FAILED)
13) One of the listeners is GridCachePartitionExchangeManager#discoLsnr
It creates a new GridDhtPartitionsExchangeFuture with the empty DiscoCache 
received with the event and enqueues it
14) The future gets eventually handled by GridDhtPartitionsExchangeFuture and 
initialized
15) updateTopologies is called, which for each GridCacheContext gets its 
topology (GridDhtPartitionTopology)
and calls GridDhtPartitionTopology#updateTopologyVersion
16) DiscoCache for GridDhtPartitionTopology is assigned from the one of the 
GridDhtPartitionsExchangeFuture.
The assigned DiscoCache has empty alives at the moment
15) A distributed exchange is handled 
(GridDhtPartitionsExchangeFuture#distributedExchange)
16) For each cache context GridCacheContext, for its topology 
(GridDhtPartitionTopologyImpl) GridDhtPartitionTopologyImpl#beforeExchange is 
called
17) The fact that the node has left is determined and 
GridDhtPartitionTopologyImpl#removeNode is called to handle it
18) An attempt is made to get the alive coordinator node by calling 
DiscoCache#oldestAliveServerNode
19) null is returned which results in an AssertionError

The fix should probably prevent initiating exchange futures if a node has 
segmented.

  was:
Below is the sequence of steps that leads to the assertion:

1) A node becomes SEGMENTED when it's determined by SegmentCheckWorker, after 
an EVT_NODE_FAILED has been received.
2) It gets visibleRemoteNodes from it's TcpDiscoveryNodesRing
3) Clears the TcpDiscoveryNodesRing leaving only self on the list. The node 
ring is used to determine if a node is alive
during DiscoCache creation
4) After that, the node initiates removal of all the nodes read in step 2
5) For each node, it sends an EVT_NODE_FAILED to the corresponding 
DiscoverySpiListener
providing a topology containing all the nodes except already processed
6) This event gets into GridDiscoveryManager 
7) The node gets removed from alive nodes for every DiscoCache in discoCacheHist
8) Topology change is detected
9) Creation of a new DiscoCache is attempted. At this moment every remote node 
is not available due to the
TcpDiscoveryNodesRing has been cleared, thus resulting in a DiscoCache with 
empty alives
10) The event with the created DiscoCache and the new topology version is 
passed to DiscoveryWorker
11) The event is eventually handled by DiscoveryWorker and is recorded by 
DiscoveryWorker#recordEvent
12) The recording is handled by GridEventStorageManager which notifies every 
listener for this 

[jira] [Created] (IGNITE-6256) When a node becomes segmented an AssertionError is thrown during GridDhtPartitionTopologyImpl.removeNode

[Alexandr Fedotov (JIRA)]

Alexandr Fedotov created IGNITE-6256:


 Summary: When a node becomes segmented an AssertionError is thrown 
during GridDhtPartitionTopologyImpl.removeNode
 Key: IGNITE-6256
 URL: https://issues.apache.org/jira/browse/IGNITE-6256
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.8
Reporter: Alexandr Fedotov
 Fix For: 2.3


Below is the sequence of steps that leads to the assertion:

1) A node becomes SEGMENTED when it's determined by SegmentCheckWorker, after 
an EVT_NODE_FAILED has been received.
2) It gets visibleRemoteNodes from it's TcpDiscoveryNodesRing
3) Clears the TcpDiscoveryNodesRing leaving only self on the list. The node 
ring is used to determine if a node is alive
during DiscoCache creation
4) After that, the node initiates removal of all the nodes read in step 2
5) For each node, it sends an EVT_NODE_FAILED to the corresponding 
DiscoverySpiListener
providing a topology containing all the nodes except already processed
6) This event gets into GridDiscoveryManager 
7) The node gets removed from alive nodes for every DiscoCache in discoCacheHist
8) Topology change is detected
9) Creation of a new DiscoCache is attempted. At this moment every remote node 
is not available due to the
TcpDiscoveryNodesRing has been cleared, thus resulting in a DiscoCache with 
empty alives
10) The event with the created DiscoCache and the new topology version is 
passed to DiscoveryWorker
11) The event is eventually handled by DiscoveryWorker and is recorded by 
DiscoveryWorker#recordEvent
12) The recording is handled by GridEventStorageManager which notifies every 
listener for this event type (EVT_NODE_FAILED)
13) One of the listeners is GridCachePartitionExchangeManager#discoLsnr
It creates a new GridDhtPartitionsExchangeFuture with the empty DiscoCache 
received with the event and enqueues it
14) The future gets eventually handled by GridDhtPartitionsExchangeFuture and 
initialized
15) updateTopologies is called, which for each GridCacheContext gets its 
topology (GridDhtPartitionTopology)
and calls GridDhtPartitionTopology#updateTopologyVersion
16) DiscoCache for GridDhtPartitionTopology is assigned from the one of the 
GridDhtPartitionsExchangeFuture.
The assigned DiscoCache has empty alives at the moment
15) A distributed exchange is handled 
(GridDhtPartitionsExchangeFuture#distributedExchange)
16) For each cache context GridCacheContext, for its topology 
(GridDhtPartitionTopologyImpl) GridDhtPartitionTopologyImpl#beforeExchange is 
called
17) The fact that the node has left is determined and 
GridDhtPartitionTopologyImpl#removeNode is called to handle it
18) An attempt is made to get the alive coordinator node by calling 
DiscoCache#oldestAliveServerNode
19) null is returned which results in an AssertionError

The fix should probably prevent initiating exchange futures if a node has 
segmented.



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

[jira] [Commented] (IGNITE-6220) Values of types int and long[] are not delivered via JDBC

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-6220:
-

Hi [~pranas], 
An issue with {{long[]}} is fixed in master. Everything should work fine now. 
Please let us know if you still experiencing any problems.

> Values of types int and long[] are not delivered via JDBC
> -
>
> Key: IGNITE-6220
> URL: https://issues.apache.org/jira/browse/IGNITE-6220
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc
>Affects Versions: 2.1
>Reporter: Pranas Baliuka
>Assignee: Taras Ledkov
>  Labels: arrays
> Fix For: 2.3
>
> Attachments: Screen Shot 2017-08-30 at 16.19.25.png
>
>
> I've tried Low GC prototype to populate collocated server node without 
> replication and access it via JDBC.
> Issues detected:
> * The JDBC column "TIME" with type long[] is not delivered;
> * Duplicate entries in the result set;
> * Key column of type int is used for filtering, but not delivered to the JDBC 
> Record set.
> To reproduce:
> [Git:https://github.com/pranasblk/ignite-not-flushing/tree/MIssingJDBCTypes]
> * Run IgniteNode main
> * Run JDBC main / or connect via favourite JDBC supporting client



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

[jira] [Commented] (IGNITE-6170) JDBC: consistent product name across all drivers

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6170:


Github user asfgit closed the pull request at:

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


> JDBC: consistent product name across all drivers
> 
>
> Key: IGNITE-6170
> URL: https://issues.apache.org/jira/browse/IGNITE-6170
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Roman Shtykh
>  Labels: usability
> Fix For: 2.3
>
>
> We have 3 JDBC drivers. Some of them report 
> {{DatabaseMetaData#getDatabaseProductName}} as *Ignite*, others as *Ignite 
> Cache*. Neither are correct. 
> It should be *Apache Ignite*.



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

[jira] [Commented] (IGNITE-6237) Script for signing and uploading artifacts to remote staging.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6237:


GitHub user oleg-ostanin opened a pull request:

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

IGNITE-6237 created script for signing and uploading artifacts to rem…

…ote staging.

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

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

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

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


commit 991ca6af905bb2115ad39972a7aedfce27634a54
Author: oleg-ostanin 
Date:   2017-09-04T10:57:55Z

IGNITE-6237 created script for signing and uploading artifacts to remote 
staging.




> Script for signing and uploading artifacts to remote staging.
> -
>
> Key: IGNITE-6237
> URL: https://issues.apache.org/jira/browse/IGNITE-6237
> Project: Ignite
>  Issue Type: Sub-task
>  Components: build
>Reporter: Oleg Ostanin
>Assignee: Oleg Ostanin
> Fix For: 2.3
>
>
> Create script for signing artifacts in locally staged repository and 
> uploading to the remote staging.



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

[jira] [Commented] (IGNITE-6139) JDBC driver should return actual values for get*Version()

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6139:


Github user asfgit closed the pull request at:

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


> JDBC driver should return actual values for get*Version()
> -
>
> Key: IGNITE-6139
> URL: https://issues.apache.org/jira/browse/IGNITE-6139
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc
>Affects Versions: 2.1
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
> Fix For: 2.3
>
>
> Right now it returns:
> Database version 1.0 (suggested - actual version from server nodes)
> JDBC version 1.0 (suggested - 4.1, that's what's in Java 7)
> Driver version 1.0 (suggested - actual version of running Ignite code)
> Database product name is "Ignite Cache", probably keep that.



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

[jira] [Updated] (IGNITE-6242) Passing custom cache name to CREATE TABLE

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-6242:

Description: 
CREATE TABLE automatically creates an IgniteCache naming it 
SQL_PUBLIC_\{TABLE\}. So, if a Person table is created you’ll have 
SQL_PUBLIC_PERSON cache in the cluster.

If we keep to SQL APIs the cache name is not a big deal but as soon as 
key-value, compute, service grid APIs are needed the cache name will be used 
here and there looking bizarre.

Let's give a way to pass the cache name into WITH clause parameters set

  was:
CREATE TABLE automatically creates an IgniteCache naming it SQL_PUBLIC_{TABLE}. 
So, if a Person table is created you’ll have SQL_PUBLIC_PERSON cache in the 
cluster.

If we keep to SQL APIs the cache name is not a big deal but as soon as 
key-value, compute, service grid APIs are needed the cache name will be used 
here and there looking bizarre.

Let's give a way to pass the cache name into WITH clause parameters set


> Passing custom cache name to CREATE TABLE
> -
>
> Key: IGNITE-6242
> URL: https://issues.apache.org/jira/browse/IGNITE-6242
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.1
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Critical
>  Labels: usability
> Fix For: 2.3
>
>
> CREATE TABLE automatically creates an IgniteCache naming it 
> SQL_PUBLIC_\{TABLE\}. So, if a Person table is created you’ll have 
> SQL_PUBLIC_PERSON cache in the cluster.
> If we keep to SQL APIs the cache name is not a big deal but as soon as 
> key-value, compute, service grid APIs are needed the cache name will be used 
> here and there looking bizarre.
> Let's give a way to pass the cache name into WITH clause parameters set



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

[jira] [Commented] (IGNITE-5468) Need to set IGNITE_SQL_MERGE_TABLE_MAX_SIZE on per query basis

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-5468:
-

[~yzhdanov], [~amashenkov], [~daradurvs], [~VitaliyB], 
Folks, what is the rationale behind this change? I've never saw a single 
practical case when it was required to tune this very subtle property on 
per-query basis. Suppose that we added it. How user is going to understand when 
and how to tune it? 

I vote for closing this as won't fix. Too little value, too difficult to 
understand.

> Need to set IGNITE_SQL_MERGE_TABLE_MAX_SIZE on per query basis
> --
>
> Key: IGNITE-5468
> URL: https://issues.apache.org/jira/browse/IGNITE-5468
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Yakov Zhdanov
>Assignee: Vitaliy Biryukov
>Priority: Critical
>
> Currently this property can be set via sys property only thus changing it 
> will require restart of the cluster. I think it is better to set it on 
> perquery basis with some default that is configured via cache configuration.



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

[jira] [Updated] (IGNITE-6170) JDBC: consistent product name across all drivers

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6170:

Labels: usability  (was: )

> JDBC: consistent product name across all drivers
> 
>
> Key: IGNITE-6170
> URL: https://issues.apache.org/jira/browse/IGNITE-6170
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Roman Shtykh
>  Labels: usability
> Fix For: 2.3
>
>
> We have 3 JDBC drivers. Some of them report 
> {{DatabaseMetaData#getDatabaseProductName}} as *Ignite*, others as *Ignite 
> Cache*. Neither are correct. 
> It should be *Apache Ignite*.



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

[jira] [Updated] (IGNITE-5795) @AffinityKeyMapped ignored if QueryEntity used

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5795:

Component/s: sql

> @AffinityKeyMapped ignored if QueryEntity used
> --
>
> Key: IGNITE-5795
> URL: https://issues.apache.org/jira/browse/IGNITE-5795
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.0
>Reporter: Dmitry Karachentsev
>Assignee: Alexey Kukushkin
>  Labels: usability
> Fix For: 2.3
>
>
> When cache configured with QueryEntity and used key type with 
> @AffinityKeyMapped field, it will be ignored and wrong partition calculated. 
> This happens because QueryEntity processing precedes key type registering in 
> binary meta cache. On that step 
> CacheObjectBinaryProcessorImpl#affinityKeyField called and unable to resolve 
> type, so null returned and null putted in affKeyFields.
> On next put/get operation CacheObjectBinaryProcessorImpl#affinityKeyField 
> will return null from affKeyFields, but should be affinity key field.
> Test that reproduces problem in [PR 
> 2330|https://github.com/apache/ignite/pull/2330]
> To wrorkaround the issue, set IgniteConfiguration#setKeyConfiguration(), it 
> will force registering key.



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

[jira] [Updated] (IGNITE-4172) SQL: Add support for Java 8 Time API classes in date\time functions

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4172:

Labels: usability  (was: )

> SQL: Add support for Java 8 Time API classes in date\time functions
> ---
>
> Key: IGNITE-4172
> URL: https://issues.apache.org/jira/browse/IGNITE-4172
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.0
>Reporter: Andrew Mashenkov
>Assignee: Alexandr Fedotov
>  Labels: usability
> Fix For: 2.3
>
>
> We have is issue with querying LocalDateTime objects with our SQL engine. 
> Next query can fails with error, if one of row localDateTimeField value has 
> zero-time: 
> select DATEDIFF('DAY', localDateTimeField, CURRENT_DATE ()) from t;
> Startpoint is IgniteH2Indexing.wrap() method. 
> We need add support to these classes: LocalDate, LocalTime, LocalDateTime.



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

[jira] [Updated] (IGNITE-5620) Meaningful error codes and types of exceptions for SQL operations

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5620:

Labels: usability  (was: )

> Meaningful error codes and types of exceptions for SQL operations 
> --
>
> Key: IGNITE-5620
> URL: https://issues.apache.org/jira/browse/IGNITE-5620
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>  Labels: usability
> Fix For: 2.3
>
>
> Presently, SQL engine throws a generic type of exception with custom text in 
> case of an operation failure. In result, Ignite ODBC driver returns a similar 
> error code (2000) for different kind of failures.
> For example, error code 2000 is returned for the following
> {code}
> Duplicate key during INSERT [key=CorpcontactcountKey [idHash=1412656257, 
> hash=2004096461, mdn=9192]] 
> {code}
> {code}
> Failed to parse query: INSERT INTO "DG".Corpcontactcount 
> (mdn,contactcount,lastupdatetime)
> values(?,?,?,?) 
> {code}
> {code}
> Wrong value has been set [typeName=Pocsubscrinfo, fieldName=vocoderid, 
> fieldType=short, assignedValueType=byte] Error Code: 2000
> {code}
> The following has to be done:
> * Create unique types of exceptions for Java whenever applicable.
> * Add {{errorCode}} parameter and method to a generic SQL exception.
> * ODBC and JDBC drivers have to return unique codes based on the exception 
> code or type.
> * All the codes have to be documented on readme.io. 



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

[jira] [Commented] (IGNITE-5839) Unclear exception from BinaryObjectBuilder::build call when builder is reused

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-5839:
--

[~sergey-chugunov]], would you please review a PR?

> Unclear exception from BinaryObjectBuilder::build call when builder is reused
> -
>
> Key: IGNITE-5839
> URL: https://issues.apache.org/jira/browse/IGNITE-5839
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Sergey Chugunov
>Assignee: Andrew Mashenkov
> Fix For: 2.3
>
> Attachments: Fix_BinaryObject_builder_reuse_issue_.patch
>
>
> Simple test where {{BinaryObjectBuilder}} builder object is reused fails with 
> exception {noformat}org.apache.ignite.binary.BinaryObjectException: Wrong 
> value has been set [typeName=SimpleCls, fieldName=str, fieldType=String, 
> assignedValueType=Object]{noformat}
> {noformat}
> IgniteCache cache = /* obtain a reference to 
> withKeepBinary cache instance */;
> BinaryObjectBuilder bldr = grid(0).binary().builder("SimpleCls");
> bldr.setField("str", "abc");
> c.put(0, bldr.build());
> bldr.setField("str", null);
> c.put(1, bldr.build());
> bldr.setField("str", "def");
> c.put(2, bldr.build()); //exception will be thrown by call 
> bldr.build()
> {noformat}
> It can be fixed by simply recreating BinaryObjectBuilder instead of reusing 
> the same instance. 
> However reusing builder object must be either explicitly prohibited or 
> exception must be fixed.
> Right now documentation on builder class says nothing about reusing this 
> object.



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

[jira] [Updated] (IGNITE-6197) SQL: QueryIndex.setInlineSize should return this instead of void

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6197:

Labels: usability  (was: )

> SQL: QueryIndex.setInlineSize should return this instead of void
> 
>
> Key: IGNITE-6197
> URL: https://issues.apache.org/jira/browse/IGNITE-6197
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>  Labels: usability
> Fix For: 2.3
>
>
> Subj. We messed up with return type.



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

[jira] [Commented] (IGNITE-6197) SQL: QueryIndex.setInlineSize should return this instead of void

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6197:


Github user asfgit closed the pull request at:

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


> SQL: QueryIndex.setInlineSize should return this instead of void
> 
>
> Key: IGNITE-6197
> URL: https://issues.apache.org/jira/browse/IGNITE-6197
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.3
>
>
> Subj. We messed up with return type.



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

[jira] [Commented] (IGNITE-6254) Assertion error in IgniteTxHandler.processDhtTxFinishRequest(...)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6254:


GitHub user ilantukh opened a pull request:

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

IGNITE-6254 : Fixed assertions for req.txState().



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

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

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

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


commit 79fc1a871710e2aa081852b7a9dfd8e05e0bc8c7
Author: Ilya Lantukh 
Date:   2017-09-04T10:21:06Z

ignite-6254 : Fixed assertions for req.txState().




> Assertion error in IgniteTxHandler.processDhtTxFinishRequest(...)
> -
>
> Key: IGNITE-6254
> URL: https://issues.apache.org/jira/browse/IGNITE-6254
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
> Fix For: 2.3
>
>
> AssertionError is thrown in the end of this method:
> {noformat}
> assert req.txState() != null || (ctx.tm().tx(req.version()) == null && 
> ctx.tm().nearTx(req.version()) == null);
> {noformat}
> This could happen only if results of calls to IgniteTxManager changed after 
> method execution started. We should re-use already aquired values:
> - replace ctx.tm().tx(...) call with dhtTx;
> - replace ctx.tml().nearTx(...) call with nearTx.



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

[jira] [Updated] (IGNITE-6255) .NET: Fix TestAffinityCall to take late affinity assignment into account

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-6255:
---
Labels: .NET MakeTeamcityGreenAgain  (was: .NET)

> .NET: Fix TestAffinityCall to take late affinity assignment into account
> 
>
> Key: IGNITE-6255
> URL: https://issues.apache.org/jira/browse/IGNITE-6255
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, MakeTeamcityGreenAgain
> Fix For: 2.3
>
>
> {{ComputeApiTest.TestAffinityCall}} fails because affinity assignment changes 
> during test execution. Find a way to handle this (either retry the test, or 
> wait for some cache event).



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

[jira] [Created] (IGNITE-6255) .NET: Fix TestAffinityCall to take late affinity assignment into account

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-6255:
--

 Summary: .NET: Fix TestAffinityCall to take late affinity 
assignment into account
 Key: IGNITE-6255
 URL: https://issues.apache.org/jira/browse/IGNITE-6255
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.3


{{ComputeApiTest.TestAffinityCall}} fails because affinity assignment changes 
during test execution. Find a way to handle this (either retry the test, or 
wait for some cache event).



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

[jira] [Updated] (IGNITE-5795) @AffinityKeyMapped ignored if QueryEntity used

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5795:

Labels: usability  (was: )

> @AffinityKeyMapped ignored if QueryEntity used
> --
>
> Key: IGNITE-5795
> URL: https://issues.apache.org/jira/browse/IGNITE-5795
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.0
>Reporter: Dmitry Karachentsev
>Assignee: Alexey Kukushkin
>  Labels: usability
> Fix For: 2.3
>
>
> When cache configured with QueryEntity and used key type with 
> @AffinityKeyMapped field, it will be ignored and wrong partition calculated. 
> This happens because QueryEntity processing precedes key type registering in 
> binary meta cache. On that step 
> CacheObjectBinaryProcessorImpl#affinityKeyField called and unable to resolve 
> type, so null returned and null putted in affKeyFields.
> On next put/get operation CacheObjectBinaryProcessorImpl#affinityKeyField 
> will return null from affKeyFields, but should be affinity key field.
> Test that reproduces problem in [PR 
> 2330|https://github.com/apache/ignite/pull/2330]
> To wrorkaround the issue, set IgniteConfiguration#setKeyConfiguration(), it 
> will force registering key.



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

[jira] [Created] (IGNITE-6254) Assertion error in IgniteTxHandler.processDhtTxFinishRequest(...)

[Ilya Lantukh (JIRA)]

Ilya Lantukh created IGNITE-6254:


 Summary: Assertion error in 
IgniteTxHandler.processDhtTxFinishRequest(...)
 Key: IGNITE-6254
 URL: https://issues.apache.org/jira/browse/IGNITE-6254
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Ilya Lantukh
Assignee: Ilya Lantukh
 Fix For: 2.3


AssertionError is thrown in the end of the method:
{noformat}
assert req.txState() != null || (ctx.tm().tx(req.version()) == null && 
ctx.tm().nearTx(req.version()) == null);
{noformat}
This could happen only if results of calls to IgniteTxManager changed after 
method execution started. We should re-use already aquired values:
- replace ctx.tm().tx(...) call with dhtTx;
- replace ctx.tml().nearTx(...) call with nearTx.



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

[jira] [Commented] (IGNITE-4931) Safe way for deactivate cluster

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-4931:
--

[~DmitriyGovorukhin] In test _testDeactivationWithPendingTransaction_ we wait 
transaction to complete, and then proceed deactivation. If we activate clust 
after deactivation, the result of transaction must be seen (the key-value must 
exist in cache). 
After deactivation, all cache data got removed, so we must safe ongoing 
transactions before deactivation, and restart them after activation. Could you 
change the description of task. May be we should create another task - to 
restart transactions after re-activation ?

> Safe way for deactivate cluster
> ---
>
> Key: IGNITE-4931
> URL: https://issues.apache.org/jira/browse/IGNITE-4931
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.0
>Reporter: Dmitriy Govorukhin
>Assignee: Alexey Kuznetsov
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.3
>
>
> We must provide safe way for deactivate cluster, i mean we must wait while 
> all cache operation, transaction and etc. comleted before start deactivation 
> process, in current implementation we do not wait while transaction comlete, 
> (forcibly stop cache during transaction).



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

[jira] [Updated] (IGNITE-6254) Assertion error in IgniteTxHandler.processDhtTxFinishRequest(...)

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh updated IGNITE-6254:
-
Description: 
AssertionError is thrown in the end of this method:
{noformat}
assert req.txState() != null || (ctx.tm().tx(req.version()) == null && 
ctx.tm().nearTx(req.version()) == null);
{noformat}
This could happen only if results of calls to IgniteTxManager changed after 
method execution started. We should re-use already aquired values:
- replace ctx.tm().tx(...) call with dhtTx;
- replace ctx.tml().nearTx(...) call with nearTx.

  was:
AssertionError is thrown in the end of the method:
{noformat}
assert req.txState() != null || (ctx.tm().tx(req.version()) == null && 
ctx.tm().nearTx(req.version()) == null);
{noformat}
This could happen only if results of calls to IgniteTxManager changed after 
method execution started. We should re-use already aquired values:
- replace ctx.tm().tx(...) call with dhtTx;
- replace ctx.tml().nearTx(...) call with nearTx.


> Assertion error in IgniteTxHandler.processDhtTxFinishRequest(...)
> -
>
> Key: IGNITE-6254
> URL: https://issues.apache.org/jira/browse/IGNITE-6254
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
> Fix For: 2.3
>
>
> AssertionError is thrown in the end of this method:
> {noformat}
> assert req.txState() != null || (ctx.tm().tx(req.version()) == null && 
> ctx.tm().nearTx(req.version()) == null);
> {noformat}
> This could happen only if results of calls to IgniteTxManager changed after 
> method execution started. We should re-use already aquired values:
> - replace ctx.tm().tx(...) call with dhtTx;
> - replace ctx.tml().nearTx(...) call with nearTx.



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

[jira] [Commented] (IGNITE-5879) .NET: Move TestPlatformPlugin to a separate module

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur commented on IGNITE-5879:


[~yzhdanov], any comments from your side?

> .NET: Move TestPlatformPlugin to a separate module
> --
>
> Key: IGNITE-5879
> URL: https://issues.apache.org/jira/browse/IGNITE-5879
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Vyacheslav Daradur
>  Labels: .NET
> Fix For: 2.3
>
>
> Move test plugin to a separate module and load it only for .NET tests so we 
> don't interfere with other tests.
> Dev list discussion: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Plugins-in-tests-td20167.html



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

[jira] [Commented] (IGNITE-5355) Create task with release tools

[Aleksey Chetaev (JIRA)]

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

Aleksey Chetaev commented on IGNITE-5355:
-

[~ntikhonov]
* I changed org.json to com.googlecode.json-simple. org.json license don't 
support by apache license policy.
* I tried to fix all style issues.
* Change code to use StringBuffer
* This don't need to have test, because it's not part of Ignite Node, it's 
tools needed for release process changes.

> Create task with release tools
> --
>
> Key: IGNITE-5355
> URL: https://issues.apache.org/jira/browse/IGNITE-5355
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Aleksey Chetaev
>Assignee: Aleksey Chetaev
>
> 1. Create task for auto-generate HTML formatted releases notes



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

[jira] [Updated] (IGNITE-5653) Add to query execution plan debug data for joins

[Yakov Zhdanov (JIRA)]

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

Yakov Zhdanov updated IGNITE-5653:
--
Labels: usability  (was: )

> Add to query execution plan debug data for joins
> 
>
> Key: IGNITE-5653
> URL: https://issues.apache.org/jira/browse/IGNITE-5653
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
> Environment: Plan should output table type (replicated/partitioned) 
> and colocation information if possible. If we have this than we can warn (or 
> throw exception) if users try to join non colocated tables with local joins.
>Reporter: Alexander Paschenko
>  Labels: usability
>




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