[jira] [Commented] (IGNITE-4633) Initiate DDL operation through custom discovery message

2017-02-03 Thread Alexander Paschenko (JIRA)

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

Alexander Paschenko commented on IGNITE-4633:
-

Working on INIT/ACK/error handling; ETA is Mon/Tue.

> Initiate DDL operation through custom discovery message
> ---
>
> Key: IGNITE-4633
> URL: https://issues.apache.org/jira/browse/IGNITE-4633
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.0
>
>
> Design considerations:
> 1) Create generic DDL custom discovery message pair - {{INIT}} and {{ACK}} 
> messages - which will hold concrete DDL commands.
> 2) Originator must generate unique message ID to be able to track it later.
> 3) Coordinator calculates all participants through affinity API and adds them 
> to message.
> 4) {{INIT}} message goes through the ring and:performs some fast preliminary 
> checks if necessary and collects error; in particular it may verify whether 
> schema change is valid to allow for fail-fast client notification.;
> 5) If at least one error occurs during {{INIT}} stage, originator may throw 
> exception to the user.
> 6) {{ACK}} message schedules asynchronous execution of the command.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (IGNITE-4617) CPP: Implement Field-access methods for binary objects

2017-02-03 Thread Igor Sapego (JIRA)

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

Igor Sapego commented on IGNITE-4617:
-

I've run into a something, that seems like a pretty serious problem to me. 
Current implementation of binary format requires uses field ids in object 
schema. To resolve such ids from name one have to use 
{{TemplatedBinaryIdResolver}}, which is obviously enough templated and requires 
object type. So basically this all leads to the following, to get valid 
{{BinaryObject}} on which we can call {{HasField}} and {{GetField}} methods 
user still needs to specify object type. Something like:
{code}
BinaryObject obj = cache.GetBinary(key);
BinaryObject field = obj.GetBinaryField("field_name");
{code}


> CPP: Implement Field-access methods for binary objects
> --
>
> Key: IGNITE-4617
> URL: https://issues.apache.org/jira/browse/IGNITE-4617
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.8
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 1.9
>
>
> Currently we have very limited implementation of binary objects that does not 
>  provide access to fields of the binary object. At least such methods as 
> {{HasField}} and {{GetField}} should be implemented.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Comment Edited] (IGNITE-3793) Need to fix dependencies and it's licenses.

2017-02-03 Thread Denis Magda (JIRA)

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

Denis Magda edited comment on IGNITE-3793 at 2/3/17 6:28 PM:
-

Alexandr, thanks! Merged your changes to the master.


was (Author: dmagda):
Alexandr, thanks! Merged your changes.

> Need to fix dependencies and it's licenses.
> ---
>
> Key: IGNITE-3793
> URL: https://issues.apache.org/jira/browse/IGNITE-3793
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Alexandr Fedotov
>Priority: Blocker
>  Labels: important
> Fix For: 1.9
>
>
> 1) H2 license listed at LICENSE_FABRIC seems to be wrong.
> Need to make sure that correct one listed at ignite-indexing-licenses.txt and 
> remove wrong at LICENSE_FABRIC.
> 2) JCache changed the license to Apache 2.0 
> (https://raw.githubusercontent.com/jsr107/jsr107spec/master/LICENSE.txt). 
> Content of {{ignite-core-licenses.txt}} mustn't be mentioned there. JCache 
> has to be mentioned the file from 3)
> 3) Apache licenses should be always shown at ignite-*-licenses.txt.
> licenses.txt.vm should be fixed.
> 4)  Revert geronimo related changes merged into this branch. Geronimo is no 
> longer needed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Closed] (IGNITE-3793) Need to fix dependencies and it's licenses.

2017-02-03 Thread Denis Magda (JIRA)

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

Denis Magda closed IGNITE-3793.
---

> Need to fix dependencies and it's licenses.
> ---
>
> Key: IGNITE-3793
> URL: https://issues.apache.org/jira/browse/IGNITE-3793
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Alexandr Fedotov
>Priority: Blocker
>  Labels: important
> Fix For: 1.9
>
>
> 1) H2 license listed at LICENSE_FABRIC seems to be wrong.
> Need to make sure that correct one listed at ignite-indexing-licenses.txt and 
> remove wrong at LICENSE_FABRIC.
> 2) JCache changed the license to Apache 2.0 
> (https://raw.githubusercontent.com/jsr107/jsr107spec/master/LICENSE.txt). 
> Content of {{ignite-core-licenses.txt}} mustn't be mentioned there. JCache 
> has to be mentioned the file from 3)
> 3) Apache licenses should be always shown at ignite-*-licenses.txt.
> licenses.txt.vm should be fixed.
> 4)  Revert geronimo related changes merged into this branch. Geronimo is no 
> longer needed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (IGNITE-3793) Need to fix dependencies and it's licenses.

2017-02-03 Thread Denis Magda (JIRA)

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

Denis Magda commented on IGNITE-3793:
-

Alexandr, thanks! Merged your changes.

> Need to fix dependencies and it's licenses.
> ---
>
> Key: IGNITE-3793
> URL: https://issues.apache.org/jira/browse/IGNITE-3793
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Alexandr Fedotov
>Priority: Blocker
>  Labels: important
> Fix For: 1.9
>
>
> 1) H2 license listed at LICENSE_FABRIC seems to be wrong.
> Need to make sure that correct one listed at ignite-indexing-licenses.txt and 
> remove wrong at LICENSE_FABRIC.
> 2) JCache changed the license to Apache 2.0 
> (https://raw.githubusercontent.com/jsr107/jsr107spec/master/LICENSE.txt). 
> Content of {{ignite-core-licenses.txt}} mustn't be mentioned there. JCache 
> has to be mentioned the file from 3)
> 3) Apache licenses should be always shown at ignite-*-licenses.txt.
> licenses.txt.vm should be fixed.
> 4)  Revert geronimo related changes merged into this branch. Geronimo is no 
> longer needed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (IGNITE-4212) Ignite Benchmarking Simplification and Automation

2017-02-03 Thread Denis Magda (JIRA)

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

Denis Magda commented on IGNITE-4212:
-

* {{Building the project}} section says that {{Please look for the building 
instructions in `DEVNOTES.txt`}}. However, the devnotes are located under 
"source" folder. They either have to be placed under "benchmarks" folder or the 
documentation has to say that they are under "sources" folder.

* Documented property {{config/benchmark-atomic-put.properties}} is missing. 
Can't check benchmarks execution as README says.

* If to follow the instructions and execute {{`./bin/benchmark-run-all.sh`}} 
then I see this error all the time

{code}
<11:14:35> Starting driver config '...eTxBenchmark -sn IgniteNode 
-ds RELEASE-tx-invoke-1-backup' on localhost with id=0
ssh: connect to host localhost port 22: Connection refused
ssh: connect to host localhost port 22: Connection refused
ssh: connect to host localhost port 22: Connection refused
{code}

* Why do I need this? 
{{NOTE: You need to configure ssh key-based authentication to localhost for 
running benchmarks on your local machine.}}

I've edited the README file. Please copy-paste all the content from the 
attached one in this ticket. I'll review and edit {{Running Ignite Benchmarks 
Remotely}} section after the issues above are resolved.

> Ignite Benchmarking Simplification and Automation
> -
>
> Key: IGNITE-4212
> URL: https://issues.apache.org/jira/browse/IGNITE-4212
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Assignee: Oleg Ostanin
> Fix For: 2.0
>
>
> There is a plenty of useful Yardstick benchmarks located in ignite-yardstick 
> module that is used by the community to check Ignite performance across 
> deployments of different configurations.
> However, it's not easy to start with the benchmarking process because the 
> user needs to download Ignite, build and set up benchmarks and only after 
> that run them.
> The goal of this task is to simplify the process in the following way:
> 1) ignite-yardstick benchmarks have to be pre-compiled and available with 
> every Ignite deliverable.
> 2) every deliverable must contain an executable (bat or sh file) with a clear 
> instruction on how to start a specific benchmark from the console.
> 3) the executable has to use some default yardstick configuration. The first 
> configuration should be intented for local execution (multicast IP finder) 
> and the second needs to be AWS oriented.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-4212) Ignite Benchmarking Simplification and Automation

2017-02-03 Thread Denis Magda (JIRA)

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

Denis Magda updated IGNITE-4212:

Attachment: README.txt

> Ignite Benchmarking Simplification and Automation
> -
>
> Key: IGNITE-4212
> URL: https://issues.apache.org/jira/browse/IGNITE-4212
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Assignee: Oleg Ostanin
> Fix For: 2.0
>
> Attachments: README.txt
>
>
> There is a plenty of useful Yardstick benchmarks located in ignite-yardstick 
> module that is used by the community to check Ignite performance across 
> deployments of different configurations.
> However, it's not easy to start with the benchmarking process because the 
> user needs to download Ignite, build and set up benchmarks and only after 
> that run them.
> The goal of this task is to simplify the process in the following way:
> 1) ignite-yardstick benchmarks have to be pre-compiled and available with 
> every Ignite deliverable.
> 2) every deliverable must contain an executable (bat or sh file) with a clear 
> instruction on how to start a specific benchmark from the console.
> 3) the executable has to use some default yardstick configuration. The first 
> configuration should be intented for local execution (multicast IP finder) 
> and the second needs to be AWS oriented.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Comment Edited] (IGNITE-4541) Create test for Hadoop running in external JVM

2017-02-03 Thread Ivan Veselovsky (JIRA)

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

Ivan Veselovsky edited comment on IGNITE-4541 at 2/3/17 6:30 PM:
-

Created 2 versions of this fix:

"Full" version: all the tests suite is running in multi-JVM mode, branch 
ignite-4541, prq 1490 , build passed on TC, but ~10 tests are disabled -- 2 
problems are still pending.
Tests: 
http://ci.ignite.apache.org/viewLog.html?buildId=443000=buildResultsDiv=IgniteTests_IgniteHadoop

"Lingt" version: only TeraSort test is running in Multi-JVM mode, branch 
ignite-4541b, prq 1497, waiting for TC results, but locally tests pass. This is 
ready for review if tests are ok on TC. 
Tests: 
http://ci.ignite.apache.org/viewLog.html?buildId=443470=buildResultsDiv=IgniteTests_IgniteHadoop
 


was (Author: iveselovskiy):
Created 2 versions of this fix:
"Full" version: all the tests suite is running in multi-JVM mode, branch 
ignite-4541, prq 1490 , build passed on TC, but ~10 tests are disabled -- 2 
problems are still pending.
"Lingt" version: only TeraSort test is running in Multi-JVM mode, branch 
ignite-4541b, prq 1497, waiting for TC results, but locally tests pass. This is 
ready for review if tests are ok on TC. 

