[jira] [Commented] (IGNITE-3877) Clarify if IgfsFile -> FileStatus conversion should treat groupBlockSize as blockSize

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-3877:
-

Closing as the whole fix is inside IGNITE-481.

> Clarify if IgfsFile -> FileStatus conversion should treat groupBlockSize as 
> blockSize
> -
>
> Key: IGNITE-3877
> URL: https://issues.apache.org/jira/browse/IGNITE-3877
> Project: Ignite
>  Issue Type: Bug
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Ivan Veselovsky
>Assignee: Vladimir Ozerov
> Fix For: 2.0
>
>
> During Metrics tests repairing test 
> org.apache.ignite.igfs.Hadoop1DualAbstractTest#testMetricsBlock revealed the 
> following problem:
> org.apache.ignite.hadoop.fs.v1.IgniteHadoopFileSystem#convert(org.apache.ignite.igfs.IgfsFile)
>  method treats groupBlockSize as blockSize for Hadoop FileStatus. 
> groupBlockSize can be several times larger than blockSize, so blockSize in 
> status gets different to that in original IgfsFile .
> changing file.groupBlockSize() to file.blockSize()  fixes problem in metrics 
> tests, but creates problems in Hadoop tests that are bound to splits 
> calculation, since split calculation related to blockSizes.
> Need to 
> 1) clarify if the treatment of groupBlcokSize was intentional.
> 2) fix either metrics tests or Hadoop tests. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (IGNITE-3877) Clarify if IgfsFile -> FileStatus conversion should treat groupBlockSize as blockSize

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-3877.
---

> Clarify if IgfsFile -> FileStatus conversion should treat groupBlockSize as 
> blockSize
> -
>
> Key: IGNITE-3877
> URL: https://issues.apache.org/jira/browse/IGNITE-3877
> Project: Ignite
>  Issue Type: Bug
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Ivan Veselovsky
>Assignee: Vladimir Ozerov
> Fix For: 2.0
>
>
> During Metrics tests repairing test 
> org.apache.ignite.igfs.Hadoop1DualAbstractTest#testMetricsBlock revealed the 
> following problem:
> org.apache.ignite.hadoop.fs.v1.IgniteHadoopFileSystem#convert(org.apache.ignite.igfs.IgfsFile)
>  method treats groupBlockSize as blockSize for Hadoop FileStatus. 
> groupBlockSize can be several times larger than blockSize, so blockSize in 
> status gets different to that in original IgfsFile .
> changing file.groupBlockSize() to file.blockSize()  fixes problem in metrics 
> tests, but creates problems in Hadoop tests that are bound to splits 
> calculation, since split calculation related to blockSizes.
> Need to 
> 1) clarify if the treatment of groupBlcokSize was intentional.
> 2) fix either metrics tests or Hadoop tests. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-4442) Web console: Implement configuration of affinity function in cache configuration.

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-4442:
-
Fix Version/s: (was: 1.9)
   2.0

> Web console: Implement configuration of affinity function in cache 
> configuration.
> -
>
> Key: IGNITE-4442
> URL: https://issues.apache.org/jira/browse/IGNITE-4442
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 1.8
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
> Fix For: 2.0
>
>
> Also implement custom configuration of cache store.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-4442) Web console: Implement configuration of affinity function in cache configuration.

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-4442:
-
Affects Version/s: (was: 1.9)
   1.8

> Web console: Implement configuration of affinity function in cache 
> configuration.
> -
>
> Key: IGNITE-4442
> URL: https://issues.apache.org/jira/browse/IGNITE-4442
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 1.8
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
> Fix For: 1.9
>
>
> Also implement custom configuration of cache store.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[Andrey Novikov (JIRA)]

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

Andrey Novikov edited comment on IGNITE-4472 at 12/29/16 7:33 AM:
--

Reviewed. Renamed methods.
statisticsService should return promise with data, Rename statistics.service.js 
to Statistics.data.js


was (Author: anovikov):
Reviewed. Rename methods.
statisticsService should return promise with data, Rename statistics.service.js 
to Statistics.data.js

> 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
>
> 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.4#6332)

[jira] [Commented] (IGNITE-4442) Web console: Implement configuration of affinity function in cache configuration.

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-4442:


Tested.

> Web console: Implement configuration of affinity function in cache 
> configuration.
> -
>
> Key: IGNITE-4442
> URL: https://issues.apache.org/jira/browse/IGNITE-4442
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 1.9
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
> Fix For: 1.9
>
>
> Also implement custom configuration of cache store.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-4442) Web console: Implement configuration of affinity function in cache configuration.

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-4442:
---
Assignee: Alexey Kuznetsov  (was: Pavel Konstantinov)

> Web console: Implement configuration of affinity function in cache 
> configuration.
> -
>
> Key: IGNITE-4442
> URL: https://issues.apache.org/jira/browse/IGNITE-4442
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 1.9
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
> Fix For: 1.9
>
>
> Also implement custom configuration of cache store.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-1997) "Query entities can be set only once." error on node start

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-1997:
---
Assignee: (was: Pavel Konstantinov)

> "Query entities can be set only once." error on node start
> --
>
> Key: IGNITE-1997
> URL: https://issues.apache.org/jira/browse/IGNITE-1997
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>
> I'm faced with this error in case when one cache has "queryEntities" and 
> other cache has "cacheTypeMetadata".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-3878:
-

[~dreamx], if you think the ticket is ready for review please change the status 
from "in progress" to "patch available". Also make sure you have added 
additional tests to check your functionality and validated the changes on Team 
City. Refer to this documentation section for more details
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-1.CreateGitHubpull-request

> 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.4#6332)

[jira] [Commented] (IGNITE-4157) Use discovery custom messages instead of marshaller cache

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov commented on IGNITE-4157:
-

Reviewed code before reopening pull request, made several improvements and 
added more documentation comments.

> Use discovery custom messages instead of marshaller cache
> -
>
> Key: IGNITE-4157
> URL: https://issues.apache.org/jira/browse/IGNITE-4157
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Sergey Chugunov
> Fix For: 2.0
>
>
> Currently we use system caches for keeping classname to class ID mapping and 
> for storing binary metadata
> This has several serious disadvantages:
> 1) We need to introduce at least two additional thread pools for each of 
> these caches
> 2) Since cache operations require stable topology, registering a class ID or 
> updating metadata inside a transaction or another cache operation is tricky 
> and deadlock-prone.
> 3) It may be beneficial in some cases to have nodes with no caches at all, 
> currently this is impossible because system caches are always present.
> 4) Reading binary metadata leads to huge local contention, caching metadata 
> values in a local map doubles memory consumption
> I suggest we use discovery custom events for these purposes. Each node will 
> have a corresponding local map (state) which will be updated inside custom 
> event handler. From the first point of view, this should remove all the 
> disadvantages above.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Oleg Ostanin commented on IGNITE-4212:
--

