[jira] [Closed] (IGNITE-1023) Need to add more information for startNodes at cmd visor.

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov closed IGNITE-1023.
--
Assignee: (was: Pavel Konstantinov)

> Need to add more information for startNodes at cmd visor.
> -
>
> Key: IGNITE-1023
> URL: https://issues.apache.org/jira/browse/IGNITE-1023
> Project: Ignite
>  Issue Type: Task
>Reporter: Artem Shutak
> Attachments: 
> #_IGNITE-1023_Additional_information_about_start_node_command.patch, 
> #_IGNITE-1023_Fixed_reading_of_an_empty_environment_variable.patch
>
>
> See 
> http://apache-ignite-users.70518.x6.nabble.com/Topology-Specification-INI-td467.html
> TODO:
> - add note about where to find ignite-startNodes logs
> - Successful start attempts - means nothing
> - describe ini-file format file
> - '-s' option - is it mandatory.



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

[jira] [Resolved] (IGNITE-1023) Need to add more information for startNodes at cmd visor.

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov resolved IGNITE-1023.

Resolution: Fixed

> Need to add more information for startNodes at cmd visor.
> -
>
> Key: IGNITE-1023
> URL: https://issues.apache.org/jira/browse/IGNITE-1023
> Project: Ignite
>  Issue Type: Task
>Reporter: Artem Shutak
>Assignee: Pavel Konstantinov
> Attachments: 
> #_IGNITE-1023_Additional_information_about_start_node_command.patch, 
> #_IGNITE-1023_Fixed_reading_of_an_empty_environment_variable.patch
>
>
> See 
> http://apache-ignite-users.70518.x6.nabble.com/Topology-Specification-INI-td467.html
> TODO:
> - add note about where to find ignite-startNodes logs
> - Successful start attempts - means nothing
> - describe ini-file format file
> - '-s' option - is it mandatory.



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

[jira] [Commented] (IGNITE-1023) Need to add more information for startNodes at cmd visor.

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-1023:


Tested.

> Need to add more information for startNodes at cmd visor.
> -
>
> Key: IGNITE-1023
> URL: https://issues.apache.org/jira/browse/IGNITE-1023
> Project: Ignite
>  Issue Type: Task
>Reporter: Artem Shutak
>Assignee: Pavel Konstantinov
> Attachments: 
> #_IGNITE-1023_Additional_information_about_start_node_command.patch, 
> #_IGNITE-1023_Fixed_reading_of_an_empty_environment_variable.patch
>
>
> See 
> http://apache-ignite-users.70518.x6.nabble.com/Topology-Specification-INI-td467.html
> TODO:
> - add note about where to find ignite-startNodes logs
> - Successful start attempts - means nothing
> - describe ini-file format file
> - '-s' option - is it mandatory.



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

[jira] [Assigned] (IGNITE-4472) Web Console: Implement usage tracing

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-4472:
--

Assignee: Dmitriy Shabalin  (was: Pavel Konstantinov)

> Web Console: Implement usage tracing
> 
>
> Key: IGNITE-4472
> URL: https://issues.apache.org/jira/browse/IGNITE-4472
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Shabalin
>Assignee: Dmitriy Shabalin
> Fix For: 1.9
>
>
> We need to track some kind of "activity scores" for users.
> Activities:
> # Configuration
> # SQL
> # Demo
> And show that score on admin panel.
> May be this could be implemented by some library.



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

[jira] [Comment Edited] (IGNITE-4472) Web Console: Implement usage tracing

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov edited comment on IGNITE-4472 at 2/3/17 6:53 AM:


1. Please do correct descriptions for all actions. Now some of them is the same 
as action string.


was (Author: pkonstantinov):
1. Please do correct descriptions for all actions

> Web Console: Implement usage tracing
> 
>
> Key: IGNITE-4472
> URL: https://issues.apache.org/jira/browse/IGNITE-4472
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Shabalin
>Assignee: Pavel Konstantinov
> Fix For: 1.9
>
>
> We need to track some kind of "activity scores" for users.
> Activities:
> # Configuration
> # SQL
> # Demo
> And show that score on admin panel.
> May be this could be implemented by some library.



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

[jira] [Commented] (IGNITE-4472) Web Console: Implement usage tracing

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-4472:


1. Please do correct descriptions for all actions

> Web Console: Implement usage tracing
> 
>
> Key: IGNITE-4472
> URL: https://issues.apache.org/jira/browse/IGNITE-4472
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Shabalin
>Assignee: Pavel Konstantinov
> Fix For: 1.9
>
>
> We need to track some kind of "activity scores" for users.
> Activities:
> # Configuration
> # SQL
> # Demo
> And show that score on admin panel.
> May be this could be implemented by some library.



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

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

[Maksim Kozlov (JIRA)]

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

Maksim Kozlov commented on IGNITE-3878:
---

[~ntikhonov] I added a check on which you wrote in the previous comments, all 
right? {{CacheContinuousQueryFailoverAbstractSelfTest}} class, 
{{testRemoteFilter}} method, 
[commit|https://github.com/apache/ignite/pull/1393/commits/f1fd32fcfc69fb994e6ac7f56c88e909f24e11c1].

> 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-4610) Please add explicity recomendation to check "ignite-rest-http" is present in "libs" folder

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov closed IGNITE-4610.
--
Assignee: Alexey Kuznetsov  (was: Pavel Konstantinov)

> Please add explicity recomendation to check "ignite-rest-http" is present in 
> "libs" folder
> --
>
> Key: IGNITE-4610
> URL: https://issues.apache.org/jira/browse/IGNITE-4610
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.8
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
> Fix For: 1.9
>
>
> Currently it is not clear what I need to check in case when I got error about 
> executing REST command.



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

[jira] [Commented] (IGNITE-4610) Please add explicity recomendation to check "ignite-rest-http" is present in "libs" folder

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-4610:


Tested.

> Please add explicity recomendation to check "ignite-rest-http" is present in 
> "libs" folder
> --
>
> Key: IGNITE-4610
> URL: https://issues.apache.org/jira/browse/IGNITE-4610
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.8
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
> Fix For: 1.9
>
>
> Currently it is not clear what I need to check in case when I got error about 
> executing REST command.



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

[jira] [Created] (IGNITE-4649) Upgrade JCache dependency when Apache 2.0 license migration finalized

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4649:
---

 Summary: Upgrade JCache dependency when Apache 2.0 license 
migration finalized
 Key: IGNITE-4649
 URL: https://issues.apache.org/jira/browse/IGNITE-4649
 Project: Ignite
  Issue Type: Task
Reporter: Denis Magda


JCache's migration to Apache 2.0 license will be finished soon. Upgrade JCache 
dependency in Ignite's pom file once this happens. Also, make sure that 
Ignite's files with licenses will reflect the change.

