[jira] [Commented] (IGNITE-6022) SQL: add native batch execution support for DML statements

[Roman Kondakov (JIRA)]

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

Roman Kondakov commented on IGNITE-6022:


[~vozerov], my comments:
1) I agree. I'll add this test.
2) Concerning flushing all batches on duplicates found - I agree it's not 
efficient, I'll change this behavior into flushing only the affected batch. 
Concerning replacing a {{Map cntPerRow}} with an array. I 
think it is not a good idea because we do not know the total size of the rows 
we need to update on {{DmlBatchSender}} creation stage. We have only cursor 
which allows to iterate over these rows. So, we have to manage the array size 
manually and extend it on demand. But it is possible to replace the {{Map}} 
with an {{ArrayList}}. I'm not sure it is much more efficient and easier to 
implement than a map, but I agree that if we have a range of integer keys from 
{{0}} to {{N}} it better to use array-like structures than map. I'll replace 
map with an {{ArrayList}}.
3) I'll remove this method.
4) I agree. I'll add tests with various scenarios in {{JdbcThinBatchSelfTest}}. 
Or should I add these tests not only for thin driver, but also for all Ignite 
JDBC driver types?

> SQL: add native batch execution support for DML statements
> --
>
> Key: IGNITE-6022
> URL: https://issues.apache.org/jira/browse/IGNITE-6022
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
>  Labels: iep-1, performance
> Fix For: 2.4
>
>
> We have batch execution support for JDBC and ODBC drivers. This decreases 
> number of network hops. However, we do not have any batch execution support 
> on the server side. It means that for batch of N similar statements, every 
> statement will go through the whole execution chain - parsing, splitting, 
> communication with servers. And while parsing and splitting might be avoided 
> with help of statement cache, the most heavy part - network communication - 
> is still there.
> We need to investigate how to optimize the flow for batch updates. Possible 
> improvements:
> 1) Execute statements with certain degree of parallelism;
> 2) Send several query execution requests to the server at once;
> 3) Ensure that caches are used properly for batching - we should not parse 
> the same request multiple times.



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

[jira] [Commented] (IGNITE-7323) Update Storm dependencies to 1.1.1

[Roman Shtykh (JIRA)]

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

Roman Shtykh commented on IGNITE-7323:
--

Looks like it's built with Java8 but run with Java7 in TC
{{teamcity.agent.jvm.java.home   /usr/lib/jvm/java-8-oracle/jre}}
This this failure 
https://ci.ignite.apache.org/viewLog.html?buildId=1022304=buildResultsDiv=IgniteTests_IgniteStreamers

> Update Storm dependencies to 1.1.1
> --
>
> Key: IGNITE-7323
> URL: https://issues.apache.org/jira/browse/IGNITE-7323
> Project: Ignite
>  Issue Type: Bug
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
> Fix For: 2.4
>
>
> http://storm.apache.org/2017/08/01/storm111-released.html



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

[jira] [Closed] (IGNITE-7259) GridIndexRebuildSelfTest hangs

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-7259.
---

> GridIndexRebuildSelfTest hangs
> --
>
> Key: IGNITE-7259
> URL: https://issues.apache.org/jira/browse/IGNITE-7259
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.5
>
>




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

[jira] [Commented] (IGNITE-3084) Spark Data Frames Support in Apache Ignite

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-3084:
-

{quote}can you please also take a look at DataFrameWriter API? Is it possible 
to allow saving a data frame into Ignite, and how hard would it be to 
implement?{quote}

It seems that we need to support {{InsertableRelation}} and 
{{CreatableRelationProvider}}
I think it will be relatively easy to implement it for Ignite.

> Spark Data Frames Support in Apache Ignite
> --
>
> Key: IGNITE-3084
> URL: https://issues.apache.org/jira/browse/IGNITE-3084
> Project: Ignite
>  Issue Type: Task
>  Components: spark
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Nikolay Izhikov
>Priority: Critical
>  Labels: bigdata, important
> Fix For: 2.4
>
>
> Apache Spark already benefits from integration with Apache Ignite. The latter 
> provides shared RDDs, an implementation of Spark RDD, that help Spark to 
> share a state between Spark workers and execute SQL queries much faster. The 
> next logical step is to enable support for modern Spark Data Frames API in a 
> similar way.
> As a contributor, you will be fully in charge of the integration of Spark 
> Data Frame API and Apache Ignite.



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

[jira] [Commented] (IGNITE-6783) Create common mechanism for group training.

[Oleg Ignatenko (JIRA)]

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

Oleg Ignatenko commented on IGNITE-6783:


{{IgniteMLTestSuite}} passes, including new tests in {{TrainersGroupTestSuite}}

> Create common mechanism for group training.
> ---
>
> Key: IGNITE-6783
> URL: https://issues.apache.org/jira/browse/IGNITE-6783
> Project: Ignite
>  Issue Type: Task
>  Components: ml
>Reporter: Artem Malykh
>Assignee: Artem Malykh
>
> In distributed ML it is a common task to train several models in parallel 
> with ability to communicate with each other during training. Simple example 
> of this case is training of neural network with SGD on different chunks of 
> data located on several nodes. In such training we do the following in a 
> loop: on each node we do one or several SGD steps then send gradient on 
> central node which averages gradients from each of worker nodes and send back 
> the averaged gradient. There is a pattern in this procedure which can be 
> applied to other ML algos and it could be useful to extract this pattern.



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

[jira] [Comment Edited] (IGNITE-3084) Spark Data Frames Support in Apache Ignite

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov edited comment on IGNITE-3084 at 12/28/17 4:46 AM:
---

{quote}
I don't agree on OPTION_GRID. In catalog implementation you already have Ignite 
instance, so I don't see why would you need to get it by name again. There 
should be another solution.
And in general, implementation detail should not drive public API. OPTION_GRID 
is very confusing and I still think it should be removed, at least in this 
iteration.
{quote}

I made {{OPTION_GRID}} private in IgniteExternalCatalog so it not appear in 
public API.
Please, take a look.
Is it OK?

https://github.com/apache/ignite/pull/2742/commits/a68b19abdcee56d4d6e585a08abed560aec84e20

Please, see some details about spark relation resolving:

1. When spark execute SQL query it resolves catalog relation with 
{{FindDataSourceTable}}. Relation resolved with string options provided from 
Catalog:

https://github.com/apache/spark/blob/v2.2.0/sql/core/src/main/scala/org/apache/spark/sql/execution/datasources/DataSourceStrategy.scala#L230

2. DataSource constructs relation throw 
RelationProvider(IgniteRelationProvider) with these string options:

https://github.com/apache/spark/blob/v2.2.0/sql/core/src/main/scala/org/apache/spark/sql/execution/datasources/DataSource.scala#L306

So we have to pass some string ID from a catalog to IgniteRelationProvider to 
get existing Ignite instance.
As far as I can understand - Ignite.name is well for this purpose.
What have I missed?

Another option, that I can see - make some internal HashMap[String, Ignite] and 
use `UUID.randomUUID()` as Ignite identifier.
What do you think?



was (Author: nizhikov):
{quote}
I don't agree on OPTION_GRID. In catalog implementation you already have Ignite 
instance, so I don't see why would you need to get it by name again. There 
should be another solution.
And in general, implementation detail should not drive public API. OPTION_GRID 
is very confusing and I still think it should be removed, at least in this 
iteration.
{quote}

I made {{OPTION_GRID}} private in IgniteExternalCatalog so it not appear in 
public API.
Is it OK?

Please, see some details about spark relation resolving:

1. When spark execute SQL query it resolves catalog relation with 
{{FindDataSourceTable}}. Relation resolved with string options provided from 
Catalog:

https://github.com/apache/spark/blob/v2.2.0/sql/core/src/main/scala/org/apache/spark/sql/execution/datasources/DataSourceStrategy.scala#L230

2. DataSource constructs relation throw 
RelationProvider(IgniteRelationProvider) with these string options:

https://github.com/apache/spark/blob/v2.2.0/sql/core/src/main/scala/org/apache/spark/sql/execution/datasources/DataSource.scala#L306

So we have to pass some string ID from a catalog to IgniteRelationProvider to 
get existing Ignite instance.
As far as I can understand - Ignite.name is well for this purpose.
What have I missed?

Another option, that I can see - make some internal HashMap[String, Ignite] and 
use `UUID.randomUUID()` as Ignite identifier.
What do you think?


> Spark Data Frames Support in Apache Ignite
> --
>
> Key: IGNITE-3084
> URL: https://issues.apache.org/jira/browse/IGNITE-3084
> Project: Ignite
>  Issue Type: Task
>  Components: spark
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Nikolay Izhikov
>Priority: Critical
>  Labels: bigdata, important
> Fix For: 2.4
>
>
> Apache Spark already benefits from integration with Apache Ignite. The latter 
> provides shared RDDs, an implementation of Spark RDD, that help Spark to 
> share a state between Spark workers and execute SQL queries much faster. The 
> next logical step is to enable support for modern Spark Data Frames API in a 
> similar way.
> As a contributor, you will be fully in charge of the integration of Spark 
> Data Frame API and Apache Ignite.



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

[jira] [Commented] (IGNITE-3084) Spark Data Frames Support in Apache Ignite

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-3084:
-

{quote}
I don't agree on OPTION_GRID. In catalog implementation you already have Ignite 
instance, so I don't see why would you need to get it by name again. There 
should be another solution.
And in general, implementation detail should not drive public API. OPTION_GRID 
is very confusing and I still think it should be removed, at least in this 
iteration.
{quote}

I made {{OPTION_GRID}} private in IgniteExternalCatalog so it not appear in 
public API.
Is it OK?

Please, see some details about spark relation resolving:

1. When spark execute SQL query it resolves catalog relation with 
{{FindDataSourceTable}}. Relation resolved with string options provided from 
Catalog:

https://github.com/apache/spark/blob/v2.2.0/sql/core/src/main/scala/org/apache/spark/sql/execution/datasources/DataSourceStrategy.scala#L230

2. DataSource constructs relation throw 
RelationProvider(IgniteRelationProvider) with these string options:

https://github.com/apache/spark/blob/v2.2.0/sql/core/src/main/scala/org/apache/spark/sql/execution/datasources/DataSource.scala#L306

So we have to pass some string ID from a catalog to IgniteRelationProvider to 
get existing Ignite instance.
As far as I can understand - Ignite.name is well for this purpose.
What have I missed?

Another option, that I can see - make some internal HashMap[String, Ignite] and 
use `UUID.randomUUID()` as Ignite identifier.
What do you think?


> Spark Data Frames Support in Apache Ignite
> --
>
> Key: IGNITE-3084
> URL: https://issues.apache.org/jira/browse/IGNITE-3084
> Project: Ignite
>  Issue Type: Task
>  Components: spark
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Nikolay Izhikov
>Priority: Critical
>  Labels: bigdata, important
> Fix For: 2.4
>
>
> Apache Spark already benefits from integration with Apache Ignite. The latter 
> provides shared RDDs, an implementation of Spark RDD, that help Spark to 
> share a state between Spark workers and execute SQL queries much faster. The 
> next logical step is to enable support for modern Spark Data Frames API in a 
> similar way.
> As a contributor, you will be fully in charge of the integration of Spark 
> Data Frame API and Apache Ignite.



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

[jira] [Commented] (IGNITE-7323) Update Storm dependencies to 1.1.1

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7323:


GitHub user shroman opened a pull request:

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

IGNITE-7323: Update Storm dependencies to 1.1.1.



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

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

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

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


commit 47e04536650cd4fd6eeaf5cd4c718f1ba89fac87
Author: shroman 
Date:   2017-12-28T03:52:34Z

IGNITE-7323: Update Storm dependencies to 1.1.1.




> Update Storm dependencies to 1.1.1
> --
>
> Key: IGNITE-7323
> URL: https://issues.apache.org/jira/browse/IGNITE-7323
> Project: Ignite
>  Issue Type: Bug
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> http://storm.apache.org/2017/08/01/storm111-released.html



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

[jira] [Assigned] (IGNITE-7323) Update Storm dependencies to 1.1.1

[Roman Shtykh (JIRA)]

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

Roman Shtykh reassigned IGNITE-7323:


Assignee: Roman Shtykh

> Update Storm dependencies to 1.1.1
> --
>
> Key: IGNITE-7323
> URL: https://issues.apache.org/jira/browse/IGNITE-7323
> Project: Ignite
>  Issue Type: Bug
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> http://storm.apache.org/2017/08/01/storm111-released.html



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

[jira] [Updated] (IGNITE-7323) Update Storm dependencies to 4.2.0

[Roman Shtykh (JIRA)]

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

Roman Shtykh updated IGNITE-7323:
-
Summary: Update Storm dependencies to 4.2.0  (was: Up)

> Update Storm dependencies to 4.2.0
> --
>
> Key: IGNITE-7323
> URL: https://issues.apache.org/jira/browse/IGNITE-7323
> Project: Ignite
>  Issue Type: Bug
>Reporter: Roman Shtykh
>




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

[jira] [Updated] (IGNITE-7323) Update Storm dependencies to 1.1.1

[Roman Shtykh (JIRA)]

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

Roman Shtykh updated IGNITE-7323:
-
Summary: Update Storm dependencies to 1.1.1  (was: Update Storm 
dependencies to 4.2.0)

> Update Storm dependencies to 1.1.1
> --
>
> Key: IGNITE-7323
> URL: https://issues.apache.org/jira/browse/IGNITE-7323
> Project: Ignite
>  Issue Type: Bug
>Reporter: Roman Shtykh
>
> http://storm.apache.org/2017/08/01/storm111-released.html



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

[jira] [Updated] (IGNITE-7323) Update Storm dependencies to 4.2.0

[Roman Shtykh (JIRA)]

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

Roman Shtykh updated IGNITE-7323:
-
Description: http://storm.apache.org/2017/08/01/storm111-released.html

> Update Storm dependencies to 4.2.0
> --
>
> Key: IGNITE-7323
> URL: https://issues.apache.org/jira/browse/IGNITE-7323
> Project: Ignite
>  Issue Type: Bug
>Reporter: Roman Shtykh
>
> http://storm.apache.org/2017/08/01/storm111-released.html



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

[jira] [Created] (IGNITE-7323) Up

[Roman Shtykh (JIRA)]

Roman Shtykh created IGNITE-7323:


 Summary: Up
 Key: IGNITE-7323
 URL: https://issues.apache.org/jira/browse/IGNITE-7323
 Project: Ignite
  Issue Type: Bug
Reporter: Roman Shtykh






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

[jira] [Commented] (IGNITE-7311) Expiration does not work with enabled MVCC

[Roman Shtykh (JIRA)]

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

Roman Shtykh commented on IGNITE-7311:
--

[~vozerov] Can you please give me some idea how it should be honored so that I 
can fix it? Any reference to MVCC implementation would be also helpful.

