[jira] [Commented] (IGNITE-1071) IgniteCache.metrics() method returns local metrics

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-1071:
-

Anton, I would look through all MBeans we have and check if the metrics they 
are exposing are meaningful. Should we discuss this on dev list?

> IgniteCache.metrics() method returns local metrics
> --
>
> Key: IGNITE-1071
> URL: https://issues.apache.org/jira/browse/IGNITE-1071
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
>Priority: Minor
>  Labels: Usability
> Fix For: 1.6
>
>
> To get metrics for the whole cluster user needs to use 
> {{cache.metrics(ignite.cluster())}}, which is counterintuitive and 
> inconsistent with other APIs. {{IgniteCache.metrics()}} w/o parameters should 
> return metrics for the whole cluster.



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

[jira] [Commented] (IGNITE-2797) Prepare and finish future never time out

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-2797:
-

Fixed my findings that mentioned above. For first finding I just throw 
{{TransactionTimeoutException}} if {{remainingTime == 0}}. Test doesn't hang 
anymore but many tests failed on TC.

Also fix Val's finding with timeout logic in optimistic transactions. 
{{TxTest2.java}} doesn't fail anymore. Waiting for TC.

> Prepare and finish future never time out
> 
>
> Key: IGNITE-2797
> URL: https://issues.apache.org/jira/browse/IGNITE-2797
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Priority: Blocker
>  Labels: community, customer, important
> Fix For: 1.6
>
> Attachments: TxTest2.java
>
>
> Even if transaction timeout is configured, transaction will not timeout if 
> it's already in prepare state. It will be shown in log as pending transaction 
> and can cause the whole cluster hang.
> We need to add a mechanism that will properly timeout prepare and (if 
> possible) finish futures.
> Also we can create an event that will be fired if there is a transaction 
> pending for a long time, showing which nodes we are waiting responses from. 
> This will allow user to recover by stopping only these nodes instead of 
> restarting the whole cluster.



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

[jira] [Updated] (IGNITE-2856) Do not generate index fields when them is absent in query fields

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko updated IGNITE-2856:
--
Description: Schema import utility can generate index fields that is 
exclude from query fields.

> Do not generate index fields when them is absent in query fields
> 
>
> Key: IGNITE-2856
> URL: https://issues.apache.org/jira/browse/IGNITE-2856
> Project: Ignite
>  Issue Type: Bug
>  Components: UI, wizards
>Affects Versions: 1.6
>Reporter: Vasiliy Sisko
>
> Schema import utility can generate index fields that is exclude from query 
> fields.



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

[jira] [Comment Edited] (IGNITE-1630) .Net: Create LINQ adapter for queries.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-1630 at 3/17/16 7:07 PM:
-

Added CompiledQuery example (as part of existing one)


was (Author: ptupitsyn):
TODO:
* Add CompiledQuery example (as part of existing one)
* Think about AsCacheQueryable naming. NHibernate uses Linq(), should we do the 
same?

> .Net: Create LINQ adapter for queries.
> --
>
> Key: IGNITE-1630
> URL: https://issues.apache.org/jira/browse/IGNITE-1630
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Fix For: 1.6
>
>
> SQL queries are one of the most frequently used features in data grids. And 
> .Net comes with a very nice LINQ concept. 
> * LINQ provider should come in a separate assembly
> * Make sure that assembly is included in binary distribution



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

[jira] [Updated] (IGNITE-2549) ODBC: Implement example that can be used for data visualization.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2549:

Fix Version/s: (was: 1.6)
   1.7

> ODBC: Implement example that can be used for data visualization.
> 
>
> Key: IGNITE-2549
> URL: https://issues.apache.org/jira/browse/IGNITE-2549
> Project: Ignite
>  Issue Type: Sub-task
>  Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>
> As the one of the purposes for development of the ODBC driver was to use data 
> visualization tools with Apache Ignite, we need to have example that can be 
> used to test interoperability with such tools. Such example should contain 
> several caches with relational data that can provide meaningful graphs when 
> visualized.



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

[jira] [Updated] (IGNITE-1433) .Net: Add IgniteException.JavaStackTrace

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-1433:

Fix Version/s: (was: 1.6)
   1.7

> .Net: Add IgniteException.JavaStackTrace
> 
>
> Key: IGNITE-1433
> URL: https://issues.apache.org/jira/browse/IGNITE-1433
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>
> Propagate java stack trace as a string in ExceptionUtils.GetException and 
> write it to a new field in IgniteException class.
> This will simplify debugging for us both locally and when getting error 
> reports from clients.



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

[jira] [Assigned] (IGNITE-2815) IGFS: IgfsMetaManager.create() should not use "putIfAbsent" to create a file.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-2815:
---

Assignee: Vladimir Ozerov  (was: Ivan Veselovsky)

> IGFS: IgfsMetaManager.create() should not use "putIfAbsent" to create a file.
> -
>
> Key: IGNITE-2815
> URL: https://issues.apache.org/jira/browse/IGNITE-2815
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.7
>
>
> This is less than optimal approach. Instead, we should use entry processor 
> which will accept file ID, block size and properties.



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

[jira] [Created] (IGNITE-2861) IGFS: Move meta processors to separate classes.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-2861:
---

 Summary: IGFS: Move meta processors to separate classes.
 Key: IGNITE-2861
 URL: https://issues.apache.org/jira/browse/IGNITE-2861
 Project: Ignite
  Issue Type: Task
  Components: IGFS
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Minor
 Fix For: 1.6


The goal is to simplify {{IgfsMetaManager}}.



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

[jira] [Commented] (IGNITE-2850) ODBC: Add documentation for the ODBC.

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-2850:
-

Vladimir,

Kind of weird mistake. I will move the documentation to the Apache Ignite.

> ODBC: Add documentation for the ODBC.
> -
>
> Key: IGNITE-2850
> URL: https://issues.apache.org/jira/browse/IGNITE-2850
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation, odbc
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.6
>
>
> Need to add documentation for the ODBC to http://apacheignite.gridgain.org



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

[jira] [Comment Edited] (IGNITE-2523) Introduce "single put" NEAR update request.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-2523 at 3/17/16 11:51 AM:
---

Moved to 1.7. It looks like we should implement optimized paths for 
single-updates in futures and only then apply any protocol changes.


was (Author: vozerov):
Moved to 1.7. It looks like we should implement optimzied paths for 
single-updates in futures and only then apply any protocol changes.

> Introduce "single put" NEAR update request.
> ---
>
> Key: IGNITE-2523
> URL: https://issues.apache.org/jira/browse/IGNITE-2523
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>
> Essentially, in this case we could get rid of all collections and garbage 
> inside GridNearAtomicUpdateRequest/GridDhtAtomicUpdateRequest.
> This should drastically decrease message size and improve performance.



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

[jira] [Updated] (IGNITE-2855) Apache Calcite as an SQL query parser and optimizer

[Roman Shtykh (JIRA)]

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

Roman Shtykh updated IGNITE-2855:
-
Priority: Minor  (was: Major)