Track JCache migration here:
https://github.com/jsr107/jsr107spec/issues/333#issuecomment-277106702

Relevant discussion on the dev list:
http://apache-ignite-developers.2346864.n4.nabble.com/moving-to-geronimo-JCache-jar-td8118.html



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

Alexei Scherbakov commented on IGNITE-4523:
---

Same for remote 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-4541) Create test for Hadoop running in external JVM

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky commented on IGNITE-4541:
-

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

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



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

[jira] [Commented] (IGNITE-4589) Possible starvation during rebalancing for marshaller cache

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-4589:
--

Cause of the problem in processing ordered messages. During balancing between 
two nodes happens the following scenario: 
* Ordered {{GridDhtPartitionSupplyMessageV2}} message was sent for 
{{ignite-marshaller-sys-cache}} cache with {{GridIoPolicy#MARSH_CACHE_POOL}};
* Ordered {{GridDhtPartitionSupplyMessageV2}} message was sent for 
{{ignite-sys-cache}} cache with {{GridIoPolicy#UTILITY_CACHE_POOL}};
* On receiver node, the first message creates {{GridCommunicationMessageSet}} 
and start polling messages from queue in marshaller thread pool.
* Second supply message added in the same {{GridCommunicationMessageSet}} and 
that thread (from marshaller thread pool) is proccessed this message, although 
the message have different io policy.

> Possible starvation during rebalancing for marshaller cache
> ---
>
> Key: IGNITE-4589
> URL: https://issues.apache.org/jira/browse/IGNITE-4589
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Nikolay Tikhonov
>Assignee: Nikolay Tikhonov
>
> When Ignite processing supply messages (rebalancing) in marshaller threads 
> and calling marshaller cache from them, but responses also should be 
> proccessed in marshaller threadpool. It leads to starvation.
> {noformat}
> marshaller-cache-#26%test-node%" #117 prio=5 os_prio=0 tid=0x7f89e40c6000 
> nid=0x1dc waiting on condition [0x7f8a3fffc000]
>java.lang.Thread.State: WAITING (parking)
>  at sun.misc.Unsafe.park(Native Method)
>  - parking to wait for <0xc206d318> (a 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedGetFuture)
>  at java.util.concurrent.locks.LockSupport.park(Unknown Source)
>  at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(Unknown
>  Source)
>  at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(Unknown
>  Source)
>  at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(Unknown
>  Source)
>  at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:159)
>  at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:117)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getTopologySafe(GridCacheAdapter.java:1340)
>  at 
> org.apache.ignite.internal.MarshallerContextImpl.className(MarshallerContextImpl.java:195)
>  at 
> org.apache.ignite.internal.MarshallerContextAdapter.getClass(MarshallerContextAdapter.java:174)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:266)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:318)
>  at java.io.ObjectInputStream.readObject(Unknown Source)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readFields(OptimizedObjectInputStream.java:491)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readSerializable(OptimizedObjectInputStream.java:579)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedClassDescriptor.read(OptimizedClassDescriptor.java:927)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:324)
>  at java.io.ObjectInputStream.readObject(Unknown Source)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readFields(OptimizedObjectInputStream.java:491)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readSerializable(OptimizedObjectInputStream.java:579)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedClassDescriptor.read(OptimizedClassDescriptor.java:927)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:324)
>  at java.io.ObjectInputStream.readObject(Unknown Source)
>  at 
> org.apache.ignite.marshaller.optimized.OptimizedMarshaller.unmarshal0(OptimizedMarshaller.java:218)
>  at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
>  at 
> org.apache.ignite.internal.binary.BinaryUtils.doReadOptimized(BinaryUtils.java:1614)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1680)
>  at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1450)
>  at 
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:298)
>  at 
> 

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

[Oleg Ostanin (JIRA)]

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

Oleg Ostanin commented on IGNITE-4212:
--

[~dmagda]

I've fixed README.txt and DEVNOTES.txt.

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



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4252:


GitHub user skalashnikov opened a pull request:

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

IGNITE-4252 Fixed exception with local cache query started on partiti…

…oned cache

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

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

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

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


commit 42d0e97be861cf285c994faa1232e660adc12a08
Author: skalashnikov 
Date:   2017-02-02T16:50:15Z

IGNITE-4252 Fixed exception with local cache query started on partitioned 
cache




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



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

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

[Sergey Stronchinskiy (JIRA)]

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

Sergey Stronchinskiy edited comment on IGNITE-4425 at 2/2/17 4:39 PM:
--

Hi,

After investigating the issue I think the best way to implement 
"Array.Contains" is directly translating it to "IN (?,?,?)" cause:

1.  It is the most direct and expected mapping
2. Also there are some possible queries that can not be that easily translated 
to "JOIN" clause (for example: .Where(entry => keys.Contains(entry.entry.Key) 
|| _SomeBooleanCondition_))

So i would like to implement it that way in conjunction with enabling 
"Enumerable.Join" with local collections.



was (Author: gurustron):
Hi,

After investigating the issue I think the best way to implement 
"Array.Contains" is directly translating it to "IN (?,?,?)" cause:

1.  It is the most direct and expected mapping
2. Also there are some possible queries that can not be that easily translated 
to "JOIN" clause (for example: .Where(entry => keys.Contains(entry.entry.Key) 
|| _SomeBooleanCondition_))

So my i would like to implement it that way in conjunction with enabling 
"Enumerable.Join" with local collections.


> .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] [Commented] (IGNITE-4633) Initiate DDL operation through custom discovery message

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko commented on IGNITE-4633:
-

Put DDL processor in order (tied its lifecycle w/that of GridQueryProcessor). 
Working on generic part of distributed DDL API.

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



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

[jira] [Commented] (IGNITE-4645) Best effort to avoid extra copying in binary marshaller

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4645:


GitHub user gvvinblade opened a pull request:

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

IGNITE-4645



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

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

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

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


commit df4487388e477dc389091ef5bff99e0d08a87072
Author: Igor Seliverstov 
Date:   2017-02-02T15:41:47Z

IGNITE-4645 Best effort to avoid extra copying in binary marshaller




> Best effort to avoid extra copying in binary marshaller
> ---
>
> Key: IGNITE-4645
> URL: https://issues.apache.org/jira/browse/IGNITE-4645
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Reporter: Yakov Zhdanov
>Assignee: Igor Seliverstov
> Fix For: 1.9
>
>
> If we marshal a class that contain only primitives then we can predict the 
> final byte array size and avoid copies to grow array and final trimming.



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

Pavel Tupitsyn commented on IGNITE-3430:


Tests fixed, feature enabled again in master.

