[jira] [Created] (IGNITE-6647) Web Console: Implement schema migration

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-6647:


 Summary: Web Console: Implement schema migration
 Key: IGNITE-6647
 URL: https://issues.apache.org/jira/browse/IGNITE-6647
 Project: Ignite
  Issue Type: Improvement
  Security Level: Public (Viewable by anyone)
  Components: wizards
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov
 Fix For: 2.4


We need to support schema updates for Web Console new versions.



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

[jira] [Assigned] (IGNITE-6608) .NET: Thin client documentation

[Denis Magda (JIRA)]

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

Denis Magda reassigned IGNITE-6608:
---

Assignee: Prachi Garg  (was: Pavel Tupitsyn)

> .NET: Thin client documentation
> ---
>
> Key: IGNITE-6608
> URL: https://issues.apache.org/jira/browse/IGNITE-6608
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, platforms, thin client
>Affects Versions: 2.3
>Reporter: Pavel Tupitsyn
>Assignee: Prachi Garg
>  Labels: .NET
> Fix For: 2.3
>
>
> Document new Thin Client API on readme.io: 
> https://apacheignite-net.readme.io/docs



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

[jira] [Commented] (IGNITE-6608) .NET: Thin client documentation

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-6608:
-

[~pgarg], please do a final review and editing of the doc.

> .NET: Thin client documentation
> ---
>
> Key: IGNITE-6608
> URL: https://issues.apache.org/jira/browse/IGNITE-6608
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, platforms, thin client
>Affects Versions: 2.3
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Document new Thin Client API on readme.io: 
> https://apacheignite-net.readme.io/docs



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

[jira] [Closed] (IGNITE-6593) Document C and SQL types, supported by ODBC driver.

[Denis Magda (JIRA)]

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

Denis Magda closed IGNITE-6593.
---

> Document C and SQL types, supported by ODBC driver.
> ---
>
> Key: IGNITE-6593
> URL: https://issues.apache.org/jira/browse/IGNITE-6593
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.2
>Reporter: Igor Sapego
>Assignee: Denis Magda
> Fix For: 2.3
>
>
> Need to list all the available C and SQL types, supported by ODBC driver.



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

[jira] [Closed] (IGNITE-6573) SQL: Document WRAP_KEY and WRAP_VALUE commands

[Denis Magda (JIRA)]

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

Denis Magda closed IGNITE-6573.
---

> SQL: Document WRAP_KEY and WRAP_VALUE commands
> --
>
> Key: IGNITE-6573
> URL: https://issues.apache.org/jira/browse/IGNITE-6573
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Vladimir Ozerov
>Assignee: Denis Magda
> Fix For: 2.3
>
>




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

[jira] [Commented] (IGNITE-6283) Document ALTER TABLE ADD COLUMN command

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-6283:
-

[~al.psc], I've edited the doc a bit and have a couple of questions before the 
ticket is closed:
* It's said that _"Schema changes applied by this command are persisted on 
disk, thus, surviving full cluster restarts."_. Does this work only when Ignite 
persistence is enabled?
* The changes that are appied by CREATE INDEX and DROP INDEX command are 
persisted too, right?

> Document ALTER TABLE ADD COLUMN command
> ---
>
> Key: IGNITE-6283
> URL: https://issues.apache.org/jira/browse/IGNITE-6283
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, sql
>Reporter: Vladimir Ozerov
>Assignee: Denis Magda
> Fix For: 2.3
>
>




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

[jira] [Assigned] (IGNITE-6283) Document ALTER TABLE ADD COLUMN command

[Denis Magda (JIRA)]

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

Denis Magda reassigned IGNITE-6283:
---

Assignee: Alexander Paschenko  (was: Denis Magda)

> Document ALTER TABLE ADD COLUMN command
> ---
>
> Key: IGNITE-6283
> URL: https://issues.apache.org/jira/browse/IGNITE-6283
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.3
>
>




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

[jira] [Comment Edited] (IGNITE-6283) Document ALTER TABLE ADD COLUMN command

[Denis Magda (JIRA)]

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

Denis Magda edited comment on IGNITE-6283 at 10/16/17 10:50 PM:


[~al.psc], I've edited the doc a bit and have a couple of questions before the 
ticket is closed:
* It's said that _"Schema changes applied by this command are persisted on 
disk, thus, surviving full cluster restarts."_. Does this work only when Ignite 
persistence is enabled?
* The changes that are done by CREATE INDEX and DROP INDEX command are 
persisted too, right?


was (Author: dmagda):
[~al.psc], I've edited the doc a bit and have a couple of questions before the 
ticket is closed:
* It's said that _"Schema changes applied by this command are persisted on 
disk, thus, surviving full cluster restarts."_. Does this work only when Ignite 
persistence is enabled?
* The changes that are appied by CREATE INDEX and DROP INDEX command are 
persisted too, right?

> Document ALTER TABLE ADD COLUMN command
> ---
>
> Key: IGNITE-6283
> URL: https://issues.apache.org/jira/browse/IGNITE-6283
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, sql
>Reporter: Vladimir Ozerov
>Assignee: Denis Magda
> Fix For: 2.3
>
>




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

[jira] [Created] (IGNITE-6645) Security issues in Ignite that allows users with write access to datagrid to execute arbitrary code

[Denis Magda (JIRA)]

Denis Magda created IGNITE-6645:
---

 Summary: Security issues in Ignite that allows users with write 
access to datagrid to execute arbitrary code
 Key: IGNITE-6645
 URL: https://issues.apache.org/jira/browse/IGNITE-6645
 Project: Ignite
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
Affects Versions: 1.0
Reporter: Denis Magda
Assignee: Yakov Zhdanov
Priority: Critical
 Fix For: 2.4


The security breach was reported by an end-user:
https://mail-search.apache.org/pmc/private-arch/ignite-private/201710.mbox/%3c7099cd44-92a7-4254-89c5-d8270b5a6...@apache.org%3e

Details shared by the user:
I would like to report some security issues that we found using the query 
language QL from lgtm.com. These are unsafe deserialization issues that allow 
users, possibly remote, that have rights to put entities on the datagrid to 
execute arbitrary code on an ignite server node.

As there are more than one of these issues, I will send them to you in separate 
emails.

The first issue affects the socket streaming server. The PoC code are included 
and are modifications of the `wordcount.socket` example in the examples 
package. 

A bit of set up is needed to see the full effect of code execution, so I will 
not include the details here, but if you want to try it out yourself, then 
please let me know and I can include the full PoC.

First add commons-beantil to the dependency, any version will work. Then 
download the file `obj`, which contains the serialized data of a malicious 
object. Change line 44 in `SocketStreamClient` so that it opens this file.

First start a server node using the example config `config/example-ignite.xml`, 
then start up the streaming server `SocketStreamerServer`. Now when you run 
`SocketStreamClient`, you will get an error, but somewhere in the stacktrace on 
the log in `SocketStreamerServer`, you will see this:

Caused by: java.lang.RuntimeException: InvocationTargetException: 
java.lang.reflect.InvocationTargetException
at 
org.apache.commons.beanutils.BeanComparator.compare(BeanComparator.java:171)
at java.util.PriorityQueue.siftDownUsingComparator(PriorityQueue.java:721)
at java.util.PriorityQueue.siftDown(PriorityQueue.java:687)
at java.util.PriorityQueue.heapify(PriorityQueue.java:736)
at java.util.PriorityQueue.readObject(PriorityQueue.java:795)

This shows that the node running the `SocketStreamerServer` is deserializing 
the payload object that I send it.

When properly set up, an attacker will have a remote ldap server that contains 
a second malicious Java object. Then when the above deserialization happens, an 
ldap look up will cause the second malicious object to be instantiated, which 
can then be used to execute arbitrary code. Also, although this exploit relies 
on having commons-beanutils to be on the classpath, there are other exploits 
that will work for different third party libraries, so it is not so much of a 
problem in commons-beanutils, but an issue in the handling of deserialization 
in ignite.

These results are using a slightly more ahead version of the QL library with we 
haven't made available on lgtm yet, but should be in a few days, if you are 
interested, I can share a link to the query and results to you when it is 
ready. Thanks.



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

[jira] [Commented] (IGNITE-6627) .NET: cache deserialization fails with complex value type & enum

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6627:


GitHub user apopovgg opened a pull request:

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

IGNITE-6627 .NET: cache deserialization fails with complex value type…



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

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

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

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


commit 80bebfc0752fb75feb8eaea1771fb03ce01429ac
Author: apopov 
Date:   2017-10-16T16:10:16Z

IGNITE-6627 .NET: cache deserialization fails with complex value type & enum




