[jira] [Commented] (IGNITE-2422) Unable to deserialize BinaryObjectBuilder

[Maksim Kozlov (JIRA)]

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

Maksim Kozlov commented on IGNITE-2422:
---

[~dmagda] yes.

> Unable to deserialize BinaryObjectBuilder
> -
>
> Key: IGNITE-2422
> URL: https://issues.apache.org/jira/browse/IGNITE-2422
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Maksim Kozlov
>  Labels: important
> Fix For: 2.0
>
> Attachments: ExampleNodeStartup.java
>
>
> Presently it's possible to serialize {{BinaryObjectBuilder}} but it will lead 
> to the errors at deserialization stage.
> After a brief investigation I see that this happens because neither 
> {{org.apache.ignite.binary.BinaryObjectBuilder}} nor 
> {{org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl}} 
> presents in {{META-INF/classnames.properties}} file.
> If you try to update 
> {{ignite/modules/core/src/main/resources/META-INF/classnames.properties}} by 
> building the project from scratch and copying-pasting generated content from 
> built {{classnames.properties}}, then you will still see that there are still 
> no entries for  {{org.apache.ignite.binary.BinaryObjectBuilder}} nor 
> {org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl}}.
> Looks like that {{ClassesGenerator}} misses these and other possible classes 
> by some reason.



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

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

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-3625 at 2/2/17 7:03 AM:
--

Taras, in general looks good for me, but when I started some my tests I got 
following exception:
{code}
Cache name cannot match the template "igfs-(-data|-meta)" because it 
is reserved for IGFS internal purposes.
{code}
And I have no idea what cache has wrong name. How about to print actual cache 
name in order user to be able quickly found wrong name and fix it?
The exception message could look like this:
{code}
Cache name 'igfs-meta' cannot match the template 
"igfs-(-data|-meta)" because it is reserved for IGFS internal 
purposes.
{code}

Please fix this and resubmit for review to me.



was (Author: kuaw26):
Taras, in general looks good for me, but when I started some my tests I got 
following exception:
{code}
Cache name cannot match the template "igfs-(-data|-meta)" because it 
is reserved for IGFS internal purposes.
{code}
And I have no idea what cache has wrong name. How about to print actual cache 
name in order user to be able quickly found wrong name and fix it?
The exception message could look like this:
{code}
Cache name '' cannot match the template "igfs-(-data|-meta)" 
because it is reserved for IGFS internal purposes.
{code}

Please fix this and resubmit for review to me.


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



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

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

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-3625:


Assignee: Taras Ledkov  (was: Alexey Kuznetsov)

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



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

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

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-3625:
--

Taras, in general looks good for me, but when I started some my tests I got 
following exception:
{code}
Cache name cannot match the template "igfs-(-data|-meta)" because it 
is reserved for IGFS internal purposes.
{code}
And I have no idea what cache has wrong name. How about to print actual cache 
name in order user to be able quickly found wrong name and fix it?
The exception message could look like this:
{code}
Cache name '' cannot match the template "igfs-(-data|-meta)" 
because it is reserved for IGFS internal purposes.
{code}


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



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

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

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-3625 at 2/2/17 6:45 AM:
--

Taras, in general looks good for me, but when I started some my tests I got 
following exception:
{code}
Cache name cannot match the template "igfs-(-data|-meta)" because it 
is reserved for IGFS internal purposes.
{code}
And I have no idea what cache has wrong name. How about to print actual cache 
name in order user to be able quickly found wrong name and fix it?
The exception message could look like this:
{code}
Cache name '' cannot match the template "igfs-(-data|-meta)" 
because it is reserved for IGFS internal purposes.
{code}

Please fix this and resubmit for review to me.



was (Author: kuaw26):
Taras, in general looks good for me, but when I started some my tests I got 
following exception:
{code}
Cache name cannot match the template "igfs-(-data|-meta)" because it 
is reserved for IGFS internal purposes.
{code}
And I have no idea what cache has wrong name. How about to print actual cache 
name in order user to be able quickly found wrong name and fix it?
The exception message could look like this:
{code}
Cache name '' cannot match the template "igfs-(-data|-meta)" 
because it is reserved for IGFS internal purposes.
{code}


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



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

[jira] [Created] (IGNITE-4643) JdbcDatabaseMetadata.getIndexInfo() method not working

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-4643:
---

 Summary: JdbcDatabaseMetadata.getIndexInfo() method not working
 Key: IGNITE-4643
 URL: https://issues.apache.org/jira/browse/IGNITE-4643
 Project: Ignite
  Issue Type: Bug
  Components: jdbc-driver
Affects Versions: 1.8
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
 Fix For: 1.9


{{JdbcDatabaseMetadata.getIndexInfo()}} method does not update metadata before 
creating result set. So if it's a first method invocation on this instance of 
{{JdbcDatabaseMetadata}}, it fails with NPE. Need to create tests and add 
{{updateMetaData()}} call in the beginning of the method.



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

[jira] [Updated] (IGNITE-4642) Support enforceJoinOrder flag for JDBC driver

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-4642:

Fix Version/s: 1.9

> Support enforceJoinOrder flag for JDBC driver
> -
>
> Key: IGNITE-4642
> URL: https://issues.apache.org/jira/browse/IGNITE-4642
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc-driver
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
> Fix For: 1.9
>
>
> There is a useful {{enforceJoinOrder}} flag on {{SqlFieldsQuery}}, but it's 
> not exposed on JDBC driver.



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

[jira] [Updated] (IGNITE-4642) Support enforceJoinOrder flag for JDBC driver

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-4642:

Affects Version/s: 1.8

> Support enforceJoinOrder flag for JDBC driver
> -
>
> Key: IGNITE-4642
> URL: https://issues.apache.org/jira/browse/IGNITE-4642
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc-driver
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
> Fix For: 1.9
>
>
> There is a useful {{enforceJoinOrder}} flag on {{SqlFieldsQuery}}, but it's 
> not exposed on JDBC driver.



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

[jira] [Created] (IGNITE-4642) Support enforceJoinOrder flag for JDBC driver

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-4642:
---

 Summary: Support enforceJoinOrder flag for JDBC driver
 Key: IGNITE-4642
 URL: https://issues.apache.org/jira/browse/IGNITE-4642
 Project: Ignite
  Issue Type: Improvement
  Components: jdbc-driver
Reporter: Valentin Kulichenko


There is a useful {{enforceJoinOrder}} flag on {{SqlFieldsQuery}}, but it's not 
exposed on JDBC driver.



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

[jira] [Commented] (IGNITE-4564) Ensure that builder approach is used for all setters in public API

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-4564:
--

Tests look fine.

> Ensure that builder approach is used for all setters in public API
> --
>
> Key: IGNITE-4564
> URL: https://issues.apache.org/jira/browse/IGNITE-4564
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Andrew Mashenkov
> Fix For: 2.0
>
>
> *Problem*
> We employed "builder" approach for some configuration classes:
> {code}
> class Configuration {
> Configuration setSomething(Something);
> }
> {code}
> This is very convenient for users. However, only part of our configs employ 
> this approach.
> *Task*
> Let's make sure that all other parts of our API follow this rule.



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

[jira] [Created] (IGNITE-4641) Refresh client attributes during reconnect

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-4641:
---

 Summary: Refresh client attributes during reconnect
 Key: IGNITE-4641
 URL: https://issues.apache.org/jira/browse/IGNITE-4641
 Project: Ignite
  Issue Type: Improvement
  Components: general
Affects Versions: 1.8
Reporter: Valentin Kulichenko
 Fix For: 1.9


Currently, when client disconnects and reconnects, it is forced to do that with 
the exact same set of attributes. However, there can be a component that wants 
to update attribute(s) in {{onDisconnected}} method, so that node reconnects 
with new attributes. To make sure this happens we need to refresh attributes 
before reconnecting. Most likely this should happen in 
{{TcpDiscoveryNode.clientReconnectNode()}} method which should acquire 
attributes via {{GridKernalContext.nodeAttributes()}}.

Typical use case is a security token that can expire. Security processor 
implementation may want to refresh the token in case of disconnect, but this is 
not possible now.



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

[jira] [Commented] (IGNITE-4523) Allow distributed SQL query execution over explicit set of partitions

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov commented on IGNITE-4523:
---

Finished adding support for multiple partitions in ScanQueries local mode.

> Allow distributed SQL query execution over explicit set of partitions
> -
>
> Key: IGNITE-4523
> URL: https://issues.apache.org/jira/browse/IGNITE-4523
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, SQL
>Affects Versions: 1.8
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
> Fix For: 1.9
>
>
> 3Currently distributed SQL query is executed on all nodes containing primary 
> partitions for a cache, sending map query requests on all nodes in grid.
> Sometimes we know in advance which partitions hold a data for query, on 
> example, in case of custom affinity function. 
> Therefore it's possible to reduce number of nodes receiving map query request 
> by providing explicit set of partitions, which will give significant 
> performance advantage and traffic reduction in case of very large clusters.
> Internally we already have such functionality, so the only necessary thing is 
> to provide public API for what.



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

[jira] [Commented] (IGNITE-4564) Ensure that builder approach is used for all setters in public API

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-4564:
--

All done.
Waiting for TC tests.

> Ensure that builder approach is used for all setters in public API
> --
>
> Key: IGNITE-4564
> URL: https://issues.apache.org/jira/browse/IGNITE-4564
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Andrew Mashenkov
> Fix For: 2.0
>
>
> *Problem*
> We employed "builder" approach for some configuration classes:
> {code}
> class Configuration {
> Configuration setSomething(Something);
> }
> {code}
> This is very convenient for users. However, only part of our configs employ 
> this approach.
> *Task*
> Let's make sure that all other parts of our API follow this rule.



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

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

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-4617:
-

It seems some refactoring of the {{BinaryObject}} and {{BinaryObjectImpl}} is 
going to be needed to implement these methods in an effective way. I'm going to 
get rid of validity checks on every call and only check validity once on 
{{BinaryObject}} instance creation.

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



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

[jira] [Commented] (IGNITE-2422) Unable to deserialize BinaryObjectBuilder

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-2422:
-

[~dreamx], could you revert your current changes and fix the bug as Vladimir 
suggests?

> Unable to deserialize BinaryObjectBuilder
> -
>
> Key: IGNITE-2422
> URL: https://issues.apache.org/jira/browse/IGNITE-2422
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Maksim Kozlov
>  Labels: important
> Fix For: 2.0
>
> Attachments: ExampleNodeStartup.java
>
>
> Presently it's possible to serialize {{BinaryObjectBuilder}} but it will lead 
> to the errors at deserialization stage.
> After a brief investigation I see that this happens because neither 
> {{org.apache.ignite.binary.BinaryObjectBuilder}} nor 
> {{org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl}} 
> presents in {{META-INF/classnames.properties}} file.
> If you try to update 
> {{ignite/modules/core/src/main/resources/META-INF/classnames.properties}} by 
> building the project from scratch and copying-pasting generated content from 
> built {{classnames.properties}}, then you will still see that there are still 
> no entries for  {{org.apache.ignite.binary.BinaryObjectBuilder}} nor 
> {org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl}}.
> Looks like that {{ClassesGenerator}} misses these and other possible classes 
> by some reason.



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

[jira] [Commented] (IGNITE-4106) SQL: parallelize sql queries over cache local partitions

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-4106:
--

Local queries is fixed.
Waiting for TC tests.

> SQL: parallelize sql queries over cache local partitions
> 
>
> Key: IGNITE-4106
> URL: https://issues.apache.org/jira/browse/IGNITE-4106
> Project: Ignite
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 1.7
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>  Labels: performance
> Fix For: 1.9
>
> Attachments: 1node-4thread.jfr, 4node-1thread.jfr
>
>
> If we run SQL query on cache partitioned over several cluster nodes, it will 
> be split into several queries running in parallel. But really we will have 
> one thread per query on each node.
> So, for now, to improve SQL query performance we need to run more Ignite 
> instances or split caches manually.
> It seems to be better to split local SQL queries over cache partitions, so we 
> would be able to parallelize SQL query on every single node and utilize CPU 
> more efficiently.



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

[jira] [Commented] (IGNITE-4511) Set QueryIndexType.SORTED by default for an index

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-4511:
--

TC tests look fine.