> .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] [Resolved] (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 resolved IGNITE-3430.

Resolution: Fixed

> .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] [Commented] (IGNITE-3430) .NET: Run Ignite transactions via standard TransactionScope API

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3430:


Github user asfgit closed the pull request at:

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


> .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-4581) Async API: IgniteCache refactoring

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-4581 at 2/2/17 2:33 PM:
--

JavaDocs are self reviewed


was (Author: tledkov-gridgain):
JavaDoc is self reviewed

> Async API: IgniteCache refactoring 
> ---
>
> Key: IGNITE-4581
> URL: https://issues.apache.org/jira/browse/IGNITE-4581
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache, general
>Affects Versions: 1.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> {{IgniteCache}} refactoring to simplify the async API.



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

[jira] [Updated] (IGNITE-4647) ComputeTask with custom classLoader fail

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny updated IGNITE-4647:
---
Attachment: (was: repro-2813.tar.gz)

> ComputeTask with custom classLoader fail
> 
>
> Key: IGNITE-4647
> URL: https://issues.apache.org/jira/browse/IGNITE-4647
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Affects Versions: 2.0
>Reporter: Stanilovsky Evgeny
>Priority: Minor
> Attachments: repro-2813.tar.gz
>
>
> In case, when we want to run ComputeTask with custom classLoader and custom 
> inherited IgniteCallable class initialized with instance from custom loader, 
> catch error *java.lang.ClassNotFoundException*. 
> for example we implementing something like :
> {code}
> public class MyCallable implements Callable {
> public Integer call() throws Exception {
> System.out.println("I'm called. Working now!");
> }
> }
> {code}
> {code}
> public class IgniteCallableWrapper implements IgniteCallable {
> private final Class> innerCallableClass;
> public IgniteCallableWrapper(Class> 
> innerCallableClass) {
> this.innerCallableClass = innerCallableClass;
> }
> public Integer call() throws Exception {
> Callable callableInstance = 
> innerCallableClass.newInstance();
> return callableInstance.call();
> }
> }
> {code}
> and start two nodes like :
> first
> {code}
> public static void main(String[] args) throws MalformedURLException, 
> ClassNotFoundException {
> IgniteConfiguration icfg = new IgniteConfiguration();
> icfg.setGridName("grid");
> icfg.setPeerClassLoadingEnabled(true);
> Ignition.start(icfg);
> }
> {code}
> and second :
> {code}
> private final static File myCallableArtifact = new 
> File("./my-callable-artifact.jar");
> private final static File igniteCallableArtifact = new 
> File("./ignite-callable.jar");
> public static void main(String[] args) throws MalformedURLException, 
> ClassNotFoundException, NoSuchMethodException, IllegalAccessException, 
> InvocationTargetException, InstantiationException {
> URLClassLoader myCallableLoader = new URLClassLoader(new URL[] {
> myCallableArtifact.toURI().toURL()});
> URLClassLoader igniteWrapperLoader = new URLClassLoader(new URL[] {
> igniteCallableArtifact.toURI().toURL()},
> SecondNode.class.getClassLoader());
> IgniteLoader igniteLoader = new 
> IgniteLoader(SecondNode.class.getClassLoader(), myCallableLoader, 
> igniteWrapperLoader);
> // Start node
> IgniteConfiguration icfg = new IgniteConfiguration();
> icfg.setGridName("grid");
> icfg.setPeerClassLoadingEnabled(true);
> icfg.setClassLoader(igniteLoader);
> Ignite ignite = Ignition.start(icfg);
> CacheConfiguration cacheConfiguration = new 
> CacheConfiguration("cache");
> IgniteCache cache = 
> ignite.createCache(cacheConfiguration);
> // Load callable
> Class myCallable = myCallableLoader.loadClass("MyCallable");
> Class igniteCallableClass = (Class extends IgniteCallable>) 
> igniteWrapperLoader.loadClass("IgniteCallableWrapper");
> Constructor constructor = 
> igniteCallableClass.getConstructor(Class.class);
> IgniteCallable igniteCallable = constructor.newInstance(myCallable);
> // Send it everywhere!
> for (int i = 0; i < 1024; i++) {
> ignite.compute().affinityCall("cache", i, igniteCallable);
> }
> }
> {code}
> all detailed info, how to reproduce in attach.
> debug shows that function {code} processResourceRequest(UUID nodeId, 
> GridDeploymentRequest req) {code} return classLoader {code} ClassLoader ldr = 
> dep.classLoader(); {code} not that expected (that was setting throught 
> icfg.setClassLoader(igniteLoader);) but classLoader from {code} 
> ignite.compute().affinityCall("cache", i, igniteCallable); {code}{code} 
> igniteCallable {code} object.
> All source for reproduce can be found in attach.



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

[jira] [Updated] (IGNITE-4647) ComputeTask with custom classLoader fail

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny updated IGNITE-4647:
---
Attachment: repro-2813.tar.gz