> .NET: cache deserialization fails with complex value type & enum
> 
>
> Key: IGNITE-6627
> URL: https://issues.apache.org/jira/browse/IGNITE-6627
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.2
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>  Labels: .NET
> Fix For: 2.4
>
>
> There is an deserialization issue with complex structure.
> Please see the sample code below:
> {noformat}
> public enum SampleEnum : byte
> {
> One = 0,
> Two = 1,
> Three = 2
> }
> {noformat}
> {noformat}
> var cache = ignite.GetOrCreateCache Dictionary>>("mySampleCache");
> cache.Put("DictData", Dict);
> var result = cache.Get("DictData");
> {noformat}
> var result = cache.Get("DictData"); fails with exception:
> {"The constructor to deserialize an object of type 
> 'System.Collections.Generic.ObjectEqualityComparer`1[SampleProject.SampleEnum]'
>  was not found."}
> If we change 
> Dictionary>
> to 
> Dictionary>
> then everything works fine



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

[jira] [Commented] (IGNITE-6627) .NET: cache deserialization fails with complex value type & enum

[Alexey Popov (JIRA)]

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

Alexey Popov commented on IGNITE-6627:
--

There are 3 actual fixes here:
1. Type EnumEqualityComparer`1 serialization issue: its object type 
ObjectEqualityComparer`1 is not ISerializable and should not be serialized.
Some explanation could be found here 
http://dotnetstudio.blogspot.ru/2012/06/net-35-to-net-40-enum.html
2. HashSet and other generic collection deserialization issue for enum arrays: 
object array was not casted to enum array
3. EmptyObject serialization issues: typeid of such object were not passed to 
Grid (BinaryProcessor)

Several tests were added for all issues.

[~ptupitsyn] please review the changes

> .NET: cache deserialization fails with complex value type & enum
> 
>
> Key: IGNITE-6627
> URL: https://issues.apache.org/jira/browse/IGNITE-6627
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.2
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>  Labels: .NET
> Fix For: 2.4
>
>
> There is an deserialization issue with complex structure.
> Please see the sample code below:
> {noformat}
> public enum SampleEnum : byte
> {
> One = 0,
> Two = 1,
> Three = 2
> }
> {noformat}
> {noformat}
> var cache = ignite.GetOrCreateCache Dictionary>>("mySampleCache");
> cache.Put("DictData", Dict);
> var result = cache.Get("DictData");
> {noformat}
> var result = cache.Get("DictData"); fails with exception:
> {"The constructor to deserialize an object of type 
> 'System.Collections.Generic.ObjectEqualityComparer`1[SampleProject.SampleEnum]'
>  was not found."}
> If we change 
> Dictionary>
> to 
> Dictionary>
> then everything works fine



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

[jira] [Commented] (IGNITE-5195) DataStreamer can fails if non-data node enter\leave the grid.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5195:


GitHub user ilantukh opened a pull request:

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

IGNITE-5195 : DataStreamer remap optimization.



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

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

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

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


commit caa7f7c833a162a01edacb241634515cdce67ec2
Author: Ilya Lantukh 
Date:   2017-10-16T14:56:18Z

ignite-5195 : DataStreamer remap optimization.




> DataStreamer can fails if non-data node enter\leave the grid.
> -
>
> Key: IGNITE-5195
> URL: https://issues.apache.org/jira/browse/IGNITE-5195
> Project: Ignite
>  Issue Type: Bug
>  Components: streaming
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Ilya Lantukh
> Fix For: 2.4
>
> Attachments: DataStreamerFailure.java
>
>
> DataStreamer failed with "too many remaps" message even if non-data node 
> enter\leave topology.
> PFA repro attached. 
> Seems, we should ignore topology changes when non-data node enter\leave the 
> grid. 
> And also we need to sure that remapping doesn't occurs when there is no data 
> nodes in grid any more, as remapping make no sense and more suitable message 
> should be logged.



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

[jira] [Comment Edited] (IGNITE-6217) Add benchmark to compare JDBC drivers and native SQL execution

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-6217 at 10/16/17 2:43 PM:


The other benchmark result.

Configurations:
# Native SQL: 1 server, 1 client. SQL queries are execute4d on client on 
separate host
# JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host.
# JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and 
connects to the client node. SQL queries are executed on JDBC client on 
separate4 host.

SQL query:
{{SELECT val FROM test WHERE id = }}
where TEST table contains two columns: {{id long, val long}}
The table contains 1M unique rows.

|| Benchmark || Ops /sec (1 row) ||
| Nativa SQL | 9385.99 |
| JDBC v2 | .48 |  
| JDBC thin | 4367.87 |


was (Author: tledkov-gridgain):
The other benchmark result.

Configurations:
# Native SQL: 1 server, 1 client. SQL queries are execute4d on client on 
separate host
# JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host.
# JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and 
connects to the client node. SQL queries are executed on JDBC client on 
separate4 host.

SQL query:
{{SELECT val FROM test WHERE id = }}
where TEST table contains two columns: {{id long, val long}}
The table contains 1M unique rows.

|| Benchmark || Ops /sec (1 row in result) ||
| Nativa SQL | 9385.99 |
| JDBC v2 | .48 |  
| JDBC thin | 4367.87 |

> Add benchmark to compare JDBC drivers and native SQL execution
> --
>
> Key: IGNITE-6217
> URL: https://issues.apache.org/jira/browse/IGNITE-6217
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql, yardstick
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.4
>
>
> We have to compare performance of the native SQL execution (via Ignite SQL 
> API), JDBC v2 driver, that uses Ignite client to connect to grid and JDBC 
> thin client.



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

[jira] [Comment Edited] (IGNITE-6217) Add benchmark to compare JDBC drivers and native SQL execution

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-6217 at 10/16/17 2:42 PM:


The other benchmark result.

Configurations:
# Native SQL: 1 server, 1 client. SQL queries are execute4d on client on 
separate host
# JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host.
# JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and 
connects to the client node. SQL queries are executed on JDBC client on 
separate4 host.

SQL query:
{{SELECT val FROM test WHERE id = }}
where TEST table contains two columns: {{id long, val long}}
The table contains 1M unique rows.

|| Benchmark || Ops /sec (1 row in result) ||
| Nativa SQL | 9385.99 |
| JDBC v2 | .48 |  
| JDBC thin | 4367.87 |


was (Author: tledkov-gridgain):
The other benchmark result.

Configurations:
# Native SQL: 1 server, 1 client. SQL queries are execute4d on client on 
separate host
# JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host.
# JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and 
connects to the client node. SQL queries are executed on JDBC client on 
separate4 host.

SQL query:
{{SELECT val FROM test WHERE id = }}
where TEST table contains two columns: {{id long, val long}}
The table contains 1M unique rows.

|| Benchmark || Ops /sec ||
| Nativa SQL | 9385.99 |
| JDBC v2 | .48 |  
| JDBC thin | 4367.87 |

> Add benchmark to compare JDBC drivers and native SQL execution
> --
>
> Key: IGNITE-6217
> URL: https://issues.apache.org/jira/browse/IGNITE-6217
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql, yardstick
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.4
>
>
> We have to compare performance of the native SQL execution (via Ignite SQL 
> API), JDBC v2 driver, that uses Ignite client to connect to grid and JDBC 
> thin client.



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

[jira] [Created] (IGNITE-6642) Integration with PMML

[Yury Babak (JIRA)]

Yury Babak created IGNITE-6642:
--

 Summary: Integration with PMML
 Key: IGNITE-6642
 URL: https://issues.apache.org/jira/browse/IGNITE-6642
 Project: Ignite
  Issue Type: New Feature
  Security Level: Public (Viewable by anyone)
  Components: ml
Reporter: Yury Babak


PMML - Predictive Model Markup Language is XML based language which used in 
SPARK MLlib and others platforms.

Here some additional info about PMML:

(i) http://dmg.org/pmml/v4-3/GeneralStructure.html
(i) https://github.com/jpmml/jpmml-model



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

[jira] [Created] (IGNITE-6641) PageId handling improvement: PARTITION_ID masking

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-6641:
---

 Summary: PageId handling improvement: PARTITION_ID masking
 Key: IGNITE-6641
 URL: https://issues.apache.org/jira/browse/IGNITE-6641
 Project: Ignite
  Issue Type: Improvement
  Security Level: Public (Viewable by anyone)
  Components: cache
Reporter: Sergey Chugunov
 Fix For: 2.4


All in-memory caches share the same FreeList data structure which relies on 
pageId comparisons to manage its internal state.

As described in javadoc for *FullPageId* class each pageId contains a 
partitionID part which is not guaranteed to be constant and is going to be 
changed as part of a linked ticket.

Thus we need to exclude partitionID when using pageId for comparisons that 
expect pageId to be constant.

h2. Notes
This change is not applicable for persistent caches as they maintain separate 
FreeList for each partition so partitionID part is constant for pages from that 
partition.



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

[jira] [Commented] (IGNITE-6515) .NET: Enable persistence on per-cache basis

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-6515:


API updated according to latest changes in IGNITE-6030, tests seem to be fine.

> .NET: Enable persistence on per-cache basis
> ---
>
> Key: IGNITE-6515
> URL: https://issues.apache.org/jira/browse/IGNITE-6515
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, important
> Fix For: 2.3
>
>
> Propagate new configuration to .NET: IGNITE-6030



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

[jira] [Created] (IGNITE-6640) Introduction of models import/export

[Yury Babak (JIRA)]

Yury Babak created IGNITE-6640:
--

 Summary: Introduction of models import/export
 Key: IGNITE-6640
 URL: https://issues.apache.org/jira/browse/IGNITE-6640
 Project: Ignite
  Issue Type: New Feature
  Security Level: Public (Viewable by anyone)
  Components: ml
Reporter: Yury Babak
Assignee: Yury Babak


We need to add basic import/export functionality for ml models. We will start 
from simple binary save to file and load from file.



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

[jira] [Commented] (IGNITE-6637) No proper cleanup of statements cache is done on table drop

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6637:


Github user asfgit closed the pull request at:

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


> No proper cleanup of statements cache is done on table drop
> ---
>
> Key: IGNITE-6637
> URL: https://issues.apache.org/jira/browse/IGNITE-6637
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: sql
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 2.3
>
> Attachments: IgniteCacheLocalQuerySelfTest.java
>
>
> We should cleanup statements cache whenever cache is deregistered - otherwise 
> it's possible to retrieve from statements cache a statement that is prepared 
> from H2 perspective but may not be executed. Such situation may arise for any 
> dynamic cache, not only for that created via SQL.
> Reproducer attached.



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

[jira] [Commented] (IGNITE-6362) NPE in Log4J2Logger

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6362:


Github user asfgit closed the pull request at:

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


> NPE in Log4J2Logger
> ---
>
> Key: IGNITE-6362
> URL: https://issues.apache.org/jira/browse/IGNITE-6362
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.1
>Reporter: Valentin Kulichenko
>Assignee: Alexey Popov
> Fix For: 2.4
>
>
> When I start a node with {{Log4J2Logger}} configured and verbose mode 
> ({{-DIGNITE_QUIET=false}}, it fails with NPE:
> {noformat}
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.(LoggerConfig.java:145)
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.createLogger(LoggerConfig.java:523)
>   at 
> org.apache.ignite.logger.log4j2.Log4J2Logger.createConsoleLogger(Log4J2Logger.java:380)
>   at 
> org.apache.ignite.logger.log4j2.Log4J2Logger.addConsoleAppenderIfNeeded(Log4J2Logger.java:338)
>   at 
> org.apache.ignite.logger.log4j2.Log4J2Logger.(Log4J2Logger.java:145)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>   at 
> org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:142)
>   ... 34 more
> {noformat}
> This is caused by the fact that {{Log4J2Logger#createConsoleLogger}} method 
> invokes {{LoggerConfig.createLogger}} providing {{null}} as {{Configuration}} 
> object, which unconditionally causes NPE. Need to provide some default 
> configuration instead.



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

[jira] [Commented] (IGNITE-6362) NPE in Log4J2Logger

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6362:
--

[~alexey.tank2],
Thank for you contribution! Looks good to me. I've merged to master.

> NPE in Log4J2Logger
> ---
>
> Key: IGNITE-6362
> URL: https://issues.apache.org/jira/browse/IGNITE-6362
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.1
>Reporter: Valentin Kulichenko
>Assignee: Alexey Popov
> Fix For: 2.4
>
>
> When I start a node with {{Log4J2Logger}} configured and verbose mode 
> ({{-DIGNITE_QUIET=false}}, it fails with NPE:
> {noformat}
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.(LoggerConfig.java:145)
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.createLogger(LoggerConfig.java:523)
>   at 
> org.apache.ignite.logger.log4j2.Log4J2Logger.createConsoleLogger(Log4J2Logger.java:380)
>   at 
> org.apache.ignite.logger.log4j2.Log4J2Logger.addConsoleAppenderIfNeeded(Log4J2Logger.java:338)
>   at 
> org.apache.ignite.logger.log4j2.Log4J2Logger.(Log4J2Logger.java:145)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>   at 
> org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:142)
>   ... 34 more
> {noformat}
> This is caused by the fact that {{Log4J2Logger#createConsoleLogger}} method 
> invokes {{LoggerConfig.createLogger}} providing {{null}} as {{Configuration}} 
> object, which unconditionally causes NPE. Need to provide some default 
> configuration instead.



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

[jira] [Updated] (IGNITE-6638) Add an ability for auto activate BLT

[Sergey Puchnin (JIRA)]

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

Sergey Puchnin updated IGNITE-6638:
---
Description: 
For further improvement BLT it'd be great to add auto activation functionality. 
It allow to reduce stuff intervention.

Next subtasks should be solved:
* To change the metasrore format. Choose a format to store a node list (whole 
node list, only id+hash, etc)
* Add a BLT management to WebConsole
* Add a BLT management to CLI
* Save affinity function attributes to metastore
* Check equality configuration between metasore and XML. Reject to start a 
cluster if different 

  was:
For further improvement BLT it'd be great to add auto activation functionality. 
It allow to reduce stuff intervention.

Next subtasks should be solved:
* To change the metasrore format. Choose a format to store a node list (whole 
node list, only id+hash, etc)
* Add a BLT management to WebConsole
* Add a BLT management to CLI
* Save affinity function attributes to metastore
* Check equality configuration between metasore and XML. Reject to start a 
cluster if different 
* To support a rolling upgrade procedure for BLT cluster 


> Add an ability for auto activate BLT
> 
>
> Key: IGNITE-6638
> URL: https://issues.apache.org/jira/browse/IGNITE-6638
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.2
>Reporter: Sergey Puchnin
>Assignee: Dmitriy Pavlov
> Fix For: 2.4
>
>
> For further improvement BLT it'd be great to add auto activation 
> functionality. It allow to reduce stuff intervention.
> Next subtasks should be solved:
> * To change the metasrore format. Choose a format to store a node list (whole 
> node list, only id+hash, etc)
> * Add a BLT management to WebConsole
> * Add a BLT management to CLI
> * Save affinity function attributes to metastore
> * Check equality configuration between metasore and XML. Reject to start a 
> cluster if different 



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

[jira] [Updated] (IGNITE-6627) .NET: cache deserialization fails with complex value type & enum

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-6627:
---
Fix Version/s: (was: 2.3)
   2.4

> .NET: cache deserialization fails with complex value type & enum
> 
>
> Key: IGNITE-6627
> URL: https://issues.apache.org/jira/browse/IGNITE-6627
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.2
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>  Labels: .NET
> Fix For: 2.4
>
>
> There is an deserialization issue with complex structure.
> Please see the sample code below:
> {noformat}
> public enum SampleEnum : byte
> {
> One = 0,
> Two = 1,
> Three = 2
> }
> {noformat}
> {noformat}
> var cache = ignite.GetOrCreateCache Dictionary>>("mySampleCache");
> cache.Put("DictData", Dict);
> var result = cache.Get("DictData");
> {noformat}
> var result = cache.Get("DictData"); fails with exception:
> {"The constructor to deserialize an object of type 
> 'System.Collections.Generic.ObjectEqualityComparer`1[SampleProject.SampleEnum]'
>  was not found."}
> If we change 
> Dictionary>
> to 
> Dictionary>
> then everything works fine



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

[jira] [Updated] (IGNITE-6638) Add an ability for auto activate BLT

[Sergey Puchnin (JIRA)]

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

Sergey Puchnin updated IGNITE-6638:
---
Description: 
For further improvement BLT it'd be great to add auto activation functionality. 
It allow to reduce stuff intervention.

Next subtasks should be solved:
* To change the metasrore format. Choose a format to store a node list (whole 
node list, only id+hash, etc)
* Add a BLT management to WebConsole
* Add a BLT management to CLI
* Save affinity function attributes to metastore
* Check equality configuration between metasore and XML. Reject to start a 
cluster if different 
* To support a rolling upgrade procedure for BLT cluster 

  was:To support an 


> Add an ability for auto activate BLT
> 
>
> Key: IGNITE-6638
> URL: https://issues.apache.org/jira/browse/IGNITE-6638
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.2
>Reporter: Sergey Puchnin
>Assignee: Dmitriy Pavlov
> Fix For: 2.4
>
>
> For further improvement BLT it'd be great to add auto activation 
> functionality. It allow to reduce stuff intervention.
> Next subtasks should be solved:
> * To change the metasrore format. Choose a format to store a node list (whole 
> node list, only id+hash, etc)
> * Add a BLT management to WebConsole
> * Add a BLT management to CLI
> * Save affinity function attributes to metastore
> * Check equality configuration between metasore and XML. Reject to start a 
> cluster if different 
> * To support a rolling upgrade procedure for BLT cluster 



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

[jira] [Assigned] (IGNITE-6280) Cassandra ignores AffinityKeyMapped annotation in parent classes.

[Mikhail Cherkasov (JIRA)]

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

Mikhail Cherkasov reassigned IGNITE-6280:
-

Assignee: Mikhail Cherkasov

> Cassandra ignores AffinityKeyMapped annotation in parent classes.
> -
>
> Key: IGNITE-6280
> URL: https://issues.apache.org/jira/browse/IGNITE-6280
> Project: Ignite
>  Issue Type: Bug
>  Components: cassandra
>Affects Versions: 2.1
>Reporter: Andrew Mashenkov
>Assignee: Mikhail Cherkasov
> Attachments: CassandraConfigTest.java
>
>
> By default, using @AffinityKeyMapped annotation force Ignire to override user 
> _keyPersistence_ configuration that may cause confusing results.
> PFA repro attached.
> h3. Description
> 1. Let there is 2 keys A and B that has same fields with one difference. Key 
> A has affinity key in parent class. So, it looks like this.
> {code}
> class BaseKey {
> @AffinityKeyMapped
>  Object affinityKey
> }
> {code}
> {code}
> class A extends BaseKey {
>  int id;
> }
> {code}
> {code}
> class B {
> @AffinityKeyMapped
>  Object affinityKey;
>  int uid;
> }
> {code}
> 2. Let we make different affinity mapping for Cassandra store, that looks 
> like a valid case
> {code:xml}
> 
> 
>  
>  
>
> 
> {code}
> 3. We have different behavior for these similar cases that makes user 
> confused.
> For key A this will work fine and expected DDL will be generated.
> For key B we'll get different DDL as Ignite will remove "_uid_" field from 
> "_partitionKey_".
> So, we should either to not allow Ignite to override key mapping or force 
> Ignite to check if parent classes has @AffinityKeyMapped annotation.



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

[jira] [Updated] (IGNITE-6627) .NET: cache deserialization fails with complex value type & enum

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-6627:
---
Fix Version/s: 2.3

> .NET: cache deserialization fails with complex value type & enum
> 
>
> Key: IGNITE-6627
> URL: https://issues.apache.org/jira/browse/IGNITE-6627
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.2
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>  Labels: .NET
> Fix For: 2.3
>
>
> There is an deserialization issue with complex structure.
> Please see the sample code below:
> {noformat}
> public enum SampleEnum : byte
> {
> One = 0,
> Two = 1,
> Three = 2
> }
> {noformat}
> {noformat}
> var cache = ignite.GetOrCreateCache Dictionary>>("mySampleCache");
> cache.Put("DictData", Dict);
> var result = cache.Get("DictData");
> {noformat}
> var result = cache.Get("DictData"); fails with exception:
> {"The constructor to deserialize an object of type 
> 'System.Collections.Generic.ObjectEqualityComparer`1[SampleProject.SampleEnum]'
>  was not found."}
> If we change 
> Dictionary>
> to 
> Dictionary>
> then everything works fine



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

[jira] [Commented] (IGNITE-6637) No proper cleanup of statements cache is done on table drop

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-6637:
-

[~al.psc], looks good to me.

> No proper cleanup of statements cache is done on table drop
> ---
>
> Key: IGNITE-6637
> URL: https://issues.apache.org/jira/browse/IGNITE-6637
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: sql
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 2.3
>
> Attachments: IgniteCacheLocalQuerySelfTest.java
>
>
> We should cleanup statements cache whenever cache is deregistered - otherwise 
> it's possible to retrieve from statements cache a statement that is prepared 
> from H2 perspective but may not be executed. Such situation may arise for any 
> dynamic cache, not only for that created via SQL.
> Reproducer attached.



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

[jira] [Updated] (IGNITE-6638) Add an ability for auto activate BLT

[Sergey Puchnin (JIRA)]

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

Sergey Puchnin updated IGNITE-6638:
---
Description: To support an   (was: Currently, the WAL iterator can be 
obtained from the WAL manager when an Ignite node is up and running.
However, it may be extremely useful to read WAL in an 'offline' mode, when a 
node is not started up. This may be required for crash analysis or to export 
committed data to some external systems.

In the future we can make this even a public interface, however as a starting 
point, I would like to keep it in private package because moving to the public 
package will require Iterator and records to be public too.

So, as a starting point, we need:
 * An object that will allow us to get WALIterator instances (probably, should 
be closeable)
 * A method on this object which will create an iterator by a file name or file 
names

Using this object should not require an active Ignite instance running.)

> Add an ability for auto activate BLT
> 
>
> Key: IGNITE-6638
> URL: https://issues.apache.org/jira/browse/IGNITE-6638
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.2
>Reporter: Sergey Puchnin
>Assignee: Dmitriy Pavlov
> Fix For: 2.4
>
>
> To support an 



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

[jira] [Updated] (IGNITE-6638) Add an ability for auto activate BLT

[Sergey Puchnin (JIRA)]

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

Sergey Puchnin updated IGNITE-6638:
---
Fix Version/s: (was: 2.1)
   2.4

> Add an ability for auto activate BLT
> 
>
> Key: IGNITE-6638
> URL: https://issues.apache.org/jira/browse/IGNITE-6638
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.2
>Reporter: Sergey Puchnin
>Assignee: Dmitriy Pavlov
> Fix For: 2.4
>
>
> Currently, the WAL iterator can be obtained from the WAL manager when an 
> Ignite node is up and running.
> However, it may be extremely useful to read WAL in an 'offline' mode, when a 
> node is not started up. This may be required for crash analysis or to export 
> committed data to some external systems.
> In the future we can make this even a public interface, however as a starting 
> point, I would like to keep it in private package because moving to the 
> public package will require Iterator and records to be public too.
> So, as a starting point, we need:
>  * An object that will allow us to get WALIterator instances (probably, 
> should be closeable)
>  * A method on this object which will create an iterator by a file name or 
> file names
> Using this object should not require an active Ignite instance running.



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

[jira] [Created] (IGNITE-6638) Add an ability for auto activate BLT

[Sergey Puchnin (JIRA)]

Sergey Puchnin created IGNITE-6638:
--

 Summary: Add an ability for auto activate BLT
 Key: IGNITE-6638
 URL: https://issues.apache.org/jira/browse/IGNITE-6638
 Project: Ignite
  Issue Type: Improvement
  Components: persistence
Affects Versions: 2.1
Reporter: Sergey Puchnin
Assignee: Dmitriy Pavlov
 Fix For: 2.1


Currently, the WAL iterator can be obtained from the WAL manager when an Ignite 
node is up and running.
However, it may be extremely useful to read WAL in an 'offline' mode, when a 
node is not started up. This may be required for crash analysis or to export 
committed data to some external systems.

In the future we can make this even a public interface, however as a starting 
point, I would like to keep it in private package because moving to the public 
package will require Iterator and records to be public too.

So, as a starting point, we need:
 * An object that will allow us to get WALIterator instances (probably, should 
be closeable)
 * A method on this object which will create an iterator by a file name or file 
names

Using this object should not require an active Ignite instance running.



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

[jira] [Created] (IGNITE-6639) Ignite node can try to join to itself

[Mikhail Cherkasov (JIRA)]

Mikhail Cherkasov created IGNITE-6639:
-

 Summary: Ignite node can try to join to itself
 Key: IGNITE-6639
 URL: https://issues.apache.org/jira/browse/IGNITE-6639
 Project: Ignite
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
  Components: general
Affects Versions: 2.3
Reporter: Mikhail Cherkasov
Assignee: Mikhail Cherkasov
 Fix For: 2.4






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

[jira] [Updated] (IGNITE-6638) Add an ability for auto activate BLT

[Sergey Puchnin (JIRA)]

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

Sergey Puchnin updated IGNITE-6638:
---
Affects Version/s: (was: 2.1)
   2.2

> Add an ability for auto activate BLT
> 
>
> Key: IGNITE-6638
> URL: https://issues.apache.org/jira/browse/IGNITE-6638
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.2
>Reporter: Sergey Puchnin
>Assignee: Dmitriy Pavlov
> Fix For: 2.4
>
>
> Currently, the WAL iterator can be obtained from the WAL manager when an 
> Ignite node is up and running.
> However, it may be extremely useful to read WAL in an 'offline' mode, when a 
> node is not started up. This may be required for crash analysis or to export 
> committed data to some external systems.
> In the future we can make this even a public interface, however as a starting 
> point, I would like to keep it in private package because moving to the 
> public package will require Iterator and records to be public too.
> So, as a starting point, we need:
>  * An object that will allow us to get WALIterator instances (probably, 
> should be closeable)
>  * A method on this object which will create an iterator by a file name or 
> file names
> Using this object should not require an active Ignite instance running.



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

[jira] [Commented] (IGNITE-6637) No proper cleanup of statements cache is done on table drop

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6637:


GitHub user alexpaschenko opened a pull request:

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

IGNITE-6637 Statements cache clear on cache destroy.



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

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

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

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


commit 0f2acd36c851a4f4ebdf5eff976e94289aa09bf2
Author: Alexander Paschenko 
Date:   2017-10-16T12:18:46Z

IGNITE-6637 Statements cache clear on cache destroy.




> No proper cleanup of statements cache is done on table drop
> ---
>
> Key: IGNITE-6637
> URL: https://issues.apache.org/jira/browse/IGNITE-6637
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: sql
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 2.3
>
> Attachments: IgniteCacheLocalQuerySelfTest.java
>
>
> We should cleanup statements cache whenever cache is deregistered - otherwise 
> it's possible to retrieve from statements cache a statement that is prepared 
> from H2 perspective but may not be executed. Such situation may arise for any 
> dynamic cache, not only for that created via SQL.
> Reproducer attached.



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

[jira] [Assigned] (IGNITE-5195) DataStreamer can fails if non-data node enter\leave the grid.

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh reassigned IGNITE-5195:


Assignee: Ilya Lantukh  (was: Evgenii Zhuravlev)

> DataStreamer can fails if non-data node enter\leave the grid.
> -
>
> Key: IGNITE-5195
> URL: https://issues.apache.org/jira/browse/IGNITE-5195
> Project: Ignite
>  Issue Type: Bug
>  Components: streaming
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Ilya Lantukh
> Fix For: 2.4
>
> Attachments: DataStreamerFailure.java
>
>
> DataStreamer failed with "too many remaps" message even if non-data node 
> enter\leave topology.
> PFA repro attached. 
> Seems, we should ignore topology changes when non-data node enter\leave the 
> grid. 
> And also we need to sure that remapping doesn't occurs when there is no data 
> nodes in grid any more, as remapping make no sense and more suitable message 
> should be logged.



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

[jira] [Updated] (IGNITE-6637) No proper cleanup of statements cache is done on table drop

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko updated IGNITE-6637:

Description: 
We should cleanup statements cache whenever cache is deregistered - otherwise 
it's possible to retrieve from statements cache a statement that is prepared 
from H2 perspective but may not be executed. Such situation may arise for any 
dynamic cache, not only for that created via SQL.
Reproducer attached.

  was:
We should cleanup statements cache whenever cache is deregistered - otherwise 
it's possible to retrieve from statements cache a statement that is prepared 
from H2 perspective but may not be executed.
Reproducer attached.


> No proper cleanup of statements cache is done on table drop
> ---
>
> Key: IGNITE-6637
> URL: https://issues.apache.org/jira/browse/IGNITE-6637
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: sql
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 2.3
>
> Attachments: IgniteCacheLocalQuerySelfTest.java
>
>
> We should cleanup statements cache whenever cache is deregistered - otherwise 
> it's possible to retrieve from statements cache a statement that is prepared 
> from H2 perspective but may not be executed. Such situation may arise for any 
> dynamic cache, not only for that created via SQL.
> Reproducer attached.



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

[jira] [Updated] (IGNITE-6637) No proper cleanup of statements cache is done on table drop

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko updated IGNITE-6637:

Fix Version/s: 2.3

> No proper cleanup of statements cache is done on table drop
> ---
>
> Key: IGNITE-6637
> URL: https://issues.apache.org/jira/browse/IGNITE-6637
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: sql
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 2.3
>
> Attachments: IgniteCacheLocalQuerySelfTest.java
>
>
> We should cleanup statements cache whenever cache is deregistered - otherwise 
> it's possible to retrieve from statements cache a statement that is prepared 
> from H2 perspective but may not be executed.
> Reproducer attached.



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

[jira] [Commented] (IGNITE-6562) Dynamic service deployment should use projection if no NodeFilter is set.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6562:


Github user asfgit closed the pull request at:

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


> Dynamic service deployment should use projection if no NodeFilter is set.
> -
>
> Key: IGNITE-6562
> URL: https://issues.apache.org/jira/browse/IGNITE-6562
> Project: Ignite
>  Issue Type: Bug
>  Components: managed services
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
> Fix For: 2.4
>
>
> We have two issues here when service starts dynamically with 
> serviceConfiguration provided that not contains any NodeFilter.
> 1. Projection is ignored. 
> So, if user use a projection for service deployment, we should use it as 
> NodeFilter.
> 2. Service can be unexpectedly deployed on client nodes.
> If projection is not specified then cluster.forServers() projection should be 
> used.



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

[jira] [Updated] (IGNITE-6637) No proper cleanup of statements cache is done on table drop

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko updated IGNITE-6637:

Attachment: IgniteCacheLocalQuerySelfTest.java

> No proper cleanup of statements cache is done on table drop
> ---
>
> Key: IGNITE-6637
> URL: https://issues.apache.org/jira/browse/IGNITE-6637
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: sql
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Attachments: IgniteCacheLocalQuerySelfTest.java
>
>
> We should cleanup statements cache whenever cache is deregistered - otherwise 
> it's possible to retrieve from statements cache a statement that is prepared 
> from H2 perspective but may not be executed.
> Reproducer attached.



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

[jira] [Created] (IGNITE-6637) No proper cleanup of statements cache is done on table drop

[Alexander Paschenko (JIRA)]

Alexander Paschenko created IGNITE-6637:
---

 Summary: No proper cleanup of statements cache is done on table 
drop
 Key: IGNITE-6637
 URL: https://issues.apache.org/jira/browse/IGNITE-6637
 Project: Ignite
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
  Components: sql
Reporter: Alexander Paschenko
Assignee: Alexander Paschenko


We should cleanup statements cache whenever cache is deregistered - otherwise 
it's possible to retrieve from statements cache a statement that is prepared 
from H2 perspective but may not be executed.
Reproducer attached.



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

[jira] [Updated] (IGNITE-6613) .NET: Thin client: Create dotnet core unit test project, run on Linux

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-6613:
---
Component/s: thin client

> .NET: Thin client: Create dotnet core unit test project, run on Linux
> -
>
> Key: IGNITE-6613
> URL: https://issues.apache.org/jira/browse/IGNITE-6613
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Affects Versions: 2.3
>Reporter: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET, xplat
> Fix For: 2.4
>
>
> .NET Thin Client actually works on .NET Core and on Linux. Let's add unit 
> tests for that and run them on Linux machines to avoid regression.



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

[jira] [Updated] (IGNITE-6615) .NET: Thin client: XML configuration

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-6615:
---
Component/s: thin client

> .NET: Thin client: XML configuration
> 
>
> Key: IGNITE-6615
> URL: https://issues.apache.org/jira/browse/IGNITE-6615
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Affects Versions: 2.3
>Reporter: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> Provide a way to configure {{IgniteClientConfiguration}} in XML, similar to 
> {{IgniteConfiguration}}.



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

[jira] [Commented] (IGNITE-6608) .NET: Thin client documentation

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-6608:


[~dmagda] done.

Server connector can be configured in .NET, app.config, and Spring XML. But 
client connection can only be configured from code for now. Ticket: IGNITE-6615.

> .NET: Thin client documentation
> ---
>
> Key: IGNITE-6608
> URL: https://issues.apache.org/jira/browse/IGNITE-6608
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, platforms, thin client
>Affects Versions: 2.3
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Document new Thin Client API on readme.io: 
> https://apacheignite-net.readme.io/docs



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

[jira] [Updated] (IGNITE-6608) .NET: Thin client documentation

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-6608:
---
Component/s: thin client

> .NET: Thin client documentation
> ---
>
> Key: IGNITE-6608
> URL: https://issues.apache.org/jira/browse/IGNITE-6608
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, platforms, thin client
>Affects Versions: 2.3
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Document new Thin Client API on readme.io: 
> https://apacheignite-net.readme.io/docs



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

[jira] [Created] (IGNITE-6636) BinaryStream position integer overflow

[Alexandr Kuramshin (JIRA)]

Alexandr Kuramshin created IGNITE-6636:
--

 Summary: BinaryStream position integer overflow
 Key: IGNITE-6636
 URL: https://issues.apache.org/jira/browse/IGNITE-6636
 Project: Ignite
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
  Components: general
Affects Versions: 2.2
Reporter: Alexandr Kuramshin


There were some issues with negative {{BinaryAbstractStream#pos}} value.

We may get stack trace like that
{noformat}
java.lang.ArrayIndexOutOfBoundsException: -2142240123
at 
org.apache.ignite.internal.binary.streams.BinaryHeapOutputStream.writeByteAndShift(BinaryHeapOutputStream.java)
at 
org.apache.ignite.internal.binary.streams.BinaryAbstractOutputStream.writeByte(BinaryAbstractOutputStream.java)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java)
{noformat}

The worst of it is that the {{ArrayIndexOutOfBoundsException}} has been thrown 
on the next write to the stream, and upon stack unwinding we couldn't know 
which object actually cause the overflow.

I've to suggest to check all updates to the {{BinaryAbstractStream#pos}} and 
throw exception right after the change.



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

[jira] [Commented] (IGNITE-6635) Minimize H2 usages in InlineIndexHelper

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-6635:
-

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

> Minimize H2 usages in InlineIndexHelper
> ---
>
> Key: IGNITE-6635
> URL: https://issues.apache.org/jira/browse/IGNITE-6635
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.4
>
>
> In order to extract index from {{H2Tree}} we need to rework 
> {{InlineIndexHelper}} to minimize H2 classes usage. 



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

[jira] [Commented] (IGNITE-6635) Minimize H2 usages in InlineIndexHelper

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6635:


GitHub user devozerov opened a pull request:

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

IGNITE-6635



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

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

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

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


commit b807a7f0ff33de416287b506927188b077744109
Author: devozerov 
Date:   2017-10-16T08:02:23Z

WIP.

commit d40025def33eb46d85abb60457ce0adc110b8ac2
Author: devozerov 
Date:   2017-10-16T08:10:31Z

Key-only row.

commit da96581de2e45fcfb8fea7215f84ddb1610b327a
Author: devozerov 
Date:   2017-10-16T08:10:40Z

Key-only row.

commit 4732faa5c4ad0a636a494fcf6a5da7bdef57f7d3
Author: devozerov 
Date:   2017-10-16T08:14:05Z

It compiles.

commit fe602efca5b873397cd956fad0b9e73ef4e0d603
Author: devozerov 
Date:   2017-10-16T08:21:23Z

Hidden public fields.

commit 3f79ee7437117e786fdfbb188a6f13ddb88a27d6
Author: devozerov 
Date:   2017-10-16T08:48:40Z

WIP.

commit 020367e724621e772735de24f2eb14e12f08e256
Author: devozerov 
Date:   2017-10-16T10:39:42Z

Merge branch 'master' into inline-separate-value-enum

commit e8207f82c5436616e5c31f9193ee243bd18a914a
Author: devozerov 
Date:   2017-10-16T10:58:11Z

Reworked sort order.




> Minimize H2 usages in InlineIndexHelper
> ---
>
> Key: IGNITE-6635
> URL: https://issues.apache.org/jira/browse/IGNITE-6635
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.4
>
>
> In order to extract index from {{H2Tree}} we need to rework 
> {{InlineIndexHelper}} to minimize H2 classes usage. 



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

[jira] [Updated] (IGNITE-6635) Minimize H2 usages in InlineIndexHelper

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6635:

Component/s: sql

> Minimize H2 usages in InlineIndexHelper
> ---
>
> Key: IGNITE-6635
> URL: https://issues.apache.org/jira/browse/IGNITE-6635
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.4
>
>
> In order to extract index from {{H2Tree}} we need to rework 
> {{InlineIndexHelper}} to minimize H2 classes usage. 



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

[jira] [Created] (IGNITE-6635) Minimize H2 usages in InlineIndexHelper

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6635:
---

 Summary: Minimize H2 usages in InlineIndexHelper
 Key: IGNITE-6635
 URL: https://issues.apache.org/jira/browse/IGNITE-6635
 Project: Ignite
  Issue Type: Task
  Security Level: Public (Viewable by anyone)
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.4


In order to extract index from {{H2Tree}} we need to rework 
{{InlineIndexHelper}} to minimize H2 classes usage. 



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

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

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov edited comment on IGNITE-6005 at 10/16/17 10:43 AM:


[~avinogradov], [~agura]

Below wider explanation why I have stucked:

> I think better way is using special code flow for operations with 
> non-interruptible semantic.

1. As far as I can see - *all* {{get*}} operations within tx requires 
synchronization on internal {{Semaphore}} therefore can't be executed on 
interrupted thread.

2. I suggest usage explicit lock on data structure key. It helps a bit, but I 
don't get any logic in call results:

Interrupted thread:

GridDhtColocatedCache:

cache.get(key) - fails.
cache.getAsync(key).getUninterruptibly() - succeed
cache.remove(key) - succeed.
cache.removeAsync(key).getUninterruptibly() - fails.

GridDhtAtomicCache: 

All calls of get* or getAsync* fails.

Any suggestion why this happening?

This code runs OK on interrupted thread. Cache is GridDhtColocatedCache.
{code:java}
boolean lock = cache.lock(key, 0);
AtomicDataStructureValue val = cache.getAsync(key).getUninterruptibly();
cache.remove(key);
{code}

This code fails on interrupted thread. Cache is GridDhtAtomicCache
{code:java}
hdr = (GridCacheSetHeader) cctx.cache().getAsync(new 
GridCacheSetHeaderKey(name)).getUninterruptibly();
{code}


was (Author: nizhikov):
[~avinogradov]

Below wider explanation why I have stucked:

> I think better way is using special code flow for operations with 
> non-interruptible semantic.

1. As far as I can see - *all* {{get*}} operations within tx requires 
synchronization on internal {{Semaphore}} therefore can't be executed on 
interrupted thread.

2. I suggest usage explicit lock on data structure key. It helps a bit, but I 
don't get any logic in call results:

Interrupted thread:

GridDhtColocatedCache:

cache.get(key) - fails.
cache.getAsync(key).getUninterruptibly() - succeed
cache.remove(key) - succeed.
cache.removeAsync(key).getUninterruptibly() - fails.

GridDhtAtomicCache: 

All calls of get* or getAsync* fails.

Any suggestion why this happening?

This code runs OK on interrupted thread. Cache is GridDhtColocatedCache.
{code:java}
boolean lock = cache.lock(key, 0);
AtomicDataStructureValue val = cache.getAsync(key).getUninterruptibly();
cache.remove(key);
{code}

This code fails on interrupted thread. Cache is GridDhtAtomicCache
{code:java}
hdr = (GridCacheSetHeader) cctx.cache().getAsync(new 
GridCacheSetHeaderKey(name)).getUninterruptibly();
{code}

> [Test failed] 
> GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe
> -
>
> Key: IGNITE-6005
> URL: https://issues.apache.org/jira/browse/IGNITE-6005
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Nikolay Izhikov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
>
> Example of fail
> https://ci.ignite.apache.org/viewLog.html?buildId=762788=buildResultsDiv=Ignite20Tests_IgniteDataStrucutures
> Typical problem is 
> {code}
> org.apache.ignite.IgniteInterruptedException: Failed to wait for asynchronous 
> operation permit (thread got interrupted).
> at 
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:805)
> at 
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:803)
> at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:961)
> at 
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.close(GridCacheSemaphoreImpl.java:1026)
> at 
> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:458)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.InterruptedException: null
> at 
> 

[jira] [Commented] (IGNITE-5195) DataStreamer can fails if non-data node enter\leave the grid.

[Mikhail Cherkasov (JIRA)]

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

Mikhail Cherkasov commented on IGNITE-5195:
---

I set priority to major because many users have faced with this problem and in 
an active cluster, where a lot of clients join and left cluster makes data 
streamer useless.

> DataStreamer can fails if non-data node enter\leave the grid.
> -
>
> Key: IGNITE-5195
> URL: https://issues.apache.org/jira/browse/IGNITE-5195
> Project: Ignite
>  Issue Type: Bug
>  Components: streaming
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Evgenii Zhuravlev
> Fix For: 2.4
>
> Attachments: DataStreamerFailure.java
>
>
> DataStreamer failed with "too many remaps" message even if non-data node 
> enter\leave topology.
> PFA repro attached. 
> Seems, we should ignore topology changes when non-data node enter\leave the 
> grid. 
> And also we need to sure that remapping doesn't occurs when there is no data 
> nodes in grid any more, as remapping make no sense and more suitable message 
> should be logged.



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

[jira] [Updated] (IGNITE-5195) DataStreamer can fails if non-data node enter\leave the grid.

[Mikhail Cherkasov (JIRA)]

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

Mikhail Cherkasov updated IGNITE-5195:
--
Priority: Major  (was: Minor)

> DataStreamer can fails if non-data node enter\leave the grid.
> -
>
> Key: IGNITE-5195
> URL: https://issues.apache.org/jira/browse/IGNITE-5195
> Project: Ignite
>  Issue Type: Bug
>  Components: streaming
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Evgenii Zhuravlev
> Fix For: 2.4
>
> Attachments: DataStreamerFailure.java
>
>
> DataStreamer failed with "too many remaps" message even if non-data node 
> enter\leave topology.
> PFA repro attached. 
> Seems, we should ignore topology changes when non-data node enter\leave the 
> grid. 
> And also we need to sure that remapping doesn't occurs when there is no data 
> nodes in grid any more, as remapping make no sense and more suitable message 
> should be logged.



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

[jira] [Commented] (IGNITE-6634) SQL: move IgniteDistributedJoinTestSuite to query suite(s)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6634:


Github user devozerov closed the pull request at:

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


> SQL: move IgniteDistributedJoinTestSuite to query suite(s)
> --
>
> Key: IGNITE-6634
> URL: https://issues.apache.org/jira/browse/IGNITE-6634
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.4
>
>
> Currently this suite is executed as a part of continuous queries tests.



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

[jira] [Assigned] (IGNITE-6521) Review default JVM options for better performance

[Alexandr Kuramshin (JIRA)]

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

Alexandr Kuramshin reassigned IGNITE-6521:
--

Assignee: Dmitriy Govorukhin  (was: Alexandr Kuramshin)

> Review default JVM options for better performance
> -
>
> Key: IGNITE-6521
> URL: https://issues.apache.org/jira/browse/IGNITE-6521
> Project: Ignite
>  Issue Type: Improvement
>  Components: general, visor
>Affects Versions: 2.1
>Reporter: Alexandr Kuramshin
>Assignee: Dmitriy Govorukhin
>
> Non-optimal recommendations are present in ignite startup scrips
> {noformat}
> ::
> :: Uncomment the following GC settings if you see spikes in your throughput 
> due to Garbage Collection.
> ::
> :: set JVM_OPTS=%JVM_OPTS% -XX:+UseParNewGC -XX:+UseConcMarkSweepGC 
> -XX:+UseTLAB -XX:NewSize=128m -XX:MaxNewSize=128m
> :: set JVM_OPTS=%JVM_OPTS% -XX:MaxTenuringThreshold=0 -XX:SurvivorRatio=1024 
> -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=60
> {noformat}
> Some utilities (like Visor) are hanged up in continuous GCs when connected to 
> large clusters (above one hundred nodes). Even after using large heap (about 
> 32 Gb).
> I'd like to propose to remove this lines and modify default JVM_OPTS as 
> follows
> {noformat}
> set JVM_OPTS=-Xms1g -Xmx8g -XX:+UseG1GC -server -XX:+AggressiveOpts 
> -XX:MaxPermSize=256m
> {noformat}



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

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

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov edited comment on IGNITE-6005 at 10/16/17 10:00 AM:


[~avinogradov]

Below wider explanation why I have stucked:

> I think better way is using special code flow for operations with 
> non-interruptible semantic.

1. As far as I can see - *all* {{get*}} operations within tx requires 
synchronization on internal {{Semaphore}} therefore can't be executed on 
interrupted thread.

2. I suggest usage explicit lock on data structure key. It helps a bit, but I 
don't get any logic in call results:

Interrupted thread:

GridDhtColocatedCache:

cache.get(key) - fails.
cache.getAsync(key).getUninterruptibly() - succeed
cache.remove(key) - succeed.
cache.removeAsync(key).getUninterruptibly() - fails.

GridDhtAtomicCache: 

All calls of get* or getAsync* fails.

Any suggestion why this happening?

This code runs OK on interrupted thread. Cache is GridDhtColocatedCache.
{code:java}
boolean lock = cache.lock(key, 0);
AtomicDataStructureValue val = cache.getAsync(key).getUninterruptibly();
cache.remove(key);
{code}

This code fails on interrupted thread. Cache is GridDhtAtomicCache
{code:java}
hdr = (GridCacheSetHeader) cctx.cache().getAsync(new 
GridCacheSetHeaderKey(name)).getUninterruptibly();
{code}


was (Author: nizhikov):
[~avinogradov]

Below wider explanation why I have stucked:

> I think better way is using special code flow for operations with 
> non-interruptible semantic.

1. As far as I can see - *all* {{get*}} operations requires synchronization on 
internal {{Semaphore}} therefore can't be executed on interrupted thread.

2. I suggest usage explicit lock on data structure key. It helps a bit, but I 
don't get any logic in call results:

Interrupted thread:

GridDhtColocatedCache:

cache.get(key) - fails.
cache.getAsync(key).getUninterruptibly() - succeed
cache.remove(key) - succeed.
cache.removeAsync(key).getUninterruptibly() - fails.

GridDhtAtomicCache: 

All calls of get* or getAsync* fails.

Any suggestion why this happening?

This code runs OK on interrupted thread. Cache is GridDhtColocatedCache.
{code:java}
boolean lock = cache.lock(key, 0);
AtomicDataStructureValue val = cache.getAsync(key).getUninterruptibly();
cache.remove(key);
{code}

This code fails on interrupted thread. Cache is GridDhtAtomicCache
{code:java}
hdr = (GridCacheSetHeader) cctx.cache().getAsync(new 
GridCacheSetHeaderKey(name)).getUninterruptibly();
{code}

> [Test failed] 
> GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe
> -
>
> Key: IGNITE-6005
> URL: https://issues.apache.org/jira/browse/IGNITE-6005
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Nikolay Izhikov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
>
> Example of fail
> https://ci.ignite.apache.org/viewLog.html?buildId=762788=buildResultsDiv=Ignite20Tests_IgniteDataStrucutures
> Typical problem is 
> {code}
> org.apache.ignite.IgniteInterruptedException: Failed to wait for asynchronous 
> operation permit (thread got interrupted).
> at 
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:805)
> at 
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:803)
> at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:961)
> at 
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.close(GridCacheSemaphoreImpl.java:1026)
> at 
> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:458)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.InterruptedException: null
> at 
> 

[jira] [Commented] (IGNITE-6521) Review default JVM options for better performance

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6521:


GitHub user akuramshingg opened a pull request:

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

IGNITE-6521 Update JVM options (default and recommendations) for better 
performance



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

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

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

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


commit 8f2490fd64f3a0935b7633c800d804e3a2c53940
Author: Alexandr Kuramshin 
Date:   2017-10-16T09:45:13Z

IGNITE-6521 Update JVM options (default and recommendations) for better 
performance




> Review default JVM options for better performance
> -
>
> Key: IGNITE-6521
> URL: https://issues.apache.org/jira/browse/IGNITE-6521
> Project: Ignite
>  Issue Type: Improvement
>  Components: general, visor
>Affects Versions: 2.1
>Reporter: Alexandr Kuramshin
>Assignee: Alexandr Kuramshin
>
> Non-optimal recommendations are present in ignite startup scrips
> {noformat}
> ::
> :: Uncomment the following GC settings if you see spikes in your throughput 
> due to Garbage Collection.
> ::
> :: set JVM_OPTS=%JVM_OPTS% -XX:+UseParNewGC -XX:+UseConcMarkSweepGC 
> -XX:+UseTLAB -XX:NewSize=128m -XX:MaxNewSize=128m
> :: set JVM_OPTS=%JVM_OPTS% -XX:MaxTenuringThreshold=0 -XX:SurvivorRatio=1024 
> -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=60
> {noformat}
> Some utilities (like Visor) are hanged up in continuous GCs when connected to 
> large clusters (above one hundred nodes). Even after using large heap (about 
> 32 Gb).
> I'd like to propose to remove this lines and modify default JVM_OPTS as 
> follows
> {noformat}
> set JVM_OPTS=-Xms1g -Xmx8g -XX:+UseG1GC -server -XX:+AggressiveOpts 
> -XX:MaxPermSize=256m
> {noformat}



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

[jira] [Comment Edited] (IGNITE-6217) Add benchmark to compare JDBC drivers and native SQL execution

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-6217 at 10/16/17 9:46 AM:


The other benchmark result.

Configurations:
# Native SQL: 1 server, 1 client. SQL queries are execute4d on client on 
separate host
# JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host.
# JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and 
connects to the client node. SQL queries are executed on JDBC client on 
separate4 host.

SQL query:
{{SELECT val FROM test WHERE id = }}
where TEST table contains two columns: {{id long, val long}}
The table contains unique 1M rows.

|| Benchmark || Ops /sec ||
| Nativa SQL | 9385.99 |
| JDBC v2 | .48 |  
| JDBC thin | 4367.87 |


was (Author: tledkov-gridgain):
The other benchmark result.

Configurations:
# Native SQL: 1 server, 1 client. SQL queries are execute4d on client on 
separate host
# JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host.
# JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and 
connects to the client node. SQL queries are executed on JDBC client on 
separate4 host.

SQL query:
{{SELECT val FROM test WHERE id = }}
where TEST table contains two column {{id long, val long}}
The table contains unique 1M rows.

|| Benchmark || Ops /sec ||
| Nativa SQL | 9385.99 |
| JDBC v2 | .48 |  
| JDBC thin | 4367.87 |

> Add benchmark to compare JDBC drivers and native SQL execution
> --
>
> Key: IGNITE-6217
> URL: https://issues.apache.org/jira/browse/IGNITE-6217
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql, yardstick
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.4
>
>
> We have to compare performance of the native SQL execution (via Ignite SQL 
> API), JDBC v2 driver, that uses Ignite client to connect to grid and JDBC 
> thin client.



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

[jira] [Comment Edited] (IGNITE-6217) Add benchmark to compare JDBC drivers and native SQL execution

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-6217 at 10/16/17 9:46 AM:


The other benchmark result.

Configurations:
# Native SQL: 1 server, 1 client. SQL queries are execute4d on client on 
separate host
# JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host.
# JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and 
connects to the client node. SQL queries are executed on JDBC client on 
separate4 host.

SQL query:
{{SELECT val FROM test WHERE id = }}
where TEST table contains two columns: {{id long, val long}}
The table contains 1M unique rows.

|| Benchmark || Ops /sec ||
| Nativa SQL | 9385.99 |
| JDBC v2 | .48 |  
| JDBC thin | 4367.87 |


was (Author: tledkov-gridgain):
The other benchmark result.

Configurations:
# Native SQL: 1 server, 1 client. SQL queries are execute4d on client on 
separate host
# JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host.
# JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and 
connects to the client node. SQL queries are executed on JDBC client on 
separate4 host.

SQL query:
{{SELECT val FROM test WHERE id = }}
where TEST table contains two columns: {{id long, val long}}
The table contains unique 1M rows.

|| Benchmark || Ops /sec ||
| Nativa SQL | 9385.99 |
| JDBC v2 | .48 |  
| JDBC thin | 4367.87 |

> Add benchmark to compare JDBC drivers and native SQL execution
> --
>
> Key: IGNITE-6217
> URL: https://issues.apache.org/jira/browse/IGNITE-6217
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql, yardstick
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.4
>
>
> We have to compare performance of the native SQL execution (via Ignite SQL 
> API), JDBC v2 driver, that uses Ignite client to connect to grid and JDBC 
> thin client.



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

[jira] [Comment Edited] (IGNITE-6217) Add benchmark to compare JDBC drivers and native SQL execution

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-6217 at 10/16/17 9:46 AM:


The other benchmark result.

Configurations:
# Native SQL: 1 server, 1 client. SQL queries are execute4d on client on 
separate host
# JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host.
# JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and 
connects to the client node. SQL queries are executed on JDBC client on 
separate4 host.

SQL query:
{{SELECT val FROM test WHERE id = }}
where TEST table contains two column {{id long, val long}}
The table contains unique 1M rows.

|| Benchmark || Ops /sec ||
| Nativa SQL | 9385.99 |
| JDBC v2 | .48 |  
| JDBC thin | 4367.87 |


was (Author: tledkov-gridgain):
The other benchmark result.

Configurations:
# Native SQL: 1 server, 1 client. SQL queries are execute4d on client on 
separate host
# JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host.
# JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and 
connects to the client node. SQL queries are executed on JDBC client on 
separate4 host.

SQL query:
{{SELECT val FROM test WHERE id =  }}
where TEST table contains two column {{id long, val long}}
The table contains unique 1M rows.

|| Benchmark || Ops /sec ||
| Nativa SQL | 9385.99 |
| JDBC v2 | .48 |  
| JDBC thin | 4367.87 |

> Add benchmark to compare JDBC drivers and native SQL execution
> --
>
> Key: IGNITE-6217
> URL: https://issues.apache.org/jira/browse/IGNITE-6217
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql, yardstick
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.4
>
>
> We have to compare performance of the native SQL execution (via Ignite SQL 
> API), JDBC v2 driver, that uses Ignite client to connect to grid and JDBC 
> thin client.



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

[jira] [Commented] (IGNITE-6634) SQL: move IgniteDistributedJoinTestSuite to query suite(s)

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-6634:
-

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

> SQL: move IgniteDistributedJoinTestSuite to query suite(s)
> --
>
> Key: IGNITE-6634
> URL: https://issues.apache.org/jira/browse/IGNITE-6634
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.4
>
>
> Currently this suite is executed as a part of continuous queries tests.



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

[jira] [Updated] (IGNITE-6234) [Test failure] GridCacheClientModesTcpClientDiscoveryAbstractTest$CaseNearReplicatedTransactional.testGetFromClientNode

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6234:

Fix Version/s: 2.4

> [Test failure] 
> GridCacheClientModesTcpClientDiscoveryAbstractTest$CaseNearReplicatedTransactional.testGetFromClientNode
> ---
>
> Key: IGNITE-6234
> URL: https://issues.apache.org/jira/browse/IGNITE-6234
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.4
>
>
> Test reproducible locally although with a very low probability. 
> I wasn't able to reproduce it starting test in isolation but managed to do it 
> starting *GridCacheClientModesTcpClientDiscoveryAbstractTest* 50 times in a 
> row observing from 1 to 3 failures.
> Test run with failed test is available 
> [here|https://ci.ignite.apache.org/viewLog.html?buildId=798538=buildResultsDiv=Ignite20Tests_IgniteCache].
> It seems that when client requests value of custom class from near cache it 
> may see BinaryMetadata for this class with no schema.
> Test fails with the following exception:
> {noformat}
> java.lang.NullPointerException: null
> at 
> org.apache.ignite.internal.binary.BinaryMetadata.hasSchema(BinaryMetadata.java:189)
> at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:517)
> at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.metadata(CacheObjectBinaryProcessorImpl.java:185)
> at 
> org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1237)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2005)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:284)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:183)
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.reader(BinaryObjectImpl.java:830)
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:794)
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:143)
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:161)
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinaryIfNeeded(CacheObjectUtils.java:41)
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:125)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1734)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.addResult(GridCacheContext.java:1889)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.addResult(GridCacheContext.java:1828)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.loadEntries(GridNearGetFuture.java:752)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.access$000(GridNearGetFuture.java:68)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture$MiniFuture.onResult(GridNearGetFuture.java:1012)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.onResult(GridNearGetFuture.java:215)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearCacheAdapter.processGetResponse(GridNearCacheAdapter.java:294)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTransactionalCache$1.apply(GridNearTransactionalCache.java:92)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTransactionalCache$1.apply(GridNearTransactionalCache.java:90)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> at 
> 

