[jira] [Commented] (IGNITE-1678) IgniteAtomicSequence: make following reservations in advance

[Dmitriy Govorukhin (JIRA)]

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

Dmitriy Govorukhin commented on IGNITE-1678:


I got the following results, see attach. 

> IgniteAtomicSequence: make following reservations in advance
> 
>
> Key: IGNITE-1678
> URL: https://issues.apache.org/jira/browse/IGNITE-1678
> Project: Ignite
>  Issue Type: Improvement
>  Components: data structures
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Dmitriy Govorukhin
> Fix For: 2.0
>
> Attachments: Screenshot from 2016-12-15 10-50-22.png
>
>
> In current implementation a new reservation is made when the current local 
> sequence boundary is exceeded.
> In cases when there are many nodes that use the same atomic sequence there 
> can be a situation when all the nodes start doing a new reservation at the 
> same time. This can lead to performance drops.
> As a performance optimization it makes sense to start reserving new sequence 
> slot in advance (in background), like when around 80% of current reservation 
> has already been used. Probably we should add a special parameter to 
> {{AtomicConfiguration}} that will manage such behavior.



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

[jira] [Updated] (IGNITE-1678) IgniteAtomicSequence: make following reservations in advance

[Dmitriy Govorukhin (JIRA)]

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

Dmitriy Govorukhin updated IGNITE-1678:
---
Attachment: Screenshot from 2016-12-15 10-50-22.png

Performance between 1678-2 and master.

> IgniteAtomicSequence: make following reservations in advance
> 
>
> Key: IGNITE-1678
> URL: https://issues.apache.org/jira/browse/IGNITE-1678
> Project: Ignite
>  Issue Type: Improvement
>  Components: data structures
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Dmitriy Govorukhin
> Fix For: 2.0
>
> Attachments: Screenshot from 2016-12-15 10-50-22.png
>
>
> In current implementation a new reservation is made when the current local 
> sequence boundary is exceeded.
> In cases when there are many nodes that use the same atomic sequence there 
> can be a situation when all the nodes start doing a new reservation at the 
> same time. This can lead to performance drops.
> As a performance optimization it makes sense to start reserving new sequence 
> slot in advance (in background), like when around 80% of current reservation 
> has already been used. Probably we should add a special parameter to 
> {{AtomicConfiguration}} that will manage such behavior.



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

[jira] [Closed] (IGNITE-4234) .NET: Propagate missing CacheMetrics properties

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova closed IGNITE-4234.
---

> .NET: Propagate missing CacheMetrics properties
> ---
>
> Key: IGNITE-4234
> URL: https://issues.apache.org/jira/browse/IGNITE-4234
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 1.8
>
>
> CacheMetrics in Java has a lot more properties than ICacheMetrics in .NET



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

[jira] [Closed] (IGNITE-4126) .NET: add Swap SPI wrappers and/or default implementations

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova closed IGNITE-4126.
---

> .NET: add Swap SPI wrappers and/or default implementations
> --
>
> Key: IGNITE-4126
> URL: https://issues.apache.org/jira/browse/IGNITE-4126
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Affects Versions: 1.7
>Reporter: Denis Magda
> Fix For: 1.8
>
>
> Presently, if someone decides to use the swapping then it must use Spring XML 
> configuration in order to enable a particular Swap SPI implementation.
> We should add this interface and/or similar default implementations to .NET 
> so that it's possible at least to set the SPI from both App.config and C# 
> configuration.



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

[jira] [Updated] (IGNITE-4432) Web console: incorrect code generation for creating a near cache on client node

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-4432:
-
Fix Version/s: 2.0

> Web console: incorrect code generation for creating a near cache on client 
> node
> ---
>
> Key: IGNITE-4432
> URL: https://issues.apache.org/jira/browse/IGNITE-4432
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
> Fix For: 2.0
>
>
> Current java-code generated as
> {code}
> // Demo of near cache creation on client node.   
> ignite.getOrCreateCache(ClientConfigurationFactory.ComalgorithmCache(), 
> ClientConfigurationFactory.nearConfigurationComalgorithmCache());
> {code}
> but actual method name for cache creation is 'cacheComalgorithmCache()' - 
> starting with 'cache'



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

[jira] [Updated] (IGNITE-4433) Web console: add into CacheConfiguration in Queries section

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-4433:
-
Fix Version/s: 2.0

> Web console: add  into 
> CacheConfiguration in Queries section
> 
>
> Key: IGNITE-4433
> URL: https://issues.apache.org/jira/browse/IGNITE-4433
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
> Fix For: 2.0
>
>
> For now it is absent.



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

[jira] [Resolved] (IGNITE-4432) Web console: incorrect code generation for creating a near cache on client node

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko resolved IGNITE-4432.
---
Resolution: Fixed
  Assignee: Pavel Konstantinov  (was: Vasiliy Sisko)

Fixed cache configuration method name generation.

> Web console: incorrect code generation for creating a near cache on client 
> node
> ---
>
> Key: IGNITE-4432
> URL: https://issues.apache.org/jira/browse/IGNITE-4432
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>
> Current java-code generated as
> {code}
> // Demo of near cache creation on client node.   
> ignite.getOrCreateCache(ClientConfigurationFactory.ComalgorithmCache(), 
> ClientConfigurationFactory.nearConfigurationComalgorithmCache());
> {code}
> but actual method name for cache creation is 'cacheComalgorithmCache()' - 
> starting with 'cache'



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

[jira] [Assigned] (IGNITE-4432) Web console: incorrect code generation for creating a near cache on client node

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-4432:
-

Assignee: Vasiliy Sisko  (was: Andrey Novikov)

> Web console: incorrect code generation for creating a near cache on client 
> node
> ---
>
> Key: IGNITE-4432
> URL: https://issues.apache.org/jira/browse/IGNITE-4432
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Vasiliy Sisko
>
> Current java-code generated as
> {code}
> // Demo of near cache creation on client node.   
> ignite.getOrCreateCache(ClientConfigurationFactory.ComalgorithmCache(), 
> ClientConfigurationFactory.nearConfigurationComalgorithmCache());
> {code}
> but actual method name for cache creation is 'cacheComalgorithmCache()' - 
> starting with 'cache'



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

[jira] [Resolved] (IGNITE-4433) Web console: add into CacheConfiguration in Queries section

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko resolved IGNITE-4433.
---
Resolution: Fixed
  Assignee: Pavel Konstantinov  (was: Vasiliy Sisko)

> Web console: add  into 
> CacheConfiguration in Queries section
> 
>
> Key: IGNITE-4433
> URL: https://issues.apache.org/jira/browse/IGNITE-4433
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>
> For now it is absent.



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

[jira] [Commented] (IGNITE-4433) Web console: add into CacheConfiguration in Queries section

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko commented on IGNITE-4433:
---

Added new configuration field.

> Web console: add  into 
> CacheConfiguration in Queries section
> 
>
> Key: IGNITE-4433
> URL: https://issues.apache.org/jira/browse/IGNITE-4433
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Vasiliy Sisko
>
> For now it is absent.



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

[jira] [Assigned] (IGNITE-4433) Web console: add into CacheConfiguration in Queries section

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-4433:
-

Assignee: Vasiliy Sisko

> Web console: add  into 
> CacheConfiguration in Queries section
> 
>
> Key: IGNITE-4433
> URL: https://issues.apache.org/jira/browse/IGNITE-4433
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Vasiliy Sisko
>
> For now it is absent.



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

[jira] [Created] (IGNITE-4433) Web console: add into CacheConfiguration in Queries section

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-4433:
--

 Summary: Web console: add  into CacheConfiguration in Queries section
 Key: IGNITE-4433
 URL: https://issues.apache.org/jira/browse/IGNITE-4433
 Project: Ignite
  Issue Type: Task
  Components: wizards
Reporter: Pavel Konstantinov


For now it is absent.



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

[jira] [Created] (IGNITE-4432) Web console: incorrect code generation for creating a near cache on client node

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-4432:
--

 Summary: Web console: incorrect code generation for creating a 
near cache on client node
 Key: IGNITE-4432
 URL: https://issues.apache.org/jira/browse/IGNITE-4432
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov
Assignee: Andrey Novikov


Current java-code generated as
{code}
// Demo of near cache creation on client node.   
ignite.getOrCreateCache(ClientConfigurationFactory.ComalgorithmCache(), 
ClientConfigurationFactory.nearConfigurationComalgorithmCache());
{code}

but actual method name for cache creation is 'cacheComalgorithmCache()' - 
starting with 'cache'



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

[jira] [Updated] (IGNITE-4432) Web console: incorrect code generation for creating a near cache on client node

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-4432:
---
Description: 
Current java-code generated as
{code}
// Demo of near cache creation on client node.   
ignite.getOrCreateCache(ClientConfigurationFactory.ComalgorithmCache(), 
ClientConfigurationFactory.nearConfigurationComalgorithmCache());
{code}

but actual method name for cache creation is 'cacheComalgorithmCache()' - 
starting with 'cache'

  was:
Current java-code generated as
{code}
// Demo of near cache creation on client node.   
ignite.getOrCreateCache(ClientConfigurationFactory.ComalgorithmCache(), 
ClientConfigurationFactory.nearConfigurationComalgorithmCache());
{code}

but actual method name for cache creation is 'cacheComalgorithmCache()' - 
starting with 'cache'


> Web console: incorrect code generation for creating a near cache on client 
> node
> ---
>
> Key: IGNITE-4432
> URL: https://issues.apache.org/jira/browse/IGNITE-4432
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Andrey Novikov
>
> Current java-code generated as
> {code}
> // Demo of near cache creation on client node.   
> ignite.getOrCreateCache(ClientConfigurationFactory.ComalgorithmCache(), 
> ClientConfigurationFactory.nearConfigurationComalgorithmCache());
> {code}
> but actual method name for cache creation is 'cacheComalgorithmCache()' - 
> starting with 'cache'



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

[jira] [Commented] (IGNITE-4205) CassandraCacheStore should start IgniteThread threads in loadCache() method

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-4205:
-