> ComputeTask with custom classLoader fail
> 
>
> Key: IGNITE-4647
> URL: https://issues.apache.org/jira/browse/IGNITE-4647
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Affects Versions: 2.0
>Reporter: Stanilovsky Evgeny
>Priority: Minor
> Attachments: repro-2813.tar.gz
>
>
> In case, when we want to run ComputeTask with custom classLoader and custom 
> inherited IgniteCallable class initialized with instance from custom loader, 
> catch error *java.lang.ClassNotFoundException*. 
> for example we implementing something like :
> {code}
> public class MyCallable implements Callable {
> public Integer call() throws Exception {
> System.out.println("I'm called. Working now!");
> }
> }
> {code}
> {code}
> public class IgniteCallableWrapper implements IgniteCallable {
> private final Class> innerCallableClass;
> public IgniteCallableWrapper(Class> 
> innerCallableClass) {
> this.innerCallableClass = innerCallableClass;
> }
> public Integer call() throws Exception {
> Callable callableInstance = 
> innerCallableClass.newInstance();
> return callableInstance.call();
> }
> }
> {code}
> and start two nodes like :
> first
> {code}
> public static void main(String[] args) throws MalformedURLException, 
> ClassNotFoundException {
> IgniteConfiguration icfg = new IgniteConfiguration();
> icfg.setGridName("grid");
> icfg.setPeerClassLoadingEnabled(true);
> Ignition.start(icfg);
> }
> {code}
> and second :
> {code}
> private final static File myCallableArtifact = new 
> File("./my-callable-artifact.jar");
> private final static File igniteCallableArtifact = new 
> File("./ignite-callable.jar");
> public static void main(String[] args) throws MalformedURLException, 
> ClassNotFoundException, NoSuchMethodException, IllegalAccessException, 
> InvocationTargetException, InstantiationException {
> URLClassLoader myCallableLoader = new URLClassLoader(new URL[] {
> myCallableArtifact.toURI().toURL()});
> URLClassLoader igniteWrapperLoader = new URLClassLoader(new URL[] {
> igniteCallableArtifact.toURI().toURL()},
> SecondNode.class.getClassLoader());
> IgniteLoader igniteLoader = new 
> IgniteLoader(SecondNode.class.getClassLoader(), myCallableLoader, 
> igniteWrapperLoader);
> // Start node
> IgniteConfiguration icfg = new IgniteConfiguration();
> icfg.setGridName("grid");
> icfg.setPeerClassLoadingEnabled(true);
> icfg.setClassLoader(igniteLoader);
> Ignite ignite = Ignition.start(icfg);
> CacheConfiguration cacheConfiguration = new 
> CacheConfiguration("cache");
> IgniteCache cache = 
> ignite.createCache(cacheConfiguration);
> // Load callable
> Class myCallable = myCallableLoader.loadClass("MyCallable");
> Class igniteCallableClass = (Class extends IgniteCallable>) 
> igniteWrapperLoader.loadClass("IgniteCallableWrapper");
> Constructor constructor = 
> igniteCallableClass.getConstructor(Class.class);
> IgniteCallable igniteCallable = constructor.newInstance(myCallable);
> // Send it everywhere!
> for (int i = 0; i < 1024; i++) {
> ignite.compute().affinityCall("cache", i, igniteCallable);
> }
> }
> {code}
> all detailed info, how to reproduce in attach.
> debug shows that function {code} processResourceRequest(UUID nodeId, 
> GridDeploymentRequest req) {code} return classLoader {code} ClassLoader ldr = 
> dep.classLoader(); {code} not that expected (that was setting throught 
> icfg.setClassLoader(igniteLoader);) but classLoader from {code} 
> ignite.compute().affinityCall("cache", i, igniteCallable); {code}{code} 
> igniteCallable {code} object.
> All source for reproduce can be found in attach.



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3430:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-3430 .NET: Enable TransactionScope API again, fix and improve tests



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

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

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

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


commit 67bff84adde9810a44b3d2f4e0807830a03a42b9
Author: Pavel Tupitsyn 
Date:   2017-02-02T13:50:54Z

IGNITE-3430 enable functionality back, unignore and fix tests

commit 0a184515d44e5b32c639e465c37cf7e5fa731068
Author: Pavel Tupitsyn 
Date:   2017-02-02T13:59:06Z

Test all isolation levels




> .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-4647) ComputeTask with custom classLoader fail

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny updated IGNITE-4647:
---
Attachment: repro-2813.tar.gz

> ComputeTask with custom classLoader fail
> 
>
> Key: IGNITE-4647
> URL: https://issues.apache.org/jira/browse/IGNITE-4647
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Affects Versions: 2.0
>Reporter: Stanilovsky Evgeny
>Priority: Minor
> Attachments: repro-2813.tar.gz
>
>
> In case, when we want to run ComputeTask with custom classLoader and custom 
> inherited IgniteCallable class initialized with instance from custom loader, 
> catch error *java.lang.ClassNotFoundException*. 
> -- deploy node code --
> IgniteConfiguration icfg = new IgniteConfiguration();
> icfg.setGridName("grid");
> icfg.setPeerClassLoadingEnabled(true);
> icfg.setClassLoader(igniteLoader);
> --client code --
> IgniteConfiguration icfg = new IgniteConfiguration();
> icfg.setGridName("grid");
> icfg.setPeerClassLoadingEnabled(true);
> all detailed info, how to reproduce in attach.
> debug shows that function {code} processResourceRequest(UUID nodeId, 
> GridDeploymentRequest req) {code} return classLoader {code} ClassLoader ldr = 
> dep.classLoader(); {code} not that expected (that was setting throught 
> icfg.setClassLoader(igniteLoader);) but classLoader from {code} 
> ignite.compute().affinityCall("cache", i, igniteCallable); {code}{code} 
> igniteCallable {code} object.
> All source for reproduce can be found in attach.



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

[jira] [Updated] (IGNITE-4647) ComputeTask with custom classLoader fail

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny updated IGNITE-4647:
---
Attachment: (was: repro-2813.tar.gz)

> ComputeTask with custom classLoader fail
> 
>
> Key: IGNITE-4647
> URL: https://issues.apache.org/jira/browse/IGNITE-4647
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Affects Versions: 2.0
>Reporter: Stanilovsky Evgeny
>Priority: Minor
> Attachments: repro-2813.tar.gz
>
>
> In case, when we want to run ComputeTask with custom classLoader and custom 
> inherited IgniteCallable class initialized with instance from custom loader, 
> catch error *java.lang.ClassNotFoundException*. 
> -- deploy node code --
> IgniteConfiguration icfg = new IgniteConfiguration();
> icfg.setGridName("grid");
> icfg.setPeerClassLoadingEnabled(true);
> icfg.setClassLoader(igniteLoader);
> --client code --
> IgniteConfiguration icfg = new IgniteConfiguration();
> icfg.setGridName("grid");
> icfg.setPeerClassLoadingEnabled(true);
> all detailed info, how to reproduce in attach.
> debug shows that function {code} processResourceRequest(UUID nodeId, 
> GridDeploymentRequest req) {code} return classLoader {code} ClassLoader ldr = 
> dep.classLoader(); {code} not that expected (that was setting throught 
> icfg.setClassLoader(igniteLoader);) but classLoader from {code} 
> ignite.compute().affinityCall("cache", i, igniteCallable); {code}{code} 
> igniteCallable {code} object.
> All source for reproduce can be found in attach.



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

[jira] [Updated] (IGNITE-4648) IgniteInternalTx.prepare() does not wait for async operations to complete

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-4648:
---
Summary: IgniteInternalTx.prepare() does not wait for async operations to 
complete  (was: TransactionProxyImpl.prepare() does not wait for async 
operations to complete)

> IgniteInternalTx.prepare() does not wait for async operations to complete
> -
>
> Key: IGNITE-4648
> URL: https://issues.apache.org/jira/browse/IGNITE-4648
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7
>Reporter: Pavel Tupitsyn
>Priority: Minor
> Fix For: 2.1
>
>
> {{commit}} and {{rollback}} wait for async operations by calling 
> {{tx.txState().awaitLastFut();}} (see {{GridCacheSharedContext}}).
> There is no such thing in {{IgniteInternalTx.prepare()}} implementations.
> Since {{prepare}} is an internal method, this is not an issue mostly, except 
> for two things:
> * JTA. {{CacheJtaResource}} calls {{prepare()}} explicitly. 
> * .NET {{TransactionScope}} API. Same thing as JTA, basically. 
> {{PlatformTransactions}} call {{prepare()}} as well.
> As a result, if user starts an async operation within JTA transaction and 
> then completes the tx, undefined behavior is possible.



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

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