[jira] [Commented] (IGNITE-6632) SQL: simplify GridH2Row infrastructure

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6632:


Github user devozerov closed the pull request at:

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


> SQL: simplify GridH2Row infrastructure
> --
>
> Key: IGNITE-6632
> URL: https://issues.apache.org/jira/browse/IGNITE-6632
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.4
>
>
> Currently we have a lot of {{GridH2Row}} implementations. But in reality we 
> need only two - for normal row and for deleted row. 
> Need to refactor the rest rows so that they do not extend {{GridH2Row}}. 
> Without it we will not be able to decouple H2 index from H2 infrastructure.



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

[jira] [Comment Edited] (IGNITE-6217) Add benchmark to compare JDBC drivers and native SQL execution

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-6217 at 10/16/17 9:29 AM:


The other benchmark result.

Configurations:
# Native SQL: 1 server, 1 client. SQL queries are execute4d on client on 
separate host
# JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host.
# JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and 
connects to the client node. SQL queries are executed on JDBC client on 
separate4 host.

SQL query:
{{SELECT val FROM test WHERE id =  }}
where TEST table contains two column {{id long, val long}}
The table contains unique 1M rows.

|| Benchmark || Ops /sec ||
| Nativa SQL | 9385.99 |
| JDBC v2 | .48 |  
| JDBC thin | 4367.87 |