> Apache Calcite as an SQL query parser and optimizer
> ---
>
> Key: IGNITE-2855
> URL: https://issues.apache.org/jira/browse/IGNITE-2855
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Roman Shtykh
>Priority: Minor
>
> Apache Calcite (https://calcite.apache.org/) can be used as an SQL query 
> parser, validator and optimizer with Ignite at the back end.



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

[jira] [Commented] (IGNITE-2809) Optimize IGFS performance.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-2809:
-

This is an umbrella ticket and should not be assigned to anyone.

> Optimize IGFS performance.
> --
>
> Key: IGNITE-2809
> URL: https://issues.apache.org/jira/browse/IGNITE-2809
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.7
>
>
> This is the umbrella ticket to host proposed IGFS performance improvements. 
> Currently IGFS is struggling from some inefficiencies. It moves lots of 
> unnecesary data over network. It has points of high contention - root and 
> trash directories. It has less than efficient default cache properties, etc..
> We need to take care about it.



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

[jira] [Commented] (IGNITE-2837) Docker daemon doesn't start on the AWS instances

[Vasilisa Sidorova (JIRA)]

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

Vasilisa  Sidorova commented on IGNITE-2837:


Please, fix the documentation also: update screenshot in the step 4 of the 
"Amazon EC2 Deployment" instruction onto new attached version 

> Docker daemon doesn't start on the AWS instances
> 
>
> Key: IGNITE-2837
> URL: https://issues.apache.org/jira/browse/IGNITE-2837
> Project: Ignite
>  Issue Type: Bug
>  Components: aws
>Affects Versions: 1.5.0.final
>Reporter: Vasilisa  Sidorova
> Attachments: ignite_aws_docker.png
>
>
> -
> DESCRIPTION
> -
> Deployment docker onto Amazon EC2 by this 
> https://apacheignite.readme.io/docs/docker-deployment instruction is failed
> -
> STEPS FOR REPRODUCE
> -
> Do items 1-7 from "Amazon EC2 Deployement" instruction
> Do item 8
> -
> ACTUAL RESULT
> -
> The list of containers is empty. And command "sudo ./startup.sh" get result:
> {noformat}
> --2016-03-15 16:51:56--  http://169.254.169.254/latest/user-data
> Connecting to 169.254.169.254:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 41 [application/octet-stream]
> Saving to: ‘user-data’
> user-data   
> 100%[===>]
>   41  --.-KB/s   in 0s 
> 2016-03-15 16:51:56 (10,1 MB/s) - ‘user-data’ saved [41/41]
> 1.5.0.final: Pulling from apacheignite/ignite
> 77e39ee82117: Already exists 
> 5eb1402f0414: Already exists 
> 9287fae7a16e: Already exists 
> 0288ae931294: Already exists 
> e5faec61f132: Already exists 
> 9e9bea63cb40: Already exists 
> dcb718404a8b: Already exists 
> a8ce4138c3d9: Already exists 
> 7c01b1c179c8: Already exists 
> a41c2ba526d9: Already exists 
> 5108e60af9fc: Already exists 
> 171a6bf29457: Already exists 
> 1e2a752083e5: Already exists 
> 6dc3a9ded560: Already exists 
> 5d9df50a72b0: Already exists 
> e3dee37923c1: Already exists 
> c7d92bcdbf90: Already exists 
> 8de8b8b056fa: Already exists 
> b298c64b2b41: Already exists 
> 8185ba03f727: Already exists 
> Digest: 
> sha256:8826e49c8ea2c008ad6225df672916eb98979701b91948fb3587432e785cf40a
> Status: Image is up to date for apacheignite/ignite:1.5.0.final
> 84ca163452f47cc0ec3a62861b6ca88ccc242ee80d5cb8594b3e4820606f113c
> {noformat}
> -
> EXPECTED RESULT
> -
> Docker daemon and Ignite nodes should be started on all running amazon 
> instances
> -
> ADDITIONAL INFO
> -
> Reproducible for all Amazon regions (west, east, central)
> For reproducing you can use instances with name ignite-docker-image in any 
> region



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

[jira] [Commented] (IGNITE-1630) .Net: Create LINQ adapter for queries.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-1630:


TODO:
* Add CompiledQuery example (as part of existing one)
* Think about AsCacheQueryable naming. NHibernate uses Linq(), should we do the 
same?

> .Net: Create LINQ adapter for queries.
> --
>
> Key: IGNITE-1630
> URL: https://issues.apache.org/jira/browse/IGNITE-1630
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.6
>
>
> SQL queries are one of the most frequently used features in data grids. And 
> .Net comes with a very nice LINQ concept. 
> * LINQ provider should come in a separate assembly
> * Make sure that assembly is included in binary distribution



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

[jira] [Resolved] (IGNITE-2549) ODBC: Implement example that can be used for data visualization.

[Igor Sapego (JIRA)]

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

Igor Sapego resolved IGNITE-2549.
-
Resolution: Won't Fix

> ODBC: Implement example that can be used for data visualization.
> 
>
> Key: IGNITE-2549
> URL: https://issues.apache.org/jira/browse/IGNITE-2549
> Project: Ignite
>  Issue Type: Sub-task
>  Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.6
>
> Attachments: ignite-2549.patch
>
>
> As the one of the purposes for development of the ODBC driver was to use data 
> visualization tools with Apache Ignite, we need to have example that can be 
> used to test interoperability with such tools. Such example should contain 
> several caches with relational data that can provide meaningful graphs when 
> visualized.



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

[jira] [Comment Edited] (IGNITE-2730) Ignite Events Source Streaming to Kafka

[Roman Shtykh (JIRA)]

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

Roman Shtykh edited comment on IGNITE-2730 at 3/18/16 7:05 AM:
---

Some implementation details for reviewers:
- I use a distributed queue as a buffer that is polled by Kafka. This is done 
to keep cache event data safe between polls.
- Schema facilities of Kafka Connect are not used -- cache events are 
marshalled with _JDKMarshaller_ and sent to Kafka. Later they can be 
deserialized with the provided _CacheEventDeserializer_, as done in the test 
code.
- Kafka partition keys are not used in the current implementation. If there are 
requests from users, we can enhance.


was (Author: roman_s):
Some implementation details for reviewers:
- I use a distributed queue as a buffer that is polled by Kafka. This is done 
to keep cache event data safe between polls.
- Schema facilities of Kafka Connect are not used -- cache events are 
marshalled with _JDKMarshaller_ and sent to Kafka. Later they can be 
deserialized with the provided _CacheEventDeserializer_, as done in the test 
code.
- Kafka partition keys are specified in the current implementation. If there 
are requests from users, we can enhance.

> Ignite Events Source Streaming to Kafka
> ---
>
> Key: IGNITE-2730
> URL: https://issues.apache.org/jira/browse/IGNITE-2730
> Project: Ignite
>  Issue Type: New Feature
>  Components: streaming
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>  Labels: community
>
> Streaming specified Ignite events 
> (https://apacheignite.readme.io/docs/events) to Kafka via Kafka Connect.
> It has to be added to org.apache.ignite.stream.kafka.connect package.



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

[jira] [Closed] (IGNITE-2816) IGFS: IgfsMetaManager should not use "put" to update parent listing.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-2816.
---

> IGFS: IgfsMetaManager should not use "put" to update parent listing.
> 
>
> Key: IGNITE-2816
> URL: https://issues.apache.org/jira/browse/IGNITE-2816
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.7
>
>
> Lightweight entry processor must be used instead.



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

[jira] [Resolved] (IGNITE-2860) IGFS: Simplify base file system operations for PRIMARY mode.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-2860.
-
Resolution: Fixed

> IGFS: Simplify base file  system operations for PRIMARY mode.
> -
>
> Key: IGNITE-2860
> URL: https://issues.apache.org/jira/browse/IGNITE-2860
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> Currently implementation of IGFS base operations for PRIMARY mode is overly 
> complex. It is prone to errors and do not let us implement relaxed mode 
> without code duplication.
> Need to refactor that.



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

[jira] [Updated] (IGNITE-2523) Introduce "single put" NEAR update request.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2523:

Fix Version/s: (was: 1.6)
   1.7

> Introduce "single put" NEAR update request.
> ---
>
> Key: IGNITE-2523
> URL: https://issues.apache.org/jira/browse/IGNITE-2523
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>
> Essentially, in this case we could get rid of all collections and garbage 
> inside GridNearAtomicUpdateRequest/GridDhtAtomicUpdateRequest.
> This should drastically decrease message size and improve performance.



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

[jira] [Closed] (IGNITE-2834) IGFS: Introduce optional co-location of metadata.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-2834.
---

> IGFS: Introduce optional co-location of metadata.
> -
>
> Key: IGNITE-2834
> URL: https://issues.apache.org/jira/browse/IGNITE-2834
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> *Description*
> IGFS meta manager heavily relies on transactions in REPLICATED cache. Some 
> transactions operate on more than 1 keys. As key affinity is not specified at 
> the moment, different Ignite nodes host different primary keys. As a result, 
> transaction on multiple keys might lead to relatively big number of network 
> requests during 2PC. 
> *Solution*
> If we co-located all metadata on a single node, transaction commit will 
> require less network trips, thus decreasing latency and contention.



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

[jira] [Assigned] (IGNITE-2809) Optimize IGFS performance.

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky reassigned IGNITE-2809:
---

Assignee: Ivan Veselovsky

> Optimize IGFS performance.
> --
>
> Key: IGNITE-2809
> URL: https://issues.apache.org/jira/browse/IGNITE-2809
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Ivan Veselovsky
>Priority: Critical
> Fix For: 1.7
>
>
> This is the umbrella ticket to host proposed IGFS performance improvements. 
> Currently IGFS is struggling from some inefficiencies. It moves lots of 
> unnecesary data over network. It has points of high contention - root and 
> trash directories. It has less than efficient default cache properties, etc..
> We need to take care about it.



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

[jira] [Commented] (IGNITE-2523) Introduce "single put" NEAR update request.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-2523:
-

Moved to 1.7. It looks like we should implement optimzied paths for 
single-updates in futures and only then apply any protocol changes.

> Introduce "single put" NEAR update request.
> ---
>
> Key: IGNITE-2523
> URL: https://issues.apache.org/jira/browse/IGNITE-2523
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>
> Essentially, in this case we could get rid of all collections and garbage 
> inside GridNearAtomicUpdateRequest/GridDhtAtomicUpdateRequest.
> This should drastically decrease message size and improve performance.



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

[jira] [Closed] (IGNITE-1697) IGFS: implement reliable Igfs failover logic

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-1697.
---

> IGFS: implement reliable Igfs failover logic 
> -
>
> Key: IGNITE-1697
> URL: https://issues.apache.org/jira/browse/IGNITE-1697
> Project: Ignite
>  Issue Type: Bug
>  Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Ivan Veselovsky
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> Problems to solve:
> 1) currently a write lock for a file may stay taken forever if a node have 
> taken the lock and then crashed.
> 2) Currently the blocks of file content are written not just as 
> dataCache.put() operations , but sent using ad-hoc async messages. This was 
> done earlier to improve performance. But in order to implement reliable 
> failover we need to get rid of that and use simple put() or asyncPut() cache 
> operations.
> Solution plan:
> 1) use async put to write file data blocks.
> 2) do writing using scheme "lock" -> "reserve space" -> "write" -> "commit" 
> -> "release lock".
> 3) The id of the node that locked a file should be readable from the lock id.
> 4) Upon taking a file lock the following procedure should be performed: 
> if file is locked, take the node Id of the node that locked the file. After 
> that ask DiscoveryProcessor if this node is alive. If it is not (node has 
> left topology), perform cleanup procedure: delete all the data blocks of the 
> reserved data range, then delete the lock.



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

[jira] [Created] (IGNITE-2860) IGFS: Simplify base file system operations for PRIMARY mode.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-2860:
---

 Summary: IGFS: Simplify base file  system operations for PRIMARY 
mode.
 Key: IGNITE-2860
 URL: https://issues.apache.org/jira/browse/IGNITE-2860
 Project: Ignite
  Issue Type: Task
  Components: IGFS
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 1.6


Currently implementation of IGFS base operations for PRIMARY mode is overly 
complex. It is prone to errors and do not let us implement relaxed mode without 
code duplication.

Need to refactor that.



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

[jira] [Closed] (IGNITE-2861) IGFS: Move meta processors to separate classes.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-2861.
---

> IGFS: Move meta processors to separate classes.
> ---
>
> Key: IGNITE-2861
> URL: https://issues.apache.org/jira/browse/IGNITE-2861
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Minor
> Fix For: 1.6
>
>
> The goal is to simplify {{IgfsMetaManager}}.



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

[jira] [Resolved] (IGNITE-2861) IGFS: Move meta processors to separate classes.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-2861.
-
Resolution: Fixed

> IGFS: Move meta processors to separate classes.
> ---
>
> Key: IGNITE-2861
> URL: https://issues.apache.org/jira/browse/IGNITE-2861
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Minor
> Fix For: 1.6
>
>
> The goal is to simplify {{IgfsMetaManager}}.



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

[jira] [Commented] (IGNITE-1433) .Net: Add IgniteException.JavaStackTrace

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-1433:


1) It does help A LOT, almost every day I face a situation where I have to run 
tests with console open to find out what's going on. It is a waste of time, and 
it is not always easy to find related exception in the console. 
We cannot predict every single situation to improve usability with it.

2) This makes sense. Instead of IgniteException.JavaStackTrace, we can populate 
InnerException property with some JavaException instance, or even plain 
Exception with java trace in the message. This way we don't pollute the API. 
Thoughts?

I still think that this ticket is very important and will defend it as long as 
I can :)



> .Net: Add IgniteException.JavaStackTrace
> 
>
> Key: IGNITE-1433
> URL: https://issues.apache.org/jira/browse/IGNITE-1433
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
> Fix For: 1.6
>
>
> Propagate java stack trace as a string in ExceptionUtils.GetException and 
> write it to a new field in IgniteException class.
> This will simplify debugging for us both locally and when getting error 
> reports from clients.



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

[jira] [Updated] (IGNITE-2002) Data streamer does not work with peerClassLoadingEnabled

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-2002:
---
Summary: Data streamer does not work with peerClassLoadingEnabled  (was: 
.Net: Data streamer does not work with peerClassLoadingEnabled)

> Data streamer does not work with peerClassLoadingEnabled
> 
>
> Key: IGNITE-2002
> URL: https://issues.apache.org/jira/browse/IGNITE-2002
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Priority: Critical
> Fix For: 1.6
>
>
> Add  to spring config, 
> run streamer tests or examples, there are exceptions in Java and flush hangs.



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

[jira] [Commented] (IGNITE-2730) Ignite Events Source Streaming to Kafka

[Roman Shtykh (JIRA)]

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

Roman Shtykh commented on IGNITE-2730:
--

TC tests are good.