Found the problem:
* {{TestTransactionScopeAllOperations}} does not call {{.Wait()}} on some async 
operations
* {{CacheTransactionManager}} calls {{prepare()}} when committing the 
transaction
* {{TransactionProxyImpl.prepare()}} is not a public API, so it does not wait 
for all transactional operations to complete (like {{commit()}} does)

Ticket created: IGNITE-4648

For now we can fix the test and say that we do not support incomplete async 
operations within {{TransactionScope}}.


was (Author: ptupitsyn):
Found the problem:
* {{TestTransactionScopeAllOperations}} does not call {{.Wait()}} on some async 
operations
* {{CacheTransactionManager}} calls {{prepare()}} when committing the 
transaction
* {{TransactionProxyImpl.prepare()}} is not a public API, so it does not wait 
for all transactional operations to complete (like {{commit()}} does)

> .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] [Created] (IGNITE-4648) TransactionProxyImpl.prepare() does not wait for async operations to complete

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4648:
--

 Summary: TransactionProxyImpl.prepare() does not wait for async 
operations to complete
 Key: IGNITE-4648
 URL: https://issues.apache.org/jira/browse/IGNITE-4648
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.7
Reporter: Pavel Tupitsyn
Priority: Minor
 Fix For: 2.1


{{commit}} and {{rollback}} wait for async operations by calling 
{{tx.txState().awaitLastFut();}} (see {{GridCacheSharedContext}}).

There is no such thing in {{IgniteInternalTx.prepare()}} implementations.

Since {{prepare}} is an internal method, this is not an issue mostly, except 
for two things:
* JTA. {{CacheJtaResource}} calls {{prepare()}} explicitly. 
* .NET {{TransactionScope}} API. Same thing as JTA, basically. 
{{PlatformTransactions}} call {{prepare()}} as well.


As a result, if user starts an async operation within JTA transaction and then 
completes the tx, undefined behavior is possible.



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

Pavel Tupitsyn commented on IGNITE-3430:


Found the problem:
* {{TestTransactionScopeAllOperations}} does not call {{.Wait()}} on some async 
operations
* {{CacheTransactionManager}} calls {{prepare()}} when committing the 
transaction
* {{TransactionProxyImpl.prepare()}} is not a public API, so it does not wait 
for all transactional operations to complete (like {{commit()}} does)

> .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] [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=15849890#comment-15849890
 ] 

Andrew Mashenkov commented on IGNITE-4564:
--

Done.

Another issues was found and I've send them to dev list [1].

[1] 
http://apache-ignite-developers.2346864.n4.nabble.com/Ensure-that-builder-approach-is-used-for-all-setters-in-public-API-td14222.html

> 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] [Updated] (IGNITE-4647) ComputeTask with custom classLoader fail

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny updated IGNITE-4647:
---
Attachment: repro-2813.tar.gz

> ComputeTask with custom classLoader fail
> 
>
> Key: IGNITE-4647
> URL: https://issues.apache.org/jira/browse/IGNITE-4647
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Affects Versions: 2.0
>Reporter: Stanilovsky Evgeny
>Priority: Minor
> Attachments: repro-2813.tar.gz
>
>
> In case, when we want to run ComputeTask with custom classLoader and custom 
> inherited IgniteCallable class initialized with instance from custom loader, 
> catch error *java.lang.ClassNotFoundException*. 
> -- deploy node code --
> IgniteConfiguration icfg = new IgniteConfiguration();
> icfg.setGridName("grid");
> icfg.setPeerClassLoadingEnabled(true);
> icfg.setClassLoader(igniteLoader);
> --client code --
> IgniteConfiguration icfg = new IgniteConfiguration();
> icfg.setGridName("grid");
> icfg.setPeerClassLoadingEnabled(true);
> all detailed info, how to reproduce in attach.
> debug shows that function {code} processResourceRequest(UUID nodeId, 
> GridDeploymentRequest req) {code} return classLoader {code} ClassLoader ldr = 
> dep.classLoader(); {code} not that expected (that was setting throught 
> icfg.setClassLoader(igniteLoader);) but classLoader from {code} 
> ignite.compute().affinityCall("cache", i, igniteCallable); {code}{code} 
> igniteCallable {code} object.



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

[jira] [Created] (IGNITE-4647) ComputeTask with custom classLoader fail

[Stanilovsky Evgeny (JIRA)]

Stanilovsky Evgeny created IGNITE-4647:
--

 Summary: ComputeTask with custom classLoader fail
 Key: IGNITE-4647
 URL: https://issues.apache.org/jira/browse/IGNITE-4647
 Project: Ignite
  Issue Type: Bug
  Components: compute
Affects Versions: 2.0
Reporter: Stanilovsky Evgeny
Priority: Minor
 Attachments: repro-2813.tar.gz

In case, when we want to run ComputeTask with custom classLoader and custom 
inherited IgniteCallable class initialized with instance from custom loader, 
catch error *java.lang.ClassNotFoundException*. 

-- deploy node code --
IgniteConfiguration icfg = new IgniteConfiguration();
icfg.setGridName("grid");
icfg.setPeerClassLoadingEnabled(true);
icfg.setClassLoader(igniteLoader);

--client code --
IgniteConfiguration icfg = new IgniteConfiguration();
icfg.setGridName("grid");
icfg.setPeerClassLoadingEnabled(true);

all detailed info, how to reproduce in attach.

debug shows that function {code} processResourceRequest(UUID nodeId, 
GridDeploymentRequest req) {code} return classLoader {code} ClassLoader ldr = 
dep.classLoader(); {code} not that expected (that was setting throught 
icfg.setClassLoader(igniteLoader);) but classLoader from {code} 
ignite.compute().affinityCall("cache", i, igniteCallable); {code}{code} 
igniteCallable {code} object.



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

[jira] [Updated] (IGNITE-4647) ComputeTask with custom classLoader fail

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny updated IGNITE-4647:
---
Description: 
In case, when we want to run ComputeTask with custom classLoader and custom 
inherited IgniteCallable class initialized with instance from custom loader, 
catch error *java.lang.ClassNotFoundException*. 

-- deploy node code --
IgniteConfiguration icfg = new IgniteConfiguration();
icfg.setGridName("grid");
icfg.setPeerClassLoadingEnabled(true);
icfg.setClassLoader(igniteLoader);

--client code --
IgniteConfiguration icfg = new IgniteConfiguration();
icfg.setGridName("grid");
icfg.setPeerClassLoadingEnabled(true);

all detailed info, how to reproduce in attach.