> Create test for Hadoop running in external JVM
> --
>
> Key: IGNITE-4541
> URL: https://issues.apache.org/jira/browse/IGNITE-4541
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Ivan Veselovsky
> Fix For: 2.0
>
>
> *Problem*
> Currently we run all Hadoop tests in synthetic "single JVM" mode. This way we 
> miss lots of potential issues. We need to be able to run them in real 
> distributed mode, but on a single machine.
> *Simplified solution*
> 1) Start N external nodes
> 2) Submit a job to these nodes and validate the result
> We can start with simple Teragen->Terasort->Teravalidate scenario. 
> Please look through {{Process}} and {{ProcessBuilder}} classes usages - most 
> probably we already have all necessary infrastructure to start nodes in 
> external JVM.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (IGNITE-4619) .NET: TransactionScope documentation and example

2017-02-03 Thread Denis Magda (JIRA)

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

Denis Magda commented on IGNITE-4619:
-

[~ptupitsyn], please give me a couple of days for more thoughtful review. Will 
be back at the beginning of the next week.

> .NET: TransactionScope documentation and example
> 
>
> Key: IGNITE-4619
> URL: https://issues.apache.org/jira/browse/IGNITE-4619
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.9
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 1.9
>
>
> Create documentation and example for {{TransactionScope}} support 
> (IGNITE-3430).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (IGNITE-4269) Implement batch statements in JDBC driver

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov reassigned IGNITE-4269:
---

Assignee: (was: Alexander Paschenko)

> Implement batch statements in JDBC driver
> -
>
> Key: IGNITE-4269
> URL: https://issues.apache.org/jira/browse/IGNITE-4269
> Project: Ignite
>  Issue Type: New Feature
>  Components: SQL
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
> Fix For: 1.9
>
>
> In the course of review of initial DML implementation, it has been agreed 
> that the first attempt to implement batching (via series of individual 
> queries) is rather incorrect (effectively series of individual queries 
> instead of one larger query). So it's been decided not to include batching 
> into initial release and rather implement it the right way shortly in nearest 
> releases.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Closed] (IGNITE-4269) Implement batch statements in JDBC driver

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov closed IGNITE-4269.
---

> Implement batch statements in JDBC driver
> -
>
> Key: IGNITE-4269
> URL: https://issues.apache.org/jira/browse/IGNITE-4269
> Project: Ignite
>  Issue Type: New Feature
>  Components: SQL
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 1.9
>
>
> In the course of review of initial DML implementation, it has been agreed 
> that the first attempt to implement batching (via series of individual 
> queries) is rather incorrect (effectively series of individual queries 
> instead of one larger query). So it's been decided not to include batching 
> into initial release and rather implement it the right way shortly in nearest 
> releases.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Reopened] (IGNITE-4269) Implement batch statements in JDBC driver

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov reopened IGNITE-4269:
-

> Implement batch statements in JDBC driver
> -
>
> Key: IGNITE-4269
> URL: https://issues.apache.org/jira/browse/IGNITE-4269
> Project: Ignite
>  Issue Type: New Feature
>  Components: SQL
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 1.9
>
>
> In the course of review of initial DML implementation, it has been agreed 
> that the first attempt to implement batching (via series of individual 
> queries) is rather incorrect (effectively series of individual queries 
> instead of one larger query). So it's been decided not to include batching 
> into initial release and rather implement it the right way shortly in nearest 
> releases.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Resolved] (IGNITE-4269) Implement batch statements in JDBC driver

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov resolved IGNITE-4269.
-
Resolution: Duplicate

> Implement batch statements in JDBC driver
> -
>
> Key: IGNITE-4269
> URL: https://issues.apache.org/jira/browse/IGNITE-4269
> Project: Ignite
>  Issue Type: New Feature
>  Components: SQL
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 1.9
>
>
> In the course of review of initial DML implementation, it has been agreed 
> that the first attempt to implement batching (via series of individual 
> queries) is rather incorrect (effectively series of individual queries 
> instead of one larger query). So it's been decided not to include batching 
> into initial release and rather implement it the right way shortly in nearest 
> releases.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (IGNITE-4196) H2 debug console is always started on artificial port

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov commented on IGNITE-4196:
-

Merged to {{master}} as impact is minor.

> H2 debug console is always started on artificial port
> -
>
> Key: IGNITE-4196
> URL: https://issues.apache.org/jira/browse/IGNITE-4196
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Sergey Kalashnikov
> Fix For: 1.9
>
>
> When H2 debug console is started as described in [1], it always binds to an 
> artificial port. This has at least two issues:
> * Sometimes a client wants to connect through firewall. It's impossible to 
> open all possible ports for the console.
> * If there is no GUI on server node, console can't be opened in a browser, so 
> user has no idea what to do next and how to connect.
> We should:
> * Print out the information about how to connect to the console after it's 
> started.
> * Allow to use a specific port provided as a system property.
> [1] https://apacheignite.readme.io/docs/sql-queries#using-h2-debug-console



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (IGNITE-4105) Create separate thread pool for SQL queries.

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov reassigned IGNITE-4105:
---

Resolution: Fixed
  Assignee: Sergey Kalashnikov  (was: Vladimir Ozerov)

LGTM.

> Create separate thread pool for SQL queries.
> 
>
> Key: IGNITE-4105
> URL: https://issues.apache.org/jira/browse/IGNITE-4105
> Project: Ignite
>  Issue Type: Task
>  Components: SQL
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Sergey Kalashnikov
>Priority: Critical
> Fix For: 2.0
>
>
> If several long-running queries are executed, all concurrent cache operations 
> will be blocked because there will be no threads in system pool to server 
> cache requests/responses.
> Let's introduce separate thread pool for SQL queries execution.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (IGNITE-4537) Update Notifier must not transfer system properties

2017-02-03 Thread Semen Boikov (JIRA)

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

Semen Boikov reassigned IGNITE-4537:


Assignee: Dmitry Karachentsev  (was: Semen Boikov)

Looks good.

Thanks!

> Update Notifier must not transfer system properties
> ---
>
> Key: IGNITE-4537
> URL: https://issues.apache.org/jira/browse/IGNITE-4537
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Dmitry Karachentsev
>Priority: Critical
> Fix For: 1.9
>
>
> Apache Ignite Update Notifier that is used for sending updates about new 
> Apache Ignite versions gathers and transfers all system properties.
> The script must not do this. Instead, it has to get only those system 
> properties like Java version, OS versions that are needed. Otherwise, the 
> script might send sensitive information like passwords stored in the system 
> properties.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-4552) Optimize GridDhtLocalPartition.rmvQueue

2017-02-03 Thread Stanilovsky Evgeny (JIRA)

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

Stanilovsky Evgeny updated IGNITE-4552:
---
Attachment: Plot_ThroughputLatencyProbe_01_20170203_1.png

> Optimize GridDhtLocalPartition.rmvQueue
> ---
>
> Key: IGNITE-4552
> URL: https://issues.apache.org/jira/browse/IGNITE-4552
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Stanilovsky Evgeny
> Fix For: 2.0
>
> Attachments: benchmark-put-remove-simultaneously.properties, 
> Plot_ThroughputLatencyProbe_01_20170203_1.png, 
> Plot_ThroughputLatencyProbe_01_31_origin.png, 
> Plot_ThroughputLatencyProbe_01_4552_mine.png, 
> Plot_ThroughputLatencyProbe_01_mine_3node.png, 
> Plot_ThroughputLatencyProbe_01_mine.png, 
> Plot_ThroughputLatencyProbe_01_origin_3node.png, 
> Plot_ThroughputLatencyProbe_01_origin.png, Screenshot_20170124_155355.png
>
>
> Current implementation stores deferred entry removals in rmvQueue for 
> consistency guaranties.
> This can lead to significant heap over-usage(I observed several Gbs) in case 
> of many caches with removals, because currently queue is cleared lazily after 
> reaching max capacity(200_000 by default).
> This can be mitigated by using lower IGNITE_ATOMIC_CACHE_DELETE_HISTORY_SIZE, 
> but can lead to consistency issues in case of frequent cache updates.
> Possible optimizations:
> * Use single fixed size queue per all caches to overcome limitations of 
> IGNITE_ATOMIC_CACHE_DELETE_HISTORY_SIZE workaround.
> * Do queue cleaning in background
> * Move queue to an off-heap.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (IGNITE-4196) H2 debug console is always started on artificial port

2017-02-03 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-4196:


Github user asfgit closed the pull request at:

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


> H2 debug console is always started on artificial port
> -
>
> Key: IGNITE-4196
> URL: https://issues.apache.org/jira/browse/IGNITE-4196
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Sergey Kalashnikov
> Fix For: 1.9
>
>
> When H2 debug console is started as described in [1], it always binds to an 
> artificial port. This has at least two issues:
> * Sometimes a client wants to connect through firewall. It's impossible to 
> open all possible ports for the console.
> * If there is no GUI on server node, console can't be opened in a browser, so 
> user has no idea what to do next and how to connect.
> We should:
> * Print out the information about how to connect to the console after it's 
> started.
> * Allow to use a specific port provided as a system property.
> [1] https://apacheignite.readme.io/docs/sql-queries#using-h2-debug-console



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (IGNITE-4252) ClassCastException with local cache query

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov commented on IGNITE-4252:
-

LGTM, merging.

> ClassCastException with local cache query
> -
>
> Key: IGNITE-4252
> URL: https://issues.apache.org/jira/browse/IGNITE-4252
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Reporter: Pavel Konstantinov
>Assignee: Sergey Kalashnikov
> Fix For: 1.9
>
>
> Try to send query for local cache to partitioned cache for executing:
> Two caches: local_cache & partitioned_cache.
> // SQL query performed on local_cache, but entry point is partitioned_cache.
> ignite.cache("partitioned_cache").query(new SqlFieldsQuery("select * from 
> "local_cache".Table"))
> {code}
> java.lang.ClassCastException: 
> org.apache.ignite.internal.processors.cache.local.atomic.GridLocalAtomicCache 
> cannot be cast to 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.topology(GridCacheContext.java:853)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.topology(GridCacheContext.java:831)
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.hasMovingPartitions(GridReduceQueryExecutor.java:389)
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.isPreloadingActive(GridReduceQueryExecutor.java:376)
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:520)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$5.iterator(IgniteH2Indexing.java:1089)
>   at 
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:81)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (IGNITE-4252) ClassCastException with local cache query

2017-02-03 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-4252:


Github user asfgit closed the pull request at:

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