> Expiration does not work with enabled MVCC
> --
>
> Key: IGNITE-7311
> URL: https://issues.apache.org/jira/browse/IGNITE-7311
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Vladimir Ozerov
> Fix For: 2.5
>
>
> Reproducer: {{RedisProtocolStringSelfTest#testExpire}}
> Root cause: MVCC is not honored when updating entry TTL.
> {code}
> Exception in thread "pub-#101%redis.RedisProtocolStringSelfTest0%" 
> java.lang.AssertionError: Assertion error on search row: SearchRow 
> [key=KeyCacheObjectImpl [part=294, val=k1, hasValBytes=true], hash=3366, 
> cacheId=0]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1749)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1337)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:371)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:3249)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.updateTtl(GridCacheMapEntry.java:2391)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.updateTtl(GridCacheMapEntry.java:3191)
>   at 
> org.apache.ignite.internal.processors.rest.handlers.cache.GridCacheCommandHandler$UpdateTllCommand$1$1.process(GridCacheCommandHandler.java:1685)
>   at 
> org.apache.ignite.internal.processors.rest.handlers.cache.GridCacheCommandHandler$UpdateTllCommand$1$1.process(GridCacheCommandHandler.java:1675)
>   at 
> org.apache.ignite.internal.processors.cache.EntryProcessorResourceInjectorProxy.process(EntryProcessorResourceInjectorProxy.java:68)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onEntriesLocked(GridDhtTxPrepareFuture.java:432)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1271)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:683)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1061)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:395)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:519)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTxLocal(IgniteTxHandler.java:320)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.proceedPrepare(GridNearOptimisticTxPrepareFuture.java:604)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.prepareSingle(GridNearOptimisticTxPrepareFuture.java:410)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.prepare0(GridNearOptimisticTxPrepareFuture.java:341)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFutureAdapter.prepareOnTopology(GridNearOptimisticTxPrepareFutureAdapter.java:158)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFutureAdapter.prepare(GridNearOptimisticTxPrepareFutureAdapter.java:95)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.prepareNearTxLocal(GridNearTxLocal.java:3323)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.commitNearTxLocalAsync(GridNearTxLocal.java:3390)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.optimisticPutFuture(GridNearTxLocal.java:2550)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAsync0(GridNearTxLocal.java:646)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.invokeAsync(GridNearTxLocal.java:431)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$25.op(GridCacheAdapter.java:2481)
>   at 
> 

[jira] [Updated] (IGNITE-7291) Apache Ignite "in use at" section

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-7291:

Description: 
Put together a list of publicly disclosed Apache Ignite use cases and present 
them on the main page right below the benefits. The "Ignite is in use at" 
section might be like Cassandra's "PROVEN" section:
http://cassandra.apache.org

A list of the known use cases:
* 
https://www.imcsummit.org/us/sessions/implementation-investment-book-record-ibor-using-apache-ignitegridgain
* 
https://www.imcsummit.org/us/sessions/high-availability-and-disaster-recovery-imdg
* https://www.imcsummit.org/us/sessions/ignite-compute-grid-in-cloud
* https://youtu.be/1D8hyLWMtfM
* 
https://www.imcsummit.org/us/sessions/how-in-memory-solutions-can-assist-saas-integrations
* https://www.youtube.com/watch?v=RxWLt3x_yBk

In addition, create a dedicated page that will host all the videos in the 
following format:
* Youtube vide rectangle
* Talk title goes below
* Presenter (name and company) goes below
* At the very bottom of the page add the text saying "If you want to add your 
presentation or video to the page send a message at d...@ignite.apache.org"


  was:
Put together a list of publicly disclosed Apache Ignite use cases and present 
them on the main page right below the benefits. The "Ignite is in use at" 
section might be like Cassandra's "PROVEN" section:
http://cassandra.apache.org

A list of the known use cases:
* 
https://www.imcsummit.org/us/sessions/implementation-investment-book-record-ibor-using-apache-ignitegridgain
* 
https://www.imcsummit.org/us/sessions/high-availability-and-disaster-recovery-imdg
* https://www.imcsummit.org/us/sessions/ignite-compute-grid-in-cloud
* https://youtu.be/1D8hyLWMtfM
* 
https://www.imcsummit.org/us/sessions/how-in-memory-solutions-can-assist-saas-integrations
* https://www.youtube.com/watch?v=RxWLt3x_yBk

In addition, create a dedicated page that will host all the videos in the 
following format:
* Yuotube vide rectangle
* Talk title goes below
* Presenter (name and company) goes below



> Apache Ignite "in use at" section
> -
>
> Key: IGNITE-7291
> URL: https://issues.apache.org/jira/browse/IGNITE-7291
> Project: Ignite
>  Issue Type: Task
>  Components: site
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 2.4
>
>
> Put together a list of publicly disclosed Apache Ignite use cases and present 
> them on the main page right below the benefits. The "Ignite is in use at" 
> section might be like Cassandra's "PROVEN" section:
> http://cassandra.apache.org
> A list of the known use cases:
> * 
> https://www.imcsummit.org/us/sessions/implementation-investment-book-record-ibor-using-apache-ignitegridgain
> * 
> https://www.imcsummit.org/us/sessions/high-availability-and-disaster-recovery-imdg
> * https://www.imcsummit.org/us/sessions/ignite-compute-grid-in-cloud
> * https://youtu.be/1D8hyLWMtfM
> * 
> https://www.imcsummit.org/us/sessions/how-in-memory-solutions-can-assist-saas-integrations
> * https://www.youtube.com/watch?v=RxWLt3x_yBk
> In addition, create a dedicated page that will host all the videos in the 
> following format:
> * Youtube vide rectangle
> * Talk title goes below
> * Presenter (name and company) goes below
> * At the very bottom of the page add the text saying "If you want to add your 
> presentation or video to the page send a message at d...@ignite.apache.org"



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

[jira] [Updated] (IGNITE-7291) Apache Ignite "in use at" section

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-7291:

Description: 
Put together a list of publicly disclosed Apache Ignite use cases and present 
them on the main page right below the benefits. The "Ignite is in use at" 
section might be like Cassandra's "PROVEN" section:
http://cassandra.apache.org

A list of the known use cases:
* 
https://www.imcsummit.org/us/sessions/implementation-investment-book-record-ibor-using-apache-ignitegridgain
* 
https://www.imcsummit.org/us/sessions/high-availability-and-disaster-recovery-imdg
* https://www.imcsummit.org/us/sessions/ignite-compute-grid-in-cloud
* https://youtu.be/1D8hyLWMtfM
* 
https://www.imcsummit.org/us/sessions/how-in-memory-solutions-can-assist-saas-integrations
* https://www.youtube.com/watch?v=RxWLt3x_yBk

In addition, create a dedicated page that will host all the videos in the 
following format:
* Yuotube vide rectangle
* Talk title goes below
* Presenter (name and company) goes below


  was:
Put together a list of publicly disclosed Apache Ignite use cases and present 
them on the main page right below the benefits. The "Ignite is in use at" 
section might be like Cassandra's "PROVEN" section:
http://cassandra.apache.org

A list of the known use cases:
* 
https://www.imcsummit.org/us/sessions/implementation-investment-book-record-ibor-using-apache-ignitegridgain
* 
https://www.imcsummit.org/us/sessions/high-availability-and-disaster-recovery-imdg
* https://www.imcsummit.org/us/sessions/ignite-compute-grid-in-cloud
* https://youtu.be/1D8hyLWMtfM
* 
https://www.imcsummit.org/us/sessions/how-in-memory-solutions-can-assist-saas-integrations
* https://www.youtube.com/watch?v=RxWLt3x_yBk


> Apache Ignite "in use at" section
> -
>
> Key: IGNITE-7291
> URL: https://issues.apache.org/jira/browse/IGNITE-7291
> Project: Ignite
>  Issue Type: Task
>  Components: site
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 2.4
>
>
> Put together a list of publicly disclosed Apache Ignite use cases and present 
> them on the main page right below the benefits. The "Ignite is in use at" 
> section might be like Cassandra's "PROVEN" section:
> http://cassandra.apache.org
> A list of the known use cases:
> * 
> https://www.imcsummit.org/us/sessions/implementation-investment-book-record-ibor-using-apache-ignitegridgain
> * 
> https://www.imcsummit.org/us/sessions/high-availability-and-disaster-recovery-imdg
> * https://www.imcsummit.org/us/sessions/ignite-compute-grid-in-cloud
> * https://youtu.be/1D8hyLWMtfM
> * 
> https://www.imcsummit.org/us/sessions/how-in-memory-solutions-can-assist-saas-integrations
> * https://www.youtube.com/watch?v=RxWLt3x_yBk
> In addition, create a dedicated page that will host all the videos in the 
> following format:
> * Yuotube vide rectangle
> * Talk title goes below
> * Presenter (name and company) goes below



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

[jira] [Commented] (IGNITE-7304) Node discovery through AWS ELB

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-7304:
-

[~bbarin],

Please consider a couple of review notes:
* Instead of passing these parameters {{AWSCredentialsProvider 
awsCredentialsProvider, String loadBalancerName, String region, int port}} into 
the constructor, create a separate setter method for each leaving constructor's 
parameters list empty. Every setter method needs to have a documentation on 
what the parameter is for. Refer to other IP finders to see how it's done.
* Add a documentation to the class level (before {{class 
TcpDiscoveryElbIpFinder}}) sharing more info about the IP finder. You can refer 
to other IP finders as to an example.
* How can we test this IP finder? If it requires us to host something on Amazon 
then I would do a simple test checking that methods don't fail with some 
unknown reason like it's done for {{TcpDiscoveryKubernetesIpFinderSelfTest}}.

> Node discovery through AWS ELB
> --
>
> Key: IGNITE-7304
> URL: https://issues.apache.org/jira/browse/IGNITE-7304
> Project: Ignite
>  Issue Type: New Feature
>  Components: aws
>Affects Versions: 2.3
>Reporter: Bruno Barin
>
> Would be nice to have AWS ELB node discovery out of the box with Ignite.
> I've already have developed code to perform this and is working well in 
> production if you agree, i can PR my solution



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

[jira] [Commented] (IGNITE-3084) Spark Data Frames Support in Apache Ignite

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-3084:
-

[~NIzhikov], can you please also take a look at {{DataFrameWriter}} API? Is it 
possible to allow saving a data frame into Ignite, and how hard would it be to 
implement?

> Spark Data Frames Support in Apache Ignite
> --
>
> Key: IGNITE-3084
> URL: https://issues.apache.org/jira/browse/IGNITE-3084
> Project: Ignite
>  Issue Type: Task
>  Components: spark
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Nikolay Izhikov
>Priority: Critical
>  Labels: bigdata, important
> Fix For: 2.4
>
>
> Apache Spark already benefits from integration with Apache Ignite. The latter 
> provides shared RDDs, an implementation of Spark RDD, that help Spark to 
> share a state between Spark workers and execute SQL queries much faster. The 
> next logical step is to enable support for modern Spark Data Frames API in a 
> similar way.
> As a contributor, you will be fully in charge of the integration of Spark 
> Data Frame API and Apache Ignite.



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

[jira] [Commented] (IGNITE-3084) Spark Data Frames Support in Apache Ignite

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-3084:
-

[~NIzhikov], I don't agree on {{OPTION_GRID}}. In catalog implementation you 
already have Ignite instance, so I don't see why would you need to get it by 
name again. There should be another solution.

And in general, implementation detail should not drive public API. 
{{OPTION_GRID}} is very confusing and I still think it should be removed, at 
least in this iteration.

> Spark Data Frames Support in Apache Ignite
> --
>
> Key: IGNITE-3084
> URL: https://issues.apache.org/jira/browse/IGNITE-3084
> Project: Ignite
>  Issue Type: Task
>  Components: spark
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Nikolay Izhikov
>Priority: Critical
>  Labels: bigdata, important
> Fix For: 2.4
>
>
> Apache Spark already benefits from integration with Apache Ignite. The latter 
> provides shared RDDs, an implementation of Spark RDD, that help Spark to 
> share a state between Spark workers and execute SQL queries much faster. The 
> next logical step is to enable support for modern Spark Data Frames API in a 
> similar way.
> As a contributor, you will be fully in charge of the integration of Spark 
> Data Frame API and Apache Ignite.



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

[jira] [Commented] (IGNITE-6022) SQL: add native batch execution support for DML statements

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-6022:
-

[~rkondakov], my comments:
1) {{DmlStatementsProcessor.processDmlSelectResultBatched}} - we should never 
reach this method in case of MERGE. Please make sure we have tests for this.
2) {{DmlBatchSender}} - could you please explain the meaning of these changes? 
I think we do not need any maps or so - array should be enough. Also, it is not 
efficient to flush *all* batches if duplicate in *one* of them is found. 
3) {{DmlBatchSender.perRowUpdateCounter}} - unused method
4) We need to extend test coverage for batched operations - use different types 
(INSERT, UPDATE, MERGE, DELETE), add multiple operations in a batch, simulate 
errors in the middle of the batch and make sure returned results conform to 
JDBC specification.

> SQL: add native batch execution support for DML statements
> --
>
> Key: IGNITE-6022
> URL: https://issues.apache.org/jira/browse/IGNITE-6022
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
>  Labels: iep-1, performance
> Fix For: 2.4
>
>
> We have batch execution support for JDBC and ODBC drivers. This decreases 
> number of network hops. However, we do not have any batch execution support 
> on the server side. It means that for batch of N similar statements, every 
> statement will go through the whole execution chain - parsing, splitting, 
> communication with servers. And while parsing and splitting might be avoided 
> with help of statement cache, the most heavy part - network communication - 
> is still there.
> We need to investigate how to optimize the flow for batch updates. Possible 
> improvements:
> 1) Execute statements with certain degree of parallelism;
> 2) Send several query execution requests to the server at once;
> 3) Ensure that caches are used properly for batching - we should not parse 
> the same request multiple times.



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

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

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko commented on IGNITE-5571:
-

[~vozerov]
All done.

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



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

[jira] [Created] (IGNITE-7322) Distributed MLP training

[Artem Malykh (JIRA)]

Artem Malykh created IGNITE-7322:


 Summary: Distributed MLP training
 Key: IGNITE-7322
 URL: https://issues.apache.org/jira/browse/IGNITE-7322
 Project: Ignite
  Issue Type: Sub-task
Affects Versions: 2.4
Reporter: Artem Malykh
Assignee: Artem Malykh






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

[jira] [Commented] (IGNITE-7259) GridIndexRebuildSelfTest hangs

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7259:


GitHub user alexpaschenko opened a pull request:

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

IGNITE-7259



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

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

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

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


commit f6e982540e65ab17d439dba990794f35616a30dd
Author: sboikov 
Date:   2017-08-30T09:45:40Z

ignite-3478

commit 275a85db5cd6923b36126166ae99b15e876192be
Author: sboikov 
Date:   2017-08-31T07:44:07Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

commit b7b9089f0102b8cab9942a9c887d93e9f26cc7d2
Author: sboikov 
Date:   2017-08-31T09:00:36Z

disco cache cleanup

commit 855c2d45794c300d41e386b4e6fa40736cc3e40d
Author: sboikov 
Date:   2017-08-31T09:09:58Z

Merge branch 'ignite-3478-1' into ignite-3478

commit 08be7310a93d3ce455215b97cf8ab1a2c3f0ab31
Author: sboikov 
Date:   2017-08-31T09:52:23Z

ignite-3478