> Set QueryIndexType.SORTED by default for an index 
> --
>
> Key: IGNITE-4511
> URL: https://issues.apache.org/jira/browse/IGNITE-4511
> Project: Ignite
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 1.7
>Reporter: Steve Hostettler
>Assignee: Andrew Mashenkov
>Priority: Minor
>  Labels: fulltext, sql
> Fix For: 2.0
>
>
> The code snippet below creates a index of type FULL TEXT which much slower 
> and that I do not need;
> QueryIndex idx1 = new QueryIndex();
> LinkedHashMap idxFlds1 = new LinkedHashMap<>();
> idxFlds1.put("field1", true);
> idxFlds1.put("field2", true);
> idx1.setFields(idxFlds1);
> idxs.add(idx1);
> To avoid this I must explicitly set
> idx1.setIndexType(QueryIndexType.SORTED);
> This is because with the above code snippet, the Index Type is null and that 
> null is interpreted as FULL TEXT in  GridQueryProcessor.java 
>  if (idx.getIndexType() == QueryIndexType.SORTED || idx.getIndexType() == 
> QueryIndexType.GEOSPATIAL) { 
>  
> } else { 
> assert idx.getIndexType() == QueryIndexType.FULLTEXT; 
> for (String field : idx.getFields().keySet()) { 
> String alias = aliases.get(field); 
> if (alias != null) 
> field = alias; 
> d.addFieldToTextIndex(field); 
> } 
> } 



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

[jira] [Commented] (IGNITE-4046) C++: Support DML API

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4046:


Github user asfgit closed the pull request at:

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


> C++: Support DML API
> 
>
> Key: IGNITE-4046
> URL: https://issues.apache.org/jira/browse/IGNITE-4046
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.8
>Reporter: Denis Magda
>Assignee: Igor Sapego
>  Labels: roadmap
> Fix For: 1.9
>
>
> Ignite's Java component will provide support for DML soon (IGNITE-2294). At 
> she same time DML will be supported at the level of ODBC and JDBC drivers.
> As the next step we should include the similar functionality into Ignite.C++ 
> by doing the following:
> - Implement DML API;
> - Enhance {{query_example.cpp}} by doing INSERTs instead of cache.puts and 
> adding UPDATE and DELETE operation examples.
> - Add documentation to Ignite.C++ readme.io covering the feature. Most like 
> most of the content can be take from the general documentation when this 
> ticket IGNITE-4018 is ready.



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

[jira] [Comment Edited] (IGNITE-3430) .NET: Run Ignite transactions via standard TransactionScope API

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-3430 at 2/1/17 3:11 PM:


Found a problem with calling {{TransactionProxyImpl.prepare()}}: tests hang 
sometimes on transactional operations.
Some work to resolve this is being done in IGNITE-3477 for 2.0.

Feature disabled in master, all tests marked with {{[Ignore]}}.

More details on test failure:
* Reproduces most often in 
{{CachePartitionedTest.TestTransactionScopeAllOperations}}
* Does not reproduce in CacheLocalTest
* Does not reproduce in Optimistic mode
* Does not reproduce with 1 and 2 nodes, only with 3 nodes.


was (Author: ptupitsyn):
Found a problem with calling {{TransactionProxyImpl.prepare()}}: tests hang 
sometimes on transactional operations.
Some work to resolve this is being done in IGNITE-3477 for 2.0.

Feature disabled in master, all tests marked with {{[Ignore]}}.

More details on test failure:
* Reproduces most often in 
{{CachePartitionedTest.TestTransactionScopeAllOperations}}
* Does not reproduce in CacheLocalTest
* Does not reproduce (?) in Optimistic mode
* Does not reproduce with 1 and 2 nodes, only with 3 nodes.

> .NET: Run Ignite transactions via standard TransactionScope API
> ---
>
> Key: IGNITE-3430
> URL: https://issues.apache.org/jira/browse/IGNITE-3430
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .net, roadmap
> Fix For: 1.9
>
> Attachments: threads_report.txt
>
>
> Automatically enlist Ignite operations in current transaction scope when 
> applicable (when cache is transactional).
> https://msdn.microsoft.com/en-us/library/system.transactions.transactionscope(v=vs.110).aspx
> https://msdn.microsoft.com/en-us/library/ee818754(v=vs.110).aspx
> This boils down to implementing {{IEnlistmentNotification}} and calling 
> {{Transaction.Current.Enlist}} when doing transactional operations.
> Later we may want to implement {{ISinglePhaseNotification}} which is an 
> optimization.



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

[jira] [Updated] (IGNITE-3430) .NET: Run Ignite transactions via standard TransactionScope API

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-3430:
---
Attachment: threads_report.txt

> .NET: Run Ignite transactions via standard TransactionScope API
> ---
>
> Key: IGNITE-3430
> URL: https://issues.apache.org/jira/browse/IGNITE-3430
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .net, roadmap
> Fix For: 1.9
>
> Attachments: threads_report.txt
>
>
> Automatically enlist Ignite operations in current transaction scope when 
> applicable (when cache is transactional).
> https://msdn.microsoft.com/en-us/library/system.transactions.transactionscope(v=vs.110).aspx
> https://msdn.microsoft.com/en-us/library/ee818754(v=vs.110).aspx
> This boils down to implementing {{IEnlistmentNotification}} and calling 
> {{Transaction.Current.Enlist}} when doing transactional operations.
> Later we may want to implement {{ISinglePhaseNotification}} which is an 
> optimization.



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

[jira] [Comment Edited] (IGNITE-3430) .NET: Run Ignite transactions via standard TransactionScope API

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-3430 at 2/1/17 3:08 PM:


Found a problem with calling {{TransactionProxyImpl.prepare()}}: tests hang 
sometimes on transactional operations.
Some work to resolve this is being done in IGNITE-3477 for 2.0.

Feature disabled in master, all tests marked with {{[Ignore]}}.

More details on test failure:
* Reproduces most often in 
{{CachePartitionedTest.TestTransactionScopeAllOperations}}
* Does not reproduce in CacheLocalTest
* Does not reproduce (?) in Optimistic mode
* Does not reproduce with 1 and 2 nodes, only with 3 nodes.


was (Author: ptupitsyn):
Found a problem with calling {{TransactionProxyImpl.prepare()}}: tests hang 
sometimes on transactional operations.
Some work to resolve this is being done in IGNITE-3477 for 2.0.

Feature disabled in master, all tests marked with {{[Ignore]}}.

More details on test failure:
* Reproduces most often in 
{{CachePartitionedTest.TestTransactionScopeAllOperations}}
* Does not reproduce in CacheLocalTest
* Does not reproduce (?) in Optimistic mode

> .NET: Run Ignite transactions via standard TransactionScope API
> ---
>
> Key: IGNITE-3430
> URL: https://issues.apache.org/jira/browse/IGNITE-3430
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .net, roadmap
> Fix For: 1.9
>
> Attachments: threads_report.txt
>
>
> Automatically enlist Ignite operations in current transaction scope when 
> applicable (when cache is transactional).
> https://msdn.microsoft.com/en-us/library/system.transactions.transactionscope(v=vs.110).aspx
> https://msdn.microsoft.com/en-us/library/ee818754(v=vs.110).aspx
> This boils down to implementing {{IEnlistmentNotification}} and calling 
> {{Transaction.Current.Enlist}} when doing transactional operations.
> Later we may want to implement {{ISinglePhaseNotification}} which is an 
> optimization.



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

[jira] [Updated] (IGNITE-4620) CPP: Add documentation for DML

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4620:

Fix Version/s: (was: 2.0)
   1.9

> CPP: Add documentation for DML
> --
>
> Key: IGNITE-4620
> URL: https://issues.apache.org/jira/browse/IGNITE-4620
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, platforms
>Affects Versions: 1.8
>Reporter: Igor Sapego
>  Labels: cpp, documentation
> Fix For: 1.9
>
>
> We need to add documentation for DML support once its implemented in C++ 
> client.



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

[jira] [Commented] (IGNITE-4046) C++: Support DML API

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4046:
-

Ok for me. 

> C++: Support DML API
> 
>
> Key: IGNITE-4046
> URL: https://issues.apache.org/jira/browse/IGNITE-4046
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.8
>Reporter: Denis Magda
>Assignee: Igor Sapego
>  Labels: roadmap
> Fix For: 1.9
>
>
> Ignite's Java component will provide support for DML soon (IGNITE-2294). At 
> she same time DML will be supported at the level of ODBC and JDBC drivers.
> As the next step we should include the similar functionality into Ignite.C++ 
> by doing the following:
> - Implement DML API;
> - Enhance {{query_example.cpp}} by doing INSERTs instead of cache.puts and 
> adding UPDATE and DELETE operation examples.
> - Add documentation to Ignite.C++ readme.io covering the feature. Most like 
> most of the content can be take from the general documentation when this 
> ticket IGNITE-4018 is ready.



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

[jira] [Comment Edited] (IGNITE-3430) .NET: Run Ignite transactions via standard TransactionScope API

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-3430 at 2/1/17 2:51 PM:


Found a problem with calling {{TransactionProxyImpl.prepare()}}: tests hang 
sometimes on transactional operations.
Some work to resolve this is being done in IGNITE-3477 for 2.0.

Feature disabled in master, all tests marked with {{[Ignore]}}.

More details on test failure:
* Reproduces most often in 
{{CachePartitionedTest.TestTransactionScopeAllOperations}}
* Does not reproduce in CacheLocalTest
* Does not reproduce (?) in Optimistic mode


was (Author: ptupitsyn):
Found a problem with calling {{TransactionProxyImpl.prepare()}}: tests hang 
sometimes.
Some work to resolve this is being done in IGNITE-3477 for 2.0.

Feature disabled in master, all tests marked with {{[Ignore]}}.

> .NET: Run Ignite transactions via standard TransactionScope API
> ---
>
> Key: IGNITE-3430
> URL: https://issues.apache.org/jira/browse/IGNITE-3430
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .net, roadmap
> Fix For: 1.9
>
>
> Automatically enlist Ignite operations in current transaction scope when 
> applicable (when cache is transactional).
> https://msdn.microsoft.com/en-us/library/system.transactions.transactionscope(v=vs.110).aspx
> https://msdn.microsoft.com/en-us/library/ee818754(v=vs.110).aspx
> This boils down to implementing {{IEnlistmentNotification}} and calling 
> {{Transaction.Current.Enlist}} when doing transactional operations.
> Later we may want to implement {{ISinglePhaseNotification}} which is an 
> optimization.



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

[jira] [Updated] (IGNITE-4631) Node starts with incorrect QueryEntity configuration

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov updated IGNITE-4631:
---
Fix Version/s: 1.9

> Node starts with incorrect QueryEntity configuration
> 
>
> Key: IGNITE-4631
> URL: https://issues.apache.org/jira/browse/IGNITE-4631
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Reporter: Sergey Kalashnikov
>Assignee: Sergey Kalashnikov
>Priority: Minor
> Fix For: 1.9
>
> Attachments: QueryEntityCaseMismatchTest.java
>
>
> When QueryEntity.keyFields property is used to specify compound key fields, 
> it is possible to set the field names in wrong register.
> The node would start normally, but for SQL queries requesting key fields the 
> resultset contains nulls in corresponding columns.
> The query processor internally fails to tell the key field from value field 
> in this case.
> Note that for optimized marshaller, the keyFields aren't taken into account 
> and queries return valid data. 
> I believe the node shall not start with such configuration at all.
> See the attached test that reproduces the case.



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

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

[Igor Sapego (JIRA)]

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

Igor Sapego reassigned IGNITE-4617:
---

Assignee: Igor Sapego

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



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

[jira] [Reopened] (IGNITE-4631) Node starts with incorrect QueryEntity configuration

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov reopened IGNITE-4631:

  Assignee: Sergey Kalashnikov  (was: Vladimir Ozerov)

> Node starts with incorrect QueryEntity configuration
> 
>
> Key: IGNITE-4631
> URL: https://issues.apache.org/jira/browse/IGNITE-4631
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Reporter: Sergey Kalashnikov
>Assignee: Sergey Kalashnikov
>Priority: Minor
> Attachments: QueryEntityCaseMismatchTest.java
>
>
> When QueryEntity.keyFields property is used to specify compound key fields, 
> it is possible to set the field names in wrong register.
> The node would start normally, but for SQL queries requesting key fields the 
> resultset contains nulls in corresponding columns.
> The query processor internally fails to tell the key field from value field 
> in this case.
> Note that for optimized marshaller, the keyFields aren't taken into account 
> and queries return valid data. 
> I believe the node shall not start with such configuration at all.
> See the attached test that reproduces the case.



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

[jira] [Assigned] (IGNITE-4618) CPP: Do not start JVM if it is already started

[Igor Sapego (JIRA)]

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

Igor Sapego reassigned IGNITE-4618:
---