> ClassCastException with local cache query
> -
>
> Key: IGNITE-4252
> URL: https://issues.apache.org/jira/browse/IGNITE-4252
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Reporter: Pavel Konstantinov
>Assignee: Sergey Kalashnikov
> Fix For: 1.9
>
>
> Try to send query for local cache to partitioned cache for executing:
> Two caches: local_cache & partitioned_cache.
> // SQL query performed on local_cache, but entry point is partitioned_cache.
> ignite.cache("partitioned_cache").query(new SqlFieldsQuery("select * from 
> "local_cache".Table"))
> {code}
> java.lang.ClassCastException: 
> org.apache.ignite.internal.processors.cache.local.atomic.GridLocalAtomicCache 
> cannot be cast to 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.topology(GridCacheContext.java:853)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.topology(GridCacheContext.java:831)
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.hasMovingPartitions(GridReduceQueryExecutor.java:389)
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.isPreloadingActive(GridReduceQueryExecutor.java:376)
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:520)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$5.iterator(IgniteH2Indexing.java:1089)
>   at 
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:81)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Comment Edited] (IGNITE-3429) org.hibernate.cache.spi.CacheKey not properly serialized by binary marshaller

2017-02-03 Thread Cameron Braid (JIRA)

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

Cameron Braid edited comment on IGNITE-3429 at 2/4/17 6:33 AM:
---

For hibernate 5.1 since CacheKey doesn't exist, use the following :
{code}
BinaryConfiguration bCfg = new BinaryConfiguration();

BinaryTypeConfiguration btCfg = new BinaryTypeConfiguration();

// must be a string since class is not public

btCfg.setTypeName("org.hibernate.cache.internal.OldCacheKeyImplementation");
btCfg.setIdentityResolver(new BinaryAbstractIdentityResolver() {
@Override protected int hashCode0(BinaryObject obj) {
return obj.field("id").hashCode();
}

@Override protected boolean equals0(BinaryObject o1, BinaryObject 
o2) {
Object obj0 = o1.field("id");
Object obj1 = o2.field("id");

return Objects.equals(obj0, obj1);
}
});

bCfg.setTypeConfigurations(Collections.singleton(btCfg));
igniteConfig.setBinaryConfiguration(bCfg);
{code}


was (Author: cameronbraid):
For hibernate 5 since CacheKey doesn't exist, use the following :
{code}
BinaryConfiguration bCfg = new BinaryConfiguration();

BinaryTypeConfiguration btCfg = new BinaryTypeConfiguration();

// must be a string since class is not public

btCfg.setTypeName("org.hibernate.cache.internal.OldCacheKeyImplementation");
btCfg.setIdentityResolver(new BinaryAbstractIdentityResolver() {
@Override protected int hashCode0(BinaryObject obj) {
return obj.field("id").hashCode();
}

@Override protected boolean equals0(BinaryObject o1, BinaryObject 
o2) {
Object obj0 = o1.field("id");
Object obj1 = o2.field("id");

return Objects.equals(obj0, obj1);
}
});

bCfg.setTypeConfigurations(Collections.singleton(btCfg));
igniteConfig.setBinaryConfiguration(bCfg);
{code}

> org.hibernate.cache.spi.CacheKey not properly serialized by binary marshaller
> -
>
> Key: IGNITE-3429
> URL: https://issues.apache.org/jira/browse/IGNITE-3429
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, Hibernate L2 cache
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Priority: Critical
> Fix For: 2.0
>
>
> {{org.hibernate.cache.spi.CacheKey}} is a class used as a key for all entries 
> in the Hibernate L2 cache. This class contains {{type}} field and custom 
> {{equals}} logic where the type is used as a helper and does not participate 
> in comparison. Instances of the same type are producing different hash codes 
> in different JVMs, which actually breaks comparison when binary format is 
> used, where byte arrays are compared.
> The issue is described in more detail here: 
> http://stackoverflow.com/questions/38132263/apache-ignite-as-hibernate-l2-cache-storing-duplicate-entities



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (IGNITE-3429) org.hibernate.cache.spi.CacheKey not properly serialized by binary marshaller

2017-02-03 Thread Cameron Braid (JIRA)

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

Cameron Braid commented on IGNITE-3429:
---

For hibernate 5 since CacheKey doesn't exist, use the following :
{code}
BinaryConfiguration bCfg = new BinaryConfiguration();

BinaryTypeConfiguration btCfg = new BinaryTypeConfiguration();

// must be a string since class is not public

btCfg.setTypeName("org.hibernate.cache.internal.OldCacheKeyImplementation");
btCfg.setIdentityResolver(new BinaryAbstractIdentityResolver() {
@Override protected int hashCode0(BinaryObject obj) {
return obj.field("id").hashCode();
}

@Override protected boolean equals0(BinaryObject o1, BinaryObject 
o2) {
Object obj0 = o1.field("id");
Object obj1 = o2.field("id");

return Objects.equals(obj0, obj1);
}
});

bCfg.setTypeConfigurations(Collections.singleton(btCfg));
igniteConfig.setBinaryConfiguration(bCfg);
{code}

> org.hibernate.cache.spi.CacheKey not properly serialized by binary marshaller
> -
>
> Key: IGNITE-3429
> URL: https://issues.apache.org/jira/browse/IGNITE-3429
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, Hibernate L2 cache
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Priority: Critical
> Fix For: 2.0
>
>
> {{org.hibernate.cache.spi.CacheKey}} is a class used as a key for all entries 
> in the Hibernate L2 cache. This class contains {{type}} field and custom 
> {{equals}} logic where the type is used as a helper and does not participate 
> in comparison. Instances of the same type are producing different hash codes 
> in different JVMs, which actually breaks comparison when binary format is 
> used, where byte arrays are compared.
> The issue is described in more detail here: 
> http://stackoverflow.com/questions/38132263/apache-ignite-as-hibernate-l2-cache-storing-duplicate-entities



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3869) Reduce number of temporary objects produced by H2

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3869:

Component/s: (was: cache)
 SQL

> Reduce number of temporary objects produced by H2
> -
>
> Key: IGNITE-3869
> URL: https://issues.apache.org/jira/browse/IGNITE-3869
> Project: Ignite
>  Issue Type: Task
>  Components: SQL
>Affects Versions: 1.4
>Reporter: Denis Magda
>Assignee: Sergi Vladykin
> Fix For: 2.0
>
>
> Presently during the execution of a query H2 generates significant number of 
> temporal objects (kind of wrappers) that eventually exhaust the heap and 
> trigger long GC pauses. 
> Need to revisit present implementation improving Ignite SQL engine and/or H2.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3869) Reduce number of temporary objects produced by H2

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3869:

Fix Version/s: (was: 2.1)
   2.0

> Reduce number of temporary objects produced by H2
> -
>
> Key: IGNITE-3869
> URL: https://issues.apache.org/jira/browse/IGNITE-3869
> Project: Ignite
>  Issue Type: Task
>  Components: SQL
>Affects Versions: 1.4
>Reporter: Denis Magda
>Assignee: Sergi Vladykin
> Fix For: 2.0
>
>
> Presently during the execution of a query H2 generates significant number of 
> temporal objects (kind of wrappers) that eventually exhaust the heap and 
> trigger long GC pauses. 
> Need to revisit present implementation improving Ignite SQL engine and/or H2.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-4594) Implement index hints for SQL

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-4594:

Component/s: SQL

> Implement index hints for SQL
> -
>
> Key: IGNITE-4594
> URL: https://issues.apache.org/jira/browse/IGNITE-4594
> Project: Ignite
>  Issue Type: New Feature
>  Components: SQL
>Reporter: Denis Magda
> Fix For: 2.0
>
>
> Recently in H2 we've merged a very important feature: index hints. It is an
> additional MySQL-like syntax:
> SELECT * FROM  my_table USE INDEX (index_a) WHERE A = 1
> It will be very easy to support this in Ignite.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3595) Improve Enum fields handling in SQL.

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3595:

Fix Version/s: (was: 1.9)
   2.0

> Improve Enum fields handling in SQL.
> 
>
> Key: IGNITE-3595
> URL: https://issues.apache.org/jira/browse/IGNITE-3595
> Project: Ignite
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 1.7
>Reporter: Sergi Vladykin
>Assignee: Alexander Paschenko
>  Labels: important
> Fix For: 2.0
>
>
> Currently queries like this do not work in Ignite if we use enum field on the 
> left side and enum constant name or ordinal on the right side:
> select * from A where my_enum = 'ENUM_CONST';
> select * from A where my_enum = 3;
> This is a huge usability issue.
> We can try to solve it by contributing `User defined Value types` in H2 and 
> implementing the special value type for Enums to handle comparison with 
> String (convert to enum by name) and with int (convert to enum by ordinal).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


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

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-4191:

Component/s: SQL

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



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3478) Transactional SQL

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3478:

Fix Version/s: (was: 2.0)

> Transactional SQL
> -
>
> Key: IGNITE-3478
> URL: https://issues.apache.org/jira/browse/IGNITE-3478
> Project: Ignite
>  Issue Type: Task
>  Components: cache, SQL
>Reporter: Alexey Goncharuk
>Assignee: Sergi Vladykin
>  Labels: important
>
> Current Ignite SQL does not take into account transaction boundaries. For 
> example, if a transaction atomically changes balance of two accounts, then a 
> concurrent SQL query can see partially committed transaction. This works for 
> data analytics, but does not work for more strict and demanding scenarios.
> It would be perfect if we had a mode which ensures transaction boundaries are 
> taken into account for SQL query.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (IGNITE-4492) Add MBean for StripedExecutor

2017-02-03 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-4492:


GitHub user voipp opened a pull request:

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

IGNITE-4492 Add MBean for StripedExecutor

added MXBean and its interface for communicating with StripedExecutor
added tests for StripedExecutor

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

$ git pull https://github.com/voipp/ignite IGNITE-4492

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

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


commit a8fe21f3c672a492aa55cd013f4f2748eafa31e3
Author: voipp 
Date:   2017-01-31T08:49:34Z

IGNITE-4492 Add MBean for StripedExecutor




> Add MBean for StripedExecutor
> -
>
> Key: IGNITE-4492
> URL: https://issues.apache.org/jira/browse/IGNITE-4492
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 1.9
>Reporter: Yakov Zhdanov
>Assignee: Alexey Kuznetsov
>Priority: Minor
>  Labels: newbie
> Fix For: 2.0
>
>
> # Add MBean interface and implementation as we have for 
> org.apache.ignite.internal.ThreadPoolMXBeanAdapter
> # Register MBean together with other pools MBeans
> # Unregister MBean on Ignite stop.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-4652) Optimization: implement BPlusTree.invoke

2017-02-03 Thread Semen Boikov (JIRA)

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

Semen Boikov updated IGNITE-4652:
-
Description: Currently for atomic cache update we first read previous cache 
value (BPlusTree.find), then depending on some cache logic can do put or remove 
(BPlusTree.put/remove). It is possible to get rid of first BPlusTree.find if 
BPlusTree provide 'invoke' operation similar to IgnteCache.invoke.