commit fce2e31f0fd2f4f6a9944422e40408a0c65cfe90
Author: sboikov 
Date:   2017-09-04T08:13:50Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

commit d3c049952384750c5543a9f88b383c033ef74096
Author: sboikov 
Date:   2017-09-04T08:52:11Z

ignite-3478

commit e71ce1937a18dd32448e92b1038dc48d4cb6f8ab
Author: sboikov 
Date:   2017-09-04T10:16:03Z

ignite-3478

commit 5fac5b0965e97f8951e16e10ca9229a2e78ddb0c
Author: sboikov 
Date:   2017-09-05T10:16:44Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

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

commit 2e0c9c08e046e8d6af1b5358d9053eae999b1fb4
Author: sboikov 
Date:   2017-09-05T11:30:55Z

ignite-3478

commit e1e07ffdf2d711ba3e72f316f5a3970eff27372e
Author: sboikov 
Date:   2017-09-05T11:31:14Z

ignite-3478

commit cbada3934a386668da0b11d4de7d0f58a4d04dfe
Author: sboikov 
Date:   2017-09-05T11:49:49Z

ignite-3484

commit 5a82c68dcd1927bb6fded8b7def38c91ff6e145b
Author: sboikov 
Date:   2017-09-05T11:59:49Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

commit bc9134c94b7a738dc1664e96ca6eabb059f1c268
Author: sboikov 
Date:   2017-09-05T12:03:39Z

Merge branch 'ignite-3478' into ignite-3484

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

commit b4bfcde78825c6517232e49d389bdb5de19f05a9
Author: sboikov 
Date:   2017-09-05T12:27:51Z

ignite-3484

commit 43834aaab9e2c3cd5fdd55289fdc4a9ff8ab6599
Author: sboikov 
Date:   2017-09-05T13:13:00Z

ignite-3478

commit d1b828095713fcadfa260cf94fef01b42a1b12fd
Author: sboikov 
Date:   2017-09-05T13:13:33Z

Merge branch 'ignite-3478' into ignite-3484

commit 6be6779b6336c36cd71eef0a25199a6a877ce6b5
Author: sboikov 
Date:   2017-09-05T13:47:11Z

ignite-3484

commit e3bba83256c1eb53c4b40fbd9ddba47fcf9d58d5
Author: sboikov 
Date:   2017-09-06T07:10:26Z

ignite-3484

commit dd0afb28466094b801506da8afa3601bfaebd853
Author: sboikov 
Date:   2017-09-06T07:30:04Z

ignite-3484

commit 27b87b413348b03986a463551db24b7726321732
Author: sboikov 
Date:   2017-09-06T08:19:18Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

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

commit dcaf8801accd6ee089849a82b2ccd558aec81895
Author: sboikov 
Date:   2017-09-06T08:19:30Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

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

commit c966451d0bf7059575de92bcfae43d72096ebce4
Author: sboikov 
Date:   2017-09-06T08:27:04Z

Merge branch 'ignite-3478' into ignite-3484

commit 91b9911731a387a3199ddbbc22704bc14af09995
Author: sboikov 
Date:   2017-09-06T09:22:22Z

ignite-3484

commit e40b4d9dcd6fe6c1cd2640bdd7116ca5a08ed781
Author: sboikov 
Date:   2017-09-07T09:12:32Z

ignite-3484

commit 

[jira] [Assigned] (IGNITE-7205) DataSet API

[Aleksey Zinoviev (JIRA)]

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

Aleksey Zinoviev reassigned IGNITE-7205:


Assignee: Aleksey Zinoviev  (was: Yury Babak)

> DataSet API
> ---
>
> Key: IGNITE-7205
> URL: https://issues.apache.org/jira/browse/IGNITE-7205
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Reporter: Yury Babak
>Assignee: Aleksey Zinoviev
>
> We want to create and implement API for Dataset.
> This should include Dataset, Labeled Dataset, dataset 
> preprocessors(normalizer, filter, mapper, etc...) 



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

[jira] [Commented] (IGNITE-7205) DataSet API

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7205:


GitHub user zaleslaw opened a pull request:

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

IGNITE-7205: Dataset API

1.  Changed Labeled Dataset
2.  Added Dataset and DatasetRow classes
3.  Moved a few methods to Normalizer and LabeledDatasetLoader
4.  Changed examples and tests
5.  Kept LabeledDataset API (minor changes in signatures)
6.  Added prototype class for FeatureMetadata (could be extended in future)

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

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

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

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


commit 7d22bcd33fcea3a7588c46368b5289d5b306db7f
Author: Zinoviev Alexey 
Date:   2017-12-07T11:01:43Z

Merge from master

commit 84cbd8b380772ce773790b18066c86b663b1af27
Author: Zinoviev Alexey 
Date:   2017-12-13T10:36:56Z

Merge branch 'master' of https://github.com/apache/ignite

commit b58db6a44be3c625174c1d89c577240771d1bfb4
Author: Zinoviev Alexey 
Date:   2017-12-26T16:37:24Z

Merged from master

commit c050cf6e9ad052ca2d5d15b035da9536eab5ba80
Author: Zinoviev Alexey 
Date:   2017-12-26T19:06:24Z

IGNITE-7205: Added draft

commit 6506cf1d0e3bdf50125004494d075d81b863a0a2
Author: Zinoviev Alexey 
Date:   2017-12-27T08:06:30Z

IGNITE-7205: Fixed classes

commit 427743e0ad8ab1cbbc2a45d3e2b032a6b66c5632
Author: Zinoviev Alexey 
Date:   2017-12-27T14:19:10Z

IGNITE-7205: Refactored Labeled Dataset

commit 1f4792fe2a4cfddbee5390b4e79d74f1cf74585e
Author: Zinoviev Alexey 
Date:   2017-12-27T14:57:49Z

IGNITE-7205: Fixed serialization issue




> DataSet API
> ---
>
> Key: IGNITE-7205
> URL: https://issues.apache.org/jira/browse/IGNITE-7205
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Reporter: Yury Babak
>Assignee: Aleksey Zinoviev
>
> We want to create and implement API for Dataset.
> This should include Dataset, Labeled Dataset, dataset 
> preprocessors(normalizer, filter, mapper, etc...) 



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

[jira] [Commented] (IGNITE-7312) Make use of plain java.util.Base64 instead of reflective alternatives

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7312:


GitHub user andrey-kuznetsov opened a pull request:

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

IGNITE-7312: Made use of java.util.Base64 for base64 encoding.



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

$ git pull https://github.com/andrey-kuznetsov/ignite ignite-7312

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

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


commit 870c6e6b6b76e9b3a15bb8ea006361b18b537edf
Author: Andrey Kuznetsov 
Date:   2017-12-27T14:54:01Z

IGNITE-7312: Made use of java.util.Base64 for base64 encoding.




> Make use of plain java.util.Base64 instead of reflective alternatives
> -
>
> Key: IGNITE-7312
> URL: https://issues.apache.org/jira/browse/IGNITE-7312
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>
> Reflective Base64 encoding should be changed to {{java.util.Base64$Encoder}} 
> as soon as language level becomes equal to 8.



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

[jira] [Commented] (IGNITE-7321) DML operation hangs in case exception is thrown from DHT enlist future

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7321:


Github user gvvinblade closed the pull request at:

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


> DML operation hangs in case exception is thrown from DHT enlist future
> --
>
> Key: IGNITE-7321
> URL: https://issues.apache.org/jira/browse/IGNITE-7321
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
> Fix For: 2.5
>
>
> Root cause: when exception is thrown on primary node (e.g. double-insert or 
> MVCC version conflict), primary future is completed, but exception doesn't 
> seem to be propagated to near node.



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

[jira] [Commented] (IGNITE-7321) DML operation hangs in case exception is thrown from DHT enlist future

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7321:


Github user gvvinblade closed the pull request at:

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


> DML operation hangs in case exception is thrown from DHT enlist future
> --
>
> Key: IGNITE-7321
> URL: https://issues.apache.org/jira/browse/IGNITE-7321
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
> Fix For: 2.5
>
>
> Root cause: when exception is thrown on primary node (e.g. double-insert or 
> MVCC version conflict), primary future is completed, but exception doesn't 
> seem to be propagated to near node.



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

[jira] [Commented] (IGNITE-7217) Add abilities to monitor custom thread pools

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7217:


Github user slukyano closed the pull request at:

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