[~irudyak], the idea behind this is not to deserialize them on server side. One 
of the main features of binary format is that it allows not to deploy classes 
on server and dynamically change the schema. If you deserialize before calling 
the store, this is not possible. But weird thing is that this is controlled by 
{{cacheStoreFactory}} configuration flag, which it's actually set to true in 
your case, so the {{CacheStore}} implementation should get binary objects. Not 
sure why this doesn't work for you...

> CassandraCacheStore should start IgniteThread threads in loadCache() method
> ---
>
> Key: IGNITE-4205
> URL: https://issues.apache.org/jira/browse/IGNITE-4205
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Igor Rudyak
>
> {{CassandraCacheStore.loadCache()}} method starts a generic thread pool for 
> parallel data load. Threads in this thread pool can't deserialize Ignite 
> internal objects (e.g. {{IgniteKernal}}) which can cause unexpected behavior. 
> Here is one of the scenarios:
> * There is column in Cassandra which stores an object as BLOB using 
> {{JavaSerializer}}.
> * {{CacheConfiguration.storeKeepBinary}} is {{true}}.
> * When an object is saved, it's passed to the store as an instance of 
> {{BinaryObject}} which is converted to a byte array and saved in Cassandra.
> * When the same object is loaded in {{loadCache}}, the store takes the byte 
> array and tries to convert it to {{BinaryObject}}. But it can't because this 
> implies calling {{IgnitionEx.localIgnite()}} from non-Ignite thread.
> To fix this we need to provide a thread factory that will create instances of 
> {{IgniteThread}} and use it in the pool that loads the data.
> Most likely the same issue exists in {{CacheAbstractJdbcStore}}.
> And in general, any threads created by Ignite internals should be 
> {{IgniteThread}}-s. This should be revisited.



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

[jira] [Updated] (IGNITE-3710) Upgrade ignite-spark module to Spark 2.0

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-3710:

Priority: Critical  (was: Major)

> Upgrade ignite-spark module to Spark 2.0
> 
>
> Key: IGNITE-3710
> URL: https://issues.apache.org/jira/browse/IGNITE-3710
> Project: Ignite
>  Issue Type: Improvement
>  Components: Ignite RDD
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
>Priority: Critical
> Attachments: Ignite_Tests_Ignite_RDD_495.log
>
>
> Currently {{ignite-spark}} depends on Spark 1.5.2 and fails with 2.0 with 
> this exception:
> {noformat}
> Exception in thread "main" java.lang.NoClassDefFoundError: 
> org/apache/spark/Logging 
> at java.lang.ClassLoader.defineClass1(Native Method) 
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763) 
> at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) 
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467) 
> at java.net.URLClassLoader.access$100(URLClassLoader.java:73) 
> at java.net.URLClassLoader$1.run(URLClassLoader.java:368) 
> at java.net.URLClassLoader$1.run(URLClassLoader.java:362) 
> at java.security.AccessController.doPrivileged(Native Method) 
> at java.net.URLClassLoader.findClass(URLClassLoader.java:361) 
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424) 
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) 
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) 
> at 
> org.apache.ignite.spark.JavaIgniteContext.(JavaIgniteContext.scala:42) 
> at client.SparkIgniteClient.main(SparkIgniteClient.java:75) 
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
> at java.lang.reflect.Method.invoke(Method.java:498) 
> at 
> com.intellij.rt.execution.application.AppMain.main(AppMain.java:144) 
> Caused by: java.lang.ClassNotFoundException: org.apache.spark.Logging 
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381) 
> {noformat}
> Need to investigate if we can upgrade without breaking compatibility with old 
> versions.



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

[jira] [Commented] (IGNITE-3710) Upgrade ignite-spark module to Spark 2.0

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-3710:
-

Val, thanks for the review.

[~avinogradov], the compilation related issue happens on TC only due to the 
reason explained above. Please assist getting over it. Assigning the ticket on 
you.

> Upgrade ignite-spark module to Spark 2.0
> 
>
> Key: IGNITE-3710
> URL: https://issues.apache.org/jira/browse/IGNITE-3710
> Project: Ignite
>  Issue Type: Improvement
>  Components: Ignite RDD
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Denis Magda
> Attachments: Ignite_Tests_Ignite_RDD_495.log
>
>
> Currently {{ignite-spark}} depends on Spark 1.5.2 and fails with 2.0 with 
> this exception:
> {noformat}
> Exception in thread "main" java.lang.NoClassDefFoundError: 
> org/apache/spark/Logging 
> at java.lang.ClassLoader.defineClass1(Native Method) 
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763) 
> at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) 
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467) 
> at java.net.URLClassLoader.access$100(URLClassLoader.java:73) 
> at java.net.URLClassLoader$1.run(URLClassLoader.java:368) 
> at java.net.URLClassLoader$1.run(URLClassLoader.java:362) 
> at java.security.AccessController.doPrivileged(Native Method) 
> at java.net.URLClassLoader.findClass(URLClassLoader.java:361) 
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424) 
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) 
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) 
> at 
> org.apache.ignite.spark.JavaIgniteContext.(JavaIgniteContext.scala:42) 
> at client.SparkIgniteClient.main(SparkIgniteClient.java:75) 
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
> at java.lang.reflect.Method.invoke(Method.java:498) 
> at 
> com.intellij.rt.execution.application.AppMain.main(AppMain.java:144) 
> Caused by: java.lang.ClassNotFoundException: org.apache.spark.Logging 
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381) 
> {noformat}
> Need to investigate if we can upgrade without breaking compatibility with old 
> versions.



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

[jira] [Commented] (IGNITE-3710) Upgrade ignite-spark module to Spark 2.0

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-3710:
-

Code changes look good to me. The compilation error looks weird, we obviously 
need to get to the bottom before merge.

> Upgrade ignite-spark module to Spark 2.0
> 
>
> Key: IGNITE-3710
> URL: https://issues.apache.org/jira/browse/IGNITE-3710
> Project: Ignite
>  Issue Type: Improvement
>  Components: Ignite RDD
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Denis Magda
> Attachments: Ignite_Tests_Ignite_RDD_495.log
>
>
> Currently {{ignite-spark}} depends on Spark 1.5.2 and fails with 2.0 with 
> this exception:
> {noformat}
> Exception in thread "main" java.lang.NoClassDefFoundError: 
> org/apache/spark/Logging 
> at java.lang.ClassLoader.defineClass1(Native Method) 
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763) 
> at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) 
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467) 
> at java.net.URLClassLoader.access$100(URLClassLoader.java:73) 
> at java.net.URLClassLoader$1.run(URLClassLoader.java:368) 
> at java.net.URLClassLoader$1.run(URLClassLoader.java:362) 
> at java.security.AccessController.doPrivileged(Native Method) 
> at java.net.URLClassLoader.findClass(URLClassLoader.java:361) 
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424) 
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) 
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) 
> at 
> org.apache.ignite.spark.JavaIgniteContext.(JavaIgniteContext.scala:42) 
> at client.SparkIgniteClient.main(SparkIgniteClient.java:75) 
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
> at java.lang.reflect.Method.invoke(Method.java:498) 
> at 
> com.intellij.rt.execution.application.AppMain.main(AppMain.java:144) 
> Caused by: java.lang.ClassNotFoundException: org.apache.spark.Logging 
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381) 
> {noformat}
> Need to investigate if we can upgrade without breaking compatibility with old 
> versions.



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

[jira] [Commented] (IGNITE-4422) Define platform plugin API in Java

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4422:


See branch ignite-2940-1 for previous work on this

> Define platform plugin API in Java
> --
>
> Key: IGNITE-4422
> URL: https://issues.apache.org/jira/browse/IGNITE-4422
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> * Move {{PlatformTarget}} to public package org.apache.ignite.platform
> * Add {{PlatformPluginConfiguration}}, {{PlatformPluginContext}} and 
> {{PlatformPluginPorvider}}, similar to regular plugins and to cache plugins. 
> User should be able to add {{PlatformPluginConfiguration}} to 
> {{PlatformConfiguration}}.



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

[jira] [Assigned] (IGNITE-4408) IndexingSpi support keepBinary options

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov reassigned IGNITE-4408:


Assignee: Andrew Mashenkov

> IndexingSpi support keepBinary options
> --
>
> Key: IGNITE-4408
> URL: https://issues.apache.org/jira/browse/IGNITE-4408
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>  Labels: easyfix, performance
> Fix For: 2.0
>
>
> For now key and values is being deserialized before passing to IndexingSpi. 
> This can cause performance issues in some cases and there is no way to change 
> this behavior.
> It look like we should allow to avoid deserialization and pass BinaryObjects 
> if keepBinary option is true as we do for CacheStore. 



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

[jira] [Commented] (IGNITE-4429) Deadlock in IgniteAtomicSequence when used inside transaction

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov commented on IGNITE-4429:
---

WIth the new separation of system and user transaction the fix as simple as 
removing outTx call.

PR: https://github.com/apache/ignite/pull/1347

Scheduled TC run.

> Deadlock in IgniteAtomicSequence when used inside transaction
> -
>
> Key: IGNITE-4429
> URL: https://issues.apache.org/jira/browse/IGNITE-4429
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, compute, data structures
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
> Fix For: 2.0
>
>
> On certains scenarios involving job runs using compute API, operations with 
> {{IgniteAtomicSequence}} inside user transactions may lead to deadlock caused 
> by public thread pool exhaustion.



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

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

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov commented on IGNITE-4157:
-

Found and fixed issue with validating topology upon executing transaction when 
there are only client nodes in topology. 
*GridCachePartitionedClientOnlyNoPrimaryFullApiSelfTest* and 
*GridCachePartitionedNearOnlyNoPrimaryFullApiSelfTest* tests are fixed.

Fixed some comments on open pull request.

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



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

[jira] [Updated] (IGNITE-4431) Default format of the ignite log doesn't contain a date.

[Taras Ledkov (JIRA)]

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

Taras Ledkov updated IGNITE-4431:
-
Summary: Default format of the ignite log doesn't contain a date.  (was: 
Default forma of the ignite log doesn't contain a date.)

