[jira] [Updated] (IGNITE-2656) Documentation on debugging and fixing the reasons of node disconnection from the cluster

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-2656:

Fix Version/s: (was: 2.0)
   2.1

> Documentation on debugging and fixing the reasons of node disconnection from 
> the cluster
> 
>
> Key: IGNITE-2656
> URL: https://issues.apache.org/jira/browse/IGNITE-2656
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Minor
> Fix For: 2.1
>
>
> Sometimes a node can be abruptly kicked off from the cluster buy some reason.
> The documentation must contain information on how to get to the root of the 
> issue by looking at logs files. Usually the node that was kicked off contains 
> "Local node segmented" message and the node that failed its next neighbor 
> contains a message with more details "Failed to send message to next node".
> Next the article must list possible reasons of the disconnection:
> - long GC pauses. Give recommendations on how to check;
> - high node utilization so that it responds with a delay;
> - low network configuration parameters that are not suited for an environment;
> There should be a section about 
> {{IgniteConfiguration.failureDetectionTimeout}} describing its behavior and 
> showing all its pros and cons.
> The article must say when it makes sense to 'disable' this timeout by 
> switching to explicit configuration of TcpDiscoverySpi.socketTimeout, 
> TcpDiscoverySpi.ackTimeout, TcpDiscoverySpi.maxAckTimeout, 
> TcpDiscoverySpi.reconnectCount. Pros and cons of manual configuration has to 
> be mentioned as well.
>   
> Also I would list the usage of TcpDiscoverySpi.joinTimeout,
> TcpDiscoverySpi.networkTimeout (used on client reconnect, servers waits for 
> join result, node stop, socket reader first message.) there as well.



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

[jira] [Updated] (IGNITE-4718) Add section in documentation on what actions may cause deadlock

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4718:

Fix Version/s: (was: 2.0)
   2.1

> Add section in documentation on what actions may cause deadlock
> ---
>
> Key: IGNITE-4718
> URL: https://issues.apache.org/jira/browse/IGNITE-4718
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 1.8
>Reporter: Dmitry Karachentsev
>Assignee: Denis Magda
> Fix For: 2.1
>
>
> Ignite has number of common cases, where wrong usage of API may lead to 
> deadlocks, starvations, cluster hangs, and they should be properly 
> documented. 
> For example, cache operations is not allowed in CacheEntryProcessor, 
> ContinuousQuery's remote filter, etc. And in some callbacks it's possible to 
> use cache API if they annotated with @IgniteAsyncCallback.



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

[jira] [Updated] (IGNITE-4159) Cloud Native Deployment of Apache Ignite using Kubernetes

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4159:

Fix Version/s: (was: 2.0)
   2.1

> Cloud Native Deployment of Apache Ignite using Kubernetes
> -
>
> Key: IGNITE-4159
> URL: https://issues.apache.org/jira/browse/IGNITE-4159
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 2.1
>
>
> Kubernetes is an open-source system for automating deployment, scaling, and 
> management of containerized applications.
> http://kubernetes.io
> Apache Ignite perfectly fits the concepts implemented in Kubernetes which may 
> greatly simplify and automate the maintenance and scaling of Apache Ignite 
> clusters running under the supervision of Kubernetes.
> Ignite won't be the first distributed storage that supports Kubernetes. There 
> are already a number of existed ones that being used:
> https://github.com/kubernetes/kubernetes/tree/master/examples/storage/cassandra
> https://github.com/pires/hazelcast-kubernetes
> https://www.mongodb.com/blog/post/running-mongodb-as-a-microservice-with-docker-and-kubernetes
> This is an umbrella ticket that incorporates all the works that have to be 
> done before Ignite officially claims that it can be launched under Kubernetes.



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

[jira] [Updated] (IGNITE-4152) Make ignite-shmem lib optional

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4152:

Fix Version/s: (was: 2.0)
   2.1

> Make ignite-shmem lib optional
> --
>
> Key: IGNITE-4152
> URL: https://issues.apache.org/jira/browse/IGNITE-4152
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 2.1
>
>
> Presently, if someone starts up a cluster and has at least two nodes running 
> on a single Unix machine then those nodes will be communicating over the 
> shared memory (shmem) by default.
> This approach sounds absolutely reasonable but the shmem library is not ideal 
> at the moment. There are many situations when a cluster may hang in the 
> production or during long running tests due to some unclear issues in shmem 
> internals. Even from Ignite community side we have the following shmem 
> related issues 
> https://issues.apache.org/jira/browse/IGNITE-1578
> https://issues.apache.org/jira/browse/IGNITE-1294
> Let's make the shmem lib optional by putting it into 
> "{{ignite-release/libs/optional}}" folder and removing any explicit reference 
> we may have in a pom.xml file.
> Refer to this discussion for more details:
> http://apache-ignite-developers.2346864.n4.nabble.com/Making-Ignite-shmem-library-optional-td11874.html



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

[jira] [Created] (IGNITE-4922) JDBC Driver: renew thin client based solution

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4922:
---

 Summary: JDBC Driver: renew thin client based solution
 Key: IGNITE-4922
 URL: https://issues.apache.org/jira/browse/IGNITE-4922
 Project: Ignite
  Issue Type: Task
Reporter: Denis Magda
Priority: Blocker
 Fix For: 2.1


This is a parent ticket for all the activities that are intended to improve the 
thin client based implementation of the JDBC driver making it default one.
 
Refer to the corresponding discussion on the dev list:
http://apache-ignite-developers.2346864.n4.nabble.com/jdbc-vs-jdbc2-packages-td14309.html

In a nutshell, depending on a type of a protocol to be used for the next-gen 
version the options are the following:
- This type of driver might be a default driver for tools and applications that 
don't need transactional support. Existing REST based protocol can be used for 
this scenario.
- If we want to support transactions (which is optional at the beginning) then 
Yakov solution (see discussion) can be applied. However, it makes sense to 
implement it only after MVCC is ready.



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

[jira] [Updated] (IGNITE-2492) .NET: Peer assembly loading

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-2492:

Fix Version/s: (was: 2.0)
   2.1

> .NET: Peer assembly loading
> ---
>
> Key: IGNITE-2492
> URL: https://issues.apache.org/jira/browse/IGNITE-2492
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .net
> Fix For: 2.1
>
>
> Similar to peer class loading in Java, we can provide a possibility to load 
> assemblies on already started nodes, so that a node can execute jobs that are 
> not present on other nodes.
> Considerations:
> * Can we unload assemblies after use to free memory? This requires a separate 
> AppDomain, can we work with that?



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

[jira] [Commented] (IGNITE-4501) Improvement of connection in a cluster of new node

[Yakov Zhdanov (JIRA)]

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

Yakov Zhdanov commented on IGNITE-4501:
---

Alexander, 

I checked out your changes to finalize and commit, but discovered this failure

org.apache.ignite.spi.discovery.tcp.TcpDiscoverySelfTest#testFailedNodes4

