[jira] [Created] (IGNITE-4749) Advanced testing of Kubernetes IP finder

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4749:
---

 Summary: Advanced testing of Kubernetes IP finder
 Key: IGNITE-4749
 URL: https://issues.apache.org/jira/browse/IGNITE-4749
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda


Test coverage of Kubernetes IP finder has to be extended. We need to find a way 
on how to start a Kubernetes single node cluster as a part of unit tests and 
check the following:
- Ignite pods are able to discover each other.
- The cluster can be scaled out or scaled in using standard Kubernetes API.



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

[jira] [Commented] (IGNITE-4161) Discovery SPI for nodes that will connect to Ignite Kubernetes cluster from outside

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-4161:
-

In general, we might not need to develop one more IP finder for the nodes 
connecting outside of Kubernetes if the following works out:

* Set hostNetwork=true in Ignite pod's YAML configuration so that the nodes 
that will be connecting from outside can establish TCP/IP connections with 
containerized Ignite nodes (pods).
* Use the same TcpDiscoveryKubernetesIpFinder for the nodes that will be 
outside of Kubernetes environment.

Needs to be checked in a Kubernetes on-premise or cloud environment.

> Discovery SPI for nodes that will connect to Ignite Kubernetes cluster from 
> outside
> ---
>
> Key: IGNITE-4161
> URL: https://issues.apache.org/jira/browse/IGNITE-4161
> Project: Ignite
>  Issue Type: Sub-task
>Affects Versions: 2.0
>Reporter: Denis Magda
> Fix For: 2.0
>
>
> Ignite cluster can be considered as a set of Kubernetes pods of a similar 
> type that are scaled across available hardware. To get access to the cluster 
> from outside the one has to use Kubernetes Service that will expose a single 
> public API address for the whole Ignite Cluster. 
> Let's think over how an Ignite client can connect to the Ignite's Kubernetes 
> cluster from outside, look up nodes and interact with them. As a result, most 
> likely we will implement a special discovery SPI for such "outside" nodes 
> that will connect to Kubernetes Service before the joining process.



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

[jira] [Commented] (IGNITE-4162) Step-by-step guidance on how to start and use Ignite cluster with Kubernetes

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-4162:
-

[~pgarg], please review and edit these two new pages:
https://apacheignite-mix.readme.io/docs/kubernetes-discovery
https://apacheignite.readme.io/docs/kubernetes-deployment

> Step-by-step guidance on how to start and use Ignite cluster with Kubernetes
> 
>
> Key: IGNITE-4162
> URL: https://issues.apache.org/jira/browse/IGNITE-4162
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 1.9
>
>
> At the end, we have to prepare a step-by-step guidance on how to:
> - configure, launch and scale Ignite cluster.
> - how to connect and work with this cluster from applications running inside 
> and outside of Kubernetes.
> Refer to existed guidance prepared for other products:
> 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 message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-4162) Step-by-step guidance on how to start and use Ignite cluster with Kubernetes

[Denis Magda (JIRA)]

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

Denis Magda reassigned IGNITE-4162:
---

Assignee: Prachi Garg  (was: Denis Magda)

> Step-by-step guidance on how to start and use Ignite cluster with Kubernetes
> 
>
> Key: IGNITE-4162
> URL: https://issues.apache.org/jira/browse/IGNITE-4162
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
> Fix For: 1.9
>
>
> At the end, we have to prepare a step-by-step guidance on how to:
> - configure, launch and scale Ignite cluster.
> - how to connect and work with this cluster from applications running inside 
> and outside of Kubernetes.
> Refer to existed guidance prepared for other products:
> 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 message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-1903) Cache configuration is serialized to nodes whether they require it or not

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-1903:

Summary: Cache configuration is serialized to nodes whether they require it 
or not  (was: CacheStore implementation is serialized to nodes whether they 
require it or not)

> Cache configuration is serialized to nodes whether they require it or not
> -
>
> Key: IGNITE-1903
> URL: https://issues.apache.org/jira/browse/IGNITE-1903
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Michael Griggs
>  Labels: community
> Fix For: 2.0
>
>
> See User discussion thread:  
> http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
> Brief summary:  When a grid client joins the grid (clientMode=true) it 
> receives a message from the server node(s) on the grid that contains the 
> serialized CacheStore implementation object.  If the client does not have 
> this class on its CLASSPATH (and there is no reason it should, as it is a 
> client) then the de-serialization of this message will fail, causing this 
> exception:
> {code}SEVERE: Failed to unmarshal discovery data for component: 1 
> class org.apache.ignite.IgniteCheckedException: Failed to find class with 
> given class loader for unmarshalling (make sure same versions of all classes 
> are available on all nodes or enable peer-class-loading): 
> sun.misc.Launcher$AppClassLoader@14dad5dc 
> at 
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
>  
> at 
> org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
>  
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) 
> Caused by: java.lang.ClassNotFoundException: 
> c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite
> {code}
> where {{c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}} is the CacheStore 
> implementation.
> The ostensible reason for the CacheStore serialization is so that clients of 
> a TRANSACTIONAL cache can begin the transaction on the underlying store.  
> The only current solution to this is to add the grid node's CacheStore 
> implementation class definition to the CLASSPATH of the client.  This creates 
> an *undesirable coupling* between server and client.
> ---
> *UPDATE (copy-paste from comment below)*
> This is actually more generic issue. When a new node joins (client or 
> server), all existing cache configurations (which include cache stores) are 
> sent to this node. It then deserializes it during startup which can cause 
> exceptions on clients or servers where cache is not supposed to be deployed 
> as defined by node filter.
> As a solution we can do the following:
> * During discovery, send node filter and cache store factory in binary format 
> along with the cache configuration, not as its parts.
> * On server, check node filter first and deserialize cache configuration and 
> cache store only if it returns true. In case of error, STOP join process (now 
> we just print exception in log and go on, which is very error-prone).
> * On client, do not deserialize cache configuration and cache store until 
> user's code tries to actually use the cache (calls Ignite.cache. If cache is 
> ATOMIC, never deserialize the cache store.



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

[jira] [Updated] (IGNITE-1903) CacheStore implementation is serialized to nodes whether they require it or not

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-1903:

Description: 
See User discussion thread:  
http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html

Brief summary:  When a grid client joins the grid (clientMode=true) it receives 
a message from the server node(s) on the grid that contains the serialized 
CacheStore implementation object.  If the client does not have this class on 
its CLASSPATH (and there is no reason it should, as it is a client) then the 
de-serialization of this message will fail, causing this exception:

{code}SEVERE: Failed to unmarshal discovery data for component: 1 
class org.apache.ignite.IgniteCheckedException: Failed to find class with given 
class loader for unmarshalling (make sure same versions of all classes are 
available on all nodes or enable peer-class-loading): 
sun.misc.Launcher$AppClassLoader@14dad5dc 
at 
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
 
at 
org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
 
at 
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
 
at 
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
 
at 
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
 
at 
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
 
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) 
Caused by: java.lang.ClassNotFoundException: 
c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite
{code}
where {{c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}} is the CacheStore 
implementation.

The ostensible reason for the CacheStore serialization is so that clients of a 
TRANSACTIONAL cache can begin the transaction on the underlying store.  

The only current solution to this is to add the grid node's CacheStore 
implementation class definition to the CLASSPATH of the client.  This creates 
an *undesirable coupling* between server and client.

---

*UPDATE (copy-paste from comment below)*

This is actually more generic issue. When a new node joins (client or server), 
all existing cache configurations (which include cache stores) are sent to this 
node. It then deserializes it during startup which can cause exceptions on 
clients or servers where cache is not supposed to be deployed as defined by 
node filter.

As a solution we can do the following:
* During discovery, send node filter and cache store factory in binary format 
along with the cache configuration, not as its parts.
* On server, check node filter first and deserialize cache configuration and 
cache store only if it returns true. In case of error, STOP join process (now 
we just print exception in log and go on, which is very error-prone).
* On client, do not deserialize cache configuration and cache store until 
user's code tries to actually use the cache (calls Ignite.cache. If cache is 
ATOMIC, never deserialize the cache store.

  was:
See User discussion thread:  
http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html

Brief summary:  When a grid client joins the grid (clientMode=true) it receives 
a message from the server node(s) on the grid that contains the serialized 
CacheStore implementation object.  If the client does not have this class on 
its CLASSPATH (and there is no reason it should, as it is a client) then the 
de-serialization of this message will fail, causing this exception:

{code}SEVERE: Failed to unmarshal discovery data for component: 1 
class org.apache.ignite.IgniteCheckedException: Failed to find class with given 
class loader for unmarshalling (make sure same versions of all classes are 
available on all nodes or enable peer-class-loading): 
sun.misc.Launcher$AppClassLoader@14dad5dc 
at 
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
 
at 
org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
 
at 
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
 
at 
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
 
at 
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
 
at 
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
 
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) 
Caused by: java.lang.ClassNotFoundException: 
c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite
{code}
where 