was (Author: tledkov-gridgain):
The other benchmark result.

Configurations:
# Native SQL: 1 server, 1 client. SQL queries are execute4d on client on 
separate host
# JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host.
# JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and 
connects to the client node. SQL queries are executed on JDBC client on 
separate4 host.
|| Benchmark || Ops /sec ||
| Nativa SQL | 9385.99 |
| JDBC v2 | .48 |  
| JDBC thin | 4367.87 |

> Add benchmark to compare JDBC drivers and native SQL execution
> --
>
> Key: IGNITE-6217
> URL: https://issues.apache.org/jira/browse/IGNITE-6217
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql, yardstick
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.4
>
>
> We have to compare performance of the native SQL execution (via Ignite SQL 
> API), JDBC v2 driver, that uses Ignite client to connect to grid and JDBC 
> thin client.



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

[jira] [Commented] (IGNITE-6217) Add benchmark to compare JDBC drivers and native SQL execution

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-6217:
--

The other benchmark result.

Configurations:
# Native SQL: 1 server, 1 client. SQL queries are execute4d on client on 
separate host
# JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host.
# JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and 
connects to the client node. SQL queries are executed on JDBC client on 
separate4 host.
|| Benchmark || Ops /sec ||
| Nativa SQL | 9385.99 |
| JDBC v2 | .48 |  
| JDBC thin | 4367.87 |