{noformat}
[02:41:39,056][ERROR][tcp-disco-msg-worker-#1169%tcp.TcpDiscoverySelfTest2%][TcpDiscoverySelfTest$TestFailedNodesSpi]
 TcpDiscoverSpi's message worker thread failed abnormally. Stopping the node in 
order to prevent cluster wide instability.
java.lang.AssertionError: Duplicate order [this=TcpDiscoveryNode 
[id=4215172c-d71b-4fd1-8baf-73ad9762, addrs=[127.0.0.1], 
sockAddrs=[/127.0.0.1:47502], discPort=47502, order=1, intOrder=1, 
lastExchangeTime=1491432076544, loc=true, ver=2.0.0#19700101-sha1:, 
clusterRegionId=-9223372036854775808, isClient=false], other=TcpDiscoveryNode 
[id=7063b039-493e-4aad-9036-30c96210, addrs=[127.0.0.1], 
sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
lastExchangeTime=1491432076533, loc=false, ver=2.0.0#19700101-sha1:, 
clusterRegionId=-9223372036854775808, isClient=false]]
at 
org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNode.compareTo(TcpDiscoveryNode.java:563)
at 
org.apache.ignite.spi.discovery.tcp.internal.RegionNodeComparator.compare(RegionNodeComparator.java:33)
at 
org.apache.ignite.spi.discovery.tcp.internal.RegionNodeComparator.compare(RegionNodeComparator.java:26)
at java.util.TreeMap.compare(TreeMap.java:1291)
at java.util.TreeMap.getHigherEntry(TreeMap.java:463)
at java.util.TreeMap$NavigableSubMap.absLowest(TreeMap.java:1423)
at 
java.util.TreeMap$NavigableSubMap$EntrySetView.isEmpty(TreeMap.java:1639)
at java.util.TreeMap$NavigableSubMap.isEmpty(TreeMap.java:1498)
at java.util.TreeSet.isEmpty(TreeSet.java:216)
at 
org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing.serverNodes(TcpDiscoveryNodesRing.java:654)
at 
org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing.nextNode(TcpDiscoveryNodesRing.java:512)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.sendMessageAcrossRing(ServerImpl.java:2676)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processHeartbeatMessage(ServerImpl.java:4940)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2547)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2349)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6398)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2435)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
[02:41:39,059][ERROR][tcp-disco-msg-worker-#1169%tcp.TcpDiscoverySelfTest2%][TcpDiscoverySelfTest$TestFailedNodesSpi]
 Runtime error caught during grid runnable execution: IgniteSpiThread 
[name=tcp-disco-msg-worker-#1169%tcp.TcpDiscoverySelfTest2%]
java.lang.AssertionError: Duplicate order [this=TcpDiscoveryNode 
[id=4215172c-d71b-4fd1-8baf-73ad9762, addrs=[127.0.0.1], 
sockAddrs=[/127.0.0.1:47502], discPort=47502, order=1, intOrder=1, 
lastExchangeTime=1491432076544, loc=true, ver=2.0.0#19700101-sha1:, 
clusterRegionId=-9223372036854775808, isClient=false], other=TcpDiscoveryNode 
[id=7063b039-493e-4aad-9036-30c96210, addrs=[127.0.0.1], 
sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
lastExchangeTime=1491432076533, loc=false, ver=2.0.0#19700101-sha1:, 
clusterRegionId=-9223372036854775808, isClient=false]]
at 
org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNode.compareTo(TcpDiscoveryNode.java:563)
at 
org.apache.ignite.spi.discovery.tcp.internal.RegionNodeComparator.compare(RegionNodeComparator.java:33)
at 
org.apache.ignite.spi.discovery.tcp.internal.RegionNodeComparator.compare(RegionNodeComparator.java:26)
at java.util.TreeMap.compare(TreeMap.java:1291)
at java.util.TreeMap.getHigherEntry(TreeMap.java:463)
at java.util.TreeMap$NavigableSubMap.absLowest(TreeMap.java:1423)
at 
java.util.TreeMap$NavigableSubMap$EntrySetView.isEmpty(TreeMap.java:1639)
at java.util.TreeMap$NavigableSubMap.isEmpty(TreeMap.java:1498)
at java.util.TreeSet.isEmpty(TreeSet.java:216)
at 
org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing.serverNodes(TcpDiscoveryNodesRing.java:654)
at 
org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing.nextNode(TcpDiscoveryNodesRing.java:512)
at 

[jira] [Commented] (IGNITE-4817) .NET: Contains fails in LINQ when subquery comes from a variable

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4817:


GitHub user gurustron opened a pull request:

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

IGNITE-4817

QueryParser switched to use CompoundExpressionTreeProcessor.

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

$ git pull https://github.com/gurustron/ignite IGNITE-4817

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

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


commit 488e67e7be7970e1373f3e23f34563e3a8a46bd3
Author: gurustron 
Date:   2017-04-05T20:11:48Z

IGNITE-4817: Query Parser uses CompoundExpressionTreeProcessor, small 
fixes, tests




> .NET: Contains fails in LINQ when subquery comes from a variable
> 
>
> Key: IGNITE-4817
> URL: https://issues.apache.org/jira/browse/IGNITE-4817
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.9
>Reporter: Pavel Tupitsyn
>Assignee: Sergey Stronchinskiy
>Priority: Minor
>  Labels: .NET, LINQ
> Fix For: 2.0
>
>
> Using Contains with subquery works when subquery is inline:
> {code}
> var res = personsQry.Where(x => orgsQry.Where(o => o.Value.Size < 
> 10).Select(o => o.Key).Contains(x.Value.OrgId));
> {code}
> And fails when extracted into a variable:
> {code}
> var orgIds = orgsQry.Where(o => o.Value.Size < 10).Select(o => o.Key);
>   
> var res = personsQry.Where(x => orgIds.Contains(x.Value.OrgId));
> {code}
> Exception:
> {code}
> Failed to parse query: select _T0._key, _T0._val from "persons-linq".Person 
> as _T0 where (_T0.OrgId IN (select _T1._key, _T1._val from 
> "orgs-linq".Organization as _T1 ))
> Caused by: org.h2.jdbc.JdbcSQLException: Subquery is not a single column query
> {code}
> This can be reproduced in {{CacheLinqTest.TestContains}} by extracting a 
> variable:
> {code}
> var foo = orgCache
>   .Where(orgEntry => orgEntry.Value.Name == "Org_1")
>   .Select(orgEntry => orgEntry.Key);
> {code}



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

[jira] [Commented] (IGNITE-4908) Ignite.reentrantLock looks much slower than IgniteCache.lock.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-4908:
--

ReentrantLock is stored as entry one of system cache.
It is possible,  ReentrantLock entry updates on every thread getting the lock. 
If so, we should handle such cases locally in some way when possible.

> Ignite.reentrantLock looks much slower than IgniteCache.lock.
> -
>
> Key: IGNITE-4908
> URL: https://issues.apache.org/jira/browse/IGNITE-4908
> Project: Ignite
>  Issue Type: Improvement
>  Components: data structures
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Alexander Menshikov
> Fix For: 2.1
>
>
> We should make a benchmark and investigate this issue.



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

[jira] [Commented] (IGNITE-4908) Ignite.reentrantLock looks much slower than IgniteCache.lock.

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov commented on IGNITE-4908:
-

May be Later I will look at our lock implementations. Right now I wrote 
benchmark IgniteCache.lock(...) vs Ignite.reentrantLock(...). There are results:

//Ignite.reentrantLock(...)
Benchmark   (create)  (failoverSafe)  (fair)   Mode 
 Cnt Score Error  Units
JmhCacheLocksBenchmark.testIgniteLocks  truetruetrue  thrpt 
  10   873,775 ±  60,388  ops/s
JmhCacheLocksBenchmark.testIgniteLocks  truetrue   false  thrpt 
  10  1177,804 ± 162,082  ops/s
JmhCacheLocksBenchmark.testIgniteLocks  true   falsetrue  thrpt 
  10   915,579 ±  42,631  ops/s
JmhCacheLocksBenchmark.testIgniteLocks  true   false   false  thrpt 
  10  1176,044 ± 108,950  ops/s
JmhCacheLocksBenchmark.testIgniteLocks falsetruetrue  thrpt 
  10   926,890 ±  37,080  ops/s
JmhCacheLocksBenchmark.testIgniteLocks falsetrue   false  thrpt 
  10  1195,663 ±  73,578  ops/s
JmhCacheLocksBenchmark.testIgniteLocks false   falsetrue  thrpt 
  10   903,658 ±  78,483  ops/s
JmhCacheLocksBenchmark.testIgniteLocks false   false   false  thrpt 
  10  1159,586 ±  81,717  ops/s
//IgniteCache.lock(...)
Benchmark   Mode  Cnt Score Error  Units
JmhCacheLocksBenchmark.testCacheLocks  thrpt   10  8076,522 ± 786,153  ops/s

Looks like IgniteCache.lock(...) faster than Ignite.reentrantLock(...) at ~8 
times.
I will investigate the reason.

> Ignite.reentrantLock looks much slower than IgniteCache.lock.
> -
>
> Key: IGNITE-4908
> URL: https://issues.apache.org/jira/browse/IGNITE-4908
> Project: Ignite
>  Issue Type: Improvement
>  Components: data structures
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Alexander Menshikov
> Fix For: 2.1
>
>
> We should make a benchmark and investigate this issue.



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

[jira] [Commented] (IGNITE-4908) Ignite.reentrantLock looks much slower than IgniteCache.lock.

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov commented on IGNITE-4908:
-

May be Later I will look at our lock implementations. Right now I wrote 
benchmark IgniteCache.lock(...) vs Ignite.reentrantLock(...). There are results:

//Ignite.reentrantLock(...)
Benchmark   (create)  (failoverSafe)  (fair)   Mode 
 Cnt Score Error  Units
JmhCacheLocksBenchmark.testIgniteLocks  truetruetrue  thrpt 
  10   873,775 ±  60,388  ops/s
JmhCacheLocksBenchmark.testIgniteLocks  truetrue   false  thrpt 
  10  1177,804 ± 162,082  ops/s
JmhCacheLocksBenchmark.testIgniteLocks  true   falsetrue  thrpt 
  10   915,579 ±  42,631  ops/s
JmhCacheLocksBenchmark.testIgniteLocks  true   false   false  thrpt 
  10  1176,044 ± 108,950  ops/s
JmhCacheLocksBenchmark.testIgniteLocks falsetruetrue  thrpt 
  10   926,890 ±  37,080  ops/s
JmhCacheLocksBenchmark.testIgniteLocks falsetrue   false  thrpt 
  10  1195,663 ±  73,578  ops/s
JmhCacheLocksBenchmark.testIgniteLocks false   falsetrue  thrpt 
  10   903,658 ±  78,483  ops/s
JmhCacheLocksBenchmark.testIgniteLocks false   false   false  thrpt 
  10  1159,586 ±  81,717  ops/s
//IgniteCache.lock(...)
Benchmark   Mode  Cnt Score Error  Units
JmhCacheLocksBenchmark.testCacheLocks  thrpt   10  8076,522 ± 786,153  ops/s

Looks like IgniteCache.lock(...) faster than Ignite.reentrantLock(...) at ~8 
times.
I will investigate the reason.

> Ignite.reentrantLock looks much slower than IgniteCache.lock.
> -
>
> Key: IGNITE-4908
> URL: https://issues.apache.org/jira/browse/IGNITE-4908
> Project: Ignite
>  Issue Type: Improvement
>  Components: data structures
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Alexander Menshikov
> Fix For: 2.1
>
>
> We should make a benchmark and investigate this issue.



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

[jira] [Commented] (IGNITE-4797) Need to expose offheap memory allocated size metric for internal data structures

[Kartik Somani (JIRA)]

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

Kartik Somani commented on IGNITE-4797:
---

I've addressed your comments [~agura], and raised another pull request. Please 
review

> Need to expose offheap memory allocated size metric for internal data 
> structures
> 
>
> Key: IGNITE-4797
> URL: https://issues.apache.org/jira/browse/IGNITE-4797
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Andrey Gura
>Assignee: Kartik Somani
>  Labels: newbie
> Fix For: 2.0
>
>
> Offheap caches expose offheap memory allocated size via 
> {{CacheMetricsMXBean.getOffHeapAllocatedSize()}}. But this metric doesn't 
> take into account offheap memory that allocated for internal data structures 
> (GridUnsafeMap and LRU eviction policy). 
> However Ignite collects this metric (see 
> GridUnsafeMemory.systemAllocatedSize() method).
> Need to expose this metric via {{CacheMetricsMXBean}}.



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

[jira] [Commented] (IGNITE-4797) Need to expose offheap memory allocated size metric for internal data structures

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4797:


GitHub user kartiksomani opened a pull request:

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

ignite-4797: Added API for system allocated size in CacheMetrics

Addressed comments made by Andrey Gura

https://issues.apache.org/jira/browse/IGNITE-4797


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

$ git pull https://github.com/kartiksomani/ignite ignite-4797

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

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


commit 4d02758bedc01ad9da2ada23b1ce3fbc62610f91
Author: Kartik Somani 
Date:   2017-04-05T16:32:40Z

ignite-4797: Added API for system allocated size in CacheMetrics




> Need to expose offheap memory allocated size metric for internal data 
> structures
> 
>
> Key: IGNITE-4797
> URL: https://issues.apache.org/jira/browse/IGNITE-4797
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Andrey Gura
>Assignee: Kartik Somani
>  Labels: newbie
> Fix For: 2.0
>
>
> Offheap caches expose offheap memory allocated size via 
> {{CacheMetricsMXBean.getOffHeapAllocatedSize()}}. But this metric doesn't 
> take into account offheap memory that allocated for internal data structures 
> (GridUnsafeMap and LRU eviction policy). 
> However Ignite collects this metric (see 
> GridUnsafeMemory.systemAllocatedSize() method).
> Need to expose this metric via {{CacheMetricsMXBean}}.



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

[jira] [Comment Edited] (IGNITE-3469) Get rid of deprecated APIs and entities

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-3469 at 4/5/17 3:32 PM:
--

The list of not removed yet:
h3. The list of the deprecated public class / methods / properties:
- The system flags:
-- {{IGNITE_BINARY_SORT_OBJECT_FIELDS}};
-- {{IGNITE_BINARY_DONT_WRAP_TREE_STRUCTURES}};
-- {{IGNITE_MIN_BUFFERED_COMMUNICATION_MSG_CNT}} - not used in the projects now.
- Backup filters for affinity functions;
- {{ContinuousQuery.setRemoteFilter}};
- {{CacheStore.sessionEnd}};
- {{CacheAbstractJdbcStore.translateFields}};
- {{CacheJdbcPojoStoreFactory.setDataSource}};
- {{CacheConfiguration}} properties: {rebalanceThreadPoolSize}};
- {{ConnectorConfiguration.sslContextFactory}} property;
- {{IgniteConfiguration.nodeId}} properties:
- {{StreamTupleExtractor}} class and relations;
- ignite-hadoop: Several constructors of the 
{{IgniteHadoopIgfsSecondaryFileSystem}};
- ignite-yarn: {{ApplicationMaster.getContainers()}}.

h3. The list of the deprecated private class / methods / properties:
- Classes are retated to the {{GridSslContextFactory}};
- {{JdbcConnection}} related classes;
- {{GridCacheUtils.cheatCache}};
- {{GridCacheCommittedTxInfo}};
- {{GridDistributedTxFinishRequest}}: {{syncCommit}}, {{syncRollback}};
- One of the constructors of {{GridLeanSet}};
- Several methods at the {{IgniteUtils}};
- Several methods at the {{GridFunc}};
- {{PlatformDotNetBinaryTypeConfiguration.isKeepDeserialized()}};
- {{ServerImpl.RingMessageWorker.processNodeAddedMessage}};
- {{TcpDiscoverySpi.versionCheckFailed}};




was (Author: tledkov-gridgain):
The list of not removed yet:
h3. The list of the deprecated public class / methods / properties:
- The system flags:
-- {{IGNITE_BINARY_SORT_OBJECT_FIELDS}};
-- {{IGNITE_BINARY_DONT_WRAP_TREE_STRUCTURES}};
-- {{IGNITE_MIN_BUFFERED_COMMUNICATION_MSG_CNT}} - not used in the projects now.
- Backup filters for affinity functions;
- {{ContinuousQuery.setRemoteFilter}};
- {{CacheStore.sessionEnd}};
- {{CacheAbstractJdbcStore.translateFields}};
- {{CacheJdbcPojoStoreFactory.setDataSource}};
- {{CacheConfiguration}} properties: {{transactionManagerLookupClassName}} and 
{rebalanceThreadPoolSize}};
- {{ConnectorConfiguration.sslContextFactory}} property;
- {{IgniteConfiguration.nodeId}} properties:
- {{TransactionConfiguration}} properties: 
-- {{txSerializableEnabled}};
-- {{txManagerLookupClassName}};
- {{StreamTupleExtractor}} class and relations;
- ignite-hadoop: Several constructors of the 
{{IgniteHadoopIgfsSecondaryFileSystem}};
- ignite-yarn: {{ApplicationMaster.getContainers()}}.

h3. The list of the deprecated private class / methods / properties:
- Classes are retated to the {{GridSslContextFactory}};
- {{JdbcConnection}} related classes;
- {{GridCacheUtils.cheatCache}};
- {{GridCacheCommittedTxInfo}};
- {{GridDistributedTxFinishRequest}}: {{syncCommit}}, {{syncRollback}};
- One of the constructors of {{GridLeanSet}};
- Several methods at the {{IgniteUtils}};
- Several methods at the {{GridFunc}};
- {{PlatformDotNetBinaryTypeConfiguration.isKeepDeserialized()}};
- {{ServerImpl.RingMessageWorker.processNodeAddedMessage}};
- {{TcpDiscoverySpi.versionCheckFailed}};



> Get rid of deprecated APIs and entities
> ---
>
> Key: IGNITE-3469
> URL: https://issues.apache.org/jira/browse/IGNITE-3469
> Project: Ignite
>  Issue Type: Task
>Reporter: Alexey Goncharuk
>Assignee: Taras Ledkov
>  Labels: important
> Fix For: 2.0
>
>
> There are more than 220 deprecated elements in Ignite code kept for the sake 
> of backward compatibility. We need to cleanup the code for Ignite 2.0 release.
> 2.0 migration guide has to be updated if needed: 
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide



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

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

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov reassigned IGNITE-4644:


Assignee: Anton Vinogradov

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



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

[jira] [Commented] (IGNITE-3592) Provide some kind of pluggable compression SPI support

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur commented on IGNITE-3592:


[~vozerov]
I've prepared the raw evaluation (marshaller layer) of compression.
[Results may be 
useful.|https://github.com/daradurvs/ignite-compression/tree/master/src/main/resources/result]
 (full evaluation is in developing)

> Provide some kind of pluggable compression SPI support
> --
>
> Key: IGNITE-3592
> URL: https://issues.apache.org/jira/browse/IGNITE-3592
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Alexey Kuznetsov
>Assignee: Vyacheslav Daradur
> Fix For: 2.0
>
>
> It may be useful in some cases to compress data stored in cache.
> And in order to give access to compressed data from SQL engine this support 
> should be implemented in ignite-core level.
> See discussion on dev-list: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Data-compression-in-Ignite-2-0-td10099.html



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

[jira] [Updated] (IGNITE-4921) Refactor segments array in PageMemoryNoStoreImpl

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-4921:
---
Remaining Estimate: 48h  (was: 168h)
 Original Estimate: 48h  (was: 168h)

> Refactor segments array in PageMemoryNoStoreImpl
> 
>
> Key: IGNITE-4921
> URL: https://issues.apache.org/jira/browse/IGNITE-4921
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Ivan Rakov
>Assignee: Alexey Goncharuk
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> In current version of PageMemoryNoStoreImpl, offheap memory is split into 
> equal segments. Quantity of segments is based on 
> MemoryConfiguration#getConcurrencyLevel (or Runtime#availableProcessors, if 
> previous is not set).
> This approach is obsolete. In order to reduce code complexity, segments 
> should be refactored into one memory region.



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

[jira] [Commented] (IGNITE-3592) Provide some kind of pluggable compression SPI support

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-3592:
-

[~daradurvs], I'll take a look shortly.

> Provide some kind of pluggable compression SPI support
> --
>
> Key: IGNITE-3592
> URL: https://issues.apache.org/jira/browse/IGNITE-3592
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Alexey Kuznetsov
>Assignee: Vyacheslav Daradur
> Fix For: 2.0
>
>
> It may be useful in some cases to compress data stored in cache.
> And in order to give access to compressed data from SQL engine this support 
> should be implemented in ignite-core level.
> See discussion on dev-list: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Data-compression-in-Ignite-2-0-td10099.html



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