[jira] [Comment Edited] (IGNITE-533) Implement IgniteZeromqStreamer to stream data from ZeroMQ

[Roman Shtykh (JIRA)]

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

Roman Shtykh edited comment on IGNITE-533 at 2/23/17 3:06 AM:
--

[~dreamx] Maksim, can you please prepare a document with a sample code on how 
to use it, so that we can add it to 
https://apacheignite-mix.readme.io/docs/overview ? If you prepare a formatted 
text, I will add it to other streamers' docs.


was (Author: roman_s):
@dreamx Maksim, can you please prepare a document with a sample code on how to 
use it, so that we can add it to 
https://apacheignite-mix.readme.io/docs/overview ? If you prepare a formatted 
text, I will add it to other streamers' docs.

> Implement IgniteZeromqStreamer to stream data from ZeroMQ
> -
>
> Key: IGNITE-533
> URL: https://issues.apache.org/jira/browse/IGNITE-533
> Project: Ignite
>  Issue Type: Sub-task
>  Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Maksim Kozlov
> Fix For: 2.0
>
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under 
> high load. It was previously named {{IgniteDataLoader}}, see ticket 
> IGNITE-394.
> See [ZeroMQ|http://zeromq.org/] for more info.
> We should create {{IgniteZeroMqStreamer}} which will consume messages from 
> Twitter and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> * Convert ZeroMQ messages to Ignite data using an optional pluggable 
> converter. If not provided, we should have some default mechanism.
> * Specify the cache name for the Ignite cache to load data into.
> * Specify other flags available on {{IgniteDataStreamer}} class.



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

[jira] [Commented] (IGNITE-533) Implement IgniteZeromqStreamer to stream data from ZeroMQ

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-533:


[~dreamx], have you added the new test suite to TeamCity? We need to be sure 
that the test suite passes there as well.

Could you create a documentation for the streamer as well? I've created a 
hidden page and granted you editor's rights, check up your email:
https://apacheignite-mix.readme.io/docs/zeromq-streamer

You can refer to the documentations prepared for the other streamers to form an 
understanding on how ZeroMQ doc should look like.
https://apacheignite-mix.readme.io/docs/mqtt-streamer
https://apacheignite-mix.readme.io/docs/storm-streamer
https://apacheignite-mix.readme.io/docs/flink-streamer

> Implement IgniteZeromqStreamer to stream data from ZeroMQ
> -
>
> Key: IGNITE-533
> URL: https://issues.apache.org/jira/browse/IGNITE-533
> Project: Ignite
>  Issue Type: Sub-task
>  Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Maksim Kozlov
> Fix For: 2.0
>
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under 
> high load. It was previously named {{IgniteDataLoader}}, see ticket 
> IGNITE-394.
> See [ZeroMQ|http://zeromq.org/] for more info.
> We should create {{IgniteZeroMqStreamer}} which will consume messages from 
> Twitter and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> * Convert ZeroMQ messages to Ignite data using an optional pluggable 
> converter. If not provided, we should have some default mechanism.
> * Specify the cache name for the Ignite cache to load data into.
> * Specify other flags available on {{IgniteDataStreamer}} class.



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

[jira] [Comment Edited] (IGNITE-533) Implement IgniteZeromqStreamer to stream data from ZeroMQ

[Roman Shtykh (JIRA)]

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

Roman Shtykh edited comment on IGNITE-533 at 2/23/17 3:02 AM:
--

[~dreamx] Thanks for the contribution! Merged with tiny modifications in 
comments.

[~avinogradov] Anton, can the tests be added to TeamCity?


was (Author: roman_s):
[~dreamx] Thanks for the contribution! Merged with tiny modifications in 
comments.

[~avinogradov] Denis, can the tests be added to TeamCity?

> Implement IgniteZeromqStreamer to stream data from ZeroMQ
> -
>
> Key: IGNITE-533
> URL: https://issues.apache.org/jira/browse/IGNITE-533
> Project: Ignite
>  Issue Type: Sub-task
>  Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Maksim Kozlov
> Fix For: 2.0
>
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under 
> high load. It was previously named {{IgniteDataLoader}}, see ticket 
> IGNITE-394.
> See [ZeroMQ|http://zeromq.org/] for more info.
> We should create {{IgniteZeroMqStreamer}} which will consume messages from 
> Twitter and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> * Convert ZeroMQ messages to Ignite data using an optional pluggable 
> converter. If not provided, we should have some default mechanism.
> * Specify the cache name for the Ignite cache to load data into.
> * Specify other flags available on {{IgniteDataStreamer}} class.



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

[jira] [Updated] (IGNITE-533) Implement IgniteZeromqStreamer to stream data from ZeroMQ

[Roman Shtykh (JIRA)]

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

Roman Shtykh updated IGNITE-533:

Fix Version/s: 2.0

> Implement IgniteZeromqStreamer to stream data from ZeroMQ
> -
>
> Key: IGNITE-533
> URL: https://issues.apache.org/jira/browse/IGNITE-533
> Project: Ignite
>  Issue Type: Sub-task
>  Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Maksim Kozlov
> Fix For: 2.0
>
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under 
> high load. It was previously named {{IgniteDataLoader}}, see ticket 
> IGNITE-394.
> See [ZeroMQ|http://zeromq.org/] for more info.
> We should create {{IgniteZeroMqStreamer}} which will consume messages from 
> Twitter and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> * Convert ZeroMQ messages to Ignite data using an optional pluggable 
> converter. If not provided, we should have some default mechanism.
> * Specify the cache name for the Ignite cache to load data into.
> * Specify other flags available on {{IgniteDataStreamer}} class.



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

[jira] [Commented] (IGNITE-533) Implement IgniteZeromqStreamer to stream data from ZeroMQ

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-533:
---

Github user asfgit closed the pull request at:

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


> Implement IgniteZeromqStreamer to stream data from ZeroMQ
> -
>
> Key: IGNITE-533
> URL: https://issues.apache.org/jira/browse/IGNITE-533
> Project: Ignite
>  Issue Type: Sub-task
>  Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Maksim Kozlov
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under 
> high load. It was previously named {{IgniteDataLoader}}, see ticket 
> IGNITE-394.
> See [ZeroMQ|http://zeromq.org/] for more info.
> We should create {{IgniteZeroMqStreamer}} which will consume messages from 
> Twitter and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> * Convert ZeroMQ messages to Ignite data using an optional pluggable 
> converter. If not provided, we should have some default mechanism.
> * Specify the cache name for the Ignite cache to load data into.
> * Specify other flags available on {{IgniteDataStreamer}} class.



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

[jira] [Created] (IGNITE-4748) jdbc2.JdbcStatement does not implement setQueryTimeout method

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-4748:
---

 Summary: jdbc2.JdbcStatement does not implement setQueryTimeout 
method
 Key: IGNITE-4748
 URL: https://issues.apache.org/jira/browse/IGNITE-4748
 Project: Ignite
  Issue Type: Bug
  Components: jdbc-driver
Affects Versions: 1.8
Reporter: Valentin Kulichenko
Priority: Critical
 Fix For: 1.9


The method was implemented in the older version of JDBC driver, but was missed 
in the newer version (still throws exception).



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

[jira] [Assigned] (IGNITE-653) Add cache name to exception message

[Konstantin Boudnik (JIRA)]

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

Konstantin Boudnik reassigned IGNITE-653:
-

Assignee: Jeyhun Karimov

> Add cache name to exception message
> ---
>
> Key: IGNITE-653
> URL: https://issues.apache.org/jira/browse/IGNITE-653
> Project: Ignite
>  Issue Type: Task
>  Components: cache, UI
>Affects Versions: sprint-3
>Reporter: Pavel Konstantinov
>Assignee: Jeyhun Karimov
>Priority: Trivial
>
> {code}
> CacheServerNotFoundException: Failed to map keys for cache (all partition 
> nodes left the grid)
> {code}
> {code}
> ClusterTopologyServerNotFoundException: Failed to map keys for cache (all 
> partition nodes left the grid).
> {code}



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

[jira] [Commented] (IGNITE-653) Add cache name to exception message

[Konstantin Boudnik (JIRA)]

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

Konstantin Boudnik commented on IGNITE-653:
---

Done

> Add cache name to exception message
> ---
>
> Key: IGNITE-653
> URL: https://issues.apache.org/jira/browse/IGNITE-653
> Project: Ignite
>  Issue Type: Task
>  Components: cache, UI
>Affects Versions: sprint-3
>Reporter: Pavel Konstantinov
>Assignee: Jeyhun Karimov
>Priority: Trivial
>
> {code}
> CacheServerNotFoundException: Failed to map keys for cache (all partition 
> nodes left the grid)
> {code}
> {code}
> ClusterTopologyServerNotFoundException: Failed to map keys for cache (all 
> partition nodes left the grid).
> {code}



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

[jira] [Assigned] (IGNITE-4569) Create SQL index locally

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko reassigned IGNITE-4569:
---

Assignee: Alexander Paschenko

> Create SQL index locally
> 
>
> Key: IGNITE-4569
> URL: https://issues.apache.org/jira/browse/IGNITE-4569
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache, SQL
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 2.0
>
>
> Design considerations:
> 1) Cache is *not blocked* for updates during index creation.
> 2) DDL thread flow:
> - Create index and add it to some collection of pending indexes;
> - Iterate over all cache entries and add them one by one;
> - Once iteration finished - add index to the table;
> 3) Cache thread flow:
> - If there are any pending index, then propagate update to the index.
> Be careful with put/remove interleaving.



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

[jira] [Updated] (IGNITE-4747) Memory leak on massive cache operations over atomic cache

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov updated IGNITE-4747:
--
Attachment: invoke-fill.zip
Heap Histogram.mht

> Memory leak on massive cache operations over atomic cache
> -
>
> Key: IGNITE-4747
> URL: https://issues.apache.org/jira/browse/IGNITE-4747
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
> Attachments: Heap Histogram.mht, invoke-fill.zip
>
>
> When starts several nodes (I have tested in 4 nodes) with the application, 
> through some time (depends of heap size), we have got a Full GC pause and 
> segmentation the grid.
> After heap dump analysis, I found some suspicious object:
>   ||Class|| Instance Count|| Total Size 
> |class java.util.concurrent.ConcurrentSkipListMap$Node| 63622411|   
> 1526937864  
> |class java.util.concurrent.ConcurrentSkipListMap$Index|  31810595|   
> 763454280  
> |class java.lang.Long|
>  63622318|508978544  
> the leak in the field {{updates}} of class {{GridDhtLocalPartition}}.



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

[jira] [Updated] (IGNITE-4747) Memory leak on massive cache operations over atomic cache

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov updated IGNITE-4747:
--
Description: 
When starts several nodes (I have tested in 4 nodes) with the application, 
through some time (depends of heap size), we have got a Full GC pause and 
segmentation the grid.
After heap dump analysis, I found some suspicious object:

  ||Class|| Instance Count|| Total Size 
|class java.util.concurrent.ConcurrentSkipListMap$Node| 63622411|   
1526937864  
|class java.util.concurrent.ConcurrentSkipListMap$Index|  31810595|   
763454280  
|class java.lang.Long| 
63622318|508978544  


the leak in the field {{updates}} of class {{GridDhtLocalPartition}}.

  was:
When starts several nodes (I have tested in 4 nodes) with the application, 
through some time (depends of heap size), we have got a Full GC pause and 
segmentation the grid.
After heap dump analysis, I found some suspicious object:

  ||Class|| Instance Count|| Total Size 
|class java.util.concurrent.ConcurrentSkipListMap$Node| 63622411|   
1526937864  
|class java.util.concurrent.ConcurrentSkipListMap$Index|  31810595|   
763454280  
|class java.lang.Long| 
63622318|508978544  


the leak in the fils "updates" of class GridDhtLocalPartition.


> Memory leak on massive cache operations over atomic cache
> -
>
> Key: IGNITE-4747
> URL: https://issues.apache.org/jira/browse/IGNITE-4747
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
>
> When starts several nodes (I have tested in 4 nodes) with the application, 
> through some time (depends of heap size), we have got a Full GC pause and 
> segmentation the grid.
> After heap dump analysis, I found some suspicious object:
>   ||Class|| Instance Count|| Total Size 
> |class java.util.concurrent.ConcurrentSkipListMap$Node| 63622411|   
> 1526937864  
> |class java.util.concurrent.ConcurrentSkipListMap$Index|  31810595|   
> 763454280  
> |class java.lang.Long|
>  63622318|508978544  
> the leak in the field {{updates}} of class {{GridDhtLocalPartition}}.



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

[jira] [Updated] (IGNITE-4747) Memory leak on massive cache operations over atomic cache

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov updated IGNITE-4747:
--
Description: 
When starts several nodes (I have tested in 4 nodes) with the application, 
through some time (depends of heap size), we have got a Full GC pause and 
segmentation the grid.
After heap dump analysis, I found some suspicious object:

  ||Class|| Instance Count|| Total Size 
|class java.util.concurrent.ConcurrentSkipListMap$Node| 63622411|   
1526937864  
|class java.util.concurrent.ConcurrentSkipListMap$Index|  31810595|   
763454280  
|class java.lang.Long| 
63622318|508978544  


the leak in the fils "updates" of class GridDhtLocalPartition.

  was:
When starts several nodes (I have tested in 4 nodes) with the application, 
through some time (depends of heap size), we have got a Full GC pause and 
segmentation the grid.
After heap dump analysis, I found some suspicious object:

  Class|| Instance Count|| Total Size 
class java.util.concurrent.ConcurrentSkipListMap$Node| 63622411|   
1526937864  
class java.util.concurrent.ConcurrentSkipListMap$Index|  31810595|   
763454280  
class java.lang.Long| 
63622318|508978544  


the leak in the fils "updates" of class GridDhtLocalPartition.


> Memory leak on massive cache operations over atomic cache
> -
>
> Key: IGNITE-4747
> URL: https://issues.apache.org/jira/browse/IGNITE-4747
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
>
> When starts several nodes (I have tested in 4 nodes) with the application, 
> through some time (depends of heap size), we have got a Full GC pause and 
> segmentation the grid.
> After heap dump analysis, I found some suspicious object:
>   ||Class|| Instance Count|| Total Size 
> |class java.util.concurrent.ConcurrentSkipListMap$Node| 63622411|   
> 1526937864  
> |class java.util.concurrent.ConcurrentSkipListMap$Index|  31810595|   
> 763454280  
> |class java.lang.Long|
>  63622318|508978544  
> the leak in the fils "updates" of class GridDhtLocalPartition.



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

[jira] [Updated] (IGNITE-4747) Memory leak on massive cache operations over atomic cache

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov updated IGNITE-4747:
--
Description: 
When starts several nodes (I have tested in 4 nodes) with the application, 
through some time (depends of heap size), we have got a Full GC pause and 
segmentation the grid.
After heap dump analysis, I found some suspicious object:

  Class|| Instance Count|| Total Size 
class java.util.concurrent.ConcurrentSkipListMap$Node| 63622411|   
1526937864  
class java.util.concurrent.ConcurrentSkipListMap$Index|  31810595|   
763454280  
class java.lang.Long| 
63622318|508978544  


the leak in the fils "updates" of class GridDhtLocalPartition.

  was:
When starts several nodes (I have tested in 4 nodes) with the application, 
through some time (depends of heap size), we have got a Full GC pause and 
segmentation the grid.
After heap dump analysis, I found some suspicious object:
{noformat}
  Class|| Instance Count|| Total Size 
class java.util.concurrent.ConcurrentSkipListMap$Node| 63622411|   
1526937864  
class java.util.concurrent.ConcurrentSkipListMap$Index|  31810595|   
763454280  
class java.lang.Long| 
63622318|508978544  
{noformat}

the leak in the fils "updates" of class GridDhtLocalPartition.


> Memory leak on massive cache operations over atomic cache
> -
>
> Key: IGNITE-4747
> URL: https://issues.apache.org/jira/browse/IGNITE-4747
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
>
> When starts several nodes (I have tested in 4 nodes) with the application, 
> through some time (depends of heap size), we have got a Full GC pause and 
> segmentation the grid.
> After heap dump analysis, I found some suspicious object:
>   Class|| Instance Count|| Total Size 
> class java.util.concurrent.ConcurrentSkipListMap$Node| 63622411|   
> 1526937864  
> class java.util.concurrent.ConcurrentSkipListMap$Index|  31810595|   
> 763454280  
> class java.lang.Long| 
> 63622318|508978544  
> the leak in the fils "updates" of class GridDhtLocalPartition.



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

[jira] [Created] (IGNITE-4747) Memory leak on massive cache operations over atomic cache

[Vladislav Pyatkov (JIRA)]

Vladislav Pyatkov created IGNITE-4747:
-

 Summary: Memory leak on massive cache operations over atomic cache
 Key: IGNITE-4747
 URL: https://issues.apache.org/jira/browse/IGNITE-4747
 Project: Ignite
  Issue Type: Bug
Reporter: Vladislav Pyatkov


When starts several nodes (I have tested in 4 nodes) with the application, 
through some time (depends of heap size), we have got a Full GC pause and 
segmentation the grid.
After heap dump analysis, I found some suspicious object:
{noforamt}
  Class Instance Count Total Size 
class java.util.concurrent.ConcurrentSkipListMap$Node  63622411  1526937864  
class java.util.concurrent.ConcurrentSkipListMap$Index  31810595  763454280  
class java.lang.Long  63622318  508978544  
{noforamt}

the leak in the fils "updates" of class GridDhtLocalPartition.



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

[jira] [Updated] (IGNITE-4747) Memory leak on massive cache operations over atomic cache

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov updated IGNITE-4747:
--
Description: 
When starts several nodes (I have tested in 4 nodes) with the application, 
through some time (depends of heap size), we have got a Full GC pause and 
segmentation the grid.
After heap dump analysis, I found some suspicious object:
{noformat}
  Class Instance Count Total Size 
class java.util.concurrent.ConcurrentSkipListMap$Node  63622411  1526937864  
class java.util.concurrent.ConcurrentSkipListMap$Index  31810595  763454280  
class java.lang.Long  63622318  508978544  
{noformat}

the leak in the fils "updates" of class GridDhtLocalPartition.

  was:
When starts several nodes (I have tested in 4 nodes) with the application, 
through some time (depends of heap size), we have got a Full GC pause and 
segmentation the grid.
After heap dump analysis, I found some suspicious object:
{noforamt}
  Class Instance Count Total Size 
class java.util.concurrent.ConcurrentSkipListMap$Node  63622411  1526937864  
class java.util.concurrent.ConcurrentSkipListMap$Index  31810595  763454280  
class java.lang.Long  63622318  508978544  
{noforamt}

the leak in the fils "updates" of class GridDhtLocalPartition.


> Memory leak on massive cache operations over atomic cache
> -
>
> Key: IGNITE-4747
> URL: https://issues.apache.org/jira/browse/IGNITE-4747
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
>
> When starts several nodes (I have tested in 4 nodes) with the application, 
> through some time (depends of heap size), we have got a Full GC pause and 
> segmentation the grid.
> After heap dump analysis, I found some suspicious object:
> {noformat}
>   Class Instance Count Total Size 
> class java.util.concurrent.ConcurrentSkipListMap$Node  63622411  1526937864  
> class java.util.concurrent.ConcurrentSkipListMap$Index  31810595  763454280  
> class java.lang.Long  63622318  508978544  
> {noformat}
> the leak in the fils "updates" of class GridDhtLocalPartition.



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

[jira] [Commented] (IGNITE-3018) Cache affinity calculation is slow with large nodes number

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-3018:
--

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

> Cache affinity calculation is slow with large nodes number
> --
>
> Key: IGNITE-3018
> URL: https://issues.apache.org/jira/browse/IGNITE-3018
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Yakov Zhdanov
> Fix For: 2.0
>
> Attachments: 003.png, 064.png, 100.png, 128.png, 200.png, 300.png, 
> 400.png, 500.png, 600.png
>
>
> With large number of cache server nodes (> 200)  RendezvousAffinityFunction 
> and FairAffinityFunction work pretty slow .
> For RendezvousAffinityFunction.assignPartitions can take hundredes of 
> milliseconds, for FairAffinityFunction it can take seconds.
> For RendezvousAffinityFunction most time is spent in MD5 hash calculation and 
> nodes list sorting. As optimization we can try to cache {partion, node} MD5 
> hash or try another hash function. Also several minor optimizations are 
> possible (avoid unncecessary allocations, only one thread local 'get', etc).



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

[jira] [Resolved] (IGNITE-4720) Sporadically fails for Hadoop

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky resolved IGNITE-4720.
-
Resolution: Won't Fix

Fix suggested by Valdimir O. is to leave default option value 'true', but print 
warning saying that it is potentially dangerous. The warning will be 
implemented in 2.0 branch . 

> Sporadically fails for Hadoop
> -
>
> Key: IGNITE-4720
> URL: https://issues.apache.org/jira/browse/IGNITE-4720
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: 1.8
>Reporter: Irina Zaporozhtseva
>Assignee: Ivan Veselovsky
> Fix For: 1.9
>
>
> hadoop example aggregatewordcount under apache ignite hadoop edition grid 
> with 4 nodes for hadoop-2_6_4 and hadoop-2_7_2:
> aggregatewordcount returns 999712 instead of 100



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

[jira] [Commented] (IGNITE-4404) GridCacheOffHeapMultiThreadedUpdateAbstractSelfTest long running test refactoring

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii commented on IGNITE-4404:


I think we can keep this numbers for atomic behavior and decrease for 
transactional.

But which tests can be replaced with mocks if they all use node's cache?

> GridCacheOffHeapMultiThreadedUpdateAbstractSelfTest long running test 
> refactoring
> -
>
> Key: IGNITE-4404
> URL: https://issues.apache.org/jira/browse/IGNITE-4404
> Project: Ignite
>  Issue Type: Test
>Reporter: Konstantin Dudkov
>Assignee: Ryabov Dmitrii
>
> in testTransform
> final int THREADS = 5;
> final int ITERATIONS_PER_THREAD = 10_000;



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

[jira] [Comment Edited] (IGNITE-3018) Cache affinity calculation is slow with large nodes number

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-3018 at 2/22/17 1:49 PM:
---

Chi^2 test:

|| Nodes ||  Fair   ||  Rendezvous (old)||   FastRendezvous   ||
|*5* | 0.04 | 0.003618|  0.002531 |
|*64*| 0.00 | 0.063599| 0.077637  |
|*100*   | 0.001740 | 0.113892| 0.115036  |
|*128*   | 0.00 | 0.121094| 0.125732  |
|*200*   | 0.004028 | 0.203918| 0.216888  |
|*256*   | 0.00 | 0.248535| 0.269531  |
|*300*   | 0.020813 | 0.280594| 0.287460  |
|*400*   | 0.037598 | 0.361847| 0.396179  |
|*500*   | 0.010895 | 0.501083| 0.504898  |
|*600*   | 0.071167 | 0.589584| 0.617050  |



was (Author: tledkov-gridgain):
Chi^2 test:

|| Nodes ||  Fair   ||  Rendezvous (old)||   FastRendezvous   ||
|*5*  | 0.002531 | 0.003618|  0.002531  |
|*64*| 0.077637 | 0.063599| 0.077637  |
|*100*   | 0.115036 | 0.113892| 0.115036  |
|*128*   | 0.125732 | 0.121094| 0.125732  |
|*200*   | 0.216888 | 0.203918| 0.216888  |
|*256*   | 0.269531 | 0.248535| 0.269531  |
|*300*   | 0.287460 | 0.280594| 0.287460  |
|*400*   | 0.396179 | 0.361847| 0.396179  |
|*500*   | 0.504898 | 0.501083| 0.504898  |
|*600*   | 0.617050 | 0.589584| 0.617050  |






















> Cache affinity calculation is slow with large nodes number
> --
>
> Key: IGNITE-3018
> URL: https://issues.apache.org/jira/browse/IGNITE-3018
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Yakov Zhdanov
> Fix For: 2.0
>
> Attachments: 003.png, 064.png, 100.png, 128.png, 200.png, 300.png, 
> 400.png, 500.png, 600.png
>
>
> With large number of cache server nodes (> 200)  RendezvousAffinityFunction 
> and FairAffinityFunction work pretty slow .
> For RendezvousAffinityFunction.assignPartitions can take hundredes of 
> milliseconds, for FairAffinityFunction it can take seconds.
> For RendezvousAffinityFunction most time is spent in MD5 hash calculation and 
> nodes list sorting. As optimization we can try to cache {partion, node} MD5 
> hash or try another hash function. Also several minor optimizations are 
> possible (avoid unncecessary allocations, only one thread local 'get', etc).



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

[jira] [Commented] (IGNITE-3018) Cache affinity calculation is slow with large nodes number

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-3018:
--

Chi^2 test:

|| Nodes ||  Fair   ||  Rendezvous (old)||   FastRendezvous   ||
|*5*  | 0.002531 | 0.003618|  0.002531  |
|*64*| 0.077637 | 0.063599| 0.077637  |
|*100*   | 0.115036 | 0.113892| 0.115036  |
|*128*   | 0.125732 | 0.121094| 0.125732  |
|*200*   | 0.216888 | 0.203918| 0.216888  |
|*256*   | 0.269531 | 0.248535| 0.269531  |
|*300*   | 0.287460 | 0.280594| 0.287460  |
|*400*   | 0.396179 | 0.361847| 0.396179  |
|*500*   | 0.504898 | 0.501083| 0.504898  |
|*600*   | 0.617050 | 0.589584| 0.617050  |






















> Cache affinity calculation is slow with large nodes number
> --
>
> Key: IGNITE-3018
> URL: https://issues.apache.org/jira/browse/IGNITE-3018
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Yakov Zhdanov
> Fix For: 2.0
>
> Attachments: 003.png, 064.png, 100.png, 128.png, 200.png, 300.png, 
> 400.png, 500.png, 600.png
>
>
> With large number of cache server nodes (> 200)  RendezvousAffinityFunction 
> and FairAffinityFunction work pretty slow .
> For RendezvousAffinityFunction.assignPartitions can take hundredes of 
> milliseconds, for FairAffinityFunction it can take seconds.
> For RendezvousAffinityFunction most time is spent in MD5 hash calculation and 
> nodes list sorting. As optimization we can try to cache {partion, node} MD5 
> hash or try another hash function. Also several minor optimizations are 
> possible (avoid unncecessary allocations, only one thread local 'get', etc).



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

[jira] [Assigned] (IGNITE-3386) Reentrant lock is lost when lock owner leaves topology

[Evgenii Zhuravlev (JIRA)]

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

Evgenii Zhuravlev reassigned IGNITE-3386:
-

Assignee: Evgenii Zhuravlev  (was: Vladisav Jelisavcic)

> Reentrant lock is lost when lock owner leaves topology
> --
>
> Key: IGNITE-3386
> URL: https://issues.apache.org/jira/browse/IGNITE-3386
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Denis Magda
>Assignee: Evgenii Zhuravlev
>Priority: Critical
>  Labels: important
> Fix For: 2.0
>
> Attachments: LockIssueVer2.java
>
>
> If to create a lock with the following configuration 
> {{IgniteLock lock = ignite.reentrantLock("lock", true, true, true);}}
> and perform the following steps below
> 1) run the first node using {{LockIssue}} that is attached;
> 2) run the second node using {{LockIssue}};
> 3) stop the first node.
> you will get the following exception on the second node side (the lock 
> information will be lost and the second node won't recreate it ignore 
> "create=true" flag):
> {code}
> SEVERE:  Failed to compare and set: 
> o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync$1@67aea87d
> class org.apache.ignite.IgniteCheckedException: Failed to find reentrant lock 
> with given name: test
>   at 
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl$Sync$1.call(GridCacheLockImpl.java:525)
>   at 
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl$Sync$1.call(GridCacheLockImpl.java:518)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils$23.call(GridCacheUtils.java:1648)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.outTx(GridCacheUtils.java:891)
>   at 
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl$Sync.compareAndSetGlobalState(GridCacheLockImpl.java:517)
>   at 
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl$Sync.tryAcquire(GridCacheLockImpl.java:400)
>   at 
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl$Sync.tryAcquire(GridCacheLockImpl.java:437)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:861)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
>   at 
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl$Sync.lock(GridCacheLockImpl.java:432)
>   at 
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl.lock(GridCacheLockImpl.java:1201)
>   at 
> com.bfm.amc.loaders.server.StartIgniteServer.main(StartIgniteServer.java:15)
> {code}
> However the issue is not 100% reproduced but it should be clear from the logs 
> what happens.



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