> Default format of the ignite log doesn't contain a date.
> 
>
> Key: IGNITE-4431
> URL: https://issues.apache.org/jira/browse/IGNITE-4431
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.8
>Reporter: Taras Ledkov
> Fix For: 2.0
>
>
> Ignite uses the default pattern layout for the log4j loggers with the 
> {{ABSOLUTE}} date format. 
> May be the {{ISO8601}} for default is more useful because {{ABSOLUTE}} 
> doesn't contain date.



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

[jira] [Updated] (IGNITE-4431) Default forma of the ignite log doesn't contain a date.

[Taras Ledkov (JIRA)]

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

Taras Ledkov updated IGNITE-4431:
-
Summary: Default forma of the ignite log doesn't contain a date.  (was: 
Default forma of the ignite log doesn't contain a data.)

> Default forma of the ignite log doesn't contain a date.
> ---
>
> Key: IGNITE-4431
> URL: https://issues.apache.org/jira/browse/IGNITE-4431
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.8
>Reporter: Taras Ledkov
> Fix For: 2.0
>
>
> Ignite uses the default pattern layout for the log4j loggers with the 
> {{ABSOLUTE}} date format. 
> May be the {{ISO8601}} for default is more useful because {{ABSOLUTE}} 
> doesn't contain date.



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

[jira] [Created] (IGNITE-4431) Default forma of the ignite log doesn't contain a data.

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-4431:


 Summary: Default forma of the ignite log doesn't contain a data.
 Key: IGNITE-4431
 URL: https://issues.apache.org/jira/browse/IGNITE-4431
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.8
Reporter: Taras Ledkov
 Fix For: 2.0


Ignite uses the default pattern layout for the log4j loggers with the 
{{ABSOLUTE}} date format. 

May be the {{ISO8601}} for default is more useful because {{ABSOLUTE}} doesn't 
contain date.



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

[jira] [Commented] (IGNITE-4399) Merge IgfsSecondaryFileSystemV2 and IgfsSecondaryFileSystem

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4399:


GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-4399: remove IgfsSecondaryFileSystemV2, implement setTimes at …

…LocalIgfsSecondaryFileSystem, modify tests

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

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

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

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


commit cfe6a2cb5bba5c01923b52cbc0eee4bd984d3906
Author: tledkov-gridgain 
Date:   2016-12-14T15:20:18Z

IGNITE-4399: remove IgfsSecondaryFileSystemV2, implement setTimes at 
LocalIgfsSecondaryFileSystem, modify tests




> Merge IgfsSecondaryFileSystemV2 and IgfsSecondaryFileSystem
> ---
>
> Key: IGNITE-4399
> URL: https://issues.apache.org/jira/browse/IGNITE-4399
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> Let's move all methods from {{IgfsSecondaryFileSystemV2}} to 
> {{IgfsSecondaryFileSystemV2}} and remove V2 altogether.



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

[jira] [Created] (IGNITE-4430) .NET: Cannot convert the "Name" value of type "System.String" to type "System.Management.Automation.Scr iptBlock"

[Ksenia Rybakova (JIRA)]

Ksenia Rybakova created IGNITE-4430:
---

 Summary: .NET: Cannot convert the "Name" value of type 
"System.String" to type "System.Management.Automation.Scr iptBlock"
 Key: IGNITE-4430
 URL: https://issues.apache.org/jira/browse/IGNITE-4430
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 1.8
Reporter: Ksenia Rybakova
Priority: Minor


Environment:
- Windows7
- VS 2015
- NuGet Package Manager 3.4.4
- Powershell version
{noformat}
PS C:\Users\San> $PSVersionTable.PSVersion
Major  Minor  Build  Revision
-  -  -  
2  0  -1 -1
{noformat}

While installing/uninstalling Apache.Ignite package the following exception 
occurs
{noformat}
PM> Install-Package Apache.Ignite -Source 
https://www.myget.org/F/apache-ignite-staging/api/v2 -Version 1.8.1
Attempting to gather dependency information for package 'Apache.Ignite.1.8.1' 
with respect to project 'WebApplication1', targeting 
'.NETFramework,Version=v4.5.2'
Attempting to resolve dependencies for package 'Apache.Ignite.1.8.1' with 
DependencyBehavior 'Lowest'
Resolving actions to install package 'Apache.Ignite.1.8.1'
Resolved actions to install package 'Apache.Ignite.1.8.1'
Adding package 'Apache.Ignite.1.8.1' to folder 
'D:\Work_Ksu\Platform_tests\WebApplication1\packages'
Added package 'Apache.Ignite.1.8.1' to folder 
'D:\Work_Ksu\Platform_tests\WebApplication1\packages'
Added package 'Apache.Ignite.1.8.1' to 'packages.config'
Executing script file 
'D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Install.ps1'
Updating project properties...
Where-Object : Cannot bind parameter 'FilterScript'. Cannot convert the "Name" 
value of type "System.String" to type "System.Management.Automation.Scr
iptBlock".
At 
D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Install.ps1:33
 char:37
+ $binDir = ($_.Properties | Where   Name -match OutputPath).Value
+ CategoryInfo  : InvalidArgument: (:) [Where-Object], 
ParameterBindingException
+ FullyQualifiedErrorId : 
CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.WhereObjectCommand
 
Where-Object : Cannot bind parameter 'FilterScript'. Cannot convert the "Name" 
value of type "System.String" to type "System.Management.Automation.Scr
iptBlock".
At 
D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Install.ps1:33
 char:37
+ $binDir = ($_.Properties | Where   Name -match OutputPath).Value
+ CategoryInfo  : InvalidArgument: (:) [Where-Object], 
ParameterBindingException
+ FullyQualifiedErrorId : 
CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.WhereObjectCommand
 
Welcome to Apache Ignite.NET!
Successfully installed 'Apache.Ignite 1.8.1' to WebApplication1
PM> 

PM> Uninstall-Package Apache.Ignite
Attempting to gather dependency information for package 'Apache.Ignite.1.8.1' 
with respect to project 'WebApplication1', targeting 
'.NETFramework,Version=v4.5.2'
Resolving actions to uninstall package 'Apache.Ignite.1.8.1'
Resolved actions to uninstall package 'Apache.Ignite.1.8.1'
Executing script file 
'D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Uninstall.ps1'
Where-Object : Cannot bind parameter 'FilterScript'. Cannot convert the "Name" 
value of type "System.String" to type "System.Management.Automation.Scr
iptBlock".
At 
D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Uninstall.ps1:29
 char:37
+ $binDir = ($_.Properties | Where   Name -match OutputPath).Value
+ CategoryInfo  : InvalidArgument: (:) [Where-Object], 
ParameterBindingException
+ FullyQualifiedErrorId : 
CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.WhereObjectCommand
 
Where-Object : Cannot bind parameter 'FilterScript'. Cannot convert the "Name" 
value of type "System.String" to type "System.Management.Automation.Scr
iptBlock".
At 
D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Uninstall.ps1:29
 char:37
+ $binDir = ($_.Properties | Where   Name -match OutputPath).Value
+ CategoryInfo  : InvalidArgument: (:) [Where-Object], 
ParameterBindingException
+ FullyQualifiedErrorId : 
CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.WhereObjectCommand
 
Removed package 'Apache.Ignite.1.8.1' from 'packages.config'
Successfully uninstalled 'Apache.Ignite.1.8.1' from WebApplication1
Removing package 'Apache.Ignite.1.8.1' from folder 
'D:\Work_Ksu\Platform_tests\WebApplication1\packages'
Removed package 'Apache.Ignite.1.8.1' from folder 
'D:\Work_Ksu\Platform_tests\WebApplication1\packages'
PM> 
{noformat}



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

[jira] [Commented] (IGNITE-4399) Merge IgfsSecondaryFileSystemV2 and IgfsSecondaryFileSystem

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-4399:
--

{{setTimes(long lastAccess, long lastModified)}} must be supported by the local 
secondary file system.

> Merge IgfsSecondaryFileSystemV2 and IgfsSecondaryFileSystem
> ---
>
> Key: IGNITE-4399
> URL: https://issues.apache.org/jira/browse/IGNITE-4399
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> Let's move all methods from {{IgfsSecondaryFileSystemV2}} to 
> {{IgfsSecondaryFileSystemV2}} and remove V2 altogether.



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

[jira] [Updated] (IGNITE-4424) REPLICATED cache isn't synced across nodes

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4424:
-
Attachment: (was: ReplicatedCacheRebalanceFails.java)

> REPLICATED cache isn't synced across nodes
> --
>
> Key: IGNITE-4424
> URL: https://issues.apache.org/jira/browse/IGNITE-4424
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Anton Vinogradov
>Priority: Blocker
> Fix For: 2.0
>
> Attachments: ReplicatedCacheRebalanceFails.java, ignite-d8e433e4.log
>
>
> Replicated cache sometimes won't sync across nodes properly.
> PFA a reproducer code.
> All nodes are started at the same time on different machines:
> * Ignition.start() // Blocks until node is up
> * Only one of the nodes performs next: getOrCreateCache() then putAll() 
> * All the other nodes block on this before proceeding. 
> * All of the nodes perform next:
> ** getOrCreateCache() // Again
> ** cache.localSize(CachePeekMode.ALL)
> All nodes should see filled cache, but sometimes some nodes see empty cache. 
> LocalSize call can be replaced by iterating over cache, but result will be 
> same.
> Much more rarely, cluster degradation is possible and one part of cluster see 
> empty cache while another see filled cache. Logs contain no errors at all. It 
> takes about two hours running test in infinite loop to catch this rare error.



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

[jira] [Updated] (IGNITE-4424) REPLICATED cache isn't synced across nodes

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4424:
-
Attachment: ReplicatedCacheRebalanceFails.java