> Add benchmark to compare JDBC drivers and native SQL execution
> --
>
> Key: IGNITE-6217
> URL: https://issues.apache.org/jira/browse/IGNITE-6217
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql, yardstick
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.4
>
>
> We have to compare performance of the native SQL execution (via Ignite SQL 
> API), JDBC v2 driver, that uses Ignite client to connect to grid and JDBC 
> thin client.



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

[jira] [Commented] (IGNITE-6634) SQL: move IgniteDistributedJoinTestSuite to query suite(s)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6634:


GitHub user devozerov opened a pull request:

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

IGNITE-6634



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

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

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

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


commit 593a7795738b453a6579faf078da1f4996f6f44d
Author: devozerov 
Date:   2017-10-16T09:25:32Z

Done.




> SQL: move IgniteDistributedJoinTestSuite to query suite(s)
> --
>
> Key: IGNITE-6634
> URL: https://issues.apache.org/jira/browse/IGNITE-6634
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.4
>
>
> Currently this suite is executed as a part of continuous queries tests.



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

[jira] [Created] (IGNITE-6634) SQL: move IgniteDistributedJoinTestSuite to query suite(s)

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6634:
---

 Summary: SQL: move IgniteDistributedJoinTestSuite to query suite(s)
 Key: IGNITE-6634
 URL: https://issues.apache.org/jira/browse/IGNITE-6634
 Project: Ignite
  Issue Type: Task
  Security Level: Public (Viewable by anyone)
  Components: sql
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.4