debug shows that function {code} processResourceRequest(UUID nodeId, 
GridDeploymentRequest req) {code} return classLoader {code} ClassLoader ldr = 
dep.classLoader(); {code} not that expected (that was setting throught 
icfg.setClassLoader(igniteLoader);) but classLoader from {code} 
ignite.compute().affinityCall("cache", i, igniteCallable); {code}{code} 
igniteCallable {code} object.

All source for reproduce can be found in attach.

  was:
In case, when we want to run ComputeTask with custom classLoader and custom 
inherited IgniteCallable class initialized with instance from custom loader, 
catch error *java.lang.ClassNotFoundException*. 

-- deploy node code --
IgniteConfiguration icfg = new IgniteConfiguration();
icfg.setGridName("grid");
icfg.setPeerClassLoadingEnabled(true);
icfg.setClassLoader(igniteLoader);

--client code --
IgniteConfiguration icfg = new IgniteConfiguration();
icfg.setGridName("grid");
icfg.setPeerClassLoadingEnabled(true);

all detailed info, how to reproduce in attach.

debug shows that function {code} processResourceRequest(UUID nodeId, 
GridDeploymentRequest req) {code} return classLoader {code} ClassLoader ldr = 
dep.classLoader(); {code} not that expected (that was setting throught 
icfg.setClassLoader(igniteLoader);) but classLoader from {code} 
ignite.compute().affinityCall("cache", i, igniteCallable); {code}{code} 
igniteCallable {code} object.


> ComputeTask with custom classLoader fail
> 
>
> Key: IGNITE-4647
> URL: https://issues.apache.org/jira/browse/IGNITE-4647
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Affects Versions: 2.0
>Reporter: Stanilovsky Evgeny
>Priority: Minor
> Attachments: repro-2813.tar.gz
>
>
> In case, when we want to run ComputeTask with custom classLoader and custom 
> inherited IgniteCallable class initialized with instance from custom loader, 
> catch error *java.lang.ClassNotFoundException*. 
> -- deploy node code --
> IgniteConfiguration icfg = new IgniteConfiguration();
> icfg.setGridName("grid");
> icfg.setPeerClassLoadingEnabled(true);
> icfg.setClassLoader(igniteLoader);
> --client code --
> IgniteConfiguration icfg = new IgniteConfiguration();
> icfg.setGridName("grid");
> icfg.setPeerClassLoadingEnabled(true);
> all detailed info, how to reproduce in attach.
> debug shows that function {code} processResourceRequest(UUID nodeId, 
> GridDeploymentRequest req) {code} return classLoader {code} ClassLoader ldr = 
> dep.classLoader(); {code} not that expected (that was setting throught 
> icfg.setClassLoader(igniteLoader);) but classLoader from {code} 
> ignite.compute().affinityCall("cache", i, igniteCallable); {code}{code} 
> igniteCallable {code} object.
> All source for reproduce can be found in attach.



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

[jira] [Commented] (IGNITE-4583) Async API: Other components refactoring

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-4583:
--

Vladimir, the JavaDocs comments are reviewed, tests for new async API for 
{{IgniteServices}} are added.

> Async API: Other components refactoring
> ---
>
> Key: IGNITE-4583
> URL: https://issues.apache.org/jira/browse/IGNITE-4583
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Affects Versions: 1.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> Refactoring the {{IgniteCluster, IgniteEvents, IgniteMessaging, 
> IgniteServices}} to simplify async API.



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

[jira] [Commented] (IGNITE-4646) Try to unmarshall direct messages in striped pool

[Yakov Zhdanov (JIRA)]

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

Yakov Zhdanov commented on IGNITE-4646:
---

[~vozerov]
Agree, let's use 32 bits
Good point on direct reader optimizations
Well, nobody knows how this will affect the system. Let's implement and 
measure. I think that there will be positive effect - more work in stripes and 
less parks and we also move work from NIO workers that are limited to stripes 
which we have times more in the system. It seems just to be better from 
resource usage standpoint. And we will probably apply default for 2-4 NIO 
workers instead of half CPU count.

> Try to unmarshall direct messages in striped pool
> -
>
> Key: IGNITE-4646
> URL: https://issues.apache.org/jira/browse/IGNITE-4646
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: Igor Seliverstov
> Fix For: 2.0
>
>
> During marshalling in NIO thread the following should be added to the write 
> buffer and sent to peer:
> 1. chunk size - 16 bits (this probably puts limitation on max write buffer 
> size of 64k or will require some changes to direct writer)
> 2. last  chunk - 1 bit
> 3. pool policy - 8 bits
> Here is the scheme to explain how this should work.
> {noformat}
> [chunk size] [pool policy] [partition] [last flag] [chunk data] X <-- no more 
> space in write buffer
> [next chunk size] [last flag] [chunk data] <<-- we write next chunk once some 
> space is available in write buffer, but we skip partition and policy flags 
> and maybe others that should be sent only once.
> ...
> ...
> [next chunk size] [last flag] [chunk data] <<-- last flag is true here
> {noformat}
> Examples
> Write buffer - 64k
> Message - 84k
> # sender reserves space for chunk size
> # reserves space for policy and last chunk flag
> # marshalls message to buffer while it has free space (64k - SPACE will be 
> written to buffer)
> # puts size and flags to reserved space in the beginning
> # sends buffer or part of it which makes some space available to further 
> writes
> # reserves space for next chunk size and flags
> # marshalls message to buffer while it has free space (lets assume the rest 
> of message fits)
> # puts size and last=true to the reserved space and sends
> Receiver:
> # reads chunk size, stores the target pool and partition
> # allocates heap buffer and copies chunk data to it from read buffer
> # once all message chunks are fully read message should be submitted to a 
> pool where it will be unmarshalled and processed



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

Pavel Tupitsyn commented on IGNITE-3430:


We need to run {{TestTransactionScopeAllOperations}} in different tx modes 
later.

> .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] [Commented] (IGNITE-4646) Try to unmarshall direct messages in striped pool

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4646:
-

[~yzhdanov],
Setting hard limit to max buffer size is bad idea because modern high-end NICs 
can have buffers of hundreds KBs and more. I do not see a reason for economy in 
several bytes, let's just dedicate {{INT}} for chunk size. It will add 1-2% 
overhead to message - negligible IMO.

Another important implication of this changes is that we can get rid of all 
complex logic in reader. No "available data" checks, no boundary checks. Just 
go through array with {{Unsafe}}. 

Bad news is that I already tried what you desribed (remember my coding on 
Joker? :)) and it didn't give any improvement. However, it was done before 
striped pool optimization.