Assignee: (was: Igor Sapego)

> CPP: Do not start JVM if it is already started
> --
>
> Key: IGNITE-4618
> URL: https://issues.apache.org/jira/browse/IGNITE-4618
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
> Fix For: 1.9
>
>
> *Problem*
> Consider the following scenario:
> 1) User's app started JVM in the process somehow.
> 2) User tries to start the node. 
> 3) Result: exception.
> *Solution*
> We need to check if JVM is already started. If yes - then try re-using. Note 
> that we are likely to fail at this point because user might forgot to pass 
> proper Ignite classpath. In this case we must throw extremely sensible 
> exception, so that user understand how to fix the problem right away. 
> E.g.: "Failed to start Ignite node with already started JVM due to invalid 
> classpath; please add the following JARs to the classpath: [PATH TO 
> IGNITE_HOME JARS]".



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

[jira] [Updated] (IGNITE-4638) Share current DDL schema and pending DDL operations with joining nodes

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4638:

Description: 
1) Basically there are three operation types which must be shared with joining 
node:
- {{COMPLETED}} - shared as snapshot of current schema state;
- {{ACKED}} - shared as operation requests;
- {{INITED}} - shared as operation requests.

2) Completed and acked operations are applied right away.

3) Inited operations are not applied immediately. Instead, joined node sends 
{{VERIFY_INIT_OPS}} request to coordinator. Operations are applied only after 
coordinator confirmed that they were not rejected on {{INIT}} stage.

It seems that to achieve p.3 nodes will have to keep a kind of history of 
rejected operations which is not very desirable, but do we really have other 
options?

  was:
1) Basically there are three operation types which must be shared with joining 
node:
- {{COMPLETED}} - shared as snapshot of current schema state;
- {{ACKED}} - shared as operation requests;
- {{INITED}} - shared as operation requests.

2) Completed and acked operations are applied right away.

3) Inited operations are not applied immediately. Instead, joined node sends 
{{VERIFY_INIT_OPS}} request to coordinator. Operations are applied only after 
coordinator confirmed that they were not rejected on {{INIT}} stage.

It seems that to achieve p.3 nodes will have to keep a kind of history of 
rejected operations which is not desirable.


> Share current DDL schema and pending DDL operations with joining nodes
> --
>
> Key: IGNITE-4638
> URL: https://issues.apache.org/jira/browse/IGNITE-4638
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> 1) Basically there are three operation types which must be shared with 
> joining node:
> - {{COMPLETED}} - shared as snapshot of current schema state;
> - {{ACKED}} - shared as operation requests;
> - {{INITED}} - shared as operation requests.
> 2) Completed and acked operations are applied right away.
> 3) Inited operations are not applied immediately. Instead, joined node sends 
> {{VERIFY_INIT_OPS}} request to coordinator. Operations are applied only after 
> coordinator confirmed that they were not rejected on {{INIT}} stage.
> It seems that to achieve p.3 nodes will have to keep a kind of history of 
> rejected operations which is not very desirable, but do we really have other 
> options?



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

[jira] [Updated] (IGNITE-4638) Share current DDL schema and pending DDL operations with joining nodes

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4638:

Description: 
1) Basically there are three operation types which must be shared with joining 
node:
- {{COMPLETED}} - shared as snapshot of current schema state;
- {{ACKED}} - shared as operation requests;
- {{INITED}} - shared as operation requests.

2) Completed and acked operations are applied right away.

3) Inited operations are not applied immediately. Instead, joined node sends 
{{VERIFY_INIT_OPS}} request to coordinator. Operations are applied only after 
coordinator confirmed that they were not rejected on {{INIT}} stage.

It seems that to achieve p.3 nodes will have to keep a kind of history of 
rejected operations which is not desirable.

  was:
1) Basically there are three operation types which must be shared with joining 
node:
- Completed - shared as snapshot of current schema state;
- Acked - shared as operation requests;
- Inited ops - shared as operation requests.

2) Completed and acked operations are applied right away.

3) Inited operations are not applied immediately. Instead, joined node sends 
{{VERIFY_INIT_OPS}} request to coordinator. Operations are applied only after 
coordinator confirmed that they were not rejected on {{INIT}} stage.

It seems that to achieve p.3 nodes will have to keep a kind of history of 
rejected operations which is not desirable.


> Share current DDL schema and pending DDL operations with joining nodes
> --
>
> Key: IGNITE-4638
> URL: https://issues.apache.org/jira/browse/IGNITE-4638
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> 1) Basically there are three operation types which must be shared with 
> joining node:
> - {{COMPLETED}} - shared as snapshot of current schema state;
> - {{ACKED}} - shared as operation requests;
> - {{INITED}} - shared as operation requests.
> 2) Completed and acked operations are applied right away.
> 3) Inited operations are not applied immediately. Instead, joined node sends 
> {{VERIFY_INIT_OPS}} request to coordinator. Operations are applied only after 
> coordinator confirmed that they were not rejected on {{INIT}} stage.
> It seems that to achieve p.3 nodes will have to keep a kind of history of 
> rejected operations which is not desirable.



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

[jira] [Updated] (IGNITE-4638) Share current DDL schema and pending DDL operations with joining nodes

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4638:

Description: 
1) Basically there are three operation types which must be shared with joining 
node:
- Completed - shared as snapshot of current schema state;
- Acked - shared as operation requests;
- Inited ops - shared as operation requests.

2) Completed and acked operations are applied right away.

3) Inited operations are not applied immediately. Instead, joined node sends 
{{VERIFY_INIT_OPS}} request to coordinator. Operations are applied only after 
coordinator confirmed that they were not rejected on {{INIT}} stage.

It seems that to achieve p.3 nodes will have to keep a kind of history of 
rejected operations which is not desirable.

  was:
Design considerations:
1) Should be implemented through custom discovery data mechanism. 
2) Probably it makes sense to add version to every DDL change. E.g. (topVer + 
local coordinator ctr). It will help us to avoid duplicated operations in case 
of some unforseen races.


> Share current DDL schema and pending DDL operations with joining nodes
> --
>
> Key: IGNITE-4638
> URL: https://issues.apache.org/jira/browse/IGNITE-4638
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> 1) Basically there are three operation types which must be shared with 
> joining node:
> - Completed - shared as snapshot of current schema state;
> - Acked - shared as operation requests;
> - Inited ops - shared as operation requests.
> 2) Completed and acked operations are applied right away.
> 3) Inited operations are not applied immediately. Instead, joined node sends 
> {{VERIFY_INIT_OPS}} request to coordinator. Operations are applied only after 
> coordinator confirmed that they were not rejected on {{INIT}} stage.
> It seems that to achieve p.3 nodes will have to keep a kind of history of 
> rejected operations which is not desirable.



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

[jira] [Updated] (IGNITE-4637) Implement DDL operation completion protocol

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4637:

Description: 
*Normal flow*
1) When participating node completed operation, it sends 
{{PARTICIPANT_FINISHED}} message to coordinator.
2) When coordinator collected responses from all participants, it notifies 
originator with {{FINISHED}} request.
3) Originator responds coordinator with {{FINISHED_ACK}} message.
4) Coordinator responds to all originators with {{PARTICIPANT_FINISHED_ACK}} 
message.

*Originator leave*
1) Coordinator marks originator as "notified", and sends 
{{PARTICIPANT_FINISHED_ACK}} message to participants after all 
{{PARTICIPANT_FINISHED}} are collected.

*Participant leave*
1) Coordinator marks participant as "finished" and no longer waits for any 
responses from it.

*Coordinator leave*
1) The oldest node among remaining participants is elected as new coordinator.
2) Coordinator *polls* explicitly operation state from participants with 
{{IS_PARTICIPANT_FINISHED}} message.
3) Participants re-send {{PARTICIPANT_FINISHED}} message to new coordinator.
4) If all participant nodes have left, originator feature is completed with 
error.

  was:
*Normal flow*
1) When participating node completed operation, it sends 
{{PARTICIPANT_FINISHED}} message to coordinator.
2) When coordinator collected responses from all participants, it notifies 
originator with {{FINISHED}} request.
3) Originator responds coordinator with {{FINISHED_ACK}} message.
4) Coordinator responds to all originators with {{PARTICIPANT_FINISHED_ACK}} 
message.

*Originator leave*
1) Coordinator marks originator as "notified", and sends 
{{PARTICIPANT_FINISHED_ACK}} message to participants after all 
{{PARTICIPANT_FINISHED}} are collected.

*Participant leave*
1) Coordinator marks participant as "finished" and no longer waits for any 
responses from it.

*Coordinator leave*
1) The oldest node among remaining participants is elected as new coordinator.
2) Other participants re-send {{PARTICIPANT_FINISHED}} message to new 
coordinator.
3) If it was the last participating node, then originator must be informed 
about the failure. It means that client must be aware of participating nodes. 
Otherwise it's future will never be completed.







> Implement DDL operation completion protocol
> ---
>
> Key: IGNITE-4637
> URL: https://issues.apache.org/jira/browse/IGNITE-4637
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> *Normal flow*
> 1) When participating node completed operation, it sends 
> {{PARTICIPANT_FINISHED}} message to coordinator.
> 2) When coordinator collected responses from all participants, it notifies 
> originator with {{FINISHED}} request.
> 3) Originator responds coordinator with {{FINISHED_ACK}} message.
> 4) Coordinator responds to all originators with {{PARTICIPANT_FINISHED_ACK}} 
> message.
> *Originator leave*
> 1) Coordinator marks originator as "notified", and sends 
> {{PARTICIPANT_FINISHED_ACK}} message to participants after all 
> {{PARTICIPANT_FINISHED}} are collected.
> *Participant leave*
> 1) Coordinator marks participant as "finished" and no longer waits for any 
> responses from it.
> *Coordinator leave*
> 1) The oldest node among remaining participants is elected as new coordinator.
> 2) Coordinator *polls* explicitly operation state from participants with 
> {{IS_PARTICIPANT_FINISHED}} message.
> 3) Participants re-send {{PARTICIPANT_FINISHED}} message to new coordinator.
> 4) If all participant nodes have left, originator feature is completed with 
> error.



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4633:

Description: 
Design considerations:
1) Create generic DDL custom discovery message pair - {{INIT}} and {{ACK}} 
messages - which will hold concrete DDL commands.
2) Originator must generate unique message ID to be able to track it later.
3) Coordinator calculates all participants through affinity API and adds them 
to message.
4) {{INIT}} message goes through the ring and:performs some fast preliminary 
checks if necessary and collects error; in particular it may verify whether 
schema change is valid to allow for fail-fast client notification.;
5) If at least one error occurs during {{INIT}} stage, originator may throw 
exception to the user.
6) {{ACK}} message schedules asynchronous execution of the command.

  was:
Design considerations:
1) Create generic DDL custom discovery message pair - {{INIT}} and {{ACK}} 
messages - which will hold concrete DDL commands:
2) {{INIT}} message goes through the ring and:
- Collect IDs of all participating nodes;
- Perform some fast preliminary checks if necessary;
- Collect errors if needed;

3) If at least one error occur - throw exception on a originator node;
4) If all is OK - send {{ACK}} message.
5) {{ACK}} message initiates actual operation. No-op at the moment.
6) Finally, originator node is provided with the list of participating nodes.


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



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

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

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov commented on IGNITE-4196:


[~vozerov], could you please review?

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



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

[jira] [Updated] (IGNITE-4639) Share information about DDL schema changes with existing node

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4639:

Issue Type: Task  (was: Sub-task)
Parent: (was: IGNITE-4565)

> Share information about DDL schema changes with existing node
> -
>
> Key: IGNITE-4639
> URL: https://issues.apache.org/jira/browse/IGNITE-4639
> Project: Ignite
>  Issue Type: Task
>  Components: cache, SQL
>Reporter: Vladimir Ozerov
>
> Some existing nodes will not participate in DDL operations. Namely:
> 1) Client nodes;
> 2) Server nodes without affected cache;
> 3) Nodes which joined before finish of {{INIT}} phase of particular DDL 
> operation. At this point coordinator doesn't know whether this operation will 
> be started or not, so information about it is not shared with joining node.
> We need to inform this nodes about started DDL operations somehow, ensuring 
> proper ordering. Custom discovery message is good candidate, but 
> unfortunately it doesn't work for client nodes.
> Possible solution:
> 1) Initial state is shared through custom discovery data.
> 2) Completed updates are broadcasted from coordinator node to all other nodes 
> through {{DDL_CHANGE}} messages. 
> 3) {{DDL_CHANGE}} messages must be processed in a single thread to avoid 
> concurrency issues. 
> 4) If {{DDL_CHANGE}} message arrived before custom discovery data (i.e. we 
> have a race between IO and discovery flows), it's processing should be 
> delayed until custom disco data is processed.



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