> Add abilities to monitor custom thread pools
> 
>
> Key: IGNITE-7217
> URL: https://issues.apache.org/jira/browse/IGNITE-7217
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Stanislav Lukyanov
> Fix For: 2.4
>
>
> We have a periodic metrics logger that prints out different stats including 
> the ones for public and system thread pools:
> {noformat}
> ^-- Public thread pool [active=0, idle=0, qSize=0]
> ^-- System thread pool [active=0, idle=8, qSize=0]
> {noformat}
> However, if user configures custom thread pools via 
> {{IgniteConfiguration#setExecutorConfiguration}}, stats for these thread 
> pools are not added. We also do not register MBeans for these pools.



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

[jira] [Resolved] (IGNITE-7321) DML operation hangs in case exception is thrown from DHT enlist future

[Igor Seliverstov (JIRA)]

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

Igor Seliverstov resolved IGNITE-7321.
--
Resolution: Fixed

> DML operation hangs in case exception is thrown from DHT enlist future
> --
>
> Key: IGNITE-7321
> URL: https://issues.apache.org/jira/browse/IGNITE-7321
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
> Fix For: 2.5
>
>
> Root cause: when exception is thrown on primary node (e.g. double-insert or 
> MVCC version conflict), primary future is completed, but exception doesn't 
> seem to be propagated to near node.



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

[jira] [Commented] (IGNITE-7288) Thin client: partial cache configuration

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7288:


Added partial config test, added tests to .NET Core project. Waiting for TC.

> Thin client: partial cache configuration
> 
>
> Key: IGNITE-7288
> URL: https://issues.apache.org/jira/browse/IGNITE-7288
> Project: Ignite
>  Issue Type: Improvement
>  Components: thin client
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 2.4
>
>
> {{OP_CACHE_CREATE_WITH_CONFIGURATION}} and 
> {{OP_CACHE_GET_OR_CREATE_WITH_CONFIGURATION}} should not require complete 
> {{CacheConfiguration}}. User should be able to specify any combination of 
> properties in any order, leaving others at default state.
> Prefix each property with unique ID, then do a switch in a loop.



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

[jira] [Updated] (IGNITE-6826) Change default DiscoverySpi ipFinder type for examples

[Alexey Popov (JIRA)]

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

Alexey Popov updated IGNITE-6826:
-
Description: 
It is better to change multicast ipFinder to static (vm) ipFinder for java 
examples, .NET examples and C++ examples.

http://apache-ignite-developers.2346864.n4.nabble.com/ipFinder-configuration-for-Samples-td23818.html

  was:
It is better to change multicast ipFinder to static (vm) ipFinder for java 
examples and .Net examples.

http://apache-ignite-developers.2346864.n4.nabble.com/ipFinder-configuration-for-Samples-td23818.html


> Change default DiscoverySpi ipFinder type for examples
> --
>
> Key: IGNITE-6826
> URL: https://issues.apache.org/jira/browse/IGNITE-6826
> Project: Ignite
>  Issue Type: Improvement
>  Components: examples
>Affects Versions: 2.3
>Reporter: Alexey Popov
>Assignee: Ryabov Dmitrii
>  Labels: newbie
>
> It is better to change multicast ipFinder to static (vm) ipFinder for java 
> examples, .NET examples and C++ examples.
> http://apache-ignite-developers.2346864.n4.nabble.com/ipFinder-configuration-for-Samples-td23818.html



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

[jira] [Commented] (IGNITE-7321) DML operation hangs in case exception is thrown from DHT enlist future

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7321:


GitHub user gvvinblade opened a pull request:

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

IGNITE-7321 mvcc enabled



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

$ git pull https://github.com/gridgain/apache-ignite 
ignite-7321-mvcc-enabled

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

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


commit 6be6779b6336c36cd71eef0a25199a6a877ce6b5
Author: sboikov 
Date:   2017-09-05T13:47:11Z

ignite-3484

commit e3bba83256c1eb53c4b40fbd9ddba47fcf9d58d5
Author: sboikov 
Date:   2017-09-06T07:10:26Z

ignite-3484

commit dd0afb28466094b801506da8afa3601bfaebd853
Author: sboikov 
Date:   2017-09-06T07:30:04Z

ignite-3484

commit 27b87b413348b03986a463551db24b7726321732
Author: sboikov 
Date:   2017-09-06T08:19:18Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

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

commit dcaf8801accd6ee089849a82b2ccd558aec81895
Author: sboikov 
Date:   2017-09-06T08:19:30Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

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

commit c966451d0bf7059575de92bcfae43d72096ebce4
Author: sboikov 
Date:   2017-09-06T08:27:04Z

Merge branch 'ignite-3478' into ignite-3484

commit 91b9911731a387a3199ddbbc22704bc14af09995
Author: sboikov 
Date:   2017-09-06T09:22:22Z

ignite-3484

commit e40b4d9dcd6fe6c1cd2640bdd7116ca5a08ed781
Author: sboikov 
Date:   2017-09-07T09:12:32Z

ignite-3484

commit 41a1c571e6ba1765941e2f1679dc4ac1582275c4
Author: sboikov 
Date:   2017-09-08T07:55:24Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3484

commit 1626130801dc330bcaf693f46906f6564cce6802
Author: sboikov 
Date:   2017-09-08T08:04:57Z

ignite-3484

commit 91bbb7cd24f38a38e2e65fc3ebf5637572b11b25
Author: sboikov 
Date:   2017-09-08T12:34:52Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-6149

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

commit 085a3219088bc1610d1928c437f075a6fb9a4f9b
Author: sboikov 
Date:   2017-09-08T13:02:16Z

ignite-6149

commit c6f894817ef063984cee1ea886313eecc8da3be0
Author: sboikov 
Date:   2017-09-11T13:51:11Z

ignite-6149

commit 774af444cfc03ab292124ae027e5e85b61496011
Author: sboikov 
Date:   2017-09-12T07:45:36Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-6149

commit 6d1702646fc0abbba690b1b4f7b7fde718d9f4d2
Author: sboikov 
Date:   2017-09-12T08:48:16Z

ignite-6149

commit 0079a0052215f2c1b66b300c34bcf30e4a1da1b0
Author: sboikov 
Date:   2017-09-12T08:48:16Z

ignite-6149

commit 072322f9002df3c2c9033108897d2b7a3de35ca5
Author: sboikov 
Date:   2017-09-12T14:19:18Z

Merge remote-tracking branch 'origin/ignite-6149' into ignite-6149

# Conflicts:
#   
modules/core/src/test/java/org/apache/ignite/internal/processors/cache/mvcc/CacheMvccTransactionsTest.java

commit b5cac1c0d818967553c72d4699d1c66c57c1fb10
Author: sboikov 
Date:   2017-09-13T07:36:42Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-6149

commit 16e52541ef799f1e135576636a69d89591a1fee2
Author: sboikov 
Date:   2017-09-13T08:06:37Z

ignite-6149

commit 9d90972df23a0266246baf6b41774184542233e9
Author: sboikov 
Date:   2017-09-13T08:49:39Z

ignite-6149

commit 7a99432655307acf7c5e190e20952322f68e0e4f
Author: sboikov 
Date:   2017-09-13T09:44:29Z

ignite-6149

commit c961bd91186217807e51453fad906cd5118a8b9a
Author: sboikov 
Date:   2017-09-13T11:24:21Z

ignite-6149

commit f3f58214047d4fa1d9cb5f7ce50ac7278ee17569
Author: sboikov 
Date:   2017-09-13T14:15:55Z

ignite-6149

commit 1a7e10ac56e57ddbe1d9ccf99acab90062dc6957
Author: sboikov 
Date:   2017-09-13T15:01:42Z

Merge remote-tracking branch 'origin/ignite-6149' into ignite-6149

commit 393f802465c8b68d5a5de59ed9107fe25ad23777
Author: sboikov 
Date:   2017-09-15T08:06:58Z

Merge 

[jira] [Commented] (IGNITE-7321) DML operation hangs in case exception is thrown from DHT enlist future

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7321:


GitHub user gvvinblade opened a pull request:

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

IGNITE-7321



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

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

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

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


commit f6e982540e65ab17d439dba990794f35616a30dd
Author: sboikov 
Date:   2017-08-30T09:45:40Z

ignite-3478

commit 275a85db5cd6923b36126166ae99b15e876192be
Author: sboikov 
Date:   2017-08-31T07:44:07Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

commit b7b9089f0102b8cab9942a9c887d93e9f26cc7d2
Author: sboikov 
Date:   2017-08-31T09:00:36Z

disco cache cleanup

commit 855c2d45794c300d41e386b4e6fa40736cc3e40d
Author: sboikov 
Date:   2017-08-31T09:09:58Z

Merge branch 'ignite-3478-1' into ignite-3478

commit 08be7310a93d3ce455215b97cf8ab1a2c3f0ab31
Author: sboikov 
Date:   2017-08-31T09:52:23Z

ignite-3478

commit fce2e31f0fd2f4f6a9944422e40408a0c65cfe90
Author: sboikov 
Date:   2017-09-04T08:13:50Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

commit d3c049952384750c5543a9f88b383c033ef74096
Author: sboikov 
Date:   2017-09-04T08:52:11Z

ignite-3478

commit e71ce1937a18dd32448e92b1038dc48d4cb6f8ab
Author: sboikov 
Date:   2017-09-04T10:16:03Z

ignite-3478

commit 5fac5b0965e97f8951e16e10ca9229a2e78ddb0c
Author: sboikov 
Date:   2017-09-05T10:16:44Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

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

commit 2e0c9c08e046e8d6af1b5358d9053eae999b1fb4
Author: sboikov 
Date:   2017-09-05T11:30:55Z

ignite-3478

commit e1e07ffdf2d711ba3e72f316f5a3970eff27372e
Author: sboikov 
Date:   2017-09-05T11:31:14Z

ignite-3478

commit cbada3934a386668da0b11d4de7d0f58a4d04dfe
Author: sboikov 
Date:   2017-09-05T11:49:49Z

ignite-3484

commit 5a82c68dcd1927bb6fded8b7def38c91ff6e145b
Author: sboikov 
Date:   2017-09-05T11:59:49Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

commit bc9134c94b7a738dc1664e96ca6eabb059f1c268
Author: sboikov 
Date:   2017-09-05T12:03:39Z

Merge branch 'ignite-3478' into ignite-3484

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

commit b4bfcde78825c6517232e49d389bdb5de19f05a9
Author: sboikov 
Date:   2017-09-05T12:27:51Z

ignite-3484

commit 43834aaab9e2c3cd5fdd55289fdc4a9ff8ab6599
Author: sboikov 
Date:   2017-09-05T13:13:00Z

ignite-3478

commit d1b828095713fcadfa260cf94fef01b42a1b12fd
Author: sboikov 
Date:   2017-09-05T13:13:33Z

Merge branch 'ignite-3478' into ignite-3484

commit 6be6779b6336c36cd71eef0a25199a6a877ce6b5
Author: sboikov 
Date:   2017-09-05T13:47:11Z

ignite-3484

commit e3bba83256c1eb53c4b40fbd9ddba47fcf9d58d5
Author: sboikov 
Date:   2017-09-06T07:10:26Z

ignite-3484

commit dd0afb28466094b801506da8afa3601bfaebd853
Author: sboikov 
Date:   2017-09-06T07:30:04Z

ignite-3484

commit 27b87b413348b03986a463551db24b7726321732
Author: sboikov 
Date:   2017-09-06T08:19:18Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

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

commit dcaf8801accd6ee089849a82b2ccd558aec81895
Author: sboikov 
Date:   2017-09-06T08:19:30Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

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

commit c966451d0bf7059575de92bcfae43d72096ebce4
Author: sboikov 
Date:   2017-09-06T08:27:04Z

Merge branch 'ignite-3478' into ignite-3484

commit 91b9911731a387a3199ddbbc22704bc14af09995
Author: sboikov 
Date:   2017-09-06T09:22:22Z

ignite-3484

commit e40b4d9dcd6fe6c1cd2640bdd7116ca5a08ed781
Author: sboikov 
Date:   2017-09-07T09:12:32Z

ignite-3484

commit 

[jira] [Commented] (IGNITE-7214) performance measurement for FCM and KNN algorithms

[Oleg Ignatenko (JIRA)]

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

Oleg Ignatenko commented on IGNITE-7214:


Implemented the benchmarks in [branch 
ignite-7214|https://github.com/gridgain/apache-ignite/tree/ignite-7214]. Also 
implemented a missing example of local FCM (for the sake of completeness).

Plan to accommodate changes to be made in yardstick and examples modules per 
IGNITE-7203 and after that merge to master.

> performance measurement for FCM and KNN algorithms
> --
>
> Key: IGNITE-7214
> URL: https://issues.apache.org/jira/browse/IGNITE-7214
> Project: Ignite
>  Issue Type: Task
>  Components: ml, yardstick
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
> Fix For: 2.4
>
>
> We want to start tracking our performance of Fuzzy c-means (FCM) and k 
> nearest neighbours (KNN) to avoid performance degradation. Also we need some 
> performance comparison with other ml libs.



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

[jira] [Closed] (IGNITE-7302) SQL TX: Failed to query INFORMATIONAL_SCHEMA

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-7302.
---

> SQL TX: Failed to query INFORMATIONAL_SCHEMA
> 
>
> Key: IGNITE-7302
> URL: https://issues.apache.org/jira/browse/IGNITE-7302
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.5
>
>
> {code}
> javax.cache.CacheException: class org.apache.ignite.IgniteException: 
> Unsupported query: Unexpected Table implementation [cls=MetaTable]
> at 
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.assert0(GridSqlQueryParser.java:1876)
> at 
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parseTable(GridSqlQueryParser.java:612)
> at 
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parseTableFilter(GridSqlQueryParser.java:565)
> at 
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parseSelect(GridSqlQueryParser.java:665)
> at 
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parseQuery(GridSqlQueryParser.java:1539)
> at 
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parse(GridSqlQueryParser.java:1490)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.mvccTracker(IgniteH2Indexing.java:1294)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryLocalSqlFields(IgniteH2Indexing.java:926)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryLocalSqlFields(IgniteH2Indexing.java:870)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryLocalSqlFields(IgniteH2Indexing.java:1163)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:1951)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:1936)
> at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2521)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1968)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:585)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:560)
> at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:382)
> at 
> org.apache.ignite.internal.processors.cache.local.IgniteCacheLocalFieldsQuerySelfTest.testInformationSchema(IgniteCacheLocalFieldsQuerySelfTest.java:49)
> {code}



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

[jira] [Commented] (IGNITE-7288) Thin client: partial cache configuration

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7288:


[~vozerov]
1) Looks like you are right, removed.
2) Done, properties and their ids grouped by purpose.

> Thin client: partial cache configuration
> 
>
> Key: IGNITE-7288
> URL: https://issues.apache.org/jira/browse/IGNITE-7288
> Project: Ignite
>  Issue Type: Improvement
>  Components: thin client
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 2.4
>
>
> {{OP_CACHE_CREATE_WITH_CONFIGURATION}} and 
> {{OP_CACHE_GET_OR_CREATE_WITH_CONFIGURATION}} should not require complete 
> {{CacheConfiguration}}. User should be able to specify any combination of 
> properties in any order, leaving others at default state.
> Prefix each property with unique ID, then do a switch in a loop.



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

[jira] [Assigned] (IGNITE-6456) Add flags to ClientConnectorConfiguration which enable/disable different clients

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-6456:
---

Assignee: Roman Kondakov

> Add flags to ClientConnectorConfiguration which enable/disable different 
> clients
> 
>
> Key: IGNITE-6456
> URL: https://issues.apache.org/jira/browse/IGNITE-6456
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc, odbc, thin client
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Roman Kondakov
>  Labels: usability
> Fix For: 2.4
>
>
> There is currently no way to disable only one client. For example, currently 
> you can't disallow thin JDBC driver connectivity alone, you can only disable 
> the whole {{ClientListenerProcessor}}, which is going to disable ODBC and 
> thin .NET clients as well.
> We should add options to disable/enable every single client, supported by the 
> {{ClientListenerProcessor}} separately. For example, we can add flags to the 
> {{ClientConnectorConfiguration}}:
> {{allowJdbc}}
> {{allowOdbc}}
> {{allowClient}}



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

[jira] [Updated] (IGNITE-6456) Add flags to ClientConnectorConfiguration which enable/disable different clients

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6456:

Description: 
There is currently no way to disable only one client. For example, currently 
you can't disallow thin JDBC driver connectivity alone, you can only disable 
the whole {{ClientListenerProcessor}}, which is going to disable ODBC and thin 
.NET clients as well.

We should add options to disable/enable every single client, supported by the 
{{ClientListenerProcessor}} separately. For example, we can add flags to the 
{{ClientConnectorConfiguration}}:
{{allowJdbc}}
{{allowOdbc}}
{{allowClient}}


  was:
There is currently no way to disable only one client. For example, currently 
you can't disallow thin JDBC driver connectivity alone, you can only disable 
the whole {{ClientListenerProcessor}}, which is going to disable ODBC and thin 
.NET clients as well.

We should add options to disable/enable every single client, supported by the 
{{ClientListenerProcessor}} separately. For example, we can add flags to the 
{{SqlConnectorConfiguration}}:
{{allowJdbc}}
{{allowOdbc}}
{{allowClient}}



> Add flags to ClientConnectorConfiguration which enable/disable different 
> clients
> 
>
> Key: IGNITE-6456
> URL: https://issues.apache.org/jira/browse/IGNITE-6456
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc, odbc, thin client
>Affects Versions: 2.1
>Reporter: Igor Sapego
>  Labels: usability
> Fix For: 2.4
>
>
> There is currently no way to disable only one client. For example, currently 
> you can't disallow thin JDBC driver connectivity alone, you can only disable 
> the whole {{ClientListenerProcessor}}, which is going to disable ODBC and 
> thin .NET clients as well.
> We should add options to disable/enable every single client, supported by the 
> {{ClientListenerProcessor}} separately. For example, we can add flags to the 
> {{ClientConnectorConfiguration}}:
> {{allowJdbc}}
> {{allowOdbc}}
> {{allowClient}}



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

[jira] [Updated] (IGNITE-6456) Add flags to ClientConnectorConfiguration which enable/disable different clients

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6456:

Description: 
There is currently no way to disable only one client. For example, currently 
you can't disallow thin JDBC driver connectivity alone, you can only disable 
the whole {{ClientListenerProcessor}}, which is going to disable ODBC and thin 
.NET clients as well.

We should add options to disable/enable every single client, supported by the 
{{ClientListenerProcessor}} separately. For example, we can add flags to the 
{{SqlConnectorConfiguration}}:
{{allowJdbc}}
{{allowOdbc}}
{{allowClient}}


  was:
There is currently no way to disable only one client. For example, currently 
you can't disallow thin JDBC driver connectivity alone, you can only disable 
the whole {{ClientListenerProcessor}}, which is going to disable ODBC and thin 
.NET clients as well.

We should add options to disable/enable every single client, supported by the 
{{ClientListenerProcessor}} separately. For example, we can add flags to the 
{{SqlConnectorConfiguration}}:
{{enableJdbc}}
{{enableOdbc}}
{{enableThinClients}}



> Add flags to ClientConnectorConfiguration which enable/disable different 
> clients
> 
>
> Key: IGNITE-6456
> URL: https://issues.apache.org/jira/browse/IGNITE-6456
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc, odbc, thin client
>Affects Versions: 2.1
>Reporter: Igor Sapego
>  Labels: usability
> Fix For: 2.4
>
>
> There is currently no way to disable only one client. For example, currently 
> you can't disallow thin JDBC driver connectivity alone, you can only disable 
> the whole {{ClientListenerProcessor}}, which is going to disable ODBC and 
> thin .NET clients as well.
> We should add options to disable/enable every single client, supported by the 
> {{ClientListenerProcessor}} separately. For example, we can add flags to the 
> {{SqlConnectorConfiguration}}:
> {{allowJdbc}}
> {{allowOdbc}}
> {{allowClient}}



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

[jira] [Comment Edited] (IGNITE-6923) Cache metrics are updated in timeout-worker potentially delaying critical code execution due to current implementation issues.

[Aleksey Plekhanov (JIRA)]

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

Aleksey Plekhanov edited comment on IGNITE-6923 at 12/27/17 12:36 PM:
--

There were 4 fixes made:

# Each cluster metrics calculation invoked the 
{{DiscoveryMetricsProvider#cacheMetrics}} method, which creates metrics 
snapshots for all caches and is heavy, when a large number of caches are 
started. But only one cache metric is needed for cluster metrics calculation 
({{getOffHeapAllocatedSize}}), so invocation of {{cacheMetrics}} is replaced 
with a direct call to {{getOffHeapAllocatedSize}}.
# Each invocation of {{DiscoveryMetricsProvider#metrics}} creates cluster 
metrics snapshot. It’s ok for discovery update message (because all metrics are 
serialized and calculation of all metrics is needed), but sometimes this is 
redundant. For example, call to {{locNode.metrics().getTotalCpus()}} calculates 
each cluster metric, but uses only a total CPU count, which can be calculated 
at a lower cost. To solve this problem {{DiscoveryMetricsProvider#metrics}} 
method does not calculate snapshot of all metrics now, but returns a 
{{ClusterMetricsImpl}} class instance, which calculates each metric on demand.
# Some cache metrics (entities count, partitions count) iterates through local 
partitions to get the result. There are 9 such methods which uses this 
iteration per each call. But it is possible to calculate this 9 metrics using 
one iteration over partitions. The new method was implemented to calculate all 
this metrics at once, in {{CacheMetricsSnapshot}} individual calculations of 
this metrics were replaced by the new method.
# If there are a lot of nodes and a lot of caches in the cluster, size of 
{{TcpDiscoveryMetricsUpdateMessage}} can be rather large (up to hundreds of 
megabytes), because it contains information about each metric for each cache on 
each node. Sending cache metrics in the discovery message can be turned off by 
disabling statistics for caches, but it also makes unavailable cache metrics 
via JMX. New system property was added to disable cache metrics update in the 
discovery message without disabling statistics.

Some benchmarks:

Environment: 2 nodes, 200 caches (with statistics enabled), 1024 partitions per 
cache, 1 job metrics snapshots.

* First optimization (direct call to {{getOffHeapAllocatedSize}})
Subject: {{DiscoveryMetricsProvider.metrics()}} method
Before optimization: 17 operations per second
After optimization: 8000 operations per second
* Second optimization ({{ClusterMetricsImpl}} instead of 
{{ClusterMetricsSnapshot}})
Subject: {{DiscoveryMetricsProvider.metrics().getTotalCpus()}}
Before optimization: 8000 operations per second
After optimization: 200 operations per second
But individual call to {{getTotalCpus()}} is relatively rare, in most cases 
{{DiscoveryMetricsProvider.metrics()}} used for sending 
{{TcpDiscoveryMetricsUpdateMessage}} and performance of 
{{ClusterMetricsSnapshot.serialize(DiscoveryMetricsProvider.metrics())}} left 
the same (8000 operations per second). Perhaps after the first optimization 
this (second) optimization is no longer needed?
* Third optimization (one iteration over partitions)
Subject: {{DiscoveryMetricsProvider.cacheMetrics()}}
Before optimization: 17 operations per second
After optimization: 75 operations per second



was (Author: alex_pl):
There were 4 fixes made:

# Each cluster metrics calculation invoked the 
{DiscoveryMetricsProvider#cacheMetrics} method, which creates metrics snapshots 
for all caches and is heavy, when a large number of caches are started. But 
only one cache metric is needed for cluster metrics calculation 
({getOffHeapAllocatedSize}), so invocation of {cacheMetrics} is replaced with a 
direct call to {getOffHeapAllocatedSize}.
# Each invocation of {DiscoveryMetricsProvider#metrics} creates cluster metrics 
snapshot. It’s ok for discovery update message (because all metrics are 
serialized and calculation of all metrics is needed), but sometimes this is 
redundant. For example, call to {locNode.metrics().getTotalCpus()} calculates 
each cluster metric, but uses only a total CPU count, which can be calculated 
at a lower cost. To solve this problem {DiscoveryMetricsProvider#metrics} 
method does not calculate snapshot of all metrics now, but returns a 
{ClusterMetricsImpl} class instance, which calculates each metric on demand.
# Some cache metrics (entities count, partitions count) iterates through local 
partitions to get the result. There are 9 such methods which uses this 
iteration per each call. But it is possible to calculate this 9 metrics using 
one iteration over partitions. The new method was implemented to calculate all 
this metrics at once, in {CacheMetricsSnapshot} individual calculations of this 
metrics were replaced by the new method.
# If there are a 

[jira] [Comment Edited] (IGNITE-6923) Cache metrics are updated in timeout-worker potentially delaying critical code execution due to current implementation issues.

[Aleksey Plekhanov (JIRA)]

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

Aleksey Plekhanov edited comment on IGNITE-6923 at 12/27/17 12:33 PM:
--

There were 4 fixes made:

# Each cluster metrics calculation invoked the 
{DiscoveryMetricsProvider#cacheMetrics} method, which creates metrics snapshots 
for all caches and is heavy, when a large number of caches are started. But 
only one cache metric is needed for cluster metrics calculation 
({getOffHeapAllocatedSize}), so invocation of {cacheMetrics} is replaced with a 
direct call to {getOffHeapAllocatedSize}.
# Each invocation of {DiscoveryMetricsProvider#metrics} creates cluster metrics 
snapshot. It’s ok for discovery update message (because all metrics are 
serialized and calculation of all metrics is needed), but sometimes this is 
redundant. For example, call to {locNode.metrics().getTotalCpus()} calculates 
each cluster metric, but uses only a total CPU count, which can be calculated 
at a lower cost. To solve this problem {DiscoveryMetricsProvider#metrics} 
method does not calculate snapshot of all metrics now, but returns a 
{ClusterMetricsImpl} class instance, which calculates each metric on demand.
# Some cache metrics (entities count, partitions count) iterates through local 
partitions to get the result. There are 9 such methods which uses this 
iteration per each call. But it is possible to calculate this 9 metrics using 
one iteration over partitions. The new method was implemented to calculate all 
this metrics at once, in {CacheMetricsSnapshot} individual calculations of this 
metrics were replaced by the new method.
# If there are a lot of nodes and a lot of caches in the cluster, size of 
{TcpDiscoveryMetricsUpdateMessage} can be rather large (up to hundreds of 
megabytes), because it contains information about each metric for each cache on 
each node. Sending cache metrics in the discovery message can be turned off by 
disabling statistics for caches, but it also makes unavailable cache metrics 
via JMX. New system property was added to disable cache metrics update in the 
discovery message without disabling statistics.

Some benchmarks:

Environment: 2 nodes, 200 caches (with statistics enabled), 1024 partitions per 
cache, 1 job metrics snapshots.

* First optimization (direct call to {getOffHeapAllocatedSize})
Subject: {DiscoveryMetricsProvider.metrics()} method
Before optimization: 17 operations per second
After optimization: 8000 operations per second
* Second optimization ({ClusterMetricsImpl} instead of {ClusterMetricsSnapshot})
Subject: {DiscoveryMetricsProvider.metrics().getTotalCpus()}
Before optimization: 8000 operations per second
After optimization: 200 operations per second
But individual call to {getTotalCpus()} is relatively rare, in most cases 
{DiscoveryMetricsProvider.metrics()} used for sending 
{TcpDiscoveryMetricsUpdateMessage} and performance of 
{ClusterMetricsSnapshot.serialize(DiscoveryMetricsProvider.metrics())} left the 
same (8000 operations per second). Perhaps after the first optimization this 
(second) optimization is no longer needed?
* Third optimization (one iteration over partitions)
Subject: {DiscoveryMetricsProvider.cacheMetrics()}
Before optimization: 17 operations per second
After optimization: 75 operations per second



was (Author: alex_pl):
There were 4 fixes made:

# Each cluster metrics calculation invoked the 
DiscoveryMetricsProvider#cacheMetrics method, which creates metrics snapshots 
for all caches and is heavy, when a large number of caches are started. But 
only one cache metric is needed for cluster metrics calculation 
(getOffHeapAllocatedSize), so invocation of cacheMetrics is replaced with a 
direct call to getOffHeapAllocatedSize.
# Each invocation of DiscoveryMetricsProvider#metrics creates cluster metrics 
snapshot. It’s ok for discovery update message (because all metrics are 
serialized and calculation of all metrics is needed), but sometimes this is 
redundant. For example, call to locNode.metrics().getTotalCpus() calculates 
each cluster metric, but uses only a total CPU count, which can be calculated 
at a lower cost. To solve this problem DiscoveryMetricsProvider#metrics method 
does not calculate snapshot of all metrics now, but returns a 
ClusterMetricsImpl class instance, which calculates each metric on demand.
# Some cache metrics (entities count, partitions count) iterates through local 
partitions to get the result. There are 9 such methods which uses this 
iteration per each call. But it is possible to calculate this 9 metrics using 
one iteration over partitions. The new method was implemented to calculate all 
this metrics at once, in CacheMetricsSnapshot individual calculations of this 
metrics were replaced by the new method.
# If there are a lot of nodes and a lot of caches in the cluster, size of 

[jira] [Commented] (IGNITE-6923) Cache metrics are updated in timeout-worker potentially delaying critical code execution due to current implementation issues.

[Aleksey Plekhanov (JIRA)]

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

Aleksey Plekhanov commented on IGNITE-6923:
---

There were 4 fixes made:

# Each cluster metrics calculation invoked the 
DiscoveryMetricsProvider#cacheMetrics method, which creates metrics snapshots 
for all caches and is heavy, when a large number of caches are started. But 
only one cache metric is needed for cluster metrics calculation 
(getOffHeapAllocatedSize), so invocation of cacheMetrics is replaced with a 
direct call to getOffHeapAllocatedSize.
# Each invocation of DiscoveryMetricsProvider#metrics creates cluster metrics 
snapshot. It’s ok for discovery update message (because all metrics are 
serialized and calculation of all metrics is needed), but sometimes this is 
redundant. For example, call to locNode.metrics().getTotalCpus() calculates 
each cluster metric, but uses only a total CPU count, which can be calculated 
at a lower cost. To solve this problem DiscoveryMetricsProvider#metrics method 
does not calculate snapshot of all metrics now, but returns a 
ClusterMetricsImpl class instance, which calculates each metric on demand.
# Some cache metrics (entities count, partitions count) iterates through local 
partitions to get the result. There are 9 such methods which uses this 
iteration per each call. But it is possible to calculate this 9 metrics using 
one iteration over partitions. The new method was implemented to calculate all 
this metrics at once, in CacheMetricsSnapshot individual calculations of this 
metrics were replaced by the new method.
# If there are a lot of nodes and a lot of caches in the cluster, size of 
TcpDiscoveryMetricsUpdateMessage can be rather large (up to hundreds of 
megabytes), because it contains information about each metric for each cache on 
each node. Sending cache metrics in the discovery message can be turned off by 
disabling statistics for caches, but it also makes unavailable cache metrics 
via JMX. New system property was added to disable cache metrics update in the 
discovery message without disabling statistics.

Some benchmarks:

Environment: 2 nodes, 200 caches (with statistics enabled), 1024 partitions per 
cache, 1 job metrics snapshots.

* First optimization (direct call to getOffHeapAllocatedSize)
Subject: DiscoveryMetricsProvider.metrics() method
Before optimization: 17 operations per second
After optimization: 8000 operations per second
* Second optimization (ClusterMetricsImpl instead of ClusterMetricsSnapshot)
Subject: DiscoveryMetricsProvider.metrics().getTotalCpus()
Before optimization: 8000 operations per second
After optimization: 200 operations per second
But individual call to getTotalCpus() is relatively rare, in most cases 
DiscoveryMetricsProvider.metrics() used for sending 
TcpDiscoveryMetricsUpdateMessage and performance of 
ClusterMetricsSnapshot.serialize(DiscoveryMetricsProvider.metrics()) left the 
same (8000 operations per second). Perhaps after the first optimization this 
optimization is no longer needed?
* Third optimization (one iteration over partitions)
Subject: DiscoveryMetricsProvider.cacheMetrics()
Before optimization: 17 operations per second
After optimization: 75 operations per second


> Cache metrics are updated in timeout-worker potentially delaying critical 
> code execution due to current implementation issues.
> --
>
> Key: IGNITE-6923
> URL: https://issues.apache.org/jira/browse/IGNITE-6923
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.3
>Reporter: Alexei Scherbakov
>Assignee: Aleksey Plekhanov
>  Labels: iep-6
> Fix For: 2.4
>
>
> Some metrics are using cache iteration for calculation. If number of caches 
> rather large this can be slow.
> Similar code is running in discovery thread.
> See stack trace for example.
> {noformat}
> "grid-timeout-worker-#39%DPL_GRID%DplGridNodeName%" #152 prio=5 os_prio=0 
> tid=0x7f1009a03000 nid=0x5caa runnable [0x7f0f059d9000] 
>java.lang.Thread.State: RUNNABLE 
> at java.util.HashMap.containsKey(HashMap.java:595) 
> at java.util.HashSet.contains(HashSet.java:203) 
> at 
> java.util.Collections$UnmodifiableCollection.contains(Collections.java:1032) 
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$3.apply(IgniteCacheOffheapManagerImpl.java:339)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$3.apply(IgniteCacheOffheapManagerImpl.java:337)
> at 
> org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.hasNext:@TransformFilteringIterator.java:90)
> at 
> 

[jira] [Updated] (IGNITE-5783) .NET: LINQ queries should provide the ability to generate the SQL query plan

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-5783:
---
Labels: .NET LINQ newbie  (was: .NET newbie)

> .NET: LINQ queries should provide the ability to generate the SQL query plan
> 
>
> Key: IGNITE-5783
> URL: https://issues.apache.org/jira/browse/IGNITE-5783
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Michael Griggs
>Priority: Minor
>  Labels: .NET, LINQ, newbie
>
> At present, the only way to see the query plan generated by a LINQ query in 
> C# is to:
> # Call {{GetFieldsQuery()}}
> # Prepend the string {{"explain "}} to the resulting string
> # execute the query in the step above and retrieve the plan



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

[jira] [Commented] (IGNITE-5783) .NET: LINQ queries should provide the ability to generate the SQL query plan

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5783:


Proposed design: add {{ICacheQueryable.Explain()}} method:

{code}
var qry = cache.AsCacheQueryable().Where(x=>x.Key > 3);
string explanation = qry.ToCacheQueryable().Explain();
{code}

> .NET: LINQ queries should provide the ability to generate the SQL query plan
> 
>
> Key: IGNITE-5783
> URL: https://issues.apache.org/jira/browse/IGNITE-5783
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Michael Griggs
>Priority: Minor
>  Labels: .NET, newbie
>
> At present, the only way to see the query plan generated by a LINQ query in 
> C# is to:
> # Call {{GetFieldsQuery()}}
> # Prepend the string {{"explain "}} to the resulting string
> # execute the query in the step above and retrieve the plan



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

[jira] [Updated] (IGNITE-5783) .NET: LINQ queries should provide the ability to generate the SQL query plan

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-5783:
---
Labels: .NET newbie  (was: .NET)

> .NET: LINQ queries should provide the ability to generate the SQL query plan
> 
>
> Key: IGNITE-5783
> URL: https://issues.apache.org/jira/browse/IGNITE-5783
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Michael Griggs
>Priority: Minor
>  Labels: .NET, newbie
>
> At present, the only way to see the query plan generated by a LINQ query in 
> C# is to:
> # Call {{GetFieldsQuery()}}
> # Prepend the string {{"explain "}} to the resulting string
> # execute the query in the step above and retrieve the plan



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

[jira] [Updated] (IGNITE-5266) .NET: Support LongCount in LINQ

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-5266:
---
Labels: .NET LINQ newbie  (was: .NET LINQ)

> .NET: Support LongCount in LINQ
> ---
>
> Key: IGNITE-5266
> URL: https://issues.apache.org/jira/browse/IGNITE-5266
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>  Labels: .NET, LINQ, newbie
>
> H2 SQL {{COUNT}} function returns a {{long}}, but LINQ {{Count}} returns an 
> int. We should simply add {{LongCount}} support the same way as {{Count}.
> The tricky thing would be to test it.



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

[jira] [Commented] (IGNITE-7203) Java 8 by default

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7203:


All .NET tests fixed

> Java 8 by default
> -
>
> Key: IGNITE-7203
> URL: https://issues.apache.org/jira/browse/IGNITE-7203
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Anton Vinogradov
>Assignee: Peter Ivanov
>  Labels: important
> Fix For: 2.4
>
>
> We should drop Java 7 support.
> 1) We should 
> - get rid of java8 profiles
> - relocate tests and sources with *.java8.* package to regular sources
> - set 
> {noformat}
>  1.8
>  1.8
> {noformat} 
> by default
> 2) Release process
> https://ci.ignite.apache.org/project.html?projectId=AssemblyAndRelease
> should be updated if necessary.



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

[jira] [Updated] (IGNITE-7188) SQL TX: Retry strategy on lock conflicts

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7188:

Fix Version/s: 2.5

> SQL TX: Retry strategy on lock conflicts
> 
>
> Key: IGNITE-7188
> URL: https://issues.apache.org/jira/browse/IGNITE-7188
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Igor Seliverstov
>  Labels: iep-3, sql
> Fix For: 2.5
>
>
> We need to provide some strategy to avoid lock conflicts (deadlocks), detect 
> and hanle them.



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

[jira] [Updated] (IGNITE-7186) SQL TX: Replicated caches support

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7186:

Fix Version/s: 2.5

> SQL TX: Replicated caches support
> -
>
> Key: IGNITE-7186
> URL: https://issues.apache.org/jira/browse/IGNITE-7186
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Igor Seliverstov
>  Labels: iep-3, sql
> Fix For: 2.5
>
>
> Need to implement query execution and update on a near node.



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

[jira] [Updated] (IGNITE-7185) SQL TX: Updates during rebalancing.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7185:

Fix Version/s: 2.5

> SQL TX: Updates during rebalancing.
> ---
>
> Key: IGNITE-7185
> URL: https://issues.apache.org/jira/browse/IGNITE-7185
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Igor Seliverstov
>  Labels: iep-3, sql
> Fix For: 2.5
>
>
> Crrently we map an update operation to data nodes and perform it on all the 
> nodes simultaneously. It works fine on stable topology but produces many 
> issues if the operation happens at the rebalance time because we cannot query 
> data properly if some partitions are in moving state.



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

[jira] [Updated] (IGNITE-7187) SQL TX: Near caches support

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7187:

Fix Version/s: 2.5

> SQL TX: Near caches support
> ---
>
> Key: IGNITE-7187
> URL: https://issues.apache.org/jira/browse/IGNITE-7187
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Igor Seliverstov
>  Labels: iep-3, sql
> Fix For: 2.5
>
>
> Currently near readers don't participate in SQL transactions, we need to 
> notify near readers on updates.



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

[jira] [Updated] (IGNITE-4193) SQL TX: ODBC driver support

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4193:

Fix Version/s: (was: 2.4)
   2.5

> SQL TX: ODBC driver support
> ---
>
> Key: IGNITE-4193
> URL: https://issues.apache.org/jira/browse/IGNITE-4193
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Reporter: Denis Magda
>  Labels: iep-3
> Fix For: 2.5
>
>
> To support execution of DML and SELECT statements inside of a transaction 
> started from ODBC driver side.



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

[jira] [Updated] (IGNITE-7184) SQL TX: Support optimistic transactions

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7184:

Fix Version/s: 2.5

> SQL TX: Support optimistic transactions
> ---
>
> Key: IGNITE-7184
> URL: https://issues.apache.org/jira/browse/IGNITE-7184
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Igor Seliverstov
>  Labels: iep-3, sql
> Fix For: 2.5
>
>
> Support optimistic transactions



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

[jira] [Updated] (IGNITE-7302) SQL TX: Failed to query INFORMATIONAL_SCHEMA

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7302:

Fix Version/s: (was: 2.4)
   2.5

> SQL TX: Failed to query INFORMATIONAL_SCHEMA
> 
>
> Key: IGNITE-7302
> URL: https://issues.apache.org/jira/browse/IGNITE-7302
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.5
>
>
> {code}
> javax.cache.CacheException: class org.apache.ignite.IgniteException: 
> Unsupported query: Unexpected Table implementation [cls=MetaTable]
> at 
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.assert0(GridSqlQueryParser.java:1876)
> at 
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parseTable(GridSqlQueryParser.java:612)
> at 
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parseTableFilter(GridSqlQueryParser.java:565)
> at 
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parseSelect(GridSqlQueryParser.java:665)
> at 
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parseQuery(GridSqlQueryParser.java:1539)
> at 
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parse(GridSqlQueryParser.java:1490)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.mvccTracker(IgniteH2Indexing.java:1294)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryLocalSqlFields(IgniteH2Indexing.java:926)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryLocalSqlFields(IgniteH2Indexing.java:870)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryLocalSqlFields(IgniteH2Indexing.java:1163)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:1951)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:1936)
> at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2521)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1968)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:585)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:560)
> at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:382)
> at 
> org.apache.ignite.internal.processors.cache.local.IgniteCacheLocalFieldsQuerySelfTest.testInformationSchema(IgniteCacheLocalFieldsQuerySelfTest.java:49)
> {code}



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