Thank you for your response. I have placed source files in the 
release-package/benchmarks directory along with compiled module. 

> 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.4#6332)

[jira] [Comment Edited] (IGNITE-1680) CPP: Implement basic API for user entry point lookup

[Igor Sapego (JIRA)]

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

Igor Sapego edited comment on IGNITE-1680 at 12/28/16 4:45 PM:
---

Vladimir,

1) Ok, already done.
2) Yeah, that's how it's implemented currently.
3) I like {{IgniteRpc}} the best. Is that OK with you?
4) I will think about it though I would not put such API in public just yet. We 
can always add it in future, once we need it and once we have better 
understanding of what should it be.
5) Do you mean specifying classes/functions in text form that should be called 
upon some event later? No, it's not possible. At least, there is no standard 
way to do that, because C++ does not provide reflection and don't even have 
standardized ABI to write any meaningful workaround code. We can force user to 
declare functions in specific way so that later we are going to be able to find 
and call them in runtime (this is the case with the {{IgniteModuleInit}} 
function - its name actually *can* be specified in textual form in 
configuration file), but we can not do the same with class methods. More than 
that, methods can be virtual and there is no standard ways to store vtable for 
class - it's implementation specific. Summarizing - no, there is no way to do 
that.



was (Author: isapego):
Vladimir,

1) Ok, already done.
2) Yeah, that's how it's implemented currently.
3) I like {{IgniteRpc}} the best. Is that OK with you?
4) I will think about it though I would not put such API in public just yet. We 
can always add it in future, once we need it and once we have better 
understanding of what should it be.
5) Do you mean specifying classes/functions in text form that should be called 
upon some event later? No, it's not possible. At least, there is no standard 
way to do that, because C++ does not provide reflection and don't even have 
standardized ABI to write any meaningful workaround code. We can force user to 
declare functions in specific way so that later we are going to be able to find 
and call them in runtime (this is the case with the {{IgniteModuleInit}} 
function - its name actually *can* be specified in textual form in 
configuration file), but we can not do the same with class methods. More than 
that, methods can be virtual and there is no standard ways to store vtable for 
class.

> CPP: Implement basic API for user entry point lookup
> 
>
> Key: IGNITE-1680
> URL: https://issues.apache.org/jira/browse/IGNITE-1680
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp, roadmap
> Fix For: 2.0
>
>
> Need to implement IgniteCompute class for C++ with one basic method 
> IgniteCompute::Call(...) which will provide basic remote job execution API.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-1680) CPP: Implement basic API for user entry point lookup

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-1680:
-

Vladimir,

1) Ok, already done.
2) Yeah, that's how it's implemented currently.
3) I like {{IgniteRpc}} the best. Is that OK with you?
4) I will think about it though I would not put such API in public just yet. We 
can always add it in future, once we need it and once we have better 
understanding of what should it be.
5) Do you mean specifying classes/functions in text form that should be called 
upon some event later? No, it's not possible. At least, there is no standard 
way to do that, because C++ does not provide reflection and don't even have 
standardized ABI to write any meaningful workaround code. We can force user to 
declare functions in specific way so that later we are going to be able to find 
and call them in runtime (this is the case with the {{IgniteModuleInit}} 
function - its name actually *can* be specified in textual form in 
configuration file), but we can not do the same with class methods. More than 
that, methods can be virtual and there is no standard ways to store vtable for 
class.

> CPP: Implement basic API for user entry point lookup
> 
>
> Key: IGNITE-1680
> URL: https://issues.apache.org/jira/browse/IGNITE-1680
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp, roadmap
> Fix For: 2.0
>
>
> Need to implement IgniteCompute class for C++ with one basic method 
> IgniteCompute::Call(...) which will provide basic remote job execution API.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-4506) Implement thread-per-partition processing for atomic cache updates

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4506:
-

May be we should add {{sendAsync}} methods to {{GridIoManager}} which will 
ensure that message processing happens asynchronously and in correct thread 
pool even for local messages. And your cache logic may simply switch to this 
{{sendAsync}} method. We will certainly need this in other places, so probably 
we should add some common mechanics right now.

> Implement thread-per-partition processing for atomic cache updates
> --
>
> Key: IGNITE-4506
> URL: https://issues.apache.org/jira/browse/IGNITE-4506
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Konstantin Dudkov
> Fix For: 2,0
>
>
> Need implement thread-per-partition processing for atomic cache updates.
> For single key requests remote request should be already processed by striped 
> executor, need fix case when update is mapped on local node - in this case it 
> is processed from calling thread.
> For batched updates need implement per-partition mapping and processing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-4506) Implement thread-per-partition processing for atomic cache updates

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4506:
-

Sam, please see this as well: https://issues.apache.org/jira/browse/IGNITE-4476

> Implement thread-per-partition processing for atomic cache updates
> --
>
> Key: IGNITE-4506
> URL: https://issues.apache.org/jira/browse/IGNITE-4506
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Konstantin Dudkov
> Fix For: 2,0
>
>
> Need implement thread-per-partition processing for atomic cache updates.
> For single key requests remote request should be already processed by striped 
> executor, need fix case when update is mapped on local node - in this case it 
> is processed from calling thread.
> For batched updates need implement per-partition mapping and processing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (IGNITE-4506) Implement thread-per-partition processing for atomic cache updates

[Konstantin Dudkov (JIRA)]

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

Konstantin Dudkov reassigned IGNITE-4506:
-

Assignee: Konstantin Dudkov

> Implement thread-per-partition processing for atomic cache updates
> --
>
> Key: IGNITE-4506
> URL: https://issues.apache.org/jira/browse/IGNITE-4506
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Konstantin Dudkov
> Fix For: 2,0
>
>
> Need implement thread-per-partition processing for atomic cache updates.
> For single key requests remote request should be already processed by striped 
> executor, need fix case when update is mapped on local node - in this case it 
> is processed from calling thread.
> For batched updates need implement per-partition mapping and processing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-4506) Implement thread-per-partition processing for atomic cache updates

[Semen Boikov (JIRA)]

Semen Boikov created IGNITE-4506:


 Summary: Implement thread-per-partition processing for atomic 
cache updates
 Key: IGNITE-4506
 URL: https://issues.apache.org/jira/browse/IGNITE-4506
 Project: Ignite
  Issue Type: Task
  Components: cache
Reporter: Semen Boikov
 Fix For: 2,0


Need implement thread-per-partition processing for atomic cache updates.

For single key requests remote request should be already processed by striped 
executor, need fix case when update is mapped on local node - in this case it 
is processed from calling thread.