[jira] [Updated] (IGNITE-4639) Share information about DDL schema changes with existing node

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4639:

Fix Version/s: (was: 2.0)

> Share information about DDL schema changes with existing node
> -
>
> Key: IGNITE-4639
> URL: https://issues.apache.org/jira/browse/IGNITE-4639
> Project: Ignite
>  Issue Type: Task
>  Components: cache, SQL
>Reporter: Vladimir Ozerov
>
> Some existing nodes will not participate in DDL operations. Namely:
> 1) Client nodes;
> 2) Server nodes without affected cache;
> 3) Nodes which joined before finish of {{INIT}} phase of particular DDL 
> operation. At this point coordinator doesn't know whether this operation will 
> be started or not, so information about it is not shared with joining node.
> We need to inform this nodes about started DDL operations somehow, ensuring 
> proper ordering. Custom discovery message is good candidate, but 
> unfortunately it doesn't work for client nodes.
> Possible solution:
> 1) Initial state is shared through custom discovery data.
> 2) Completed updates are broadcasted from coordinator node to all other nodes 
> through {{DDL_CHANGE}} messages. 
> 3) {{DDL_CHANGE}} messages must be processed in a single thread to avoid 
> concurrency issues. 
> 4) If {{DDL_CHANGE}} message arrived before custom discovery data (i.e. we 
> have a race between IO and discovery flows), it's processing should be 
> delayed until custom disco data is processed.



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

[jira] [Closed] (IGNITE-4639) Share information about DDL schema changes with existing node

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-4639.
---

> Share information about DDL schema changes with existing node
> -
>
> Key: IGNITE-4639
> URL: https://issues.apache.org/jira/browse/IGNITE-4639
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache, SQL
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> Some existing nodes will not participate in DDL operations. Namely:
> 1) Client nodes;
> 2) Server nodes without affected cache;
> 3) Nodes which joined before finish of {{INIT}} phase of particular DDL 
> operation. At this point coordinator doesn't know whether this operation will 
> be started or not, so information about it is not shared with joining node.
> We need to inform this nodes about started DDL operations somehow, ensuring 
> proper ordering. Custom discovery message is good candidate, but 
> unfortunately it doesn't work for client nodes.
> Possible solution:
> 1) Initial state is shared through custom discovery data.
> 2) Completed updates are broadcasted from coordinator node to all other nodes 
> through {{DDL_CHANGE}} messages. 
> 3) {{DDL_CHANGE}} messages must be processed in a single thread to avoid 
> concurrency issues. 
> 4) If {{DDL_CHANGE}} message arrived before custom discovery data (i.e. we 
> have a race between IO and discovery flows), it's processing should be 
> delayed until custom disco data is processed.



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

[jira] [Resolved] (IGNITE-4639) Share information about DDL schema changes with existing node

[Vladimir Ozerov (JIRA)]

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

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

> Share information about DDL schema changes with existing node
> -
>
> Key: IGNITE-4639
> URL: https://issues.apache.org/jira/browse/IGNITE-4639
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache, SQL
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> Some existing nodes will not participate in DDL operations. Namely:
> 1) Client nodes;
> 2) Server nodes without affected cache;
> 3) Nodes which joined before finish of {{INIT}} phase of particular DDL 
> operation. At this point coordinator doesn't know whether this operation will 
> be started or not, so information about it is not shared with joining node.
> We need to inform this nodes about started DDL operations somehow, ensuring 
> proper ordering. Custom discovery message is good candidate, but 
> unfortunately it doesn't work for client nodes.
> Possible solution:
> 1) Initial state is shared through custom discovery data.
> 2) Completed updates are broadcasted from coordinator node to all other nodes 
> through {{DDL_CHANGE}} messages. 
> 3) {{DDL_CHANGE}} messages must be processed in a single thread to avoid 
> concurrency issues. 
> 4) If {{DDL_CHANGE}} message arrived before custom discovery data (i.e. we 
> have a race between IO and discovery flows), it's processing should be 
> delayed until custom disco data is processed.



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

[jira] [Updated] (IGNITE-4640) .NET: Improve performance of dynamically generated code

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-4640:
---
Description: 
Ignite uses dynamically generated delegates to avoid constly reflection calls 
on hot paths (invoking user-defined generic methods, constructors, etc) - see 
{{DelegateTypeDescriptor}} and {{DelegateConverter}} classes.

Investigate whether adding the following attributes to our assemblies affects 
performance:
{code}
[assembly: AllowPartiallyTrustedCallers]
[assembly: SecurityTransparent]
[assembly: 
SecurityRules(SecurityRuleSet.Level2,SkipVerificationInFullTrust=true)]
{code}

See
http://stackoverflow.com/questions/13431573/dynamicmethod-is-much-slower-than-compiled-il-function/14297080#14297080

  was:
Ignite uses dynamically generated delegates to avoid constly reflection calls 
on hot paths (invoking user-defined generic methods, constructors, etc) - see 
{{DelegateTypeDescriptor}} and {{DelegateConverter}} classes.

Investigate whethe adding the following attributes to our assemblies affects 
performance:
{code}
[assembly: AllowPartiallyTrustedCallers]
[assembly: SecurityTransparent]
[assembly: 
SecurityRules(SecurityRuleSet.Level2,SkipVerificationInFullTrust=true)]
{code}

See
http://stackoverflow.com/questions/13431573/dynamicmethod-is-much-slower-than-compiled-il-function/14297080#14297080


> .NET: Improve performance of dynamically generated code
> ---
>
> Key: IGNITE-4640
> URL: https://issues.apache.org/jira/browse/IGNITE-4640
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.8
>Reporter: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET, perfomance
> Fix For: 2.1
>
>
> Ignite uses dynamically generated delegates to avoid constly reflection calls 
> on hot paths (invoking user-defined generic methods, constructors, etc) - see 
> {{DelegateTypeDescriptor}} and {{DelegateConverter}} classes.
> Investigate whether adding the following attributes to our assemblies affects 
> performance:
> {code}
> [assembly: AllowPartiallyTrustedCallers]
> [assembly: SecurityTransparent]
> [assembly: 
> SecurityRules(SecurityRuleSet.Level2,SkipVerificationInFullTrust=true)]
> {code}
> See
> http://stackoverflow.com/questions/13431573/dynamicmethod-is-much-slower-than-compiled-il-function/14297080#14297080



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

[jira] [Created] (IGNITE-4640) .NET: Improve performance of dynamically generated code

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4640:
--

 Summary: .NET: Improve performance of dynamically generated code
 Key: IGNITE-4640
 URL: https://issues.apache.org/jira/browse/IGNITE-4640
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 1.8
Reporter: Pavel Tupitsyn
Priority: Minor
 Fix For: 2.1


Ignite uses dynamically generated delegates to avoid constly reflection calls 
on hot paths (invoking user-defined generic methods, constructors, etc) - see 
{{DelegateTypeDescriptor}} and {{DelegateConverter}} classes.

Investigate whethe adding the following attributes to our assemblies affects 
performance:
{code}
[assembly: AllowPartiallyTrustedCallers]
[assembly: SecurityTransparent]
[assembly: 
SecurityRules(SecurityRuleSet.Level2,SkipVerificationInFullTrust=true)]
{code}

See
http://stackoverflow.com/questions/13431573/dynamicmethod-is-much-slower-than-compiled-il-function/14297080#14297080



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

[jira] [Commented] (IGNITE-4046) C++: Support DML API

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-4046:
-

[~vozerov], I decided to not remove this function as there are already tests 
for it, but I've moved it to {{BinaryUtils}} to hide it from public API. Is it 
OK?

> C++: Support DML API
> 
>
> Key: IGNITE-4046
> URL: https://issues.apache.org/jira/browse/IGNITE-4046
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.8
>Reporter: Denis Magda
>Assignee: Igor Sapego
>  Labels: roadmap
> Fix For: 1.9
>
>
> Ignite's Java component will provide support for DML soon (IGNITE-2294). At 
> she same time DML will be supported at the level of ODBC and JDBC drivers.
> As the next step we should include the similar functionality into Ignite.C++ 
> by doing the following:
> - Implement DML API;
> - Enhance {{query_example.cpp}} by doing INSERTs instead of cache.puts and 
> adding UPDATE and DELETE operation examples.
> - Add documentation to Ignite.C++ readme.io covering the feature. Most like 
> most of the content can be take from the general documentation when this 
> ticket IGNITE-4018 is ready.



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

[jira] [Comment Edited] (IGNITE-3430) .NET: Run Ignite transactions via standard TransactionScope API

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-3430 at 2/1/17 1:05 PM:


Found a problem with calling {{TransactionProxyImpl.prepare()}}: tests hang 
sometimes.
Some work to resolve this is being done in IGNITE-3477 for 2.0.

Feature disabled in master, all tests marked with {{[Ignore]}}.


was (Author: ptupitsyn):
Found a problem with calling {{TransactionProxyImpl.prepare()}}: tests hang 
sometimes.
Some work to resolve this is being done in IGNITE-3477 for 2.0.

> .NET: Run Ignite transactions via standard TransactionScope API
> ---
>
> Key: IGNITE-3430
> URL: https://issues.apache.org/jira/browse/IGNITE-3430
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .net, roadmap
> Fix For: 1.9
>
>
> Automatically enlist Ignite operations in current transaction scope when 
> applicable (when cache is transactional).
> https://msdn.microsoft.com/en-us/library/system.transactions.transactionscope(v=vs.110).aspx
> https://msdn.microsoft.com/en-us/library/ee818754(v=vs.110).aspx
> This boils down to implementing {{IEnlistmentNotification}} and calling 
> {{Transaction.Current.Enlist}} when doing transactional operations.
> Later we may want to implement {{ISinglePhaseNotification}} which is an 
> optimization.



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4196:


GitHub user skalashnikov opened a pull request:

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

IGNITE-4196 Added means to specify port for H2 debug console



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

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

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

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


commit ebc293b14f3eed3fc563f3fc11e3d1ecd85f55e9
Author: skalashnikov 
Date:   2017-02-01T13:02:36Z

IGNITE-4196 Added means to specify port for H2 debug console




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



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

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

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-3878:
--

[~yzhdanov],
Yes, continuous query filter triggered on primary and backup nodes. 

[~dreamx],
You can add remote filter in CQ and check that it will be invoked once on 
primary node (with isPrimary == true) and several times on backup nodes (with 
isBackup == true).


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



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

[jira] [Closed] (IGNITE-4612) Minor code cleanup

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov closed IGNITE-4612.


> Minor code cleanup
> --
>
> Key: IGNITE-4612
> URL: https://issues.apache.org/jira/browse/IGNITE-4612
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 1.8
>Reporter: Alexander Menshikov
>Assignee: Alexander Menshikov
>Priority: Trivial
> Fix For: 1.8
>
>
> This issue about trivial code cleanup.
> 1) Cleanup unused imports/variable/argument.
> 2) Rename ignored exception to "ignored".
> 3) ...
> 4) PROFIT :)



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

[jira] [Commented] (IGNITE-3920) Hadoop: remove PayloadAware interface.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-3920:
-

Branch {{ignite-3920-1}}.

> Hadoop: remove PayloadAware interface.
> --
>
> Key: IGNITE-3920
> URL: https://issues.apache.org/jira/browse/IGNITE-3920
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> When IGNITE-3376 is ready, we will be able to execute {{PROXY}} operations 
> directly from {{IgfsImpl}}. It means that we no longer need 
> {{HadoopPayloadAware}} interface, and we no longer need to pass {{IgfsPaths}} 
> to the client. 
> Let's remove them all together.



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

[jira] [Assigned] (IGNITE-4046) C++: Support DML API

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-4046:
---

Assignee: Igor Sapego  (was: Vladimir Ozerov)

> C++: Support DML API
> 
>
> Key: IGNITE-4046
> URL: https://issues.apache.org/jira/browse/IGNITE-4046
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.8
>Reporter: Denis Magda
>Assignee: Igor Sapego
>  Labels: roadmap
> Fix For: 1.9
>
>
> Ignite's Java component will provide support for DML soon (IGNITE-2294). At 
> she same time DML will be supported at the level of ODBC and JDBC drivers.
> As the next step we should include the similar functionality into Ignite.C++ 
> by doing the following:
> - Implement DML API;
> - Enhance {{query_example.cpp}} by doing INSERTs instead of cache.puts and 
> adding UPDATE and DELETE operation examples.
> - Add documentation to Ignite.C++ readme.io covering the feature. Most like 
> most of the content can be take from the general documentation when this 
> ticket IGNITE-4018 is ready.



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