[jira] [Commented] (IGNITE-4720) Sporadically fails for Hadoop

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky commented on IGNITE-4720:
-

Actual reason of failure is that field 
org.apache.hadoop.mapreduce.lib.aggregate.ValueAggregatorJobBase#aggregatorDescriptorList
holding the ValueAggregatorDescriptor-s  is *static*, so when using 
ignite.job.shared.classloader=true , this field is used in several Map tasks , 
creating data race.


> Sporadically fails for Hadoop
> -
>
> Key: IGNITE-4720
> URL: https://issues.apache.org/jira/browse/IGNITE-4720
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: 1.8
>Reporter: Irina Zaporozhtseva
>Assignee: Ivan Veselovsky
> Fix For: 1.9
>
>
> hadoop example aggregatewordcount under apache ignite hadoop edition grid 
> with 4 nodes for hadoop-2_6_4 and hadoop-2_7_2:
> aggregatewordcount returns 999712 instead of 100



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

[jira] [Commented] (IGNITE-4735) Some CPP files are missing from source releases.

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-4735:
-

[~avinogradov] Yeah, I've checked that with a diff tool.

> Some CPP files are missing from source releases.
> 
>
> Key: IGNITE-4735
> URL: https://issues.apache.org/jira/browse/IGNITE-4735
> Project: Ignite
>  Issue Type: Bug
>  Components: build
>Affects Versions: 1.8
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 1.9
>
>
> Some CPP files missing from the sources release. For example:
> - modules/platforms/cpp/common/project/vs/targetver.h
> - modules/platforms/cpp/jni/project/vs/targetver.h
> - modules/platforms/cpp/core/include/ignite/impl/interop/interop_target.h
> It seems that there is issue with files which has "target" in name.



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