For batched updates need implement per-partition mapping and processing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[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: Sub-task
>  Components: hadoop, IGFS
>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.4#6332)

[jira] [Comment Edited] (IGNITE-4459) Hadoop: IgniteHadoopWeightedMapReducePlanner must be default planner

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-4459 at 12/28/16 2:08 PM:


Code review: 
[IGNT-CR-62|http://reviews.ignite.apache.org/ignite/review/IGNT-CR-62]
Re-merged with ignite-2.0 and update the [tests 
result|http://195.239.208.174/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull%2F1391%2Fhead]



was (Author: tledkov-gridgain):
[Tests 
result|http://195.239.208.174/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull%2F1391%2Fhead]
Code review: 
[IGNT-CR-62|http://reviews.ignite.apache.org/ignite/review/IGNT-CR-62]

> Hadoop: IgniteHadoopWeightedMapReducePlanner must be default planner
> 
>
> Key: IGNITE-4459
> URL: https://issues.apache.org/jira/browse/IGNITE-4459
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> It offers much better job distribution as current default implementation. 
> Let's make it default and remove the previous one.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (IGNITE-4504) .NET: Expose default concurrency and isolation on ITransactions

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-4504.

Resolution: Implemented
  Assignee: (was: Pavel Tupitsyn)

Done in master

> .NET: Expose default concurrency and isolation on ITransactions
> ---
>
> Key: IGNITE-4504
> URL: https://issues.apache.org/jira/browse/IGNITE-4504
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.8
>Reporter: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> There are two methods to start an Ignite transaction:
> * {{ITransactions.TxStart()}}
> * {{ITransactions.TxStart(TransactionConcurrency concurrency, 
> TransactionIsolation isolation)}}
> There is no easy way for the user to know which values will be used with the 
> first method, so there is no way to override only one of them.
> But internally we have this information and can easily add 
> {{ITransactions.DefaultTransactionConcurrency}} and 
> {{ITransactions.DefaultTransactionIsolation}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-4505) IGFS docs: remove grid name from endpoint

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4505:

Component/s: IGFS

> IGFS docs: remove grid name from endpoint
> -
>
> Key: IGNITE-4505
> URL: https://issues.apache.org/jira/browse/IGNITE-4505
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, IGFS
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> See IGNITE-4462. We must reflect these changes in docs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-4458) Hadoop: striped shuffle mode must be enabled by default

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-4458:
--

[Tests 
results|http://195.239.208.174/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull%2F1390%2Fhead]

> Hadoop: striped shuffle mode must be enabled by default
> ---
>
> Key: IGNITE-4458
> URL: https://issues.apache.org/jira/browse/IGNITE-4458
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> Striped mode is enabled with 
> {{HadoopJobProperty.SHUFFLE_MAPPER_STRIPED_OUTPUT}}. It shows consistently 
> better results comparing to original shuffling mode.
> Possible solutions:
> 1) Make this property enabled by default;
> 2) Or totally remove previous mode (do not think it is a good idea)..



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-4505) IGFS docs: remove grid name from endpoint

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4505:
---

 Summary: IGFS docs: remove grid name from endpoint
 Key: IGNITE-4505
 URL: https://issues.apache.org/jira/browse/IGNITE-4505
 Project: Ignite
  Issue Type: Task
  Components: documentation
Affects Versions: 2.0
Reporter: Vladimir Ozerov
 Fix For: 2.0


See IGNITE-4462. We must reflect these changes in docs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-4462) IGFS: remove grid name from HadoopIgfsEndpoint

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-4462:
--

[Tests 
results|http://195.239.208.174/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull%2F1368%2Fhead]

> IGFS: remove grid name from HadoopIgfsEndpoint
> --
>
> Key: IGNITE-4462
> URL: https://issues.apache.org/jira/browse/IGNITE-4462
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> When the {{HadoopIgfsWrapper}} creates IGFS delegate with it must not find 
> the ignite instance by the the name. 
> The collection of available ignite instances must be scanned and the first 
> instance with the target file system will be used If the several nodes are 
> available on the specified host  / localhost / current VM process.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-4462) IGFS: remove grid name from HadoopIgfsEndpoint

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4462:
-

Taras, looks good. Please confirm TC status.

> IGFS: remove grid name from HadoopIgfsEndpoint
> --
>
> Key: IGNITE-4462
> URL: https://issues.apache.org/jira/browse/IGNITE-4462
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> When the {{HadoopIgfsWrapper}} creates IGFS delegate with it must not find 
> the ignite instance by the the name. 
> The collection of available ignite instances must be scanned and the first 
> instance with the target file system will be used If the several nodes are 
> available on the specified host  / localhost / current VM process.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-4462) IGFS: remove grid name from HadoopIgfsEndpoint

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4462:

Summary: IGFS: remove grid name from HadoopIgfsEndpoint  (was: Remove grid 
name from HadoopIgfsEndpoint)

> IGFS: remove grid name from HadoopIgfsEndpoint
> --
>
> Key: IGNITE-4462
> URL: https://issues.apache.org/jira/browse/IGNITE-4462
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> When the {{HadoopIgfsWrapper}} creates IGFS delegate with it must not find 
> the ignite instance by the the name. 
> The collection of available ignite instances must be scanned and the first 
> instance with the target file system will be used If the several nodes are 
> available on the specified host  / localhost / current VM process.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (IGNITE-4428) Hadoop: move HadoopMapReducePlanner and dependent classes to public space.

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-4428 at 12/28/16 1:18 PM:


Code review: 
[IGNT-CR-58|http://reviews.ignite.apache.org/ignite/review/IGNT-CR-58]


was (Author: tledkov-gridgain):
Code revire: 
[IGNT-CR-58|http://reviews.ignite.apache.org/ignite/review/IGNT-CR-58]

> Hadoop: move HadoopMapReducePlanner and dependent classes to public space.
> --
>
> Key: IGNITE-4428
> URL: https://issues.apache.org/jira/browse/IGNITE-4428
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> Currently these classes are located in private package. Need to move the to 
> public.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-4428) Hadoop: move HadoopMapReducePlanner and dependent classes to public space.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4428:


GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-4428 Hadoop: move HadoopMapReducePlanner and dependent classes to 
public space.



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

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

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

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


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 bf27bebcc3d6f61cb2bad4596fb26edb4d29eca2
Author: tledkov-gridgain 
Date:   2016-12-28T13:14:17Z

IGNITE-4428: Hadoop: move HadoopMapReducePlanner and dependent classes to 
public space




> Hadoop: move HadoopMapReducePlanner and dependent classes to public space.
> --
>
> Key: IGNITE-4428
> URL: https://issues.apache.org/jira/browse/IGNITE-4428
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> Currently these classes are located in private package. Need to move the to 
> public.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (IGNITE-3207) Rename IgniteConfiguration.gridName

[Alexandr Fedotov (JIRA)]

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

Alexandr Fedotov reassigned IGNITE-3207:


Assignee: Alexandr Fedotov  (was: Biao Ma)

> Rename IgniteConfiguration.gridName
> ---
>
> Key: IGNITE-3207
> URL: https://issues.apache.org/jira/browse/IGNITE-3207
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Alexandr Fedotov
>  Labels: important
> Fix For: 2.0
>
>
> We have got a TON of questions on gridName property. Everyone thinks that 
> clusters are formed based on the gridName, that is, nodes with the same grid 
> name will join one cluster, and nodes with a different name will be in a 
> separate cluster.
> Let's do the following:
> * Deprecate IgniteConfiguration.gridName
> * Add IgniteConfiguration.localInstanceName
> * Rename related parameters in Ignition class (and other places, if present)
> * Update Javadoc: clearly state that this name only works locally and has no 
> effect on topology.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (IGNITE-4504) .NET: Expose default concurrency and isolation on ITransactions

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-4504:
--

Assignee: Pavel Tupitsyn

> .NET: Expose default concurrency and isolation on ITransactions
> ---
>
> Key: IGNITE-4504
> URL: https://issues.apache.org/jira/browse/IGNITE-4504
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.8
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> There are two methods to start an Ignite transaction:
> * {{ITransactions.TxStart()}}
> * {{ITransactions.TxStart(TransactionConcurrency concurrency, 
> TransactionIsolation isolation)}}
> There is no easy way for the user to know which values will be used with the 
> first method, so there is no way to override only one of them.
> But internally we have this information and can easily add 
> {{ITransactions.DefaultTransactionConcurrency}} and 
> {{ITransactions.DefaultTransactionIsolation}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[Dmitriy Shabalin (JIRA)]

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

Dmitriy Shabalin commented on IGNITE-4472:
--

Fixed issues

> 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
>
> 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.4#6332)

[jira] [Commented] (IGNITE-3207) Rename IgniteConfiguration.gridName

[Alexandr Fedotov (JIRA)]

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

Alexandr Fedotov commented on IGNITE-3207:
--

Looks like there has not been any activity since July. Taking the issue.

> Rename IgniteConfiguration.gridName
> ---
>
> Key: IGNITE-3207
> URL: https://issues.apache.org/jira/browse/IGNITE-3207
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Biao Ma
>  Labels: important
> Fix For: 2.0
>
>
> We have got a TON of questions on gridName property. Everyone thinks that 
> clusters are formed based on the gridName, that is, nodes with the same grid 
> name will join one cluster, and nodes with a different name will be in a 
> separate cluster.
> Let's do the following:
> * Deprecate IgniteConfiguration.gridName
> * Add IgniteConfiguration.localInstanceName
> * Rename related parameters in Ignition class (and other places, if present)
> * Update Javadoc: clearly state that this name only works locally and has no 
> effect on topology.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-4428) Hadoop: move HadoopMapReducePlanner and dependent classes to public space.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4428:


Github user tledkov-gridgain closed the pull request at:

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


> Hadoop: move HadoopMapReducePlanner and dependent classes to public space.
> --
>
> Key: IGNITE-4428
> URL: https://issues.apache.org/jira/browse/IGNITE-4428
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> Currently these classes are located in private package. Need to move the to 
> public.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-4504) .NET: Expose default concurrency and isolation on ITransactions

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4504:
--

 Summary: .NET: Expose default concurrency and isolation on 
ITransactions
 Key: IGNITE-4504
 URL: https://issues.apache.org/jira/browse/IGNITE-4504
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 1.8
Reporter: Pavel Tupitsyn
 Fix For: 2.0


There are two methods to start an Ignite transaction:
* {{ITransactions.TxStart()}}
* {{ITransactions.TxStart(TransactionConcurrency concurrency, 
TransactionIsolation isolation)}}

There is no easy way for the user to know which values will be used with the 
first method, so there is no way to override only one of them.

But internally we have this information and can easily add 
{{ITransactions.DefaultTransactionConcurrency}} and 
{{ITransactions.DefaultTransactionIsolation}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-4503) HadoopDirectDataInput must have boundary checks

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4503:
---

 Summary: HadoopDirectDataInput must have boundary checks
 Key: IGNITE-4503
 URL: https://issues.apache.org/jira/browse/IGNITE-4503
 Project: Ignite
  Issue Type: Task
  Components: hadoop
Affects Versions: 1.8
Reporter: Vladimir Ozerov
 Fix For: 2.0


Otherwise we may end up with JVM crash in case of invalid implementation of 
key/value deserialization routine.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (IGNITE-1997) "Query entities can be set only once." error on node start

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov closed IGNITE-1997.
--

> "Query entities can be set only once." error on node start
> --
>
> Key: IGNITE-1997
> URL: https://issues.apache.org/jira/browse/IGNITE-1997
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>
> I'm faced with this error in case when one cache has "queryEntities" and 
> other cache has "cacheTypeMetadata".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (IGNITE-1997) "Query entities can be set only once." error on node start

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov resolved IGNITE-1997.

Resolution: Cannot Reproduce

> "Query entities can be set only once." error on node start
> --
>
> Key: IGNITE-1997
> URL: https://issues.apache.org/jira/browse/IGNITE-1997
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>
> I'm faced with this error in case when one cache has "queryEntities" and 
> other cache has "cacheTypeMetadata".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-1997) "Query entities can be set only once." error on node start

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-1997:


I suppose this was already fixed and can be closed.

> "Query entities can be set only once." error on node start
> --
>
> Key: IGNITE-1997
> URL: https://issues.apache.org/jira/browse/IGNITE-1997
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>
> I'm faced with this error in case when one cache has "queryEntities" and 
> other cache has "cacheTypeMetadata".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[Andrey Novikov (JIRA)]

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

Andrey Novikov commented on IGNITE-4472:


Reviewed. Rename methods.
statisticsService should return promise with data, Rename statistics.service.js 
to Statistics.data.js

> 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: Andrey Novikov
>
> 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.4#6332)

[jira] [Commented] (IGNITE-3875) Create separate thread pool for data streamer.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3875:


Github user devozerov closed the pull request at:

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


> Create separate thread pool for data streamer.
> --
>
> Key: IGNITE-3875
> URL: https://issues.apache.org/jira/browse/IGNITE-3875
> Project: Ignite
>  Issue Type: Task
>  Components: streaming
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.0
>
>
> Currently data streamer requests are submitted to PUBLIC pool. Because of 
> this it is not safe to run streamer from compute tasks which is very 
> inconvenient.
> We should create separate thread pool for streamer and route streamer jobs to 
> it. Compatibility must be preserved.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-521) Exception is not thrown on near node when TX is failed on primary node.

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-521:

Assignee: (was: Alexey Goncharuk)

> Exception is not thrown on near node when TX is failed on primary node.
> ---
>
> Key: IGNITE-521
> URL: https://issues.apache.org/jira/browse/IGNITE-521
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Affects Versions: sprint-1
>Reporter: Vladimir Ozerov
>
> Test scenario:
> 1) Start 2 nodes with TX PARTITIONED_ONLY cache and 0 backups.
> 2) Start continuous query providing a filter which throws exceptions on each 
> call.
> 3) Put primary key to cache through "getAndPut()" -> TX is rolled back, you 
> receive exception.
> 4) Put near key to cache in the same way -> TX is rolled back, but NO 
> EXCEPTION!
> 5) Set backups=1 => step 4 throws an exception as expected.
> 6) Set mode to ATOMIC => step 4 throws an exception as expected.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-3357) getOrCreateCache on second node fails replication if first node is doing loadCache

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-3357:
-
Assignee: (was: Alexey Goncharuk)

> getOrCreateCache on second node fails replication if first node is doing 
> loadCache
> --
>
> Key: IGNITE-3357
> URL: https://issues.apache.org/jira/browse/IGNITE-3357
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6, 1.7
>Reporter: Kristian Rosenvold
>  Labels: community, important
>
> If the first node on a REPLICATED cache is doing loadCache, a subsequent node 
> that starts while this operation is in process will not reach identical state 
> as the first node.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-3357) getOrCreateCache on second node fails replication if first node is doing loadCache

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-3357:
--

[~dmagda], at the first glance the correct solution will be to restart the 
whole loadCache() operation. It was designed to run on a stable topology, and I 
am not sure if we can do something else to make sure it works correctly other 
than restart. The solution suggested by Kristian to use DataStreamer looks good 
enough to me.

> getOrCreateCache on second node fails replication if first node is doing 
> loadCache
> --
>
> Key: IGNITE-3357
> URL: https://issues.apache.org/jira/browse/IGNITE-3357
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6, 1.7
>Reporter: Kristian Rosenvold
>Assignee: Alexey Goncharuk
>  Labels: community, important
>
> If the first node on a REPLICATED cache is doing loadCache, a subsequent node 
> that starts while this operation is in process will not reach identical state 
> as the first node.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-1997) "Query entities can be set only once." error on node start

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-1997:
-
Assignee: Pavel Konstantinov  (was: Alexey Goncharuk)

> "Query entities can be set only once." error on node start
> --
>
> Key: IGNITE-1997
> URL: https://issues.apache.org/jira/browse/IGNITE-1997
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>
> I'm faced with this error in case when one cache has "queryEntities" and 
> other cache has "cacheTypeMetadata".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-1997) "Query entities can be set only once." error on node start

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-1997:
--

Pavel, I cannot reproduce this behavior. Please provide more details - exact 
cache configuration, version, number of nodes.

> "Query entities can be set only once." error on node start
> --
>
> Key: IGNITE-1997
> URL: https://issues.apache.org/jira/browse/IGNITE-1997
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Alexey Goncharuk
>
> I'm faced with this error in case when one cache has "queryEntities" and 
> other cache has "cacheTypeMetadata".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-1997) "Query entities can be set only once." error on node start

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-1997:
-
Assignee: (was: Alexey Goncharuk)

> "Query entities can be set only once." error on node start
> --
>
> Key: IGNITE-1997
> URL: https://issues.apache.org/jira/browse/IGNITE-1997
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>
> I'm faced with this error in case when one cache has "queryEntities" and 
> other cache has "cacheTypeMetadata".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (IGNITE-1997) "Query entities can be set only once." error on node start

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk reassigned IGNITE-1997:


Assignee: Alexey Goncharuk

> "Query entities can be set only once." error on node start
> --
>
> Key: IGNITE-1997
> URL: https://issues.apache.org/jira/browse/IGNITE-1997
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Alexey Goncharuk
>
> I'm faced with this error in case when one cache has "queryEntities" and 
> other cache has "cacheTypeMetadata".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (IGNITE-1152) Distribution of backup partitions is not uniform

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk resolved IGNITE-1152.
--
Resolution: Won't Fix

Number of backup partitions includes temporary non-evicted partitions.

> Distribution of backup partitions is not uniform
> 
>
> Key: IGNITE-1152
> URL: https://issues.apache.org/jira/browse/IGNITE-1152
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.1.4
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Goncharuk
>Priority: Minor
> Attachments: CacheBackupPartitionsTest.java
>
>
> I started 4 nodes with partitioned cache with 1 backup.
> And found that primary parts more or less uniform, but backup parts - not:
> Node n1: : pri=244, bak=367
> Node n2: : pri=260, bak=590
> Node n3: : pri=244, bak=367
> Node n4: : pri=260, bak=590
> Code to test this issue attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-1553) Optimize transaction prepare step when store is enabled

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-1553:
-
Assignee: (was: Alexey Goncharuk)

> Optimize transaction prepare step when store is enabled
> ---
>
> Key: IGNITE-1553
> URL: https://issues.apache.org/jira/browse/IGNITE-1553
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Alexey Goncharuk
>  Labels: important
>
> Currently entries are enlisted in a database transaction after grid 
> transaction is in PREPARED state. We can do this in parallel in the following 
> fashion (pseudo-code):
> {code}
> fut = tx.prepareAsync();
> db.write(tx.writes());
> fut.get();
> try {
> db.commit();
> 
> tx.commit();
> }
> catch (Exception e) {
> tx.rollback();
> }
> {code}
> If this approach is applied, we should be able to reduce latency for 
> transactions when write-through is enabled.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-1094) Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-1094:
-
Assignee: (was: Alexey Goncharuk)

> Ignite.createCache(CacheConfiguration) hangs if some exception occurs during 
> cache initialization
> -
>
> Key: IGNITE-1094
> URL: https://issues.apache.org/jira/browse/IGNITE-1094
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: sprint-7
>Reporter: Sergey Evdokimov
>  Labels: Muted_test
>
> User can pass broken configuration, for example, store factory that throws 
> exception from create() method. I created test to demonstrate the problem. 
> See IgniteDynamicCacheStartSelfTest#testBrokenStoreFactory in 'ignite-1094' 
> branch 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (IGNITE-939) Cache close() produces "Different deployment IDs" errors

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk resolved IGNITE-939.
-
   Resolution: Cannot Reproduce
Fix Version/s: 1.5.0.final

Cannot reproduce since 1.5.0.final