[jira] [Created] (IGNITE-4921) Refactor segments array in PageMemoryNoStoreImpl

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-4921:
--

 Summary: Refactor segments array in PageMemoryNoStoreImpl
 Key: IGNITE-4921
 URL: https://issues.apache.org/jira/browse/IGNITE-4921
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.0
Reporter: Ivan Rakov
Assignee: Alexey Goncharuk


In current version of PageMemoryNoStoreImpl, offheap memory is split into equal 
segments. Quantity of segments is based on 
MemoryConfiguration#getConcurrencyLevel (or Runtime#availableProcessors, if 
previous is not set).
This approach is obsolete. In order to reduce code complexity, segments should 
be refactored into one memory region.



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

[jira] [Created] (IGNITE-4920) LocalDeploymentSpi resources cleanup on spi.register() might clean resources from other tasks using delegating classloader.

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-4920:
-

 Summary: LocalDeploymentSpi resources cleanup on spi.register() 
might clean resources from other tasks using delegating classloader.
 Key: IGNITE-4920
 URL: https://issues.apache.org/jira/browse/IGNITE-4920
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.6
Reporter: Alexei Scherbakov
Assignee: Alexei Scherbakov
 Fix For: 2.1


Culrpit is "if" condition in LocalDelpoymentSpi:

{noformat}
if (entry.getKey().equals(entry.getValue()) && isResourceExist(ldr, 
entry.getKey()) &&
!U.hasParent(clsLdrToIgnore, ldr) && 
ldrRsrcs.remove(ldr, clsLdrRsrcs)) {
...
}
{noformat}

and can be fixed by adding clsLdrRsrcs.containsKey(entry.getKey()):

{noformat}
if (entry.getKey().equals(entry.getValue()) && isResourceExist(ldr, 
entry.getKey()) &&
!U.hasParent(clsLdrToIgnore, ldr) && 
clsLdrRsrcs.containsKey(entry.getKey()) && ldrRsrcs.remove(ldr, clsLdrRsrcs)) {
...
}
{noformat}

Reproducer (might require multiple runs)

{noformat}
/** */
public class Main {
public static void main(String args[]) throws MalformedURLException, 
ClassNotFoundException {
System.setProperty("IGNITE_CACHE_REMOVED_ENTRIES_TTL", "1");

IgniteConfiguration cfg = new IgniteConfiguration();
cfg.setPeerClassLoadingEnabled(true);

TcpDiscoverySpi spi = new TcpDiscoverySpi();
spi.setIpFinder(new TcpDiscoveryVmIpFinder(true));

cfg.setDiscoverySpi(spi);

final Ignite ignite = Ignition.start(cfg);

final ClassLoader moduleClsLdr = Main.class.getClassLoader();

final ClassLoader moduleCLImpl = new DelegateClassLoader(null, 
moduleClsLdr);

for (int i = 0; i < 100; i++)
try {
Class clazz = moduleCLImpl.loadClass("Main$CallFunction");

ignite.compute().call(

(IgniteCallable)clazz.getDeclaredConstructor(ClassLoader.class).newInstance(moduleCLImpl)
);
}
catch (Exception e) {
e.printStackTrace();
}

System.out.println("Done");
}

public static class CallFunction implements IgniteCallable, 
GridPeerDeployAware {
transient ClassLoader classLoader;

public CallFunction(ClassLoader cls) {
this.classLoader = cls;
}

public Object call() throws Exception {
return null;
}

public Class deployClass() {
return this.getClass();
}

public ClassLoader classLoader() {
return classLoader;
}
}

public static class DelegateClassLoader extends ClassLoader {
private ClassLoader delegateCL;

public DelegateClassLoader(ClassLoader parent, ClassLoader delegateCL) {
super(parent); // Parent doesn't matter.
this.delegateCL = delegateCL;
}

@Override
public URL getResource(String name) {
return delegateCL.getResource(name);
}

@Override
public Class loadClass(String name) throws ClassNotFoundException {
return delegateCL.loadClass(name);
}
}
}
{noformat}



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4511:


Github user AMashenkov closed the pull request at:

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


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



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

[jira] [Commented] (IGNITE-4259) Geospatial functionality is broken in master

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4259:


Github user AMashenkov closed the pull request at:

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