[jira] [Commented] (IGNITE-4745) CPP: remove unsused targetver.h files

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4745:


GitHub user isapego opened a pull request:

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

IGNITE-4745: Removed unused targetver.h files



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

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

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

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


commit 730c41754dda2f42dc204c397bf7550637ebfd2a
Author: Igor Sapego 
Date:   2017-02-22T12:57:58Z

IGNITE-4745: Removed unused targetver.h files




> CPP: remove unsused targetver.h files
> -
>
> Key: IGNITE-4745
> URL: https://issues.apache.org/jira/browse/IGNITE-4745
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.8
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Minor
>  Labels: cpp
> Fix For: 1.9
>
>
> Currently, there are {{targetver.h}} files in {{common}} and {{jni}} libs of 
> the C++ client:
> - modules/platforms/cpp/common/project/vs/targetver.h
> - modules/platforms/cpp/jni/project/vs/targetver.h
> They are not used as for now so remove them.



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

[jira] [Updated] (IGNITE-4111) Communication fails to send message if target node did not finish join process

[Semen Boikov (JIRA)]

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

Semen Boikov updated IGNITE-4111:
-
Priority: Minor  (was: Major)

> Communication fails to send message if target node did not finish join process
> --
>
> Key: IGNITE-4111
> URL: https://issues.apache.org/jira/browse/IGNITE-4111
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Semen Boikov
>Assignee: Semen Boikov
>Priority: Minor
> Fix For: 2.0
>
> Attachments: test onFirstMessage hang.log
>
>
> Currently this scenario is possible:
> - joining node sent join request and waits for 
> TcpDiscoveryNodeAddFinishedMessage inside ServerImpl.joinTopology
> - others nodes already see this node and can send messages to it (for example 
> try to run compute job on this node)
> - joining node can not receive message: TcpCommunicationSpi will hang inside 
> 'onFirstMessage' on 'getSpiContext' call, so sending node will get error 
> trying to establish connection
> Possible fix: if in onFirstMessage() spi context is not available, then 
> TcpCommunicationSpi  should send special response which indicates that this 
> node is not ready yet, and sender should retry after some time.
> Also need check internal code for places where message can be unnecessarily 
> sent to node: one such place is 
> GridCachePartitionExchangeManager.refreshPartitions - message is sent to all 
> known nodes, but here we can filter by node order / finished exchage version.



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