> REPLICATED cache isn't synced across nodes
> --
>
> Key: IGNITE-4424
> URL: https://issues.apache.org/jira/browse/IGNITE-4424
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Anton Vinogradov
>Priority: Blocker
> Fix For: 2.0
>
> Attachments: ReplicatedCacheRebalanceFails.java, ignite-d8e433e4.log
>
>
> Replicated cache sometimes won't sync across nodes properly.
> PFA a reproducer code.
> All nodes are started at the same time on different machines:
> * Ignition.start() // Blocks until node is up
> * Only one of the nodes performs next: getOrCreateCache() then putAll() 
> * All the other nodes block on this before proceeding. 
> * All of the nodes perform next:
> ** getOrCreateCache() // Again
> ** cache.localSize(CachePeekMode.ALL)
> All nodes should see filled cache, but sometimes some nodes see empty cache. 
> LocalSize call can be replaced by iterating over cache, but result will be 
> same.
> Much more rarely, cluster degradation is possible and one part of cluster see 
> empty cache while another see filled cache. Logs contain no errors at all. It 
> takes about two hours running test in infinite loop to catch this rare error.



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

[jira] [Commented] (IGNITE-4277) Hadoop: support raw comparator.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4277:
-

As we work with offheap, we cannot use standard {{RawComparator}} here 
unfortunately. Moreover, the most painful case for us is comparison of 
deserialized key on the one side with offheap memory on the other. 

I created another interface {{PartialRawComparator}} which should take care of 
this situation.

> Hadoop: support raw comparator.
> ---
>
> Key: IGNITE-4277
> URL: https://issues.apache.org/jira/browse/IGNITE-4277
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.0
>
>




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

[jira] [Commented] (IGNITE-4277) Hadoop: support raw comparator.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4277:


GitHub user devozerov opened a pull request:

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

IGNITE-4277



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

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

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

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


commit a800aad27b16a953a6fe5e603b939a5b1d12c810
Author: devozerov 
Date:   2016-12-13T12:26:51Z

Semi-raw comparator works!

commit e5c9459a0b4e531e2538fbacba33098ebc665916
Author: devozerov 
Date:   2016-12-13T12:48:36Z

Correct class placement.

commit 1cfd1a86bfb0b06c3ab74ac76ca8683e295a6a0d
Author: devozerov 
Date:   2016-12-13T13:12:52Z

No value deserialziation.

commit 4d4ddd6f75b6b223857f3062bd7195548ae698e4
Author: devozerov 
Date:   2016-12-13T14:04:03Z

No key deserialization (no, or almost no effect).

commit d88970cdd07f84150467c73a7c287779d399ba46
Author: devozerov 
Date:   2016-12-13T14:04:23Z

Minors (Git bug).

commit 011f3a88e348493b51658463c21ac8629c84472f
Author: devozerov 
Date:   2016-12-13T14:04:32Z

Minors (Git bug).

commit 2359c8da64a99ac23c38e43c8eae995fdae3c241
Author: devozerov 
Date:   2016-12-13T14:20:41Z

Opto: common classloader for all tasks.

commit 945468a95f0c5c7859ea14e2a179d1cabcfd0e02
Author: devozerov 
Date:   2016-12-14T09:02:15Z

Fixed classloader init.

commit 1dd4c34d3c3a3598e81583bd5de7c464aae55732
Author: devozerov 
Date:   2016-12-14T10:54:11Z

Merge branch 'master' into ignite-4277

commit b9673bd53e4f510e3551a73a3456da9cf871a4ac
Author: devozerov 
Date:   2016-12-14T11:02:18Z

Better naming.

commit 90d2433256da965bc21b111fa85c511b473fcf11
Author: devozerov 
Date:   2016-12-14T11:03:49Z

Better defaults.

commit 6708ea92e8439c6403d9ea30265e1a1259f1cffc
Author: devozerov 
Date:   2016-12-14T11:38:09Z

Merge branch 'master' into ignite-4277

# Conflicts:
#   
modules/hadoop/src/main/java/org/apache/ignite/internal/processors/hadoop/impl/v2/HadoopV2Job.java

commit 269d4045d8f1098fc54a5d8b7d1bc2c333b886ba
Author: devozerov 
Date:   2016-12-14T12:58:13Z

Reverted unnecessary "direct" marshalling opto.

commit c56634f933a475959710ee4ae9bdbfd1be8d2a9c
Author: devozerov 
Date:   2016-12-14T13:00:05Z

Reverted unnecessary "direct" marshalling opto (2).

commit 3edfcec6b95cf6ba3cfee245eb1c916e6a890e50
Author: devozerov 
Date:   2016-12-14T13:56:19Z

Added comparators.

commit 4a5033135349baf1d212c2131779ce1da6abbdab
Author: devozerov 
Date:   2016-12-14T13:59:31Z

Adjusted HadoopClassLoader.

commit 9ce0b083faa8baddc08060865e1e8abdc3f07292
Author: devozerov 
Date:   2016-12-14T13:59:39Z

Better classes placement.

commit 1dbd01a73a2ffdd2d3261dd5e6c8bcfcf05d4772
Author: devozerov 
Date:   2016-12-14T14:06:45Z

Proper "memory" classes placement.

commit e3db7e7f872395e58fb8c9435346a6c5a785ad6a
Author: devozerov 
Date:   2016-12-14T14:08:06Z

Updated POM.

commit 7e1a0b463c9b7f5d06264a9be34ee47856b6d05b
Author: devozerov 
Date:   2016-12-14T14:08:33Z

Reverted changes to POM - everything is already there.

commit c2c40e9a0a9c52dafe16ec40b598261ba46ffbd1
Author: devozerov 
Date:   2016-12-14T14:14:50Z

WIP.

commit f1452a7fb7bd0202bd03520c229128d5d759aad8
Author: devozerov 
Date:   2016-12-14T14:18:36Z

Finalizing.

commit 3d4c9f94ea9adc1648159887780776ce57fa6699
Author: devozerov 
Date:   2016-12-14T14:21:05Z

Better property naming.

commit 6e5c9df4013860eebd6830437976944ef77000c2
Author: devozerov 
Date:   2016-12-14T14:41:53Z

Minors.




> Hadoop: support raw comparator.
> ---
>
> Key: IGNITE-4277
> URL: https://issues.apache.org/jira/browse/IGNITE-4277
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.0
>
>

[jira] [Updated] (IGNITE-4424) REPLICATED cache isn't synced across nodes

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4424:
-
Attachment: ignite-d8e433e4.log

> REPLICATED cache isn't synced across nodes
> --
>
> Key: IGNITE-4424
> URL: https://issues.apache.org/jira/browse/IGNITE-4424
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Anton Vinogradov
>Priority: Blocker
> Fix For: 2.0
>
> Attachments: ReplicatedCacheRebalanceFails.java, ignite-d8e433e4.log
>
>
> Replicated cache sometimes won't sync across nodes properly.
> PFA a reproducer code.
> All nodes are started at the same time on different machines:
> * Ignition.start() // Blocks until node is up
> * Only one of the nodes performs next: getOrCreateCache() then putAll() 
> * All the other nodes block on this before proceeding. 
> * All of the nodes perform next:
> ** getOrCreateCache() // Again
> ** cache.localSize(CachePeekMode.ALL)
> All nodes should see filled cache, but sometimes some nodes see empty cache. 
> LocalSize call can be replaced by iterating over cache, but result will be 
> same.
> Much more rarely, cluster degradation is possible and one part of cluster see 
> empty cache while another see filled cache. Logs contain no errors at all. It 
> takes about two hours running test in infinite loop to catch this rare error.



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

[jira] [Updated] (IGNITE-4429) Deadlock in IgniteAtomicSequence when used inside transaction

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov updated IGNITE-4429:
--
Fix Version/s: 2.0

> Deadlock in IgniteAtomicSequence when used inside transaction
> -
>
> Key: IGNITE-4429
> URL: https://issues.apache.org/jira/browse/IGNITE-4429
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, compute, data structures
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
> Fix For: 2.0
>
>
> On certains scenarios involving job runs using compute API, operations with 
> {{IgniteAtomicSequence}} inside user transactions may lead to deadlock caused 
> by public thread pool exhaustion.



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

[jira] [Created] (IGNITE-4429) Deadlock in IgniteAtomicSequence when used inside transaction

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-4429:
-

 Summary: Deadlock in IgniteAtomicSequence when used inside 
transaction
 Key: IGNITE-4429
 URL: https://issues.apache.org/jira/browse/IGNITE-4429
 Project: Ignite
  Issue Type: Bug
  Components: cache, compute, data structures
Reporter: Alexei Scherbakov
Assignee: Alexei Scherbakov


On certains scenarios involving job runs using compute API, operations with 
{{IgniteAtomicSequence}} inside user transactions may lead to deadlock caused 
by public thread pool exhaustion.



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

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

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4428:
---

 Summary: Hadoop: move HadoopMapReducePlanner and dependent classes 
to public space.
 Key: IGNITE-4428
 URL: https://issues.apache.org/jira/browse/IGNITE-4428
 Project: Ignite
  Issue Type: Task
  Components: hadoop
Affects Versions: 1.8
Reporter: Vladimir Ozerov
Assignee: Taras Ledkov
Priority: Critical
 Fix For: 2.0


Currently these classes are located in private package. Need to move the to 
public.



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

[jira] [Updated] (IGNITE-4424) REPLICATED cache isn't synced across nodes

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4424:
-
Attachment: (was: ReplicatedCacheRebalanceFails.java)

> REPLICATED cache isn't synced across nodes
> --
>
> Key: IGNITE-4424
> URL: https://issues.apache.org/jira/browse/IGNITE-4424
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Anton Vinogradov
>Priority: Blocker
> Fix For: 2.0
>
>
> Replicated cache sometimes won't sync across nodes properly.
> PFA a reproducer code.
> All nodes are started at the same time on different machines:
> * Ignition.start() // Blocks until node is up
> * Only one of the nodes performs next: getOrCreateCache() then putAll() 
> * All the other nodes block on this before proceeding. 
> * All of the nodes perform next:
> ** getOrCreateCache() // Again
> ** cache.localSize(CachePeekMode.ALL)
> All nodes should see filled cache, but sometimes some nodes see empty cache. 
> LocalSize call can be replaced by iterating over cache, but result will be 
> same.
> Much more rarely, cluster degradation is possible and one part of cluster see 
> empty cache while another see filled cache. Logs contain no errors at all. It 
> takes about two hours running test in infinite loop to catch this rare error.



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