> Geospatial functionality is broken in master
> 
>
> Key: IGNITE-4259
> URL: https://issues.apache.org/jira/browse/IGNITE-4259
> Project: Ignite
>  Issue Type: Bug
>  Components: binary, SQL
>Reporter: Andrew Mashenkov
>Assignee: Vladimir Ozerov
>Priority: Blocker
> Fix For: 1.8
>
>
> GridH2IndexingGeoSelfTest fails with binary marshaller configured. 
> Query parameters are converted to binary since commit "ae77653" as a result 
> of  [https://issues.apache.org/jira/browse/IGNITE-2208]
> Also see [https://issues.apache.org/jira/browse/IGNITE-4238].



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

[jira] [Commented] (IGNITE-3925) Output process ID to the log during node start.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3925:


Github user AMashenkov closed the pull request at:

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


> Output process ID to the log during node start.
> ---
>
> Key: IGNITE-3925
> URL: https://issues.apache.org/jira/browse/IGNITE-3925
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Andrew Mashenkov
>Priority: Minor
> Fix For: 1.8
>
>
> It might be very useful to know process ID of Ignite node. However, we do not 
> output this info to the log. Let's add it.
> I would output it after {{VM total memory}} message.
> Since there is no reliable way to get PID in Java, we do our best to get it, 
> but never throw and error if it is impossible for some reason.
> Start point: {{IgniteKernal.start}} and various {{IgniteKernal.ack*}} 
> methods. 



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

[jira] [Commented] (IGNITE-4919) Remove support BinaryIdentityResolver

[Dmitriy Govorukhin (JIRA)]

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

Dmitriy Govorukhin commented on IGNITE-4919:


[~ptupitsyn] Can you support this task from .NET side?

> Remove support BinaryIdentityResolver
> -
>
> Key: IGNITE-4919
> URL: https://issues.apache.org/jira/browse/IGNITE-4919
> Project: Ignite
>  Issue Type: Task
>  Components: binary
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
> Fix For: 2.0
>
>
> We must get rid of BinaryIdentityResolver, because in new memory model, we 
> must provide stable binary key representation. 
> [discussion|http://apache-ignite-developers.2346864.n4.nabble.com/Stable-binary-key-representation-td15904.html]



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

[jira] [Updated] (IGNITE-4919) Remove support BinaryIdentityResolver

[Dmitriy Govorukhin (JIRA)]

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

Dmitriy Govorukhin updated IGNITE-4919:
---
Description: We must get rid of BinaryIdentityResolver, because in new 
memory model, we must provide stable binary key representation. 
[discussion|http://apache-ignite-developers.2346864.n4.nabble.com/Stable-binary-key-representation-td15904.html]
  (was: We must get rid of BinaryIdentityResolver, because in new memory mode 
we must provide stable binary key representation. 
[discussion|http://apache-ignite-developers.2346864.n4.nabble.com/Stable-binary-key-representation-td15904.html])

> Remove support BinaryIdentityResolver
> -
>
> Key: IGNITE-4919
> URL: https://issues.apache.org/jira/browse/IGNITE-4919
> Project: Ignite
>  Issue Type: Task
>  Components: binary
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
> Fix For: 2.0
>
>
> We must get rid of BinaryIdentityResolver, because in new memory model, we 
> must provide stable binary key representation. 
> [discussion|http://apache-ignite-developers.2346864.n4.nabble.com/Stable-binary-key-representation-td15904.html]



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

[jira] [Updated] (IGNITE-4918) ScanQuery filter class code is not updated on server once it has been changed on client.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4918:
-
Description: 
PFA reproducer attached. Peer class loading should be enabled on both, server 
and client.
Server should NOT has scan query filter class in its classpath.

Steps to reproduce:
- start standalone server
- run repro, it should work fine.
- run repro with changed filter code, it will return same results as on 
previous step.

Looks like filter code is cached on server and is never being updated.

  was:
PFA reproducer attached. Peer class loading should be enabled on both, server 
and client.
Server should NOT has scan query filter class in its classpath.

Steps to reproduce:
- start standalone server
- run repro, it should work fine.
- run repro with changed filter code, it will return same results.


> ScanQuery filter class code is not updated on server once it has been changed 
> on client.
> 
>
> Key: IGNITE-4918
> URL: https://issues.apache.org/jira/browse/IGNITE-4918
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.9
>Reporter: Andrew Mashenkov
> Fix For: 2.0
>
> Attachments: ScanQueryFilter.java
>
>
> PFA reproducer attached. Peer class loading should be enabled on both, server 
> and client.
> Server should NOT has scan query filter class in its classpath.
> Steps to reproduce:
> - start standalone server
> - run repro, it should work fine.
> - run repro with changed filter code, it will return same results as on 
> previous step.
> Looks like filter code is cached on server and is never being updated.



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

[jira] [Updated] (IGNITE-4918) ScanQuery filter class code is not updated on server once it has been changed on client.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4918:
-
Fix Version/s: 2.0

> ScanQuery filter class code is not updated on server once it has been changed 
> on client.
> 
>
> Key: IGNITE-4918
> URL: https://issues.apache.org/jira/browse/IGNITE-4918
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.9
>Reporter: Andrew Mashenkov
> Fix For: 2.0
>
> Attachments: ScanQueryFilter.java
>
>
> PFA reproducer attached. Peer class loading should be enabled on both, server 
> and client.
> Server should NOT has scan query filter class in its classpath.
> Steps to reproduce:
> - start standalone server
> - run repro, it should work fine.
> - run repro with changed filter code, it will return same results.



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

[jira] [Updated] (IGNITE-4918) ScanQuery filter class code is not updated on server once it has been changed on client.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4918:
-
Description: 
PFA reproducer attached. Peer class loading should be enabled on both, server 
and client.
Server should NOT has scan query filter class in its classpath.

Steps to reproduce:
- start standalone server
- run repro, it should work fine.
- run repro with changed filter code, it will return same results.

  was:
PFA reproducer attached.
Steps to reproduce:
- start standalone server
- run repro, it should work fine.
- run repro with changed filter code, it will return same results.


> ScanQuery filter class code is not updated on server once it has been changed 
> on client.
> 
>
> Key: IGNITE-4918
> URL: https://issues.apache.org/jira/browse/IGNITE-4918
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.9
>Reporter: Andrew Mashenkov
> Attachments: ScanQueryFilter.java
>
>
> PFA reproducer attached. Peer class loading should be enabled on both, server 
> and client.
> Server should NOT has scan query filter class in its classpath.
> Steps to reproduce:
> - start standalone server
> - run repro, it should work fine.
> - run repro with changed filter code, it will return same results.



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

[jira] [Updated] (IGNITE-4918) ScanQuery filter class code is not updated on server once it has been changed on client.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4918:
-
Description: 
PFA reproducer attached.
Steps to reproduce:
- start standalone server
- run repro, it should work fine.
- run repro with changed filter code, it will return same results.

> ScanQuery filter class code is not updated on server once it has been changed 
> on client.
> 
>
> Key: IGNITE-4918
> URL: https://issues.apache.org/jira/browse/IGNITE-4918
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.9
>Reporter: Andrew Mashenkov
> Attachments: ScanQueryFilter.java
>
>
> PFA reproducer attached.
> Steps to reproduce:
> - start standalone server
> - run repro, it should work fine.
> - run repro with changed filter code, it will return same results.



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

[jira] [Updated] (IGNITE-4918) ScanQuery filter class code is not updated on server once it has been changed on client.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4918:
-
Attachment: ScanQueryFilter.java

> ScanQuery filter class code is not updated on server once it has been changed 
> on client.
> 
>
> Key: IGNITE-4918
> URL: https://issues.apache.org/jira/browse/IGNITE-4918
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.9
>Reporter: Andrew Mashenkov
> Attachments: ScanQueryFilter.java
>
>
> PFA reproducer attached.
> Steps to reproduce:
> - start standalone server
> - run repro, it should work fine.
> - run repro with changed filter code, it will return same results.



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

[jira] [Commented] (IGNITE-4914) Dynamic type registration hangs for platformId > 0 on node restart

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4914:


GitHub user sergey-chugunov-1985 opened a pull request:

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

IGNITE-4914 distributing marshaller mappings for multiple platforms fixed



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

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

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

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


commit 519e9d473db696452c169e87719cb74d5be17c9a
Author: Sergey Chugunov 
Date:   2017-04-05T13:31:24Z

IGNITE-4914 distributing marshaller mappings for multiple platforms was 
fixed




> Dynamic type registration hangs for platformId > 0 on node restart
> --
>
> Key: IGNITE-4914
> URL: https://issues.apache.org/jira/browse/IGNITE-4914
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Sergey Chugunov
> Fix For: 2.0
>
>
> {{MarshallerContextImpl.registerClassName}} hangs when called after node 
> restart:
> * Start two nodes, A and B
> * Call {{registerClassName}} with {{platformId = 1}} and any class name from 
> node B
> * Stop node B
> * Start node B again
> * Call {{registerClassName}} with {{platformId = 1}} and any class name from 
> node B
> The last call hangs.



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

[jira] [Created] (IGNITE-4918) ScanQuery filter class code is not updated on server once it has been changed on client.

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-4918:


 Summary: ScanQuery filter class code is not updated on server once 
it has been changed on client.
 Key: IGNITE-4918
 URL: https://issues.apache.org/jira/browse/IGNITE-4918
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.9
Reporter: Andrew Mashenkov






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

[jira] [Commented] (IGNITE-4908) Ignite.reentrantLock looks much slower than IgniteCache.lock.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-4908:
--

[~sharpler],
Your results may be very useful. If you see any issues with our lock 
implementations, please, create separate issue and\or start discussion on 
dev-list.

> Ignite.reentrantLock looks much slower than IgniteCache.lock.
> -
>
> Key: IGNITE-4908
> URL: https://issues.apache.org/jira/browse/IGNITE-4908
> Project: Ignite
>  Issue Type: Improvement
>  Components: data structures
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Alexander Menshikov
> Fix For: 2.1
>
>
> We should make a benchmark and investigate this issue.



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

[jira] [Commented] (IGNITE-4908) Ignite.reentrantLock looks much slower than IgniteCache.lock.

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov commented on IGNITE-4908:
-

Ops... :) Okay.

> Ignite.reentrantLock looks much slower than IgniteCache.lock.
> -
>
> Key: IGNITE-4908
> URL: https://issues.apache.org/jira/browse/IGNITE-4908
> Project: Ignite
>  Issue Type: Improvement
>  Components: data structures
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Alexander Menshikov
> Fix For: 2.1
>
>
> We should make a benchmark and investigate this issue.



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

[jira] [Commented] (IGNITE-4908) Ignite.reentrantLock looks much slower than IgniteCache.lock.

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov commented on IGNITE-4908:
-

[~amashenkov]
The formatting got corrupted :( I can send results in file if you want. Anyway 
this benchmarks use locks in write mode only. So may be we need more complex 
scenario.

> Ignite.reentrantLock looks much slower than IgniteCache.lock.
> -
>
> Key: IGNITE-4908
> URL: https://issues.apache.org/jira/browse/IGNITE-4908
> Project: Ignite
>  Issue Type: Improvement
>  Components: data structures
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Alexander Menshikov
> Fix For: 2.1
>
>
> We should make a benchmark and investigate this issue.



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

[jira] [Issue Comment Deleted] (IGNITE-4908) Ignite.reentrantLock looks much slower than IgniteCache.lock.

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov updated IGNITE-4908:

Comment: was deleted

(was: [~amashenkov]
The formatting got corrupted :( I can send results in file if you want. Anyway 
this benchmarks use locks in write mode only. So may be we need more complex 
scenario.)

> Ignite.reentrantLock looks much slower than IgniteCache.lock.
> -
>
> Key: IGNITE-4908
> URL: https://issues.apache.org/jira/browse/IGNITE-4908
> Project: Ignite
>  Issue Type: Improvement
>  Components: data structures
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Alexander Menshikov
> Fix For: 2.1
>
>
> We should make a benchmark and investigate this issue.



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

[jira] [Updated] (IGNITE-4908) Ignite.reentrantLock looks much slower than IgniteCache.lock.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4908:
-
Summary: Ignite.reentrantLock looks much slower than IgniteCache.lock.  
(was: Reentrant lock looks much slower that cache locks.)

> Ignite.reentrantLock looks much slower than IgniteCache.lock.
> -
>
> Key: IGNITE-4908
> URL: https://issues.apache.org/jira/browse/IGNITE-4908
> Project: Ignite
>  Issue Type: Improvement
>  Components: data structures
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Alexander Menshikov
> Fix For: 2.1
>
>
> We should make a benchmark and investigate this issue.



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

[jira] [Commented] (IGNITE-4908) Reentrant lock looks much slower that cache locks.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-4908:
--

[~sharpler], seems, there is misunderstanding.
I mean, we need compare distributed locks features: IgniteCache.lock(...) vs 
Ignite.reentrantLock(...).


> Reentrant lock looks much slower that cache locks.
> --
>
> Key: IGNITE-4908
> URL: https://issues.apache.org/jira/browse/IGNITE-4908
> Project: Ignite
>  Issue Type: Improvement
>  Components: data structures
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Alexander Menshikov
> Fix For: 2.1
>
>
> We should make a benchmark and investigate this issue.



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

[jira] [Commented] (IGNITE-4908) Reentrant lock looks much slower that cache locks.

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov commented on IGNITE-4908:
-

[~amashenkov]

I started work on this issue. I have already written JMH benchmark for these 
Ignite's lock classes: GridSpinReadWriteLock, GridStripedSpinBusyLock, 
GridKeyLock, StripedCompositeReadWriteLock, GridBusyLock and GridSpinBusyLock. 
And for these JDK's lock classes: synchronized, ReentrantReadWriteLock and 
ReentrantLock - for comparison. In benchmarks just increment one long field. 
And for comparation I also added AtomicLong and nonsynchronized version. Result 
for my notebook with 2 real cores + 2 hyper threading cores:
--
With 1 thread:

Benchmark Mode  Cnt
ScoreError   Units
//For comparation
JmhGridLocksBenchmark.testNonThreadSafeLong  thrpt   10  
373,469 ± 10,764  ops/us
JmhGridLocksBenchmark.testAtomicLong thrpt   10  
114,843 ±  3,791  ops/us
//JDK locks
JmhGridLocksBenchmark.testReentrantLockLong  thrpt   10   
39,025 ±  0,641  ops/us
JmhGridLocksBenchmark.testReadWriteLockLong  thrpt   10   
37,919 ±  0,521  ops/us
JmhGridLocksBenchmark.testSynchronizedLong   thrpt   10   
34,335 ±  0,815  ops/us
//Ignite locks
JmhGridLocksBenchmark.testGridStripedSpinBusyLockLongthrpt   10   
37,806 ±  0,560  ops/us
JmhGridLocksBenchmark.testGridBusyLockLong   thrpt   10   
34,996 ±  0,781  ops/us
JmhGridLocksBenchmark.testGridSpinBusyLockLong   thrpt   10   
29,781 ±  1,175  ops/us
JmhGridLocksBenchmark.testGridSpinReadWriteLockLong  thrpt   10   
24,921 ±  0,716  ops/us
JmhGridLocksBenchmark.testStripedCompositeReadWriteLockLong  thrpt   10   
10,300 ±  0,167  ops/us
JmhGridLocksBenchmark.testGridKeyLockLongthrpt   10
6,752 ±  0,235  ops/us
--
With 2 threads:

Benchmark Mode  Cnt
ScoreError   Units
//For comparation
JmhGridLocksBenchmark.testNonThreadSafeLong  thrpt   10  
652,727 ±  2,569  ops/us
JmhGridLocksBenchmark.testAtomicLong thrpt   10   
31,319 ± 11,587  ops/us
//JDK locks
JmhGridLocksBenchmark.testReentrantLockLong  thrpt   10
7,602 ±  4,341  ops/us
JmhGridLocksBenchmark.testReadWriteLockLong  thrpt   10
8,698 ±  4,474  ops/us
JmhGridLocksBenchmark.testSynchronizedLong   thrpt   10   
14,623 ±  2,185  ops/us
//Ignite locks
JmhGridLocksBenchmark.testGridStripedSpinBusyLockLongthrpt   10   
28,999 ±  0,421  ops/us
JmhGridLocksBenchmark.testGridBusyLockLong   thrpt   10
7,987 ±  1,918  ops/us
JmhGridLocksBenchmark.testGridSpinBusyLockLong   thrpt   10
7,361 ±  1,351  ops/us
JmhGridLocksBenchmark.testGridSpinReadWriteLockLong  thrpt   10   
22,250 ±  2,190  ops/us
JmhGridLocksBenchmark.testStripedCompositeReadWriteLockLong  thrpt   10
3,067 ±  0,391  ops/us
JmhGridLocksBenchmark.testGridKeyLockLongthrpt   10
2,827 ±  0,398  ops/us
--
With 4 threads:

Benchmark Mode  Cnt
Score   Error   Units
//For comparation
JmhGridLocksBenchmark.testNonThreadSafeLong  thrpt   10  
592,226 ± 1,551  ops/us
JmhGridLocksBenchmark.testAtomicLong thrpt   10   
25,414 ± 1,831  ops/us
//JDK locks
JmhGridLocksBenchmark.testReentrantLockLong  thrpt   10   
29,794 ± 0,966  ops/us
JmhGridLocksBenchmark.testReadWriteLockLong  thrpt   10   
26,638 ± 0,572  ops/us
JmhGridLocksBenchmark.testSynchronizedLong   thrpt   10   
20,910 ± 0,747  ops/us
//Ignite locks
JmhGridLocksBenchmark.testGridStripedSpinBusyLockLongthrpt   10   
30,443 ± 1,125  ops/us
JmhGridLocksBenchmark.testGridBusyLockLong   thrpt   10
6,323 ± 0,233  ops/us
JmhGridLocksBenchmark.testGridSpinBusyLockLong   thrpt   10
6,153 ± 0,188  ops/us
JmhGridLocksBenchmark.testGridSpinReadWriteLockLong  thrpt   10   
19,847 ± 4,011  ops/us
JmhGridLocksBenchmark.testStripedCompositeReadWriteLockLong  thrpt   10
7,132 ± 0,983  ops/us
JmhGridLocksBenchmark.testGridKeyLockLongthrpt   10
2,648 ± 0,652  ops/us
--
With 8 threads:

Benchmark Mode  Cnt
Score   Error   Units
//For comparation
JmhGridLocksBenchmark.testNonThreadSafeLong  thrpt   10  
586,749 ± 2,911  ops/us
JmhGridLocksBenchmark.testAtomicLong thrpt   10   
32,270 ± 0,609  ops/us
//JDK locks

[jira] [Commented] (IGNITE-3303) Apache Flink Integration - Flink source to run a continuous query against one or multiple caches

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-3303:
--

[~samaitra]

I don't think it's acceptable restriction to have only one IgniteSource since 
this means we can use only one cache in this case. 
Seems we have to find Flink expert to review or redesign this.

> Apache Flink Integration - Flink source to run a continuous query against one 
> or multiple caches
> 
>
> Key: IGNITE-3303
> URL: https://issues.apache.org/jira/browse/IGNITE-3303
> Project: Ignite
>  Issue Type: New Feature
>  Components: streaming
>Reporter: Saikat Maitra
>Assignee: Anton Vinogradov
> Attachments: Screen Shot 2016-10-07 at 12.44.47 AM.png, 
> testFlinkIgniteSourceWithLargeBatch.log, win7.PNG
>
>
> Apache Flink integration 
> +++ *Ignite as a bidirectional Connector* +++
> As a Flink source => run a continuous query against one or multiple
> caches [4].
> Related discussion : 
> http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Flink-lt-gt-Apache-Ignite-integration-td8163.html



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

[jira] [Comment Edited] (IGNITE-3469) Get rid of deprecated APIs and entities

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-3469 at 4/5/17 1:03 PM:
--

The list of not removed yet:
h3. The list of the deprecated public class / methods / properties:
- The system flags:
-- {{IGNITE_BINARY_SORT_OBJECT_FIELDS}};
-- {{IGNITE_BINARY_DONT_WRAP_TREE_STRUCTURES}};
-- {{IGNITE_MIN_BUFFERED_COMMUNICATION_MSG_CNT}} - not used in the projects now.
- Backup filters for affinity functions;
- {{ContinuousQuery.setRemoteFilter}};
- {{CacheStore.sessionEnd}};
- {{CacheAbstractJdbcStore.translateFields}};
- {{CacheJdbcPojoStoreFactory.setDataSource}};
- {{CacheConfiguration}} properties: {{transactionManagerLookupClassName}} and 
{rebalanceThreadPoolSize}};
- {{ConnectorConfiguration.sslContextFactory}} property;
- {{IgniteConfiguration.nodeId}} properties:
- {{TransactionConfiguration}} properties: 
-- {{txSerializableEnabled}};
-- {{txManagerLookupClassName}};
- {{StreamTupleExtractor}} class and relations;
- ignite-hadoop: Several constructors of the 
{{IgniteHadoopIgfsSecondaryFileSystem}};
- ignite-yarn: {{ApplicationMaster.getContainers()}}.

h3. The list of the deprecated private class / methods / properties:
- Classes are retated to the {{GridSslContextFactory}};
- {{JdbcConnection}} related classes;
- {{GridCacheUtils.cheatCache}};
- {{GridCacheCommittedTxInfo}};
- {{GridDistributedTxFinishRequest}}: {{syncCommit}}, {{syncRollback}};
- One of the constructors of {{GridLeanSet}};
- Several methods at the {{IgniteUtils}};
- Several methods at the {{GridFunc}};
- {{PlatformDotNetBinaryTypeConfiguration.isKeepDeserialized()}};
- {{ServerImpl.RingMessageWorker.processNodeAddedMessage}};
- {{TcpDiscoverySpi.versionCheckFailed}};




was (Author: tledkov-gridgain):
The list of not removed yet:
h3. The list of the deprecated public class / methods / properties:
- The system flags:
-- {{IGNITE_BINARY_SORT_OBJECT_FIELDS}};
-- {{IGNITE_BINARY_DONT_WRAP_TREE_STRUCTURES}};
-- {{IGNITE_MIN_BUFFERED_COMMUNICATION_MSG_CNT}} - not used in the projects now.
- Classes related with {{AffinityNodeHashResolver}};
- Backup filters for affinity functions;
- {{RandomEvictionPolicy}};
- {{ContinuousQuery.setRemoteFilter}};
- {{CacheStore.sessionEnd}};
- {{CacheAbstractJdbcStore.translateFields}};
- {{CacheJdbcPojoStoreFactory.setDataSource}};
- {{CacheConfiguration}} properties: {{transactionManagerLookupClassName}} and 
{rebalanceThreadPoolSize}};
- {{ConnectorConfiguration.sslContextFactory}} property;
- {{IgniteConfiguration.nodeId}} properties:
- {{TransactionConfiguration}} properties: 
-- {{txSerializableEnabled}};
-- {{txManagerLookupClassName}};
- {{StreamTupleExtractor}} class and relations;
- ignite-hadoop: Several constructors of the 
{{IgniteHadoopIgfsSecondaryFileSystem}};
- ignite-yarn: {{ApplicationMaster.getContainers()}}.

h3. The list of the deprecated private class / methods / properties:
- Classes are retated to the {{GridSslContextFactory}};
- {{JdbcConnection}} related classes;
- {{GridCacheUtils.cheatCache}};
- {{GridCacheCommittedTxInfo}};
- {{GridDistributedTxFinishRequest}}: {{syncCommit}}, {{syncRollback}};
- One of the constructors of {{GridLeanSet}};
- Several methods at the {{IgniteUtils}};
- Several methods at the {{GridFunc}};
- {{PlatformDotNetBinaryTypeConfiguration.isKeepDeserialized()}};
- {{ServerImpl.RingMessageWorker.processNodeAddedMessage}};
- {{TcpDiscoverySpi.versionCheckFailed}};



> Get rid of deprecated APIs and entities
> ---
>
> Key: IGNITE-3469
> URL: https://issues.apache.org/jira/browse/IGNITE-3469
> Project: Ignite
>  Issue Type: Task
>Reporter: Alexey Goncharuk
>Assignee: Taras Ledkov
>  Labels: important
> Fix For: 2.0
>
>
> There are more than 220 deprecated elements in Ignite code kept for the sake 
> of backward compatibility. We need to cleanup the code for Ignite 2.0 release.
> 2.0 migration guide has to be updated if needed: 
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide



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

[jira] [Assigned] (IGNITE-2466) OutOfMemory when PRIMARY_SYNC mode is used

[Semen Boikov (JIRA)]

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

Semen Boikov reassigned IGNITE-2466:


Assignee: Dmitry Karachentsev  (was: Semen Boikov)

Hi,

I reviewed your changes, have some comments:
- I think new interface BackPressureTracker is not needed, just use existing 
GridNioMessageTracker everywhere. Also you can not change 
CommunicationListener, this is public API, so use class cast where needed.
- I don't like you added one more thread local in GridNioBackPressureControl. I 
think single thread local is enough, (threadProcessingMessage is true is there 
is non-null tracker)
- this changes in GridDhtAtomicCache:
{noformat}
if (node.isClient() && !dhtFut.isDone()) {
final BackPressureTracker tracker = 
GridNioBackPressureControl.threadTracker();

if (tracker != null) {
tracker.registerMessage();

dhtFut.listen(new IgniteInClosure() {
@Override public void apply(IgniteInternalFuture fut) {
tracker.deregisterMessage();
}
});
}
}
{noformat}
I think check 'node.isClient()' is not needed, it should not matter if update 
was initiated by client or server, instead you need add check taht 
writeSynchronizationMode = PRIMARY_SYNC

Thanks

> OutOfMemory when PRIMARY_SYNC mode is used
> --
>
> Key: IGNITE-2466
> URL: https://issues.apache.org/jira/browse/IGNITE-2466
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Dmitry Karachentsev
> Fix For: 2.0
>
> Attachments: example-ignite.xml, MemTest.java
>
>
> To reproduce, run two server nodes with 2g of heap each and then MemTest. 
> Servers will fail with OOME. If backups are disabled or there is only one 
> server node, it works.



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

[jira] [Comment Edited] (IGNITE-3469) Get rid of deprecated APIs and entities

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-3469 at 4/5/17 12:49 PM:
---

The list of not removed yet:
h3. The list of the deprecated public class / methods / properties:
- The system flags:
-- {{IGNITE_BINARY_SORT_OBJECT_FIELDS}};
-- {{IGNITE_BINARY_DONT_WRAP_TREE_STRUCTURES}};
-- {{IGNITE_MIN_BUFFERED_COMMUNICATION_MSG_CNT}} - not used in the projects now.
- Classes related with {{AffinityNodeHashResolver}};
- Backup filters for affinity functions;
- {{RandomEvictionPolicy}};
- {{ContinuousQuery.setRemoteFilter}};
- {{CacheStore.sessionEnd}};
- {{CacheAbstractJdbcStore.translateFields}};
- {{CacheJdbcPojoStoreFactory.setDataSource}};
- {{CacheConfiguration}} properties: {{transactionManagerLookupClassName}} and 
{rebalanceThreadPoolSize}};
- {{ConnectorConfiguration.sslContextFactory}} property;
- {{IgniteConfiguration.nodeId}} properties:
- {{TransactionConfiguration}} properties: 
-- {{txSerializableEnabled}};
-- {{txManagerLookupClassName}};
- {{StreamTupleExtractor}} class and relations;
- ignite-hadoop: Several constructors of the 
{{IgniteHadoopIgfsSecondaryFileSystem}};
- ignite-yarn: {{ApplicationMaster.getContainers()}}.

h3. The list of the deprecated private class / methods / properties:
- Classes are retated to the {{GridSslContextFactory}};
- {{JdbcConnection}} related classes;
- {{GridCacheUtils.cheatCache}};
- {{GridCacheCommittedTxInfo}};
- {{GridDistributedTxFinishRequest}}: {{syncCommit}}, {{syncRollback}};
- One of the constructors of {{GridLeanSet}};
- Several methods at the {{IgniteUtils}};
- Several methods at the {{GridFunc}};
- {{PlatformDotNetBinaryTypeConfiguration.isKeepDeserialized()}};
- {{ServerImpl.RingMessageWorker.processNodeAddedMessage}};
- {{TcpDiscoverySpi.versionCheckFailed}};




was (Author: tledkov-gridgain):
The list of not removed yet:
h3. The list of the deprecated public class / methods / properties:
- The system flags:
-- {{IGNITE_BINARY_SORT_OBJECT_FIELDS}};
-- {{IGNITE_BINARY_DONT_WRAP_TREE_STRUCTURES}};
-- {{IGNITE_MIN_BUFFERED_COMMUNICATION_MSG_CNT}} - not used in the projects now.
- Classes related with {{AffinityNodeHashResolver}};
- Backup filters for affinity functions;
- {{RandomEvictionPolicy}};
- {{ContinuousQuery.setRemoteFilter}};
- {{CacheStore.sessionEnd}};
- {{CacheAbstractJdbcStore.translateFields}};
- {{CacheJdbcPojoStoreFactory.setDataSource}};
- {{CacheConfiguration}} properties: {{transactionManagerLookupClassName}} and 
{rebalanceThreadPoolSize}};
- {{ConnectorConfiguration.sslContextFactory}} property;
- {{IgniteConfiguration}} properties:
-- {{nodeId}};
-- {{DFLT_PUBLIC_KEEP_ALIVE_TIME}};
-- {{DFLT_PUBLIC_THREADPOOL_QUEUE_CAP}};
-- {{DFLT_SYSTEM_MAX_THREAD_CNT}};
-- {{DFLT_SYSTEM_KEEP_ALIVE_TIME}};
-- {{DFLT_UTILITY_KEEP_ALIVE_TIME}};
-- {{DFLT_SYSTEM_THREADPOOL_QUEUE_CAP}};
- {{TransactionConfiguration}} properties: 
-- {{txSerializableEnabled}};
-- {{txManagerLookupClassName}};
- {{StreamTupleExtractor}} class and relations;
- ignite-hadoop: Several constructors of the 
{{IgniteHadoopIgfsSecondaryFileSystem}};
- ignite-yarn: {{ApplicationMaster.getContainers()}}.

h3. The list of the deprecated private class / methods / properties:
- Classes are retated to the {{GridSslContextFactory}};
- {{JdbcConnection}} related classes;
- {{GridCacheUtils.cheatCache}};
- {{GridCacheCommittedTxInfo}};
- {{GridDistributedTxFinishRequest}}: {{syncCommit}}, {{syncRollback}};
- One of the constructors of {{GridLeanSet}};
- Several methods at the {{IgniteUtils}};
- Several methods at the {{GridFunc}};
- {{PlatformDotNetBinaryTypeConfiguration.isKeepDeserialized()}};
- {{ServerImpl.RingMessageWorker.processNodeAddedMessage}};
- {{TcpDiscoverySpi.versionCheckFailed}};



> Get rid of deprecated APIs and entities
> ---
>
> Key: IGNITE-3469
> URL: https://issues.apache.org/jira/browse/IGNITE-3469
> Project: Ignite
>  Issue Type: Task
>Reporter: Alexey Goncharuk
>Assignee: Taras Ledkov
>  Labels: important
> Fix For: 2.0
>
>
> There are more than 220 deprecated elements in Ignite code kept for the sake 
> of backward compatibility. We need to cleanup the code for Ignite 2.0 release.
> 2.0 migration guide has to be updated if needed: 
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide



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

[jira] [Commented] (IGNITE-4535) Add option to store deserialized values on-heap

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4535:


GitHub user ilantukh opened a pull request:

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

IGNITE-4535



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

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

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

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


commit 59c302c1b707c29a681fca398671863e69d22171
Author: Ilya Lantukh 
Date:   2017-03-14T13:29:15Z

ignite-4535 : WIP.

(cherry picked from commit 4dc8376)

commit abfbaf801f8a4de747e463a2ac7bcdb5cea61061
Author: Ilya Lantukh 
Date:   2017-03-16T11:44:24Z

ignite-4535 : fixed tests to distinguish onheap and offheap peeks.

(cherry picked from commit 925c7e4)

commit 51d27eb772a227ecbfd6a394c16bea89d945f94e
Author: Ilya Lantukh 
Date:   2017-03-16T12:55:22Z

ignite-4535 : Fixed test failures.

(cherry picked from commit 678bd1b)

commit 82fe3bfc3ac5a3997ea2c650cf6ee40753325a10
Author: Ilya Lantukh 
Date:   2017-03-16T14:53:30Z

ignite-4535 : Analyzed failing tests.

(cherry picked from commit 7c483a3)

commit 5ce33f3334c1692eed93a07af3eb962b44f7b8cb
Author: Ilya Lantukh 
Date:   2017-03-16T15:34:15Z

ignite-4535 : Fixed and uncommented eviction tests.

(cherry picked from commit ff4ec5e)

commit 8c60243aac12164918aedc829936a61db4e44d31
Author: Ilya Lantukh 
Date:   2017-03-20T12:49:27Z

ignite-4535 : Removed SWAP PeekMode, adjusted tests.

(cherry picked from commit 5ac245e)

commit edc8b7fb51786a405f5a26fe6b6b059ac7e3ed10
Author: Ilya Lantukh 
Date:   2017-03-20T13:49:41Z

ignite-4535 : Fixed calculation of entries count in heap.

(cherry picked from commit 9826ce4)

commit 51eee72c8fb594005a517c8db30578e84728e099
Author: Ilya Lantukh 
Date:   2017-03-20T15:15:42Z

ignite-4535 : Removing CacheMemoryMode - WIP.

(cherry picked from commit 149b974)

commit b55640aafb8e4e9d701e606239a31384e133ea35
Author: Ilya Lantukh 
Date:   2017-03-20T15:29:57Z

ignite-4535 : Removing CacheMemoryMode - WIP.

(cherry picked from commit 250597e)

commit 3e71edae117c435ee406c4fda6526c27d805db99
Author: Ilya Lantukh 
Date:   2017-03-20T16:12:36Z

ignite-4535 : Removing CacheMemoryMode - WIP.

(cherry picked from commit 5e90523)

commit 5ec807a53a812c47a5a8b22f98d57b25cccf0240
Author: Ilya Lantukh 
Date:   2017-03-21T13:27:18Z

ignite-4535 : Removing CacheMemoryMode - WIP.

(cherry picked from commit b3e1bc3)

commit 7a49fa5d4be9970af93ef662abc84d0538638717
Author: Ilya Lantukh 
Date:   2017-03-30T13:10:26Z

ignite-4535 : Conflicts.

commit 4ea0316e7a2e04389e57efbfbbeaad77fa5bcb45
Author: Ilya Lantukh 
Date:   2017-03-21T13:48:51Z

ignite-4535 : Removing CacheMemoryMode - done.

(cherry picked from commit 6b7472c)

commit c89c563b573d57f5138ab61bd9a161a2d8c8866b
Author: Ilya Lantukh 
Date:   2017-03-21T13:52:43Z

ignite-4535 : Removed redundant test.

(cherry picked from commit 3cfea91)

commit 141064ed9e0c392ca0c5bb51bf848945bec1c1d1
Author: Ilya Lantukh 
Date:   2017-03-21T14:29:05Z

ignite-4535 : Fixed size calculation.

(cherry picked from commit 531a449)

commit b5ccfe365ff1a1f1ef949b7505f6058b772671c7
Author: Ilya Lantukh 
Date:   2017-03-21T14:42:06Z

ignite-4535 : Redesigned semantics of GridDhtLocalPartitions#size() and 
#publicSize() methods.

(cherry picked from commit dd3884d)

commit 0756bb890c26d74a51e72268811048c485502aee
Author: Ilya Lantukh 
Date:   2017-03-22T12:15:02Z

ignite-4535 : Fixed test.

(cherry picked from commit 1475ee3)

commit 952c0efd12d2b90b3b519a999ae0fd6935b84274
Author: Ilya Lantukh 
Date:   2017-03-24T11:30:00Z

ignite-4535 : Fixed DHT cache size calculation.

(cherry picked from commit 06c845c)

commit 06d853d124c9cfc1cea5e13867edfa78c89a3d74
Author: Ilya Lantukh 
Date:   2017-03-30T13:21:52Z

ignite-4535 : conflicts

commit 4ad8974c9f741ea33379ad4e323db9873cfda328
Author: Ilya Lantukh 
Date:   2017-03-30T13:31:03Z

ignite-4535 : Conflicts.

commit 

[jira] [Commented] (IGNITE-3469) Get rid of deprecated APIs and entities

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-3469:
--

The list of not removed yet:
h3. The list of the deprecated public class / methods / properties:
- The system flags:
-- {{IGNITE_BINARY_SORT_OBJECT_FIELDS}};
-- {{IGNITE_BINARY_DONT_WRAP_TREE_STRUCTURES}};
-- {{IGNITE_MIN_BUFFERED_COMMUNICATION_MSG_CNT}} - not used in the projects now.
- Classes related with {{AffinityNodeHashResolver}};
- Backup filters for affinity functions;
- {{RandomEvictionPolicy}};
- {{ContinuousQuery.setRemoteFilter}};
- {{CacheStore.sessionEnd}};
- {{CacheAbstractJdbcStore.translateFields}};
- {{CacheJdbcPojoStoreFactory.setDataSource}};
- {{CacheConfiguration}} properties: {{transactionManagerLookupClassName}} and 
{rebalanceThreadPoolSize}};
- {{ConnectorConfiguration.sslContextFactory}} property;
- {{IgniteConfiguration}} properties:
-- {{nodeId}};
-- {{DFLT_PUBLIC_KEEP_ALIVE_TIME}};
-- {{DFLT_PUBLIC_THREADPOOL_QUEUE_CAP}};
-- {{DFLT_SYSTEM_MAX_THREAD_CNT}};
-- {{DFLT_SYSTEM_KEEP_ALIVE_TIME}};
-- {{DFLT_UTILITY_KEEP_ALIVE_TIME}};
-- {{DFLT_SYSTEM_THREADPOOL_QUEUE_CAP}};
- {{TransactionConfiguration}} properties: 
-- {{txSerializableEnabled}};
-- {{txManagerLookupClassName}};
- {{IgniteSpiContext}}: methods {{addMessageListener, removeMessageListener}};
- {{StreamTupleExtractor}} class and relations;
- ignite-hadoop: Several constructors of the 
{{IgniteHadoopIgfsSecondaryFileSystem}};
- ignite-yarn: {{ApplicationMaster.getContainers()}}.

h3. The list of the deprecated private class / methods / properties:
- Classes are retated to the {{GridSslContextFactory}};
- {{JdbcConnection}} related classes;
- {{GridCacheUtils.cheatCache}};
- {{GridCacheCommittedTxInfo}};
- {{GridDistributedTxFinishRequest}}: {{syncCommit}}, {{syncRollback}};
- One of the constructors of {{GridLeanSet}};
- Several methods at the {{IgniteUtils}};
- Several methods at the {{GridFunc}};
- {{PlatformDotNetBinaryTypeConfiguration.isKeepDeserialized()}};
- {{ServerImpl.RingMessageWorker.processNodeAddedMessage}};
- {{TcpDiscoverySpi.versionCheckFailed}};



> Get rid of deprecated APIs and entities
> ---
>
> Key: IGNITE-3469
> URL: https://issues.apache.org/jira/browse/IGNITE-3469
> Project: Ignite
>  Issue Type: Task
>Reporter: Alexey Goncharuk
>Assignee: Taras Ledkov
>  Labels: important
> Fix For: 2.0
>
>
> There are more than 220 deprecated elements in Ignite code kept for the sake 
> of backward compatibility. We need to cleanup the code for Ignite 2.0 release.
> 2.0 migration guide has to be updated if needed: 
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide



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

[jira] [Comment Edited] (IGNITE-4899) .NET: Review Dictionary usage in APIs

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-4899 at 4/5/17 11:59 AM:
-

{{GetAll}} reads data from pooled memory using pooled stream. Returning lazy 
{{IEnumerable}} will capture these pooled things and may lead to undefined 
behavior. We should not do this.

However, dictionary is still inefficient when it is used as a collection.


was (Author: ptupitsyn):
{{GetAll}} reads data from pooled memory using pooled stream. Returning lazy 
{{IEnumerable}} will capture these pooled things and may lead to undefined 
behavior. We should not do this.

> .NET: Review Dictionary usage in APIs
> -
>
> Key: IGNITE-4899
> URL: https://issues.apache.org/jira/browse/IGNITE-4899
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, breaking-api
> Fix For: 2.0
>
>
> We have replaced {{IDictionary}} with {{IEnumerable>}} 
> in {{ICacheStore}}, let's do the same for other APIs like {{ICache.GetAll}}.
> Reading GetAll results into a dictionary is inefficient in case when user 
> only needs to iterate over results (unneeded allocation and hashing).



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

[jira] [Commented] (IGNITE-4899) .NET: Review Dictionary usage in APIs

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4899:


{{GetAll}} reads data from pooled memory using pooled stream. Returning lazy 
{{IEnumerable}} will capture these pooled things and may lead to undefined 
behavior. We should not do this.

> .NET: Review Dictionary usage in APIs
> -
>
> Key: IGNITE-4899
> URL: https://issues.apache.org/jira/browse/IGNITE-4899
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, breaking-api
> Fix For: 2.0
>
>
> We have replaced {{IDictionary}} with {{IEnumerable>}} 
> in {{ICacheStore}}, let's do the same for other APIs like {{ICache.GetAll}}.
> Reading GetAll results into a dictionary is inefficient in case when user 
> only needs to iterate over results (unneeded allocation and hashing).



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

[jira] [Commented] (IGNITE-4917) BinaryObjectBuilder field value access failed if its serialized with optimal marshaller

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4917:


GitHub user AMashenkov opened a pull request:

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

IGNITE-4917: BinaryObjectBuilder field value access failed if its 
serialized with optimal marshaller

Fixed failure when accessing BinaryObjectBuilder field value serialized 
with OptimizedMarshaller.

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

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

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

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


commit 1fcf992b30d86ad0c34df82c7a6afb5c52ac6106
Author: Andrey V. Mashenkov 
Date:   2017-04-05T11:33:27Z

Fixed failure when accessing BinaryObjectBuilder field value serialized 
with OptimizedMarshaller .




> BinaryObjectBuilder field value access failed if its serialized with optimal 
> marshaller
> ---
>
> Key: IGNITE-4917
> URL: https://issues.apache.org/jira/browse/IGNITE-4917
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
> Fix For: 2.0
>
>
> Repro:
> {noformat}
> BinaryObjectBuilder bob = ignite.binary().builder("test");
> bob.setField("test1", new BigInteger("123456789"), BigInteger.class);
>
> BinaryObjectBuilder bob2 = bob.build().toBuilder();
> 
> Object o = bob2.getField("test1"); // This call failed with "Invalid flag 
> value: -2"
> {noformat}



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

[jira] [Commented] (IGNITE-4917) BinaryObjectBuilder field value access failed if its serialized with optimal marshaller

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-4917:
--

Looks like it was missed in IGNITE-4026.

> BinaryObjectBuilder field value access failed if its serialized with optimal 
> marshaller
> ---
>
> Key: IGNITE-4917
> URL: https://issues.apache.org/jira/browse/IGNITE-4917
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
> Fix For: 2.0
>
>
> Repro:
> {noformat}
> BinaryObjectBuilder bob = ignite.binary().builder("test");
> bob.setField("test1", new BigInteger("123456789"), BigInteger.class);
>
> BinaryObjectBuilder bob2 = bob.build().toBuilder();
> 
> Object o = bob2.getField("test1"); // This call failed with "Invalid flag 
> value: -2"
> {noformat}



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

[jira] [Assigned] (IGNITE-4917) BinaryObjectBuilder field value access failed if its serialized with optimal marshaller

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov reassigned IGNITE-4917:


Assignee: Andrew Mashenkov

> BinaryObjectBuilder field value access failed if its serialized with optimal 
> marshaller
> ---
>
> Key: IGNITE-4917
> URL: https://issues.apache.org/jira/browse/IGNITE-4917
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
> Fix For: 2.0
>
>
> Repro:
> {noformat}
> BinaryObjectBuilder bob = ignite.binary().builder("test");
> bob.setField("test1", new BigInteger("123456789"), BigInteger.class);
>
> BinaryObjectBuilder bob2 = bob.build().toBuilder();
> 
> Object o = bob2.getField("test1"); // This call failed with "Invalid flag 
> value: -2"
> {noformat}



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

[jira] [Commented] (IGNITE-4915) Remove deprecated methods at the public API

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4915:


GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-4915 Remove deprecated methods at the public API



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

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

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

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


commit 723bf2e2a1b0d5c52bb48d8a490189f6ac8f1d5d
Author: tledkov-gridgain 
Date:   2017-04-05T09:35:16Z

IGNITE-4915: remove IgniteCluster.mapKeysToNodes

commit f346a1eecf62323fe7bb6715548cd9dabf2c486a
Author: tledkov-gridgain 
Date:   2017-04-05T10:29:21Z

IGNITE-4915: remove IgniteCache.randomEntry

commit 61bfd5fa16b0002dc9ca3d141a496d7ca07872b7
Author: tledkov-gridgain 
Date:   2017-04-05T11:07:30Z

IGNITE-4915: remove deprecated properties from IGFS configuration

commit ee72fb8d267acae0cea94fa0c2cbc3c58f9a0130
Author: tledkov-gridgain 
Date:   2017-04-05T11:22:32Z

IGNITE-4915: remove deprecated methods from IgfsPath




> Remove deprecated methods at the public API
> ---
>
> Key: IGNITE-4915
> URL: https://issues.apache.org/jira/browse/IGNITE-4915
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Affects Versions: 1.9
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> Methods to remove:
> - {{IgniteCluster.mapKeysToNodes}};
> - {{IgniteCache.randomEntry}};
> - {{FileSystemConfiguration}} properties;
> - {{IgfsPath}} methods.



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

[jira] [Commented] (IGNITE-4844) Get rid of cache async operations queue

[Konstantin Dudkov (JIRA)]

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

Konstantin Dudkov commented on IGNITE-4844:
---

completely removed queue (atomics & tx), [TC 
tests|http://ci.ignite.apache.org/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull%2F1657%2Fhead]

please review

> Get rid of cache async operations queue
> ---
>
> Key: IGNITE-4844
> URL: https://issues.apache.org/jira/browse/IGNITE-4844
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Konstantin Dudkov
> Fix For: 2.0
>
>
> Now all async cache operations are internally queued and executed 
> sequentially one by one (see for example GridDhtAtomicCache.asyncOp). Need 
> get rid of this queue.



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

[jira] [Updated] (IGNITE-4917) BinaryObjectBuilder field value access failed if its serialized with optimal marshaller

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4917:
-
Description: 
Repro:
{noformat}
BinaryObjectBuilder bob = ignite.binary().builder("test");

bob.setField("test1", new BigInteger("123456789"), BigInteger.class);
   
BinaryObjectBuilder bob2 = bob.build().toBuilder();

Object o = bob2.getField("test1"); // This call failed with "Invalid flag 
value: -2"
{noformat}

> BinaryObjectBuilder field value access failed if its serialized with optimal 
> marshaller
> ---
>
> Key: IGNITE-4917
> URL: https://issues.apache.org/jira/browse/IGNITE-4917
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Reporter: Andrew Mashenkov
> Fix For: 2.0
>
>
> Repro:
> {noformat}
> BinaryObjectBuilder bob = ignite.binary().builder("test");
> bob.setField("test1", new BigInteger("123456789"), BigInteger.class);
>
> BinaryObjectBuilder bob2 = bob.build().toBuilder();
> 
> Object o = bob2.getField("test1"); // This call failed with "Invalid flag 
> value: -2"
> {noformat}



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

[jira] [Updated] (IGNITE-4917) BinaryObjectBuilder field value access failed if its serialized with optimal marshaller

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4917:
-
Fix Version/s: 2.0

> BinaryObjectBuilder field value access failed if its serialized with optimal 
> marshaller
> ---
>
> Key: IGNITE-4917
> URL: https://issues.apache.org/jira/browse/IGNITE-4917
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Reporter: Andrew Mashenkov
> Fix For: 2.0
>
>
> Repro:
> {noformat}
> BinaryObjectBuilder bob = ignite.binary().builder("test");
> bob.setField("test1", new BigInteger("123456789"), BigInteger.class);
>
> BinaryObjectBuilder bob2 = bob.build().toBuilder();
> 
> Object o = bob2.getField("test1"); // This call failed with "Invalid flag 
> value: -2"
> {noformat}



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

[jira] [Created] (IGNITE-4917) BinaryObjectBuilder field value access failed if its serialized with optimal marshaller

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-4917:


 Summary: BinaryObjectBuilder field value access failed if its 
serialized with optimal marshaller
 Key: IGNITE-4917
 URL: https://issues.apache.org/jira/browse/IGNITE-4917
 Project: Ignite
  Issue Type: Bug
  Components: binary
Reporter: Andrew Mashenkov






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

[jira] [Assigned] (IGNITE-4899) .NET: Review Dictionary usage in APIs

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-4899:
--

Assignee: Pavel Tupitsyn

> .NET: Review Dictionary usage in APIs
> -
>
> Key: IGNITE-4899
> URL: https://issues.apache.org/jira/browse/IGNITE-4899
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, breaking-api
> Fix For: 2.0
>
>
> We have replaced {{IDictionary}} with {{IEnumerable>}} 
> in {{ICacheStore}}, let's do the same for other APIs like {{ICache.GetAll}}.
> Reading GetAll results into a dictionary is inefficient in case when user 
> only needs to iterate over results (unneeded allocation and hashing).



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

[jira] [Updated] (IGNITE-4915) Remove deprecated methods at the public API

[Taras Ledkov (JIRA)]

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

Taras Ledkov updated IGNITE-4915:
-
Description: 
Methods to remove:
- {{IgniteCluster.mapKeysToNodes}};
- {{IgniteCache.randomEntry}};
- {{FileSystemConfiguration}} properties;
- {{IgfsPath}} methods.

  was:
Methods to remove:
- {{IgniteCluster.mapKeysToNodes}};
- {{IgniteCache.randomEntry}}



> Remove deprecated methods at the public API
> ---
>
> Key: IGNITE-4915
> URL: https://issues.apache.org/jira/browse/IGNITE-4915
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Affects Versions: 1.9
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> Methods to remove:
> - {{IgniteCluster.mapKeysToNodes}};
> - {{IgniteCache.randomEntry}};
> - {{FileSystemConfiguration}} properties;
> - {{IgfsPath}} methods.



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

[jira] [Commented] (IGNITE-4885) .NET: Meaningless exception on generic type in BinaryConfiguration

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4885:


* Open generics and abstract types are disallowed
* Exception propagation fixed to preserve original stack trace

> .NET: Meaningless exception on generic type in BinaryConfiguration
> --
>
> Key: IGNITE-4885
> URL: https://issues.apache.org/jira/browse/IGNITE-4885
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> {{BinaryTypeConfiguration}} does not support open generic types (when 
> parameters are not specified, like {{typeof(List<>)}} instead of 
> {{typeof(List}}). But the exception is not helpful, and stack trace is 
> very short (because of native transition).
> We should try to provide meaningful exception message and a proper stack 
> trace.



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

[jira] [Issue Comment Deleted] (IGNITE-3682) GridFunc: move all inner anonymous classes to separate top-level classes.

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-3682:
---
Comment: was deleted

(was: [The latest 
ci.tests|http://ci.ignite.apache.org/viewLog.html?buildId=530728])

> GridFunc: move all inner anonymous classes to separate top-level classes.
> -
>
> Key: IGNITE-3682
> URL: https://issues.apache.org/jira/browse/IGNITE-3682
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vyacheslav Daradur
>  Labels: important
> Fix For: 2.0
>
>
> Otherwise almost any change to class {{GridFunc}} will lead to serialization 
> issues because we have no control over inner class names.
> E.g. if removed single anonymous class, another anonymous class might change 
> it's name from {{GridFunc$4}} to {{GridFunc$3}}.



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

[jira] [Commented] (IGNITE-3682) GridFunc: move all inner anonymous classes to separate top-level classes.

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur commented on IGNITE-3682:


[The latest ci.tests|http://ci.ignite.apache.org/viewLog.html?buildId=530728]

> GridFunc: move all inner anonymous classes to separate top-level classes.
> -
>
> Key: IGNITE-3682
> URL: https://issues.apache.org/jira/browse/IGNITE-3682
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vyacheslav Daradur
>  Labels: important
> Fix For: 2.0
>
>
> Otherwise almost any change to class {{GridFunc}} will lead to serialization 
> issues because we have no control over inner class names.
> E.g. if removed single anonymous class, another anonymous class might change 
> it's name from {{GridFunc$4}} to {{GridFunc$3}}.



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

[jira] [Resolved] (IGNITE-4913) Update yardstick properties files

[Oleg Ostanin (JIRA)]

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

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

> Update yardstick properties files
> -
>
> Key: IGNITE-4913
> URL: https://issues.apache.org/jira/browse/IGNITE-4913
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 1.9
>Reporter: Ilya Suntsov
>Assignee: Oleg Ostanin
> Fix For: 2.0
>
>
> Need to add *ver* parameter in all properties files from yardstick/config.
> Example:
> {noformat}
> #Ignite version
> ver="RELEASE-"
> 
> CONFIGS="\
> -cfg ${SCRIPT_DIR}/../config/ignite-multicast-config.xml -nn ${nodesNum} -b 
> ${b} -w ${w} -d ${d} -t ${t} -sm ${sm} -dn IgnitePutBenchmark -sn IgniteNode 
> -ds ${ver}atomic-put-${b}-backup,\
> ...
> {noformat}



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

[jira] [Commented] (IGNITE-4913) Update yardstick properties files

[Oleg Ostanin (JIRA)]

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

Oleg Ostanin commented on IGNITE-4913:
--

Done.

> Update yardstick properties files
> -
>
> Key: IGNITE-4913
> URL: https://issues.apache.org/jira/browse/IGNITE-4913
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 1.9
>Reporter: Ilya Suntsov
>Assignee: Oleg Ostanin
> Fix For: 2.0
>
>
> Need to add *ver* parameter in all properties files from yardstick/config.
> Example:
> {noformat}
> #Ignite version
> ver="RELEASE-"
> 
> CONFIGS="\
> -cfg ${SCRIPT_DIR}/../config/ignite-multicast-config.xml -nn ${nodesNum} -b 
> ${b} -w ${w} -d ${d} -t ${t} -sm ${sm} -dn IgnitePutBenchmark -sn IgniteNode 
> -ds ${ver}atomic-put-${b}-backup,\
> ...
> {noformat}



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

[jira] [Updated] (IGNITE-1084) [Test] HibernateL2CacheSelfTest#testNaturalIdCache() is broken

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-1084:
-
Issue Type: Sub-task  (was: Test)
Parent: IGNITE-4916

> [Test] HibernateL2CacheSelfTest#testNaturalIdCache() is broken
> --
>
> Key: IGNITE-1084
> URL: https://issues.apache.org/jira/browse/IGNITE-1084
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Reporter: Sergey Evdokimov
>Assignee: Milap Wadhwa
>Priority: Minor
>  Labels: Muted_test
>
> Test HibernateL2CacheSelfTest#testNaturalIdCache() should be unmuted and 
> fixed.



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

[jira] [Updated] (IGNITE-2345) Implement JPA-based store session listener

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-2345:
-
Issue Type: Sub-task  (was: Improvement)
Parent: IGNITE-4916

> Implement JPA-based store session listener
> --
>
> Key: IGNITE-2345
> URL: https://issues.apache.org/jira/browse/IGNITE-2345
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Reporter: Valentin Kulichenko
> Fix For: 2.0
>
>
> We already have JDBC, Spring and Hibernate-based listeners, but it would be 
> useful to have JPA-based implementation as well.



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

[jira] [Updated] (IGNITE-2196) Broken links in the documentation

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-2196:
-
Issue Type: Sub-task  (was: Task)
Parent: IGNITE-4916

> Broken links in the documentation 
> --
>
> Key: IGNITE-2196
> URL: https://issues.apache.org/jira/browse/IGNITE-2196
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation
>Affects Versions: 1.5.0.final
> Environment: Apache Ignite 1.5.0-final build #45
>Reporter: Vasilisa  Sidorova
> Fix For: 2.0
>
>
> There is two broken links in the binary package documentation:
> # IGNITE_HOME/docs/javadoc/org/apache/ignite/cache/store/CacheStore.html 
> (click on the CacheHibarnateBlobStore link -> go to nonexistent page 
> IGNITE_HOME/docs/javadoc/org/apache/ignite/cache/store/hibernate/CacheHibernateBlobStore.html)
> # 
> IGNITE_HOME/docs/javadoc/org/apache/ignite/cache/store/CacheStoreSessionListener.html
>  (click on the CacheHibernateStoreSessionListener link -> go to nonexistent 
> page 
> IGNITE_HOME/docs/javadoc/org/apache/ignite/cache/store/hibernate/CacheHibernateStoreSessionListener.html)
> Please, fix it



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

[jira] [Updated] (IGNITE-3715) Incorrect Hibernate L2 cache statistics

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-3715:
-
Issue Type: Sub-task  (was: Bug)
Parent: IGNITE-4916

> Incorrect Hibernate L2 cache statistics
> ---
>
> Key: IGNITE-3715
> URL: https://issues.apache.org/jira/browse/IGNITE-3715
> Project: Ignite
>  Issue Type: Sub-task
>  Components: Hibernate L2 cache
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Priority: Minor
>
> These methods on {{SecondLevelCacheStatistics}} return incorrect data:
> * {{getElementCountInMemory()}} - returns only local node's cache size (zero 
> on client), not the global cache size.
> * {{getEntries()}} - always returns empty map, even if there is data in cache.



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

[jira] [Updated] (IGNITE-4760) Hibernate L2 cache stores value in wrong cache

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4760:
-
Issue Type: Sub-task  (was: Bug)
Parent: IGNITE-4916

> Hibernate L2 cache stores value in wrong cache
> --
>
> Key: IGNITE-4760
> URL: https://issues.apache.org/jira/browse/IGNITE-4760
> Project: Ignite
>  Issue Type: Sub-task
>  Components: Hibernate L2 cache
>Reporter: Semen Boikov
>Assignee: Vadim Opolski
> Fix For: 2.0
>
>
> Issue is reported here:
> http://apache-ignite-developers.2346864.n4.nabble.com/issue-with-Hibernate-2L-cache-region-factory-ignite-1-8-td14912.html
> First it is necessary add JUnit test reproducing issue (see existing tests in 
> IgniteHibernateTestSuite).
> Currently Hibernate access strategies track updates using thread locals, and 
> it looks like updates for different caches can be mixed. I think per-cache 
> thread local can fix issue for HibernateNonStrictAccessStrategy, but 
> per-cache thread local can not be used for HibernateReadWriteAccessStrategy, 
> since it is assumed that all updates should be part of the same cross-cache 
> ignite transaction.
> So possible fix:
> - use per-cache thread local for HibernateNonStrictAccessStrategy (or somehow 
> track target cache in HibernateNonStrictAccessStrategy)
> - use single thread local for HibernateReadWriteAccessStrategy



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

[jira] [Updated] (IGNITE-4915) Remove deprecated methods at the public API

[Taras Ledkov (JIRA)]

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

Taras Ledkov updated IGNITE-4915:
-
Description: 
Methods to remove:
- {{IgniteCluster.mapKeysToNodes}};
- {{IgniteCache.randomEntry}}


  was:
Methods to remove:
- {{IgniteCluster.mapKeysToNodes}};



> Remove deprecated methods at the public API
> ---
>
> Key: IGNITE-4915
> URL: https://issues.apache.org/jira/browse/IGNITE-4915
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Affects Versions: 1.9
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> Methods to remove:
> - {{IgniteCluster.mapKeysToNodes}};
> - {{IgniteCache.randomEntry}}



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

[jira] [Updated] (IGNITE-3603) Hibernate L2 cache should be able to create caches automatically

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-3603:
-
Issue Type: Sub-task  (was: Improvement)
Parent: IGNITE-4916

> Hibernate L2 cache should be able to create caches automatically
> 
>
> Key: IGNITE-3603
> URL: https://issues.apache.org/jira/browse/IGNITE-3603
> Project: Ignite
>  Issue Type: Sub-task
>  Components: Hibernate L2 cache
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
> Fix For: 2.0
>
>
> Hibernate L2 cache is typically configured using annotations, like this:
> {code}
> @Cache(usage = CacheConcurrencyStrategy.READ_ONLY, region = "userType")
> {code}
> Currently we require user to explicitly configure {{userType}} cache, but we 
> can avoid this and create caches automatically.
> Atomicity mode should be chosen based on concurrency strategy, all other 
> settings should be default.



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

[jira] [Updated] (IGNITE-1794) Ignite should support Hibernate 5

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-1794:
-
Issue Type: Sub-task  (was: Task)
Parent: IGNITE-4916

> Ignite should support Hibernate 5
> -
>
> Key: IGNITE-1794
> URL: https://issues.apache.org/jira/browse/IGNITE-1794
> Project: Ignite
>  Issue Type: Sub-task
>  Components: Hibernate L2 cache
>Reporter: Artem Shutak
>Assignee: Vadim Opolski
>  Labels: important, newbie
> Fix For: 2.0
>
> Attachments: HibernateCollectionRegionForIgnite.java, 
> HibernateEntityRegionForIgnite.java, HibernateRegionFactoryForIgnite.java, 
> HibernateTimestampsRegionForIgnite.java
>
>
> Currently Ignite supports Hibernate 4. 
> In Hibernate 5 org.hibernate.cache.spi.RegionFactory.start() method signature 
> has been changed from
> {{void start(Settings var1, Properties var2) throws CacheException;}}
> on
> {{void start(SessionFactoryOptions settings, Properties properties) throws 
> CacheException;}}
> Original user list: 
> http://apache-ignite-users.70518.x6.nabble.com/Hibernate-5-L2-Cache-Compatibility-td1656.html



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

[jira] [Updated] (IGNITE-3429) org.hibernate.cache.spi.CacheKey not properly serialized by binary marshaller

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-3429:
-
Issue Type: Sub-task  (was: Bug)
Parent: IGNITE-4916

> org.hibernate.cache.spi.CacheKey not properly serialized by binary marshaller
> -
>
> Key: IGNITE-3429
> URL: https://issues.apache.org/jira/browse/IGNITE-3429
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache, Hibernate L2 cache
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Assignee: Andrew Mashenkov
> Fix For: 2.0
>
>
> {{org.hibernate.cache.spi.CacheKey}} is a class used as a key for all entries 
> in the Hibernate L2 cache. This class contains {{type}} field and custom 
> {{equals}} logic where the type is used as a helper and does not participate 
> in comparison. Instances of the same type are producing different hash codes 
> in different JVMs, which actually breaks comparison when binary format is 
> used, where byte arrays are compared.
> The issue is described in more detail here: 
> http://stackoverflow.com/questions/38132263/apache-ignite-as-hibernate-l2-cache-storing-duplicate-entities



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

[jira] [Created] (IGNITE-4916) Hibernate support improvement

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-4916:


 Summary: Hibernate support improvement
 Key: IGNITE-4916
 URL: https://issues.apache.org/jira/browse/IGNITE-4916
 Project: Ignite
  Issue Type: Task
  Components: Hibernate L2 cache
Reporter: Andrew Mashenkov
 Fix For: 2.1






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

[jira] [Assigned] (IGNITE-4913) Update yardstick properties files

[Oleg Ostanin (JIRA)]

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

Oleg Ostanin reassigned IGNITE-4913:


Assignee: Oleg Ostanin

> Update yardstick properties files
> -
>
> Key: IGNITE-4913
> URL: https://issues.apache.org/jira/browse/IGNITE-4913
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 1.9
>Reporter: Ilya Suntsov
>Assignee: Oleg Ostanin
> Fix For: 2.0
>
>
> Need to add *ver* parameter in all properties files from yardstick/config.
> Example:
> {noformat}
> #Ignite version
> ver="RELEASE-"
> 
> CONFIGS="\
> -cfg ${SCRIPT_DIR}/../config/ignite-multicast-config.xml -nn ${nodesNum} -b 
> ${b} -w ${w} -d ${d} -t ${t} -sm ${sm} -dn IgnitePutBenchmark -sn IgniteNode 
> -ds ${ver}atomic-put-${b}-backup,\
> ...
> {noformat}



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

[jira] [Updated] (IGNITE-4915) Remove deprecated methods at the public API

[Taras Ledkov (JIRA)]

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

Taras Ledkov updated IGNITE-4915:
-
Description: 
Methods to remove:
- {{IgniteCluster.mapKeysToNodes}};


> Remove deprecated methods at the public API
> ---
>
> Key: IGNITE-4915
> URL: https://issues.apache.org/jira/browse/IGNITE-4915
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Affects Versions: 1.9
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> Methods to remove:
> - {{IgniteCluster.mapKeysToNodes}};



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

[jira] [Created] (IGNITE-4915) Remove deprecated methods at the public API

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-4915:


 Summary: Remove deprecated methods at the public API
 Key: IGNITE-4915
 URL: https://issues.apache.org/jira/browse/IGNITE-4915
 Project: Ignite
  Issue Type: Sub-task
  Components: general
Affects Versions: 1.9
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.0






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

[jira] [Commented] (IGNITE-4906) .NET: Examples tests hang

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4906:


There is a bug on Java side in dynamic registration engine, IGNITE-4914 
created. Waiting for the fix.

> .NET: Examples tests hang
> -
>
> Key: IGNITE-4906
> URL: https://issues.apache.org/jira/browse/IGNITE-4906
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> {{ExamplesTest}} hangs on various stages: 
> http://195.239.208.174/viewType.html?buildTypeId=IgniteTests_IgnitePlatformNetLongRunnin
> Logs show many multicast-related exceptions. We should probably avoid 
> multicast in tests.



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

[jira] [Commented] (IGNITE-4839) Remove CacheTypeMetadata

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4839:


Github user asfgit closed the pull request at:

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


> Remove CacheTypeMetadata
> 
>
> Key: IGNITE-4839
> URL: https://issues.apache.org/jira/browse/IGNITE-4839
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Affects Versions: 1.9
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>




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

[jira] [Assigned] (IGNITE-4914) Dynamic type registration hangs for platformId > 0 on node restart

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov reassigned IGNITE-4914:
---

Assignee: Sergey Chugunov

> Dynamic type registration hangs for platformId > 0 on node restart
> --
>
> Key: IGNITE-4914
> URL: https://issues.apache.org/jira/browse/IGNITE-4914
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Sergey Chugunov
> Fix For: 2.0
>
>
> {{MarshallerContextImpl.registerClassName}} hangs when called after node 
> restart:
> * Start two nodes, A and B
> * Call {{registerClassName}} with {{platformId = 1}} and any class name from 
> node B
> * Stop node B
> * Start node B again
> * Call {{registerClassName}} with {{platformId = 1}} and any class name from 
> node B
> The last call hangs.



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

[jira] [Commented] (IGNITE-4667) Throw exception on starting client cache when indexed types cannot be loaded

[Semen Boikov (JIRA)]

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

Semen Boikov commented on IGNITE-4667:
--

Hi Dmitry,

Reviewed your changes, have some comments:
- please add more tests so that all cache modes are tested: 
transactional/atomic + near cache enabled/disabled
- I think you need catch/handle cache init exception on more higher level - 
inside CacheAffinitySharedManager.onCacheChangeRequest (prepareCacheStart can 
finish without errors, but after this initAffinity can fail)
- also I think it is better to finish cache statr futures in single place, now 
this is done in GridCacheProcessor.onExchangeDone, let's just change it to 
finish future with error if 'err' != null 

Thanks!

> Throw exception on starting client cache when indexed types cannot be loaded
> 
>
> Key: IGNITE-4667
> URL: https://issues.apache.org/jira/browse/IGNITE-4667
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
> Fix For: 2.0
>
>
> Assume following situation:
> 1. Server node configured cache indexed types with classes that client node 
> doesn't have.
> 2. Start server.
> 3. Start client. Client successfully connected.
> 4. Try to get cache on client node.
> 5. Was thrown exception in GridQueryProcessor and request for cache on client 
> node hangs forever.
> If on some reason cache couldn't be initialized, exception must be thrown on 
> Ignite.cache() operation.



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

[jira] [Created] (IGNITE-4914) Dynamic type registration hangs for platformId > 0 on node restart

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4914:
--

 Summary: Dynamic type registration hangs for platformId > 0 on 
node restart
 Key: IGNITE-4914
 URL: https://issues.apache.org/jira/browse/IGNITE-4914
 Project: Ignite
  Issue Type: Bug
  Components: binary
Affects Versions: 2.0
Reporter: Pavel Tupitsyn
 Fix For: 2.0


{{MarshallerContextImpl.registerClassName}} hangs when called after node 
restart:

* Start two nodes, A and B
* Call {{registerClassName}} with {{platformId = 1}} and any class name from 
node B
* Stop node B
* Start node B again
* Call {{registerClassName}} with {{platformId = 1}} and any class name from 
node B

The last call hangs.



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

[jira] [Commented] (IGNITE-4534) Implement offheap eviction policies based on page memory

[Semen Boikov (JIRA)]

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

Semen Boikov commented on IGNITE-4534:
--

Ivan,

I'm reviewing your changes, meanwhile I want to know if you tested evictions 
impact on performance:
- did you compare performance before/after your changes when eviction is 
disabled?
- did you compare performance eviction enabled vs eviction disabled?

Thanks

> Implement offheap eviction policies based on page memory
> 
>
> Key: IGNITE-4534
> URL: https://issues.apache.org/jira/browse/IGNITE-4534
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Ivan Rakov
>  Labels: important
> Fix For: 2.0
>
>
> Since the internal structure of offheap storage has changed, we need to 
> re-implement Fifo, Lru and Sorted eviction policies



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

[jira] [Updated] (IGNITE-4477) Fix IgniteFuture.listen() and IgniteFuture.chain() semantics

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4477:

Labels: important  (was: )

> Fix IgniteFuture.listen() and IgniteFuture.chain() semantics
> 
>
> Key: IGNITE-4477
> URL: https://issues.apache.org/jira/browse/IGNITE-4477
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Dmitry Karachentsev
>  Labels: important
> Fix For: 2.0
>
>
> *Problem*
> We allow users to pass continuations to {{IgniteFuture}} which will be 
> executed on future completion. This can be done through {{listen}} or 
> {{chain}} methods.
> However, continuation semantics is broken intrinsically:
> 1) If future is already completed, user code executed in the same thread;
> 2) If future is not completed yet, it will be executed in completion thread.
> Neither of this options are valid because it easily leads to starvation. E.g.:
> {code}
> IgniteFuture fut = cache.getAsync(key2);
> fut.listen(fut0 -> {
>  cache.put(key2, val2); // Possible deadlock, because invoked in sys pool;
> });
> {code}
> *Solution*
> 1) By default callbacks must be executed asynchronously in some common pool 
> (public pool? new "callback pool"? FJP?)
> 2) It should be possible to specify where to execute a callback explicitly:
> {code}
> IgniteFuture.listen(IgniteClosure, ExecutorService);
> {code}
> 3) We may want to expose our public pool on API for convenience.



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

[jira] [Created] (IGNITE-4913) Update yardstick properties files

[Ilya Suntsov (JIRA)]

Ilya Suntsov created IGNITE-4913:


 Summary: Update yardstick properties files
 Key: IGNITE-4913
 URL: https://issues.apache.org/jira/browse/IGNITE-4913
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 1.9
Reporter: Ilya Suntsov
 Fix For: 2.0


Need to add *ver* parameter in all properties files from yardstick/config.
Example:
{noformat}
#Ignite version
ver="RELEASE-"

CONFIGS="\
-cfg ${SCRIPT_DIR}/../config/ignite-multicast-config.xml -nn ${nodesNum} -b 
${b} -w ${w} -d ${d} -t ${t} -sm ${sm} -dn IgnitePutBenchmark -sn IgniteNode 
-ds ${ver}atomic-put-${b}-backup,\
...
{noformat}



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

[jira] [Commented] (IGNITE-4856) .NET: StopAll on AppDomain unload

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4856:


* {{Ignition.StopAll}} on domain unload implemented
* {{IgniteConfiguration.AutoGenerateIgniteInstanceName}} added

Checked with IIS & ASP.NET, user has to specify 
{{AutoGenerateIgniteInstanceName}} in config and can work without any issues 
after that.

[~vozerov] please have a look.

> .NET: StopAll on AppDomain unload
> -
>
> Key: IGNITE-4856
> URL: https://issues.apache.org/jira/browse/IGNITE-4856
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> In certain scenarios .NET {{AppDomain}} can be unloaded and started again. 
> Java part of Ignite continues to run, but .NET part (including Ignite 
> instances) is lost. User can no longer work with started nodes, .NET callback 
> pointers are lost, etc.
> 1) Track AppDomain unload and stop all Ignite instances.
> 2) When starting Ignite, wait for node with specified name to stop.
> 3) Make it possible to auto-generate a unique grid name automatically? This 
> may be useful in app.config.
> IIS issues example: 
> http://stackoverflow.com/questions/42961879/how-do-i-retrieve-a-started-ignite-instance-when-a-website-restart-occurs-in-iis/42968183#42968183



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