> Ignite Events Source Streaming to Kafka
> ---
>
> Key: IGNITE-2730
> URL: https://issues.apache.org/jira/browse/IGNITE-2730
> Project: Ignite
>  Issue Type: New Feature
>  Components: streaming
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>  Labels: community
>
> Streaming specified Ignite events 
> (https://apacheignite.readme.io/docs/events) to Kafka via Kafka Connect.
> It has to be added to org.apache.ignite.stream.kafka.connect package.



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

[jira] [Commented] (IGNITE-2850) ODBC: Add documentation for the ODBC.

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-2850:
-

I have forked 1.6 documentation version and created 1.6-b. Added section 
{{Drivers}} and moved {{JDBC Driver}} article there. Also I have added {{ODBC 
Driver}} article to this section.

> ODBC: Add documentation for the ODBC.
> -
>
> Key: IGNITE-2850
> URL: https://issues.apache.org/jira/browse/IGNITE-2850
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation, odbc
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.6
>
>
> Need to add documentation for the ODBC to http://apacheignite.gridgain.org



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

[jira] [Commented] (IGNITE-2855) Apache Calcite as an SQL query parser and optimizer

[Sergi Vladykin (JIRA)]

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

Sergi Vladykin commented on IGNITE-2855:


I don't think it's worth trying to integrate this fancy thing in ignite (in 
near future at least). But may be it makes sense to do some experimenting in 
independent integration project and evaluate what it can give us.

> Apache Calcite as an SQL query parser and optimizer
> ---
>
> Key: IGNITE-2855
> URL: https://issues.apache.org/jira/browse/IGNITE-2855
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Roman Shtykh
>
> Apache Calcite (https://calcite.apache.org/) can be used as an SQL query 
> parser, validator and optimizer with Ignite at the back end.



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

[jira] [Commented] (IGNITE-2693) withKeepBinary and non-binary marshallers

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-2693:
-

Hi Oddo,

Before {{BinaryMarshaller}} was created, Ignite had used 
{{OptimizedMarshaller}} as default one. And in our test framework we still has 
OptimizedMarshaller as default. You can see this in the method 
{{IgniteTestResources.getMarshaller()}}. 

I would recommend you create your own configuration and set BinaryMarshaller 
explicitly.

Vladimir.

> withKeepBinary and non-binary marshallers
> -
>
> Key: IGNITE-2693
> URL: https://issues.apache.org/jira/browse/IGNITE-2693
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Sergey Kozlov
>Assignee: Oddo
>  Labels: newbie
> Fix For: 1.6
>
>
> Currently the user is able to set {{.withKeepBinary()}} for any used 
> marshaller. But it obviously causes ClassCastException for non-binary 
> marshallers and should be available only for binary marshaller.



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

[jira] [Created] (IGNITE-2852) TreeMap can't be converted to portable

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-2852:
---

 Summary: TreeMap can't be converted to portable
 Key: IGNITE-2852
 URL: https://issues.apache.org/jira/browse/IGNITE-2852
 Project: Ignite
  Issue Type: Bug
  Components: binary
Affects Versions: 1.5.0.final
Reporter: Valentin Kulichenko
 Fix For: 1.6


When trying to convert {{TreeMap}} into binary object using {{toBinary}} 
method, the following exception fails:

{noformat}
Exception in thread "main" java.lang.ClassCastException: 
org.apache.ignite.internal.binary.BinaryObjectImpl cannot be cast to 
java.lang.Comparable
at java.util.TreeMap.compare(TreeMap.java:1188)
at java.util.TreeMap.put(TreeMap.java:531)
at 
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:495)
at 
org.apache.ignite.internal.processors.cache.binary.IgniteBinaryImpl.toBinary(IgniteBinaryImpl.java:67)
at TreeMapTest.main(TreeMapTest.java:15)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
{noformat}

This happens because maps are not wrapped into binary objects, therefore we 
create another {{TreeMap}} and put {{BinaryObject}} instances, which are not 
{{Comparable}}.



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

[jira] [Updated] (IGNITE-1697) IGFS: implement reliable Igfs failover logic

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-1697:

Affects Version/s: 1.5.0.final

> IGFS: implement reliable Igfs failover logic 
> -
>
> Key: IGNITE-1697
> URL: https://issues.apache.org/jira/browse/IGNITE-1697
> Project: Ignite
>  Issue Type: Bug
>  Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Ivan Veselovsky
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> Problems to solve:
> 1) currently a write lock for a file may stay taken forever if a node have 
> taken the lock and then crashed.
> 2) Currently the blocks of file content are written not just as 
> dataCache.put() operations , but sent using ad-hoc async messages. This was 
> done earlier to improve performance. But in order to implement reliable 
> failover we need to get rid of that and use simple put() or asyncPut() cache 
> operations.
> Solution plan:
> 1) use async put to write file data blocks.
> 2) do writing using scheme "lock" -> "reserve space" -> "write" -> "commit" 
> -> "release lock".
> 3) The id of the node that locked a file should be readable from the lock id.
> 4) Upon taking a file lock the following procedure should be performed: 
> if file is locked, take the node Id of the node that locked the file. After 
> that ask DiscoveryProcessor if this node is alive. If it is not (node has 
> left topology), perform cleanup procedure: delete all the data blocks of the 
> reserved data range, then delete the lock.



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

[jira] [Closed] (IGNITE-2820) IGFS: Ensure that all participating IDs are locked right after TX start.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-2820.
---

> IGFS: Ensure that all participating IDs are locked right after TX start.
> 
>
> Key: IGNITE-2820
> URL: https://issues.apache.org/jira/browse/IGNITE-2820
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.7
>
>
> *Problem*
> Sometimes we have to create new entries during some operation on metadata. If 
> we do not lock this ID along with other participating IDs right after TX 
> start, subsequent cache operation on this ID will result in network calls to 
> block this key on other nodes.
> *Solution*
> Create potentially new key before entering TX and lock it with other keys. 
> This should decrease number of network calls.



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

[jira] [Commented] (IGNITE-2851) ODBC: Metadata type retrieval algorithm is wrong.

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-2851:
-

Merged with IGNITE-2663.

> ODBC: Metadata type retrieval algorithm is wrong.
> -
>
> Key: IGNITE-2851
> URL: https://issues.apache.org/jira/browse/IGNITE-2851
> Project: Ignite
>  Issue Type: Sub-task
>  Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.6
>
>
> OdbcColumnMeta.writeBinary() method retrieves binary type for the class in a 
> wrong way. Use BinaryUtils.typeByClass() instead of BinaryClassDescriptor.



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

[jira] [Created] (IGNITE-2862) Deployment Ignite in Mesos cluster is failed

[Vasilisa Sidorova (JIRA)]

Vasilisa  Sidorova created IGNITE-2862:
--

 Summary: Deployment Ignite in Mesos cluster is failed
 Key: IGNITE-2862
 URL: https://issues.apache.org/jira/browse/IGNITE-2862
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.5.0.final
Reporter: Vasilisa  Sidorova


-
DESCRIPTION
-
Deployment  Ignite in Mesos cluster by this instruction 
https://apacheignite.readme.io/docs/mesos-deployment is failed 
-
STEPS FOR REPRODUCE
-
# Do items 1-5 from "RUN THE FRAMEWORK VIA MARATHON"   paragraph 
-
ACTUAL RESULT
-
# Ignite nodes didn't start. Only ignition task is running. Look at the 
attached picture "mesos_activetasks.png"
# Stderr log for ignition task get follow exception:
{noformat}
I0318 18:42:08.252142 17138 fetcher.cpp:409] Fetcher Info: 
{"cache_directory":"\/tmp\/mesos\/fetch\/slaves\/20160318-180241-16777343-5050-16554-S0\/root","items":[{"action":"BYPASS_CACHE","uri":{"extract":false,"value":"https:\/\/s3.amazonaws.com\/vasilisk\/m\/ignite-mesos-1.5.0.final.jar"}}],"sandbox_directory":"\/tmp\/mesos\/slaves\/20160318-180241-16777343-5050-16554-S0\/frameworks\/20150603-121744-16842879-5050-6241-\/executors\/ignition.f8fa2435-ed1f-11e5-bea1-0242e00dbbdd\/runs\/776db62f-965f-4e9e-950a-4edb67c44667","user":"root"}
I0318 18:42:08.253284 17138 fetcher.cpp:364] Fetching URI 
'https://s3.amazonaws.com/vasilisk/m/ignite-mesos-1.5.0.final.jar'
I0318 18:42:08.253298 17138 fetcher.cpp:238] Fetching directly into the sandbox 
directory
I0318 18:42:08.253312 17138 fetcher.cpp:176] Fetching URI 
'https://s3.amazonaws.com/vasilisk/m/ignite-mesos-1.5.0.final.jar'
I0318 18:42:08.253325 17138 fetcher.cpp:126] Downloading resource from 
'https://s3.amazonaws.com/vasilisk/m/ignite-mesos-1.5.0.final.jar' to 
'/tmp/mesos/slaves/20160318-180241-16777343-5050-16554-S0/frameworks/20150603-121744-16842879-5050-6241-/executors/ignition.f8fa2435-ed1f-11e5-bea1-0242e00dbbdd/runs/776db62f-965f-4e9e-950a-4edb67c44667/ignite-mesos-1.5.0.final.jar'
I0318 18:42:12.091784 17138 fetcher.cpp:441] Fetched 
'https://s3.amazonaws.com/vasilisk/m/ignite-mesos-1.5.0.final.jar' to 
'/tmp/mesos/slaves/20160318-180241-16777343-5050-16554-S0/frameworks/20150603-121744-16842879-5050-6241-/executors/ignition.f8fa2435-ed1f-11e5-bea1-0242e00dbbdd/runs/776db62f-965f-4e9e-950a-4edb67c44667/ignite-mesos-1.5.0.final.jar'
I0318 18:42:12.293658 17142 exec.cpp:132] Version: 0.23.0
I0318 18:42:12.296212 17145 exec.cpp:206] Executor registered on slave 
20160318-180241-16777343-5050-16554-S0
Mar 18, 2016 6:42:12 PM org.apache.ignite.mesos.IgniteFramework main
INFO: Enabling checkpoint for the framework
2016-03-18 18:42:12.495:INFO::main: Logging initialized @151ms
2016-03-18 18:42:22.542:INFO:oejs.Server:main: jetty-9.2.z-SNAPSHOT
2016-03-18 18:42:22.579:INFO:oejs.ServerConnector:main: Started 
ServerConnector@1268c278{HTTP/1.1}{172.17.0.1:48610}
2016-03-18 18:42:22.580:INFO:oejs.Server:main: Started @10235ms
Exception in thread "main" java.lang.RuntimeException: Got unexpected response 
code. Response code: 404
at 
org.apache.ignite.mesos.resource.IgniteProvider.downloadIgnite(IgniteProvider.java:202)
at 
org.apache.ignite.mesos.resource.IgniteProvider.getIgnite(IgniteProvider.java:132)
at 
org.apache.ignite.mesos.resource.ResourceProvider.init(ResourceProvider.java:57)
at org.apache.ignite.mesos.IgniteFramework.main(IgniteFramework.java:77)
{noformat}

-
EXPECTED RESULT
-
Tasks for all 3 nodes are running with ignition task. 
-
ADDITIONAL INFO
-
# File "marathon.json" is attached




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

[jira] [Updated] (IGNITE-2863) Memory leak in GridUnsafeMap destruct method.

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan updated IGNITE-2863:
--
Fix Version/s: 1.6