> Try to unmarshall direct messages in striped pool
> -
>
> Key: IGNITE-4646
> URL: https://issues.apache.org/jira/browse/IGNITE-4646
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: Igor Seliverstov
> Fix For: 2.0
>
>
> During marshalling in NIO thread the following should be added to the write 
> buffer and sent to peer:
> 1. chunk size - 16 bits (this probably puts limitation on max write buffer 
> size of 64k or will require some changes to direct writer)
> 2. last  chunk - 1 bit
> 3. pool policy - 8 bits
> Here is the scheme to explain how this should work.
> {noformat}
> [chunk size] [pool policy] [partition] [last flag] [chunk data] X <-- no more 
> space in write buffer
> [next chunk size] [last flag] [chunk data] <<-- we write next chunk once some 
> space is available in write buffer, but we skip partition and policy flags 
> and maybe others that should be sent only once.
> ...
> ...
> [next chunk size] [last flag] [chunk data] <<-- last flag is true here
> {noformat}
> Examples
> Write buffer - 64k
> Message - 84k
> # sender reserves space for chunk size
> # reserves space for policy and last chunk flag
> # marshalls message to buffer while it has free space (64k - SPACE will be 
> written to buffer)
> # puts size and flags to reserved space in the beginning
> # sends buffer or part of it which makes some space available to further 
> writes
> # reserves space for next chunk size and flags
> # marshalls message to buffer while it has free space (lets assume the rest 
> of message fits)
> # puts size and last=true to the reserved space and sends
> Receiver:
> # reads chunk size, stores the target pool and partition
> # allocates heap buffer and copies chunk data to it from read buffer
> # once all message chunks are fully read message should be submitted to a 
> pool where it will be unmarshalled and processed



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

[jira] [Assigned] (IGNITE-4646) Try to unmarshall direct messages in striped pool

[Igor Seliverstov (JIRA)]

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

Igor Seliverstov reassigned IGNITE-4646:


Assignee: Igor Seliverstov

> Try to unmarshall direct messages in striped pool
> -
>
> Key: IGNITE-4646
> URL: https://issues.apache.org/jira/browse/IGNITE-4646
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: Igor Seliverstov
> Fix For: 2.0
>
>
> During marshalling in NIO thread the following should be added to the write 
> buffer and sent to peer:
> 1. chunk size - 16 bits (this probably puts limitation on max write buffer 
> size of 64k or will require some changes to direct writer)
> 2. last  chunk - 1 bit
> 3. pool policy - 8 bits
> Here is the scheme to explain how this should work.
> {noformat}
> [chunk size] [pool policy] [partition] [last flag] [chunk data] X <-- no more 
> space in write buffer
> [next chunk size] [last flag] [chunk data] <<-- we write next chunk once some 
> space is available in write buffer, but we skip partition and policy flags 
> and maybe others that should be sent only once.
> ...
> ...
> [next chunk size] [last flag] [chunk data] <<-- last flag is true here
> {noformat}
> Examples
> Write buffer - 64k
> Message - 84k
> # sender reserves space for chunk size
> # reserves space for policy and last chunk flag
> # marshalls message to buffer while it has free space (64k - SPACE will be 
> written to buffer)
> # puts size and flags to reserved space in the beginning
> # sends buffer or part of it which makes some space available to further 
> writes
> # reserves space for next chunk size and flags
> # marshalls message to buffer while it has free space (lets assume the rest 
> of message fits)
> # puts size and last=true to the reserved space and sends
> Receiver:
> # reads chunk size, stores the target pool and partition
> # allocates heap buffer and copies chunk data to it from read buffer
> # once all message chunks are fully read message should be submitted to a 
> pool where it will be unmarshalled and processed



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-4363:
---

Assignee: Alexander Paschenko  (was: Vladimir Ozerov)

[~al.psc],
It seems that this fix conflicts with some other SQL change related to 
properties. Could you please re-merge from {{master}} and resolve the conflict?

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



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

[jira] [Created] (IGNITE-4646) Try to unmarshall direct messages in striped pool

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-4646:
-

 Summary: Try to unmarshall direct messages in striped pool
 Key: IGNITE-4646
 URL: https://issues.apache.org/jira/browse/IGNITE-4646
 Project: Ignite
  Issue Type: Improvement
Reporter: Yakov Zhdanov
 Fix For: 2.0


During marshalling in NIO thread the following should be added to the write 
buffer and sent to peer:
1. chunk size - 16 bits (this probably puts limitation on max write buffer size 
of 64k or will require some changes to direct writer)
2. last  chunk - 1 bit
3. pool policy - 8 bits

Here is the scheme to explain how this should work.
{noformat}
[chunk size] [pool policy] [partition] [last flag] [chunk data] X <-- no more 
space in write buffer
[next chunk size] [last flag] [chunk data] <<-- we write next chunk once some 
space is available in write buffer, but we skip partition and policy flags and 
maybe others that should be sent only once.
...
...
[next chunk size] [last flag] [chunk data] <<-- last flag is true here
{noformat}

Examples
Write buffer - 64k
Message - 84k

# sender reserves space for chunk size
# reserves space for policy and last chunk flag
# marshalls message to buffer while it has free space (64k - SPACE will be 
written to buffer)
# puts size and flags to reserved space in the beginning
# sends buffer or part of it which makes some space available to further writes
# reserves space for next chunk size and flags
# marshalls message to buffer while it has free space (lets assume the rest of 
message fits)
# puts size and last=true to the reserved space and sends

Receiver:
# reads chunk size, stores the target pool and partition
# allocates heap buffer and copies chunk data to it from read buffer
# once all message chunks are fully read message should be submitted to a pool 
where it will be unmarshalled and processed




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

[jira] [Assigned] (IGNITE-4645) Best effort to avoid extra copying in binary marshaller

[Igor Seliverstov (JIRA)]

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

Igor Seliverstov reassigned IGNITE-4645:


Assignee: Igor Seliverstov

> Best effort to avoid extra copying in binary marshaller
> ---
>
> Key: IGNITE-4645
> URL: https://issues.apache.org/jira/browse/IGNITE-4645
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Reporter: Yakov Zhdanov
>Assignee: Igor Seliverstov
> Fix For: 1.9
>
>
> If we marshal a class that contain only primitives then we can predict the 
> final byte array size and avoid copies to grow array and final trimming.



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

[jira] [Created] (IGNITE-4645) Best effort to avoid extra copying in binary marshaller

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-4645:
-

 Summary: Best effort to avoid extra copying in binary marshaller
 Key: IGNITE-4645
 URL: https://issues.apache.org/jira/browse/IGNITE-4645
 Project: Ignite
  Issue Type: Bug
  Components: binary
Reporter: Yakov Zhdanov
 Fix For: 1.9


If we marshal a class that contain only primitives then we can predict the 
final byte array size and avoid copies to grow array and final trimming.



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

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

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko reassigned IGNITE-4633:
---