[jira] [Commented] (IGNITE-4856) .NET: StopAll on AppDomain unload

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4856:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-4856 .NET: StopAll on AppDomain unload



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

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

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

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


commit c3431e901678ea1520bfc647b935e7d425b839d4
Author: Igor Sapego 
Date:   2017-04-04T16:07:49Z

IGNITE-3583: Replaced passing by value with passing by reference

commit 0ef9046373846b7f79ced81468ff461172c44995
Author: Pavel Tupitsyn 
Date:   2017-04-05T08:00:20Z

IGNITE-4856 .NET: StopAll on AppDomain unload




> .NET: StopAll on AppDomain unload
> -
>
> Key: IGNITE-4856
> URL: https://issues.apache.org/jira/browse/IGNITE-4856
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> In certain scenarios .NET {{AppDomain}} can be unloaded and started again. 
> Java part of Ignite continues to run, but .NET part (including Ignite 
> instances) is lost. User can no longer work with started nodes, .NET callback 
> pointers are lost, etc.
> 1) Track AppDomain unload and stop all Ignite instances.
> 2) When starting Ignite, wait for node with specified name to stop.
> 3) Make it possible to auto-generate a unique grid name automatically? This 
> may be useful in app.config.
> IIS issues example: 
> http://stackoverflow.com/questions/42961879/how-do-i-retrieve-a-started-ignite-instance-when-a-website-restart-occurs-in-iis/42968183#42968183



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

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