> Memory leak in GridUnsafeMap destruct method.
> -
>
> Key: IGNITE-2863
> URL: https://issues.apache.org/jira/browse/IGNITE-2863
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, general
>Reporter: Krome Plasma
> Fix For: 1.6
>
> Attachments: memoryLeak.patch
>
>
> There's a memory leak in GridUnsafeMap destruct method() for loop.
> The loop's condition is wrong "binAddr < memCap" where offset + memCap should 
> be used.



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

[jira] [Updated] (IGNITE-2863) Memory leak in GridUnsafeMap destruct method.

[Krome Plasma (JIRA)]

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

Krome Plasma updated IGNITE-2863:
-
Attachment: memoryLeak.patch

> Memory leak in GridUnsafeMap destruct method.
> -
>
> Key: IGNITE-2863
> URL: https://issues.apache.org/jira/browse/IGNITE-2863
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, general
>Reporter: Krome Plasma
> Attachments: memoryLeak.patch
>
>
> There's a memory leak in GridUnsafeMap destruct method() for loop.
> The loop's condition is wrong "binAddr < memCap" where offset + memCap should 
> be used.



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

[jira] [Commented] (IGNITE-2863) Memory leak in GridUnsafeMap destruct method.

[Krome Plasma (JIRA)]

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

Krome Plasma commented on IGNITE-2863:
--

I've attached a small patch.

> Memory leak in GridUnsafeMap destruct method.
> -
>
> Key: IGNITE-2863
> URL: https://issues.apache.org/jira/browse/IGNITE-2863
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, general
>Reporter: Krome Plasma
> Attachments: memoryLeak.patch
>
>
> There's a memory leak in GridUnsafeMap destruct method() for loop.
> The loop's condition is wrong "binAddr < memCap" where offset + memCap should 
> be used.



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

[jira] [Created] (IGNITE-2863) Memory leak in GridUnsafeMap destruct method.

[Krome Plasma (JIRA)]

Krome Plasma created IGNITE-2863:


 Summary: Memory leak in GridUnsafeMap destruct method.
 Key: IGNITE-2863
 URL: https://issues.apache.org/jira/browse/IGNITE-2863
 Project: Ignite
  Issue Type: Bug
  Components: cache, general
Reporter: Krome Plasma


There's a memory leak in GridUnsafeMap destruct method() for loop.
The loop's condition is wrong "binAddr < memCap" where offset + memCap should 
be used.



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

[jira] [Created] (IGNITE-2853) Job processor should be stopped earlier than service processor

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-2853:
---

 Summary: Job processor should be stopped earlier than service 
processor
 Key: IGNITE-2853
 URL: https://issues.apache.org/jira/browse/IGNITE-2853
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.5.0.final
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
 Fix For: 1.6


It's a common use case when a compute job accesses service. Currently, if such 
job is cancelled, it can't do this gracefully, because service is already 
stopped.



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

[jira] [Created] (IGNITE-2859) IGFS: test org.apache.ignite.internal.processors.igfs.IgfsStartCacheTest#testCacheStart fakily fails

[Ivan Veselovsky (JIRA)]

Ivan Veselovsky created IGNITE-2859:
---

 Summary: IGFS: test 
org.apache.ignite.internal.processors.igfs.IgfsStartCacheTest#testCacheStart 
fakily fails
 Key: IGNITE-2859
 URL: https://issues.apache.org/jira/browse/IGNITE-2859
 Project: Ignite
  Issue Type: Bug
  Components: IGFS
Affects Versions: 1.6
Reporter: Ivan Veselovsky
 Fix For: 1.6


{code}
java.io.IOException: File was concurrently deleted: /test/test.file
at 
org.apache.ignite.internal.processors.igfs.IgfsOutputStreamImpl.flush(IgfsOutputStreamImpl.java:278)
at 
org.apache.ignite.internal.processors.igfs.IgfsOutputStreamAdapter.close(IgfsOutputStreamAdapter.java:182)
at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:320)
at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:149)
at java.io.OutputStreamWriter.close(OutputStreamWriter.java:233)
at java.io.BufferedWriter.close(BufferedWriter.java:266)
at 
org.apache.ignite.internal.processors.igfs.IgfsStartCacheTest.testCacheStart(IgfsStartCacheTest.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1758)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1696)
at java.lang.Thread.run(Thread.java:745)

{code}

In method 
org.apache.ignite.internal.processors.igfs.IgfsOutputStreamImpl#flush() 
existence of the file being written is checked with id2InfoPrj.get(id) .
For some reason it appears that sometimes this get returns null, while method 
org.apache.ignite.internal.processors.igfs.IgfsMetaManager#create guaranteed to 
return at this point, and the file creation transaction must already be 
committed.



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

[jira] [Updated] (IGNITE-2801) Coordinator floods network with partitions full map exchange messages

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-2801:

Summary: Coordinator floods network with partitions full map exchange 
messages  (was: Coordinator floods network with partitions' full map messages)

> Coordinator floods network with partitions full map exchange messages
> -
>
> Key: IGNITE-2801
> URL: https://issues.apache.org/jira/browse/IGNITE-2801
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Priority: Critical
>  Labels: community, important
> Fix For: 1.6
>
> Attachments: basic_node.nps, basic_node.png, coordinator.nps, 
> coordinator.png
>
>
> It is detected that the more machines in the cluster we have and the more 
> caches are started then the more outgoing traffic is produced by a 
> coordinator node.
> As an example in the current deployment
> - 30 nodes;
> - 67 caches;
> - caches are empty and the cluster is not used at all (idle).
> the coordinator constantly uses 300 Mbit/s of outgoing traffic. In contrast 
> each other node shows constant 10 Mbit/s usage of incoming traffic.
> Most likely the reason is that the coordinator indefinitely sends partitions 
> full map for all the caches to all the nodes. This shouldn't happen.
> Need to debug the reason of the issue and fix it.
> Attached snapshots taken from the coordinator and on of cluster's nodes. 
> Probably they would help.



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

[jira] [Commented] (IGNITE-2708) Need to validate that SPIs are started only once

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-2708:
-

Hi, is there any reason why it's implemented not in the way it is described in 
the ticket? The purpose of this task is to make sure that {{spiStart}} is never 
called more than once on the same instance. I don't like setting the flag in 
{{injectResources}} method instead, this looks like a dirty hack.

In addition two nodes with the same SPI instance can be started concurrently. 
You solution is not thread-safe and doesn't work in this scenario. You may want 
to use {{AtomicBoolean.compareAndSet}} here instead of non-volatile boolean 
variable.

> Need to validate that SPIs are started only once
> 
>
> Key: IGNITE-2708
> URL: https://issues.apache.org/jira/browse/IGNITE-2708
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Reporter: Valentin Kulichenko
>Assignee: Ryan Zhao
>  Labels: newbie, usability
>
> User forum discussion: 
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-instance-hangs-during-restart-in-client-mode-td3101.html
> If one uses the same instance of {{IgniteConfiguration}} more than once, it 
> doesn't work because SPIs have lifecycle and can be started only once. 
> Currently this causes hang on start which is counterintuitive.
> We should add a validation step to {{GridSpiAdapter}} that will check that 
> the SPI was never started before. Its {{spiStart()}} method should set some 
> flag there or throw exception if it has already been set. All internal SPI 
> implementations should be changed to call {{super.spiStart()}} as first 
> statement.



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

[jira] [Commented] (IGNITE-1743) IGFS: Use async cache put instead of block/ack messages on data write

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-1743:
-

Also sometimes we see hangs during file updates. Probably they are caused by a 
kind of thread-pool starvation. Probably this problem is related to the ticket. 
Once we switch to normal cache updates, the problem is likely to go away.

> IGFS: Use async cache put instead of block/ack messages on data write
> -
>
> Key: IGNITE-1743
> URL: https://issues.apache.org/jira/browse/IGNITE-1743
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
> Fix For: 1.7
>
>
> Item "1)" from IGNITE-1697



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

[jira] [Updated] (IGNITE-2797) Prepare and finish future never time out

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-2797:

Attachment: TxTest2.java

> Prepare and finish future never time out
> 
>
> Key: IGNITE-2797
> URL: https://issues.apache.org/jira/browse/IGNITE-2797
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Priority: Blocker
>  Labels: community, customer, important
> Fix For: 1.6
>
> Attachments: TxTest2.java
>
>
> Even if transaction timeout is configured, transaction will not timeout if 
> it's already in prepare state. It will be shown in log as pending transaction 
> and can cause the whole cluster hang.
> We need to add a mechanism that will properly timeout prepare and (if 
> possible) finish futures.
> Also we can create an event that will be fired if there is a transaction 
> pending for a long time, showing which nodes we are waiting responses from. 
> This will allow user to recover by stopping only these nodes instead of 
> restarting the whole cluster.



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

[jira] [Commented] (IGNITE-2693) withKeepBinary and non-binary marshallers

[Oddo (JIRA)]

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

Oddo commented on IGNITE-2693:
--

Vladimir,

I must confess I am a bit confused by the whole thing.

>From the failing tests, grid(0).cache(null) - what marshaller does this 
>actually use? I would expect this to use the default binary marshaller but it 
>does not appear to do so. Where is the optimized marshaller actually set and 
>how do I change it? I am not really sure what the failing test actually does 
>:-(


> withKeepBinary and non-binary marshallers
> -
>
> Key: IGNITE-2693
> URL: https://issues.apache.org/jira/browse/IGNITE-2693
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Sergey Kozlov
>Assignee: Oddo
>  Labels: newbie
> Fix For: 1.6
>
>
> Currently the user is able to set {{.withKeepBinary()}} for any used 
> marshaller. But it obviously causes ClassCastException for non-binary 
> marshallers and should be available only for binary marshaller.



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

[jira] [Updated] (IGNITE-2847) Failed atomic-offheap-invoke-retry load consistency test

[Ilya Suntsov (JIRA)]

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

Ilya Suntsov updated IGNITE-2847:
-
Attachment: logs_1_backup.zip

> Failed atomic-offheap-invoke-retry load consistency test
> 
>
> Key: IGNITE-2847
> URL: https://issues.apache.org/jira/browse/IGNITE-2847
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.6
> Environment: Yardstick driver's host: 
> Ubuntu 14.04.3 LTS
> Yardstick server's hosts: Ubuntu 14.04.3 LTS and CentOS release 6.7 (Final)
>Reporter: Ilya Suntsov
>Assignee: Artem Shutak
>Priority: Critical
> Fix For: 1.6
>
> Attachments: logs_1_backup.zip, logs_configs.zip
>
>
> I ran load test with 2 backups in client mode (1 client, 4 servers) on 3 
> hosts (host1 - client, hosts-2,3 - 2 data nodes on each) and got the 
> following exception after 5h of work of test:
> {noformat}
> <13:49:20> Got 
> exception: 
> org.apache.ignite.yardstick.cache.failover.IgniteConsistencyException: Cache 
> and local map are in inconsistent state [badKeys=[key-62687]]
> org.apache.ignite.yardstick.cache.failover.IgniteConsistencyException: Cache 
> and local map are in inconsistent state 
> [badKeys=[key-62687]]<13:49:20> Full thread 
> dump of the current node below.
> {noformat}
> Logs in attachment.



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

[jira] [Resolved] (IGNITE-2848) Ignite OSGI exit code 1 on TC

[Anton Vinogradov (JIRA)]

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

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

Build splitted to 
1)mvn install -U -Plgpl,examples,-clean-libs,-release -Dmaven.javadoc.skip=true 
-DskipTests
2)mvn test -U -Plgpl,examples,-clean-libs,-release 
-Dmaven.test.failure.ignore=true -Dmaven.javadoc.skip=true 
-DfailIfNoTests=false -Dtest=%TEST_SUITE%