[jira] [Created] (IGNITE-4746) Add documentation for SQL query parallelism

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4746:
---

 Summary: Add documentation for SQL query parallelism
 Key: IGNITE-4746
 URL: https://issues.apache.org/jira/browse/IGNITE-4746
 Project: Ignite
  Issue Type: Task
  Components: documentation, SQL
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 1.9


See IGNITE-4106.



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

[jira] [Created] (IGNITE-4745) CPP: remove unsused targetver.h files

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-4745:
---

 Summary: CPP: remove unsused targetver.h files
 Key: IGNITE-4745
 URL: https://issues.apache.org/jira/browse/IGNITE-4745
 Project: Ignite
  Issue Type: Task
  Components: platforms
Affects Versions: 1.8
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 1.9


Currently, there are {{targetver.h}} files in {{common}} and {{jni}} libs of 
the C++ client:
- modules/platforms/cpp/common/project/vs/targetver.h
- modules/platforms/cpp/jni/project/vs/targetver.h

They are not used as for now so remove them.



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

[jira] [Updated] (IGNITE-4745) CPP: remove unsused targetver.h files

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-4745:

Priority: Minor  (was: Major)

> CPP: remove unsused targetver.h files
> -
>
> Key: IGNITE-4745
> URL: https://issues.apache.org/jira/browse/IGNITE-4745
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.8
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Minor
>  Labels: cpp
> Fix For: 1.9
>
>
> Currently, there are {{targetver.h}} files in {{common}} and {{jni}} libs of 
> the C++ client:
> - modules/platforms/cpp/common/project/vs/targetver.h
> - modules/platforms/cpp/jni/project/vs/targetver.h
> They are not used as for now so remove them.



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

[jira] [Updated] (IGNITE-4744) visorcmd: task command doesn't show any tasks running on grid in some case

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-4744:
---
Description: 
I faced that visorcmd doesn't show any tasks that I running using my test load.
{code}
visor> tasks
(wrn) : No tasks or executions found.
(wrn) : Type 'help tasks' to see how to use this command.
visor> tasks
Tasks: 2
+==+
| Task Name(@ID), Oldest/Latest & Rate | Duration  | Nodes  |  
Executions  |
+==+
| TesterComputeFailoverTask(@t0)  | min: 00:00:00:000 | min: 2 | Total: 1 |
|  | avg: 00:00:00:000 | avg: 2 |   
   |
| Oldest: 02/22/17, 19:02:58   | max: 00:00:00:000 | max: 2 | St: 0 
(0%)   |
| Latest: 02/22/17, 19:02:58   |   || Fi: 1 
(100%) |
|  |   || Fa: 0 
(0%)   |
| Exec. Rate: 1 in 00:00:00:000|   || Un: 0 
(0%)   |
|  |   || Ti: 0 
(0%)   |
+--+---++--+
| TesterComputeTask(@t1)  | min: 00:00:00:071 | min: 2 | Total: 1 |
|  | avg: 00:00:00:071 | avg: 2 |   
   |