Currently this suite is executed as a part of continuous queries tests.



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

[jira] [Created] (IGNITE-6633) Repair basic SQL functionality

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-6633:
-

 Summary: Repair basic SQL functionality
 Key: IGNITE-6633
 URL: https://issues.apache.org/jira/browse/IGNITE-6633
 Project: Ignite
  Issue Type: Improvement
  Security Level: Public (Viewable by anyone)
  Components: sql
Reporter: Alexei Scherbakov
 Fix For: 2.4


For a long time SQL engine has known limitation (H2 related) [1]

This is huge usability issue, because proposed workaround requires query 
rewriting and is difficult to implement in some cases, e.g. when some kind of 
query builder is used.

I suggest to fix it at last.

[1] 
https://apacheignite.readme.io/v2.1/docs/sql-performance-and-debugging#sql-performance-and-usability-considerations



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

[jira] [Commented] (IGNITE-6632) SQL: simplify GridH2Row infrastructure

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-6632:
-

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

> SQL: simplify GridH2Row infrastructure
> --
>
> Key: IGNITE-6632
> URL: https://issues.apache.org/jira/browse/IGNITE-6632
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.4
>
>
> Currently we have a lot of {{GridH2Row}} implementations. But in reality we 
> need only two - for normal row and for deleted row. 
> Need to refactor the rest rows so that they do not extend {{GridH2Row}}. 
> Without it we will not be able to decouple H2 index from H2 infrastructure.



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