Assignee: Alexander Paschenko

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



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

[jira] [Commented] (IGNITE-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=15849720#comment-15849720
 ] 

Pavel Tupitsyn commented on IGNITE-3430:


Java has {{TransactionConfiguration.UseJtaSynchronization}} property (false by 
default).
When false, {{prepare}} is never called from {{CacheJtaResource}}. We could add 
the same option in .NET, but I'm not sure if this really provides any benefits.

> .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-4644) Value from IgniteQueue in atomic mode could be lost

[Dmitry Karachentsev (JIRA)]

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

Dmitry Karachentsev updated IGNITE-4644:

Description: 
Assume following case (operations are going concurrently):
1) Client1 -> offer. Add new index in queue.
2) On Client1 happens JVM pause or short-time problem with connectivity to 
cluster longer than 3 sec.
3) Client2 -> poll. Get index from cache, but no value available.
4) Client2 checks for value about 3 sec and if no value appears, just skips it.

Should be fixed somehow or make timeout configurable.

  was:
Assume following case (operations are going concurrently):
1) Client1 -> offer. Add new index in queue.
2) On Client1 happens JVM pause or short-time problem with connectivity to 
cluster longer than 3 sec.
3) Client2 -> poll. Get index from cache, but no value available.
4) Client2 checks for value about 3 sec and if no value appears, just skip it.

Should be fixed somehow or make timeout configurable.


> Value from IgniteQueue in atomic mode could be lost
> ---
>
> Key: IGNITE-4644
> URL: https://issues.apache.org/jira/browse/IGNITE-4644
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Dmitry Karachentsev
>
> Assume following case (operations are going concurrently):
> 1) Client1 -> offer. Add new index in queue.
> 2) On Client1 happens JVM pause or short-time problem with connectivity to 
> cluster longer than 3 sec.
> 3) Client2 -> poll. Get index from cache, but no value available.
> 4) Client2 checks for value about 3 sec and if no value appears, just skips 
> it.
> Should be fixed somehow or make timeout configurable.



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

[jira] [Updated] (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 updated IGNITE-4612:
-
Fix Version/s: (was: 1.8)
   1.9

> 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.9
>
>
> 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] [Assigned] (IGNITE-4475) Simplify async API

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-4475:
---

Assignee: (was: Taras Ledkov)

> Simplify async API
> --
>
> Key: IGNITE-4475
> URL: https://issues.apache.org/jira/browse/IGNITE-4475
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> *Problem*
> We need to simplify our async API. It is to complex and verbose at the moment:
> {code}
> IgniteCache asyncCache = cache.withAsync();
> asyncCache.get(key);
> IgniteFuture fut = asyncCache.future();
> {code}
> *Proposed solution*
> 1) Deprecate {{IgniteAsyncSupport}} interface.
> 2) Make async operations more straightforward:
> {code}
> IgniteFuture fut = cache.getAsync(key);
> {code}
> *Scope*
> ~80 async methods in all public interfaces.
> Base branch: {{ignite-4475-async}}



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

[jira] [Created] (IGNITE-4644) Value from IgniteQueue in atomic mode could be lost

[Dmitry Karachentsev (JIRA)]

Dmitry Karachentsev created IGNITE-4644:
---

 Summary: Value from IgniteQueue in atomic mode could be lost
 Key: IGNITE-4644
 URL: https://issues.apache.org/jira/browse/IGNITE-4644
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.8
Reporter: Dmitry Karachentsev


Assume following case (operations are going concurrently):
1) Client1 -> offer. Add new index in queue.
2) On Client1 happens JVM pause or short-time problem with connectivity to 
cluster longer than 3 sec.
3) Client2 -> poll. Get index from cache, but no value available.
4) Client2 checks for value about 3 sec and if no value appears, just skip it.

Should be fixed somehow or make timeout configurable.



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

[jira] [Updated] (IGNITE-4475) Simplify async API

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4475:

Description: 
*Problem*
We need to simplify our async API. It is to complex and verbose at the moment:
{code}
IgniteCache asyncCache = cache.withAsync();
asyncCache.get(key);
IgniteFuture fut = asyncCache.future();
{code}

*Proposed solution*
1) Deprecate {{IgniteAsyncSupport}} interface.
2) Make async operations more straightforward:
{code}
IgniteFuture fut = cache.getAsync(key);
{code}

*Scope*
~80 async methods in all public interfaces.

Base branch: {{ignite-4475-async}}

  was:
*Problem*
We need to simplify our async API. It is to complex and verbose at the moment:
{code}
IgniteCache asyncCache = cache.withAsync();
asyncCache.get(key);
IgniteFuture fut = asyncCache.future();
{code}

*Proposed solution*
1) Deprecate {{IgniteAsyncSupport}} interface.
2) Make async operations more straightforward:
{code}
IgniteFuture fut = cache.getAsync(key);
{code}

*Scope*
~80 async methods in all public interfaces.


> Simplify async API
> --
>
> Key: IGNITE-4475
> URL: https://issues.apache.org/jira/browse/IGNITE-4475
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> *Problem*
> We need to simplify our async API. It is to complex and verbose at the moment:
> {code}
> IgniteCache asyncCache = cache.withAsync();
> asyncCache.get(key);
> IgniteFuture fut = asyncCache.future();
> {code}
> *Proposed solution*
> 1) Deprecate {{IgniteAsyncSupport}} interface.
> 2) Make async operations more straightforward:
> {code}
> IgniteFuture fut = cache.getAsync(key);
> {code}
> *Scope*
> ~80 async methods in all public interfaces.
> Base branch: {{ignite-4475-async}}



--
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.

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-3625:
--

[~akuznetsov], the issue of exception message is fixed. Please review.

> 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] [Resolved] (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 resolved IGNITE-4570.
-
Resolution: Fixed

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

Vladimir Ozerov commented on IGNITE-4570:
-

Merged to {{ignite-4565-ddl}} branch.

> 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] [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

Base branch: {{ignite-4565-ddl}}

  was:
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
> 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
> Base branch: {{ignite-4565-ddl}}



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

Vladimir Ozerov commented on IGNITE-4570:
-

Alex, several comments from my side before we go ahead with merge:
1) I fixed several code style violations. Please review them.
2) Please merge it with {{ignite-2.0}}. Currently it is merged only with master.
3) I do not like {{UNSUPPORTED_TOKEN}} error. It is no different from 
{{UNSUPPORTED_OPERATION}}. Let's remove it and use {{UNSUPPORTED_OPERATION}} 
instead.

> 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] [Commented] (IGNITE-4570) Handle CREATE INDEX statements

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko commented on IGNITE-4570:
-

[~vozerov] fixed, please check

> 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)