> Ignite OSGI exit code 1 on TC
> -
>
> Key: IGNITE-2848
> URL: https://issues.apache.org/jira/browse/IGNITE-2848
> Project: Ignite
>  Issue Type: Bug
>Reporter: Artem Shutak
>Assignee: Anton Vinogradov
>
> http://204.14.53.153/viewLog.html?buildId=208978=buildResultsDiv=IgniteTests_IgniteOSGi
> {noformat}
> [09:20:59]Step 5/6: Build and run tests OSGi (Maven) (7m:17s)
> [09:28:14][Step 5/6] org.apache.ignite:ignite-weblogic-test
> [09:28:14][org.apache.ignite:ignite-weblogic-test] Failed to execute goal 
> org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-war) on project 
> ignite-weblogic-test: Failed to copy file for artifact 
> [org.apache.ignite:ignite-core:jar:1.6.0-SNAPSHOT:compile]
> [09:28:16][Step 5/6] Step Build and run tests OSGi (Maven) failed
> {noformat}



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

[jira] [Closed] (IGNITE-2859) IGFS: test org.apache.ignite.internal.processors.igfs.IgfsStartCacheTest#testCacheStart fakily fails

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-2859.
---

> IGFS: test 
> org.apache.ignite.internal.processors.igfs.IgfsStartCacheTest#testCacheStart 
> fakily fails
> 
>
> Key: IGNITE-2859
> URL: https://issues.apache.org/jira/browse/IGNITE-2859
> Project: Ignite
>  Issue Type: Bug
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Ivan Veselovsky
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> {code}
> java.io.IOException: File was concurrently deleted: /test/test.file
>   at 
> org.apache.ignite.internal.processors.igfs.IgfsOutputStreamImpl.flush(IgfsOutputStreamImpl.java:278)
>   at 
> org.apache.ignite.internal.processors.igfs.IgfsOutputStreamAdapter.close(IgfsOutputStreamAdapter.java:182)
>   at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:320)
>   at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:149)
>   at java.io.OutputStreamWriter.close(OutputStreamWriter.java:233)
>   at java.io.BufferedWriter.close(BufferedWriter.java:266)
>   at 
> org.apache.ignite.internal.processors.igfs.IgfsStartCacheTest.testCacheStart(IgfsStartCacheTest.java:127)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1758)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1696)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> In method 
> org.apache.ignite.internal.processors.igfs.IgfsOutputStreamImpl#flush() 
> existence of the file being written is checked with id2InfoPrj.get(id) .
> For some reason it appears that sometimes this get returns null, while method 
> org.apache.ignite.internal.processors.igfs.IgfsMetaManager#create guaranteed 
> to return at this point, and the file creation transaction must already be 
> committed.



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

[jira] [Closed] (IGNITE-2815) IGFS: IgfsMetaManager.create() should not use "putIfAbsent" to create a file.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-2815.
---

> IGFS: IgfsMetaManager.create() should not use "putIfAbsent" to create a file.
> -
>
> Key: IGNITE-2815
> URL: https://issues.apache.org/jira/browse/IGNITE-2815
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.7
>
>
> This is less than optimal approach. Instead, we should use entry processor 
> which will accept file ID, block size and properties.



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

[jira] [Closed] (IGNITE-2549) ODBC: Implement example that can be used for data visualization.

[Igor Sapego (JIRA)]

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

Igor Sapego closed IGNITE-2549.
---

> ODBC: Implement example that can be used for data visualization.
> 
>
> Key: IGNITE-2549
> URL: https://issues.apache.org/jira/browse/IGNITE-2549
> Project: Ignite
>  Issue Type: Sub-task
>  Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.6
>
> Attachments: ignite-2549.patch
>
>
> As the one of the purposes for development of the ODBC driver was to use data 
> visualization tools with Apache Ignite, we need to have example that can be 
> used to test interoperability with such tools. Such example should contain 
> several caches with relational data that can provide meaningful graphs when 
> visualized.



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

[jira] [Assigned] (IGNITE-2801) Coordinator floods network with partitions full map exchange messages

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov reassigned IGNITE-2801:


Assignee: Anton Vinogradov

> Coordinator floods network with partitions full map exchange messages
> -
>
> Key: IGNITE-2801
> URL: https://issues.apache.org/jira/browse/IGNITE-2801
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Anton Vinogradov
>Priority: Critical
>  Labels: community, important
> Fix For: 1.6
>
> Attachments: basic_node.nps, basic_node.png, coordinator.nps, 
> coordinator.png
>
>
> It is detected that the more machines in the cluster we have and the more 
> caches are started then the more outgoing traffic is produced by a 
> coordinator node.
> As an example in the current deployment
> - 30 nodes;
> - 67 caches;
> - caches are empty and the cluster is not used at all (idle).
> the coordinator constantly uses 300 Mbit/s of outgoing traffic. In contrast 
> each other node shows constant 10 Mbit/s usage of incoming traffic.
> Most likely the reason is that the coordinator indefinitely sends partitions 
> full map for all the caches to all the nodes. This shouldn't happen.
> Need to debug the reason of the issue and fix it.
> Attached snapshots taken from the coordinator and on of cluster's nodes. 
> Probably they would help.



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

[jira] [Commented] (IGNITE-2694) .NET: AnyCPU build

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-2694:


1) Fixed
2) Confirmed

> .NET: AnyCPU build
> --
>
> Key: IGNITE-2694
> URL: https://issues.apache.org/jira/browse/IGNITE-2694
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.6
>
>
> Currently we provide separate x86 & x64 binaries. NuGet is x64-only.
> This is inconvenient both for us and the user.
> The only thing that prevents AnyCPU is unmanaged "common" project.
> But we load it dynamically from resources, and we may as well detect current 
> process platform (x64 or not) and load a proper unmanaged resource.



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

[jira] [Commented] (IGNITE-2004) Asynchronous execution of ContinuousQuery's remote filter & local list

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-2004:
--

Added separate thread pool which used for executing callbacks. If a listener 
and a filter implements marker interface then they will be submitted in 
non-system thread pool.

> Asynchronous execution of ContinuousQuery's remote filter & local list
> --
>
> Key: IGNITE-2004
> URL: https://issues.apache.org/jira/browse/IGNITE-2004
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Nikolay Tikhonov
>  Labels: important
> Fix For: 1.6
>
>
> Presently remote filters are executed synchronously an entry update. This 
> leads to the limitation when it's disallowed to perform cache related 
> operation in a filter body.
> It's required to add the ability to execute remote filters asynchronously. 
> This will let to execute any kind of operations including cache operations 
> directly in the filter body.
> The solution must be fault-tolerant. At least once execution of a filter in 
> case of a failure works fine. 



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

[jira] [Updated] (IGNITE-2122) .NET: Add generic Read/WriteCollection and Read/WriteDictionary methods.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-2122:
---
Fix Version/s: (was: 1.6)

> .NET: Add generic Read/WriteCollection and Read/WriteDictionary methods.
> 
>
> Key: IGNITE-2122
> URL: https://issues.apache.org/jira/browse/IGNITE-2122
> Project: Ignite
>  Issue Type: Task
>  Components: general, platforms
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Critical
>




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

[jira] [Assigned] (IGNITE-2859) IGFS: test org.apache.ignite.internal.processors.igfs.IgfsStartCacheTest#testCacheStart fakily fails

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-2859:
---

Assignee: Vladimir Ozerov

> IGFS: test 
> org.apache.ignite.internal.processors.igfs.IgfsStartCacheTest#testCacheStart 
> fakily fails
> 
>
> Key: IGNITE-2859
> URL: https://issues.apache.org/jira/browse/IGNITE-2859
> Project: Ignite
>  Issue Type: Bug
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Ivan Veselovsky
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> {code}
> java.io.IOException: File was concurrently deleted: /test/test.file
>   at 
> org.apache.ignite.internal.processors.igfs.IgfsOutputStreamImpl.flush(IgfsOutputStreamImpl.java:278)
>   at 
> org.apache.ignite.internal.processors.igfs.IgfsOutputStreamAdapter.close(IgfsOutputStreamAdapter.java:182)
>   at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:320)
>   at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:149)
>   at java.io.OutputStreamWriter.close(OutputStreamWriter.java:233)
>   at java.io.BufferedWriter.close(BufferedWriter.java:266)
>   at 
> org.apache.ignite.internal.processors.igfs.IgfsStartCacheTest.testCacheStart(IgfsStartCacheTest.java:127)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1758)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1696)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> In method 
> org.apache.ignite.internal.processors.igfs.IgfsOutputStreamImpl#flush() 
> existence of the file being written is checked with id2InfoPrj.get(id) .
> For some reason it appears that sometimes this get returns null, while method 
> org.apache.ignite.internal.processors.igfs.IgfsMetaManager#create guaranteed 
> to return at this point, and the file creation transaction must already be 
> committed.



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

[jira] [Created] (IGNITE-2850) ODBC: Add documentation for the ODBC.

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-2850:
---

 Summary: ODBC: Add documentation for the ODBC.
 Key: IGNITE-2850
 URL: https://issues.apache.org/jira/browse/IGNITE-2850
 Project: Ignite
  Issue Type: Sub-task
  Components: documentation, odbc
Affects Versions: 1.5.0.final
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 1.6


Need to add documentation for the ODBC to http://apacheignite.gridgain.org



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

[jira] [Commented] (IGNITE-2663) ODBC: Add protocol version to protocol packet header.

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-2663:
-

Vladimir,

1) In parser we check protocol version because on the parser level we need to 
make sure that we know how to de-serialize messages. However we pass handshake 
message further to the handler even if the version check has failed so we can 
answer to the client. If we'd throw an exception during parsing that would 
result in closing the session without any messages.
2) Good catch. This is actually a bug.

> ODBC: Add protocol version to protocol packet header.
> -
>
> Key: IGNITE-2663
> URL: https://issues.apache.org/jira/browse/IGNITE-2663
> Project: Ignite
>  Issue Type: Sub-task
>  Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.6
>
>
> Currently, there is no way for server to find out that ODBC driver uses 
> incompatible protocol version. Consider adding {{protocolVersion}} field to 
> ODBC protocol message header.



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

[jira] [Commented] (IGNITE-1071) IgniteCache.metrics() method returns local metrics

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-1071:
--

Seems we have to add distributive clear method in case we want to work with 
cluster group metrics. At this moment tests use g.cache(null).mxBean().clear(); 
which clears only local metrics.
I see that metrics sets via Heartbeat message.
Is it suitable case to add some clearMetrics flag to Heartbeat message instead 
of create new clearMetricsMessage?

Also, Val,
could you please specify what MBeans should be refactored?