[jira] [Updated] (IGNITE-4424) REPLICATED cache isn't synced across nodes

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4424:
-
Attachment: ReplicatedCacheRebalanceFails.java

> REPLICATED cache isn't synced across nodes
> --
>
> Key: IGNITE-4424
> URL: https://issues.apache.org/jira/browse/IGNITE-4424
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Anton Vinogradov
>Priority: Blocker
> Fix For: 2.0
>
> Attachments: ReplicatedCacheRebalanceFails.java
>
>
> Replicated cache sometimes won't sync across nodes properly.
> PFA a reproducer code.
> All nodes are started at the same time on different machines:
> * Ignition.start() // Blocks until node is up
> * Only one of the nodes performs next: getOrCreateCache() then putAll() 
> * All the other nodes block on this before proceeding. 
> * All of the nodes perform next:
> ** getOrCreateCache() // Again
> ** cache.localSize(CachePeekMode.ALL)
> All nodes should see filled cache, but sometimes some nodes see empty cache. 
> LocalSize call can be replaced by iterating over cache, but result will be 
> same.
> Much more rarely, cluster degradation is possible and one part of cluster see 
> empty cache while another see filled cache. Logs contain no errors at all. It 
> takes about two hours running test in infinite loop to catch this rare error.



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

[jira] [Updated] (IGNITE-4422) Define platform plugin API in Java

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-4422:
---
Description: 
* Move {{PlatformTarget}} to public package org.apache.ignite.platform

* Add {{PlatformPluginConfiguration}}, {{PlatformPluginContext}} and 
{{PlatformPluginPorvider}}, similar to regular plugins and to cache plugins. 
User should be able to add {{PlatformPluginConfiguration}} to 
{{PlatformConfiguration}}.

  was:
* Move PlatformTarget to public package org.apache.ignite.platform

* Add {{PlatformPluginConfiguration}}, {{PlatformPluginContext}} and 
{{PlatformPluginPorvider}}, similar to regular plugins and to cache plugins. 
User should be able to add {{PlatformPluginConfiguration}} to 
{{PlatformConfiguration}}.


> Define platform plugin API in Java
> --
>
> Key: IGNITE-4422
> URL: https://issues.apache.org/jira/browse/IGNITE-4422
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> * Move {{PlatformTarget}} to public package org.apache.ignite.platform
> * Add {{PlatformPluginConfiguration}}, {{PlatformPluginContext}} and 
> {{PlatformPluginPorvider}}, similar to regular plugins and to cache plugins. 
> User should be able to add {{PlatformPluginConfiguration}} to 
> {{PlatformConfiguration}}.



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

[jira] [Resolved] (IGNITE-3290) Yarstick: log when preloading/warmup started/finished

[Oleg Ostanin (JIRA)]

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

Oleg Ostanin resolved IGNITE-3290.
--
Resolution: Fixed

> Yarstick: log when preloading/warmup started/finished
> -
>
> Key: IGNITE-3290
> URL: https://issues.apache.org/jira/browse/IGNITE-3290
> Project: Ignite
>  Issue Type: Wish
>  Components: yardstick
>Reporter: Ksenia Rybakova
>Assignee: Oleg Ostanin
>
> Please, add messages to log that whould indicate that:
> 1) preloading started
> 2) preloading finished
> 3) warmup started



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

[jira] [Commented] (IGNITE-3290) Yarstick: log when preloading/warmup started/finished

[Oleg Ostanin (JIRA)]

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

Oleg Ostanin commented on IGNITE-3290:
--

Fixed along with IGNITE-3292.

> Yarstick: log when preloading/warmup started/finished
> -
>
> Key: IGNITE-3290
> URL: https://issues.apache.org/jira/browse/IGNITE-3290
> Project: Ignite
>  Issue Type: Wish
>  Components: yardstick
>Reporter: Ksenia Rybakova
>Assignee: Oleg Ostanin
>
> Please, add messages to log that whould indicate that:
> 1) preloading started
> 2) preloading finished
> 3) warmup started



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

[jira] [Updated] (IGNITE-4397) .NET: Support BinaryFieldsIdentityResolver

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-4397:
---
Affects Version/s: (was: 1.9)
   2.1

> .NET: Support BinaryFieldsIdentityResolver
> --
>
> Key: IGNITE-4397
> URL: https://issues.apache.org/jira/browse/IGNITE-4397
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> IGNITE-4045 introduced DML API with Binary resolver as the only option.
> Field resolver is partially implemented and hidden. It requires GetHashCode 
> implementations with Java algorithms for all basic types:
> bool, byte/sbyte, short/ushort, char, int/uint, long/ulong, float, double, 
> string, decimal, Guid, DateTime



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

[jira] [Comment Edited] (IGNITE-4397) .NET: Support BinaryFieldsIdentityResolver

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-4397 at 12/14/16 12:26 PM:
---

decimal turns out to be quite complicated. In Java BigDecimal is BigInteger + 
scale, with special cases for smaller values. We'll need all of this 
reimplemented in .NET.

Let's postpone this to 2.1.


was (Author: ptupitsyn):
decimal turns out to be quite complicated. In Java BigDecimal is BigInteger + 
scale, with special cases for smaller values. We'll need all of this 
reimplemented in .NET.

> .NET: Support BinaryFieldsIdentityResolver
> --
>
> Key: IGNITE-4397
> URL: https://issues.apache.org/jira/browse/IGNITE-4397
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> IGNITE-4045 introduced DML API with Binary resolver as the only option.
> Field resolver is partially implemented and hidden. It requires GetHashCode 
> implementations with Java algorithms for all basic types:
> bool, byte/sbyte, short/ushort, char, int/uint, long/ulong, float, double, 
> string, decimal, Guid, DateTime



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

[jira] [Resolved] (IGNITE-3292) Yardstick: add logging of preloading progress

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov resolved IGNITE-3292.
--
Resolution: Fixed

> Yardstick: add logging of preloading progress
> -
>
> Key: IGNITE-3292
> URL: https://issues.apache.org/jira/browse/IGNITE-3292
> Project: Ignite
>  Issue Type: Wish
>  Components: yardstick
>Reporter: Ksenia Rybakova
>Assignee: Oleg Ostanin
> Fix For: 2.0
>
>
> Please, add logging of preloading progress. This is really useful when we 
> load a lot of entries or they are large. 
> For instance: "Preloading: 200 of 1000 loaded".
> Also adding an option that controls frequency of such output makes sense. For 
> instance, this might be a step (number of entries loaded) - if entries are 
> large, we set small step, if entries are integers,  the step will be large.



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

[jira] [Commented] (IGNITE-3292) Yardstick: add logging of preloading progress

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-3292:
--

Thank you for your contribution!
Looks good for me. Merged to master.

> Yardstick: add logging of preloading progress
> -
>
> Key: IGNITE-3292
> URL: https://issues.apache.org/jira/browse/IGNITE-3292
> Project: Ignite
>  Issue Type: Wish
>  Components: yardstick
>Reporter: Ksenia Rybakova
>Assignee: Oleg Ostanin
> Fix For: 2.0
>
>
> Please, add logging of preloading progress. This is really useful when we 
> load a lot of entries or they are large. 
> For instance: "Preloading: 200 of 1000 loaded".
> Also adding an option that controls frequency of such output makes sense. For 
> instance, this might be a step (number of entries loaded) - if entries are 
> large, we set small step, if entries are integers,  the step will be large.



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

[jira] [Commented] (IGNITE-3292) Yardstick: add logging of preloading progress

[Oleg Ostanin (JIRA)]

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

Oleg Ostanin commented on IGNITE-3292:
--

Fixed Comments. 

[~ntikhonov]
Please look at the new version of code.

> Yardstick: add logging of preloading progress
> -
>
> Key: IGNITE-3292
> URL: https://issues.apache.org/jira/browse/IGNITE-3292
> Project: Ignite
>  Issue Type: Wish
>  Components: yardstick
>Reporter: Ksenia Rybakova
>Assignee: Oleg Ostanin
> Fix For: 2.0
>
>
> Please, add logging of preloading progress. This is really useful when we 
> load a lot of entries or they are large. 
> For instance: "Preloading: 200 of 1000 loaded".
> Also adding an option that controls frequency of such output makes sense. For 
> instance, this might be a step (number of entries loaded) - if entries are 
> large, we set small step, if entries are integers,  the step will be large.



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

[jira] [Created] (IGNITE-4427) .NET: Compute Checkpointing

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4427:
--

 Summary: .NET: Compute Checkpointing
 Key: IGNITE-4427
 URL: https://issues.apache.org/jira/browse/IGNITE-4427
 Project: Ignite
  Issue Type: New Feature
  Components: platforms
Reporter: Pavel Tupitsyn
 Fix For: 2.1


Implement compute checkpointing:
https://apacheignite.readme.io/docs/checkpointing



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

[jira] [Commented] (IGNITE-1443) CPP: Implement cache continuous queries.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-1443:


Please merge with master, there are some conflicts.

Left minor comments in review.

> CPP: Implement cache continuous queries.
> 
>
> Key: IGNITE-1443
> URL: https://issues.apache.org/jira/browse/IGNITE-1443
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>  Labels: cpp, important, roadmap
> Fix For: 2.0
>
>




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

[jira] [Commented] (IGNITE-4426) Hadoop: allow optional classloader reuse between tasks.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4426:


Github user devozerov closed the pull request at:

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


> Hadoop: allow optional classloader reuse between tasks.
> ---
>
> Key: IGNITE-4426
> URL: https://issues.apache.org/jira/browse/IGNITE-4426
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.0
>
>
> *Problem*
> Currently we create separate {{HadoopClassLoader}} for each and every MR 
> task. It has serious performance implications:
> 1) Every task have to reload classes form disk;
> 2) Every task starts from "cold" state with not-compiled classes;
> 3) Very high permgen/metaspace and code cache regions usage.
> We can observe, that every task classloader works with the same JARs. It 
> means that the only case when we really need to isolate tasks through 
> classloaders is when they depend on some static data, which should not be 
> shared.
> *Proposal*
> - Share {{HadoopClassLoader}} between tasks by default;
> - Allow to optionally disable this opto.



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