[jira] [Commented] (IGNITE-6632) SQL: simplify GridH2Row infrastructure

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6632:


GitHub user devozerov opened a pull request:

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

IGNITE-6632



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

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

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

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


commit b807a7f0ff33de416287b506927188b077744109
Author: devozerov 
Date:   2017-10-16T08:02:23Z

WIP.

commit d40025def33eb46d85abb60457ce0adc110b8ac2
Author: devozerov 
Date:   2017-10-16T08:10:31Z

Key-only row.

commit da96581de2e45fcfb8fea7215f84ddb1610b327a
Author: devozerov 
Date:   2017-10-16T08:10:40Z

Key-only row.

commit 4732faa5c4ad0a636a494fcf6a5da7bdef57f7d3
Author: devozerov 
Date:   2017-10-16T08:14:05Z

It compiles.

commit fe602efca5b873397cd956fad0b9e73ef4e0d603
Author: devozerov 
Date:   2017-10-16T08:21:23Z

Hidden public fields.




> SQL: simplify GridH2Row infrastructure
> --
>
> Key: IGNITE-6632
> URL: https://issues.apache.org/jira/browse/IGNITE-6632
> Project: Ignite
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.4
>
>
> Currently we have a lot of {{GridH2Row}} implementations. But in reality we 
> need only two - for normal row and for deleted row. 
> Need to refactor the rest rows so that they do not extend {{GridH2Row}}. 
> Without it we will not be able to decouple H2 index from H2 infrastructure.



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