> Optimization: implement BPlusTree.invoke
> 
>
> Key: IGNITE-4652
> URL: https://issues.apache.org/jira/browse/IGNITE-4652
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Semen Boikov
> Fix For: 2.0
>
>
> Currently for atomic cache update we first read previous cache value 
> (BPlusTree.find), then depending on some cache logic can do put or remove 
> (BPlusTree.put/remove). It is possible to get rid of first BPlusTree.find if 
> BPlusTree provide 'invoke' operation similar to IgnteCache.invoke.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3860) Improve distributed SQL support.

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3860:

Fix Version/s: (was: 2.0)
   1.9

> Improve distributed SQL support.
> 
>
> Key: IGNITE-3860
> URL: https://issues.apache.org/jira/browse/IGNITE-3860
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 1.7
>Reporter: Sergi Vladykin
>Assignee: Sergi Vladykin
>Priority: Critical
>  Labels: important
> Fix For: 1.9
>
>
> Now we do not process subqueries containing aggregate functions or group bys 
> in FROM clause. Also we do not correctly process UNIONs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (IGNITE-4169) Data streamer mode for DML

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov reassigned IGNITE-4169:
---

Assignee: Alexander Paschenko  (was: Vladimir Ozerov)

> Data streamer mode for DML
> --
>
> Key: IGNITE-4169
> URL: https://issues.apache.org/jira/browse/IGNITE-4169
> Project: Ignite
>  Issue Type: New Feature
>  Components: SQL
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 1.9
>
>
> SQL INSERT and MERGE are supposed to support data streamer mode which should 
> be turned on by JDBC connection string param.
> Note: particular details of usage means and implementation of this mode, as 
> well as urgency of this feature are yet to be discussed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (IGNITE-4363) Inner properties mutation broken in SQL UPDATE

2017-02-03 Thread Alexander Paschenko (JIRA)

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

Alexander Paschenko commented on IGNITE-4363:
-

[~vozerov] merged, TC is on the run.

> Inner properties mutation broken in SQL UPDATE
> --
>
> Key: IGNITE-4363
> URL: https://issues.apache.org/jira/browse/IGNITE-4363
> Project: Ignite
>  Issue Type: Bug
>  Components: binary, SQL
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 1.9
>
>
> Discovered in course of working on IGNITE-4340.
> Say, we have following type for cache values
> {code:java}
> static final class AllTypes implements Serializable {
> /**
>  * Data Long.
>  */
> @QuerySqlField
> Long longCol;
> /**
>  * Inner type object.
>  */
> @QuerySqlField
> InnerType innerTypeCol;
> /** */
> static final class InnerType implements Serializable {
> /** */
> @QuerySqlField
> Long innerLongCol;
> /** */
> @QuerySqlField
> String innerStrCol;
>}
> }
> {code}
> Queries like this fail for both optimized and binary marshaller:
> {code:sql}
> UPDATE AllTypes set innerLongCol = ?
> {code}
> For optimized, current DML implementation mutates existing inner property 
> thus confusing DML statements re-run logic (query re-runs because engine sees 
> value as concurrently modified, though the only change is its own, and 
> ultimately fails). The solution is to clone inner objects and set new 
> property values on them because we need to have old value pristine.
> For binary, current DML implementation does not honor properties hierarchy 
> and, for above example, just sets {{innerLongCol}} field on {{AllTypes}} 
> binary object and not its child {{InnerType}} object. Thus, index will be 
> updated and SELECTs for that column will return correct value for that field, 
> but inner state of target property {{innerTypeCol}} does not change, and 
> {{AllTypes}} object gets its own odd field {{innerLongCol}} which it does not 
> know how to do with (no metadata about it in type descriptor).
> The patch for both problems is ready and lying on my shelf waiting for 1.8 
> release to happen to be applied. Then this will ultimately be fixed with the 
> rest of known problems/improvements (Jira issues for them will follow).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-4575) Implement in Ignite wrapper for enums based on H2 user value type

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-4575:

Fix Version/s: (was: 1.9)
   2.0

> Implement in Ignite wrapper for enums based on H2 user value type
> -
>
> Key: IGNITE-4575
> URL: https://issues.apache.org/jira/browse/IGNITE-4575
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 2.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (IGNITE-4651) Support CREATE TABLE and DROP TABLE commands

2017-02-03 Thread Vladimir Ozerov (JIRA)
Vladimir Ozerov created IGNITE-4651:
---

 Summary: Support CREATE TABLE and DROP TABLE commands
 Key: IGNITE-4651
 URL: https://issues.apache.org/jira/browse/IGNITE-4651
 Project: Ignite
  Issue Type: Task
  Components: SQL
Reporter: Vladimir Ozerov






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (IGNITE-4652) Optimization: implement BPlusTree.invoke

2017-02-03 Thread Semen Boikov (JIRA)
Semen Boikov created IGNITE-4652:


 Summary: Optimization: implement BPlusTree.invoke
 Key: IGNITE-4652
 URL: https://issues.apache.org/jira/browse/IGNITE-4652
 Project: Ignite
  Issue Type: Task
  Components: cache
Reporter: Semen Boikov
Assignee: Semen Boikov
 Fix For: 2.0






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (IGNITE-4619) .NET: TransactionScope documentation and example

2017-02-03 Thread Pavel Tupitsyn (JIRA)

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

Pavel Tupitsyn commented on IGNITE-4619:


Hidden page created: 
https://apacheignite-net.readme.io/docs/transactionscope-api

> .NET: TransactionScope documentation and example
> 
>
> Key: IGNITE-4619
> URL: https://issues.apache.org/jira/browse/IGNITE-4619
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.9
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 1.9
>
>
> Create documentation and example for {{TransactionScope}} support 
> (IGNITE-3430).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (IGNITE-4619) .NET: TransactionScope documentation and example

2017-02-03 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-4619:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-4619 .NET: TransactionScope example



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

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

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

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


commit 68743dfb62ff0089746c0c4e786fb84bb52b20b1
Author: Pavel Tupitsyn 
Date:   2017-02-03T12:16:58Z

IGNITE-4619 .NET: TransactionScope example

commit 80cc363100704be5be973f8cb11f49c898d2a2cb
Author: Pavel Tupitsyn 
Date:   2017-02-03T12:22:38Z

Add console output




> .NET: TransactionScope documentation and example
> 
>
> Key: IGNITE-4619
> URL: https://issues.apache.org/jira/browse/IGNITE-4619
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.9
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 1.9
>
>
> Create documentation and example for {{TransactionScope}} support 
> (IGNITE-3430).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (IGNITE-4619) .NET: TransactionScope documentation and example

2017-02-03 Thread Pavel Tupitsyn (JIRA)

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

Pavel Tupitsyn commented on IGNITE-4619:


[~dmagda] please have a look at updated example and documentation.

> .NET: TransactionScope documentation and example
> 
>
> Key: IGNITE-4619
> URL: https://issues.apache.org/jira/browse/IGNITE-4619
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.9
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 1.9
>
>
> Create documentation and example for {{TransactionScope}} support 
> (IGNITE-3430).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (IGNITE-4653) Support analytical ROLLUP and CUBE functions

2017-02-03 Thread Vladimir Ozerov (JIRA)
Vladimir Ozerov created IGNITE-4653:
---

 Summary: Support analytical ROLLUP and CUBE functions
 Key: IGNITE-4653
 URL: https://issues.apache.org/jira/browse/IGNITE-4653
 Project: Ignite
  Issue Type: Task
  Components: SQL
Reporter: Vladimir Ozerov






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (IGNITE-4552) Optimize GridDhtLocalPartition.rmvQueue

2017-02-03 Thread Stanilovsky Evgeny (JIRA)

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

Stanilovsky Evgeny reassigned IGNITE-4552:
--

Assignee: Semen Boikov  (was: Stanilovsky Evgeny)

> Optimize GridDhtLocalPartition.rmvQueue
> ---
>
> Key: IGNITE-4552
> URL: https://issues.apache.org/jira/browse/IGNITE-4552
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Semen Boikov
> Fix For: 2.0
>
> Attachments: benchmark-put-remove-simultaneously.properties, 
> Plot_ThroughputLatencyProbe_01_20170203_1.png, 
> Plot_ThroughputLatencyProbe_01_31_origin.png, 
> Plot_ThroughputLatencyProbe_01_4552_mine.png, 
> Plot_ThroughputLatencyProbe_01_mine_3node.png, 
> Plot_ThroughputLatencyProbe_01_mine.png, 
> Plot_ThroughputLatencyProbe_01_origin_3node.png, 
> Plot_ThroughputLatencyProbe_01_origin.png, Screenshot_20170124_155355.png
>
>
> Current implementation stores deferred entry removals in rmvQueue for 
> consistency guaranties.
> This can lead to significant heap over-usage(I observed several Gbs) in case 
> of many caches with removals, because currently queue is cleared lazily after 
> reaching max capacity(200_000 by default).
> This can be mitigated by using lower IGNITE_ATOMIC_CACHE_DELETE_HISTORY_SIZE, 
> but can lead to consistency issues in case of frequent cache updates.
> Possible optimizations:
> * Use single fixed size queue per all caches to overcome limitations of 
> IGNITE_ATOMIC_CACHE_DELETE_HISTORY_SIZE workaround.
> * Do queue cleaning in background
> * Move queue to an off-heap.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (IGNITE-4196) H2 debug console is always started on artificial port

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov commented on IGNITE-4196:
-

[~skalashnikov], looks good to me. Will merge in the nearest time.

> H2 debug console is always started on artificial port
> -
>
> Key: IGNITE-4196
> URL: https://issues.apache.org/jira/browse/IGNITE-4196
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Sergey Kalashnikov
> Fix For: 2.0
>
>
> When H2 debug console is started as described in [1], it always binds to an 
> artificial port. This has at least two issues:
> * Sometimes a client wants to connect through firewall. It's impossible to 
> open all possible ports for the console.
> * If there is no GUI on server node, console can't be opened in a browser, so 
> user has no idea what to do next and how to connect.
> We should:
> * Print out the information about how to connect to the console after it's 
> started.
> * Allow to use a specific port provided as a system property.
> [1] https://apacheignite.readme.io/docs/sql-queries#using-h2-debug-console



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (IGNITE-4650) Scan and SPI queries must go through dedicated query pool

2017-02-03 Thread Vladimir Ozerov (JIRA)
Vladimir Ozerov created IGNITE-4650:
---

 Summary: Scan and SPI queries must go through dedicated query pool
 Key: IGNITE-4650
 URL: https://issues.apache.org/jira/browse/IGNITE-4650
 Project: Ignite
  Issue Type: Task
  Components: cache
Reporter: Vladimir Ozerov
Assignee: Taras Ledkov
 Fix For: 2.0