> Cache close() produces "Different deployment IDs" errors
> 
>
> Key: IGNITE-939
> URL: https://issues.apache.org/jira/browse/IGNITE-939
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Vinogradov
>Assignee: Alexey Goncharuk
> Fix For: 1.5.0.final
>
>
> Please have a look at CacheCloseTest (branch ignite-939).
> Seems that during nodes startup happens unexpected changing of deploymentId
> java.lang.Exception: 550ce4c7d41-59846c1e-dd75-4751-8ac8-bf52841be827 -> 
> 350ce4c7d41-59846c1e-dd75-4751-8ac8-bf52841be827
>   at 
> org.apache.ignite.internal.util.IgniteUtils.dumpStack(IgniteUtils.java:838)
>   at 
> org.apache.ignite.internal.processors.cache.DynamicCacheDescriptor.deploymentId(DynamicCacheDescriptor.java:109)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onDiscoveryDataReceived(GridCacheProcessor.java:1667)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$5.onExchange(GridDiscoveryManager.java:456)
>   at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpiAdapter.onExchange(TcpDiscoverySpiAdapter.java:774)
>   at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi$RingMessageWorker.processNodeAddedMessage(TcpDiscoverySpi.java:3647)
>   at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi$RingMessageWorker.processJoinRequestMessage(TcpDiscoverySpi.java:3405)
>   at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi$RingMessageWorker.processMessage(TcpDiscoverySpi.java:2631)
>   at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpiAdapter$MessageWorkerAdapter.body(TcpDiscoverySpiAdapter.java:987)
>   at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> which produces comparison fail during cache closing:
> java.lang.Exception: 350ce4c7d41-59846c1e-dd75-4751-8ac8-bf52841be827 
> compares with 550ce4c7d41-59846c1e-dd75-4751-8ac8-bf52841be827
>   at 
> org.apache.ignite.internal.util.IgniteUtils.dumpStack(IgniteUtils.java:838)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:1494)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onExchangeDone(GridCacheProcessor.java:1536)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:851)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:52)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:302)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:991)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:954)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:241)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:204)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceive(GridDhtPartitionsExchangeFuture.java:954)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:862)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1100(GridCachePartitionExchangeManager.java:57)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:224)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:222)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:1224)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:1206)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:527)
>   at 
> 

[jira] [Resolved] (IGNITE-922) Loop of getOrCreateCache hangs

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk resolved IGNITE-922.
-
   Resolution: Cannot Reproduce
Fix Version/s: 1.5.0.final

Cannot reproduce this since 1.5.0.final

> Loop of  getOrCreateCache hangs
> ---
>
> Key: IGNITE-922
> URL: https://issues.apache.org/jira/browse/IGNITE-922
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: sprint-4, sprint-5
>Reporter: Sergey Kozlov
>Assignee: Alexey Goncharuk
> Fix For: 1.5.0.final
>
>
> 1. Start node by ExampleNodeStartup
> 2. Run following code (I changed CachePutGetExample)
> {code:title=CachePutGetExample.java|borderStyle=solid}
> public static void main(String[] args) throws IgniteException {
> try (Ignite ignite = 
> Ignition.start("examples/config/example-ignite.xml")) {
> for (int i=1; i <= 1000; i++) {
> System.out.println(">>> Iteration " + Integer.toString(i));
> try (IgniteCache cache = 
> ignite.getOrCreateCache(CACHE_NAME)) {
> }
> IgniteCache cache = 
> ignite.getOrCreateCache(CACHE_NAME);
> }
> }
> }
> {code}
> After 40-50 iterations test program hangs. No errors and warnings on nodes 
> found.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-79) Illegal state exception in affinity assignment cache

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-79:
---
Assignee: (was: Alexey Goncharuk)

> Illegal state exception in affinity assignment cache
> 
>
> Key: IGNITE-79
> URL: https://issues.apache.org/jira/browse/IGNITE-79
> Project: Ignite
>  Issue Type: Bug
>Reporter: Yakov Zhdanov
>
> {noformat}
> java.lang.IllegalStateException: Getting affinity for topology version 
> earlier than affinity is calculated 
> [locNodeId=41caf5c2-3827-4566-9e52-22dabf51f864, topVer=179, head=180]
>   at 
> org.gridgain.grid.kernal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:328)
>  ~[gridgain-core-6.2.1-p1.jar:na]
>   at 
> org.gridgain.grid.kernal.processors.affinity.GridAffinityAssignmentCache.primaryPartitions(GridAffinityAssignmentCache.java:294)
>  ~[gridgain-core-6.2.1-p1.jar:na]
>   at 
> org.gridgain.grid.kernal.processors.cache.GridCacheAffinityManager.primaryPartitions(GridCacheAffinityManager.java:349)
>  ~[gridgain-core-6.2.1-p1.jar:na]
>   at 
> org.gridgain.grid.kernal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:478)
>  ~[gridgain-core-6.2.1-p1.jar:na]
>   at 
> org.gridgain.grid.kernal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemandPool$ExchangeWorker.body(GridDhtPartitionDemandPool.java:1285)
>  ~[gridgain-core-6.2.1-p1.jar:na]
>   at org.gridgain.grid.util.worker.GridWorker.run(GridWorker.java:151) 
> ~[gridgain-core-6.2.1-p1.jar:na]
>   at java.lang.Thread.run(Thread.java:745) [na:1.7.0_55]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-258) GridCachePartitionedQueueRotativeMultiNodeTest.testTakeRemoveRotativeNodes() fails sporadically

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-258:

Assignee: (was: Alexey Goncharuk)

> GridCachePartitionedQueueRotativeMultiNodeTest.testTakeRemoveRotativeNodes() 
> fails sporadically
> ---
>
> Key: IGNITE-258
> URL: https://issues.apache.org/jira/browse/IGNITE-258
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: sprint-1
>Reporter: Alexey Goncharuk
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-258) GridCachePartitionedQueueRotativeMultiNodeTest.testTakeRemoveRotativeNodes() fails sporadically

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-258:

Issue Type: Test  (was: Bug)

> GridCachePartitionedQueueRotativeMultiNodeTest.testTakeRemoveRotativeNodes() 
> fails sporadically
> ---
>
> Key: IGNITE-258
> URL: https://issues.apache.org/jira/browse/IGNITE-258
> Project: Ignite
>  Issue Type: Test
>  Components: cache
>Affects Versions: sprint-1
>Reporter: Alexey Goncharuk
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-835) IgniteCache.lock is broken for PARTITIONED cache without near cache.

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-835:

Assignee: (was: Alexey Goncharuk)