[jira] [Created] (IGNITE-6632) SQL: simplify GridH2Row infrastructure

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6632:
---

 Summary: SQL: simplify GridH2Row infrastructure
 Key: IGNITE-6632
 URL: https://issues.apache.org/jira/browse/IGNITE-6632
 Project: Ignite
  Issue Type: Task
  Security Level: Public (Viewable by anyone)
  Components: sql
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.4


Currently we have a lot of {{GridH2Row}} implementations. But in reality we 
need only two - for normal row and for deleted row. 

Need to refactor the rest rows so that they do not extend {{GridH2Row}}. 
Without it we will not be able to decouple H2 index from H2 infrastructure.



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

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

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii commented on IGNITE-2313:


[~avinogradov], [~sboikov], I've done with tests. PR is ready, can you merge it?

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



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

[jira] [Commented] (IGNITE-6631) Optimize GridH2KeyValueRowOnheap.getValue() method

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6631:


Github user devozerov closed the pull request at:

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


> Optimize GridH2KeyValueRowOnheap.getValue() method
> --
>
> Key: IGNITE-6631
> URL: https://issues.apache.org/jira/browse/IGNITE-6631
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.4
>
>
> There are some unnecessary operations around this method:
> 1) Redundant recursion
> 2) Too big value cache
> Etc.
> Need to optimize it.



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