[jira] [Resolved] (IGNITE-4426) Hadoop: allow optional classloader reuse between tasks.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-4426.
-
Resolution: Fixed

> Hadoop: allow optional classloader reuse between tasks.
> ---
>
> Key: IGNITE-4426
> URL: https://issues.apache.org/jira/browse/IGNITE-4426
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.0
>
>
> *Problem*
> Currently we create separate {{HadoopClassLoader}} for each and every MR 
> task. It has serious performance implications:
> 1) Every task have to reload classes form disk;
> 2) Every task starts from "cold" state with not-compiled classes;
> 3) Very high permgen/metaspace and code cache regions usage.
> We can observe, that every task classloader works with the same JARs. It 
> means that the only case when we really need to isolate tasks through 
> classloaders is when they depend on some static data, which should not be 
> shared.
> *Proposal*
> - Share {{HadoopClassLoader}} between tasks by default;
> - Allow to optionally disable this opto.



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

[jira] [Assigned] (IGNITE-4424) REPLICATED cache isn't synced across nodes

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov reassigned IGNITE-4424:


Assignee: Anton Vinogradov

> REPLICATED cache isn't synced across nodes
> --
>
> Key: IGNITE-4424
> URL: https://issues.apache.org/jira/browse/IGNITE-4424
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Anton Vinogradov
>Priority: Blocker
> Fix For: 2.0
>
> Attachments: ReplicatedCacheFails.java
>
>
> Replicated cache sometimes won't sync across nodes properly.
> PFA a reproducer code.
> All nodes are started at the same time on different machines:
> * Ignition.start() // Blocks until node is up
> * Only one of the nodes performs next: getOrCreateCache() then putAll() 
> * All the other nodes block on this before proceeding. 
> * All of the nodes perform next:
> ** getOrCreateCache() // Again
> ** cache.localSize(CachePeekMode.ALL)
> All nodes should see filled cache, but sometimes some nodes see empty cache. 
> LocalSize call can be replaced by iterating over cache, but result will be 
> same.
> Much more rarely, cluster degradation is possible and one part of cluster see 
> empty cache while another see filled cache. Logs contain no errors at all. It 
> takes about two hours running test in infinite loop to catch this rare error.



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

[jira] [Commented] (IGNITE-4426) Hadoop: allow optional classloader reuse between tasks.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4426:


GitHub user devozerov opened a pull request:

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

IGNITE-4426



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

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

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

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


commit df99bd4bba938862f2a942d1f470dcfbb9090bdd
Author: devozerov 
Date:   2016-12-14T11:13:16Z

Implemented.




> Hadoop: allow optional classloader reuse between tasks.
> ---
>
> Key: IGNITE-4426
> URL: https://issues.apache.org/jira/browse/IGNITE-4426
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.0
>
>
> *Problem*
> Currently we create separate {{HadoopClassLoader}} for each and every MR 
> task. It has serious performance implications:
> 1) Every task have to reload classes form disk;
> 2) Every task starts from "cold" state with not-compiled classes;
> 3) Very high permgen/metaspace and code cache regions usage.
> We can observe, that every task classloader works with the same JARs. It 
> means that the only case when we really need to isolate tasks through 
> classloaders is when they depend on some static data, which should not be 
> shared.
> *Proposal*
> - Share {{HadoopClassLoader}} between tasks by default;
> - Allow to optionally disable this opto.



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

[jira] [Updated] (IGNITE-3428) TcpCommunicationSpi: potential message lost during reconnect

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-3428:
-
Fix Version/s: 1.8

> TcpCommunicationSpi: potential message lost during reconnect
> 
>
> Key: IGNITE-3428
> URL: https://issues.apache.org/jira/browse/IGNITE-3428
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Semen Boikov
>Priority: Critical
> Fix For: 1.8
>
>
> Added test reproducing lost message during reconnect: 
> IgniteCacheMessageRecoveryIdleConnection. 
> It is possible that method 'send' finished, then connection closed, there are 
> unacknowledged messages, but communication does not try to reconnect (if 
> there are no others messages to be sent to this node).
> Looks like there are at least 2 issues:
> - 'onDisconnected' checks result of 'clients.remove(id, rmv)' to trigger 
> reconnect. this is not saf (e.g. client is removed when session is closed on 
> idle timeout)
> - 'onDisconnected' checks that messagesFutures() collection is not empty, but 
> 'onDisconnected' is erroneously called before all futures are polled from 
> closing session (GridNioService.AbstractNioClientWorker.close)



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

[jira] [Commented] (IGNITE-1443) CPP: Implement cache continuous queries.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-1443:


GitHub user isapego opened a pull request:

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

IGNITE-1443: Implemented ContinuousQuery for C++.



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

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

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

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


commit 2ecb8221992d2487509a57493fd40fb9bbd5a5f7
Author: isapego 
Date:   2016-06-08T15:12:29Z

IGNITE-1443: Implemented CacheEntryEventListener and ContinuousQuery.

commit c6bca10cdc0405aae9255d4c8b601d8db3bb51c1
Author: isapego 
Date:   2016-06-08T16:58:29Z

IGNITE-1443: Added ContinuousQueryHandle.

commit 633fa9af4fcde078fd962e464fbf28a4777b1799
Author: isapego 
Date:   2016-06-08T17:10:12Z

IGNITE-1443: Mistake in the comment fixed.

commit 798673bce4201027c514afa6f55cb3dcac46d159
Author: isapego 
Date:   2016-06-09T13:30:25Z

IGNITE-1443: Implemented CacheEntryEvent.

commit cb9f55cfc2c6598f0a88ddae0f9ecacf25f29acd
Author: isapego 
Date:   2016-06-10T12:39:31Z

IGNITE-1443: Added tests.

commit 632b2d654aeb94e43f9c8aa331562e56adf839f2
Author: isapego 
Date:   2016-06-10T15:29:22Z

IGNITE-1443: Test added.

commit 6e31605b4b5e65ad04773cf0717fa5450d0a5b75
Author: isapego 
Date:   2016-06-10T15:30:52Z

Merge branch 'master' into ignite-1443

commit 992331ecdea749884026fecfadceffde56131290
Author: isapego 
Date:   2016-06-10T19:37:59Z

IGNITE-1443: Implemented initial query.

commit 835f65cd1d808f6f0ee7a720537e8cadb0dff0af
Author: isapego 
Date:   2016-06-14T11:41:54Z

IGNITE-1443: Added tests for initial query.

commit 22f526131168a3aafe6e10c2c461192f242a7385
Author: isapego 
Date:   2016-06-14T11:51:34Z

IGNITE-1443: Minor refactoring for tests.

commit 5e3a86e3f10306d969ea958087ec1c2c647c92f8
Author: isapego 
Date:   2016-06-14T12:00:46Z

IGNITE-1443: Configuration simplyfied.

commit 431e08dd9023db1dc39f8e517cb3c8f483fe5230
Author: isapego 
Date:   2016-06-14T12:08:41Z

IGNITE-1443: Added tests for no-except version of functions.

commit 5243a3212ab01c57c8d7e7149fff5938e06ad65b
Author: isapego 
Date:   2016-06-14T12:13:58Z

IGNITE-1443: Boost libraries cleanup.

commit 7bdf0ef1835e5cc6ca6c0c54dbfc7c81742a30fc
Author: isapego 
Date:   2016-06-14T14:25:29Z

IGNITE-1443: Documentation and other minor fixes.

commit 7726047e0e0172b9cd804f70c8eeaf3d124e165e
Author: isapego 
Date:   2016-06-14T14:52:54Z

IGNITE-1443: Fix for cache_impl.

commit fb40cd46897ebc7358ce3a18eeac8d0280b568ad
Author: Igor Sapego 
Date:   2016-06-14T15:14:44Z

IGNITE-1443: Fix for Linux.

commit 759bb4ae8dc435c735292b8fa70920b93c820886
Author: isapego 
Date:   2016-06-14T16:47:15Z

IGNITE-1443: fix for boost libraries versions.

commit 41b67c57962690f09838710b47082cee51add4f7
Author: isapego 
Date:   2016-06-27T12:03:18Z

IGNITE-1443: Comments fixed.

commit e90f23c96021a2ada1da31a005c5ca6fdec6be30
Author: isapego 
Date:   2016-06-27T13:08:47Z

IGNITE-1443: Review fixes.

commit b4e708e0cd741420e3e7fc374ef079fb7072f2a6
Author: isapego 
Date:   2016-06-27T13:15:26Z

Merge remote-tracking branch 'upstream/master' into ignite-1443

commit a4dee21def1ea78d6be7f8399921479ac71c27fa
Author: isapego 
Date:   2016-06-28T12:17:39Z

IGNITE-1443: Moved HasValue() to CacheEntry.

commit ffa5197738541434f8a4df90c089310d77256b47
Author: isapego 
Date:   2016-07-11T18:01:06Z

IGNITE-1443: Fixed ContinuousQuery destruction order.

commit 6823e42cafa32055a0020c3f9fb92d6f4efd319e
Author: isapego 
Date:   2016-07-12T09:52:17Z

IGNITE-1443: Added propperties tests.

commit ce25d0c83855bff03b96ddc7a736b8d7c05e3e88
Author: isapego 
Date:   2016-07-12T10:10:41Z

IGNITE-1443: Minor tweaks for tests.

commit ec5947fea6f39510be45d4c804984ffa8e66b486
Author: isapego 
Date:   2016-07-12T10:38:37Z

IGNITE-1443: Added another test.

commit 1376f68490ef70696d24236d8f55b9b50632
Author: isapego 
Date:   

[jira] [Commented] (IGNITE-1443) CPP: Implement cache continuous queries.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-1443:


Github user isapego closed the pull request at:

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


> CPP: Implement cache continuous queries.
> 
>
> Key: IGNITE-1443
> URL: https://issues.apache.org/jira/browse/IGNITE-1443
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>  Labels: cpp, important, roadmap
> Fix For: 2.0
>
>




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