In IGNITE-4105 we introduced separate thread pool for queries. Currently it is 
used only for {{SQL}} queries. 

Need to make sure that it is also used for {{SCAN}} and {{SPI}} queries.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-4105) Create separate thread pool for SQL queries

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-4105:

Summary: Create separate thread pool for SQL queries  (was: Create separate 
thread pool for SQL queries.)

> Create separate thread pool for SQL queries
> ---
>
> Key: IGNITE-4105
> URL: https://issues.apache.org/jira/browse/IGNITE-4105
> Project: Ignite
>  Issue Type: Task
>  Components: SQL
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Sergey Kalashnikov
>Priority: Critical
> Fix For: 2.0
>
>
> If several long-running queries are executed, all concurrent cache operations 
> will be blocked because there will be no threads in system pool to server 
> cache requests/responses.
> Let's introduce separate thread pool for SQL queries execution.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3013) Support sorted merge index for SQL

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3013:

Labels: SQL  (was: sql)

> Support sorted merge index for SQL
> --
>
> Key: IGNITE-3013
> URL: https://issues.apache.org/jira/browse/IGNITE-3013
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Sergi Vladykin
>Assignee: Sergi Vladykin
>  Labels: SQL
> Fix For: 1.9
>
>
> Currently for sorting we have to fetch all the result sets from remote nodes 
> and sort them on the client side, need to implement sorted merge index which 
> will do it lazily in streaming fashion.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-4524) Indexes usage in SQL functions like min/max

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-4524:

Component/s: SQL

> Indexes usage in SQL functions like min/max
> ---
>
> Key: IGNITE-4524
> URL: https://issues.apache.org/jira/browse/IGNITE-4524
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Reporter: Denis Magda
>Assignee: Sergi Vladykin
> Fix For: 2.0
>
>
> If to execute queries like this
> {code}
> select min(id) from MyValue
> select max(id) from MyValue
> {code}
> assuming that 'id' is an indexed field then the engine will not gain from 
> this. 
> The SQL engine needs to be improved so that the indexes are used for queries 
> like the ones above.
> More details can be found in this discussion:
> http://apache-ignite-developers.2346864.n4.nabble.com/min-max-SQL-and-indexes-td13492.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3870) Keeping SQL query result set in off heap tier

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3870:

Fix Version/s: 2.0

> Keeping SQL query result set in off heap tier
> -
>
> Key: IGNITE-3870
> URL: https://issues.apache.org/jira/browse/IGNITE-3870
> Project: Ignite
>  Issue Type: Task
>  Components: SQL
>Reporter: Denis Magda
>Assignee: Sergi Vladykin
> Fix For: 2.0
>
>
> With the new off heap storage architectures (IGNITE-3477) it makes sense to 
> improve a part of the system that prepares an SQL query result set in a such 
> a way:
> - result set should consist of wrappers objects that incorporate off heap 
> pointers to fields and values stored off heap;
> - during the time the result set is being sent over the wire we shouldn't 
> move fields and values from off heap to Java heap but rather implement a 
> solution that will allow us to pass an off heap pointer to a sockets output 
> stream. Probably this can be done by leveraging Java's DirectBuffers.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3870) Keeping SQL query result set in off heap tier

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3870:

Component/s: SQL

> Keeping SQL query result set in off heap tier
> -
>
> Key: IGNITE-3870
> URL: https://issues.apache.org/jira/browse/IGNITE-3870
> Project: Ignite
>  Issue Type: Task
>  Components: SQL
>Reporter: Denis Magda
>Assignee: Sergi Vladykin
> Fix For: 2.0
>
>
> With the new off heap storage architectures (IGNITE-3477) it makes sense to 
> improve a part of the system that prepares an SQL query result set in a such 
> a way:
> - result set should consist of wrappers objects that incorporate off heap 
> pointers to fields and values stored off heap;
> - during the time the result set is being sent over the wire we shouldn't 
> move fields and values from off heap to Java heap but rather implement a 
> solution that will allow us to pass an off heap pointer to a sockets output 
> stream. Probably this can be done by leveraging Java's DirectBuffers.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Comment Edited] (IGNITE-3625) IGFS: Use common naming for IGFS meta and data caches.

2017-02-03 Thread Taras Ledkov (JIRA)

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

Taras Ledkov edited comment on IGNITE-3625 at 2/3/17 11:52 AM:
---

[~vozerov]], the review issues are fixed.


was (Author: tledkov-gridgain):
The review issues are fixed.

> IGFS: Use common naming for IGFS meta and data caches.
> --
>
> Key: IGNITE-3625
> URL: https://issues.apache.org/jira/browse/IGNITE-3625
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> Currently IGFS is configured by passing names of two caches: meta and data. 
> See {{FileSystemConfiguration.metaCacheName}} and 
> {{FileSystemConfiguration.dataCacheName}}.
> These two caches are considered internal then and are not accessible for the 
> user.
> We need to do the following during node startup:
> 1) If certain cache is configured as meta or data cache for multiple IGFS-es, 
> or if it is configured as both meta and data cache for a single IGFS, then 
> throw an exception.
> Relevant code pieces:
> {{IgfsProcessor.validateLocalIgfsConfigurations}}
> {{IgfsProcessorSelfTest}}.
> 2) During node startup change the name of this cache to 
> {{igfs-IGFS_NAME-meta}} or {{igfs-IGFS_NAME-data}}. Change must be performed 
> both inside IGFS config and cache config.
> Relevant code pieces:
> {{CacheConfiguration.name}}
> {{FileSystemConfiguration.metaCacheName}}
> {{FileSystemConfiguration.dataCacheName}}
> {{IgfsUtils.prepareCacheConfiguration}} - where change will be done.
> 3) If any of new names caches with any other cache name, an exception should 
> be thrown. The most simple way: throw an exception if user-configured cache 
> name starts with {{igfs-}} and ends with {{-meta}} or {{-data}}.
> Relevant code pieces:
> {{IgniteNamedInstance.initializeDefaultCacheConfiguration}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Comment Edited] (IGNITE-3625) IGFS: Use common naming for IGFS meta and data caches.

2017-02-03 Thread Taras Ledkov (JIRA)

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

Taras Ledkov edited comment on IGNITE-3625 at 2/3/17 11:52 AM:
---

[~vozerov], the review issues are fixed.


was (Author: tledkov-gridgain):
[~vozerov]], the review issues are fixed.

> IGFS: Use common naming for IGFS meta and data caches.
> --
>
> Key: IGNITE-3625
> URL: https://issues.apache.org/jira/browse/IGNITE-3625
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> Currently IGFS is configured by passing names of two caches: meta and data. 
> See {{FileSystemConfiguration.metaCacheName}} and 
> {{FileSystemConfiguration.dataCacheName}}.
> These two caches are considered internal then and are not accessible for the 
> user.
> We need to do the following during node startup:
> 1) If certain cache is configured as meta or data cache for multiple IGFS-es, 
> or if it is configured as both meta and data cache for a single IGFS, then 
> throw an exception.
> Relevant code pieces:
> {{IgfsProcessor.validateLocalIgfsConfigurations}}
> {{IgfsProcessorSelfTest}}.
> 2) During node startup change the name of this cache to 
> {{igfs-IGFS_NAME-meta}} or {{igfs-IGFS_NAME-data}}. Change must be performed 
> both inside IGFS config and cache config.
> Relevant code pieces:
> {{CacheConfiguration.name}}
> {{FileSystemConfiguration.metaCacheName}}
> {{FileSystemConfiguration.dataCacheName}}
> {{IgfsUtils.prepareCacheConfiguration}} - where change will be done.
> 3) If any of new names caches with any other cache name, an exception should 
> be thrown. The most simple way: throw an exception if user-configured cache 
> name starts with {{igfs-}} and ends with {{-meta}} or {{-data}}.
> Relevant code pieces:
> {{IgniteNamedInstance.initializeDefaultCacheConfiguration}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-4573) Optimize H2 comparisons w/constant

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-4573:

Fix Version/s: (was: 1.9)
   2.0

> Optimize H2 comparisons w/constant
> --
>
> Key: IGNITE-4573
> URL: https://issues.apache.org/jira/browse/IGNITE-4573
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 2.0
>
>
> Currently H2 performs constant conversions for each row - say, for {{WHERE 
> person.id = '1'}} the {{'1'}} will be converted to {{int}} for each row which 
> is clearly redundant.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-4574) Introduce user value types to H2 w/custom conversion logic

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-4574:

Fix Version/s: (was: 1.9)
   2.0

> Introduce user value types to H2 w/custom conversion logic
> --
>
> Key: IGNITE-4574
> URL: https://issues.apache.org/jira/browse/IGNITE-4574
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 2.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-4510) SQL: co-located query may calculate target partition in advance in some cases

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-4510:

Fix Version/s: (was: 2.0)
   2.1

> SQL: co-located query may calculate target partition in advance in some cases
> -
>
> Key: IGNITE-4510
> URL: https://issues.apache.org/jira/browse/IGNITE-4510
> Project: Ignite
>  Issue Type: Task
>  Components: SQL
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>  Labels: performance, sql
> Fix For: 2.1
>
>
> Consider the following SQL query with {{distributedJoins=false}}:
> {code}
> SELECT ... 
> FROM Employee e
> INNER JOIN Department d on d.id = e.dept_id
> WHERE e.dept_id = ?
> {code}
> If {{dept_id}} is affinity key, and this should be certainly so in case of 
> non-colocated joins (otherwise query will return incorrect result), then we 
> can do the following:
> 1) Determine partition for this affinity key.
> 2) Send query execution request to this partition only.
> Same technique can be applied to {{WHERE e.dept_id IN (?, ...)}} case.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


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

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-4191:

Fix Version/s: (was: 2.1)
   2.2

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



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3171) Support column selectivity calculation for SQL

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3171:

Component/s: SQL

> Support column selectivity calculation for SQL
> --
>
> Key: IGNITE-3171
> URL: https://issues.apache.org/jira/browse/IGNITE-3171
> Project: Ignite
>  Issue Type: Improvement
>  Components: SQL
>Reporter: Sergi Vladykin
> Fix For: 2.1
>
>
> Need to support ANALYZE command. 
> http://h2database.com/html/grammar.html#analyze
> Currently H2 explicitly ignores external table engines (don't see any reasons 
> why). Probably we have to fix H2 by adding method Table.canAnalyze() and use 
> it in that check.
> Also when IGNITE-1232 will be merged we'll need to propagate this statistics 
> to clients.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3171) Support column selectivity calculation for SQL

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3171:

Fix Version/s: 2.1