[jira] [Updated] (IGNITE-7300) Allow expressions in SQL INSERTs within transactions

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7300:

Fix Version/s: (was: 2.4)
   2.5

> Allow expressions in SQL INSERTs within transactions
> 
>
> Key: IGNITE-7300
> URL: https://issues.apache.org/jira/browse/IGNITE-7300
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexander Paschenko
>Assignee: Igor Seliverstov
> Fix For: 2.5
>
>
> The problem is related to IGNITE-7267 - the latter honors raw rows, but drops 
> support for inserts with expressions which yield local subqueries. To fix 
> this, {{UpdatePlan.isLocalSubquery()}} must be honored.



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

[jira] [Updated] (IGNITE-5935) Integrate mvcc support in tx recovery protocol

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5935:

Fix Version/s: 2.5

> Integrate mvcc support in tx recovery protocol
> --
>
> Key: IGNITE-5935
> URL: https://issues.apache.org/jira/browse/IGNITE-5935
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Semen Boikov
> Fix For: 2.5
>
>
> Need make sure tx recovery work properly with mvcc enabled:
> - tx IDs are generated and not lost if transaction is committed by recovery 
> procedure
> - tx should be removed from list of active transactions on coordinator



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

[jira] [Updated] (IGNITE-6353) Integrate mvcc support in scan query protocol

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6353:

Fix Version/s: 2.5

> Integrate mvcc support in scan query protocol
> -
>
> Key: IGNITE-6353
> URL: https://issues.apache.org/jira/browse/IGNITE-6353
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
> Fix For: 2.5
>
>
> Need integrate mvcc support in scan query protocol:
> - request current ID and list of active txs from coordinator
> - pass this info in query requests and in cache iterators
> - notify coordinator after query completed



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

[jira] [Updated] (IGNITE-6754) Support coordinator change while sql is in progress

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6754:

Fix Version/s: 2.5

> Support coordinator change while sql is in progress
> ---
>
> Key: IGNITE-6754
> URL: https://issues.apache.org/jira/browse/IGNITE-6754
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Semen Boikov
> Fix For: 2.5
>
>
> Need support coordinator change while sql queries are in progress (see how 
> MvccQueryTracker is used for cache.getAll operation). Need make sure this is 
> handled for both local/non-local queries and add tests similar to 
> CacheMvccTransactionsTest.testCleanupWaitsForGet. 



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

[jira] [Updated] (IGNITE-6875) MVCC: advanced features

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6875:

Fix Version/s: 2.5

> MVCC: advanced features
> ---
>
> Key: IGNITE-6875
> URL: https://issues.apache.org/jira/browse/IGNITE-6875
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Vladimir Ozerov
> Fix For: 2.5
>
>
> This is umbrella ticket for advanced MVCC features, focusing on failover, 
> performance, scan queries.



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

[jira] [Updated] (IGNITE-6921) Optimise tx/queries tracking when mvcc is enabled and local caches are used

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6921:

Fix Version/s: 2.5

> Optimise tx/queries tracking when mvcc is enabled and local caches are used
> ---
>
> Key: IGNITE-6921
> URL: https://issues.apache.org/jira/browse/IGNITE-6921
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Igor Seliverstov
>  Labels: sql
> Fix For: 2.5
>
>
> Seems we don't need to request mvcc version and track tx/queries on mvcc 
> coordinator when only local caches are used.



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

[jira] [Updated] (IGNITE-6459) Implement metrics to monitor mvcc coordinator performance

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6459:

Fix Version/s: 2.5

> Implement metrics to monitor mvcc coordinator performance
> -
>
> Key: IGNITE-6459
> URL: https://issues.apache.org/jira/browse/IGNITE-6459
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
> Fix For: 2.5
>
>
> Need provide some public metrics which allow to to monitor mvcc coordinator 
> performance.



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

[jira] [Updated] (IGNITE-6458) Implement possibility to manually change mvcc coordinator

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6458:

Fix Version/s: 2.5

> Implement possibility to manually change mvcc coordinator
> -
>
> Key: IGNITE-6458
> URL: https://issues.apache.org/jira/browse/IGNITE-6458
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
> Fix For: 2.5
>
>
> Need provide some ability to manually switch mvcc coordinator, probably via 
> MBean.



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

[jira] [Updated] (IGNITE-6888) Cache involved tables set for statement

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6888:

Fix Version/s: 2.5

> Cache involved tables set for statement
> ---
>
> Key: IGNITE-6888
> URL: https://issues.apache.org/jira/browse/IGNITE-6888
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Igor Seliverstov
> Fix For: 2.5
>
>
> Currently we have to create AST from {{PreparedStatement}} to collect and 
> process all involved 
> in the query caches (See IgniteH2Indexing#mvccTracker}}). It makes sense to 
> cache parse results per statements by analogy with statements itself.



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

[jira] [Updated] (IGNITE-5936) Cleanup of not needed and committed versions

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5936:

Fix Version/s: (was: 2.4)
   2.5

> Cleanup of not needed and committed versions
> 
>
> Key: IGNITE-5936
> URL: https://issues.apache.org/jira/browse/IGNITE-5936
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
> Fix For: 2.5
>
>
> At first committed data is stored in separate data structure.Need implement 
> some procedure to remove from mvcc storage versions which are not needed 
> anymore and flush committed versions in main storage. Version which is safe 
> to remove (there are not readers using this version) should be somehow passed 
> from coordinator to servers.



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

[jira] [Updated] (IGNITE-6874) MVCC: base functionality

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6874:

Fix Version/s: (was: 2.4)
   2.5

> MVCC: base functionality
> 
>
> Key: IGNITE-6874
> URL: https://issues.apache.org/jira/browse/IGNITE-6874
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Vladimir Ozerov
> Fix For: 2.5
>
>
> This is an umbrella ticket for base MVCC functionality:
> 1) Version management
> 2) Cache transactions support
> 3) SQL SELECTs support



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

[jira] [Commented] (IGNITE-6022) SQL: add native batch execution support for DML statements

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6022:


GitHub user dolphin1414 opened a pull request:

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

IGNITE-6022: Implemented native batch execution support for DML statements.

Implemented native batch execution support for DML statements.

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

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

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

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


commit eacd01fc01c9dea0b81e7aec8d5bbd89852401ae
Author: rkondakov 
Date:   2017-12-27T11:53:30Z

IGNITE-6022: Implemented native batch execution support for DML statements.




> SQL: add native batch execution support for DML statements
> --
>
> Key: IGNITE-6022
> URL: https://issues.apache.org/jira/browse/IGNITE-6022
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
>  Labels: iep-1, performance
> Fix For: 2.4
>
>
> We have batch execution support for JDBC and ODBC drivers. This decreases 
> number of network hops. However, we do not have any batch execution support 
> on the server side. It means that for batch of N similar statements, every 
> statement will go through the whole execution chain - parsing, splitting, 
> communication with servers. And while parsing and splitting might be avoided 
> with help of statement cache, the most heavy part - network communication - 
> is still there.
> We need to investigate how to optimize the flow for batch updates. Possible 
> improvements:
> 1) Execute statements with certain degree of parallelism;
> 2) Send several query execution requests to the server at once;
> 3) Ensure that caches are used properly for batching - we should not parse 
> the same request multiple times.



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

[jira] [Updated] (IGNITE-5937) Mvcc data structure for SQL queries

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5937:

Fix Version/s: (was: 2.4)
   2.5

> Mvcc data structure for SQL queries
> ---
>
> Key: IGNITE-5937
> URL: https://issues.apache.org/jira/browse/IGNITE-5937
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Semen Boikov
>Assignee: Semen Boikov
> Fix For: 2.5
>
>
> Need implement some data structure to store/query multiple entry versions.
> One possible option:
> - committed value at first is stored in separate BPlusTree index (there also 
> need store related tx id to filter out data for non-finished transactions)
> - periodically flush data for finished transaction in 'main' index
> - for SQL queries need merge result from main index and filtered 'mvcc' 
> index. Note: it is possible 'mvcc' index will contain multiple committed 
> versions of the same entry, need make sure only one last one will appear in 
> result.



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

[jira] [Updated] (IGNITE-3484) MVCC data structure for getAll operation

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3484:

Fix Version/s: (was: 2.4)
   2.5

> MVCC data structure for getAll operation
> 
>
> Key: IGNITE-3484
> URL: https://issues.apache.org/jira/browse/IGNITE-3484
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Semen Boikov
> Fix For: 2.5
>
>
> Need implement some data structure to store/get multiple entry versions:
> - committed value at first is stored in separate data structure (there also 
> need store related tx id to filter out data for non-finished transactions), 
> probably existing BPlusTree can be used
> - periodically need flush data for finished transaction in 'main' hash index
> - 'getAll' operation should include max 'visible' ID and list of active 
> transactions, this information should be used to find last 'visible' version 
> in 'mvcc' or 'main' index



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

[jira] [Updated] (IGNITE-6149) Create mvcc prototype application

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6149:

Fix Version/s: (was: 2.4)
   2.5

> Create mvcc prototype application
> -
>
> Key: IGNITE-6149
> URL: https://issues.apache.org/jira/browse/IGNITE-6149
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Semen Boikov
> Fix For: 2.5
>
> Attachments: MvccTestApp.java
>
>
> Need create simple prototype application to verify major concepts:
> - which data should be stored on coordinator and on data nodes
> - filtering algorithm for getAll and sql operations
> - clean up of committed versions



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

[jira] [Updated] (IGNITE-3479) Coordinator(s) for global transaction ordering

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3479:

Fix Version/s: (was: 2.4)
   2.5

> Coordinator(s) for global transaction ordering
> --
>
> Key: IGNITE-3479
> URL: https://issues.apache.org/jira/browse/IGNITE-3479
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Semen Boikov
> Fix For: 2.5
>
>
> Current transaction ID will not work for SQL MVCC ordering because two 
> transaction IDs are not in total order across the cluster.
> One of the approaches is to have a dedicated coordinator which will assign a 
> continuously growing transaction ID for each committed transaction. This ID 
> must be acquired by each transaction at the last step of PREPARE stage.



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

[jira] [Updated] (IGNITE-5932) Integrate communication with coordinator in tx protocol

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5932:

Fix Version/s: (was: 2.4)
   2.5

> Integrate communication with coordinator in tx protocol
> ---
>
> Key: IGNITE-5932
> URL: https://issues.apache.org/jira/browse/IGNITE-5932
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Semen Boikov
> Fix For: 2.5
>
>
> Need integrate communication with coordinator in transactions protocol:
> - reading transaction need request read ID from coordinator
> - after locks are acquired need request ID from coordinator
> - this ID should be passed to primary/backups and passed to update
> - after tx is committed need notify coordinator (note: need make sure that 
> this notification is processed in such way so that thread executed 
> transaction will see all his changes)
> Notes:
> - there are differences in prepare logic for 
> optimistic/pessimistic/serializable transactions, so most probably work with 
> coordinator should be implemented separately for these tx types
> - need support case when coordinator fails during prepare (need think is 
> necessary rollback and retry tx or switch to next assigned coordinator)



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