[jira] [Updated] (IGNITE-3904) Add an option to serialize specific type(s) with OptimizedMarshaller when binary format is used

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov updated IGNITE-3904:
-
Assignee: (was: Nikolay Tikhonov)

> Add an option to serialize specific type(s) with OptimizedMarshaller when 
> binary format is used
> ---
>
> Key: IGNITE-3904
> URL: https://issues.apache.org/jira/browse/IGNITE-3904
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Priority: Critical
> Fix For: 2.0
>
>
> Currently binary marshaller delegates to optimized marshaller for 
> {{Externalizable}} classes and classes that have {{write/readObject}} 
> methods. It can be useful to manually force this behavior for other classes 
> as well.
> We can add {{BinaryTypeConfiguration.useOptimizedMarshaller}} property for 
> this.



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

[jira] [Created] (IGNITE-4426) Hadoop: allow optional classloader reuse between tasks.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4426:
---

 Summary: Hadoop: allow optional classloader reuse between tasks.
 Key: IGNITE-4426
 URL: https://issues.apache.org/jira/browse/IGNITE-4426
 Project: Ignite
  Issue Type: Sub-task
  Components: hadoop
Affects Versions: 1.8
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.0


*Problem*
Currently we create separate {{HadoopClassLoader}} for each and every MR task. 
It has serious performance implications:
1) Every task have to reload classes form disk;
2) Every task starts from "cold" state with not-compiled classes;
3) Very high permgen/metaspace and code cache regions usage.

We can observe, that every task classloader works with the same JARs. It means 
that the only case when we really need to isolate tasks through classloaders is 
when they depend on some static data, which should not be shared.

*Proposal*
- Share {{HadoopClassLoader}} between tasks by default;
- Allow to optionally disable this opto.



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

[jira] [Updated] (IGNITE-4273) Hadoop: implement heap-based data structures.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4273:

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

> Hadoop: implement heap-based data structures.
> -
>
> Key: IGNITE-4273
> URL: https://issues.apache.org/jira/browse/IGNITE-4273
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.0
>
>
> We store output offheap what causes a lot of offheap <-> heap transitions. 
> Also it doesn't allow is to use raw comparator. 
> Let's add new data structures which utilize heap arrays.



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

[jira] [Resolved] (IGNITE-4273) Hadoop: implement heap-based data structures.

[Vladimir Ozerov (JIRA)]

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

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

No need for this at the moment.

> Hadoop: implement heap-based data structures.
> -
>
> Key: IGNITE-4273
> URL: https://issues.apache.org/jira/browse/IGNITE-4273
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.0
>
>
> We store output offheap what causes a lot of offheap <-> heap transitions. 
> Also it doesn't allow is to use raw comparator. 
> Let's add new data structures which utilize heap arrays.



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

[jira] [Resolved] (IGNITE-4263) Hadoop: abstract out offheap/heap memory management.

[Vladimir Ozerov (JIRA)]

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

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

Current heap-based variant shown bad perf due to excessive dereferencing and GC 
problems. is better to keep everything offheap for now. 

As far as IGNITE-4277, I managed to apply a concept similar to 
{{RawComparator}} without resorting to heap-based data structures. Hence, 
closing this ticket.

> Hadoop: abstract out offheap/heap memory management.
> 
>
> Key: IGNITE-4263
> URL: https://issues.apache.org/jira/browse/IGNITE-4263
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>  Labels: performance
> Fix For: 2.0
>
>




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

[jira] [Closed] (IGNITE-4263) Hadoop: abstract out offheap/heap memory management.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-4263.
---

> Hadoop: abstract out offheap/heap memory management.
> 
>
> Key: IGNITE-4263
> URL: https://issues.apache.org/jira/browse/IGNITE-4263
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>  Labels: performance
> Fix For: 2.0
>
>




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

[jira] [Updated] (IGNITE-4263) Hadoop: abstract out offheap/heap memory management.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4263:

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

> Hadoop: abstract out offheap/heap memory management.
> 
>
> Key: IGNITE-4263
> URL: https://issues.apache.org/jira/browse/IGNITE-4263
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>  Labels: performance
> Fix For: 2.0
>
>




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

[jira] [Updated] (IGNITE-4424) REPLICATED cache isn't synced across nodes

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4424:
-
Description: 
Replicated cache sometimes won't sync across nodes properly.
PFA a reproducer code.

All nodes are started at the same time on different machines:
* Ignition.start() // Blocks until node is up
* Only one of the nodes performs next: getOrCreateCache() then putAll() 
* All the other nodes block on this before proceeding. 
* All of the nodes perform next:
** getOrCreateCache() // Again
** cache.localSize(CachePeekMode.ALL)

All nodes should see filled cache, but sometimes some nodes see empty cache. 
LocalSize call can be replaced by iterating over cache, but result will be same.

Much more rarely, cluster degradation is possible and one part of cluster see 
empty cache while another see filled cache. Logs contain no errors at all. It 
takes about two hours running test in infinite loop to catch this rare error.

  was:
Replicated cache sometimes won't sync across nodes properly.
PFA a reproducer code.

All nodes are started at the same time on different machines:
* Ignition.start() // Blocks until node is up
* Only one of the nodes performs next: getOrCreateCache() then putAll() 
* All the other nodes block on this before proceeding. 
* All of the nodes perform next:
** getOrCreateCache() // Again
** cache.localSize(CachePeekMode.ALL)
All nodes should see filled cache, but sometimes some nodes see empty cache. 
LocalSize call can be replaced by iterating over cache, but result will be same.

Much more rarely, cluster degradation is possible and one part of cluster see 
empty cache while another see filled cache. Logs contain no errors at all. It 
takes about two hours running test in infinite loop to catch this rare error.


> REPLICATED cache isn't synced across nodes
> --
>
> Key: IGNITE-4424
> URL: https://issues.apache.org/jira/browse/IGNITE-4424
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Priority: Blocker
> Fix For: 2.0
>
> Attachments: ReplicatedCacheFails.java
>
>
> Replicated cache sometimes won't sync across nodes properly.
> PFA a reproducer code.
> All nodes are started at the same time on different machines:
> * Ignition.start() // Blocks until node is up
> * Only one of the nodes performs next: getOrCreateCache() then putAll() 
> * All the other nodes block on this before proceeding. 
> * All of the nodes perform next:
> ** getOrCreateCache() // Again
> ** cache.localSize(CachePeekMode.ALL)
> All nodes should see filled cache, but sometimes some nodes see empty cache. 
> LocalSize call can be replaced by iterating over cache, but result will be 
> same.
> Much more rarely, cluster degradation is possible and one part of cluster see 
> empty cache while another see filled cache. Logs contain no errors at all. It 
> takes about two hours running test in infinite loop to catch this rare error.



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

[jira] [Updated] (IGNITE-4424) REPLICATED cache isn't synced across nodes

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4424:
-
Attachment: (was: ReplicatedCacheFails.java)

> REPLICATED cache isn't synced across nodes
> --
>
> Key: IGNITE-4424
> URL: https://issues.apache.org/jira/browse/IGNITE-4424
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Priority: Blocker
> Fix For: 2.0
>
> Attachments: ReplicatedCacheFails.java
>
>
> Replicated cache sometimes won't sync across nodes properly.
> PFA a reproducer code.
> All nodes are started at the same time on different machines:
> * Ignition.start() // Blocks until node is up
> * Only one of the nodes performs next: getOrCreateCache() then putAll() 
> * All the other nodes block on this before proceeding. 
> * All of the nodes perform next:
> ** getOrCreateCache() // Again
> ** cache.localSize(CachePeekMode.ALL)
> All nodes should see filled cache, but sometimes some nodes see empty cache. 
> LocalSize call can be replaced by iterating over cache, but result will be 
> same.
> Much more rarely, cluster degradation is possible and one part of cluster see 
> empty cache while another see filled cache. Logs contain no errors at all. It 
> takes about two hours running test in infinite loop to catch this rare error.



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

[jira] [Updated] (IGNITE-4424) REPLICATED cache isn't synced across nodes

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4424:
-
Attachment: ReplicatedCacheFails.java

> REPLICATED cache isn't synced across nodes
> --
>
> Key: IGNITE-4424
> URL: https://issues.apache.org/jira/browse/IGNITE-4424
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Priority: Blocker
> Fix For: 2.0
>
> Attachments: ReplicatedCacheFails.java
>
>
> Replicated cache sometimes won't sync across nodes properly.
> PFA a reproducer code.
> All nodes are started at the same time on different machines:
> * Ignition.start() // Blocks until node is up
> * Only one of the nodes performs next: getOrCreateCache() then putAll() 
> * All the other nodes block on this before proceeding. 
> * All of the nodes perform next:
> ** getOrCreateCache() // Again
> ** cache.localSize(CachePeekMode.ALL)
> All nodes should see filled cache, but sometimes some nodes see empty cache. 
> LocalSize call can be replaced by iterating over cache, but result will be 
> same.
> Much more rarely, cluster degradation is possible and one part of cluster see 
> empty cache while another see filled cache. Logs contain no errors at all. It 
> takes about two hours running test in infinite loop to catch this rare error.



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

[jira] [Updated] (IGNITE-4424) REPLICATED cache isn't synced across nodes

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4424:
-
Description: 
Replicated cache sometimes won't sync across nodes properly.
PFA a reproducer code.

All nodes are started at the same time on different machines:
* Ignition.start() // Blocks until node is up
* Only one of the nodes performs next: getOrCreateCache() then putAll() 
* All the other nodes block on this before proceeding. 
* All of the nodes perform next:
** getOrCreateCache() // Again
** cache.localSize(CachePeekMode.ALL)
All nodes should see filled cache, but sometimes some nodes see empty cache. 
LocalSize call can be replaced by iterating over cache, but result will be same.

Much more rarely, cluster degradation is possible and one part of cluster see 
empty cache while another see filled cache. Logs contain no errors at all. It 
takes about two hours running test in infinite loop to catch this rare error.

  was:
Replicated cache sometimes won't sync across nodes properly.
PFA a reproducer code.