[jira] [Commented] (IGNITE-4046) C++: Support DML API

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4046:
-

Igor,
I think it makes sense to remove {{GetDataHashCode}} method from 
{{binary_type.h}} and move it to {{binary_array_identity_resolver.cpp}}.
The rest looks good to me.

> C++: Support DML API
> 
>
> Key: IGNITE-4046
> URL: https://issues.apache.org/jira/browse/IGNITE-4046
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.8
>Reporter: Denis Magda
>Assignee: Vladimir Ozerov
>  Labels: roadmap
> Fix For: 1.9
>
>
> Ignite's Java component will provide support for DML soon (IGNITE-2294). At 
> she same time DML will be supported at the level of ODBC and JDBC drivers.
> As the next step we should include the similar functionality into Ignite.C++ 
> by doing the following:
> - Implement DML API;
> - Enhance {{query_example.cpp}} by doing INSERTs instead of cache.puts and 
> adding UPDATE and DELETE operation examples.
> - Add documentation to Ignite.C++ readme.io covering the feature. Most like 
> most of the content can be take from the general documentation when this 
> ticket IGNITE-4018 is ready.



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

[jira] [Commented] (IGNITE-3920) Hadoop: remove PayloadAware interface.

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-3920:
--

[~vozerov], please merge the patch.

> Hadoop: remove PayloadAware interface.
> --
>
> Key: IGNITE-3920
> URL: https://issues.apache.org/jira/browse/IGNITE-3920
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> When IGNITE-3376 is ready, we will be able to execute {{PROXY}} operations 
> directly from {{IgfsImpl}}. It means that we no longer need 
> {{HadoopPayloadAware}} interface, and we no longer need to pass {{IgfsPaths}} 
> to the client. 
> Let's remove them all together.



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

[jira] [Assigned] (IGNITE-3920) Hadoop: remove PayloadAware interface.

[Taras Ledkov (JIRA)]

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

Taras Ledkov reassigned IGNITE-3920:


Assignee: Taras Ledkov  (was: Vladimir Ozerov)

> Hadoop: remove PayloadAware interface.
> --
>
> Key: IGNITE-3920
> URL: https://issues.apache.org/jira/browse/IGNITE-3920
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> When IGNITE-3376 is ready, we will be able to execute {{PROXY}} operations 
> directly from {{IgfsImpl}}. It means that we no longer need 
> {{HadoopPayloadAware}} interface, and we no longer need to pass {{IgfsPaths}} 
> to the client. 
> Let's remove them all together.



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

[jira] [Commented] (IGNITE-3430) .NET: Run Ignite transactions via standard TransactionScope API

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-3430:


Found a problem with calling {{TransactionProxyImpl.prepare()}}: tests hang 
sometimes.
Some work to resolve this is being done in IGNITE-3477 for 2.0.

> .NET: Run Ignite transactions via standard TransactionScope API
> ---
>
> Key: IGNITE-3430
> URL: https://issues.apache.org/jira/browse/IGNITE-3430
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .net, roadmap
> Fix For: 1.9
>
>
> Automatically enlist Ignite operations in current transaction scope when 
> applicable (when cache is transactional).
> https://msdn.microsoft.com/en-us/library/system.transactions.transactionscope(v=vs.110).aspx
> https://msdn.microsoft.com/en-us/library/ee818754(v=vs.110).aspx
> This boils down to implementing {{IEnlistmentNotification}} and calling 
> {{Transaction.Current.Enlist}} when doing transactional operations.
> Later we may want to implement {{ISinglePhaseNotification}} which is an 
> optimization.



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

[jira] [Reopened] (IGNITE-3430) .NET: Run Ignite transactions via standard TransactionScope API

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reopened IGNITE-3430:

  Assignee: Pavel Tupitsyn

> .NET: Run Ignite transactions via standard TransactionScope API
> ---
>
> Key: IGNITE-3430
> URL: https://issues.apache.org/jira/browse/IGNITE-3430
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .net, roadmap
> Fix For: 1.9
>
>
> Automatically enlist Ignite operations in current transaction scope when 
> applicable (when cache is transactional).
> https://msdn.microsoft.com/en-us/library/system.transactions.transactionscope(v=vs.110).aspx
> https://msdn.microsoft.com/en-us/library/ee818754(v=vs.110).aspx
> This boils down to implementing {{IEnlistmentNotification}} and calling 
> {{Transaction.Current.Enlist}} when doing transactional operations.
> Later we may want to implement {{ISinglePhaseNotification}} which is an 
> optimization.



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

[jira] [Commented] (IGNITE-4444) Extend .NET plugin API to interact with Java

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-:


Merged to ignite-2.0

> Extend .NET plugin API to interact with Java
> 
>
> Key: IGNITE-
> URL: https://issues.apache.org/jira/browse/IGNITE-
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Plugin authors should be able to call Java part of the plugin via some 
> {{IPluginContext}} API.



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

[jira] [Commented] (IGNITE-4444) Extend .NET plugin API to interact with Java

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-:


Github user ptupitsyn closed the pull request at:

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


> Extend .NET plugin API to interact with Java
> 
>
> Key: IGNITE-
> URL: https://issues.apache.org/jira/browse/IGNITE-
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Plugin authors should be able to call Java part of the plugin via some 
> {{IPluginContext}} API.



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

[jira] [Assigned] (IGNITE-4444) Extend .NET plugin API to interact with Java

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-:
---

Assignee: Pavel Tupitsyn  (was: Vladimir Ozerov)

> Extend .NET plugin API to interact with Java
> 
>
> Key: IGNITE-
> URL: https://issues.apache.org/jira/browse/IGNITE-
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Plugin authors should be able to call Java part of the plugin via some 
> {{IPluginContext}} API.



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

[jira] [Commented] (IGNITE-4444) Extend .NET plugin API to interact with Java

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-:
-

Pavel,

LGTM.

> Extend .NET plugin API to interact with Java
> 
>
> Key: IGNITE-
> URL: https://issues.apache.org/jira/browse/IGNITE-
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Vladimir Ozerov
>  Labels: .NET
> Fix For: 2.0
>
>
> Plugin authors should be able to call Java part of the plugin via some 
> {{IPluginContext}} API.



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

[jira] [Updated] (IGNITE-4621) Hang on broadcast when BinaryUtils.FIELDS_SORTED_ORDER == true

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-4621:
-
Fix Version/s: 1.9

> Hang on broadcast when BinaryUtils.FIELDS_SORTED_ORDER == true
> --
>
> Key: IGNITE-4621
> URL: https://issues.apache.org/jira/browse/IGNITE-4621
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Critical
> Fix For: 1.9
>
>
> Reproducer:
> {noformat}
> assert BinaryUtils.FIELDS_SORTED_ORDER; // should be set by ENV 
> variable.
> startGrids(GRIDS);
> //awaitPartitionMapExchange();
> Ignite ignite = grid(0);
> ignite.compute(ignite.cluster().forServers()).broadcast(new 
> JustAnotherCallable()); // hang here
> stopAllGrids();
> {noformat}
> where cache configuration is 
> {noformat}
> ...
> cfg.setMarshaller(new BinaryMarshaller());
> final BinaryConfiguration binaryCfg = new BinaryConfiguration();
> binaryCfg.setCompactFooter(false);
> cfg.setBinaryConfiguration(binaryCfg);
> ...
> {noformat}
> Stacktrace:
> {noformat}
>   - parking to wait for  <0x00076fce15c8> (a 
> org.apache.ignite.internal.util.future.GridFutureAdapter$ChainFuture)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:158)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:118)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$25.op(GridCacheAdapter.java:2369)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$25.op(GridCacheAdapter.java:2355)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4385)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.invoke0(GridCacheAdapter.java:2355)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.invoke(GridCacheAdapter.java:2326)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.invoke(IgniteCacheProxy.java:1814)
>   at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:585)
>   at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$3.addMeta(CacheObjectBinaryProcessorImpl.java:218)
>   at 
> org.apache.ignite.internal.binary.BinaryContext.updateMetadata(BinaryContext.java:1215)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:753)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:205)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:146)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:200)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:146)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:133)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteObject(BinaryWriterExImpl.java:459)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.writeObjectField(BinaryWriterExImpl.java:1092)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.write(BinaryFieldAccessor.java:623)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:782)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:205)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:146)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:133)
>   at 
> org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:239)
>   at 
> org.apache.ignite.internal.binary.BinaryMarshaller.marshal0(BinaryMarshaller.java:83)
>   at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:58)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteU

[jira] [Resolved] (IGNITE-4621) Hang on broadcast when BinaryUtils.FIELDS_SORTED_ORDER == true

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov resolved IGNITE-4621.
--
Resolution: Fixed

> Hang on broadcast when BinaryUtils.FIELDS_SORTED_ORDER == true
> --
>
> Key: IGNITE-4621
> URL: https://issues.apache.org/jira/browse/IGNITE-4621
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Critical
> Fix For: 1.9
>
>
> Reproducer:
> {noformat}
> assert BinaryUtils.FIELDS_SORTED_ORDER; // should be set by ENV 
> variable.
> startGrids(GRIDS);
> //awaitPartitionMapExchange();
> Ignite ignite = grid(0);
> ignite.compute(ignite.cluster().forServers()).broadcast(new 
> JustAnotherCallable()); // hang here
> stopAllGrids();
> {noformat}
> where cache configuration is 
> {noformat}
> ...
> cfg.setMarshaller(new BinaryMarshaller());
> final BinaryConfiguration binaryCfg = new BinaryConfiguration();
> binaryCfg.setCompactFooter(false);
> cfg.setBinaryConfiguration(binaryCfg);
> ...
> {noformat}
> Stacktrace:
> {noformat}
>   - parking to wait for  <0x00076fce15c8> (a 
> org.apache.ignite.internal.util.future.GridFutureAdapter$ChainFuture)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:158)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:118)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$25.op(GridCacheAdapter.java:2369)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$25.op(GridCacheAdapter.java:2355)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4385)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.invoke0(GridCacheAdapter.java:2355)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.invoke(GridCacheAdapter.java:2326)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.invoke(IgniteCacheProxy.java:1814)
>   at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:585)
>   at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$3.addMeta(CacheObjectBinaryProcessorImpl.java:218)
>   at 
> org.apache.ignite.internal.binary.BinaryContext.updateMetadata(BinaryContext.java:1215)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:753)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:205)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:146)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:200)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:146)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:133)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteObject(BinaryWriterExImpl.java:459)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.writeObjectField(BinaryWriterExImpl.java:1092)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.write(BinaryFieldAccessor.java:623)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:782)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:205)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:146)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:133)
>   at 
> org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:239)
>   at 
> org.apache.ignite.internal.binary.BinaryMarshaller.marshal0(BinaryMarshaller.java:83)
>   at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:58)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.marshal(Ignite

[jira] [Updated] (IGNITE-4569) Create SQL index locally

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko updated IGNITE-4569:

Description: 
Design considerations:
1) Cache is *not blocked* for updates during index creation.

2) DDL thread flow:
- Create index and add it to some collection of pending indexes;
- Iterate over all cache entries and add them one by one;
- Once iteration finished - add index to the table;

3) Cache thread flow:
- If there are any pending index, then propagate update to the index.

Be careful with put/remove interleaving.

  was:
Design considerations:
1) Cache is *not blocked* for updates during index creation.
2) DDL thread flow:
- Create index and add it to some collection of pending indexes;
- Iterate over all cache entries and add them one by one;
- Once iteration finished - add index to the table;
3) Cache thread flow:
- If there are any pending index, then propagate update to the index.

Be careful with put/remove interleaving.


> Create SQL index locally
> 
>
> Key: IGNITE-4569
> URL: https://issues.apache.org/jira/browse/IGNITE-4569
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache, SQL
>Reporter: Alexander Paschenko
> Fix For: 2.0
>
>
> Design considerations:
> 1) Cache is *not blocked* for updates during index creation.
> 2) DDL thread flow:
> - Create index and add it to some collection of pending indexes;
> - Iterate over all cache entries and add them one by one;
> - Once iteration finished - add index to the table;
> 3) Cache thread flow:
> - If there are any pending index, then propagate update to the index.
> Be careful with put/remove interleaving.



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

[jira] [Assigned] (IGNITE-4570) Handle CREATE INDEX statements

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-4570:
---