[jira] [Updated] (IGNITE-6709) Support mvcc filter for H2TreeIndex.findFirstOrLast

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6709:

Fix Version/s: (was: 2.4)
   2.5

> Support mvcc filter for H2TreeIndex.findFirstOrLast
> ---
>
> Key: IGNITE-6709
> URL: https://issues.apache.org/jira/browse/IGNITE-6709
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Semen Boikov
>Assignee: Igor Seliverstov
> Fix For: 2.5
>
>
> Need implement possibility to pass filter in findFirst/findLast (test already 
> exists CacheMvccSqlQueriesTest.testMaxMinTransactional).



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

[jira] [Updated] (IGNITE-5933) Integrate mvcc support in cache.getAll protocol

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5933:

Fix Version/s: (was: 2.4)
   2.5

> Integrate mvcc support in cache.getAll protocol
> ---
>
> Key: IGNITE-5933
> URL: https://issues.apache.org/jira/browse/IGNITE-5933
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Semen Boikov
> Fix For: 2.5
>
>
> Need integrate mvcc support in cache.getAll protocol:
> - request current ID and list of active txs from coordinator
> - pass this info in get requests and in local 'get'
> - notify coordinator after getAll completed



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

[jira] [Updated] (IGNITE-5934) Integrate mvcc support in sql query protocol

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5934:

Fix Version/s: (was: 2.4)
   2.5

> Integrate mvcc support in sql query protocol
> 
>
> Key: IGNITE-5934
> URL: https://issues.apache.org/jira/browse/IGNITE-5934
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Semen Boikov
>Assignee: Igor Seliverstov
> Fix For: 2.5
>
>
> Need integrate mvcc support in sql query protocol:
> - request current ID and list of active txs from coordinator
> - pass this info in sql requests and in sql queries
> - notify coordinator after query completed



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

[jira] [Updated] (IGNITE-6929) Preserve mvcc versions on index rebuild

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6929:

Fix Version/s: 2.5

> Preserve mvcc versions on index rebuild
> ---
>
> Key: IGNITE-6929
> URL: https://issues.apache.org/jira/browse/IGNITE-6929
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Igor Seliverstov
>Assignee: Alexander Paschenko
> Fix For: 2.5
>
>
> Currently we may loose next available version for an index row on index 
> rebuild 
> ({{org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.CacheDataStoreImpl#updateIndexes}})



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

[jira] [Closed] (IGNITE-5934) Integrate mvcc support in sql query protocol

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-5934.
---

> Integrate mvcc support in sql query protocol
> 
>
> Key: IGNITE-5934
> URL: https://issues.apache.org/jira/browse/IGNITE-5934
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Semen Boikov
>Assignee: Igor Seliverstov
> Fix For: 2.5
>
>
> Need integrate mvcc support in sql query protocol:
> - request current ID and list of active txs from coordinator
> - pass this info in sql requests and in sql queries
> - notify coordinator after query completed



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

[jira] [Closed] (IGNITE-6738) Support mvcc filter for local sql queries

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-6738.
---

> Support mvcc filter for local sql queries
> -
>
> Key: IGNITE-6738
> URL: https://issues.apache.org/jira/browse/IGNITE-6738
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Semen Boikov
>Assignee: Igor Seliverstov
> Fix For: 2.5
>
>
> Need receive/release mvcc version for queries with setLocal flag set, there 
> are already some tests in CacheMvccSqlQueriesTest.



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

[jira] [Updated] (IGNITE-6738) Support mvcc filter for local sql queries

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6738:

Fix Version/s: (was: 2.4)
   2.5

> Support mvcc filter for local sql queries
> -
>
> Key: IGNITE-6738
> URL: https://issues.apache.org/jira/browse/IGNITE-6738
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Semen Boikov
>Assignee: Igor Seliverstov
> Fix For: 2.5
>
>
> Need receive/release mvcc version for queries with setLocal flag set, there 
> are already some tests in CacheMvccSqlQueriesTest.



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

[jira] [Closed] (IGNITE-6929) Preserve mvcc versions on index rebuild

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-6929.
---

> Preserve mvcc versions on index rebuild
> ---
>
> Key: IGNITE-6929
> URL: https://issues.apache.org/jira/browse/IGNITE-6929
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Igor Seliverstov
>Assignee: Alexander Paschenko
> Fix For: 2.5
>
>
> Currently we may loose next available version for an index row on index 
> rebuild 
> ({{org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.CacheDataStoreImpl#updateIndexes}})



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

[jira] [Closed] (IGNITE-7272) SQL TX: incorrect row MVCC version override during CREATE INDEX

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-7272.
---

> SQL TX: incorrect row MVCC version override during CREATE INDEX
> ---
>
> Key: IGNITE-7272
> URL: https://issues.apache.org/jira/browse/IGNITE-7272
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.5
>
>
> Affected tests: {{DynamicIndexServerNodeFIlterBasicSelfTest}} and all 
> siblings.
> Root cause: see {{IgniteH2Indexing#dynamicIndexCreate}}
> {code}
> if (rowDesc.context().mvccEnabled())
> row.mvccVersion(1, MVCC_START_CNTR);
> {code}



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

[jira] [Closed] (IGNITE-7261) SQL TX: SELECT and DML operations must share the same MVCC version

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-7261.
---

> SQL TX: SELECT and DML operations must share the same MVCC version
> --
>
> Key: IGNITE-7261
> URL: https://issues.apache.org/jira/browse/IGNITE-7261
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
> Fix For: 2.5
>
>
> Need to make sure that all statements within TX share the same MVCC version 
> which is assigned on first read/write. 
> Need to add tests for this to confirm REPEATABLE_READ behavior.
> Note that regular implicit SELECTs outside transaction should only register 
> itself as "query" on MVCC coordinator, while SELECT inside TX must register 
> itself as both "query" and "tx".



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

[jira] [Closed] (IGNITE-7271) UPDATE and DELETE statements do not work through thin JDBC work in MVCC mode

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-7271.
---

> UPDATE and DELETE statements do not work through thin JDBC work in MVCC mode
> 
>
> Key: IGNITE-7271
> URL: https://issues.apache.org/jira/browse/IGNITE-7271
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc, sql
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
> Fix For: 2.5
>
>
> See relevant failures JDBC suite.



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

[jira] [Closed] (IGNITE-6935) SQL TX: Locking protocol for simple queries

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-6935.
---

> SQL TX: Locking protocol for simple queries
> ---
>
> Key: IGNITE-6935
> URL: https://issues.apache.org/jira/browse/IGNITE-6935
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
>  Labels: iep-3
> Fix For: 2.5
>
>
> We need to develop locking protocol for SQL queries. Design considerations:
> 1) Use {{GridNeaLockRequest|Response}} as a template for new messages
> 2) Cover only queries which doesn't require reduce stage (see server-side DML 
> optimization code, e.g. {{GridH2DmlRequest}}).
> 3) When next entry is found, try locking it. If it is already locked, then 
> register current TX as candidate in MVCC manager and go to the next row. 
> Other TXes will notify use when entries are released. Send a response when 
> all entries are locked.
> 4) Read entry version before locking and after. If they doesn't match (i.e. 
> concurrent modification occurred), then throw an exception.



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

[jira] [Closed] (IGNITE-7267) Fix transactional inserts.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-7267.
---

> Fix transactional inserts.
> --
>
> Key: IGNITE-7267
> URL: https://issues.apache.org/jira/browse/IGNITE-7267
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
> Fix For: 2.5
>
>
> Inserts optimisation (IGNITE-4490) breaks transactional inserts. Need to 
> rework the feature.



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

[jira] [Closed] (IGNITE-7280) SQL TX: improve JDBC test coverage

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-7280.
---

> SQL TX: improve JDBC test coverage
> --
>
> Key: IGNITE-7280
> URL: https://issues.apache.org/jira/browse/IGNITE-7280
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.5
>
>
> The following cases must be handled:
> 1) Single update stmt in TX
> 2) Multiple update stmts in TX
> 3) Changes to multiple caches in TX
> 4) Mix of both selects and updates (e.g. get data from select and then build 
> updates based on it)
> 5) Different operation types - INSERT, UPDATE, MERGE (take in count various 
> DML optimizations to ensure that as much code paths are covered as possible)
> 6) Batch updates
> 7) Joins (both co-located and distributed)
> 8) Different cache modes - PARTITIONED, REPLICATED
> 9) Different backup counts
> 10) Communication with client node vs communication with server node
> 11) Both implicit and explicit transactions



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

[jira] [Closed] (IGNITE-7183) SQL TX: Implicit transactions

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-7183.
---

> SQL TX: Implicit transactions
> -
>
> Key: IGNITE-7183
> URL: https://issues.apache.org/jira/browse/IGNITE-7183
> Project: Ignite
>  Issue Type: Task
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
>  Labels: iep-3, sql
> Fix For: 2.5
>
>
> Implicit transaction has to be started on any SQL update in a transactional 
> cache.



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

[jira] [Updated] (IGNITE-7249) SQL TX: Commit/rollback active TX before DDL statement processing

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7249:

Fix Version/s: (was: 2.4)
   2.5

> SQL TX: Commit/rollback active TX before DDL statement processing
> -
>
> Key: IGNITE-7249
> URL: https://issues.apache.org/jira/browse/IGNITE-7249
> Project: Ignite
>  Issue Type: Test
>  Components: sql
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
>  Labels: sql
> Fix For: 2.5
>
>
> Commit/rollback active TX before DDL statement processing



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

[jira] [Updated] (IGNITE-7271) UPDATE and DELETE statements do not work through thin JDBC work in MVCC mode

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7271:

Fix Version/s: (was: 2.4)
   2.5

> UPDATE and DELETE statements do not work through thin JDBC work in MVCC mode
> 
>
> Key: IGNITE-7271
> URL: https://issues.apache.org/jira/browse/IGNITE-7271
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc, sql
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
> Fix For: 2.5
>
>
> See relevant failures JDBC suite.



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

[jira] [Closed] (IGNITE-4192) SQL TX: JDBC driver support

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-4192.
---

> SQL TX: JDBC driver support
> ---
>
> Key: IGNITE-4192
> URL: https://issues.apache.org/jira/browse/IGNITE-4192
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>  Labels: iep-3
> Fix For: 2.5
>
>
> To support execution of DML and SELECT statements inside of a transaction 
> started from JDBC driver side.



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

[jira] [Updated] (IGNITE-6935) SQL TX: Locking protocol for simple queries

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6935:

Fix Version/s: (was: 2.4)
   2.5

> SQL TX: Locking protocol for simple queries
> ---
>
> Key: IGNITE-6935
> URL: https://issues.apache.org/jira/browse/IGNITE-6935
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
>  Labels: iep-3
> Fix For: 2.5
>
>
> We need to develop locking protocol for SQL queries. Design considerations:
> 1) Use {{GridNeaLockRequest|Response}} as a template for new messages
> 2) Cover only queries which doesn't require reduce stage (see server-side DML 
> optimization code, e.g. {{GridH2DmlRequest}}).
> 3) When next entry is found, try locking it. If it is already locked, then 
> register current TX as candidate in MVCC manager and go to the next row. 
> Other TXes will notify use when entries are released. Send a response when 
> all entries are locked.
> 4) Read entry version before locking and after. If they doesn't match (i.e. 
> concurrent modification occurred), then throw an exception.



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

[jira] [Updated] (IGNITE-4192) SQL TX: JDBC driver support

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4192:

Fix Version/s: (was: 2.4)
   2.5

> SQL TX: JDBC driver support
> ---
>
> Key: IGNITE-4192
> URL: https://issues.apache.org/jira/browse/IGNITE-4192
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>  Labels: iep-3
> Fix For: 2.5
>
>
> To support execution of DML and SELECT statements inside of a transaction 
> started from JDBC driver side.



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

[jira] [Commented] (IGNITE-6783) Create common mechanism for group training.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6783:


GitHub user artemmalykh opened a pull request:

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

IGNITE-6783: Create common mechanism for group training.



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

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

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

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


commit c4dbf2113d54976ed201171298174adc9a825eda
Author: Artem Malykh 
Date:   2017-10-27T17:03:31Z

IGNITE-6783: First steps.

commit ebb5b1f9c1a3d001b089b29c019acb80d02d8602
Author: Artem Malykh 
Date:   2017-10-27T17:10:59Z

IGNITE-6783: First steps[1].

commit 4af8bf1551d19830d35f3a36f7ad8a684c6260f9
Author: Artem Malykh 
Date:   2017-10-29T10:59:44Z

IGNITE-6783: First steps[2].

commit 6c4c77c262f9818142819f8b40a4855a62aabd4f
Author: Artem Malykh 
Date:   2017-10-29T12:42:43Z

IGNITE-6783: First steps[3].

commit dd8df49c4f04cf04e4cebdccdb0df72022e67886
Author: Artem Malykh 
Date:   2017-10-30T11:08:02Z

IGNITE-6783: First steps[4].

commit a335496869096ff0e23e9f6ba529afcbd26116a3
Author: Artem Malykh 
Date:   2017-10-30T13:58:14Z

IGNITE-6783: Cherrypicked some functions.

commit 7ed9ff9b2674042509b4d9620d406f13db9af357
Author: Artem Malykh 
Date:   2017-10-30T15:51:11Z

IGNITE-6783: First steps[5].

commit 6ef704d1d6846c14e2d7f1636c21269cd0843b9a
Author: Artem Malykh 
Date:   2017-10-31T15:40:42Z

IGNITE-6783: Workerschain is almost complete.

commit 8f6d713f2beeb7156c6fdfc977fceae18d9e8965
Author: Artem Malykh 
Date:   2017-11-01T13:05:36Z

IGNITE-6783: Monad-like workers chain.

commit e87f9b046f7fa45e0cdca2499f268baf527ca1c8
Author: Artem Malykh 
Date:   2017-11-01T15:49:39Z

IGNITE-6783: Enriched GroupTrainingCacheKey with data.

commit c9b818803e6b1f7d3ae4579afd9392bf9e34f039
Author: Artem Malykh 
Date:   2017-11-02T12:53:26Z

IGNITE-6783: Some fixes and test class.

commit c048bcc0088386bcdfe82ed7ae0c690be7c6c406
Author: Artem Malykh 
Date:   2017-11-08T18:15:22Z

IGNITE-6783: Intermidiate commit [uncompilable].

commit 58ea6b196fda151ccddda635ba18bc4ebd64aecd
Author: Artem Malykh 
Date:   2017-11-13T19:51:34Z

IGNITE-6783: WIP

commit f15e634eee17f322ee46e83f8d9d8a99e42c3e9e
Author: Artem Malykh 
Date:   2017-11-13T21:08:14Z

Merge branch 'master-apache' into ignite-6783