| Oldest: 02/22/17, 19:02:58   | max: 00:00:00:071 | max: 2 | St: 0 
(0%)   |
| Latest: 02/22/17, 19:02:58   |   || Fi: 1 
(100%) |
|  |   || Fa: 0 
(0%)   |
| Exec. Rate: 1 in 00:00:00:071|   || Un: 0 
(0%)   |
|  |   || Ti: 0 
(0%)   |
+--+

'St' - Started tasks.
'Fi' - Finished tasks.
'Fa' - Failed tasks.
'Un' - Undefined tasks (originating node left topology).
'Ti' - Timed out tasks.
visor> tasks
(wrn) : No tasks or executions found.
(wrn) : Type 'help tasks' to see how to use this command.
visor>
{code}

  was:I faced that visorcmd doesn't show any tasks that I running using my test 
load.


> visorcmd: task command doesn't show any tasks running on grid in some case
> --
>
> Key: IGNITE-4744
> URL: https://issues.apache.org/jira/browse/IGNITE-4744
> Project: Ignite
>  Issue Type: Bug
>  Components: visor
>Affects Versions: 1.9
>Reporter: Pavel Konstantinov
>
> I faced that visorcmd doesn't show any tasks that I running using my test 
> load.
> {code}
> visor> tasks
> (wrn) : No tasks or executions found.
> (wrn) : Type 'help tasks' to see how to use this command.
> visor> tasks
> Tasks: 2
> +==+
> | Task Name(@ID), Oldest/Latest & Rate | Duration  | Nodes  |  
> Executions  |
> +==+
> | TesterComputeFailoverTask(@t0)  | min: 00:00:00:000 | min: 2 | Total: 1 
> |
> |  | avg: 00:00:00:000 | avg: 2 | 
>  |
> | Oldest: 02/22/17, 19:02:58   | max: 00:00:00:000 | max: 2 | St: 0 
> (0%)   |
> | Latest: 02/22/17, 19:02:58   |   || Fi: 1 
> (100%) |
> |  |   || Fa: 0 
> (0%)   |
> | Exec. Rate: 1 in 00:00:00:000|   || Un: 0 
> (0%)   |
> |  |   || Ti: 0 
> (0%)   |
> +--+---++--+
> | TesterComputeTask(@t1)  | min: 00:00:00:071 | min: 2 | Total: 1 
> |
> |  | avg: 00:00:00:071 | avg: 2 | 
>  |
> | Oldest: 02/22/17, 19:02:58   | max: 00:00:00:071 | max: 2 | St: 0 
> (0%)   |
> | Latest: 02/22/17, 19:02:58   |   || Fi: 1 
> (100%) |
> |  |   || Fa: 0 
> (0%)   |
> | Exec. Rate: 1 in 00:00:00:071|   || Un: 0 
> (0%)   |
> |  |   || Ti: 0 
> (0%)   |
> +--+
> 'St' - Started tasks.
> 'Fi' - Finished tasks.
> 'Fa' - Failed tasks.
> 'Un' - Undefined tasks (originating node left topology).
> 'Ti' - Timed out tasks.
> visor> tasks
> (wrn) : No tasks or executions found.
> (wrn) : Type 

[jira] [Updated] (IGNITE-4744) visorcmd: task command doesn't show any tasks running on grid in some case

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-4744:
---
Description: 
I faced that some time visorcmd doesn't show any tasks that I running using my 
test load 
{code}
visor> tasks
(wrn) : No tasks or executions found.
(wrn) : Type 'help tasks' to see how to use this command.
visor> tasks
Tasks: 2
+==+
| Task Name(@ID), Oldest/Latest & Rate | Duration  | Nodes  |  
Executions  |
+==+
| TesterComputeFailoverTask(@t0)  | min: 00:00:00:000 | min: 2 | Total: 1 |
|  | avg: 00:00:00:000 | avg: 2 |   
   |
| Oldest: 02/22/17, 19:02:58   | max: 00:00:00:000 | max: 2 | St: 0 
(0%)   |
| Latest: 02/22/17, 19:02:58   |   || Fi: 1 
(100%) |
|  |   || Fa: 0 
(0%)   |
| Exec. Rate: 1 in 00:00:00:000|   || Un: 0 
(0%)   |
|  |   || Ti: 0 
(0%)   |
+--+---++--+
| TesterComputeTask(@t1)  | min: 00:00:00:071 | min: 2 | Total: 1 |
|  | avg: 00:00:00:071 | avg: 2 |   
   |
| Oldest: 02/22/17, 19:02:58   | max: 00:00:00:071 | max: 2 | St: 0 
(0%)   |
| Latest: 02/22/17, 19:02:58   |   || Fi: 1 
(100%) |
|  |   || Fa: 0 
(0%)   |
| Exec. Rate: 1 in 00:00:00:071|   || Un: 0 
(0%)   |
|  |   || Ti: 0 
(0%)   |
+--+

'St' - Started tasks.
'Fi' - Finished tasks.
'Fa' - Failed tasks.
'Un' - Undefined tasks (originating node left topology).
'Ti' - Timed out tasks.
visor> tasks
(wrn) : No tasks or executions found.
(wrn) : Type 'help tasks' to see how to use this command.
visor>
{code}

  was:
I faced that visorcmd doesn't show any tasks that I running using my test load.
{code}
visor> tasks
(wrn) : No tasks or executions found.
(wrn) : Type 'help tasks' to see how to use this command.
visor> tasks
Tasks: 2
+==+
| Task Name(@ID), Oldest/Latest & Rate | Duration  | Nodes  |  
Executions  |
+==+
| TesterComputeFailoverTask(@t0)  | min: 00:00:00:000 | min: 2 | Total: 1 |
|  | avg: 00:00:00:000 | avg: 2 |   
   |
| Oldest: 02/22/17, 19:02:58   | max: 00:00:00:000 | max: 2 | St: 0 
(0%)   |
| Latest: 02/22/17, 19:02:58   |   || Fi: 1 
(100%) |
|  |   || Fa: 0 
(0%)   |
| Exec. Rate: 1 in 00:00:00:000|   || Un: 0 
(0%)   |
|  |   || Ti: 0 
(0%)   |
+--+---++--+
| TesterComputeTask(@t1)  | min: 00:00:00:071 | min: 2 | Total: 1 |
|  | avg: 00:00:00:071 | avg: 2 |   
   |
| Oldest: 02/22/17, 19:02:58   | max: 00:00:00:071 | max: 2 | St: 0 
(0%)   |
| Latest: 02/22/17, 19:02:58   |   || Fi: 1 
(100%) |
|  |   || Fa: 0 
(0%)   |
| Exec. Rate: 1 in 00:00:00:071|   || Un: 0 
(0%)   |
|  |   || Ti: 0 
(0%)   |
+--+

'St' - Started tasks.
'Fi' - Finished tasks.
'Fa' - Failed tasks.
'Un' - Undefined tasks (originating node left topology).
'Ti' - Timed out tasks.
visor> tasks
(wrn) : No tasks or executions found.
(wrn) : Type 'help tasks' to see how to use this command.
visor>
{code}


> visorcmd: task command doesn't show any tasks running on grid in some case
> --
>
> Key: IGNITE-4744
> URL: https://issues.apache.org/jira/browse/IGNITE-4744
> Project: Ignite
>  Issue Type: Bug
>  Components: visor
>Affects Versions: 1.9
>Reporter: Pavel Konstantinov
>
> I faced that some time visorcmd doesn't show any tasks that I running using 
> my test load 
> {code}
> visor> 

[jira] [Updated] (IGNITE-4744) visorcmd: task command doesn't show any tasks running on grid in some case

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-4744:
---
Summary: visorcmd: task command doesn't show any tasks running on grid in 
some case  (was: visorcmd: task command doesn't show any tasks running on grid)

> visorcmd: task command doesn't show any tasks running on grid in some case
> --
>
> Key: IGNITE-4744
> URL: https://issues.apache.org/jira/browse/IGNITE-4744
> Project: Ignite
>  Issue Type: Bug
>  Components: visor
>Affects Versions: 1.9
>Reporter: Pavel Konstantinov
>
> I faced that visorcmd doesn't show any tasks that I running using my test 
> load.



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

[jira] [Assigned] (IGNITE-4694) Add tests to check there are no memory leaks in PageMemory

[Semen Boikov (JIRA)]

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

Semen Boikov reassigned IGNITE-4694:


Assignee: Semen Boikov  (was: Igor Seliverstov)

> Add tests to check there are no memory leaks in PageMemory
> --
>
> Key: IGNITE-4694
> URL: https://issues.apache.org/jira/browse/IGNITE-4694
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Semen Boikov
> Fix For: 2.0
>
>
> Need add several tests running for 5-10 munites verifying there are no memory 
> leaks in new data structures based of PageMemory:
> - test various page size
> - test various objects size
> - test put/get/remove operations
> - test create cache/destroy cache operations
> - test cases when indexes enabled/disabled
> - test case when cache expiry policy is used
> New tests should be added in new test suite.



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

[jira] [Assigned] (IGNITE-4712) Memory leaks in PageMemory

[Semen Boikov (JIRA)]

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

Semen Boikov reassigned IGNITE-4712:


Assignee: Semen Boikov  (was: Igor Seliverstov)

> Memory leaks in PageMemory
> --
>
> Key: IGNITE-4712
> URL: https://issues.apache.org/jira/browse/IGNITE-4712
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Igor Seliverstov
>Assignee: Semen Boikov
> Fix For: 2.0
>
>
> During performing put/get/remove operations on large objects (objects, which 
> size is more than 1kb) allocated pages number constantly grows.



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

[jira] [Commented] (IGNITE-533) Implement IgniteZeromqStreamer to stream data from ZeroMQ

[Maksim Kozlov (JIRA)]

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

Maksim Kozlov commented on IGNITE-533:
--

[~roman_s] all fixed and corrected all your comments, thank you very much! 
Please review again :)