> Support column selectivity calculation for SQL
> --
>
> Key: IGNITE-3171
> URL: https://issues.apache.org/jira/browse/IGNITE-3171
> Project: Ignite
>  Issue Type: Improvement
>  Components: SQL
>Reporter: Sergi Vladykin
> Fix For: 2.1
>
>
> Need to support ANALYZE command. 
> http://h2database.com/html/grammar.html#analyze
> Currently H2 explicitly ignores external table engines (don't see any reasons 
> why). Probably we have to fix H2 by adding method Table.canAnalyze() and use 
> it in that check.
> Also when IGNITE-1232 will be merged we'll need to propagate this statistics 
> to clients.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-4221) Document ComputeJobMasterLeaveAware interface usage

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-4221:

Fix Version/s: (was: 2.0)
   2.1

> Document ComputeJobMasterLeaveAware interface usage
> ---
>
> Key: IGNITE-4221
> URL: https://issues.apache.org/jira/browse/IGNITE-4221
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
> Fix For: 2.1
>
>
> The usage and applicability of `ComputeJobMasterLeaveAware` have to be 
> documented on Apache Ignite Readme.io which will help out to avoid discussion 
> like that [1]. The new page has to be created for the topic and placed here 
> [2].
> In advance, the following example has to be contributed to Apache Ignite
> https://github.com/gridgain/gridgain-advanced-examples/blob/master/src/main/java/org/gridgain/examples/compute/masterleave/ComputeMasterLeaveAwareExample.java
>  
> [1] 
> http://apache-ignite-users.70518.x6.nabble.com/Remote-Server-Thread-Not-exit-when-Job-finished-Cause-out-of-memory-tp8934p8947.html
> [2] https://apacheignite.readme.io/docs/compute-grid#section-features



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-4222) Document the usage of ComputeJobContinuation API

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-4222:

Fix Version/s: (was: 2.0)
   2.1

> Document the usage of ComputeJobContinuation API
> 
>
> Key: IGNITE-4222
> URL: https://issues.apache.org/jira/browse/IGNITE-4222
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
> Fix For: 2.1
>
>
> The usage and applicability of `ComputeJobContinuation` have to be documented 
> on Apache Ignite Readme.io which will help out to avoid discussion like that 
> [1]. The new page has to be created for the topic and placed here [2].
> The content should consist not only of technical details but also provide use 
> cases for this API:
> - don't block a thread from the public pool if a job is waiting for some 
> result. Put the thread back into the pool and wait for the result 
> asynchronously.
> - splitting a job into several pieces that can be executed in parallel. Refer 
> to this example [3].
>  
> [1] 
> http://apache-ignite-users.70518.x6.nabble.com/Remote-Server-Thread-Not-exit-when-Job-finished-Cause-out-of-memory-tp8934p8947.html
> [2] https://apacheignite.readme.io/docs/compute-grid#section-features
> [3] 
> https://github.com/apache/ignite/blob/master/examples/src/main/java/org/apache/ignite/examples/computegrid/ComputeFibonacciContinuationExample.java



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-4510) SQL: co-located query may calculate target partition in advance in some cases

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-4510:

Fix Version/s: (was: 2.1)

> SQL: co-located query may calculate target partition in advance in some cases
> -
>
> Key: IGNITE-4510
> URL: https://issues.apache.org/jira/browse/IGNITE-4510
> Project: Ignite
>  Issue Type: Task
>  Components: SQL
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>  Labels: performance, sql
>
> Consider the following SQL query with {{distributedJoins=false}}:
> {code}
> SELECT ... 
> FROM Employee e
> INNER JOIN Department d on d.id = e.dept_id
> WHERE e.dept_id = ?
> {code}
> If {{dept_id}} is affinity key, and this should be certainly so in case of 
> non-colocated joins (otherwise query will return incorrect result), then we 
> can do the following:
> 1) Determine partition for this affinity key.
> 2) Send query execution request to this partition only.
> Same technique can be applied to {{WHERE e.dept_id IN (?, ...)}} case.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3171) Support column selectivity calculation for SQL

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3171:

Fix Version/s: (was: 2.1)

> Support column selectivity calculation for SQL
> --
>
> Key: IGNITE-3171
> URL: https://issues.apache.org/jira/browse/IGNITE-3171
> Project: Ignite
>  Issue Type: Improvement
>  Components: SQL
>Reporter: Sergi Vladykin
>
> Need to support ANALYZE command. 
> http://h2database.com/html/grammar.html#analyze
> Currently H2 explicitly ignores external table engines (don't see any reasons 
> why). Probably we have to fix H2 by adding method Table.canAnalyze() and use 
> it in that check.
> Also when IGNITE-1232 will be merged we'll need to propagate this statistics 
> to clients.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


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

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-4191:

Fix Version/s: (was: 2.2)

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



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-4651) Support CREATE TABLE and DROP TABLE commands

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-4651:

Issue Type: New Feature  (was: Task)

> Support CREATE TABLE and DROP TABLE commands
> 
>
> Key: IGNITE-4651
> URL: https://issues.apache.org/jira/browse/IGNITE-4651
> Project: Ignite
>  Issue Type: New Feature
>  Components: SQL
>Reporter: Vladimir Ozerov
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (IGNITE-4654) GridMarshallerPerformanceTest fail

2017-02-03 Thread Stanilovsky Evgeny (JIRA)
Stanilovsky Evgeny created IGNITE-4654:
--

 Summary: GridMarshallerPerformanceTest fail
 Key: IGNITE-4654
 URL: https://issues.apache.org/jira/browse/IGNITE-4654
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.0
Reporter: Stanilovsky Evgeny
Priority: Minor


NPE fail
{code}
[13:46:49,678][INFO ][main][root] >>> Starting test class: 
GridMarshallerPerformanceTest <<<
[13:46:49,688][INFO ][main][root] >>> Starting test: 
GridMarshallerPerformanceTest#testGridMarshaller <<<
[13:46:49,694][ERROR][main][root] Test failed.
class org.apache.ignite.internal.util.lang.GridClosureException: Failed to 
serialize object: 
org.apache.ignite.marshaller.GridMarshallerPerformanceTest$TestObject@d0bb6d5
at 
org.apache.ignite.internal.util.lang.GridFunc.wrap(GridFunc.java:4582)
at 
org.apache.ignite.internal.util.lang.IgniteInClosureX.apply(IgniteInClosureX.java:41)
at 
org.apache.ignite.marshaller.GridMarshallerPerformanceTest.runTest(GridMarshallerPerformanceTest.java:236)
at 
org.apache.ignite.marshaller.GridMarshallerPerformanceTest.testGridMarshaller(GridMarshallerPerformanceTest.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1803)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1718)
at java.lang.Thread.run(Thread.java:745)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to serialize 
object: 
org.apache.ignite.marshaller.GridMarshallerPerformanceTest$TestObject@d0bb6d5
at 
org.apache.ignite.marshaller.optimized.OptimizedMarshaller.marshal0(OptimizedMarshaller.java:197)
at 
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:58)
at 
org.apache.ignite.marshaller.GridMarshallerPerformanceTest$3.applyx(GridMarshallerPerformanceTest.java:122)
at 
org.apache.ignite.marshaller.GridMarshallerPerformanceTest$3.applyx(GridMarshallerPerformanceTest.java:120)
at 
org.apache.ignite.internal.util.lang.IgniteInClosureX.apply(IgniteInClosureX.java:38)
... 11 more
Caused by: java.lang.NullPointerException
{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (IGNITE-3575) CPP: Support continuous queries remote filters.

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov reassigned IGNITE-3575:
---

Assignee: Igor Sapego

> CPP: Support continuous queries remote filters.
> ---
>
> Key: IGNITE-3575
> URL: https://issues.apache.org/jira/browse/IGNITE-3575
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (IGNITE-4654) GridMarshallerPerformanceTest fail

2017-02-03 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-4654:


GitHub user zstan opened a pull request:

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

IGNITE-4654 GridMarshallerPerformanceTest#testGridMarshaller fix



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

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

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

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


commit be0ae98ab477ec6b03d4393050f82d518684b5d4
Author: Evgeny Stanilovskiy 
Date:   2017-02-03T13:24:36Z

IGNITE-4654 GridMarshallerPerformanceTest#testGridMarshaller fix




> GridMarshallerPerformanceTest fail
> --
>
> Key: IGNITE-4654
> URL: https://issues.apache.org/jira/browse/IGNITE-4654
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Stanilovsky Evgeny
>Priority: Minor
>
> NPE fail
> {code}
> [13:46:49,678][INFO ][main][root] >>> Starting test class: 
> GridMarshallerPerformanceTest <<<
> [13:46:49,688][INFO ][main][root] >>> Starting test: 
> GridMarshallerPerformanceTest#testGridMarshaller <<<
> [13:46:49,694][ERROR][main][root] Test failed.
> class org.apache.ignite.internal.util.lang.GridClosureException: Failed to 
> serialize object: 
> org.apache.ignite.marshaller.GridMarshallerPerformanceTest$TestObject@d0bb6d5
> at 
> org.apache.ignite.internal.util.lang.GridFunc.wrap(GridFunc.java:4582)
> at 
> org.apache.ignite.internal.util.lang.IgniteInClosureX.apply(IgniteInClosureX.java:41)
> at 
> org.apache.ignite.marshaller.GridMarshallerPerformanceTest.runTest(GridMarshallerPerformanceTest.java:236)
> at 
> org.apache.ignite.marshaller.GridMarshallerPerformanceTest.testGridMarshaller(GridMarshallerPerformanceTest.java:132)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1803)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1718)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to 
> serialize object: 
> org.apache.ignite.marshaller.GridMarshallerPerformanceTest$TestObject@d0bb6d5
> at 
> org.apache.ignite.marshaller.optimized.OptimizedMarshaller.marshal0(OptimizedMarshaller.java:197)
> at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:58)
> at 
> org.apache.ignite.marshaller.GridMarshallerPerformanceTest$3.applyx(GridMarshallerPerformanceTest.java:122)
> at 
> org.apache.ignite.marshaller.GridMarshallerPerformanceTest$3.applyx(GridMarshallerPerformanceTest.java:120)
> at 
> org.apache.ignite.internal.util.lang.IgniteInClosureX.apply(IgniteInClosureX.java:38)
> ... 11 more
> Caused by: java.lang.NullPointerException
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (IGNITE-4654) GridMarshallerPerformanceTest fail

2017-02-03 Thread Stanilovsky Evgeny (JIRA)

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

Stanilovsky Evgeny reassigned IGNITE-4654:
--

Assignee: Semen Boikov