All nodes are started at the same time on different machines:
* Ignition.start() // Blocks until node is up
* Only one of the nodes performs next: getOrCreateCache() then putAll() 
* All the other nodes block on this before proceeding. 
* All of the nodes perform next:
** getOrCreateCache() // Again
** cache.localSize(CachePeekMode.ALL)
All nodes should see filled cache, but sometimes some nodes see empty cache. 
LocalSize call can be replaced by iterating over cache, but result will be same.

Logs says that more than one cluster is started unexpectedly, but there is no 
errors at all.

I'd run test in infinite loop and it failed in two hours. It looks like there 
is a race.  Possibly, it is harder to reproduce on single machine due to small 
latency.


> REPLICATED cache isn't synced across nodes
> --
>
> Key: IGNITE-4424
> URL: https://issues.apache.org/jira/browse/IGNITE-4424
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Priority: Blocker
> Fix For: 2.0
>
> Attachments: ReplicatedCacheFails.java
>
>
> Replicated cache sometimes won't sync across nodes properly.
> PFA a reproducer code.
> All nodes are started at the same time on different machines:
> * Ignition.start() // Blocks until node is up
> * Only one of the nodes performs next: getOrCreateCache() then putAll() 
> * All the other nodes block on this before proceeding. 
> * All of the nodes perform next:
> ** getOrCreateCache() // Again
> ** cache.localSize(CachePeekMode.ALL)
> All nodes should see filled cache, but sometimes some nodes see empty cache. 
> LocalSize call can be replaced by iterating over cache, but result will be 
> same.
> Much more rarely, cluster degradation is possible and one part of cluster see 
> empty cache while another see filled cache. Logs contain no errors at all. It 
> takes about two hours running test in infinite loop to catch this rare error.



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

[jira] [Commented] (IGNITE-4397) .NET: Support BinaryFieldsIdentityResolver

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4397:


decimal turns out to be quite complicated. In Java BigDecimal is BigInteger + 
scale, with special cases for smaller values. We'll need all of this 
reimplemented in .NET.

> .NET: Support BinaryFieldsIdentityResolver
> --
>
> Key: IGNITE-4397
> URL: https://issues.apache.org/jira/browse/IGNITE-4397
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.9
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> IGNITE-4045 introduced DML API with Binary resolver as the only option.
> Field resolver is partially implemented and hidden. It requires GetHashCode 
> implementations with Java algorithms for all basic types:
> bool, byte/sbyte, short/ushort, char, int/uint, long/ulong, float, double, 
> string, decimal, Guid, DateTime



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

[jira] [Commented] (IGNITE-4421) ODBC: SQLFetch fails if result set contains non-primitive column.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4421:


Merged to master

> ODBC: SQLFetch fails if result set contains non-primitive column.
> -
>
> Key: IGNITE-4421
> URL: https://issues.apache.org/jira/browse/IGNITE-4421
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 1.8
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: odbc
> Fix For: 2.0
>
>
> If any column of the result set is complex binary object (non primitive 
> type), then {{SQLFetch}} fails upon call with the following message:
> {noformat}
> Error 01S01: Can not retrieve row column.
> {noformat}



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

[jira] [Commented] (IGNITE-4421) ODBC: SQLFetch fails if result set contains non-primitive column.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4421:


Github user asfgit closed the pull request at:

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


> ODBC: SQLFetch fails if result set contains non-primitive column.
> -
>
> Key: IGNITE-4421
> URL: https://issues.apache.org/jira/browse/IGNITE-4421
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 1.8
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: odbc
> Fix For: 2.0
>
>
> If any column of the result set is complex binary object (non primitive 
> type), then {{SQLFetch}} fails upon call with the following message:
> {noformat}
> Error 01S01: Can not retrieve row column.
> {noformat}



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

[jira] [Updated] (IGNITE-4424) REPLICATED cache isn't synced across nodes

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4424:
-
Attachment: ReplicatedCacheFails.java

> REPLICATED cache isn't synced across nodes
> --
>
> Key: IGNITE-4424
> URL: https://issues.apache.org/jira/browse/IGNITE-4424
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Priority: Blocker
> Fix For: 2.0
>
> Attachments: ReplicatedCacheFails.java
>
>
> Replicated cache sometimes won't sync across nodes properly.
> PFA a reproducer code.
> All nodes are started at the same time on different machines:
> * Ignition.start() // Blocks until node is up
> * Only one of the nodes performs next: getOrCreateCache() then putAll() 
> * All the other nodes block on this before proceeding. 
> * All of the nodes perform next:
> ** getOrCreateCache() // Again
> ** cache.localSize(CachePeekMode.ALL)
> All nodes should see filled cache, but sometimes some nodes see empty cache. 
> LocalSize call can be replaced by iterating over cache, but result will be 
> same.
> Logs says that more than one cluster is started unexpectedly, but there is no 
> errors at all.
> I'd run test in infinite loop and it failed in two hours. It looks like there 
> is a race.  Possibly, it is harder to reproduce on single machine due to 
> small latency.



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

[jira] [Updated] (IGNITE-4424) REPLICATED cache isn't synced across nodes

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4424:
-
Attachment: (was: ReplicatedCacheFails.java)

> REPLICATED cache isn't synced across nodes
> --
>
> Key: IGNITE-4424
> URL: https://issues.apache.org/jira/browse/IGNITE-4424
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Priority: Blocker
> Fix For: 2.0
>
>
> Replicated cache sometimes won't sync across nodes properly.
> PFA a reproducer code.
> All nodes are started at the same time on different machines:
> * Ignition.start() // Blocks until node is up
> * Only one of the nodes performs next: getOrCreateCache() then putAll() 
> * All the other nodes block on this before proceeding. 
> * All of the nodes perform next:
> ** getOrCreateCache() // Again
> ** cache.localSize(CachePeekMode.ALL)
> All nodes should see filled cache, but sometimes some nodes see empty cache. 
> LocalSize call can be replaced by iterating over cache, but result will be 
> same.
> Logs says that more than one cluster is started unexpectedly, but there is no 
> errors at all.
> I'd run test in infinite loop and it failed in two hours. It looks like there 
> is a race.  Possibly, it is harder to reproduce on single machine due to 
> small latency.



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

[jira] [Updated] (IGNITE-4424) REPLICATED cache isn't synced across nodes

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4424:
-
Priority: Blocker  (was: Critical)

> REPLICATED cache isn't synced across nodes
> --
>
> Key: IGNITE-4424
> URL: https://issues.apache.org/jira/browse/IGNITE-4424
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Priority: Blocker
> Fix For: 2.0
>
> Attachments: ReplicatedCacheFails.java
>
>
> Replicated cache sometimes won't sync across nodes properly.
> PFA a reproducer code.
> All nodes are started at the same time on different machines:
> * Ignition.start() // Blocks until node is up
> * Only one of the nodes performs next: getOrCreateCache() then putAll() 
> * All the other nodes block on this before proceeding. 
> * All of the nodes perform next:
> ** getOrCreateCache() // Again
> ** cache.localSize(CachePeekMode.ALL)
> All nodes should see filled cache, but sometimes some nodes see empty cache. 
> LocalSize call can be replaced by iterating over cache, but result will be 
> same.
> Logs says that more than one cluster is started unexpectedly, but there is no 
> errors at all.
> I'd run test in infinite loop and it failed in two hours. It looks like there 
> is a race.  Possibly, it is harder to reproduce on single machine due to 
> small latency.



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

[jira] [Updated] (IGNITE-4424) REPLICATED cache isn't synced across nodes

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4424:
-
Description: 
Replicated cache sometimes won't sync across nodes properly.
PFA a reproducer code.

All nodes are started at the same time on different machines:
* Ignition.start() // Blocks until node is up
* Only one of the nodes performs next: getOrCreateCache() then putAll() 
* All the other nodes block on this before proceeding. 
* All of the nodes perform next:
** getOrCreateCache() // Again
** cache.localSize(CachePeekMode.ALL)
All nodes should see filled cache, but sometimes some nodes see empty cache. 
LocalSize call can be replaced by iterating over cache, but result will be same.

Logs says that more than one cluster is started unexpectedly, but there is no 
errors at all.

I'd run test in infinite loop and it failed in two hours. It looks like there 
is a race.  Possibly, it is harder to reproduce on single machine due to small 
latency.

  was:
Replicated cache sometimes won't sync across nodes properly.
PFA a reproducer code.

All nodes are started at the same time on different machines:
* Ignition.start() // Blocks until node is up
* Only one of the nodes performs next: getOrCreateCache() then putAll() 
* All the other nodes block on this before proceeding. 
* All of the nodes perform next:
** getOrCreateCache() // Again
** cache.localSize(CachePeekMode.ALL)
All nodes should see filled cache, but sometimes some nodes see empty cache. 
LocalSize call can be replaced by iterating over cache, but result will be same.

Logs says that more than one cluster is started unexpectedly, but there is no 
errors at all.


> REPLICATED cache isn't synced across nodes
> --
>
> Key: IGNITE-4424
> URL: https://issues.apache.org/jira/browse/IGNITE-4424
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Priority: Critical
> Fix For: 2.0
>
> Attachments: ReplicatedCacheFails.java
>
>
> Replicated cache sometimes won't sync across nodes properly.
> PFA a reproducer code.
> All nodes are started at the same time on different machines:
> * Ignition.start() // Blocks until node is up
> * Only one of the nodes performs next: getOrCreateCache() then putAll() 
> * All the other nodes block on this before proceeding. 
> * All of the nodes perform next:
> ** getOrCreateCache() // Again
> ** cache.localSize(CachePeekMode.ALL)
> All nodes should see filled cache, but sometimes some nodes see empty cache. 
> LocalSize call can be replaced by iterating over cache, but result will be 
> same.
> Logs says that more than one cluster is started unexpectedly, but there is no 
> errors at all.
> I'd run test in infinite loop and it failed in two hours. It looks like there 
> is a race.  Possibly, it is harder to reproduce on single machine due to 
> small latency.



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

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

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4425:
--

 Summary: .NET: Support "Array.Contains" in LINQ
 Key: IGNITE-4425
 URL: https://issues.apache.org/jira/browse/IGNITE-4425
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
 Fix For: 2.0


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

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

Add support in LINQ like this:

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




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