> IgniteCache.metrics() method returns local metrics
> --
>
> Key: IGNITE-1071
> URL: https://issues.apache.org/jira/browse/IGNITE-1071
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
>Priority: Minor
>  Labels: Usability
> Fix For: 1.6
>
>
> To get metrics for the whole cluster user needs to use 
> {{cache.metrics(ignite.cluster())}}, which is counterintuitive and 
> inconsistent with other APIs. {{IgniteCache.metrics()}} w/o parameters should 
> return metrics for the whole cluster.



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

[jira] [Updated] (IGNITE-1697) IGFS: implement reliable Igfs failover logic

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-1697:

Component/s: IGFS

> IGFS: implement reliable Igfs failover logic 
> -
>
> Key: IGNITE-1697
> URL: https://issues.apache.org/jira/browse/IGNITE-1697
> Project: Ignite
>  Issue Type: Bug
>  Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Ivan Veselovsky
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> Problems to solve:
> 1) currently a write lock for a file may stay taken forever if a node have 
> taken the lock and then crashed.
> 2) Currently the blocks of file content are written not just as 
> dataCache.put() operations , but sent using ad-hoc async messages. This was 
> done earlier to improve performance. But in order to implement reliable 
> failover we need to get rid of that and use simple put() or asyncPut() cache 
> operations.
> Solution plan:
> 1) use async put to write file data blocks.
> 2) do writing using scheme "lock" -> "reserve space" -> "write" -> "commit" 
> -> "release lock".
> 3) The id of the node that locked a file should be readable from the lock id.
> 4) Upon taking a file lock the following procedure should be performed: 
> if file is locked, take the node Id of the node that locked the file. After 
> that ask DiscoveryProcessor if this node is alive. If it is not (node has 
> left topology), perform cleanup procedure: delete all the data blocks of the 
> reserved data range, then delete the lock.



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

[jira] [Assigned] (IGNITE-2832) CacheJdbcPojoStoreFactory.dataSource property should be replaced with Factory

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-2832:


Assignee: Alexey Kuznetsov  (was: Valentin Kulichenko)

> CacheJdbcPojoStoreFactory.dataSource property should be replaced with Factory
> -
>
> Key: IGNITE-2832
> URL: https://issues.apache.org/jira/browse/IGNITE-2832
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
> Fix For: 1.6
>
>
> {{CacheJdbcPojoStoreFactory.dataSource}} property seems to be useless and 
> confusing, because it's transient and therefore data source is lost when 
> configuration is serialized.
> This property should be deprecated and replaced with {{Factory}}.



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

[jira] [Resolved] (IGNITE-2859) IGFS: test org.apache.ignite.internal.processors.igfs.IgfsStartCacheTest#testCacheStart fakily fails

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-2859.
-
Resolution: Duplicate

Already fixed in another ticket.

> IGFS: test 
> org.apache.ignite.internal.processors.igfs.IgfsStartCacheTest#testCacheStart 
> fakily fails
> 
>
> Key: IGNITE-2859
> URL: https://issues.apache.org/jira/browse/IGNITE-2859
> Project: Ignite
>  Issue Type: Bug
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Ivan Veselovsky
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> {code}
> java.io.IOException: File was concurrently deleted: /test/test.file
>   at 
> org.apache.ignite.internal.processors.igfs.IgfsOutputStreamImpl.flush(IgfsOutputStreamImpl.java:278)
>   at 
> org.apache.ignite.internal.processors.igfs.IgfsOutputStreamAdapter.close(IgfsOutputStreamAdapter.java:182)
>   at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:320)
>   at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:149)
>   at java.io.OutputStreamWriter.close(OutputStreamWriter.java:233)
>   at java.io.BufferedWriter.close(BufferedWriter.java:266)
>   at 
> org.apache.ignite.internal.processors.igfs.IgfsStartCacheTest.testCacheStart(IgfsStartCacheTest.java:127)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1758)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1696)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> In method 
> org.apache.ignite.internal.processors.igfs.IgfsOutputStreamImpl#flush() 
> existence of the file being written is checked with id2InfoPrj.get(id) .
> For some reason it appears that sometimes this get returns null, while method 
> org.apache.ignite.internal.processors.igfs.IgfsMetaManager#create guaranteed 
> to return at this point, and the file creation transaction must already be 
> committed.



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

[jira] [Updated] (IGNITE-1778) IGFS: Implement rollback procedure: cleanup the "reserved" data.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-1778:

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

> IGFS: Implement rollback procedure: cleanup the "reserved" data.
> 
>
> Key: IGNITE-1778
> URL: https://issues.apache.org/jira/browse/IGNITE-1778
> Project: Ignite
>  Issue Type: Task
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
> Fix For: 1.7
>
>
> The following procedure is applied if the file is locked:
> 1) take Node id from the lock Id.
> 2) see via discovery service if this node is alive.
> 3) if yes, return (we cannot lock the file).
> 4) if not: do a rollback:
>  -  delete all the blocks in "reserved" range from the data cache.
>  -  set reserved range to zero.
>  -  remove the lock from the FileInfo. 
> The above procedure should be performed upon every attempt to take a lock, 
> and (may be) periodically while traversing the file system.



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

[jira] [Closed] (IGNITE-2848) Ignite OSGI exit code 1 on TC

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov closed IGNITE-2848.


> Ignite OSGI exit code 1 on TC
> -
>
> Key: IGNITE-2848
> URL: https://issues.apache.org/jira/browse/IGNITE-2848
> Project: Ignite
>  Issue Type: Bug
>Reporter: Artem Shutak
>Assignee: Anton Vinogradov
>
> http://204.14.53.153/viewLog.html?buildId=208978=buildResultsDiv=IgniteTests_IgniteOSGi
> {noformat}
> [09:20:59]Step 5/6: Build and run tests OSGi (Maven) (7m:17s)
> [09:28:14][Step 5/6] org.apache.ignite:ignite-weblogic-test
> [09:28:14][org.apache.ignite:ignite-weblogic-test] Failed to execute goal 
> org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-war) on project 
> ignite-weblogic-test: Failed to copy file for artifact 
> [org.apache.ignite:ignite-core:jar:1.6.0-SNAPSHOT:compile]
> [09:28:16][Step 5/6] Step Build and run tests OSGi (Maven) failed
> {noformat}



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

[jira] [Updated] (IGNITE-2837) Docker daemon doesn't start on the AWS instances

[Vasilisa Sidorova (JIRA)]

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

Vasilisa  Sidorova updated IGNITE-2837:
---
Attachment: ignite_aws_docker.png

> Docker daemon doesn't start on the AWS instances
> 
>
> Key: IGNITE-2837
> URL: https://issues.apache.org/jira/browse/IGNITE-2837
> Project: Ignite
>  Issue Type: Bug
>  Components: aws
>Affects Versions: 1.5.0.final
>Reporter: Vasilisa  Sidorova
> Attachments: ignite_aws_docker.png
>
>
> -
> DESCRIPTION
> -
> Deployment docker onto Amazon EC2 by this 
> https://apacheignite.readme.io/docs/docker-deployment instruction is failed
> -
> STEPS FOR REPRODUCE
> -
> Do items 1-7 from "Amazon EC2 Deployement" instruction
> Do item 8
> -
> ACTUAL RESULT
> -
> The list of containers is empty. And command "sudo ./startup.sh" get result:
> {noformat}
> --2016-03-15 16:51:56--  http://169.254.169.254/latest/user-data
> Connecting to 169.254.169.254:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 41 [application/octet-stream]
> Saving to: ‘user-data’
> user-data   
> 100%[===>]
>   41  --.-KB/s   in 0s 
> 2016-03-15 16:51:56 (10,1 MB/s) - ‘user-data’ saved [41/41]
> 1.5.0.final: Pulling from apacheignite/ignite
> 77e39ee82117: Already exists 
> 5eb1402f0414: Already exists 
> 9287fae7a16e: Already exists 
> 0288ae931294: Already exists 
> e5faec61f132: Already exists 
> 9e9bea63cb40: Already exists 
> dcb718404a8b: Already exists 
> a8ce4138c3d9: Already exists 
> 7c01b1c179c8: Already exists 
> a41c2ba526d9: Already exists 
> 5108e60af9fc: Already exists 
> 171a6bf29457: Already exists 
> 1e2a752083e5: Already exists 
> 6dc3a9ded560: Already exists 
> 5d9df50a72b0: Already exists 
> e3dee37923c1: Already exists 
> c7d92bcdbf90: Already exists 
> 8de8b8b056fa: Already exists 
> b298c64b2b41: Already exists 
> 8185ba03f727: Already exists 
> Digest: 
> sha256:8826e49c8ea2c008ad6225df672916eb98979701b91948fb3587432e785cf40a
> Status: Image is up to date for apacheignite/ignite:1.5.0.final
> 84ca163452f47cc0ec3a62861b6ca88ccc242ee80d5cb8594b3e4820606f113c
> {noformat}
> -
> EXPECTED RESULT
> -
> Docker daemon and Ignite nodes should be started on all running amazon 
> instances
> -
> ADDITIONAL INFO
> -
> Reproducible for all Amazon regions (west, east, central)
> For reproducing you can use instances with name ignite-docker-image in any 
> region



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

[jira] [Updated] (IGNITE-2549) ODBC: Implement example that can be used for data visualization.

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-2549:

Attachment: ignite-2549.patch

Added patch as file just in case.

> ODBC: Implement example that can be used for data visualization.
> 
>
> Key: IGNITE-2549
> URL: https://issues.apache.org/jira/browse/IGNITE-2549
> Project: Ignite
>  Issue Type: Sub-task
>  Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.6
>
> Attachments: ignite-2549.patch
>
>
> As the one of the purposes for development of the ODBC driver was to use data 
> visualization tools with Apache Ignite, we need to have example that can be 
> used to test interoperability with such tools. Such example should contain 
> several caches with relational data that can provide meaningful graphs when 
> visualized.



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

[jira] [Created] (IGNITE-2856) Do not generate index fields when them is absent in query fields

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-2856:
-

 Summary: Do not generate index fields when them is absent in query 
fields
 Key: IGNITE-2856
 URL: https://issues.apache.org/jira/browse/IGNITE-2856
 Project: Ignite
  Issue Type: Bug
  Components: UI, wizards
Affects Versions: 1.6
Reporter: Vasiliy Sisko






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

[jira] [Updated] (IGNITE-2837) Docker daemon doesn't start on the AWS instances

[Vasilisa Sidorova (JIRA)]

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

Vasilisa  Sidorova updated IGNITE-2837:
---
Attachment: gcloud_ignitedocker_step6.png