> Implement IgniteZeromqStreamer to stream data from ZeroMQ
> -
>
> Key: IGNITE-533
> URL: https://issues.apache.org/jira/browse/IGNITE-533
> Project: Ignite
>  Issue Type: Sub-task
>  Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Maksim Kozlov
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under 
> high load. It was previously named {{IgniteDataLoader}}, see ticket 
> IGNITE-394.
> See [ZeroMQ|http://zeromq.org/] for more info.
> We should create {{IgniteZeroMqStreamer}} which will consume messages from 
> Twitter and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> * Convert ZeroMQ messages to Ignite data using an optional pluggable 
> converter. If not provided, we should have some default mechanism.
> * Specify the cache name for the Ignite cache to load data into.
> * Specify other flags available on {{IgniteDataStreamer}} class.



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

[jira] [Created] (IGNITE-4744) visorcmd: task command doesn't show any tasks running on grid

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-4744:
--

 Summary: visorcmd: task command doesn't show any tasks running on 
grid
 Key: IGNITE-4744
 URL: https://issues.apache.org/jira/browse/IGNITE-4744
 Project: Ignite
  Issue Type: Bug
  Components: visor
Affects Versions: 1.9
Reporter: Pavel Konstantinov


I faced that visorcmd doesn't show any tasks that I running using my test load.



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

[jira] [Commented] (IGNITE-4106) SQL: parallelize sql queries over cache local partitions

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4106:


Github user asfgit closed the pull request at:

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


> SQL: parallelize sql queries over cache local partitions
> 
>
> Key: IGNITE-4106
> URL: https://issues.apache.org/jira/browse/IGNITE-4106
> Project: Ignite
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 1.7
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>  Labels: performance
> Fix For: 1.9
>
> Attachments: 1node-4thread.jfr, 4node-1thread.jfr
>
>
> If we run SQL query on cache partitioned over several cluster nodes, it will 
> be split into several queries running in parallel. But really we will have 
> one thread per query on each node.
> So, for now, to improve SQL query performance we need to run more Ignite 
> instances or split caches manually.
> It seems to be better to split local SQL queries over cache partitions, so we 
> would be able to parallelize SQL query on every single node and utilize CPU 
> more efficiently.



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

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

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov commented on IGNITE-4501:
-

Yakov, I fixed it. Please look again.

> Improvement of connection in a cluster of new node
> --
>
> Key: IGNITE-4501
> URL: https://issues.apache.org/jira/browse/IGNITE-4501
> Project: Ignite
>  Issue Type: Improvement
>  Components: messaging
>Affects Versions: 1.8
>Reporter: Vyacheslav Daradur
>Assignee: Alexander Menshikov
> Fix For: 2.0
>
>
> h3. Main description:
> Cluster nodes connect a ring.
> For example: we have 6 nodes: A, B, C, D, E, F. 
> They can connect a ring in any possible way: A-B-C-D-E-F-A, or A-F-B-E-C-D-A, 
> etc.
> If some node leaves topology, adjacent nodes must reconnect. 
> If nodes A, B, C are in same physical place, nodes D, E, F are in other 
> place, and places lost connect each other, we will have many ways of 
> reconnections.
> At best case, if we had a ring: A-B-CxD-E-FxA ('x' means disconnect) -- then 
> we have only one reconnect (C
> will be connected to A or F will be connected to D -- depends on what part of 
> the cluster was alive.
> Also, if we had a not ring: AxFxBxExCxDxA -- then we have a lot of 
> reconnections (A to B, B to C, C to A -- in general n/2 reconnections, where 
> n -- number of nodes). 
> h3. Approach:
> It is necessary to develop approach of node insertion to the correct place 
> for creation of the correct ring-topology.
> h3. Solutions:
> Main idea is a sorting according to latency.
> * group nodes in arcs on an ARC_ID. (manualy?)
> * implement NodeComparator (nodes on the same host : nodes on the same subnet 
> : other nodes). We will use it when we connect a new node.
> * [dev list 
> thread|http://mail-archives.apache.org/mod_mbox/ignite-dev/201612.mbox/%3CCAN+WSNyWYXSXEBpGErVt72zTgi2pTQzUWLv8JY=ke83-5-r...@mail.gmail.com%3E]
> Update Dec, 29 Yakov Zhdanov:
> # introduce CLUSTER_REGION_ID node attribute. This can be done by adding 
> public static final constant to TcpDiscoverySpi.
> # Alter 
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing#nextNode(java.util.Collection)
>  to order basing on per node attribute value
> # Node comparison should be stable and consistent. E.g. if CLUSTER_REGION_IDs 
> are equal then we should compare nodes' IDs. This way we have consistent 
> order on all nodes in topology.
> # Also nextNode() has to group nodes on same host and in same subnet. This 
> can be postponed and implemented after we have other points done.



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

[jira] [Created] (IGNITE-4743) Set AUTO_COPY to false when it wasn't define in properties file

[Ilya Suntsov (JIRA)]

Ilya Suntsov created IGNITE-4743:


 Summary: Set AUTO_COPY to false when it wasn't define in 
properties file
 Key: IGNITE-4743
 URL: https://issues.apache.org/jira/browse/IGNITE-4743
 Project: Ignite
  Issue Type: Bug
Reporter: Ilya Suntsov


In case when in properties file there isn't variable AUTO_COPY we automatically 
set it to true. It's wrong. 
We should add condition if AUTO_COPY doesn't exist in property file then set it 
to false.



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

[jira] [Commented] (IGNITE-4742) Flaky IgniteCacheUpdateSqlQuerySelfTest.testTypeConversions

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4742:


GitHub user alexpaschenko opened a pull request:

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

IGNITE-4742 IgniteCacheUpdateSqlQuerySelfTest.testTypeConversions fix



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

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

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

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


commit ceffb95bc9301c716d7e35c3e80d6fd46ac7a34c
Author: Alexander Paschenko 
Date:   2017-02-22T10:31:24Z

IGNITE-4742 IgniteCacheUpdateSqlQuerySelfTest.testTypeConversions fix




> Flaky IgniteCacheUpdateSqlQuerySelfTest.testTypeConversions
> ---
>
> Key: IGNITE-4742
> URL: https://issues.apache.org/jira/browse/IGNITE-4742
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
>Priority: Minor
> Fix For: 1.9
>
>
> This test fails randomly on various query related suites and very seldom 
> locally. Seems to be test problem and not of what is tested.



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

[jira] [Commented] (IGNITE-4284) Failed second client node join with continuous query and peer class loading enabled

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4284:


Github user NSAmelchev closed the pull request at:

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


> Failed second client node join with continuous query and peer class loading 
> enabled
> ---
>
> Key: IGNITE-4284
> URL: https://issues.apache.org/jira/browse/IGNITE-4284
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7
>Reporter: Dmitry Karachentsev
>Assignee: Amelchev Nikita
> Fix For: 2.0
>
>
> Steps to reproduce:
> 1) Start server with cache and peer class loading enabled.
> 2) Start client with peer class loading enabled.
> 3) Start continuous query with custom event filter factory.
> 4) Start second client -- Fail with NPE or AsserionError.
> Test that reproduces error: 
> [PR#1267|https://github.com/apache/ignite/pull/1267]



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

[jira] [Commented] (IGNITE-4741) JdbcStreamingSelfTest is not reliable

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4741:


GitHub user alexpaschenko opened a pull request:

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

IGNITE-4741 JDBC DML streaming test fix



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

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

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

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


commit 416f427434f143f32c2e04943c8cd8c98a5bca1e
Author: Alexander Paschenko 
Date:   2017-02-22T10:10:53Z

IGNITE-4741 JDBC DML streaming test fix




> JdbcStreamingSelfTest is not reliable
> -
>
> Key: IGNITE-4741
> URL: https://issues.apache.org/jira/browse/IGNITE-4741
> Project: Ignite
>  Issue Type: Test
>  Components: jdbc-driver
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Minor
> Fix For: 1.9
>
>
> Test fails from time to time because it waits for some conditions based on 
> {{Thread.sleep(1000L}}, which is not reliable enough.



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

[jira] [Commented] (IGNITE-4735) Some CPP files are missing from source releases.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4735:
-

[~isapego],
{{interop_target.h}} appeared, but there are no {{targetver.h}} still. However, 
I dot not see them in 1.8 release either. Do we really need them?

> Some CPP files are missing from source releases.
> 
>
> Key: IGNITE-4735
> URL: https://issues.apache.org/jira/browse/IGNITE-4735
> Project: Ignite
>  Issue Type: Bug
>  Components: build
>Affects Versions: 1.8
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 1.9
>
>
> Some CPP files missing from the sources release. For example:
> - modules/platforms/cpp/common/project/vs/targetver.h
> - modules/platforms/cpp/jni/project/vs/targetver.h
> - modules/platforms/cpp/core/include/ignite/impl/interop/interop_target.h
> It seems that there is issue with files which has "target" in name.



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

[jira] [Commented] (IGNITE-2845) Get operation might ignore entry update from EntryProcessor.

[Alexandr Fedotov (JIRA)]

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

Alexandr Fedotov commented on IGNITE-2845:
--

This fix is related and will be done as a part of 
[IGNITE-3471|https://issues.apache.org/jira/browse/IGNITE-3471]

> Get operation might ignore entry update from EntryProcessor.
> 
>
> Key: IGNITE-2845
> URL: https://issues.apache.org/jira/browse/IGNITE-2845
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Alexey Kuznetsov
> Fix For: 2.0
>
>
> Originally issue was observed during work with IGFS. Steps to reproduce:
> 1) Start REPLICATE cache.
> 2) Start PESSIMISITC/REPEATABLE_READ transaction.
> 3) Invoke EntryProcessor on non-existent key and call 
> "MutableEntry.setValue()" inside it.
> 4) Call {{IgniteCache.get()}} on this value. It will return {{null}}, while 
> normally it should return value set inside EntryProcessor.



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