> IgniteCache.lock is broken for PARTITIONED cache without near cache.
> 
>
> Key: IGNITE-835
> URL: https://issues.apache.org/jira/browse/IGNITE-835
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: sprint-2
>Reporter: Vladimir Ozerov
>  Labels: Muted_test
>
> Steps to reproduce:
> 1) Go to GridCacheLockAbstractTest
> 2) Add the test source below.
> 3) Make sure to disable near cache 
> (GridCacheLockAbstractTest.cacheConfiguration() -> 
> setNearConfiguration(null)).
> 4) Run GridCachePartitionedLockSelfTest.testLockReentrancy() and observe 
> assertion failure.
> 5) Enable near cache back and re-run the test. Observe that now it pass.
> {code}
> public void testLockReentrancy() throws Throwable {
> for (int i = 10; i < 100; i++) {
> System.out.println("Key: " + i);
> final int i0 = i;
> final Lock lock = cache1.lock(i);
> lock.lockInterruptibly();
> try {
> final AtomicReference err = new AtomicReference<>();
> Thread t =  new Thread(new Runnable() {
> @Override public void run() {
> try {
> assert !lock.tryLock();
> assert !lock.tryLock(100, TimeUnit.MILLISECONDS);
> assert !cache1.lock(i0).tryLock();
> assert !cache1.lock(i0).tryLock(100, 
> TimeUnit.MILLISECONDS);
> }
> catch (Throwable e) {
> err.set(e);
> }
> }
> });
> t.start();
> t.join();
> if (err.get() != null)
> throw err.get();
> lock.lock();
> lock.unlock();
> t =  new Thread(new Runnable() {
> @Override public void run() {
> try {
> assert !lock.tryLock();
> assert !lock.tryLock(100, TimeUnit.MILLISECONDS);
> assert !cache1.lock(i0).tryLock();
> assert !cache1.lock(i0).tryLock(100, 
> TimeUnit.MILLISECONDS);
> }
> catch (Throwable e) {
> err.set(e);
> }
> }
> });
> t.start();
> t.join();
> if (err.get() != null)
> throw err.get();
> }
> finally {
> lock.unlock();
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[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:
---
Description: 
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.

  was:
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

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.


> .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: 2.0
>
>
> 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.4#6332)

[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:
---
Description: 
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

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.

  was:
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


> .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: 2.0
>
>
> 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
> 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.4#6332)

[jira] [Assigned] (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 reassigned 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: 2.0
>
>
> 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



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (IGNITE-4307) .NET: AtomicSequenceExample uses AtomicConfiguration incorrectly

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-4307:
--

Assignee: (was: Pavel Tupitsyn)

> .NET: AtomicSequenceExample uses AtomicConfiguration incorrectly
> 
>
> Key: IGNITE-4307
> URL: https://issues.apache.org/jira/browse/IGNITE-4307
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.8
>Reporter: Pavel Tupitsyn
>  Labels: .NET, examples
> Fix For: 2.0
>
>
> AtomicConfiguration is specified only on local node. Standalone nodes use 
> default configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3878:


GitHub user dream-x opened a pull request:

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

IGNITE-3878: Add isPrimary() and isBackup() methods on CacheQueryEntryEvent



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

$ git pull https://github.com/dream-x/ignite ignite-3878

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

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


commit d20e42aa2417224b4a27af2f8525b098d4d99d60
Author: Max Kozlov 
Date:   2016-12-28T08:33:52Z

Add isPrimary() and isBackup() methods in CacheQueryEntryEvent

commit 59a77bf7b40162cf4dc9ed234956347d1c98ab38
Author: Max Kozlov 
Date:   2016-12-28T08:34:36Z

Add implementation isPrimary() and isBackup() methods in 
CacheContinuousQueryEvent

commit fad42f7b1e13c41cd36a344bb9de4a96ed1eb136
Author: Max Kozlov 
Date:   2016-12-28T08:35:07Z

Add implementation isPrimary() and isBackup() methods in CacheEntryEventImpl




> 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.4#6332)

[jira] [Resolved] (IGNITE-4307) .NET: AtomicSequenceExample uses AtomicConfiguration incorrectly

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-4307.

Resolution: Fixed

Fixed in master

> .NET: AtomicSequenceExample uses AtomicConfiguration incorrectly
> 
>
> Key: IGNITE-4307
> URL: https://issues.apache.org/jira/browse/IGNITE-4307
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.8
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, examples
> Fix For: 2.0
>
>
> AtomicConfiguration is specified only on local node. Standalone nodes use 
> default configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-3170) .NET: Add user-friendly ToString overrides for public types

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-3170:
---
Description: 
Events, cache entry events, mutable cache entries, etc, should have 
{{ToString}} overridden. See {{CacheEntry}} for example.

{{IgniteConfiguration}} (and inner property classes) can be displayed as XML.

  was:Events, cache entry events, mutable cache entries, etc, should have 
ToString overridden. See CacheEntry for example.


> .NET: Add user-friendly ToString overrides for public types
> ---
>
> Key: IGNITE-3170
> URL: https://issues.apache.org/jira/browse/IGNITE-3170
> Project: Ignite
>  Issue Type: Improvement
>  Components: newbie, platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>  Labels: .net
> Fix For: 2.0
>
>
> Events, cache entry events, mutable cache entries, etc, should have 
> {{ToString}} overridden. See {{CacheEntry}} for example.
> {{IgniteConfiguration}} (and inner property classes) can be displayed as XML.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[Dmitriy Shabalin (JIRA)]

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

Dmitriy Shabalin commented on IGNITE-4472:
--

(uncompleted) $stateChangeSuccess will be deprecated in angular-ui-router 
version 1.0

> 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: Andrey Novikov
>
> 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.4#6332)

[jira] [Updated] (IGNITE-1508) .NET: Create common ToString() method

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1508:
---
Summary: .NET: Create common ToString() method  (was: .Net: Create common 
ToString() method.)

> .NET: Create common ToString() method
> -
>
> Key: IGNITE-1508
> URL: https://issues.apache.org/jira/browse/IGNITE-1508
> Project: Ignite
>  Issue Type: Improvement
>  Components: newbie, platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>  Labels: .net
>
> We have lots of places with the same code pattern in ToString() method: 
> culture info + String.Format(). 
> Let's move it to utilities and re-use just like it is done in Java.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-4502) JVM driver crash during load test

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova updated IGNITE-4502:

Attachment: ignite-yardstick-2.0.0-SNAPSHOT.jar
hs_err_pid9061.log

> JVM driver crash during load test
> -
>
> Key: IGNITE-4502
> URL: https://issues.apache.org/jira/browse/IGNITE-4502
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Ksenia Rybakova
> Attachments: hs_err_pid9061.log, ignite-yardstick-2.0.0-SNAPSHOT.jar
>
>
> During load test one of the driver JVMs failed with the following
> {noformat}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x7f781306426d, pid=9061, tid=140153654769408
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_79-b15) (build 
> 1.7.0_79-b15)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.79-b02 mixed mode 
> linux-amd64 compressed oops)
> # Problematic frame:
> # C  [libc.so.6+0x8a26d][thread 140153650558720 also had an error]
>   __memset_sse2+0x95d
> {noformat} 
> Error report file is attached.
> Revision:
> 5494dfb8 (but ignite-yardstick lib was replaced with newer version, 
> corresponding jar is attached)
> This issue is of one time occurrence.
> Load config:
> - Operations: put, put_all, get, get_all, invoke, invoke_all, remove, 
> remove_all, put_if_absent, replace
> - Heap: 8Gb for servers, 4Gb for clients
> - 5 clients, 20 servers
> - 12 caches
> - Types of caches (atomicity mode) : different (atomic, transactional)
> - Types of caches (tiered storage mode) : different (onheap without eviction, 
> onheap with eviction, offheap_tired, offheap_values)
> - Types of caches (indexing): different (with and without indexes)
> - Types of caches (cache mode): different (partitioned, replicated)
> - Backups count: 1
> - TLSv1.2 is enabled



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-4502) JVM driver crash during load test

[Ksenia Rybakova (JIRA)]

Ksenia Rybakova created IGNITE-4502:
---

 Summary: JVM driver crash during load test
 Key: IGNITE-4502
 URL: https://issues.apache.org/jira/browse/IGNITE-4502
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.7
Reporter: Ksenia Rybakova


During load test one of the driver JVMs failed with the following
{noformat}
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x7f781306426d, pid=9061, tid=140153654769408
#
# JRE version: Java(TM) SE Runtime Environment (7.0_79-b15) (build 1.7.0_79-b15)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.79-b02 mixed mode linux-amd64 
compressed oops)
# Problematic frame:
# C  [libc.so.6+0x8a26d][thread 140153650558720 also had an error]
  __memset_sse2+0x95d
{noformat} 

Error report file is attached.

Revision:
5494dfb8 (but ignite-yardstick lib was replaced with newer version, 
corresponding jar is attached)

This issue is of one time occurrence.

Load config:
- Operations: put, put_all, get, get_all, invoke, invoke_all, remove, 
remove_all, put_if_absent, replace
- Heap: 8Gb for servers, 4Gb for clients
- 5 clients, 20 servers
- 12 caches
- Types of caches (atomicity mode) : different (atomic, transactional)
- Types of caches (tiered storage mode) : different (onheap without eviction, 
onheap with eviction, offheap_tired, offheap_values)
- Types of caches (indexing): different (with and without indexes)
- Types of caches (cache mode): different (partitioned, replicated)
- Backups count: 1
- TLSv1.2 is enabled



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-4367) .NET: Fix flaky tests

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4367:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-4367 .NET: Fix flaky tests



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

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

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

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