> Docker daemon doesn't start on the AWS instances
> 
>
> Key: IGNITE-2837
> URL: https://issues.apache.org/jira/browse/IGNITE-2837
> Project: Ignite
>  Issue Type: Bug
>  Components: aws
>Affects Versions: 1.5.0.final
>Reporter: Vasilisa  Sidorova
> Attachments: gcloud_ignitedocker_step6.png, ignite_aws_docker.png
>
>
> -
> DESCRIPTION
> -
> Deployment docker onto Amazon EC2 by this 
> https://apacheignite.readme.io/docs/docker-deployment instruction is failed
> -
> STEPS FOR REPRODUCE
> -
> Do items 1-7 from "Amazon EC2 Deployement" instruction
> Do item 8
> -
> ACTUAL RESULT
> -
> The list of containers is empty. And command "sudo ./startup.sh" get result:
> {noformat}
> --2016-03-15 16:51:56--  http://169.254.169.254/latest/user-data
> Connecting to 169.254.169.254:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 41 [application/octet-stream]
> Saving to: ‘user-data’
> user-data   
> 100%[===>]
>   41  --.-KB/s   in 0s 
> 2016-03-15 16:51:56 (10,1 MB/s) - ‘user-data’ saved [41/41]
> 1.5.0.final: Pulling from apacheignite/ignite
> 77e39ee82117: Already exists 
> 5eb1402f0414: Already exists 
> 9287fae7a16e: Already exists 
> 0288ae931294: Already exists 
> e5faec61f132: Already exists 
> 9e9bea63cb40: Already exists 
> dcb718404a8b: Already exists 
> a8ce4138c3d9: Already exists 
> 7c01b1c179c8: Already exists 
> a41c2ba526d9: Already exists 
> 5108e60af9fc: Already exists 
> 171a6bf29457: Already exists 
> 1e2a752083e5: Already exists 
> 6dc3a9ded560: Already exists 
> 5d9df50a72b0: Already exists 
> e3dee37923c1: Already exists 
> c7d92bcdbf90: Already exists 
> 8de8b8b056fa: Already exists 
> b298c64b2b41: Already exists 
> 8185ba03f727: Already exists 
> Digest: 
> sha256:8826e49c8ea2c008ad6225df672916eb98979701b91948fb3587432e785cf40a
> Status: Image is up to date for apacheignite/ignite:1.5.0.final
> 84ca163452f47cc0ec3a62861b6ca88ccc242ee80d5cb8594b3e4820606f113c
> {noformat}
> -
> EXPECTED RESULT
> -
> Docker daemon and Ignite nodes should be started on all running amazon 
> instances
> -
> ADDITIONAL INFO
> -
> Reproducible for all Amazon regions (west, east, central)
> For reproducing you can use instances with name ignite-docker-image in any 
> region



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

[jira] [Comment Edited] (IGNITE-2837) Docker daemon doesn't start on the AWS instances

[Vasilisa Sidorova (JIRA)]

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

Vasilisa  Sidorova edited comment on IGNITE-2837 at 3/16/16 2:07 PM:
-

Please, fix the documentation also: 
1) Update screenshot in the step 4 of the "Amazon EC2 Deployment" instruction 
onto new attached version 
2) Update screenshot in the step 6 of the "Google Compute Deployment" 
instruction onto new attached version 



was (Author: vsidorova):
Please, fix the documentation also: update screenshot in the step 4 of the 
"Amazon EC2 Deployment" instruction onto new attached version 

> Docker daemon doesn't start on the AWS instances
> 
>
> Key: IGNITE-2837
> URL: https://issues.apache.org/jira/browse/IGNITE-2837
> Project: Ignite
>  Issue Type: Bug
>  Components: aws
>Affects Versions: 1.5.0.final
>Reporter: Vasilisa  Sidorova
> Attachments: gcloud_ignitedocker_step6.png, ignite_aws_docker.png
>
>
> -
> DESCRIPTION
> -
> Deployment docker onto Amazon EC2 by this 
> https://apacheignite.readme.io/docs/docker-deployment instruction is failed
> -
> STEPS FOR REPRODUCE
> -
> Do items 1-7 from "Amazon EC2 Deployement" instruction
> Do item 8
> -
> ACTUAL RESULT
> -
> The list of containers is empty. And command "sudo ./startup.sh" get result:
> {noformat}
> --2016-03-15 16:51:56--  http://169.254.169.254/latest/user-data
> Connecting to 169.254.169.254:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 41 [application/octet-stream]
> Saving to: ‘user-data’
> user-data   
> 100%[===>]
>   41  --.-KB/s   in 0s 
> 2016-03-15 16:51:56 (10,1 MB/s) - ‘user-data’ saved [41/41]
> 1.5.0.final: Pulling from apacheignite/ignite
> 77e39ee82117: Already exists 
> 5eb1402f0414: Already exists 
> 9287fae7a16e: Already exists 
> 0288ae931294: Already exists 
> e5faec61f132: Already exists 
> 9e9bea63cb40: Already exists 
> dcb718404a8b: Already exists 
> a8ce4138c3d9: Already exists 
> 7c01b1c179c8: Already exists 
> a41c2ba526d9: Already exists 
> 5108e60af9fc: Already exists 
> 171a6bf29457: Already exists 
> 1e2a752083e5: Already exists 
> 6dc3a9ded560: Already exists 
> 5d9df50a72b0: Already exists 
> e3dee37923c1: Already exists 
> c7d92bcdbf90: Already exists 
> 8de8b8b056fa: Already exists 
> b298c64b2b41: Already exists 
> 8185ba03f727: Already exists 
> Digest: 
> sha256:8826e49c8ea2c008ad6225df672916eb98979701b91948fb3587432e785cf40a
> Status: Image is up to date for apacheignite/ignite:1.5.0.final
> 84ca163452f47cc0ec3a62861b6ca88ccc242ee80d5cb8594b3e4820606f113c
> {noformat}
> -
> EXPECTED RESULT
> -
> Docker daemon and Ignite nodes should be started on all running amazon 
> instances
> -
> ADDITIONAL INFO
> -
> Reproducible for all Amazon regions (west, east, central)
> For reproducing you can use instances with name ignite-docker-image in any 
> region



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

[jira] [Updated] (IGNITE-2856) Do not generate index fields when them is absent in query fields

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko updated IGNITE-2856:
--
Description: 
Schema import utility can generate index fields that is exclude from query 
fields.
Also in index field name should be used java name instead of database name 
which is showed now

  was:Schema import utility can generate index fields that is exclude from 
query fields.


> Do not generate index fields when them is absent in query fields
> 
>
> Key: IGNITE-2856
> URL: https://issues.apache.org/jira/browse/IGNITE-2856
> Project: Ignite
>  Issue Type: Bug
>  Components: UI, wizards
>Affects Versions: 1.6
>Reporter: Vasiliy Sisko
>
> Schema import utility can generate index fields that is exclude from query 
> fields.
> Also in index field name should be used java name instead of database name 
> which is showed now



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

[jira] [Updated] (IGNITE-1778) IGFS: Implement rollback procedure: cleanup the "reserved" data.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-1778:

Summary: IGFS: Implement rollback procedure: cleanup the "reserved" data.  
(was: IGFS: implement rollback procedure: cleanup the "reserved" data.)

> IGFS: Implement rollback procedure: cleanup the "reserved" data.
> 
>
> Key: IGNITE-1778
> URL: https://issues.apache.org/jira/browse/IGNITE-1778
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Ivan Veselovsky
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> The following procedure is applied if the file is locked:
> 1) take Node id from the lock Id.
> 2) see via discovery service if this node is alive.
> 3) if yes, return (we cannot lock the file).
> 4) if not: do a rollback:
>  -  delete all the blocks in "reserved" range from the data cache.
>  -  set reserved range to zero.
>  -  remove the lock from the FileInfo. 
> The above procedure should be performed upon every attempt to take a lock, 
> and (may be) periodically while traversing the file system.



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

[jira] [Updated] (IGNITE-2862) Deployment Ignite in Mesos cluster is failed

[Vasilisa Sidorova (JIRA)]

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

Vasilisa  Sidorova updated IGNITE-2862:
---
Description: 
-
DESCRIPTION
-
Deployment  Ignite in Mesos cluster by this instruction 
https://apacheignite.readme.io/docs/mesos-deployment is failed 

-
STEPS FOR REPRODUCE
-
# Do items 1-5 from "RUN THE FRAMEWORK VIA MARATHON"   paragraph 

-
ACTUAL RESULT
-
# Ignite nodes didn't start. Only ignition task is running. Look at the 
attached picture "mesos_activetasks.png"
# Stderr log for ignition task get follow exception:
{noformat}
I0318 18:42:08.252142 17138 fetcher.cpp:409] Fetcher Info: 
{"cache_directory":"\/tmp\/mesos\/fetch\/slaves\/20160318-180241-16777343-5050-16554-S0\/root","items":[{"action":"BYPASS_CACHE","uri":{"extract":false,"value":"https:\/\/s3.amazonaws.com\/vasilisk\/m\/ignite-mesos-1.5.0.final.jar"}}],"sandbox_directory":"\/tmp\/mesos\/slaves\/20160318-180241-16777343-5050-16554-S0\/frameworks\/20150603-121744-16842879-5050-6241-\/executors\/ignition.f8fa2435-ed1f-11e5-bea1-0242e00dbbdd\/runs\/776db62f-965f-4e9e-950a-4edb67c44667","user":"root"}
I0318 18:42:08.253284 17138 fetcher.cpp:364] Fetching URI 
'https://s3.amazonaws.com/vasilisk/m/ignite-mesos-1.5.0.final.jar'
I0318 18:42:08.253298 17138 fetcher.cpp:238] Fetching directly into the sandbox 
directory
I0318 18:42:08.253312 17138 fetcher.cpp:176] Fetching URI 
'https://s3.amazonaws.com/vasilisk/m/ignite-mesos-1.5.0.final.jar'
I0318 18:42:08.253325 17138 fetcher.cpp:126] Downloading resource from 
'https://s3.amazonaws.com/vasilisk/m/ignite-mesos-1.5.0.final.jar' to 
'/tmp/mesos/slaves/20160318-180241-16777343-5050-16554-S0/frameworks/20150603-121744-16842879-5050-6241-/executors/ignition.f8fa2435-ed1f-11e5-bea1-0242e00dbbdd/runs/776db62f-965f-4e9e-950a-4edb67c44667/ignite-mesos-1.5.0.final.jar'
I0318 18:42:12.091784 17138 fetcher.cpp:441] Fetched 
'https://s3.amazonaws.com/vasilisk/m/ignite-mesos-1.5.0.final.jar' to 
'/tmp/mesos/slaves/20160318-180241-16777343-5050-16554-S0/frameworks/20150603-121744-16842879-5050-6241-/executors/ignition.f8fa2435-ed1f-11e5-bea1-0242e00dbbdd/runs/776db62f-965f-4e9e-950a-4edb67c44667/ignite-mesos-1.5.0.final.jar'
I0318 18:42:12.293658 17142 exec.cpp:132] Version: 0.23.0
I0318 18:42:12.296212 17145 exec.cpp:206] Executor registered on slave 
20160318-180241-16777343-5050-16554-S0
Mar 18, 2016 6:42:12 PM org.apache.ignite.mesos.IgniteFramework main
INFO: Enabling checkpoint for the framework
2016-03-18 18:42:12.495:INFO::main: Logging initialized @151ms
2016-03-18 18:42:22.542:INFO:oejs.Server:main: jetty-9.2.z-SNAPSHOT
2016-03-18 18:42:22.579:INFO:oejs.ServerConnector:main: Started 
ServerConnector@1268c278{HTTP/1.1}{172.17.0.1:48610}
2016-03-18 18:42:22.580:INFO:oejs.Server:main: Started @10235ms
Exception in thread "main" java.lang.RuntimeException: Got unexpected response 
code. Response code: 404
at 
org.apache.ignite.mesos.resource.IgniteProvider.downloadIgnite(IgniteProvider.java:202)
at 
org.apache.ignite.mesos.resource.IgniteProvider.getIgnite(IgniteProvider.java:132)
at 
org.apache.ignite.mesos.resource.ResourceProvider.init(ResourceProvider.java:57)
at org.apache.ignite.mesos.IgniteFramework.main(IgniteFramework.java:77)
{noformat}