[Konstantin Dudkov (JIRA)]

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

Konstantin Dudkov commented on IGNITE-4571:
---

Benchmarks result:

|| ||ignite-4571 rev: 3cba6132||master rev: 5d5ba5cf||delta||
|atomic-get|255475|254156|0.52%|
|atomic-get-offheap|231666|235187|-1.52%|
|atomic-get-offheap-val|251440|249509|0.77%|
|atomic-put|133599|135137|-1.15%|
|atomic-put-get|79732.6|81905.1|-2.72%|
|atomic-put-get-offheap|70188.8|70497.9|-0.44%|
|atomic-put-get-offheap-val|81702.8|81751.8|-0.06%|
|atomic-put-offheap|111749|111920|-0.15%|
|atomic-put-offheap-val|137316|137747|-0.31%|


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



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

[jira] [Commented] (IGNITE-3682) GridFunc: move all inner anonymous classes to separate top-level classes.

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur commented on IGNITE-3682:


[~agura]
bq. GridFunc.as method should be removed because this method doesn't have any 
usages.
This removal was the reason.

Sorry about that.
I was hoping at ci.tests.

I've fixed it. 
([ci.tests|http://ci.ignite.apache.org/viewLog.html?buildId=530449])

> GridFunc: move all inner anonymous classes to separate top-level classes.
> -
>
> Key: IGNITE-3682
> URL: https://issues.apache.org/jira/browse/IGNITE-3682
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vyacheslav Daradur
>  Labels: important
> Fix For: 2.0
>
>
> Otherwise almost any change to class {{GridFunc}} will lead to serialization 
> issues because we have no control over inner class names.
> E.g. if removed single anonymous class, another anonymous class might change 
> it's name from {{GridFunc$4}} to {{GridFunc$3}}.



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

[jira] [Created] (IGNITE-4912) Fix testDeployCalledAfterCacheStart and testDeployCalledBeforeCacheStart tests

[Dmitry Karachentsev (JIRA)]

Dmitry Karachentsev created IGNITE-4912:
---

 Summary: Fix testDeployCalledAfterCacheStart and 
testDeployCalledBeforeCacheStart tests
 Key: IGNITE-4912
 URL: https://issues.apache.org/jira/browse/IGNITE-4912
 Project: Ignite
  Issue Type: Sub-task
Reporter: Dmitry Karachentsev
Assignee: Dmitry Karachentsev


IgniteServiceDynamicCachesSelfTest.testDeployCalledAfterCacheStart
IgniteServiceDynamicCachesSelfTest.testDeployCalledBeforeCacheStart



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

[jira] [Created] (IGNITE-4911) Fix tests #1

[Dmitry Karachentsev (JIRA)]

Dmitry Karachentsev created IGNITE-4911:
---

 Summary: Fix tests #1
 Key: IGNITE-4911
 URL: https://issues.apache.org/jira/browse/IGNITE-4911
 Project: Ignite
  Issue Type: Bug
  Components: cache, general
Reporter: Dmitry Karachentsev
Assignee: Dmitry Karachentsev


Test that constantly failing:
IgniteServiceDynamicCachesSelfTest.testDeployCalledAfterCacheStart
IgniteServiceDynamicCachesSelfTest.testDeployCalledBeforeCacheStart

IgniteCachePeekModesAbstractTest.testNonLocalPartitionSize

GridCacheDeploymentOffHeapValuesSelfTest.testDeployment

GridCacheAtomicPrimaryWriteOrderNearRemoveFailureTest.testPutAndRemove
TcpDiscoveryNodeAttributesUpdateOnReconnectTest.testReconnect



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