> GridMarshallerPerformanceTest fail
> --
>
> Key: IGNITE-4654
> URL: https://issues.apache.org/jira/browse/IGNITE-4654
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Stanilovsky Evgeny
>Assignee: Semen Boikov
>Priority: Minor
>
> NPE fail
> {code}
> [13:46:49,678][INFO ][main][root] >>> Starting test class: 
> GridMarshallerPerformanceTest <<<
> [13:46:49,688][INFO ][main][root] >>> Starting test: 
> GridMarshallerPerformanceTest#testGridMarshaller <<<
> [13:46:49,694][ERROR][main][root] Test failed.
> class org.apache.ignite.internal.util.lang.GridClosureException: Failed to 
> serialize object: 
> org.apache.ignite.marshaller.GridMarshallerPerformanceTest$TestObject@d0bb6d5
> at 
> org.apache.ignite.internal.util.lang.GridFunc.wrap(GridFunc.java:4582)
> at 
> org.apache.ignite.internal.util.lang.IgniteInClosureX.apply(IgniteInClosureX.java:41)
> at 
> org.apache.ignite.marshaller.GridMarshallerPerformanceTest.runTest(GridMarshallerPerformanceTest.java:236)
> at 
> org.apache.ignite.marshaller.GridMarshallerPerformanceTest.testGridMarshaller(GridMarshallerPerformanceTest.java:132)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1803)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1718)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to 
> serialize object: 
> org.apache.ignite.marshaller.GridMarshallerPerformanceTest$TestObject@d0bb6d5
> at 
> org.apache.ignite.marshaller.optimized.OptimizedMarshaller.marshal0(OptimizedMarshaller.java:197)
> at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:58)
> at 
> org.apache.ignite.marshaller.GridMarshallerPerformanceTest$3.applyx(GridMarshallerPerformanceTest.java:122)
> at 
> org.apache.ignite.marshaller.GridMarshallerPerformanceTest$3.applyx(GridMarshallerPerformanceTest.java:120)
> at 
> org.apache.ignite.internal.util.lang.IgniteInClosureX.apply(IgniteInClosureX.java:38)
> ... 11 more
> Caused by: java.lang.NullPointerException
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (IGNITE-4538) BinaryObjectImpl: lack of context information upon deserialization

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov commented on IGNITE-4538:
-

[~ein], my comments:
1) I accidentally merged your branch with other unrelated branch. I reverted 
changes, but now your PR is based on {{ignite-2.0}}, not on {{master}}. 
2) Please see and review my changes to exception handling in 
{{BinaryClassDescriptor}} and {{BinaryFieldAccessor}}.
3) Changes to {{BinaryUtils}} are invalid:
- "HANDLE" is not a field type and hence should not reside in 
{{FIELD_TYPE_NAMES}}.
- Assertion in {{fieldTypeName}} is incorrect: you may easily receive arbitrary 
flag value in case of broken format, which is nevertheless within array 
boundaries.

4) {{BinaryReaderExImpl}}:
- {{wrapFieldName}} - Invalid JavaDoc format
- {{wrapFieldName}} - why don't you check for {{SENSITIVE}} flag?
- Why do you catch only {{BinaryObjectException}}, but not {{Exception}}?
- You wrap exceptions only for primitives. What about dozens of other field 
types?

> BinaryObjectImpl: lack of context information upon deserialization
> --
>
> Key: IGNITE-4538
> URL: https://issues.apache.org/jira/browse/IGNITE-4538
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary
>Affects Versions: 1.7, 1.8
>Reporter: Alexandr Kuramshin
>Assignee: Vladimir Ozerov
> Fix For: 2.0
>
>
> Taking an error we don't know the cache name was accessed, the type of 
> BinaryClassDescriptor was used, and the entry was accessed (the key of an 
> entry should be logged with respect to the *include sensitive* system 
> property).
> Such context information should be appended by wrapping inner exception on 
> the every key stack frame.
> {noformat}
> org.apache.ignite.binary.BinaryObjectException: Unexpected flag value 
> [pos=24, expected=4, actual=9]
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.checkFlagNoHandles(BinaryReaderExImpl.java:1423)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readLongNullable(BinaryReaderExImpl.java:723)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.readFixedType(BinaryFieldAccessor.java:677)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read(BinaryFieldAccessor.java:639)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:818)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1481)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:717)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:143)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinary(CacheObjectContext.java:272)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:160)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:147)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1706)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$PeekValueExpiryAwareIterator.advance(GridCacheQueryManager.java:2875)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$PeekValueExpiryAwareIterator.(GridCacheQueryManager.java:2814)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$PeekValueExpiryAwareIterator.(GridCacheQueryManager.java:2752)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$5.(GridCacheQueryManager.java:863)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> 

[jira] [Assigned] (IGNITE-4538) BinaryObjectImpl: lack of context information upon deserialization

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov reassigned IGNITE-4538:
---

Assignee: Alexandr Kuramshin  (was: Vladimir Ozerov)

> BinaryObjectImpl: lack of context information upon deserialization
> --
>
> Key: IGNITE-4538
> URL: https://issues.apache.org/jira/browse/IGNITE-4538
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary
>Affects Versions: 1.8, 1.7
>Reporter: Alexandr Kuramshin
>Assignee: Alexandr Kuramshin
> Fix For: 2.0
>
>
> Taking an error we don't know the cache name was accessed, the type of 
> BinaryClassDescriptor was used, and the entry was accessed (the key of an 
> entry should be logged with respect to the *include sensitive* system 
> property).
> Such context information should be appended by wrapping inner exception on 
> the every key stack frame.
> {noformat}
> org.apache.ignite.binary.BinaryObjectException: Unexpected flag value 
> [pos=24, expected=4, actual=9]
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.checkFlagNoHandles(BinaryReaderExImpl.java:1423)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readLongNullable(BinaryReaderExImpl.java:723)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.readFixedType(BinaryFieldAccessor.java:677)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read(BinaryFieldAccessor.java:639)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:818)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1481)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:717)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:143)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinary(CacheObjectContext.java:272)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:160)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:147)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1706)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$PeekValueExpiryAwareIterator.advance(GridCacheQueryManager.java:2875)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$PeekValueExpiryAwareIterator.(GridCacheQueryManager.java:2814)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$PeekValueExpiryAwareIterator.(GridCacheQueryManager.java:2752)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$5.(GridCacheQueryManager.java:863)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.scanIterator(GridCacheQueryManager.java:863)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.scanQueryLocal(GridCacheQueryManager.java:1436)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.executeScanQuery(GridCacheQueryAdapter.java:552)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.igniteIterator(GridCacheAdapter.java:4115)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.igniteIterator(GridCacheAdapter.java:4092)
>  ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
>

[jira] [Updated] (IGNITE-3658) Move all failing and flaky tests to separate test suite.

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3658:

Labels:   (was: roadmap)

> Move all failing and flaky tests to separate test suite.
> 
>
> Key: IGNITE-3658
> URL: https://issues.apache.org/jira/browse/IGNITE-3658
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Minor
> Fix For: 2.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3556) IGFS: Support external changes to the secondary file system.

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3556:

Labels:   (was: roadmap)

> IGFS: Support external changes to the secondary file system.
> 
>
> Key: IGNITE-3556
> URL: https://issues.apache.org/jira/browse/IGNITE-3556
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Priority: Minor
> Fix For: 2.0
>
>
> Currently if secondary file system is changed from the outside, IGFS will 
> stop working. We need to support ability to survive external change. It means 
> that we must very carefully review every single file system operation and see 
> how it should behave in this scenario.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-2977) .NET: Implement generic ability to invoke Java code from non-Java platforms

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-2977:

Labels: .net  (was: .net roadmap)

> .NET: Implement generic ability to invoke Java code from non-Java platforms
> ---
>
> Key: IGNITE-2977
> URL: https://issues.apache.org/jira/browse/IGNITE-2977
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>  Labels: .net
>
> *Problem*
> Sometimes user could have mixed cluster when some nodes are running Java and 
> some nodes running in platform mode. Obviously, in such deployments it is 
> impossible to invoke non-Java code on Java nodes.
> It appears to be a serious limitation for users. For example, if cache nodes 
> are Java-only, it is impossible to set remote filter from .NET.
> Known problematic places:
> - Remote filter in continuous query
> - Compute API
> - Scan Queries
> - Cache.invokes
> - "load cache" with non-null predicate
> - services
> - messaging remote listener
> - events remote query
> *Proposed solution*
> 1) Define two new types:
> {{JavaObject}} - encoded Java object; identified by a fully-qualified class 
> name and a map of properties.
> {{JavaObjectFactory}} - factory object for more complex cases when some 
> additional logic on Java side is required. Factory must support injections.
> 2) Implement corresponding wrappers in .NET and ensure they are unwrapped 
> correctly.
> 3) Support individual features from the list above.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3508) .NET: Make ICache implement IDictionary

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3508:

Labels: .net breaking-api  (was: .net breaking-api roadmap)

> .NET: Make ICache implement IDictionary
> ---
>
> Key: IGNITE-3508
> URL: https://issues.apache.org/jira/browse/IGNITE-3508
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>  Labels: .net, breaking-api
> Fix For: 2.0
>
>
> ICache is essentially a dictionary. Implementing IDictionary will 
> provide a familiar interface to the users.
> However, this may require us to remove ICacheEntry interface and switch to 
> KeyValuePair, since this is what IDictionary operates on. KeyValuePair is 
> also a struct, so this may improve performance in certain cases.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3571) CPP: Improve Cache API.

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3571:

Labels: cpp  (was: cpp roadmap)

> CPP: Improve Cache API.
> ---
>
> Key: IGNITE-3571
> URL: https://issues.apache.org/jira/browse/IGNITE-3571
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>  Labels: cpp
>
> This is umbrella ticket to manage ongoing C++ cache API efforts.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3555) IGFS: Expose IGFS as POSIX file system to OS.

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3555:

Labels:   (was: roadmap)

> IGFS: Expose IGFS as POSIX file system to OS.
> -
>
> Key: IGNITE-3555
> URL: https://issues.apache.org/jira/browse/IGNITE-3555
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> This way users will be able to mount IGFS and work with it as with any other 
> file system.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3567) .NET: AppFabric integration

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3567:

Labels: .net  (was: .net roadmap)

> .NET: AppFabric integration
> ---
>
> Key: IGNITE-3567
> URL: https://issues.apache.org/jira/browse/IGNITE-3567
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>  Labels: .net
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3536) IGFS: Implement async methods for all base file system operations.

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3536:

Labels:   (was: roadmap)

> IGFS: Implement async methods for all base file system operations.
> --
>
> Key: IGNITE-3536
> URL: https://issues.apache.org/jira/browse/IGNITE-3536
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> 1) Remove {{IgniteAsyncSupport}} interface
> 2) Implement async counterparts for all FS operations.
> Justification: some structure file system operations might be very 
> time-consuming, so having async counterparts sounds like a good idea.
> The questions is what thread pool will host these tasks.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3111) .NET: Configure SSL without Spring

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3111:

Labels: .net  (was: .net roadmap)

> .NET: Configure SSL without Spring
> --
>
> Key: IGNITE-3111
> URL: https://issues.apache.org/jira/browse/IGNITE-3111
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>  Labels: .net
> Fix For: 2.0
>
>
> User should be able to configure SLL in .NET terms without Spring and Java 
> KeyStore.
> See https://apacheignite.readme.io/docs/ssltls.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3550) IGFS: Improve usability for Apache Ignite 2.0.

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3550:

Labels:   (was: roadmap)

> IGFS: Improve usability for Apache Ignite 2.0.
> --
>
> Key: IGNITE-3550
> URL: https://issues.apache.org/jira/browse/IGNITE-3550
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> This is an umbrella ticket to host all IGFS usability improvements targeted 
> for Apache Ignite 2.0.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-2658) .NET: NHibernate Second Level Cache

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-2658:

Labels: .net  (was: .net roadmap)

> .NET: NHibernate Second Level Cache
> ---
>
> Key: IGNITE-2658
> URL: https://issues.apache.org/jira/browse/IGNITE-2658
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>  Labels: .net
> Fix For: 2.0
>
>
> http://nhibernate.info/blog/2009/02/09/quickly-setting-up-and-using-nhibernate-s-second-level-cache.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3546) IGFS: Review events subsystem.

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3546:

Labels:   (was: roadmap)

> IGFS: Review events subsystem.
> --
>
> Key: IGNITE-3546
> URL: https://issues.apache.org/jira/browse/IGNITE-3546
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> Currently we have different event types for various file system operations. 
> But we do not fire them always. E.g. if the path {{/a}} is removed, then we 
> will fire only one event. We will not fire events for {{/a/b}}.
> Is it fine or not? Do we need these events at all or not? May be we want to 
> configure event handling somehow? May be users would like to listen such 
> events? Need to think about it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3574) CPP: Implement compute API

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3574:

Labels: cpp  (was: cpp roadmap)

> CPP: Implement compute API
> --
>
> Key: IGNITE-3574
> URL: https://issues.apache.org/jira/browse/IGNITE-3574
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>  Labels: cpp
>
> Umbrella ticket to host all compute API tickets.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3554) IGFS: Support cross-mode operations.

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3554:

Labels:   (was: roadmap)

> IGFS: Support cross-mode operations.
> 
>
> Key: IGNITE-3554
> URL: https://issues.apache.org/jira/browse/IGNITE-3554
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> We need to support operations when certain files/diretories are moved between 
> modes. This affects operations where two directories are involved, or several 
> paths are affected:
> 1) create/append
> 2) mkdirs
> 3) rename
> 4) delete



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3365) .NET: User-defined affinity mapper

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3365:

Labels: .net  (was: .net roadmap)

> .NET: User-defined affinity mapper
> --
>
> Key: IGNITE-3365
> URL: https://issues.apache.org/jira/browse/IGNITE-3365
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>  Labels: .net
> Fix For: 2.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3557) Hadoop: integrate with Ambary management console.

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3557:

Labels:   (was: roadmap)

> Hadoop: integrate with Ambary management console.
> -
>
> Key: IGNITE-3557
> URL: https://issues.apache.org/jira/browse/IGNITE-3557
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> This will greatly simplify IGFS cluster management.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3566) .NET: Memcached integration

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3566:

Labels: .net  (was: .net roadmap)

> .NET: Memcached integration
> ---
>
> Key: IGNITE-3566
> URL: https://issues.apache.org/jira/browse/IGNITE-3566
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>  Labels: .net
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3572) CPP: Improve binary marshaller capabilities.

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3572:

Labels: cpp  (was: cpp roadmap)

> CPP: Improve binary marshaller capabilities.
> 
>
> Key: IGNITE-3572
> URL: https://issues.apache.org/jira/browse/IGNITE-3572
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>  Labels: cpp
>
> This is umbrella ticket to host all binary marshaller tickets.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-2940) .NET: Plugin system

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-2940:

Labels: .net  (was: .net roadmap)

> .NET: Plugin system
> ---
>
> Key: IGNITE-2940
> URL: https://issues.apache.org/jira/browse/IGNITE-2940
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .net
> Fix For: 2.0
>
>
> Implement a plugin system to allow extending Ignite functionality by third 
> parties.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Closed] (IGNITE-3571) CPP: Improve Cache API.

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov closed IGNITE-3571.
---

> CPP: Improve Cache API.
> ---
>
> Key: IGNITE-3571
> URL: https://issues.apache.org/jira/browse/IGNITE-3571
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>  Labels: cpp
>
> This is umbrella ticket to manage ongoing C++ cache API efforts.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3717) .NET: GridSecurityProcessor support

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3717:

Labels: .net  (was: .net roadmap)

> .NET: GridSecurityProcessor support
> ---
>
> Key: IGNITE-3717
> URL: https://issues.apache.org/jira/browse/IGNITE-3717
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Reporter: Pavel Tupitsyn
>  Labels: .net
> Fix For: 2.0
>
>
> Provide a way to secure .NET cluster natively. See GridSecurityProcessor in 
> Java, and the blog post: 
> http://smartkey.co.uk/development/securing-an-apache-ignite-cluster/



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-4427) .NET: Compute Checkpointing

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-4427:

Labels: .NET  (was: .NET roadmap)

> .NET: Compute Checkpointing
> ---
>
> Key: IGNITE-4427
> URL: https://issues.apache.org/jira/browse/IGNITE-4427
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Reporter: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.1
>
>
> Implement compute checkpointing:
> https://apacheignite.readme.io/docs/checkpointing



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-4006) Hadoop: integrate with ResourceManager.

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-4006:

Labels:   (was: roadmap)

> Hadoop: integrate with ResourceManager.
> ---
>
> Key: IGNITE-4006
> URL: https://issues.apache.org/jira/browse/IGNITE-4006
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> When jobs are executed through Hadoop, users may find useful historical info 
> (such as logs) in Resource Manager. This doesn't work for Ignite.
> Looks like we need to investigate how to integrate w/ native Resource Manager.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3576) .NET: Implement distributed data structures

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3576:

Labels: .net  (was: .net roadmap)

> .NET: Implement distributed data structures
> ---
>
> Key: IGNITE-3576
> URL: https://issues.apache.org/jira/browse/IGNITE-3576
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>  Labels: .net
>
> Umbrella ticket to host data structures efforts.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Resolved] (IGNITE-3571) CPP: Improve Cache API.

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

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

All children tickets were converted to top-level tasks.

> CPP: Improve Cache API.
> ---
>
> Key: IGNITE-3571
> URL: https://issues.apache.org/jira/browse/IGNITE-3571
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>  Labels: cpp
>
> This is umbrella ticket to manage ongoing C++ cache API efforts.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (IGNITE-2216) Duplicate field names with aliases do not work in queries.

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov reassigned IGNITE-2216:
---

Assignee: Sergey Kalashnikov  (was: Vladimir Ozerov)

> Duplicate field names with aliases do not work in queries.
> --
>
> Key: IGNITE-2216
> URL: https://issues.apache.org/jira/browse/IGNITE-2216
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, SQL
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Sergey Kalashnikov
> Fix For: 1.9
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (IGNITE-3939) Compact long zero values binary representation

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov reassigned IGNITE-3939:
---

Assignee: Andrew Mashenkov  (was: Vladimir Ozerov)

> Compact long zero values binary representation
> --
>
> Key: IGNITE-3939
> URL: https://issues.apache.org/jira/browse/IGNITE-3939
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary
>Affects Versions: 1.7
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
> Fix For: 2.0
>
>
> We can use separate type for Long zero values and exclude 8-byte value from 
> binary representation. This will reduce memory footprint and network load.
> Compatibility with previous versions MUST be preserved.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (IGNITE-4490) Optimize DML for fast INSERT and MERGE

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov reassigned IGNITE-4490:
---

Assignee: Alexander Paschenko  (was: Vladimir Ozerov)

> Optimize DML for fast INSERT and MERGE
> --
>
> Key: IGNITE-4490
> URL: https://issues.apache.org/jira/browse/IGNITE-4490
> Project: Ignite
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 2.0
>
>
> It's possible to avoid any SQL querying and map some INSERT and MERGE 
> statements to cache operations in a way similar to that of UPDATE and DELETE 
> - i.e. don't make queries when there are no expressions to evaluate in the 
> query and enhance update plans to perform direct cache operations when INSERT 
> and MERGE affect columns {{_key}} and {{_val}} only.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (IGNITE-1495) Cache SQL query metadata index's fields have wrong register.

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov reassigned IGNITE-1495:
---

Assignee: Sergey Kalashnikov  (was: Vladimir Ozerov)

> Cache SQL query metadata index's fields have wrong register.
> 
>
> Key: IGNITE-1495
> URL: https://issues.apache.org/jira/browse/IGNITE-1495
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 1.5.0.final
>Reporter: Vasiliy Sisko
>Assignee: Sergey Kalashnikov
> Fix For: 1.9
>
> Attachments: #_IGNITE-1495_Test_for_index_s_fields.patch
>
>
> Index's fields should have register how in table fields (In upper case).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-3167) Hadoop: restore external execution.

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3167:

Labels:   (was: roadmap)

> Hadoop: restore external execution.
> ---
>
> Key: IGNITE-3167
> URL: https://issues.apache.org/jira/browse/IGNITE-3167
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Priority: Critical
> Fix For: 2.0
>
>
> Some time ago we decided to get rid external execution mode. It appears to be 
> a wrong decision.
> Hadoop users rely on its process-per-job nature in lot's places. One of such 
> case could be observed in HiBench Bayes benchmark:
> 1) Job creates something in the local file system through Hadoop FileSystem 
> API.
> 2) Then it tries to get this data using regular java.io.FileReader and 
> relative paths. 
> This doesn't work in embedded mode because our LocalFileSystem wrapper 
> assigns different work dirs for jobs, but process-wide working directory is 
> always the same. As a result, aforementioned benchmark doesn't work in 
> Ignite, but work with standard Hadoop job tracker.
> It seems that we must return external execution back.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-1441) CPP: Support filter in SCAN queries.

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-1441:

Labels: cpp  (was: cpp roadmap)

> CPP: Support filter in SCAN queries.
> 
>
> Key: IGNITE-1441
> URL: https://issues.apache.org/jira/browse/IGNITE-1441
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>  Labels: cpp
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (IGNITE-1439) CPP: Implement futures.

2017-02-03 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-1439:

Labels: cpp  (was: cpp roadmap)

> CPP: Implement futures.
> ---
>
> Key: IGNITE-1439
> URL: https://issues.apache.org/jira/browse/IGNITE-1439
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>  Labels: cpp
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


  1   2   >