-
EXPECTED RESULT
-
Tasks for all 3 nodes are running with ignition task. 
-
ADDITIONAL INFO
-
# File "marathon.json" is attached


  was:
-
DESCRIPTION
-
Deployment  Ignite in Mesos cluster by this instruction 
https://apacheignite.readme.io/docs/mesos-deployment is failed 
-
STEPS FOR REPRODUCE
-
# Do items 1-5 from "RUN THE FRAMEWORK VIA MARATHON"   paragraph 
-
ACTUAL RESULT
-
# Ignite nodes didn't start. Only ignition task is running. Look at the 
attached picture "mesos_activetasks.png"
# Stderr log for ignition task get follow exception:
{noformat}
I0318 18:42:08.252142 17138 fetcher.cpp:409] Fetcher Info: 

[jira] [Comment Edited] (IGNITE-2847) Failed atomic-offheap-invoke-retry load consistency test

[Ilya Suntsov (JIRA)]

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

Ilya Suntsov edited comment on IGNITE-2847 at 3/17/16 10:42 AM:


Today I got the same exceptions during the test with 1 backup.
I attached logs to the ticket - logs_1_backup.zip.


was (Author: ustas):
Today I got the same exceptions during the test with 1 backup.
I attached logs to the ticket.

> Failed atomic-offheap-invoke-retry load consistency test
> 
>
> Key: IGNITE-2847
> URL: https://issues.apache.org/jira/browse/IGNITE-2847
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.6
> Environment: Yardstick driver's host: 
> Ubuntu 14.04.3 LTS
> Yardstick server's hosts: Ubuntu 14.04.3 LTS and CentOS release 6.7 (Final)
>Reporter: Ilya Suntsov
>Assignee: Artem Shutak
>Priority: Critical
> Fix For: 1.6
>
> Attachments: logs_1_backup.zip, logs_configs.zip
>
>
> I ran load test with 2 backups in client mode (1 client, 4 servers) on 3 
> hosts (host1 - client, hosts-2,3 - 2 data nodes on each) and got the 
> following exception after 5h of work of test:
> {noformat}
> <13:49:20> Got 
> exception: 
> org.apache.ignite.yardstick.cache.failover.IgniteConsistencyException: Cache 
> and local map are in inconsistent state [badKeys=[key-62687]]
> org.apache.ignite.yardstick.cache.failover.IgniteConsistencyException: Cache 
> and local map are in inconsistent state 
> [badKeys=[key-62687]]<13:49:20> Full thread 
> dump of the current node below.
> {noformat}
> Logs in attachment.



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

[jira] [Commented] (IGNITE-2851) ODBC: Metadata type retrieval algorithm is wrong.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2851:


GitHub user isapego opened a pull request:

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

IGNITE-2851: Metadata retrieval logic changed.

Merged with IGNITE-2663.

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

$ git pull https://github.com/isapego/ignite ignite-2851

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

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


commit 62ef449794113d3fc7a265b4d18968ccfa854b64
Author: isapego 
Date:   2016-03-09T14:05:52Z

IGNITE-2663: Added Protocol version field to OdbcProcesor.

commit 4e4c4ac03670f77a76224f37a5e905d809e4f4bb
Author: isapego 
Date:   2016-03-09T14:36:01Z

IGNITE-2663: Implemented more robust algorithm for sending and receiving
data.

commit dffb02d7757eac3e3d567bdcb92761acdf09917a
Author: isapego 
Date:   2016-03-09T15:07:06Z

IGNITE-2663: Added version to ODBC driver message header.

commit bcf2fdeef72bbe9bbd8e55c148fa424635d9d673
Author: isapego 
Date:   2016-03-09T15:15:38Z

IGNITE-2663: Error handling refactored.

commit 35b19be39cdd014bd3ee0ff2c682fa5f357718ef
Author: isapego 
Date:   2016-03-09T16:03:07Z

IGNITE-2663: Version reading fixed.

commit bcb62c66e094daec93e44a14678da70bc36b728d
Author: isapego 
Date:   2016-03-10T16:43:36Z

IGNITE-2663: Moved decoding/encoding logic to OdbcMessageParser.

commit 727bac464b9e1c660392ae2d4080285d56ad3a52
Author: isapego 
Date:   2016-03-10T17:42:52Z

IGNITE-2663: Added handshake message and version confirmation logic.

commit 818b1c4f41d2bef9602773c3bca54905a06e6ad8
Author: isapego 
Date:   2016-03-10T18:08:04Z

IGNITE-2663: Added handshake message handling.

commit 1bcf5d2894b9704bfd6491e343a1953c4a41276c
Author: isapego 
Date:   2016-03-10T18:31:13Z

IGNITE-2663: Added handshake request sending.

commit ab19178799d0929bc034b977df9a703afaad34e4
Author: isapego 
Date:   2016-03-14T16:31:55Z

IGNITE-2663: Changed version field type short => long.

commit 6920e6974adfb03438e267c7f13e283595816522
Author: isapego 
Date:   2016-03-14T16:48:35Z

IGNITE-2663: Added ConnectionData class to keep parser and handler using
single connection metadata key.

commit 1923bdcdd6eca4b6d1d5b79d73f28621c6a436dc
Author: isapego 
Date:   2016-03-16T13:19:43Z

IGNITE-2663: Split message parsing and handling error processing.

commit 8a4ebca97e36bbd3259bcb0c7a5b3cc9cd90dbb3
Author: isapego 
Date:   2016-03-16T15:29:04Z

IGNITE-2851: Metadata retrieval logic changed. Removed
ColumnMeta::typeName field.




> ODBC: Metadata type retrieval algorithm is wrong.
> -
>
> Key: IGNITE-2851
> URL: https://issues.apache.org/jira/browse/IGNITE-2851
> Project: Ignite
>  Issue Type: Sub-task
>  Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.6
>
>
> OdbcColumnMeta.writeBinary() method retrieves binary type for the class in a 
> wrong way. Use BinaryUtils.typeByClass() instead of BinaryClassDescriptor.



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

[jira] [Updated] (IGNITE-1777) IGFS: Write files with fail-safe logic: "lock" -> "reserve space" -> "write" -> "size update, unlock"

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-1777:

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

> IGFS: Write files with fail-safe logic: "lock" -> "reserve space" -> "write" 
> -> "size update, unlock"
> -
>
> Key: IGNITE-1777
> URL: https://issues.apache.org/jira/browse/IGNITE-1777
> Project: Ignite
>  Issue Type: Task
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
> Fix For: 1.7
>
>




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

[jira] [Closed] (IGNITE-2853) Job processor should be stopped earlier than service processor

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko closed IGNITE-2853.
---

> Job processor should be stopped earlier than service processor
> --
>
> Key: IGNITE-2853
> URL: https://issues.apache.org/jira/browse/IGNITE-2853
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
> Fix For: 1.6
>
>
> It's a common use case when a compute job accesses service. Currently, if 
> such job is cancelled, it can't do this gracefully, because service is 
> already stopped.



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

[jira] [Closed] (IGNITE-2813) IGFS: Optimize IgfsFileInfo format.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-2813.
---

> IGFS: Optimize IgfsFileInfo format.
> ---
>
> Key: IGNITE-2813
> URL: https://issues.apache.org/jira/browse/IGNITE-2813
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>
> *Problem*
> Currently our metadata appears to be too heavy. 
> Short summary of {{IgfsFIleInfo}}:
> {{id}} - files and dirs 
> {{len}} - only files
> {{blockSize}} - only files
> {{props}} - files and dirs
> {{lockId}} - only files
> {{affKey}} - only files
> {{fileMap}} - only files
> {{accessTime}} - files and dirs
> {{modificationTime}} - files and dirs
> {{listing}} - only dirs
> {{evictExclude}} - only files
> The same applies to {{IgfsListingEntry}}
> *Solution*
> 1) Split files and directories into separate classes. This will improve both 
> performance and maintainability of {{IgfsFileInfo}} class.
> 2) Investigate whether we need {{IgfsListingEntry}} at all. It looks like we 
> only need it for "listPaths" operation. Can we simply replace it with "String 
> -> IgniteUuid" map?



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

[jira] [Commented] (IGNITE-642) Implement IgniteReentrantLock data structure

[Vladisav Jelisavcic (JIRA)]

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

Vladisav Jelisavcic commented on IGNITE-642:


Yakov,

thanks for the review!
Should be fine now, please let me know if I missed something.


> Implement IgniteReentrantLock data structure
> 
>
> Key: IGNITE-642
> URL: https://issues.apache.org/jira/browse/IGNITE-642
> Project: Ignite
>  Issue Type: Sub-task
>  Components: data structures
>Affects Versions: 1.6
>Reporter: Dmitriy Setrakyan
>Assignee: Vladisav Jelisavcic
>  Labels: features
> Fix For: 1.6
>
>
> We need to add {{IgniteReentrantLock}} data structure in addition to other 
> data structures provided by Ignite. {{IgniteReentrantLock}} should have 
> similar API to {{java.util.concurrent.locks.ReentrantLock}} class in JDK.
> As an example, you can see how 
> [IgniteCountDownLatch|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteCountDownLatch.java]
>  is implemented in 
> [GridCacheCountDownLatchImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridCacheCountDownLatchImpl.java]
>  class.
> In general we need to have an entity in ATOMIC cache storing lock-owner 
> identifier together with a queue of waiters.



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

[jira] [Assigned] (IGNITE-1251) Develop a library of distributed data types for ML applications.

[Vladisav Jelisavcic (JIRA)]

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

Vladisav Jelisavcic reassigned IGNITE-1251:
---

Assignee: Vladisav Jelisavcic  (was: Nikita Ivanov)

> Develop a library of distributed data types for ML applications.
> 
>
> Key: IGNITE-1251
> URL: https://issues.apache.org/jira/browse/IGNITE-1251
> Project: Ignite
>  Issue Type: New Feature
>  Components: data structures
>Reporter: Nikita Ivanov
>Assignee: Vladisav Jelisavcic
>
> Essentially, we want to make Ignite as friendly to ML application as 
> possible. The first step here is to develop a set of basic (distributed) data 
> structures that can be used in implementing ML algorithms. 
> We should borrow most of the ideas from the great Apache Spark project: 
> https://spark.apache.org/docs/latest/mllib-data-types.html Our implementation 
> should be based on Ignite data grid / compute grid capabilities (instead of 
> Spark RDD concept).
> Implementation language should be Java (as well as making sure that these 
> Java APIs can be used relatively pain-free from other JVM-based languages 
> such as Scala and Groovy).
> This has also been submitted to: 
> http://eecs.oregonstate.edu/capstone/submission/?page=allproposals



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