Assignee: Alexander Paschenko  (was: Vladimir Ozerov)

Alex,
Test coverage is unacceptable. Please make sure that parsing result is correct, 
i.e. that all command parts are extracted correctly.

> Handle CREATE INDEX statements
> --
>
> Key: IGNITE-4570
> URL: https://issues.apache.org/jira/browse/IGNITE-4570
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 1.9
>
>
> Parse and execute CREATE INDEX boiling down to IgniteCacheEx.createQueryIndex 
> introduced by IGNITE-4566



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

[jira] [Updated] (IGNITE-4570) Handle CREATE INDEX statements

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4570:

Fix Version/s: (was: 1.9)
   2.0

> Handle CREATE INDEX statements
> --
>
> Key: IGNITE-4570
> URL: https://issues.apache.org/jira/browse/IGNITE-4570
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 2.0
>
>
> Parse and execute CREATE INDEX boiling down to IgniteCacheEx.createQueryIndex 
> introduced by IGNITE-4566



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

[jira] [Assigned] (IGNITE-4570) Handle CREATE INDEX statements

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko reassigned IGNITE-4570:
---

Assignee: Vladimir Ozerov  (was: Alexander Paschenko)

> Handle CREATE INDEX statements
> --
>
> Key: IGNITE-4570
> URL: https://issues.apache.org/jira/browse/IGNITE-4570
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Alexander Paschenko
>Assignee: Vladimir Ozerov
> Fix For: 1.9
>
>
> Parse and execute CREATE INDEX boiling down to IgniteCacheEx.createQueryIndex 
> introduced by IGNITE-4566



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

[jira] [Commented] (IGNITE-4626) GridDhtPartitionTopologyImpl refactoring

[Yakov Zhdanov (JIRA)]

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

Yakov Zhdanov commented on IGNITE-4626:
---

Here are my comments:
# there is concurrency issue - you do not do volatile writes
# I would change part2nodes to List[]
# Apply proper copy on write pattern

> GridDhtPartitionTopologyImpl refactoring
> 
>
> Key: IGNITE-4626
> URL: https://issues.apache.org/jira/browse/IGNITE-4626
> Project: Ignite
>  Issue Type: Task
>Reporter: Konstantin Dudkov
>Assignee: Konstantin Dudkov
>
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#nodes(int,
>  org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion)
> Need to refactor this method to use Object[] - partId->List



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

[jira] [Commented] (IGNITE-4571) Optimize futVer generations

[Yakov Zhdanov (JIRA)]

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

Yakov Zhdanov commented on IGNITE-4571:
---

Here are my comments
# use ThreadLocal.initialValue() for initialization
# Do not use Long! Only primitive.
# move nextAtomicFutureVersion() to version manager
# add multithreaded tests for version
# add new tests to suite
# fix formatting and headers

> Optimize futVer generations
> ---
>
> Key: IGNITE-4571
> URL: https://issues.apache.org/jira/browse/IGNITE-4571
> Project: Ignite
>  Issue Type: Task
>Reporter: Konstantin Dudkov
>Assignee: Konstantin Dudkov
>
> 1. Optimize futVer generations - need to get rid of using CacheVersion in 
> favor of long value.
> Example
> org/apache/ignite/internal/processors/cache/distributed/dht/atomic/GridNearAtomicUpdateFuture.java:633
> org.apache.ignite.internal.processors.cache.version.GridCacheVersionManager#next(org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion)
> Result:
> Need to replace cache version with random long (int), check compatibility and 
> messages sizes before & after and benchmark.
> How:
> Use thread local random. Generate ID on atomic future store and switch it to 
> putIfAbsent().



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

[jira] [Assigned] (IGNITE-4565) Support CREATE INDEX DDL statements

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-4565:
---

Assignee: (was: Alexander Paschenko)

> Support CREATE INDEX DDL statements
> ---
>
> Key: IGNITE-4565
> URL: https://issues.apache.org/jira/browse/IGNITE-4565
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache, SQL
>Reporter: Alexander Paschenko
> Fix For: 2.0
>
>
> We need to implement support for dynamic {{CREATE INDEX}} and {{DROP INDEX}} 
> invocations.
> Design document: 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=67640367



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

[jira] [Created] (IGNITE-4639) Share information about DDL schema changes with existing node

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4639:
---

 Summary: Share information about DDL schema changes with existing 
node
 Key: IGNITE-4639
 URL: https://issues.apache.org/jira/browse/IGNITE-4639
 Project: Ignite
  Issue Type: Sub-task
Reporter: Vladimir Ozerov
 Fix For: 2.0


Some existing nodes will not participate in DDL operations. Namely:
1) Client nodes;
2) Server nodes without affected cache;
3) Nodes which joined before finish of {{INIT}} phase of particular DDL 
operation. At this point coordinator doesn't know whether this operation will 
be started or not, so information about it is not shared with joining node.

We need to inform this nodes about started DDL operations somehow, ensuring 
proper ordering. Custom discovery message is good candidate, but unfortunately 
it doesn't work for client nodes.

Possible solution:
1) Initial state is shared through custom discovery data.
2) Completed updates are broadcasted from coordinator node to all other nodes 
through {{DDL_CHANGE}} messages. 
3) {{DDL_CHANGE}} messages must be processed in a single thread to avoid 
concurrency issues. 
4) If {{DDL_CHANGE}} message arrived before custom discovery data (i.e. we have 
a race between IO and discovery flows), it's processing should be delayed until 
custom disco data is processed.



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

[jira] [Updated] (IGNITE-4565) Support CREATE INDEX DDL statements

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4565:

Description: 
We need to implement support for dynamic {{CREATE INDEX}} and {{DROP INDEX}} 
invocations.
Design document: 
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=67640367

> Support CREATE INDEX DDL statements
> ---
>
> Key: IGNITE-4565
> URL: https://issues.apache.org/jira/browse/IGNITE-4565
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache, SQL
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 2.0
>
>
> We need to implement support for dynamic {{CREATE INDEX}} and {{DROP INDEX}} 
> invocations.
> Design document: 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=67640367



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

[jira] [Updated] (IGNITE-4565) Support CREATE INDEX DDL statements

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4565:

Fix Version/s: (was: 1.9)
   2.0

> Support CREATE INDEX DDL statements
> ---
>
> Key: IGNITE-4565
> URL: https://issues.apache.org/jira/browse/IGNITE-4565
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache, SQL
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 2.0
>
>
> We need to implement support for dynamic {{CREATE INDEX}} and {{DROP INDEX}} 
> invocations.
> Design document: 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=67640367



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

[jira] [Created] (IGNITE-4638) Share current DDL schema and pending DDL operations with joining nodes

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4638:
---

 Summary: Share current DDL schema and pending DDL operations with 
joining nodes
 Key: IGNITE-4638
 URL: https://issues.apache.org/jira/browse/IGNITE-4638
 Project: Ignite
  Issue Type: Sub-task
  Components: SQL
Reporter: Vladimir Ozerov
 Fix For: 2.0


Design considerations:
1) Should be implemented through custom discovery data mechanism. 
2) Probably it makes sense to add version to every DDL change. E.g. (topVer + 
local coordinator ctr). It will help us to avoid duplicated operations in case 
of some unforseen races.



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4633:

Description: 
Design considerations:
1) Create generic DDL custom discovery message pair - {{INIT}} and {{ACK}} 
messages - which will hold concrete DDL commands:
2) {{INIT}} message goes through the ring and:
- Collect IDs of all participating nodes;
- Perform some fast preliminary checks if necessary;
- Collect errors if needed;

3) If at least one error occur - throw exception on a originator node;
4) If all is OK - send {{ACK}} message.
5) {{ACK}} message initiates actual operation. No-op at the moment.
6) Finally, originator node is provided with the list of participating nodes.

  was:
Design considerations:
1) Create generic DDL custom discovery message pair - {{INIT}} and {{ACK}} 
messages - which will hold concrete DDL commands:
2) {{INIT}} message goes through the ring and:
- Collect IDs of all participating nodes;
- Perform some fast preliminary checks if necessary;
- Collect errors if needed;

3) If at least one error occur - throw exception on a originator node;
4) If all is OK - send {{ACK}} message.
5) {{ACK}} message initiates actual operation. No-op at the moment.


> Initiate DDL operation through custom discovery message
> ---
>
> Key: IGNITE-4633
> URL: https://issues.apache.org/jira/browse/IGNITE-4633
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> Design considerations:
> 1) Create generic DDL custom discovery message pair - {{INIT}} and {{ACK}} 
> messages - which will hold concrete DDL commands:
> 2) {{INIT}} message goes through the ring and:
> - Collect IDs of all participating nodes;
> - Perform some fast preliminary checks if necessary;
> - Collect errors if needed;
> 3) If at least one error occur - throw exception on a originator node;
> 4) If all is OK - send {{ACK}} message.
> 5) {{ACK}} message initiates actual operation. No-op at the moment.
> 6) Finally, originator node is provided with the list of participating nodes.



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

[jira] [Updated] (IGNITE-4637) Implement DDL operation completion protocol

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4637:

Description: 
*Normal flow*
1) When participating node completed operation, it sends 
{{PARTICIPANT_FINISHED}} message to coordinator.
2) When coordinator collected responses from all participants, it notifies 
originator with {{FINISHED}} request.
3) Originator responds coordinator with {{FINISHED_ACK}} message.
4) Coordinator responds to all originators with {{PARTICIPANT_FINISHED_ACK}} 
message.

*Originator leave*
1) Coordinator marks originator as "notified", and sends 
{{PARTICIPANT_FINISHED_ACK}} message to participants after all 
{{PARTICIPANT_FINISHED}} are collected.

*Participant leave*
1) Coordinator marks participant as "finished" and no longer waits for any 
responses from it.

*Coordinator leave*
1) The oldest node among remaining participants is elected as new coordinator.
2) Other participants re-send {{PARTICIPANT_FINISHED}} message to new 
coordinator.
3) If it was the last participating node, then originator must be informed 
about the failure. It means that client must be aware of participating nodes. 
Otherwise it's future will never be completed.






> Implement DDL operation completion protocol
> ---
>
> Key: IGNITE-4637
> URL: https://issues.apache.org/jira/browse/IGNITE-4637
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> *Normal flow*
> 1) When participating node completed operation, it sends 
> {{PARTICIPANT_FINISHED}} message to coordinator.
> 2) When coordinator collected responses from all participants, it notifies 
> originator with {{FINISHED}} request.
> 3) Originator responds coordinator with {{FINISHED_ACK}} message.
> 4) Coordinator responds to all originators with {{PARTICIPANT_FINISHED_ACK}} 
> message.
> *Originator leave*
> 1) Coordinator marks originator as "notified", and sends 
> {{PARTICIPANT_FINISHED_ACK}} message to participants after all 
> {{PARTICIPANT_FINISHED}} are collected.
> *Participant leave*
> 1) Coordinator marks participant as "finished" and no longer waits for any 
> responses from it.
> *Coordinator leave*
> 1) The oldest node among remaining participants is elected as new coordinator.
> 2) Other participants re-send {{PARTICIPANT_FINISHED}} message to new 
> coordinator.
> 3) If it was the last participating node, then originator must be informed 
> about the failure. It means that client must be aware of participating nodes. 
> Otherwise it's future will never be completed.



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4633:

Description: 
Design considerations:
1) Create generic DDL custom discovery message pair - {{INIT}} and {{ACK}} 
messages - which will hold concrete DDL commands:
2) {{INIT}} message goes through the ring and:
- Collect IDs of all participating nodes;
- Perform some fast preliminary checks if necessary;
- Collect errors if needed;

3) If at least one error occur - throw exception on a originator node;
4) If all is OK - send {{ACK}} message.
5) {{ACK}} message initiates actual operation. No-op at the moment.

  was:
Design considerations:
1) Create generic DDL custom discovery message pair - {{INIT}} and {{ACK}} 
messages - which will hold concrete DDL commands:
2) {{INIT}} message goes through the ring and:
- Collect IDs of all participating nodes;
- Perform some fast preliminary checks if necessary;
- Collect errors if needed;
3) If at least one error occur - throw exception on a originator node;
4) If all is OK - send {{ACK}} message.
5) {{ACK}} message initiates actual operation. No-op at the moment.