[jira] [Assigned] (IGNITE-2845) Get operation might ignore entry update from EntryProcessor.

[Alexandr Fedotov (JIRA)]

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

Alexandr Fedotov reassigned IGNITE-2845:


Assignee: Alexandr Fedotov  (was: Alexey Kuznetsov)

> Get operation might ignore entry update from EntryProcessor.
> 
>
> Key: IGNITE-2845
> URL: https://issues.apache.org/jira/browse/IGNITE-2845
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Alexandr Fedotov
> Fix For: 2.0
>
>
> Originally issue was observed during work with IGFS. Steps to reproduce:
> 1) Start REPLICATE cache.
> 2) Start PESSIMISITC/REPEATABLE_READ transaction.
> 3) Invoke EntryProcessor on non-existent key and call 
> "MutableEntry.setValue()" inside it.
> 4) Call {{IgniteCache.get()}} on this value. It will return {{null}}, while 
> normally it should return value set inside EntryProcessor.



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

[jira] [Commented] (IGNITE-4404) GridCacheOffHeapMultiThreadedUpdateAbstractSelfTest long running test refactoring

[Konstantin Dudkov (JIRA)]

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

Konstantin Dudkov commented on IGNITE-4404:
---

The ideas was:
1. we need such number of threads/iterations only for things that can fail 
under heavy/long concurrent operations. In many cases we can use less numbers 
and/or stop conditions
2. we should separate long running tests with full node start from short 
unittests. Short tests are good to run all short tests in IDE after any changes 
and to run on CI server after any commit. Long tests should be run only 
on-demand.
3. In most cases we do not need at all to start node to test some functionality 
- unittests with mocks are much faster.

> GridCacheOffHeapMultiThreadedUpdateAbstractSelfTest long running test 
> refactoring
> -
>
> Key: IGNITE-4404
> URL: https://issues.apache.org/jira/browse/IGNITE-4404
> Project: Ignite
>  Issue Type: Test
>Reporter: Konstantin Dudkov
>Assignee: Ryabov Dmitrii
>
> in testTransform
> final int THREADS = 5;
> final int ITERATIONS_PER_THREAD = 10_000;



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

[jira] [Commented] (IGNITE-3939) Compact long zero values binary representation

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-3939:
-

Introducing separate types we can significantly possible number of schemas. For 
example, suppose an object with 20 {{long}} fields, which is not uncommon in 
banking area, If all these fields could be zero at some point, we will end up 
with {{2 ^ 20 ~ 1M}} schemas, which is unacceptable. Instead we can do the 
following:
1) Define two special value states - {{NULL}} and {{ZERO}}
2) If value in one of these states, *do not write* it to body at all
3) In the footer write special offset value which will define that the object 
is in particular special state.
4) Offset value is taken form the end of the possible range for the given 
object length:
- 1-byte offsets: {{NULL = 255}}, {{ZERO = 254}}
- 2-bytes offsets: {{NULL = 65534}}, {{ZERO = 65533}}
- 4-bytes offsets: {{NULL = 4294967294}}, {{ZERO = 4294967293}}

> Compact long zero values binary representation
> --
>
> Key: IGNITE-3939
> URL: https://issues.apache.org/jira/browse/IGNITE-3939
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary
>Affects Versions: 1.7
>Reporter: Andrew Mashenkov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> We can use separate type for Long zero values and exclude 8-byte value from 
> binary representation. This will reduce memory footprint and network load.
> Compatibility with previous versions MUST be preserved.



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

[jira] [Comment Edited] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii edited comment on IGNITE-602 at 2/22/17 9:34 AM:


Don't forget to unmute test.


was (Author: somefire):
How to unmute it on TC? Class contining this test is already in basic test 
suit. 

> [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by 
> infinite recursion
> 
>
> Key: IGNITE-602
> URL: https://issues.apache.org/jira/browse/IGNITE-602
> Project: Ignite
>  Issue Type: Bug
>Reporter: Artem Shutak
>Assignee: Ryabov Dmitrii
>  Labels: Muted_test
> Fix For: 2.0
>
>
> See test 
> org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention
>  and related TODO in same source file.
> Also take a look at 
> http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring
> Test should be unmuted on TC after fix.
> see GG-5000.



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

[jira] [Commented] (IGNITE-4735) Some CPP files are missing from source releases.

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-4735:
--

Igor, 
please do "vote preparation" for same sources with both regexps (old and new) 
and make sure that sources.zip contains same files set.
 

> Some CPP files are missing from source releases.
> 
>
> Key: IGNITE-4735
> URL: https://issues.apache.org/jira/browse/IGNITE-4735
> Project: Ignite
>  Issue Type: Bug
>  Components: build
>Affects Versions: 1.8
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 1.9
>
>
> Some CPP files missing from the sources release. For example:
> - modules/platforms/cpp/common/project/vs/targetver.h
> - modules/platforms/cpp/jni/project/vs/targetver.h
> - modules/platforms/cpp/core/include/ignite/impl/interop/interop_target.h
> It seems that there is issue with files which has "target" in name.



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

[jira] [Assigned] (IGNITE-3939) Compact long zero values binary representation

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-3939:
---

Assignee: Taras Ledkov  (was: Vladimir Ozerov)

Cancelling patch, because another cool solution was proposed by [~vkulichenko]. 
Description is to follow.

> Compact long zero values binary representation
> --
>
> Key: IGNITE-3939
> URL: https://issues.apache.org/jira/browse/IGNITE-3939
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary
>Affects Versions: 1.7
>Reporter: Andrew Mashenkov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> We can use separate type for Long zero values and exclude 8-byte value from 
> binary representation. This will reduce memory footprint and network load.
> Compatibility with previous versions MUST be preserved.



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

[jira] [Created] (IGNITE-4741) JdbcStreamingSelfTest is not reliable

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4741:
---

 Summary: JdbcStreamingSelfTest is not reliable
 Key: IGNITE-4741
 URL: https://issues.apache.org/jira/browse/IGNITE-4741
 Project: Ignite
  Issue Type: Test
  Components: jdbc-driver
Affects Versions: 1.8
Reporter: Vladimir Ozerov
Assignee: Alexander Paschenko
Priority: Minor
 Fix For: 1.9


Test fails from time to time because it waits for some conditions based on 
{{Thread.sleep(1000L}}, which is not reliable enough.



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

[jira] [Commented] (IGNITE-4735) Some CPP files are missing from source releases.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4735:
-

LGTM

> Some CPP files are missing from source releases.
> 
>
> Key: IGNITE-4735
> URL: https://issues.apache.org/jira/browse/IGNITE-4735
> Project: Ignite
>  Issue Type: Bug
>  Components: build
>Affects Versions: 1.8
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 1.9
>
>
> Some CPP files missing from the sources release. For example:
> - modules/platforms/cpp/common/project/vs/targetver.h
> - modules/platforms/cpp/jni/project/vs/targetver.h
> - modules/platforms/cpp/core/include/ignite/impl/interop/interop_target.h
> It seems that there is issue with files which has "target" in name.



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