commit 37531157c2cde6331d0e1fa07873ad25bf50c36c
Author: Pavel Tupitsyn 
Date:   2016-12-26T13:48:11Z

Fix race in reconnect test

commit 044fbb56a25e5308778292d30333c0f86eb7d6a1
Author: Pavel Tupitsyn 
Date:   2016-12-26T14:07:29Z

Reduce node number in examples test

commit 8c4f8ebef6bc362e0c039809a29fe6750513d8a5
Author: Pavel Tupitsyn 
Date:   2016-12-26T14:16:13Z

Revert examples tests

commit 40b74b07d58d8caa1cf4105711c717513b781117
Author: Pavel Tupitsyn 
Date:   2016-12-28T08:14:06Z

Merge branch 'master' into ignite-4367

# Conflicts:
#   
modules/platforms/dotnet/Apache.Ignite.Core.Tests/Examples/ExamplesTest.cs
#   modules/platforms/dotnet/Apache.Ignite.Core.Tests/ReconnectTest.cs

commit a27927cc572f60a670c913bf1d4c74830894aa1a
Author: Pavel Tupitsyn 
Date:   2016-12-28T08:14:33Z

revert changes

commit 385943f4d7034aa8655c51b48067bfff63d9a4ba
Author: Pavel Tupitsyn 
Date:   2016-12-28T08:17:19Z

Add debug output




> .NET: Fix flaky tests
> -
>
> Key: IGNITE-4367
> URL: https://issues.apache.org/jira/browse/IGNITE-4367
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Trivial
>  Labels: .NET
> Fix For: 1.9
>
>
> TeamCity has detected a number of flaky tests in .NET: 
> http://ci.ignite.apache.org/project.html?projectId=IgniteTests=flakyTests=IgniteTests_IgnitePlatformNetCoverage



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-4367) .NET: Fix flaky tests

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4367:


TestClusterRestart still fails, investigating.

> .NET: Fix flaky tests
> -
>
> Key: IGNITE-4367
> URL: https://issues.apache.org/jira/browse/IGNITE-4367
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Trivial
>  Labels: .NET
> Fix For: 1.9
>
>
> TeamCity has detected a number of flaky tests in .NET: 
> http://ci.ignite.apache.org/project.html?projectId=IgniteTests=flakyTests=IgniteTests_IgnitePlatformNetCoverage



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (IGNITE-4367) .NET: Fix flaky tests

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reopened IGNITE-4367:

  Assignee: Pavel Tupitsyn

> .NET: Fix flaky tests
> -
>
> Key: IGNITE-4367
> URL: https://issues.apache.org/jira/browse/IGNITE-4367
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Trivial
>  Labels: .NET
> Fix For: 1.9
>
>
> TeamCity has detected a number of flaky tests in .NET: 
> http://ci.ignite.apache.org/project.html?projectId=IgniteTests=flakyTests=IgniteTests_IgnitePlatformNetCoverage



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (IGNITE-4307) .NET: AtomicSequenceExample uses AtomicConfiguration incorrectly

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-4307:
--

Assignee: Pavel Tupitsyn

> .NET: AtomicSequenceExample uses AtomicConfiguration incorrectly
> 
>
> Key: IGNITE-4307
> URL: https://issues.apache.org/jira/browse/IGNITE-4307
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.8
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, examples
> Fix For: 2.0
>
>
> AtomicConfiguration is specified only on local node. Standalone nodes use 
> default configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-4045) .NET: Support DML API

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4045:


Fixed FullFooter tests.

> .NET: Support DML API
> -
>
> Key: IGNITE-4045
> URL: https://issues.apache.org/jira/browse/IGNITE-4045
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Reporter: Denis Magda
>Assignee: Vladimir Ozerov
>  Labels: roadmap
> Fix For: 2.0
>
>
> 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.NET 
> by doing the following:
> - Implement DML API;
> - Enhance {{QueryExample.cs}} by doing INSERTs instead of cache.puts and 
> adding UPDATE and DELETE operation examples.
> - Add documentation to Ignite.NET 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 
> (https://apacheignite.readme.io/docs/distributed-dml).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)