> Initiate DDL operation through custom discovery message
> ---
>
> Key: IGNITE-4633
> URL: https://issues.apache.org/jira/browse/IGNITE-4633
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> Design considerations:
> 1) Create generic DDL custom discovery message pair - {{INIT}} and {{ACK}} 
> messages - which will hold concrete DDL commands:
> 2) {{INIT}} message goes through the ring and:
> - Collect IDs of all participating nodes;
> - Perform some fast preliminary checks if necessary;
> - Collect errors if needed;
> 3) If at least one error occur - throw exception on a originator node;
> 4) If all is OK - send {{ACK}} message.
> 5) {{ACK}} message initiates actual operation. No-op at the moment.



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

[jira] [Created] (IGNITE-4637) Implement DDL operation completion protocol

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4637:
---

 Summary: Implement DDL operation completion protocol
 Key: IGNITE-4637
 URL: https://issues.apache.org/jira/browse/IGNITE-4637
 Project: Ignite
  Issue Type: Sub-task
  Components: SQL
Reporter: Vladimir Ozerov
 Fix For: 2.0






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

[jira] [Comment Edited] (IGNITE-4425) .NET: Support "ICollection.Contains" in LINQ

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-4425 at 2/1/17 10:11 AM:
-

I agree.
Let's map {{ICollection.Contains}} to "IN", and do collection joins as a 
separate ticket: IGNITE-4636


was (Author: ptupitsyn):
I agree.
Let's map {{ICollection.Contains}} to "IN", and do collection joins as a 
separate ticket.

> .NET: Support "ICollection.Contains" in LINQ
> 
>
> Key: IGNITE-4425
> URL: https://issues.apache.org/jira/browse/IGNITE-4425
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Sergey Stronchinskiy
>  Labels: .NET, LINQ
> Fix For: 2.0
>
>
> SQL supports IN queries
> https://apacheignite.readme.io/docs/sql-performance-and-debugging#sql-performance-and-usability-considerations
> Example SQL:
> {code}
> new SqlFieldsQuery("select p.name from Person p where id in (?, ?)", 1, 3);
> {code}
> Add support in LINQ like this:
> {code}
> persons.AsCacheQueryable().Where(x => new[] {1,3}.Contains(x.Value.Id))
> {code}



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

[jira] [Created] (IGNITE-4636) .NET: Support local collection joins in LINQ

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4636:
--

 Summary: .NET: Support local collection joins in LINQ
 Key: IGNITE-4636
 URL: https://issues.apache.org/jira/browse/IGNITE-4636
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 1.8
Reporter: Pavel Tupitsyn
 Fix For: 2.0


LINQ {{IN}} clause is implemented in IGNITE-4425 and maps from 
{{ICollection.Contains}}.

However, {{IN}} has some limitations in Ignite, and better alternative is 
temporary table join:
https://apacheignite.readme.io/docs/sql-performance-and-debugging#sql-performance-and-usability-considerations

Example SQL:
{code}
new SqlFieldsQuery("select p.name from Person p join table(id bigint = ?) i on 
p.OrgId = i.id", new object[] { new object[] {1,3}})
{code}

Add support in LINQ like this:

{code}persons.AsCacheQueryable().Join(new[] {1, 3}, p => p.Value.OrgId, x => x, 
(p, x) => p);{code}





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

[jira] [Created] (IGNITE-4635) Implement single-threaded DDL worker

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4635:
---

 Summary: Implement single-threaded DDL worker
 Key: IGNITE-4635
 URL: https://issues.apache.org/jira/browse/IGNITE-4635
 Project: Ignite
  Issue Type: Sub-task
  Components: SQL
Reporter: Vladimir Ozerov
 Fix For: 2.0


All DDL statement must be performed from within separate worker thread. This 
worker thread should listen for discovery events (JOIN, LEAVE, FAIL, CUSTOM) 
and act accordingly.



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

[jira] [Updated] (IGNITE-4634) Drop SQL index locally

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4634:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-4565

> Drop SQL index locally
> --
>
> Key: IGNITE-4634
> URL: https://issues.apache.org/jira/browse/IGNITE-4634
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>




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

[jira] [Created] (IGNITE-4634) Drop SQL index locally

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4634:
---

 Summary: Drop SQL index locally
 Key: IGNITE-4634
 URL: https://issues.apache.org/jira/browse/IGNITE-4634
 Project: Ignite
  Issue Type: Task
  Components: SQL
Reporter: Vladimir Ozerov
 Fix For: 2.0






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

[jira] [Updated] (IGNITE-4425) .NET: Support "ICollection.Contains" in LINQ

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-4425:
---
Description: 
SQL supports IN queries
https://apacheignite.readme.io/docs/sql-performance-and-debugging#sql-performance-and-usability-considerations

Example SQL:
{code}
new SqlFieldsQuery("select p.name from Person p where id in (?, ?)", 1, 3);
{code}

Add support in LINQ like this:

{code}
persons.AsCacheQueryable().Where(x => new[] {1,3}.Contains(x.Value.Id))
{code}


  was:
SQL supports IN queries and, as a better alternative, temporary table join, as 
described in the docs:
https://apacheignite.readme.io/docs/sql-performance-and-debugging#sql-performance-and-usability-considerations

Example SQL:
{code}
new SqlFieldsQuery("select p.name from Person p join table(id bigint = ?) i on 
p.OrgId = i.id", new object[] { new object[] {1,3}})
{code}

Add support in LINQ like this:

{code}
persons.AsCacheQueryable().Where(x => new[] {1,3}.Contains(x.Value.OrgId))
{code}



> .NET: Support "ICollection.Contains" in LINQ
> 
>
> Key: IGNITE-4425
> URL: https://issues.apache.org/jira/browse/IGNITE-4425
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Sergey Stronchinskiy
>  Labels: .NET, LINQ
> Fix For: 2.0
>
>
> SQL supports IN queries
> https://apacheignite.readme.io/docs/sql-performance-and-debugging#sql-performance-and-usability-considerations
> Example SQL:
> {code}
> new SqlFieldsQuery("select p.name from Person p where id in (?, ?)", 1, 3);
> {code}
> Add support in LINQ like this:
> {code}
> persons.AsCacheQueryable().Where(x => new[] {1,3}.Contains(x.Value.Id))
> {code}



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

[jira] [Assigned] (IGNITE-4569) Create SQL index locally

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-4569:
---

Assignee: (was: Alexander Paschenko)

> Create SQL index locally
> 
>
> Key: IGNITE-4569
> URL: https://issues.apache.org/jira/browse/IGNITE-4569
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache, SQL
>Reporter: Alexander Paschenko
> Fix For: 2.0
>
>
> Design considerations:
> 1) Cache is *not blocked* for updates during index creation.
> 2) DDL thread flow:
> - Create index and add it to some collection of pending indexes;
> - Iterate over all cache entries and add them one by one;
> - Once iteration finished - add index to the table;
> 3) Cache thread flow:
> - If there are any pending index, then propagate update to the index.
> Be careful with put/remove interleaving.



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

[jira] [Updated] (IGNITE-4569) Create SQL index locally

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4569:

Description: 
Design considerations:
1) Cache is *not blocked* for updates during index creation.
2) DDL thread flow:
- Create index and add it to some collection of pending indexes;
- Iterate over all cache entries and add them one by one;
- Once iteration finished - add index to the table;
3) Cache thread flow:
- If there are any pending index, then propagate update to the index.

Be careful with put/remove interleaving.

  was:Actual index data modification - initially will render whole SQL table 
inaccessible during initial index buildup


> Create SQL index locally
> 
>
> Key: IGNITE-4569
> URL: https://issues.apache.org/jira/browse/IGNITE-4569
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache, SQL
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 2.0
>
>
> Design considerations:
> 1) Cache is *not blocked* for updates during index creation.
> 2) DDL thread flow:
> - Create index and add it to some collection of pending indexes;
> - Iterate over all cache entries and add them one by one;
> - Once iteration finished - add index to the table;
> 3) Cache thread flow:
> - If there are any pending index, then propagate update to the index.
> Be careful with put/remove interleaving.



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

[jira] [Updated] (IGNITE-4569) Create SQL index locally

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4569:

Summary: Create SQL index locally  (was: Create local portion of index 
w/table locking)

> Create SQL index locally
> 
>
> Key: IGNITE-4569
> URL: https://issues.apache.org/jira/browse/IGNITE-4569
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache, SQL
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 2.0
>
>
> Actual index data modification - initially will render whole SQL table 
> inaccessible during initial index buildup



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

[jira] [Updated] (IGNITE-4569) Create SQL index locally

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4569:

Fix Version/s: (was: 1.9)
   2.0

> Create SQL index locally
> 
>
> Key: IGNITE-4569
> URL: https://issues.apache.org/jira/browse/IGNITE-4569
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache, SQL
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 2.0
>
>
> Actual index data modification - initially will render whole SQL table 
> inaccessible during initial index buildup



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

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

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4633:
---

 Summary: Initiate DDL operation through custom discovery message
 Key: IGNITE-4633
 URL: https://issues.apache.org/jira/browse/IGNITE-4633
 Project: Ignite
  Issue Type: Sub-task
  Components: SQL
Reporter: Vladimir Ozerov
 Fix For: 2.0


Design considerations:
1) Create generic DDL custom discovery message pair - {{INIT}} and {{ACK}} 
messages - which will hold concrete DDL commands:
2) {{INIT}} message goes through the ring and:
- Collect IDs of all participating nodes;
- Perform some fast preliminary checks if necessary;
- Collect errors if needed;
3) If at least one error occur - throw exception on a originator node;
4) If all is OK - send {{ACK}} message.
5) {{ACK}} message initiates actual operation. No-op at the moment.



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

[jira] [Resolved] (IGNITE-4568) Dynamically create distributed index

[Vladimir Ozerov (JIRA)]

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

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

Will be split into several pieces.

> Dynamically create distributed index
> 
>
> Key: IGNITE-4568
> URL: https://issues.apache.org/jira/browse/IGNITE-4568
> Project: Ignite
>  Issue Type: Task
>  Components: SQL
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 1.9
>
>
> Handle index creation messaging using means introduced by IGNITE-4567



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

[jira] [Assigned] (IGNITE-4568) Dynamically create distributed index

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-4568:
---

Assignee: (was: Alexander Paschenko)

> Dynamically create distributed index
> 
>
> Key: IGNITE-4568
> URL: https://issues.apache.org/jira/browse/IGNITE-4568
> Project: Ignite
>  Issue Type: Task
>  Components: SQL
>Reporter: Alexander Paschenko
>
> Handle index creation messaging using means introduced by IGNITE-4567



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

[jira] [Updated] (IGNITE-4425) .NET: Support "ICollection.Contains" in LINQ

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-4425:
---
Summary: .NET: Support "ICollection.Contains" in LINQ  (was: .NET: Support 
"Array.Contains" in LINQ)