# Conflicts:
#   
modules/ml/src/main/java/org/apache/ignite/ml/math/distributed/CacheUtils.java
#   
modules/ml/src/main/java/org/apache/ignite/ml/math/functions/Functions.java
#   
modules/ml/src/main/java/org/apache/ignite/ml/math/functions/IgniteBinaryOperator.java

commit 915845f818467c5d7b9aaedfac5cf93b40ad8ae5
Author: Artem Malykh 
Date:   2017-11-13T21:08:30Z

IGNITE-6783: WIP

commit 77389db431642d8b84d92b122285f16036bc4669
Author: Artem Malykh 
Date:   2017-11-15T12:56:00Z

IGNITE-6783: Compilable version.

commit 813da2cce68e94741b27bfb6dd952cdc24985234
Author: Artem Malykh 
Date:   2017-11-15T17:19:54Z

IGNITE-6783: Initial tests for Destributed Trainer Workers Chain.

commit 1d4f90312a4849ee53df282d0d5483d73e5a45db
Author: Artem Malykh 
Date:   2017-11-16T18:02:24Z

IGNITE-6783: Started writing GroupTrainerTest.

commit f56a89fc911c74f1034e579a89f7f419681be0f2
Author: Artem Malykh 
Date:   2017-11-17T13:46:55Z

IGNITE-6783: GroupTrainerTest is compilable.

commit c37b274799c5fa2bcb1c657a3209aae9267f0a0a
Author: Artem Malykh 
Date:   2017-11-19T14:47:15Z

IGNITE-6783: WIP.

commit 8ed15f0b12f1f8fc0cd1aab948689ea6af4d76ba
Author: Artem Malykh 
Date:   2017-11-20T10:48:57Z

IGNITE-6783: WIP.

commit a38a47ac6966044e0db713037ffda53193306c70
Author: Artem Malykh 
Date:   2017-11-20T11:15:57Z

IGNITE-6783: WIP.

commit caefdb685638dd9fc3dcd50a1a13fb7ee526a371
Author: Artem Malykh 
Date:   2017-11-23T14:29:02Z

IGNITE-6882: WIP.

commit abc7ae0cdd272f17170c5e4f4ee88df13278957a
Author: Artem Malykh 
Date:   2017-11-23T15:36:12Z

IGNITE-6783: WIP.

commit a3ff2ad60358dcec55e901e87086bb3586489862
Author: Artem Malykh 
Date:   2017-11-23T15:36:48Z

IGNITE-7007: Added missing comments.

commit 814d0415faeff8736c0a40ee6681ba63518dcf55
Author: Artem Malykh 
Date:   

[jira] [Created] (IGNITE-7321) DML operation hangs in case exception is thrown from DHT enlist future

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-7321:
---

 Summary: DML operation hangs in case exception is thrown from DHT 
enlist future
 Key: IGNITE-7321
 URL: https://issues.apache.org/jira/browse/IGNITE-7321
 Project: Ignite
  Issue Type: Bug
  Components: sql
Reporter: Vladimir Ozerov
Assignee: Igor Seliverstov
 Fix For: 2.5


Root cause: when exception is thrown on primary node (e.g. double-insert or 
MVCC version conflict), primary future is completed, but exception doesn't seem 
to be propagated to near node.



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

[jira] [Assigned] (IGNITE-5954) Ignite Cache Failover: GridCacheAtomicNearRemoveFailureTest.testPutAndRemove fails

[Denis Mekhanikov (JIRA)]

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

Denis Mekhanikov reassigned IGNITE-5954:


Assignee: Denis Mekhanikov

> Ignite Cache Failover: GridCacheAtomicNearRemoveFailureTest.testPutAndRemove 
> fails
> --
>
> Key: IGNITE-5954
> URL: https://issues.apache.org/jira/browse/IGNITE-5954
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Denis Mekhanikov
>  Labels: MakeTeamcityGreenAgain
>
> Probably, it's broken after IGNITE-5272.



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

[jira] [Commented] (IGNITE-7304) Node discovery through AWS ELB

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7304:


GitHub user bbarin opened a pull request:

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

IGNITE-7304

I didn't figured out how to write integration tests without providing the 
AWS credentials.

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

$ git pull https://github.com/bbarin/ignite IGNITE-7304

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

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


commit f25c6ba62053c01bd06fc4afe166bdc4551901b3
Author: Bruno Barin 
Date:   2017-12-27T11:12:49Z

Added AWS ELB-based ip finder.




> Node discovery through AWS ELB
> --
>
> Key: IGNITE-7304
> URL: https://issues.apache.org/jira/browse/IGNITE-7304
> Project: Ignite
>  Issue Type: New Feature
>  Components: aws
>Affects Versions: 2.3
>Reporter: Bruno Barin
>
> Would be nice to have AWS ELB node discovery out of the box with Ignite.
> I've already have developed code to perform this and is working well in 
> production if you agree, i can PR my solution



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

[jira] [Updated] (IGNITE-7293) "BinaryObjectException: Cannot find schema for object with compact footer" when "not null" field is defined

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7293:

Component/s: binary

> "BinaryObjectException: Cannot find schema for object with compact footer" 
> when "not null" field is defined
> ---
>
> Key: IGNITE-7293
> URL: https://issues.apache.org/jira/browse/IGNITE-7293
> Project: Ignite
>  Issue Type: Bug
>  Components: binary, sql
>Affects Versions: 2.3
>Reporter: Kirill Shirokov
>Assignee: Vladimir Ozerov
> Fix For: 2.4
>
>
> If the following test:
> org.apache.ignite.internal.processors.cache.index.H2DynamicTableSelfTest#testAffinityKey
> is modified by adding "not null" constraint to "age" column definition in 
> Person2 table:
> {noformat}
> execute("CREATE TABLE \"Person2\" (\"id\" int, \"city\" 
> varchar," +
> " \"name\" varchar, \"surname\" varchar, \"age\" int not 
> null, PRIMARY KEY (\"id\", \"city\")) WITH " +
> 
> "wrap_key,wrap_value,\"template=cache,affinity_key='city'\"");}}
> {noformat}
> The test fails with the following stack trace during INSERT operation:
> {noformat}
> class org.apache.ignite.binary.BinaryObjectException: Cannot find schema for 
> object with compact footer [typeId=-1199546406, schemaId=0]
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2020)
>   at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.createSchema(BinaryObjectImpl.java:668)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldImpl.fieldOrder(BinaryFieldImpl.java:284)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldImpl.value(BinaryFieldImpl.java:106)
>   at 
> org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.fieldValue(QueryBinaryProperty.java:243)
>   at 
> org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.value(QueryBinaryProperty.java:139)
>   at 
> org.apache.ignite.internal.processors.query.QueryTypeDescriptorImpl.validateKeyAndValue(QueryTypeDescriptorImpl.java:512)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.rowToKeyValue(DmlStatementsProcessor.java:1031)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.doInsert(DmlStatementsProcessor.java:877)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.processDmlSelectResult(DmlStatementsProcessor.java:438)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:420)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:194)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:229)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1568)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1983)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1979)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2465)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1988)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1944)
>   at 
> org.apache.ignite.internal.processors.cache.index.H2DynamicTableSelfTest.checkAffinityKey(H2DynamicTableSelfTest.java:1375)
>   at 
> org.apache.ignite.internal.processors.cache.index.H2DynamicTableSelfTest.testAffinityKey(H2DynamicTableSelfTest.java:1318)
> {noformat}



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

[jira] [Commented] (IGNITE-7293) "BinaryObjectException: Cannot find schema for object with compact footer" when "not null" field is defined

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-7293:
-

Root cause: incorrect schema ID is used by builder when no fields are set.

> "BinaryObjectException: Cannot find schema for object with compact footer" 
> when "not null" field is defined
> ---
>
> Key: IGNITE-7293
> URL: https://issues.apache.org/jira/browse/IGNITE-7293
> Project: Ignite
>  Issue Type: Bug
>  Components: binary, sql
>Affects Versions: 2.3
>Reporter: Kirill Shirokov
>Assignee: Vladimir Ozerov
> Fix For: 2.4
>
>
> If the following test:
> org.apache.ignite.internal.processors.cache.index.H2DynamicTableSelfTest#testAffinityKey
> is modified by adding "not null" constraint to "age" column definition in 
> Person2 table:
> {noformat}
> execute("CREATE TABLE \"Person2\" (\"id\" int, \"city\" 
> varchar," +
> " \"name\" varchar, \"surname\" varchar, \"age\" int not 
> null, PRIMARY KEY (\"id\", \"city\")) WITH " +
> 
> "wrap_key,wrap_value,\"template=cache,affinity_key='city'\"");}}
> {noformat}
> The test fails with the following stack trace during INSERT operation:
> {noformat}
> class org.apache.ignite.binary.BinaryObjectException: Cannot find schema for 
> object with compact footer [typeId=-1199546406, schemaId=0]
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2020)
>   at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.createSchema(BinaryObjectImpl.java:668)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldImpl.fieldOrder(BinaryFieldImpl.java:284)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldImpl.value(BinaryFieldImpl.java:106)
>   at 
> org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.fieldValue(QueryBinaryProperty.java:243)
>   at 
> org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.value(QueryBinaryProperty.java:139)
>   at 
> org.apache.ignite.internal.processors.query.QueryTypeDescriptorImpl.validateKeyAndValue(QueryTypeDescriptorImpl.java:512)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.rowToKeyValue(DmlStatementsProcessor.java:1031)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.doInsert(DmlStatementsProcessor.java:877)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.processDmlSelectResult(DmlStatementsProcessor.java:438)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:420)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:194)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:229)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1568)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1983)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1979)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2465)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1988)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1944)
>   at 
> org.apache.ignite.internal.processors.cache.index.H2DynamicTableSelfTest.checkAffinityKey(H2DynamicTableSelfTest.java:1375)
>   at 
> org.apache.ignite.internal.processors.cache.index.H2DynamicTableSelfTest.testAffinityKey(H2DynamicTableSelfTest.java:1318)
> {noformat}



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

[jira] [Commented] (IGNITE-7293) "BinaryObjectException: Cannot find schema for object with compact footer" when "not null" field is defined

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7293:


GitHub user devozerov opened a pull request:

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

IGNITE-7293



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

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

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

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


commit 877218e0e185cdaf955293c92b16f8c2e1f391ef
Author: devozerov 
Date:   2017-12-27T11:07:56Z

Fixed incorrect schema ID calculation when not fields are set.




> "BinaryObjectException: Cannot find schema for object with compact footer" 
> when "not null" field is defined
> ---
>
> Key: IGNITE-7293
> URL: https://issues.apache.org/jira/browse/IGNITE-7293
> Project: Ignite
>  Issue Type: Bug
>  Components: binary, sql
>Affects Versions: 2.3
>Reporter: Kirill Shirokov
>Assignee: Vladimir Ozerov
> Fix For: 2.4
>
>
> If the following test:
> org.apache.ignite.internal.processors.cache.index.H2DynamicTableSelfTest#testAffinityKey
> is modified by adding "not null" constraint to "age" column definition in 
> Person2 table:
> {noformat}
> execute("CREATE TABLE \"Person2\" (\"id\" int, \"city\" 
> varchar," +
> " \"name\" varchar, \"surname\" varchar, \"age\" int not 
> null, PRIMARY KEY (\"id\", \"city\")) WITH " +
> 
> "wrap_key,wrap_value,\"template=cache,affinity_key='city'\"");}}
> {noformat}
> The test fails with the following stack trace during INSERT operation:
> {noformat}
> class org.apache.ignite.binary.BinaryObjectException: Cannot find schema for 
> object with compact footer [typeId=-1199546406, schemaId=0]
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2020)
>   at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.createSchema(BinaryObjectImpl.java:668)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldImpl.fieldOrder(BinaryFieldImpl.java:284)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldImpl.value(BinaryFieldImpl.java:106)
>   at 
> org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.fieldValue(QueryBinaryProperty.java:243)
>   at 
> org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.value(QueryBinaryProperty.java:139)
>   at 
> org.apache.ignite.internal.processors.query.QueryTypeDescriptorImpl.validateKeyAndValue(QueryTypeDescriptorImpl.java:512)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.rowToKeyValue(DmlStatementsProcessor.java:1031)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.doInsert(DmlStatementsProcessor.java:877)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.processDmlSelectResult(DmlStatementsProcessor.java:438)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:420)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:194)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:229)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1568)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1983)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1979)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2465)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1988)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1944)
>   at 
> org.apache.ignite.internal.processors.cache.index.H2DynamicTableSelfTest.checkAffinityKey(H2DynamicTableSelfTest.java:1375)
>   at 
> 

[jira] [Updated] (IGNITE-7293) "BinaryObjectException: Cannot find schema for object with compact footer" when "not null" field is defined

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7293:

Fix Version/s: 2.4

> "BinaryObjectException: Cannot find schema for object with compact footer" 
> when "not null" field is defined
> ---
>
> Key: IGNITE-7293
> URL: https://issues.apache.org/jira/browse/IGNITE-7293
> Project: Ignite
>  Issue Type: Bug
>  Components: binary, sql
>Affects Versions: 2.3
>Reporter: Kirill Shirokov
>Assignee: Vladimir Ozerov
> Fix For: 2.4
>
>
> If the following test:
> org.apache.ignite.internal.processors.cache.index.H2DynamicTableSelfTest#testAffinityKey
> is modified by adding "not null" constraint to "age" column definition in 
> Person2 table:
> {noformat}
> execute("CREATE TABLE \"Person2\" (\"id\" int, \"city\" 
> varchar," +
> " \"name\" varchar, \"surname\" varchar, \"age\" int not 
> null, PRIMARY KEY (\"id\", \"city\")) WITH " +
> 
> "wrap_key,wrap_value,\"template=cache,affinity_key='city'\"");}}
> {noformat}
> The test fails with the following stack trace during INSERT operation:
> {noformat}
> class org.apache.ignite.binary.BinaryObjectException: Cannot find schema for 
> object with compact footer [typeId=-1199546406, schemaId=0]
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2020)
>   at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.createSchema(BinaryObjectImpl.java:668)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldImpl.fieldOrder(BinaryFieldImpl.java:284)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldImpl.value(BinaryFieldImpl.java:106)
>   at 
> org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.fieldValue(QueryBinaryProperty.java:243)
>   at 
> org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.value(QueryBinaryProperty.java:139)
>   at 
> org.apache.ignite.internal.processors.query.QueryTypeDescriptorImpl.validateKeyAndValue(QueryTypeDescriptorImpl.java:512)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.rowToKeyValue(DmlStatementsProcessor.java:1031)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.doInsert(DmlStatementsProcessor.java:877)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.processDmlSelectResult(DmlStatementsProcessor.java:438)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:420)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:194)
>   at 
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:229)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1568)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1983)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1979)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2465)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1988)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1944)
>   at 
> org.apache.ignite.internal.processors.cache.index.H2DynamicTableSelfTest.checkAffinityKey(H2DynamicTableSelfTest.java:1375)
>   at 
> org.apache.ignite.internal.processors.cache.index.H2DynamicTableSelfTest.testAffinityKey(H2DynamicTableSelfTest.java:1318)
> {noformat}



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