> .NET: Support "ICollection.Contains" in LINQ
> 
>
> Key: IGNITE-4425
> URL: https://issues.apache.org/jira/browse/IGNITE-4425
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Sergey Stronchinskiy
>  Labels: .NET, LINQ
> Fix For: 2.0
>
>
> SQL supports IN queries and, as a better alternative, temporary table join, 
> as described in the docs:
> https://apacheignite.readme.io/docs/sql-performance-and-debugging#sql-performance-and-usability-considerations
> Example SQL:
> {code}
> new SqlFieldsQuery("select p.name from Person p join table(id bigint = ?) i 
> on p.OrgId = i.id", new object[] { new object[] {1,3}})
> {code}
> Add support in LINQ like this:
> {code}
> persons.AsCacheQueryable().Where(x => new[] {1,3}.Contains(x.Value.OrgId))
> {code}



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

[jira] [Commented] (IGNITE-4425) .NET: Support "Array.Contains" in LINQ

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4425:


I agree.
Let's map {{ICollection.Contains}} to "IN", and do collection joins as a 
separate ticket.

> .NET: Support "Array.Contains" in LINQ
> --
>
> Key: IGNITE-4425
> URL: https://issues.apache.org/jira/browse/IGNITE-4425
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Sergey Stronchinskiy
>  Labels: .NET, LINQ
> Fix For: 2.0
>
>
> SQL supports IN queries and, as a better alternative, temporary table join, 
> as described in the docs:
> https://apacheignite.readme.io/docs/sql-performance-and-debugging#sql-performance-and-usability-considerations
> Example SQL:
> {code}
> new SqlFieldsQuery("select p.name from Person p join table(id bigint = ?) i 
> on p.OrgId = i.id", new object[] { new object[] {1,3}})
> {code}
> Add support in LINQ like this:
> {code}
> persons.AsCacheQueryable().Where(x => new[] {1,3}.Contains(x.Value.OrgId))
> {code}



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

[jira] [Updated] (IGNITE-4568) Dynamically create distributed index

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4568:

Component/s: (was: messaging)

> Dynamically create distributed index
> 
>
> Key: IGNITE-4568
> URL: https://issues.apache.org/jira/browse/IGNITE-4568
> Project: Ignite
>  Issue Type: Task
>  Components: SQL
>Reporter: Alexander Paschenko
>
> Handle index creation messaging using means introduced by IGNITE-4567



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

[jira] [Closed] (IGNITE-4568) Dynamically create distributed index

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-4568.
---

> Dynamically create distributed index
> 
>
> Key: IGNITE-4568
> URL: https://issues.apache.org/jira/browse/IGNITE-4568
> Project: Ignite
>  Issue Type: Task
>  Components: SQL
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
>
> Handle index creation messaging using means introduced by IGNITE-4567



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

[jira] [Updated] (IGNITE-4568) Dynamically create distributed index

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4568:

Fix Version/s: (was: 1.9)

> Dynamically create distributed index
> 
>
> Key: IGNITE-4568
> URL: https://issues.apache.org/jira/browse/IGNITE-4568
> Project: Ignite
>  Issue Type: Task
>  Components: SQL
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
>
> Handle index creation messaging using means introduced by IGNITE-4567



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

[jira] [Updated] (IGNITE-4568) Dynamically create distributed index

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4568:

Issue Type: Task  (was: Sub-task)
Parent: (was: IGNITE-4565)

> Dynamically create distributed index
> 
>
> Key: IGNITE-4568
> URL: https://issues.apache.org/jira/browse/IGNITE-4568
> Project: Ignite
>  Issue Type: Task
>  Components: messaging, SQL
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 1.9
>
>
> Handle index creation messaging using means introduced by IGNITE-4567



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

[jira] [Assigned] (IGNITE-4570) Handle CREATE INDEX statements

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-4570:
---

Assignee: Alexander Paschenko  (was: Sergi Vladykin)

> Handle CREATE INDEX statements
> --
>
> Key: IGNITE-4570
> URL: https://issues.apache.org/jira/browse/IGNITE-4570
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 1.9
>
>
> Parse and execute CREATE INDEX boiling down to IgniteCacheEx.createQueryIndex 
> introduced by IGNITE-4566



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

[jira] [Commented] (IGNITE-4570) Handle CREATE INDEX statements

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4570:
-

Alex, my comments:
1) We already have {{QueryIndex}} and {{QueryIndexType}} classes. I propose to 
inject it into {{GridCreateIndex}} directly to avoid any duplication.
2) Please make sure there are no violations in code conventions (mainly - line 
length, comments).

> Handle CREATE INDEX statements
> --
>
> Key: IGNITE-4570
> URL: https://issues.apache.org/jira/browse/IGNITE-4570
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Alexander Paschenko
>Assignee: Sergi Vladykin
> Fix For: 1.9
>
>
> Parse and execute CREATE INDEX boiling down to IgniteCacheEx.createQueryIndex 
> introduced by IGNITE-4566



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

[jira] [Commented] (IGNITE-4584) Async API: Tests refactoring to use new async API

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-4584:
--

[Tests 
results|http://195.239.208.174/project.html?projectId=IgniteTests&tab=projectOverview&branch_IgniteTests=pull%2F1485%2Fhead]

> Async API: Tests refactoring to use new async API
> -
>
> Key: IGNITE-4584
> URL: https://issues.apache.org/jira/browse/IGNITE-4584
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Affects Versions: 1.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> The tests must use new async API instead of the deprecated API.



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

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

[Yakov Zhdanov (JIRA)]

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

Yakov Zhdanov commented on IGNITE-3878:
---

[~ntikhonov], can you please join us and confirm that event is fired on backup 
as well, so event entry is available on backups as well and entry.isBackup() 
should return true?

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



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

[jira] [Commented] (IGNITE-4584) Async API: Tests refactoring to use new async API

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4584:


GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-4584 Async API: Tests refactoring to use new async API



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

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

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

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


commit c893da70a9757b16b0799adc8eaa29fa1b03d06e
Author: tledkov-gridgain 
Date:   2016-12-21T11:54:33Z

IGNITE-4399: IGFS: Merged IgfsSecondaryFileSystem and 
IgfsSecondaryFileSystemV2 interfaces. This closes #1346.

commit c5882a85f4e3a1f61723ac54fd92f087684df6da
Author: devozerov 
Date:   2016-12-26T11:15:42Z

Merge branch 'master' into ignite-2.0

commit 7e73d0223a3f09cbe0b7094a2c04bdf9d63ca9be
Author: devozerov 
Date:   2016-12-28T09:54:47Z

Merge branch 'master' into ignite-2.0

commit 7d82d6a06b5e9f1f8cd2909b865e37d46b8da03f
Author: devozerov 
Date:   2016-12-28T09:58:11Z

IGNITE-3875: Introduced separate thread pool for data streamer. This closes 
#1173. This closes #1383.

commit a61b0eaff1817d84c0659e8a7e095f29e22800e1
Author: tledkov-gridgain 
Date:   2016-12-28T11:09:38Z

IGNITE-4405: Hadoop: implemented "readLine" method for HadoopDataInStream 
and HadoopDirectDataInput classes. This closes #1358.

commit 2df39a80d80e2575be61a902ccd48615796fcde9
Author: tledkov-gridgain 
Date:   2016-12-28T13:47:24Z

IGNITE-3961: IGFS: Added IgfsSecondaryFileSystem.affintiy() method. This 
closes #1114. This closes #1252.

commit 2e691d80ea4870c3e7b5b127792b66c920f72c39
Author: tledkov-gridgain 
Date:   2016-12-29T08:00:01Z

IGNITE-4462: IGFS: removed grid name from HadoopIgfsEndpoint. This closes 
#1368.

commit a9b1fc2b3840d47d7c978d9296e8ae6bdeb10be5
Author: tledkov-gridgain 
Date:   2016-12-29T08:07:22Z

IGNITE-4459: Hadoop: weighted planned is default one from now on. This 
closes #1391.

commit 1f743465d6875ef48b1835d03a78a0dbaf339bf6
Author: tledkov-gridgain 
Date:   2016-12-29T08:14:10Z

IGNITE-4458: Hadoop: "striped" shuffle mode is default from now on. This 
closes #1390.

commit 6090ebdfcd0ea3840b0d32cb10197b43615e1e89
Author: devozerov 
Date:   2017-01-05T09:23:06Z

Merge branch 'master' into ignite-2.0

commit 77ca2e636c73e464f833f227c4894df0785ae9e2
Author: devozerov 
Date:   2017-01-16T13:07:49Z

Merge branch 'master' into ignite-2.0

commit d14e0727b3dd61ab5ec2957133d77dbc25e9ba68
Author: tledkov-gridgain 
Date:   2017-01-16T13:36:25Z

IGNITE-4428: Hadoop: moved HadoopMapReducePlanner and dependent classes to 
public space. This closes #1389. This closes #1394.

commit f1365421c299b754a10edf8b6f156aeeb5ff0ce1
Author: tledkov-gridgain 
Date:   2017-01-16T13:57:27Z

IGNITE-4503: Hadoop: added boundary checks to HadoopDirectDataInput. This 
closes # 1416.

commit e08b6ff48916edfab2dbd5d62092be5a1f819a2f
Author: Pavel Tupitsyn 
Date:   2017-01-19T10:34:59Z

Merge branch 'master' into ignite-2.0

commit 43adf8a3f09c6b29fe3e70f62dbc58251d8d7cb9
Author: Ivan Veselovskiy 
Date:   2017-01-19T11:34:23Z

IGNITE-4219: Hadoop: fixed serialization of long strings. This closes #1409.

commit 454b9769e72775c5f6b44a36f0eef84bcce13bd7
Author: devozerov 
Date:   2017-01-19T11:34:43Z

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

commit 4cd332b781cf700b99402eed2363f988f6403602
Author: Sergey Chugunov 
Date:   2017-01-19T12:05:09Z

IGNITE-4157 Use  discovery custom messages instead of marshaller cache - 
Fixes #1271.

Signed-off-by: Alexey Goncharuk 

commit d0a6c57aa26bca64ef68370c0ebdb5ce45bcc765
Author: Pavel Tupitsyn 
Date:   2017-01-19T14:10:41Z

IGNITE-4441 Define plugin API in .NET

This closes #1362

commit 34a97833905a33bdb31b8e4580a576c2142313a7
Author: Alexey Goncharuk 
Date:   2017-01-19T15:04:23Z

IGNITE-4157 - Added mapping update listener stub

commit e8377167b7b8dd020a93d92c743e4541dcd000ed
Author: Pavel Tupitsyn 
Date:   2017-01-20T10:00:40Z

Merge branch 'master' into ignite-2.0

commit 38cb67d45eb91e20ad4b92a490747534f5e8febb
Author: Pavel Tupitsyn 
Date:   2017-01-20T13:09:57Z

Merge branch 'master' into ignite-2.0

commit b81621bf2e8a35b20989f95ff52c0f6d91dd75d6
Author: tledkov-gridgain 
Date:   2017-01-19T13:42:38Z

IGNITE-4580 change async API at the IgniteCompute, change examples, add 
tests to FullAPI suite

commit 310c846688eeb401c4832b2b633dddcd9dff63f4
Author: tledkov-gridgain 
Date:   2017-01-20T13:54:59Z

IGNITE-4580 rename in

[jira] [Assigned] (IGNITE-3244) Custom arrays are not serialized properly by CacheObjectBinaryProcessorImpl

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-3244:


Assignee: Alexey Kuznetsov

> Custom arrays are not serialized properly by CacheObjectBinaryProcessorImpl
> ---
>
> Key: IGNITE-3244
> URL: https://issues.apache.org/jira/browse/IGNITE-3244
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Fix For: 2.0
>
>
> If to put a custom object array into a cache like this one
> {code}
> TestObject[] arr = new TestObject[] {new TestObject(i)};
> cache.put(0, arr);
> {code}
> then it will be serialized as Object[] array in 
> {{CacheObjectBinaryProcessorImpl.marshallToBinary}} method.
> This leads to the situation when object's array type is lost and on cache.get 
> the code below produces {{ClassCastException}}
> {code}
> TestObject[] obj = cache.get(i);
> {code}
> The full test is already added into 
> {{GridCacheBinaryObjectsAbstractSelfTest.testCustomArrays}}.
> To fix the issue we have to revisit logic of 
> {{CacheObjectBinaryProcessorImpl.marshallToBinary}} and 
> {{CacheObjectContext.unwrapBinary}}.



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

[jira] [Resolved] (IGNITE-4631) Node starts with incorrect QueryEntity configuration

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov resolved IGNITE-4631.

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

Added check to ensure QueryEntity 'keyFields' is subset of 'fields'

> Node starts with incorrect QueryEntity configuration
> 
>
> Key: IGNITE-4631
> URL: https://issues.apache.org/jira/browse/IGNITE-4631
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Reporter: Sergey Kalashnikov
>Assignee: Vladimir Ozerov
>Priority: Minor
> Attachments: QueryEntityCaseMismatchTest.java
>
>
> When QueryEntity.keyFields property is used to specify compound key fields, 
> it is possible to set the field names in wrong register.
> The node would start normally, but for SQL queries requesting key fields the 
> resultset contains nulls in corresponding columns.
> The query processor internally fails to tell the key field from value field 
> in this case.
> Note that for optimized marshaller, the keyFields aren't taken into account 
> and queries return valid data. 
> I believe the node shall not start with such configuration at all.
> See the attached test that reproduces the case.



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

[jira] [Commented] (IGNITE-4631) Node starts with incorrect QueryEntity configuration

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov commented on IGNITE-4631:


[~vozerov], could you please review?

> Node starts with incorrect QueryEntity configuration
> 
>
> Key: IGNITE-4631
> URL: https://issues.apache.org/jira/browse/IGNITE-4631
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Reporter: Sergey Kalashnikov
>Assignee: Vladimir Ozerov
>Priority: Minor
> Attachments: QueryEntityCaseMismatchTest.java
>
>
> When QueryEntity.keyFields property is used to specify compound key fields, 
> it is possible to set the field names in wrong register.
> The node would start normally, but for SQL queries requesting key fields the 
> resultset contains nulls in corresponding columns.
> The query processor internally fails to tell the key field from value field 
> in this case.
> Note that for optimized marshaller, the keyFields aren't taken into account 
> and queries return valid data. 
> I believe the node shall not start with such configuration at all.
> See the attached test that reproduces the case.



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