[jira] [Updated] (IGNITE-4052) Add ability to set up users for MESOS

[Vadim Opolski (JIRA)]

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

Vadim Opolski updated IGNITE-4052:
--

Hello guys!

Nikolai, I improved method getRole and getUser,

Review please again:

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

but what do mean about override ?

Something like this:

public class IgniteFrameworkUnderTest extends IgniteFramework{

...
@Override
public String getUser(){
...
}

@Override
public String getRole(){
...
}

}

Vadim Opolski





> Add ability to set up users for MESOS
> -
>
> Key: IGNITE-4052
> URL: https://issues.apache.org/jira/browse/IGNITE-4052
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.7
>Reporter: Nikolay Tikhonov
>Assignee: Vadim Opolski
>Priority: Trivial
>
> In current implementation Ignite Mesos Framework connects to MESOS cluster 
> via current user. Need to add ability to configure this parameters via system 
> env properties. Also need to add properties for mesos role.
> See org/apache/ignite/mesos/IgniteFramework.java:537



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

[jira] [Comment Edited] (IGNITE-3920) Hadoop: remove PayloadAware interface.

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov edited comment on IGNITE-3920 at 4/14/17 3:53 AM:
-

Test failed
{code}
java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.igfs.IgfsModeResolver.resolveMode(IgfsModeResolver.java:100)
at 
org.gridgain.visor.fs.igfs.VisorIgfsFileSystem.mode(VisorIgfsFileSystem.scala:650)
at 
org.gridgain.visor.fs.igfs.VisorIgfsFile.cached(VisorIgfsFile.scala:191)
at 
org.gridgain.visor.fs.igfs.VisorIgfsFileSystem.(VisorIgfsFileSystem.scala:251)
at 
org.gridgain.visor.fs.igfs.VisorIgfsFileSystem$.connect(VisorIgfsFileSystem.scala:908)
at 
org.gridgain.visor.gui.model.impl.VisorGuiModelImpl.org$gridgain$visor$gui$model$impl$VisorGuiModelImpl$$igfsConnect(VisorGuiModelImpl.scala:1743)
at 
org.gridgain.visor.gui.model.impl.VisorGuiModelImpl$$anonfun$1$$anonfun$apply$mcV$sp$22$$anonfun$apply$52.apply(VisorGuiModelImpl.scala:2229)
at 
org.gridgain.visor.gui.model.impl.VisorGuiModelImpl$$anonfun$1$$anonfun$apply$mcV$sp$22$$anonfun$apply$52.apply(VisorGuiModelImpl.scala:2229)
at 
scala.collection.LinearSeqOptimized$class.find(LinearSeqOptimized.scala:113)
at scala.collection.immutable.List.find(List.scala:84)
at 
org.gridgain.visor.gui.model.impl.VisorGuiModelImpl$$anonfun$1$$anonfun$apply$mcV$sp$22.apply(VisorGuiModelImpl.scala:2229)
at 
org.gridgain.visor.gui.model.impl.VisorGuiModelImpl$$anonfun$1$$anonfun$apply$mcV$sp$22.apply(VisorGuiModelImpl.scala:2229)
at scala.collection.Iterator$class.foreach(Iterator.scala:742)
at scala.collection.AbstractIterator.foreach(Iterator.scala:1194)
at scala.collection.MapLike$DefaultValuesIterable.foreach(MapLike.sc
{code}

config attached


was (Author: pkonstantinov):
{code}
java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.igfs.IgfsModeResolver.resolveMode(IgfsModeResolver.java:100)
at 
org.gridgain.visor.fs.igfs.VisorIgfsFileSystem.mode(VisorIgfsFileSystem.scala:650)
at 
org.gridgain.visor.fs.igfs.VisorIgfsFile.cached(VisorIgfsFile.scala:191)
at 
org.gridgain.visor.fs.igfs.VisorIgfsFileSystem.(VisorIgfsFileSystem.scala:251)
at 
org.gridgain.visor.fs.igfs.VisorIgfsFileSystem$.connect(VisorIgfsFileSystem.scala:908)
at 
org.gridgain.visor.gui.model.impl.VisorGuiModelImpl.org$gridgain$visor$gui$model$impl$VisorGuiModelImpl$$igfsConnect(VisorGuiModelImpl.scala:1743)
at 
org.gridgain.visor.gui.model.impl.VisorGuiModelImpl$$anonfun$1$$anonfun$apply$mcV$sp$22$$anonfun$apply$52.apply(VisorGuiModelImpl.scala:2229)
at 
org.gridgain.visor.gui.model.impl.VisorGuiModelImpl$$anonfun$1$$anonfun$apply$mcV$sp$22$$anonfun$apply$52.apply(VisorGuiModelImpl.scala:2229)
at 
scala.collection.LinearSeqOptimized$class.find(LinearSeqOptimized.scala:113)
at scala.collection.immutable.List.find(List.scala:84)
at 
org.gridgain.visor.gui.model.impl.VisorGuiModelImpl$$anonfun$1$$anonfun$apply$mcV$sp$22.apply(VisorGuiModelImpl.scala:2229)
at 
org.gridgain.visor.gui.model.impl.VisorGuiModelImpl$$anonfun$1$$anonfun$apply$mcV$sp$22.apply(VisorGuiModelImpl.scala:2229)
at scala.collection.Iterator$class.foreach(Iterator.scala:742)
at scala.collection.AbstractIterator.foreach(Iterator.scala:1194)
at scala.collection.MapLike$DefaultValuesIterable.foreach(MapLike.sc
{code}

config attached

> Hadoop: remove PayloadAware interface.
> --
>
> Key: IGNITE-3920
> URL: https://issues.apache.org/jira/browse/IGNITE-3920
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
> Attachments: default-config.xml
>
>
> When IGNITE-3376 is ready, we will be able to execute {{PROXY}} operations 
> directly from {{IgfsImpl}}. It means that we no longer need 
> {{HadoopPayloadAware}} interface, and we no longer need to pass {{IgfsPaths}} 
> to the client. 
> Let's remove them all together.



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

[jira] [Assigned] (IGNITE-3920) Hadoop: remove PayloadAware interface.

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-3920:
--

Assignee: Taras Ledkov  (was: Pavel Konstantinov)

> Hadoop: remove PayloadAware interface.
> --
>
> Key: IGNITE-3920
> URL: https://issues.apache.org/jira/browse/IGNITE-3920
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
> Attachments: default-config.xml
>
>
> When IGNITE-3376 is ready, we will be able to execute {{PROXY}} operations 
> directly from {{IgfsImpl}}. It means that we no longer need 
> {{HadoopPayloadAware}} interface, and we no longer need to pass {{IgfsPaths}} 
> to the client. 
> Let's remove them all together.



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

[jira] [Commented] (IGNITE-3920) Hadoop: remove PayloadAware interface.

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-3920:


{code}
java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.igfs.IgfsModeResolver.resolveMode(IgfsModeResolver.java:100)
at 
org.gridgain.visor.fs.igfs.VisorIgfsFileSystem.mode(VisorIgfsFileSystem.scala:650)
at 
org.gridgain.visor.fs.igfs.VisorIgfsFile.cached(VisorIgfsFile.scala:191)
at 
org.gridgain.visor.fs.igfs.VisorIgfsFileSystem.(VisorIgfsFileSystem.scala:251)
at 
org.gridgain.visor.fs.igfs.VisorIgfsFileSystem$.connect(VisorIgfsFileSystem.scala:908)
at 
org.gridgain.visor.gui.model.impl.VisorGuiModelImpl.org$gridgain$visor$gui$model$impl$VisorGuiModelImpl$$igfsConnect(VisorGuiModelImpl.scala:1743)
at 
org.gridgain.visor.gui.model.impl.VisorGuiModelImpl$$anonfun$1$$anonfun$apply$mcV$sp$22$$anonfun$apply$52.apply(VisorGuiModelImpl.scala:2229)
at 
org.gridgain.visor.gui.model.impl.VisorGuiModelImpl$$anonfun$1$$anonfun$apply$mcV$sp$22$$anonfun$apply$52.apply(VisorGuiModelImpl.scala:2229)
at 
scala.collection.LinearSeqOptimized$class.find(LinearSeqOptimized.scala:113)
at scala.collection.immutable.List.find(List.scala:84)
at 
org.gridgain.visor.gui.model.impl.VisorGuiModelImpl$$anonfun$1$$anonfun$apply$mcV$sp$22.apply(VisorGuiModelImpl.scala:2229)
at 
org.gridgain.visor.gui.model.impl.VisorGuiModelImpl$$anonfun$1$$anonfun$apply$mcV$sp$22.apply(VisorGuiModelImpl.scala:2229)
at scala.collection.Iterator$class.foreach(Iterator.scala:742)
at scala.collection.AbstractIterator.foreach(Iterator.scala:1194)
at scala.collection.MapLike$DefaultValuesIterable.foreach(MapLike.sc
{code}

config attached

> Hadoop: remove PayloadAware interface.
> --
>
> Key: IGNITE-3920
> URL: https://issues.apache.org/jira/browse/IGNITE-3920
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Pavel Konstantinov
> Fix For: 2.0
>
> Attachments: default-config.xml
>
>
> When IGNITE-3376 is ready, we will be able to execute {{PROXY}} operations 
> directly from {{IgfsImpl}}. It means that we no longer need 
> {{HadoopPayloadAware}} interface, and we no longer need to pass {{IgfsPaths}} 
> to the client. 
> Let's remove them all together.



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

[jira] [Updated] (IGNITE-3920) Hadoop: remove PayloadAware interface.

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-3920:
---
Attachment: default-config.xml

> Hadoop: remove PayloadAware interface.
> --
>
> Key: IGNITE-3920
> URL: https://issues.apache.org/jira/browse/IGNITE-3920
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Pavel Konstantinov
> Fix For: 2.0
>
> Attachments: default-config.xml
>
>
> When IGNITE-3376 is ready, we will be able to execute {{PROXY}} operations 
> directly from {{IgfsImpl}}. It means that we no longer need 
> {{HadoopPayloadAware}} interface, and we no longer need to pass {{IgfsPaths}} 
> to the client. 
> Let's remove them all together.



--
This message was sent by Atlassian JIRA
(v6.3.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=15968139#comment-15968139
 ] 

Alexander Menshikov commented on IGNITE-4501:
-

[~yzhdanov]

I understand what going on. Region ID breaks optimization in 
ServerImpl.RingMessageWorker#processNodeAddedMessage() which clears discovery 
data from TcpDiscoveryNodeAddedMessage in case when new node is sending 
TcpDiscoveryJoinRequestMessage to coordinator. Because after that if new node 
take a random position in the ring and then coordinator verifies it and sends 
verified message through the ring, but new node not in the end of the ring. 
This optimization clears data from message and the next nodes get NPE when try 
to get data.

> 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-4979) Document SQL queries execution started on replicated cache

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4979:
---

 Summary: Document SQL queries execution started on replicated cache
 Key: IGNITE-4979
 URL: https://issues.apache.org/jira/browse/IGNITE-4979
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Denis Magda


Refer to IGNITE-4955 for more details.



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

[jira] [Created] (IGNITE-4978) Prepare Apache Ignite 2.0 Migration Guide

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4978:
---

 Summary: Prepare Apache Ignite 2.0 Migration Guide
 Key: IGNITE-4978
 URL: https://issues.apache.org/jira/browse/IGNITE-4978
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Denis Magda


There were many big and small changes introduced in Apache Ignite 2.0 that 
break backward compatibility with version 1.x and has to put into the migration 
guide.

Sources for migration guide:
* An umbrella ticket with most significant changes (IGNITE-4960)
* An umbrella ticket with minor tasks (IGNITE-4547)
* Migration guide on Ignite wiki 
(https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide)

Update readme.io documentation if needed.



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

[jira] [Created] (IGNITE-4977) Remove BinaryIdentityResolvers mentioning from the documentation

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4977:
---

 Summary: Remove BinaryIdentityResolvers mentioning from the 
documentation
 Key: IGNITE-4977
 URL: https://issues.apache.org/jira/browse/IGNITE-4977
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Denis Magda


{{BinaryIdentityResolvers}} are no longer supported. Refresh the whole 
documentation where they can be mentioned.

[~ptupitsyn], [~isapego], please do the same for .NET and C++ whenever required.



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

[jira] [Created] (IGNITE-4976) Document C++ Continuous Queries Remote Filters

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4976:
---

 Summary: Document C++ Continuous Queries Remote Filters
 Key: IGNITE-4976
 URL: https://issues.apache.org/jira/browse/IGNITE-4976
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Igor Sapego


[~isapego], please document CQ remote filters feature (IGNITE-3575) and assign 
the ticket on me and Prachi for the final modifications.



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

[jira] [Created] (IGNITE-4975) Update Hibernate documentation (Hibernate 5 addition, discontinue of binary resolvers)

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4975:
---

 Summary: Update Hibernate documentation (Hibernate 5 addition, 
discontinue of binary resolvers)
 Key: IGNITE-4975
 URL: https://issues.apache.org/jira/browse/IGNITE-4975
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Valentin Kulichenko


In Apache Ignite 2.0 there are at least two updates related to Hibernate 
integration that have to be documented:
* Hibernate 5 Support (IGNITE-1794)
* BinaryIdentityResolvers are discontinued and can't as a workaround 
(https://apacheignite-mix.readme.io/docs/hibernate-l2-cache#section-l2-cache-configuration)
 for Hibernate {{CacheKey}} serialization (IGNITE-3429)

[~vkulichenko], could help out and refine Hibernate doc taking into account 2 
points above? Here is a hidden page for the modifications:
https://dash.readme.io/project/apacheignite-mix/v1.9/docs/hibernate-l2-cache-20



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

[jira] [Created] (IGNITE-4974) Document .NET dynamically registered classes

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4974:
---

 Summary: Document .NET dynamically registered classes
 Key: IGNITE-4974
 URL: https://issues.apache.org/jira/browse/IGNITE-4974
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Pavel Tupitsyn


[~ptupitsyn], please document modifications related to .NET dynamically 
registered classes (IGNITE-2703) and assign the ticket on me and Prachi for 
final polishment.



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

[jira] [Created] (IGNITE-4973) Document .NET Plugin System

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4973:
---

 Summary: Document .NET Plugin System
 Key: IGNITE-4973
 URL: https://issues.apache.org/jira/browse/IGNITE-4973
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Pavel Tupitsyn


[~ptupitsyn], please document .NET plugin system (IGNITE-2940) with the usage 
hints whenever applicable.

As usual, assign on me and Prachi for the final review.



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

[jira] [Created] (IGNITE-4972) Document updated async API

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4972:
---

 Summary: Document updated async API
 Key: IGNITE-4972
 URL: https://issues.apache.org/jira/browse/IGNITE-4972
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Vladimir Ozerov


Ignite async API was significantly simplified and refined in Apache Ignite 2.0 
(IGNITE-4475). The changes have to be documented on readme.io.

[~vozerov], [~taras.ledkov], please decide who will document the changes and 
assign the ticket on me for the final review. This is a 2.0 copy of an existing 
page ready for the modification:
https://dash.readme.io/project/apacheignite/v1.9/docs/asynchronous-support-20





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

[jira] [Created] (IGNITE-4971) Document how heartbeats are issued across the cluster ring

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4971:
---

 Summary: Document how heartbeats are issued across the cluster ring
 Key: IGNITE-4971
 URL: https://issues.apache.org/jira/browse/IGNITE-4971
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Denis Magda


{{TcpDiscoverySpi.heartbeatsFrequency}} was removed from the API (IGNITE-4799). 
Let's update TcpDiscoverySpi page and explain how the heartbeats are issued 
across the cluster ring.
https://dash.readme.io/project/apacheignite/v1.9/docs/cluster-configuration-20




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

[jira] [Created] (IGNITE-4970) Document all transactional methods

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4970:
---

 Summary: Document all transactional methods
 Key: IGNITE-4970
 URL: https://issues.apache.org/jira/browse/IGNITE-4970
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Denis Magda
Priority: Minor


Refer to IGNITE-4795 to get a list of transactional methods that have to be 
documented on: 
https://dash.readme.io/project/apacheignite/v1.9/docs/transactions-20



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

[jira] [Created] (IGNITE-4969) Document all available thread pools including custom ones

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4969:
---

 Summary: Document all available thread pools including custom ones
 Key: IGNITE-4969
 URL: https://issues.apache.org/jira/browse/IGNITE-4969
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Vladimir Ozerov


In Apache Ignite 2.0 we introduced custom thread pools API that can be used 
along with Compute Grid.

Having this it makes sense to document all the pools we have:
* system
* public
* marshalling
* service
* custom
* etc.

[~vozerov], could you or someone who developed the custom pools document them 
there?
https://dash.readme.io/project/apacheignite/v1.9/docs/thread-pools

After that reassign the ticket on me and I'll document the rest of the pools.



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

[jira] [Created] (IGNITE-4968) Document Spring Data Integration

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4968:
---

 Summary: Document Spring Data Integration
 Key: IGNITE-4968
 URL: https://issues.apache.org/jira/browse/IGNITE-4968
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Denis Magda
Priority: Critical


Document Spring Data integration completed as a part of IGNITE-1192.



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

[jira] [Created] (IGNITE-4967) Document Index related commands of DDL

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4967:
---

 Summary: Document Index related commands of DDL
 Key: IGNITE-4967
 URL: https://issues.apache.org/jira/browse/IGNITE-4967
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Vladimir Ozerov
Priority: Critical


The first set of DDL commands is released in Apache Ignite 2.0. It will be 
possible to define and alter indexes using standard DDL statements 
(IGNITE-4565).

[~vozerov], [~al.psc], please decide who will document this capability:
https://dash.readme.io/project/apacheignite/v1.9/docs/distributed-ddl

Assign the ticket to me for final modifications because we will be required to 
update "schema and indexes" pages somehow (I'll do that):
https://apacheignite.readme.io/docs/indexes




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

[jira] [Updated] (IGNITE-4965) Document enum fileds handling and changes with 'select * ...' in SQL

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4965:

Description: 
Document the following:
* enum fields handling in SQL (IGNITE-3596)
* _key and _val are no longer returned in "select *..." result set (IGNITE-3487)

Readme page:
https://dash.readme.io/project/apacheignite/v1.9/docs/distributed-queries-20

  was:
Document the following:
* enum fields handling in SQL (IGNITE-3596)
* _key and _val are no longer returned in "select *..." result set (IGNITE-3487)


> Document enum fileds handling and changes with 'select * ...' in SQL 
> -
>
> Key: IGNITE-4965
> URL: https://issues.apache.org/jira/browse/IGNITE-4965
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 2.0
>
>
> Document the following:
> * enum fields handling in SQL (IGNITE-3596)
> * _key and _val are no longer returned in "select *..." result set 
> (IGNITE-3487)
> Readme page:
> https://dash.readme.io/project/apacheignite/v1.9/docs/distributed-queries-20



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

[jira] [Updated] (IGNITE-4966) Document SQL index hints and merge sort capabilities

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4966:

Description: 
Document the following:
* SQL hints usage (IGNITE-4594)
* Merge sort (IGNITE-3013)

Readme page:
https://dash.readme.io/project/apacheignite/v1.9/docs/distributed-queries-20

  was:
Document the following:
* SQL hints usage (IGNITE-4594)
* Merge sort (IGNITE-3013)


> Document SQL index hints and merge sort capabilities
> 
>
> Key: IGNITE-4966
> URL: https://issues.apache.org/jira/browse/IGNITE-4966
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 2.0
>
>
> Document the following:
> * SQL hints usage (IGNITE-4594)
> * Merge sort (IGNITE-3013)
> Readme page:
> https://dash.readme.io/project/apacheignite/v1.9/docs/distributed-queries-20



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

[jira] [Created] (IGNITE-4966) Document SQL index hints and merge sort capabilities

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4966:
---

 Summary: Document SQL index hints and merge sort capabilities
 Key: IGNITE-4966
 URL: https://issues.apache.org/jira/browse/IGNITE-4966
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Denis Magda


Document the following:
* SQL hints usage (IGNITE-4594)
* Merge sort (IGNITE-3013)



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

[jira] [Created] (IGNITE-4965) Document enum fileds handling and changes with 'select * ...' in SQL

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4965:
---

 Summary: Document enum fileds handling and changes with 'select * 
...' in SQL 
 Key: IGNITE-4965
 URL: https://issues.apache.org/jira/browse/IGNITE-4965
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Denis Magda


Document the following:
* enum fields handling in SQL (IGNITE-3596)
* _key and _val are no longer returned in "select *..." result set (IGNITE-3487)



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

[jira] [Commented] (IGNITE-4927) Write behind - add an option to skip write coalescing

[Alexander Belyak (JIRA)]

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

Alexander Belyak commented on IGNITE-4927:
--

Rewrite solution to increase speed, fix tests

> Write behind - add an option to skip write coalescing
> -
>
> Key: IGNITE-4927
> URL: https://issues.apache.org/jira/browse/IGNITE-4927
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 1.9
>Reporter: Yakov Zhdanov
>Assignee: Yakov Zhdanov
> Fix For: 2.0
>
>
> Currently, the write-behind store is backed by a map, therefore when several 
> updates come to the same key, they are coalesced. 
> We need to introduce optional mode and back write-behind with a queue and 
> pass each  to a database.



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

[jira] [Created] (IGNITE-4964) Document Machine Learning Grid (Distributed Algebra Implementation)

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4964:
---

 Summary: Document Machine Learning Grid (Distributed Algebra 
Implementation)
 Key: IGNITE-4964
 URL: https://issues.apache.org/jira/browse/IGNITE-4964
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Nikita Ivanov


In Apache Ignite 2.0 we introduce support for distributed algebra on top of 
Ignite. This considered to be a foundation of Ignite's Machine Learning 
framework discussed here:
http://apache-ignite-developers.2346864.n4.nabble.com/Adding-ML-to-Ignite-IGNITE-4572-td13936.html

Let's make an overview of the current implementation, its usage, and refer to 
developed examples as a part of the readme.io documentation. Here is an 
invisible page created for this purpose:
https://dash.readme.io/project/apacheignite/v1.9/docs/distributed-algebra

Please assign the ticket on [~dmagda] for the final review.



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

[jira] [Created] (IGNITE-4963) Document cache store metrics based on page memory

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4963:
---

 Summary: Document cache store metrics based on page memory 
 Key: IGNITE-4963
 URL: https://issues.apache.org/jira/browse/IGNITE-4963
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Denis Magda


There is no documentation for the metrics. At the first phase let's document 
cache metrics altered as a part of this task - IGNITE-4536



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

[jira] [Created] (IGNITE-4962) Document New Eviction and Expiration Policies

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4962:
---

 Summary: Document New Eviction and Expiration Policies 
 Key: IGNITE-4962
 URL: https://issues.apache.org/jira/browse/IGNITE-4962
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Denis Magda
Priority: Critical


This following is intended to be done as a part of this ticket:
* refine eviction policy documentation 
(https://apacheignite.readme.io/docs/evictions). Take a look at the changes - 
IGNITE-4534
* make sure everything left unchanged with the expiration policy 
(https://apacheignite.readme.io/docs/expiry-policies)



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

[jira] [Updated] (IGNITE-4961) Document Page Memory API, Architecture and Behavior

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4961:

Description: 
The goal of this ticket is to provide extensive documentation around the new 
page memory architecture introduced in Apache Ignite 2.0.

Refer to IGNITE-3477 and do the following as a part of this ticket:
* page memory architecture, advantages, and usage.
* page memory policies (IGNITE-4960).
* rework or discontinue Off-Heap Memory page 
(https://apacheignite.readme.io/docs/off-heap-memory) that lists all the memory 
tiers supported in versions 1.x. For instance, the swap space is no longer 
available (IGNITE-4736) and the Java heap is no more a default one and used 
just as a cache of the page memory (IGNITE-4535).

Once the Java documentation is ready, assign the ticket to [~ptupitsyn] and 
[~isapego] who will create .NET and C++ counterparts following a Java template.

  was:
The goal of this ticket is to provide extensive documentation around the new 
page memory architecture introduced in Apache Ignite 2.0.

Refer to IGNITE-3477 and do the following as a part of this ticket:
* page memory architecture, advantages, and usage.
* page memory policies (IGNITE-4960).
* rework or discontinue Off-Heap Memory page 
(https://apacheignite.readme.io/docs/off-heap-memory) that lists all the memory 
tiers supported in versions 1.x. For instance, the swap space is no longer 
available (IGNITE-4736) and the Java heap is no more a default one and used 
just as a cache of a page memory (IGNITE-4535).

Once the Java documentation is ready, assign the ticket to [~ptupitsyn] and 
[~isapego] who will create .NET and C++ counterparts following a Java template.


> Document Page Memory API, Architecture and Behavior
> ---
>
> Key: IGNITE-4961
> URL: https://issues.apache.org/jira/browse/IGNITE-4961
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Blocker
> Fix For: 2.0
>
>
> The goal of this ticket is to provide extensive documentation around the new 
> page memory architecture introduced in Apache Ignite 2.0.
> Refer to IGNITE-3477 and do the following as a part of this ticket:
> * page memory architecture, advantages, and usage.
> * page memory policies (IGNITE-4960).
> * rework or discontinue Off-Heap Memory page 
> (https://apacheignite.readme.io/docs/off-heap-memory) that lists all the 
> memory tiers supported in versions 1.x. For instance, the swap space is no 
> longer available (IGNITE-4736) and the Java heap is no more a default one and 
> used just as a cache of the page memory (IGNITE-4535).
> Once the Java documentation is ready, assign the ticket to [~ptupitsyn] and 
> [~isapego] who will create .NET and C++ counterparts following a Java 
> template.



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

[jira] [Created] (IGNITE-4961) Document Page Memory API, Architecture and Behavior

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4961:
---

 Summary: Document Page Memory API, Architecture and Behavior
 Key: IGNITE-4961
 URL: https://issues.apache.org/jira/browse/IGNITE-4961
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Denis Magda
Priority: Blocker


The goal of this ticket is to provide extensive documentation around the new 
page memory architecture introduced in Apache Ignite 2.0.

Refer to IGNITE-3477 and do the following as a part of this ticket:
* page memory architecture, advantages, and usage.
* page memory policies (IGNITE-4960).
* rework or discontinue Off-Heap Memory page 
(https://apacheignite.readme.io/docs/off-heap-memory) that lists all the memory 
tiers supported in versions 1.x. For instance, the swap space is no longer 
available (IGNITE-4736) and the Java heap is no more a default one and used 
just as a cache of a page memory (IGNITE-4535).

Once the Java documentation is ready, assign the ticket to [~ptupitsyn] and 
[~isapego] who will create .NET and C++ counterparts following a Java template.



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

[jira] [Created] (IGNITE-4960) Apache Ignite 2.0 Documentation

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4960:
---

 Summary: Apache Ignite 2.0 Documentation
 Key: IGNITE-4960
 URL: https://issues.apache.org/jira/browse/IGNITE-4960
 Project: Ignite
  Issue Type: Task
Reporter: Denis Magda
Assignee: Denis Magda
Priority: Critical
 Fix For: 2.0


This is an umbrella ticket for all the documentation that has to be prepared or 
updated as a part of Apache Ignite 2.0 release.



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

[jira] [Commented] (IGNITE-4182) Improve error output when query parsing failed.

[Alexei Kaigorodov (JIRA)]

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

Alexei Kaigorodov commented on IGNITE-4182:
---

the poor diagnostics goes from the H2 jdbc driver.

> Improve error output when query parsing failed.
> ---
>
> Key: IGNITE-4182
> URL: https://issues.apache.org/jira/browse/IGNITE-4182
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 1.7
>Reporter: Igor Sapego
>Priority: Minor
> Fix For: 2.1
>
>
> There is no enough information in the exception when SLQ query can not be 
> parsed. In most cases we get something like this:
> {noformat}
> Failed to execute SQL query [reqId=2, req=OdbcQueryExecuteRequest 
> [cacheName=cache, sqlQry=SELECT a FROM B, args=[]]]
> javax.cache.CacheException: class org.apache.ignite.IgniteException: Failed 
> to parse query: SELECT a FROM B
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:740)
> at 
> org.apache.ignite.internal.processors.odbc.OdbcRequestHandler.executeQuery(OdbcRequestHandler.java:193)
> at 
> org.apache.ignite.internal.processors.odbc.OdbcRequestHandler.handle(OdbcRequestHandler.java:104)
> at 
> org.apache.ignite.internal.processors.odbc.OdbcNioListener.onMessage(OdbcNioListener.java:124)
> at 
> org.apache.ignite.internal.processors.odbc.OdbcNioListener.onMessage(OdbcNioListener.java:33)
> at 
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:270)
> at 
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:107)
> at 
> org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:95)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at 
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: class org.apache.ignite.IgniteException: Failed to parse query: 
> SELECT a FROM B
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.queryTwoStep(GridQueryProcessor.java:749)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:728)
> ... 12 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to parse 
> query: SELECT a FROM B
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:1695)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.queryTwoStep(GridQueryProcessor.java:742)
> ... 13 more
> Caused by: class 
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to 
> parse query: SELECT a FROM B
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryTwoStep0(IgniteH2Indexing.java:1887)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryTwoStep(IgniteH2Indexing.java:1793)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:744)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:742)
> at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:1672)
> ... 14 more
> {noformat}
> In this particular case, for example, we do not have table "B", nor we have 
> column "a", but you can't get it from the exception.



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

[jira] [Comment Edited] (IGNITE-4565) Support CREATE INDEX DDL statements

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-4565 at 4/13/17 4:04 PM:
--

Outstanding issues:
1) Merge with 3477
2) Fix client reconnect schema consistency issue
3) Fix DROP INDEX data consistency issue (+ add more concurrent data tests).


was (Author: vozerov):
Outstanding issues:
1) Merge with 3477
2) Fix client reconnect schema consistency issue
3) Fix DROP INDEX data consistency issue (+ add more concurrent data tests)
4) Long chains could lead to exchange thread starvation. Break the loop!

> Support CREATE INDEX DDL statements
> ---
>
> Key: IGNITE-4565
> URL: https://issues.apache.org/jira/browse/IGNITE-4565
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache, SQL
>Reporter: Alexander Paschenko
>Assignee: Vladimir Ozerov
>  Labels: important
> Fix For: 2.0
>
>
> We need to implement support for dynamic {{CREATE INDEX}} and {{DROP INDEX}} 
> invocations.
> Design document: 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=67640367
> Base branch: {{ignite-4565}}



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

[jira] [Commented] (IGNITE-3488) Prohibit null as name in all the components (cache name first of all).

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3488:


GitHub user gvvinblade opened a pull request:

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

IGNITE-3488



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

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

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

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


commit ba95cc4a122e6c10057f53c7aa4646675996c68b
Author: Igor Seliverstov 
Date:   2017-04-13T11:48:41Z

[IGNITE-3488] Prohibit null as name in all the components (cache name first 
of all).

commit fc501297b2209a3f9ddd0a641790501472fb3612
Author: Igor Seliverstov 
Date:   2017-04-13T15:45:44Z

Merge remote-tracking branch 'professional/ignite-3488'

commit 8d1e2b315cf20d0f09ecaff68c33d94135956011
Author: Igor Seliverstov 
Date:   2017-04-13T11:48:41Z

[IGNITE-3488] Prohibit null as name in all the components (cache name first 
of all).

commit 10395f6bd6aea372ce29e59a323e2a7f68bdc11f
Author: Igor Seliverstov 
Date:   2017-04-13T15:44:00Z

[IGNITE-3488] Prohibit null as name in all the components (cache name first 
of all).




> Prohibit null as name in all the components (cache name first of all).
> --
>
> Key: IGNITE-3488
> URL: https://issues.apache.org/jira/browse/IGNITE-3488
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.8
>Reporter: Sergi Vladykin
>Assignee: Igor Seliverstov
>Priority: Critical
>  Labels: important
> Fix For: 2.0
>
>
> Need to create a list of all the affected components.
> 2.0 migration guide has to be updated: 
> 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-3524) IGFS: Do not allow nulls for FileSystemConfiguration.name.

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-3524:
--

Waits for TC 
[results|http://195.239.208.174/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull%2F1789%2Fhead]

> IGFS: Do not allow nulls for FileSystemConfiguration.name.
> --
>
> Key: IGNITE-3524
> URL: https://issues.apache.org/jira/browse/IGNITE-3524
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> As a part of our general approach, let's do not allow nulls as IGFS names.



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

[jira] [Commented] (IGNITE-3524) IGFS: Do not allow nulls for FileSystemConfiguration.name.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3524:


GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-3524  IGFS: Do not allow nulls for FileSystemConfiguration.name



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

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

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

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


commit cc5de23a26ba3cb93a209e66741e114db5228343
Author: tledkov-gridgain 
Date:   2017-04-13T10:18:07Z

IGNITE-3524 IGFS: Do not allow nulls for FileSystemConfiguration.name

commit 05eca2e19f9036cac0198eef7da74674ff2623da
Author: tledkov-gridgain 
Date:   2017-04-13T14:10:50Z

IGNITE-3524 IGFS: Do not allow nulls for FileSystemConfiguration.name




> IGFS: Do not allow nulls for FileSystemConfiguration.name.
> --
>
> Key: IGNITE-3524
> URL: https://issues.apache.org/jira/browse/IGNITE-3524
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> As a part of our general approach, let's do not allow nulls as IGFS names.



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

[jira] [Comment Edited] (IGNITE-4943) Web Console: Improve design of tables with grouping on Admin Panel screen

[Vica Abramova (JIRA)]

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

Vica Abramova edited comment on IGNITE-4943 at 4/13/17 3:17 PM:


Also please fix:
1. Delete checkbox on collapsed items on Admin Panel screen
2. Add tooltip to the disabled checkbox "Select all' - You can select only one 
user.
3. If user filter the data, on "Select all" action we should select only 
filtered items.
4. Add tooltip to the Export btn - Export this data.


was (Author: vabramova):
Also please fix:
1. Delete checkbox on collapsed items on Admin Panel screen
2. Add tooltip to the disabled checkbox "Select all' - You can select only one 
user.
3. If user filter the data, on "Select all" action we should select only 
filtered items.

> Web Console: Improve design of tables with grouping on Admin Panel screen
> -
>
> Key: IGNITE-4943
> URL: https://issues.apache.org/jira/browse/IGNITE-4943
> Project: Ignite
>  Issue Type: Sub-task
>  Components: UI, wizards
>Affects Versions: 1.9
>Reporter: Andrey Novikov
>Assignee: Dmitriy Shabalin
> Attachments: Advanced Table.png
>
>




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

[jira] [Updated] (IGNITE-4959) Possible slight memory leak in free list

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-4959:
---
Description: 
To reproduce, run PageEvictionMultinodeTest (any eviction mode), set ENTRIES to 
Integer.MAX_VALUE.
Observations:
1) After a few minutes of test running, number of allocated pages looks like a 
constant (a bit more than eviciton threshold, 90% by default). This is expected 
behaviour with enabled page eviction.
2) More precise measurement shows that there's slow linear growth of allocated 
pages number, literally 10-20 pages per minute.
3) Number of pages with type T_PAGE_LIST_NODE grows, number of all other pages 
remains constant.
4) Though, total number of data pages in free list remains constant (with minor 
fluctuations).
We have to find out whether this process has a saturation point, after which 
pages number stops growing. Otherwise, it's a memory leak and should be fixed.

  was:
To reproduce, run PageEvictionMultinodeTest (any eviction mode), set ENTRIES to 
Integer.MAX_VALUE.
Observations:
1) After a few minutes of test running, number of allocated pages looks like a 
constant (a bit more than eviciton threshold, 90% by default). This is expected 
behaviour with enabled page eviction.
2) More precise measurement shows that there's slow linear growth of allocated 
pages number, literally 10-20 pages per minute.
3) Number of pages with type T_PAGE_LIST_NODE grows, number of all other pages 
remains constant.
4) Though, total number of pages in free list remains constant (with minor 
fluctuations).
We have to find out whether this process has a saturation point, after which 
pages number stops growing. Otherwise, it's a memory leak and should be fixed.


> Possible slight memory leak in free list
> 
>
> Key: IGNITE-4959
> URL: https://issues.apache.org/jira/browse/IGNITE-4959
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.0
>Reporter: Ivan Rakov
>Assignee: Alexey Goncharuk
>
> To reproduce, run PageEvictionMultinodeTest (any eviction mode), set ENTRIES 
> to Integer.MAX_VALUE.
> Observations:
> 1) After a few minutes of test running, number of allocated pages looks like 
> a constant (a bit more than eviciton threshold, 90% by default). This is 
> expected behaviour with enabled page eviction.
> 2) More precise measurement shows that there's slow linear growth of 
> allocated pages number, literally 10-20 pages per minute.
> 3) Number of pages with type T_PAGE_LIST_NODE grows, number of all other 
> pages remains constant.
> 4) Though, total number of data pages in free list remains constant (with 
> minor fluctuations).
> We have to find out whether this process has a saturation point, after which 
> pages number stops growing. Otherwise, it's a memory leak and should be fixed.



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

[jira] [Updated] (IGNITE-4959) Possible slight memory leak in free list

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-4959:
---
Description: 
To reproduce, run PageEvictionMultinodeTest (any eviction mode), set ENTRIES to 
Integer.MAX_VALUE.
Observations:
1) After a few minutes of test running, number of allocated pages looks like a 
constant (a bit more than eviciton threshold, 90% by default). This is expected 
behaviour with enabled page eviction.
2) More precise measurement shows that there's slow linear growth of allocated 
pages number, literally 10-20 pages per minute.
3) Number of pages with type T_PAGE_LIST_NODE grows, number of all other pages 
remains constant.
4) Though, total number of pages in free list remains constant (with minor 
fluctuations).
We have to find out whether this process has a saturation point, after which 
pages number stops growing. Otherwise, it's a memory leak and should be fixed.

  was:
To reproduce, run PageEvictionMultinodeTest (any eviction mode), set ENTRIES to 
Integer.MAX_VALUE.
Observations:
1) After a few minutes of test running, number of allocated pages looks like a 
constant (a bit more than eviciton threshold, 90% by default). This is expected 
behaviour with enabled page eviction.
2) More precise measurement shows that there's slow linear growth of allocated 
pages number, literally 10-20 pages per minute.
3) Number of pages with type T_PAGE_LIST_NODE grows, number of all other pages 
remains constant.
4) Though, total number of pages in free list remains constant (with minor 
fluctuations).
We have to find out whether this process has a saturation point, after which 
pages number stop growing. Otherwise, it's a memory leak and should be fixed.


> Possible slight memory leak in free list
> 
>
> Key: IGNITE-4959
> URL: https://issues.apache.org/jira/browse/IGNITE-4959
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.0
>Reporter: Ivan Rakov
>Assignee: Alexey Goncharuk
>
> To reproduce, run PageEvictionMultinodeTest (any eviction mode), set ENTRIES 
> to Integer.MAX_VALUE.
> Observations:
> 1) After a few minutes of test running, number of allocated pages looks like 
> a constant (a bit more than eviciton threshold, 90% by default). This is 
> expected behaviour with enabled page eviction.
> 2) More precise measurement shows that there's slow linear growth of 
> allocated pages number, literally 10-20 pages per minute.
> 3) Number of pages with type T_PAGE_LIST_NODE grows, number of all other 
> pages remains constant.
> 4) Though, total number of pages in free list remains constant (with minor 
> fluctuations).
> We have to find out whether this process has a saturation point, after which 
> pages number stops growing. Otherwise, it's a memory leak and should be fixed.



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

[jira] [Created] (IGNITE-4959) Possible slight memory leak in free list

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-4959:
--

 Summary: Possible slight memory leak in free list
 Key: IGNITE-4959
 URL: https://issues.apache.org/jira/browse/IGNITE-4959
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 2.0
Reporter: Ivan Rakov
Assignee: Alexey Goncharuk


To reproduce, run PageEvictionMultinodeTest (any eviction mode), set ENTRIES to 
Integer.MAX_VALUE.
Observations:
1) After a few minutes of test running, number of allocated pages looks like a 
constant (a bit more than eviciton threshold, 90% by default). This is expected 
behaviour with enabled page eviction.
2) More precise measurement shows that there's slow linear growth of allocated 
pages number, literally 10-20 pages per minute.
3) Number of pages with type T_PAGE_LIST_NODE grows, number of all other pages 
remains constant.
4) Though, total number of pages in free list remains constant (with minor 
fluctuations).
We have to find out whether this process has a saturation point, after which 
pages number stop growing. Otherwise, it's a memory leak and should be fixed.



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

[jira] [Commented] (IGNITE-3920) Hadoop: remove PayloadAware interface.

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-3920:
--

Pavel, please test HDFS + IGFS + folders and files with different modes.

> Hadoop: remove PayloadAware interface.
> --
>
> Key: IGNITE-3920
> URL: https://issues.apache.org/jira/browse/IGNITE-3920
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Pavel Konstantinov
> Fix For: 2.0
>
>
> When IGNITE-3376 is ready, we will be able to execute {{PROXY}} operations 
> directly from {{IgfsImpl}}. It means that we no longer need 
> {{HadoopPayloadAware}} interface, and we no longer need to pass {{IgfsPaths}} 
> to the client. 
> Let's remove them all together.



--
This message was sent by Atlassian JIRA
(v6.3.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=15967679#comment-15967679
 ] 

Alexander Menshikov commented on IGNITE-4501:
-

[~yzhdanov]
I do my best. I hope I will manage to do it before 2.0 release. Problem in 
ServerImpl.RingMessageWorker#processNodeAddedMessage() with NPE in lines:

DiscoveryDataPacket dataPacket = msg.gridDiscoveryData();
if (dataPacket.hasJoiningNodeData())
   //^___Here, because dataPacket is null

I can fix it if remove one line:

msg.clearDiscoveryData();

#processNodeAddedMessage() is real complex, it's take a while to understand 
what going on in here.

> 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] [Assigned] (IGNITE-3920) Hadoop: remove PayloadAware interface.

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-3920:


Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

> Hadoop: remove PayloadAware interface.
> --
>
> Key: IGNITE-3920
> URL: https://issues.apache.org/jira/browse/IGNITE-3920
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Pavel Konstantinov
> Fix For: 2.0
>
>
> When IGNITE-3376 is ready, we will be able to execute {{PROXY}} operations 
> directly from {{IgfsImpl}}. It means that we no longer need 
> {{HadoopPayloadAware}} interface, and we no longer need to pass {{IgfsPaths}} 
> to the client. 
> Let's remove them all together.



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

[jira] [Assigned] (IGNITE-4937) Transactions deadlock detection should happen on each grid hang

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov reassigned IGNITE-4937:


Assignee: Anton Vinogradov

> Transactions deadlock detection should happen on each grid hang
> ---
>
> Key: IGNITE-4937
> URL: https://issues.apache.org/jira/browse/IGNITE-4937
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Critical
>
> Each "Failed to wait for partition map exchange" or similar should cause such 
> check. 
> Check can be added to 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager#dumpPendingObjects
> or/and
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager#dumpLongRunningOperations



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

[jira] [Updated] (IGNITE-4765) Different partition mapping for caches that use Fair Affinity Function

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4765:
-
Attachment: PartitionDsitributionTest.java

> Different partition mapping for caches that use Fair Affinity Function
> --
>
> Key: IGNITE-4765
> URL: https://issues.apache.org/jira/browse/IGNITE-4765
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Alper Tekinalp
> Attachments: PartitionDsitributionTest.java
>
>
> Caches created on different topology versions with fair affinity funtion may 
> have different partition mapping. The cause of this problem is fair affinity 
> function calculates partition mappings based on previous assignments. When 
> rebalancing partitions previous assignments for a cache is known and new 
> assignment calculated based on that. But when you create a new cache there is 
> no previous assignments and the calculation is different. 
> Reproduction steps:
> - Start node1
> - Start cache1
> - Start node2
> - Partitions for cache1 will be rebalanced
> - Start cache2
> - Check partition mapping for both cache1 and cache2



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

[jira] [Commented] (IGNITE-4626) GridDhtPartitionTopologyImpl refactoring

[Konstantin Dudkov (JIRA)]

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

Konstantin Dudkov commented on IGNITE-4626:
---

Benchmarks results:
|| ||rev: 8c9c60a4 (master)  ||rev: 203aab4a || ||
|atomic-put|137036|137615|0.42%|
|atomic-put-get|79112.3|81368|2.85%|
|atomic-put-get-offheap |70257.1|70508.2 |0.36%|
|atomic-put-get-offheap-val |81270.7|82938.2 |2.05%|
|atomic-put-getEntry |79817.4|80136.3 |0.40%|
|atomic-put-offheap |115548|117102 |1.34%|
|atomic-put-offheap-val |144856|146466 |1.11%|
|atomic-putAll |3558.9|4703.62 |32.16%|


> GridDhtPartitionTopologyImpl refactoring
> 
>
> Key: IGNITE-4626
> URL: https://issues.apache.org/jira/browse/IGNITE-4626
> Project: Ignite
>  Issue Type: Task
>Reporter: Konstantin Dudkov
>Assignee: Konstantin Dudkov
> Fix For: 2.1
>
>
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#nodes(int,
>  org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion)
> Need to refactor this method to use Object[] - partId->List



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

[jira] [Comment Edited] (IGNITE-4211) Update Spring dependency to latest stable version

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov edited comment on IGNITE-4211 at 4/13/17 2:11 PM:
---

Another case is to make putIfAbsent(VALUE_IN_PROGRESS).
Where VALUE_IN_PROGRESS similar to
private static final Object NULL = new NullValue();
But, in this case we have to write node failed failover and etc. 


was (Author: avinogradov):
Another case is to make putIfAbsent(VALUE_IN_PROGRESS).
Where VALUE_IN_PROGRESS similar to
private static final Object NULL = new NullValue();
But, in this case we have to write node failed failover ant etc. 

> Update Spring dependency to latest stable version
> -
>
> Key: IGNITE-4211
> URL: https://issues.apache.org/jira/browse/IGNITE-4211
> Project: Ignite
>  Issue Type: Improvement
>  Components: build
>Affects Versions: 1.7
>Reporter: Sergey Kozlov
>Assignee: Vyacheslav Daradur
> Fix For: 2.0
>
>
> It seems the Spring dependency looks outdated for now. Apache Ignite still 
> uses 4.1.0 released two years ago. Could we to update to latest stable 
> version (4.3.4 at the moment)?



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

[jira] [Comment Edited] (IGNITE-4211) Update Spring dependency to latest stable version

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov edited comment on IGNITE-4211 at 4/13/17 2:10 PM:
---

Another case is to make putIfAbsent(VALUE_IN_PROGRESS).
Where VALUE_IN_PROGRESS similar to
private static final Object NULL = new NullValue();
But, in this case we have to write node failed failover ant etc. 


was (Author: avinogradov):
Another case is to make putIfAbsent(VALUE_IN_PROGRESS).
But, in this case we have to write node failed failover ant etc. 

> Update Spring dependency to latest stable version
> -
>
> Key: IGNITE-4211
> URL: https://issues.apache.org/jira/browse/IGNITE-4211
> Project: Ignite
>  Issue Type: Improvement
>  Components: build
>Affects Versions: 1.7
>Reporter: Sergey Kozlov
>Assignee: Vyacheslav Daradur
> Fix For: 2.0
>
>
> It seems the Spring dependency looks outdated for now. Apache Ignite still 
> uses 4.1.0 released two years ago. Could we to update to latest stable 
> version (4.3.4 at the moment)?



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

[jira] [Commented] (IGNITE-4211) Update Spring dependency to latest stable version

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-4211:
--

Another case is to make putIfAbsent(VALUE_IN_PROGRESS).
But, in this case we have to write node failed failover ant etc. 

> Update Spring dependency to latest stable version
> -
>
> Key: IGNITE-4211
> URL: https://issues.apache.org/jira/browse/IGNITE-4211
> Project: Ignite
>  Issue Type: Improvement
>  Components: build
>Affects Versions: 1.7
>Reporter: Sergey Kozlov
>Assignee: Vyacheslav Daradur
> Fix For: 2.0
>
>
> It seems the Spring dependency looks outdated for now. Apache Ignite still 
> uses 4.1.0 released two years ago. Could we to update to latest stable 
> version (4.3.4 at the moment)?



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

[jira] [Created] (IGNITE-4958) Make data pages recyclable into index/meta/etc pages and vice versa

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-4958:
--

 Summary: Make data pages recyclable into index/meta/etc pages and 
vice versa
 Key: IGNITE-4958
 URL: https://issues.apache.org/jira/browse/IGNITE-4958
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 2.0
Reporter: Ivan Rakov
Assignee: Alexey Goncharuk


Recycling for data pages is disabled for now. Empty data pages are accumulated 
in FreeListImpl#emptyDataPagesBucket, and can be reused only as data pages 
again. What has to be done:
* Empty data pages should be recycled into reuse bucket
* We should check reuse bucket first before allocating a new data page
* MemoryPolicyConfiguration#emptyPagesPoolSize should be removed



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

[jira] [Commented] (IGNITE-4952) Swapping-related Event Types must be deleted

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4952:


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

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

IGNITE-4952 swap/unswap functionality was removed



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

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

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

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


commit f418736964f96d2215193c63c1e7c04f2bc755ef
Author: Sergey Chugunov 
Date:   2017-04-12T14:31:37Z

IGNITE-4952 obsolete Event Types were removed, onSwap/onUnswap methods were 
removed from Query processor/manager as well




> Swapping-related Event Types must be deleted
> 
>
> Key: IGNITE-4952
> URL: https://issues.apache.org/jira/browse/IGNITE-4952
> Project: Ignite
>  Issue Type: Task
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>
> h2. Notes
> As swap storage was removed in 
> [IGNITE-3477|https://issues.apache.org/jira/browse/IGNITE-3477] there is no 
> need to keep swap-related Event Types in ignite codebase.
> h2. Acceptance Criteria
> # Swap-related Event Types are removed from EventType enum.
> # All tests verifying swap functionality are removed from tests set.



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

[jira] [Updated] (IGNITE-4052) Add ability to set up users for MESOS

[Nikolai Tikhonov (JIRA)]

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

Nikolai Tikhonov updated IGNITE-4052:
-

Vadim,

I've left comment in the ticket.

On Wed, Apr 12, 2017 at 3:00 PM, Вадим Опольский 



> Add ability to set up users for MESOS
> -
>
> Key: IGNITE-4052
> URL: https://issues.apache.org/jira/browse/IGNITE-4052
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.7
>Reporter: Nikolay Tikhonov
>Assignee: Vadim Opolski
>Priority: Trivial
>
> In current implementation Ignite Mesos Framework connects to MESOS cluster 
> via current user. Need to add ability to configure this parameters via system 
> env properties. Also need to add properties for mesos role.
> See org/apache/ignite/mesos/IgniteFramework.java:537



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

Yakov Zhdanov commented on IGNITE-4501:
---

[~sharpler], thanks for the update! When we do you think we can expect the fix? 
This issue is a good candidate for merging to 2.0.

> 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] [Commented] (IGNITE-4052) Add ability to set up users for MESOS

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-4052:
--

[~javaller]
Let's just in test override {{getUser}} and {{getRole}} methods. It should be 
enough for this feature.
Also did you test this locally? It's really works? We need to understand which 
exception user will get if user name and/or role incorrect.

> Add ability to set up users for MESOS
> -
>
> Key: IGNITE-4052
> URL: https://issues.apache.org/jira/browse/IGNITE-4052
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.7
>Reporter: Nikolay Tikhonov
>Assignee: Vadim Opolski
>Priority: Trivial
>
> In current implementation Ignite Mesos Framework connects to MESOS cluster 
> via current user. Need to add ability to configure this parameters via system 
> env properties. Also need to add properties for mesos role.
> See org/apache/ignite/mesos/IgniteFramework.java:537



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

[jira] [Updated] (IGNITE-4956) Stabilize the test IgniteCacheLockPartitionOnAffinityRunAtomicCacheOpTest.testNotReservedTxCacheOp

[Taras Ledkov (JIRA)]

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

Taras Ledkov updated IGNITE-4956:
-
Description: 
Stabilize  the test 
*IgniteCacheLockPartitionOnAffinityRunAtomicCacheOpTest.testNotReservedTxCacheOp*

The test periodically failed with the message:

{code}
org.apache.ignite.IgniteCheckedException: Failed partition reservation. 
Partition is not primary on the node. [partition=12, cacheName=Person, 
nodeId=bf014a48-7032-4b72-9d00-d8a76551, topology=AffinityTopologyVersion 
[topVer=9, minorTopVer=0]] at 
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7172) at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:170)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:119)
 at 
org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:95)
 at 
org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:271)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListeners(GridFutureAdapter.java:259)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:389)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:355)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:343)
 at org.apache.ignite.testframework.GridTestUtils$6.run(GridTestUtils.java:858) 
at 
org.apache.ignite.testframework.GridTestUtils$8.call(GridTestUtils.java:1149) 
at org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86) 
Caused by: org.apache.ignite.IgniteException: Failed partition reservation. 
Partition is not primary on the node. [partition=12, cacheName=Person, 
nodeId=bf014a48-7032-4b72-9d00-d8a76551, topology=AffinityTopologyVersion 
[topVer=9, minorTopVer=0]] at 
org.apache.ignite.internal.processors.job.GridJobProcessor$PartitionsReservation.reserve(GridJobProcessor.java:1572)
 at 
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:504)
 at 
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:483)
 at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) 
at 
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1180)
 at 
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1894)
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1228)
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:856)
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$2100(GridIoManager.java:111)
 at 
org.apache.ignite.internal.managers.communication.GridIoManager$7.run(GridIoManager.java:798)
 at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
at java.lang.Thread.run(Thread.java:745) --- Stdout: ---
{code}


  was:
The test periodically failed with the message:

{code}
org.apache.ignite.IgniteCheckedException: Failed partition reservation. 
Partition is not primary on the node. [partition=12, cacheName=Person, 
nodeId=bf014a48-7032-4b72-9d00-d8a76551, topology=AffinityTopologyVersion 
[topVer=9, minorTopVer=0]] at 
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7172) at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:170)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:119)
 at 
org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:95)
 at 
org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:271)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListeners(GridFutureAdapter.java:259)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:389)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:355)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:343)
 at org.apache.ignite.testframework.GridTestUtils$6.run(GridTestUtils.java:858) 
at 
org.apache.ignite.testframework.GridTestUtils$8.call(GridTestUtils.java:1149) 
at org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86) 
Caused by: org.apache.ignite.IgniteException: Failed partition reservation. 
Partition is not primary 

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

Alexander Menshikov commented on IGNITE-4501:
-

[~yzhdanov]
I have fixed the bug. It was data race operation with local Node's internal 
order in ServerImpl. This code not mine so I don't know why it's work in 
master. Anyway after my fix this test became totally stable. But I found error 
in my test. It's strange because I checked for errors before make PR. Perhaps, 
something broke after merge with 2.0. I need more time for fix it.

> 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] [Commented] (IGNITE-4211) Update Spring dependency to latest stable version

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-4211:
--

[~daradurvs]
Please checks EhCacheCache.java at Spring's default impls. 
It can suits.

> Update Spring dependency to latest stable version
> -
>
> Key: IGNITE-4211
> URL: https://issues.apache.org/jira/browse/IGNITE-4211
> Project: Ignite
>  Issue Type: Improvement
>  Components: build
>Affects Versions: 1.7
>Reporter: Sergey Kozlov
>Assignee: Vyacheslav Daradur
> Fix For: 2.0
>
>
> It seems the Spring dependency looks outdated for now. Apache Ignite still 
> uses 4.1.0 released two years ago. Could we to update to latest stable 
> version (4.3.4 at the moment)?



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3018:


Github user tledkov-gridgain closed the pull request at:

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


> 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: Taras Ledkov
>  Labels: important
> Fix For: 2.0
>
> Attachments: 003.png, 004.png, 008.png, 016.png, 064.png, 100.png, 
> 128.png, 200.png, 256.png, 400.png, 600.png, balanced.003.png, 
> balanced.004.png, balanced.008.png, balanced.016.png, balanced.064.png, 
> balanced.100.png, balanced.128.png, balanced.200.png, balanced.256.png, 
> balanced.400.png, balanced.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] [Updated] (IGNITE-4957) First join query execution in client mode takes too long when there are many caches on remote nodes

[Alexandr Fedotov (JIRA)]

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

Alexandr Fedotov updated IGNITE-4957:
-
Description: 
When there are many caches deployed on server nodes and a query containing 
joins is executed on a client for the first time then it takes much time to 
complete compared to the following executions.

If caches aren't enabled locally then the first query tries to load all the 
missing caches by calling
{{org.apache.ignite.internal.processors.cache.GridCacheProcessor#createMissingCaches}}
{{createMissingCaches}} internally sends a request per each registered but not 
enabled cache.
Performance could be improved by performing a batch request.

VisualVM results for the first join query run are below
!first_run_from_client.png!

  was:
When there are many caches deployed on server nodes and a query containing 
joins is executed on a client for the first time then it takes much time to 
complete compared to the following executions.

If caches aren't enabled locally then the first query tries to load all the 
missing caches by calling
{{org.apache.ignite.internal.processors.cache.GridCacheProcessor#createMissingCaches}}
{{createMissingCaches}} internally sends a request per each registered but not 
enabled cache.
Performance could be improved by performing a batch request.




> First join query execution in client mode takes too long when there are many 
> caches on remote nodes
> ---
>
> Key: IGNITE-4957
> URL: https://issues.apache.org/jira/browse/IGNITE-4957
> Project: Ignite
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 1.9
>Reporter: Alexandr Fedotov
>  Labels: performance
> Fix For: 2.1
>
> Attachments: first_run_from_client.png
>
>
> When there are many caches deployed on server nodes and a query containing 
> joins is executed on a client for the first time then it takes much time to 
> complete compared to the following executions.
> If caches aren't enabled locally then the first query tries to load all the 
> missing caches by calling
> {{org.apache.ignite.internal.processors.cache.GridCacheProcessor#createMissingCaches}}
> {{createMissingCaches}} internally sends a request per each registered but 
> not enabled cache.
> Performance could be improved by performing a batch request.
> VisualVM results for the first join query run are below
> !first_run_from_client.png!



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

[jira] [Updated] (IGNITE-4957) First join query execution in client mode takes too long when there are many caches on remote nodes

[Alexandr Fedotov (JIRA)]

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

Alexandr Fedotov updated IGNITE-4957:
-
Attachment: first_run_from_client.png

First join query run on a client

> First join query execution in client mode takes too long when there are many 
> caches on remote nodes
> ---
>
> Key: IGNITE-4957
> URL: https://issues.apache.org/jira/browse/IGNITE-4957
> Project: Ignite
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 1.9
>Reporter: Alexandr Fedotov
>  Labels: performance
> Fix For: 2.1
>
> Attachments: first_run_from_client.png
>
>
> When there are many caches deployed on server nodes and a query containing 
> joins is executed on a client for the first time then it takes much time to 
> complete compared to the following executions.
> If caches aren't enabled locally then the first query tries to load all the 
> missing caches by calling
> {{org.apache.ignite.internal.processors.cache.GridCacheProcessor#createMissingCaches}}
> {{createMissingCaches}} internally sends a request per each registered but 
> not enabled cache.
> Performance could be improved by performing a batch request.



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

[jira] [Updated] (IGNITE-4957) First join query execution in client mode takes too long when there are many caches on remote nodes

[Alexandr Fedotov (JIRA)]

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

Alexandr Fedotov updated IGNITE-4957:
-
Description: 
When there are many caches deployed on server nodes and a query containing 
joins is executed on a client for the first time then it takes much time to 
complete compared to the following executions.

If caches aren't enabled locally then the first query tries to load all the 
missing caches by calling
{{org.apache.ignite.internal.processors.cache.GridCacheProcessor#createMissingCaches}}
{{createMissingCaches}} internally sends a request per each registered but not 
enabled cache.
Performance could be improved by performing a batch request.



  was:
When there are many caches deployed on server nodes and a query containing 
joins is executed on a client for the first time it takes much time to complete 
compared to the following executions.

If caches aren't enabled locally then the first query tries to load all the 
missing caches by calling
{{org.apache.ignite.internal.processors.cache.GridCacheProcessor#createMissingCaches}}
{{createMissingCaches}} internally sends a request per each registered but not 
enabled cache.
Performance could be improved by performing a batch request.



> First join query execution in client mode takes too long when there are many 
> caches on remote nodes
> ---
>
> Key: IGNITE-4957
> URL: https://issues.apache.org/jira/browse/IGNITE-4957
> Project: Ignite
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 1.9
>Reporter: Alexandr Fedotov
>  Labels: performance
> Fix For: 2.1
>
> Attachments: first_run_from_client.png
>
>
> When there are many caches deployed on server nodes and a query containing 
> joins is executed on a client for the first time then it takes much time to 
> complete compared to the following executions.
> If caches aren't enabled locally then the first query tries to load all the 
> missing caches by calling
> {{org.apache.ignite.internal.processors.cache.GridCacheProcessor#createMissingCaches}}
> {{createMissingCaches}} internally sends a request per each registered but 
> not enabled cache.
> Performance could be improved by performing a batch request.



--
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/13/17 1:04 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.
- {{ContinuousQuery.setRemoteFilter}};
- {{CacheStore.sessionEnd}};
- {{CacheJdbcPojoStoreFactory.setDataSource}};
- {{ConnectorConfiguration.sslContextFactory}} property;
- {{IgniteConfiguration.nodeId}} properties:
- 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;
- One of the constructors of {{GridLeanSet}};
- Several methods at the {{IgniteUtils}};
- Several methods at the {{GridFunc}};
- {{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}};
- {{CacheJdbcPojoStoreFactory.setDataSource}};
- {{ConnectorConfiguration.sslContextFactory}} property;
- {{IgniteConfiguration.nodeId}} properties:
- 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;
- One of the constructors of {{GridLeanSet}};
- Several methods at the {{IgniteUtils}};
- Several methods at the {{GridFunc}};
- {{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] [Created] (IGNITE-4957) First join query execution in client mode takes too long when there are many caches on remote nodes

[Alexandr Fedotov (JIRA)]

Alexandr Fedotov created IGNITE-4957:


 Summary: First join query execution in client mode takes too long 
when there are many caches on remote nodes
 Key: IGNITE-4957
 URL: https://issues.apache.org/jira/browse/IGNITE-4957
 Project: Ignite
  Issue Type: Improvement
  Components: SQL
Affects Versions: 1.9
Reporter: Alexandr Fedotov
 Fix For: 2.1


When there are many caches deployed on server nodes and a query containing 
joins is executed on a client for the first time it takes much time to complete 
compared to the following executions.

If caches aren't enabled locally then the first query tries to load all the 
missing caches by calling
{{org.apache.ignite.internal.processors.cache.GridCacheProcessor#createMissingCaches}}
createMissingCaches internally sends a request per each registered but not 
enabled cache.
Performance could be improved by performing a batch request.




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

[jira] [Updated] (IGNITE-4957) First join query execution in client mode takes too long when there are many caches on remote nodes

[Alexandr Fedotov (JIRA)]

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

Alexandr Fedotov updated IGNITE-4957:
-
Description: 
When there are many caches deployed on server nodes and a query containing 
joins is executed on a client for the first time it takes much time to complete 
compared to the following executions.

If caches aren't enabled locally then the first query tries to load all the 
missing caches by calling
{{org.apache.ignite.internal.processors.cache.GridCacheProcessor#createMissingCaches}}
{{createMissingCaches}} internally sends a request per each registered but not 
enabled cache.
Performance could be improved by performing a batch request.


  was:
When there are many caches deployed on server nodes and a query containing 
joins is executed on a client for the first time it takes much time to complete 
compared to the following executions.

If caches aren't enabled locally then the first query tries to load all the 
missing caches by calling
{{org.apache.ignite.internal.processors.cache.GridCacheProcessor#createMissingCaches}}
createMissingCaches internally sends a request per each registered but not 
enabled cache.
Performance could be improved by performing a batch request.



> First join query execution in client mode takes too long when there are many 
> caches on remote nodes
> ---
>
> Key: IGNITE-4957
> URL: https://issues.apache.org/jira/browse/IGNITE-4957
> Project: Ignite
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 1.9
>Reporter: Alexandr Fedotov
>  Labels: performance
> Fix For: 2.1
>
>
> When there are many caches deployed on server nodes and a query containing 
> joins is executed on a client for the first time it takes much time to 
> complete compared to the following executions.
> If caches aren't enabled locally then the first query tries to load all the 
> missing caches by calling
> {{org.apache.ignite.internal.processors.cache.GridCacheProcessor#createMissingCaches}}
> {{createMissingCaches}} internally sends a request per each registered but 
> not enabled cache.
> Performance could be improved by performing a batch request.



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

[jira] [Commented] (IGNITE-4211) Update Spring dependency to latest stable version

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur commented on IGNITE-4211:


[~avinogradov]
It doesn't guarantee across an Ignite-cluster.
It has worked in test, because all node were in one JVM.

I will try an another solution.

> Update Spring dependency to latest stable version
> -
>
> Key: IGNITE-4211
> URL: https://issues.apache.org/jira/browse/IGNITE-4211
> Project: Ignite
>  Issue Type: Improvement
>  Components: build
>Affects Versions: 1.7
>Reporter: Sergey Kozlov
>Assignee: Vyacheslav Daradur
> Fix For: 2.0
>
>
> It seems the Spring dependency looks outdated for now. Apache Ignite still 
> uses 4.1.0 released two years ago. Could we to update to latest stable 
> version (4.3.4 at the moment)?



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

[jira] [Resolved] (IGNITE-4946) GridCacheP2PUndeploySelfTest became failed

[Yakov Zhdanov (JIRA)]

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

Yakov Zhdanov resolved IGNITE-4946.
---
Resolution: Fixed

Merged to master.
Thanks for contribution, Igor!

> GridCacheP2PUndeploySelfTest became failed
> --
>
> Key: IGNITE-4946
> URL: https://issues.apache.org/jira/browse/IGNITE-4946
> Project: Ignite
>  Issue Type: Bug
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
> Fix For: 2.0
>
>
> There are a race between GridDhtPartitionsExchangeFuture which cleans caches 
> after undeployment and GridDeploymentPerVersionStore which makes the 
> undeployment.



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

[jira] [Comment Edited] (IGNITE-4565) Support CREATE INDEX DDL statements

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-4565 at 4/13/17 12:46 PM:
---

Outstanding issues:
1) Merge with 3477
2) Fix client reconnect schema consistency issue
3) Fix DROP INDEX data consistency issue (+ add more concurrent data tests)
4) Long chains could lead to exchange thread starvation. Break the loop!


was (Author: vozerov):
Outstanding issues:
1) Merge with 3477
2) Fix client reconnect schema consistency issue
3) Fix drop data consistency issue (+ add more concurrent data tests)
4) Route IO messages to proper pool
5) Long chains could lead to exchange thread starvation. Break the loop!

> Support CREATE INDEX DDL statements
> ---
>
> Key: IGNITE-4565
> URL: https://issues.apache.org/jira/browse/IGNITE-4565
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache, SQL
>Reporter: Alexander Paschenko
>Assignee: Vladimir Ozerov
>  Labels: important
> Fix For: 2.0
>
>
> We need to implement support for dynamic {{CREATE INDEX}} and {{DROP INDEX}} 
> invocations.
> Design document: 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=67640367
> Base branch: {{ignite-4565}}



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

[jira] [Comment Edited] (IGNITE-3503) .NET: Remove "Default" prefix from BinaryConfiguration properties

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-3503 at 4/13/17 12:43 PM:
--

Fixed in master, migration guide updated


was (Author: ptupitsyn):
Fixed in master.

> .NET: Remove "Default" prefix from BinaryConfiguration properties
> -
>
> Key: IGNITE-3503
> URL: https://issues.apache.org/jira/browse/IGNITE-3503
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .net, breaking-api
> Fix For: 2.0
>
>
> It does not make much sense and makes property names too long. In Java there 
> is no such prefix.
> 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-3503) .NET: Remove "Default" prefix from BinaryConfiguration properties

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-3503:


Fixed in master.

> .NET: Remove "Default" prefix from BinaryConfiguration properties
> -
>
> Key: IGNITE-3503
> URL: https://issues.apache.org/jira/browse/IGNITE-3503
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .net, breaking-api
> Fix For: 2.0
>
>
> It does not make much sense and makes property names too long. In Java there 
> is no such prefix.
> 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] [Resolved] (IGNITE-3503) .NET: Remove "Default" prefix from BinaryConfiguration properties

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-3503.

Resolution: Fixed

> .NET: Remove "Default" prefix from BinaryConfiguration properties
> -
>
> Key: IGNITE-3503
> URL: https://issues.apache.org/jira/browse/IGNITE-3503
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .net, breaking-api
> Fix For: 2.0
>
>
> It does not make much sense and makes property names too long. In Java there 
> is no such prefix.
> 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-4155) Minor issues wth IgniteSemaphoreExample and HIbernateL2CacheExample

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4155:


Github user sergey-chugunov-1985 closed the pull request at:

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


> Minor issues wth IgniteSemaphoreExample and HIbernateL2CacheExample
> ---
>
> Key: IGNITE-4155
> URL: https://issues.apache.org/jira/browse/IGNITE-4155
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Minor
>  Labels: newbie
>
> IgniteSemaphoreExample finishes fine for the first run but hangs on the 
> second unless ignite cluster is restarted.
> HibernateL2CacheExample logs errors like this during run:
> {code}
> [17:14:25,147][ERROR][main][SchemaExport] HHH000389: Unsuccessful: alter 
> table Post drop constraint FK_m7j5gwmpa7dklv5bnc41ertmi
> [17:14:25,147][ERROR][main][SchemaExport] Table "POST" not found; SQL 
> statement:
> alter table Post drop constraint FK_m7j5gwmpa7dklv5bnc41ertmi [42102-191]
> {code}
> Errors don't prevent example from finishing but may lead to a confusion that 
> something works improperly.



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

[jira] [Updated] (IGNITE-3503) .NET: Remove "Default" prefix from BinaryConfiguration properties

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-3503:
---
Description: 
It does not make much sense and makes property names too long. In Java there is 
no such prefix.

2.0 migration guide has to be updated if needed: 
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide

  was:
It does not make much sense and makes property names too long.

2.0 migration guide has to be updated if needed: 
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide


> .NET: Remove "Default" prefix from BinaryConfiguration properties
> -
>
> Key: IGNITE-3503
> URL: https://issues.apache.org/jira/browse/IGNITE-3503
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .net, breaking-api
> Fix For: 2.0
>
>
> It does not make much sense and makes property names too long. In Java there 
> is no such prefix.
> 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-3503) .NET: Remove "Default" prefix from BinaryConfiguration properties

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-3503:
--

Assignee: Pavel Tupitsyn

> .NET: Remove "Default" prefix from BinaryConfiguration properties
> -
>
> Key: IGNITE-3503
> URL: https://issues.apache.org/jira/browse/IGNITE-3503
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .net, breaking-api
> Fix For: 2.0
>
>
> It does not make much sense and makes property names too long.
> 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-4211) Update Spring dependency to latest stable version

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-4211:
--

[~daradurvs]
Please explain how can synchronized provide only-once guarantee across the 
cluster.

> Update Spring dependency to latest stable version
> -
>
> Key: IGNITE-4211
> URL: https://issues.apache.org/jira/browse/IGNITE-4211
> Project: Ignite
>  Issue Type: Improvement
>  Components: build
>Affects Versions: 1.7
>Reporter: Sergey Kozlov
>Assignee: Vyacheslav Daradur
> Fix For: 2.0
>
>
> It seems the Spring dependency looks outdated for now. Apache Ignite still 
> uses 4.1.0 released two years ago. Could we to update to latest stable 
> version (4.3.4 at the moment)?



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

[jira] [Updated] (IGNITE-4956) Stabilize the test IgniteCacheLockPartitionOnAffinityRunAtomicCacheOpTest.testNotReservedTxCacheOp

[Taras Ledkov (JIRA)]

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

Taras Ledkov updated IGNITE-4956:
-
Description: 
The test periodically failed with the message:

{panel}
org.apache.ignite.IgniteCheckedException: Failed partition reservation. 
Partition is not primary on the node. [partition=12, cacheName=Person, 
nodeId=bf014a48-7032-4b72-9d00-d8a76551, topology=AffinityTopologyVersion 
[topVer=9, minorTopVer=0]] at 
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7172) at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:170)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:119)
 at 
org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:95)
 at 
org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:271)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListeners(GridFutureAdapter.java:259)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:389)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:355)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:343)
 at org.apache.ignite.testframework.GridTestUtils$6.run(GridTestUtils.java:858) 
at 
org.apache.ignite.testframework.GridTestUtils$8.call(GridTestUtils.java:1149) 
at org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86) 
Caused by: org.apache.ignite.IgniteException: Failed partition reservation. 
Partition is not primary on the node. [partition=12, cacheName=Person, 
nodeId=bf014a48-7032-4b72-9d00-d8a76551, topology=AffinityTopologyVersion 
[topVer=9, minorTopVer=0]] at 
org.apache.ignite.internal.processors.job.GridJobProcessor$PartitionsReservation.reserve(GridJobProcessor.java:1572)
 at 
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:504)
 at 
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:483)
 at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) 
at 
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1180)
 at 
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1894)
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1228)
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:856)
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$2100(GridIoManager.java:111)
 at 
org.apache.ignite.internal.managers.communication.GridIoManager$7.run(GridIoManager.java:798)
 at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
at java.lang.Thread.run(Thread.java:745) --- Stdout: ---
{panel}


> Stabilize  the test 
> IgniteCacheLockPartitionOnAffinityRunAtomicCacheOpTest.testNotReservedTxCacheOp
> ---
>
> Key: IGNITE-4956
> URL: https://issues.apache.org/jira/browse/IGNITE-4956
> Project: Ignite
>  Issue Type: Test
>Affects Versions: 1.9
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.1
>
>
> The test periodically failed with the message:
> {panel}
> org.apache.ignite.IgniteCheckedException: Failed partition reservation. 
> Partition is not primary on the node. [partition=12, cacheName=Person, 
> nodeId=bf014a48-7032-4b72-9d00-d8a76551, topology=AffinityTopologyVersion 
> [topVer=9, minorTopVer=0]] at 
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7172) at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:170)
>  at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:119)
>  at 
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:95)
>  at 
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45)
>  at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:271)
>  at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListeners(GridFutureAdapter.java:259)
>  at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:389)
>  at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:355)
> 

[jira] [Updated] (IGNITE-4956) Stabilize the test IgniteCacheLockPartitionOnAffinityRunAtomicCacheOpTest.testNotReservedTxCacheOp

[Taras Ledkov (JIRA)]

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

Taras Ledkov updated IGNITE-4956:
-
Description: 
The test periodically failed with the message:

{code}
org.apache.ignite.IgniteCheckedException: Failed partition reservation. 
Partition is not primary on the node. [partition=12, cacheName=Person, 
nodeId=bf014a48-7032-4b72-9d00-d8a76551, topology=AffinityTopologyVersion 
[topVer=9, minorTopVer=0]] at 
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7172) at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:170)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:119)
 at 
org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:95)
 at 
org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:271)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListeners(GridFutureAdapter.java:259)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:389)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:355)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:343)
 at org.apache.ignite.testframework.GridTestUtils$6.run(GridTestUtils.java:858) 
at 
org.apache.ignite.testframework.GridTestUtils$8.call(GridTestUtils.java:1149) 
at org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86) 
Caused by: org.apache.ignite.IgniteException: Failed partition reservation. 
Partition is not primary on the node. [partition=12, cacheName=Person, 
nodeId=bf014a48-7032-4b72-9d00-d8a76551, topology=AffinityTopologyVersion 
[topVer=9, minorTopVer=0]] at 
org.apache.ignite.internal.processors.job.GridJobProcessor$PartitionsReservation.reserve(GridJobProcessor.java:1572)
 at 
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:504)
 at 
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:483)
 at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) 
at 
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1180)
 at 
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1894)
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1228)
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:856)
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$2100(GridIoManager.java:111)
 at 
org.apache.ignite.internal.managers.communication.GridIoManager$7.run(GridIoManager.java:798)
 at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
at java.lang.Thread.run(Thread.java:745) --- Stdout: ---
{code}


  was:
The test periodically failed with the message:

{panel}
org.apache.ignite.IgniteCheckedException: Failed partition reservation. 
Partition is not primary on the node. [partition=12, cacheName=Person, 
nodeId=bf014a48-7032-4b72-9d00-d8a76551, topology=AffinityTopologyVersion 
[topVer=9, minorTopVer=0]] at 
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7172) at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:170)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:119)
 at 
org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:95)
 at 
org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:271)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListeners(GridFutureAdapter.java:259)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:389)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:355)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:343)
 at org.apache.ignite.testframework.GridTestUtils$6.run(GridTestUtils.java:858) 
at 
org.apache.ignite.testframework.GridTestUtils$8.call(GridTestUtils.java:1149) 
at org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86) 
Caused by: org.apache.ignite.IgniteException: Failed partition reservation. 
Partition is not primary on the node. [partition=12, cacheName=Person, 
nodeId=bf014a48-7032-4b72-9d00-d8a76551, 

[jira] [Comment Edited] (IGNITE-4565) Support CREATE INDEX DDL statements

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-4565 at 4/13/17 12:02 PM:
---

Outstanding issues:
1) Merge with 3477
2) Fix client reconnect schema consistency issue
3) Fix drop data consistency issue (+ add more concurrent data tests)
4) Route IO messages to proper pool
5) Long chains could lead to exchange thread starvation. Break the loop!


was (Author: vozerov):
Outstanding issues:
1) Merge with 3477
2) Fix client reconnect schema consistency issue
3) Fix drop data consistency issue (+ add more concurrent data tests)
4) Route IO messages to proper pool
5) Avoid serialization of errors in exchange thread

> Support CREATE INDEX DDL statements
> ---
>
> Key: IGNITE-4565
> URL: https://issues.apache.org/jira/browse/IGNITE-4565
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache, SQL
>Reporter: Alexander Paschenko
>Assignee: Vladimir Ozerov
>  Labels: important
> Fix For: 2.0
>
>
> We need to implement support for dynamic {{CREATE INDEX}} and {{DROP INDEX}} 
> invocations.
> Design document: 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=67640367
> Base branch: {{ignite-4565}}



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

[jira] [Commented] (IGNITE-3548) .NET: Rename ILifecycleBean

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-3548:


What is the plural form? {{LifecycleAwares}}? Not sure about this. May be name 
it {{ILifecycleHandler}} instead?

> .NET: Rename ILifecycleBean
> ---
>
> Key: IGNITE-3548
> URL: https://issues.apache.org/jira/browse/IGNITE-3548
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .net, breaking-api
> Fix For: 2.0
>
>
> Bean is a Java term. 
> Either rename this interface to something like ILifecycle, or rework the 
> lifecycle notifications to C# event handlers.
> 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] [Created] (IGNITE-4956) Stabilize the test IgniteCacheLockPartitionOnAffinityRunAtomicCacheOpTest.testNotReservedTxCacheOp

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-4956:


 Summary: Stabilize  the test 
IgniteCacheLockPartitionOnAffinityRunAtomicCacheOpTest.testNotReservedTxCacheOp
 Key: IGNITE-4956
 URL: https://issues.apache.org/jira/browse/IGNITE-4956
 Project: Ignite
  Issue Type: Test
Affects Versions: 1.9
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.1






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

[jira] [Comment Edited] (IGNITE-4211) Update Spring dependency to latest stable version

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur edited comment on IGNITE-4211 at 4/13/17 11:57 AM:
--

[~avinogradov]
bq. I'm 99% sure that the reason is valueLoader we sending at EntryProcessor. 
That's exactly what I was thinking.

The following simple implemenation works well.
{code}
/** {@inheritDoc} */
@SuppressWarnings("unchecked")
@Override public  T get(Object key, Callable valueLoader) {
synchronized (SpringCache.class) {
Object val = cache.get(key);

if (val != null)
return (T)fromStoreValue(val);

try {
val = valueLoader.call();
}
catch (Exception e) {
throw new ValueRetrievalException(key, valueLoader, e);
}

cache.put(key, val);

return (T) val;
}
}
{code}


was (Author: daradurvs):
[~avinogradov]
bq. I'm 99% sure that the reason is valueLoader we sending at EntryProcessor. 
That's exactly what I was thinking.

The following simple implemenation works well.
{code}
/** {@inheritDoc} */
@SuppressWarnings("unchecked")
@Override public  T get(Object key, Callable valueLoader) {
synchronized (this) {
Object val = cache.get(key);

if (val != null)
return (T)fromStoreValue(val);

try {
val = valueLoader.call();
}
catch (Exception e) {
throw new ValueRetrievalException(key, valueLoader, e);
}

cache.put(key, val);

return (T) val;
}
}
{code}

> Update Spring dependency to latest stable version
> -
>
> Key: IGNITE-4211
> URL: https://issues.apache.org/jira/browse/IGNITE-4211
> Project: Ignite
>  Issue Type: Improvement
>  Components: build
>Affects Versions: 1.7
>Reporter: Sergey Kozlov
>Assignee: Vyacheslav Daradur
> Fix For: 2.0
>
>
> It seems the Spring dependency looks outdated for now. Apache Ignite still 
> uses 4.1.0 released two years ago. Could we to update to latest stable 
> version (4.3.4 at the moment)?



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

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

[Yakov Zhdanov (JIRA)]

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

Yakov Zhdanov reassigned IGNITE-3018:
-

Resolution: Fixed
  Assignee: Taras Ledkov  (was: Yakov Zhdanov)

merged to master

> 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: Taras Ledkov
>  Labels: important
> Fix For: 2.0
>
> Attachments: 003.png, 004.png, 008.png, 016.png, 064.png, 100.png, 
> 128.png, 200.png, 256.png, 400.png, 600.png, balanced.003.png, 
> balanced.004.png, balanced.008.png, balanced.016.png, balanced.064.png, 
> balanced.100.png, balanced.128.png, balanced.200.png, balanced.256.png, 
> balanced.400.png, balanced.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-4211) Update Spring dependency to latest stable version

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur commented on IGNITE-4211:


[~avinogradov]
bq. I'm 99% sure that the reason is valueLoader we sending at EntryProcessor. 
That's exactly what I was thinking.

The following simple implemenation works well.
{code}
/** {@inheritDoc} */
@SuppressWarnings("unchecked")
@Override public  T get(Object key, Callable valueLoader) {
synchronized (this) {
Object val = cache.get(key);

if (val != null)
return (T)fromStoreValue(val);

try {
val = valueLoader.call();
}
catch (Exception e) {
throw new ValueRetrievalException(key, valueLoader, e);
}

cache.put(key, val);

return (T) val;
}
}
{code}

> Update Spring dependency to latest stable version
> -
>
> Key: IGNITE-4211
> URL: https://issues.apache.org/jira/browse/IGNITE-4211
> Project: Ignite
>  Issue Type: Improvement
>  Components: build
>Affects Versions: 1.7
>Reporter: Sergey Kozlov
>Assignee: Vyacheslav Daradur
> Fix For: 2.0
>
>
> It seems the Spring dependency looks outdated for now. Apache Ignite still 
> uses 4.1.0 released two years ago. Could we to update to latest stable 
> version (4.3.4 at the moment)?



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

[jira] [Commented] (IGNITE-3581) CPP: Place different enums and constants in separate namespaces or structs.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3581:


Github user isapego closed the pull request at:

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


> CPP: Place different enums and constants in separate namespaces or structs.
> ---
>
> Key: IGNITE-3581
> URL: https://issues.apache.org/jira/browse/IGNITE-3581
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.0
>
>
> The common practice is to place enums and constants in separate namespaces or 
> structs. This way we can group them and avoid name clashes without the need 
> to use long names.
> [Details|http://stackoverflow.com/questions/7090130/enum-in-a-namespace].



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

[jira] [Comment Edited] (IGNITE-4565) Support CREATE INDEX DDL statements

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-4565 at 4/13/17 11:47 AM:
---

Outstanding issues:
1) Merge with 3477
2) Fix client reconnect schema consistency issue
3) Fix drop data consistency issue (+ add more concurrent data tests)
4) Route IO messages to proper pool
5) Avoid serialization of errors in exchange thread


was (Author: vozerov):
Outstanding issues:
1) Merge with 3477
2) Fix client reconnect schema consistency issue
3) Fix drop data consistency issue (+ add more concurrent data tests)


> Support CREATE INDEX DDL statements
> ---
>
> Key: IGNITE-4565
> URL: https://issues.apache.org/jira/browse/IGNITE-4565
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache, SQL
>Reporter: Alexander Paschenko
>Assignee: Vladimir Ozerov
>  Labels: important
> Fix For: 2.0
>
>
> We need to implement support for dynamic {{CREATE INDEX}} and {{DROP INDEX}} 
> invocations.
> Design document: 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=67640367
> Base branch: {{ignite-4565}}



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

[jira] [Commented] (IGNITE-2398) .NET: Change default mapper behavior

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-2398:


SQL issue fixed by adding {{+}} character (.NET nested type) handling in Java.
All done, TC looks good. 

[~vozerov] please review.

> .NET: Change default mapper behavior
> 
>
> Key: IGNITE-2398
> URL: https://issues.apache.org/jira/browse/IGNITE-2398
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .net, important
> Fix For: 2.0
>
>
> We need to mirror changes implemented in IGNITE-2191:
> 1) Default mapper must use full class name (i.e. with package)
> 2) Provide additional mapper implementation which will use simple names.



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

[jira] [Commented] (IGNITE-2398) .NET: Change default mapper behavior

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2398:


Github user ptupitsyn closed the pull request at:

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


> .NET: Change default mapper behavior
> 
>
> Key: IGNITE-2398
> URL: https://issues.apache.org/jira/browse/IGNITE-2398
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .net, important
> Fix For: 2.0
>
>
> We need to mirror changes implemented in IGNITE-2191:
> 1) Default mapper must use full class name (i.e. with package)
> 2) Provide additional mapper implementation which will use simple names.



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

[jira] [Commented] (IGNITE-2398) .NET: Change default mapper behavior

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2398:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-2398 .NET: Change default mapper behavior



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

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

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

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


commit 25e5a5417263e25f90d198b7afc86255c5bed7f2
Author: Pavel Tupitsyn 
Date:   2017-04-13T11:45:21Z

IGNITE-2398 .NET: Change default mapper behavior




> .NET: Change default mapper behavior
> 
>
> Key: IGNITE-2398
> URL: https://issues.apache.org/jira/browse/IGNITE-2398
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .net, important
> Fix For: 2.0
>
>
> We need to mirror changes implemented in IGNITE-2191:
> 1) Default mapper must use full class name (i.e. with package)
> 2) Provide additional mapper implementation which will use simple names.



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

[jira] [Commented] (IGNITE-4565) Support CREATE INDEX DDL statements

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4565:
-

Outstanding issues:
1) Merge with 3477
2) Fix client reconnect schema consistency issue
3) Fix drop data consistency issue (+ add more concurrent data tests)


> Support CREATE INDEX DDL statements
> ---
>
> Key: IGNITE-4565
> URL: https://issues.apache.org/jira/browse/IGNITE-4565
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache, SQL
>Reporter: Alexander Paschenko
>Assignee: Vladimir Ozerov
>  Labels: important
> Fix For: 2.0
>
>
> We need to implement support for dynamic {{CREATE INDEX}} and {{DROP INDEX}} 
> invocations.
> Design document: 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=67640367
> Base branch: {{ignite-4565}}



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

[jira] [Updated] (IGNITE-4951) Discontinue AffintiyKeyMapper interface

[Konstantin Dudkov (JIRA)]

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

Konstantin Dudkov updated IGNITE-4951:
--
Fix Version/s: (was: 2.0)
   2.1

> Discontinue AffintiyKeyMapper interface
> ---
>
> Key: IGNITE-4951
> URL: https://issues.apache.org/jira/browse/IGNITE-4951
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Vladimir Ozerov
>Assignee: Konstantin Dudkov
>  Labels: important
> Fix For: 2.1
>
>




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

[jira] [Commented] (IGNITE-4951) Discontinue AffintiyKeyMapper interface

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4951:
-

[~kdudkov], let's postpone this for now.

> Discontinue AffintiyKeyMapper interface
> ---
>
> Key: IGNITE-4951
> URL: https://issues.apache.org/jira/browse/IGNITE-4951
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Vladimir Ozerov
>Assignee: Konstantin Dudkov
>  Labels: important
> Fix For: 2.0
>
>




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

[jira] [Commented] (IGNITE-4211) Update Spring dependency to latest stable version

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-4211:
--

[~daradurvs]
I'm pretty sure that's not a reason, but effect.
Please investigate why this happens. 
I'm 99% sure that the reason is valueLoader we sending at EntryProcessor. 
In case that's true we have to find another way provide only-once guarantie.

> Update Spring dependency to latest stable version
> -
>
> Key: IGNITE-4211
> URL: https://issues.apache.org/jira/browse/IGNITE-4211
> Project: Ignite
>  Issue Type: Improvement
>  Components: build
>Affects Versions: 1.7
>Reporter: Sergey Kozlov
>Assignee: Vyacheslav Daradur
> Fix For: 2.0
>
>
> It seems the Spring dependency looks outdated for now. Apache Ignite still 
> uses 4.1.0 released two years ago. Could we to update to latest stable 
> version (4.3.4 at the moment)?



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

[jira] [Commented] (IGNITE-3581) CPP: Place different enums and constants in separate namespaces or structs.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-3581:


Thanks for the explanation, [~isapego]. Looks good to me.

> CPP: Place different enums and constants in separate namespaces or structs.
> ---
>
> Key: IGNITE-3581
> URL: https://issues.apache.org/jira/browse/IGNITE-3581
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.0
>
>
> The common practice is to place enums and constants in separate namespaces or 
> structs. This way we can group them and avoid name clashes without the need 
> to use long names.
> [Details|http://stackoverflow.com/questions/7090130/enum-in-a-namespace].



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

[jira] [Commented] (IGNITE-4211) Update Spring dependency to latest stable version

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur commented on IGNITE-4211:


[~avinogradov]

The most deep point of the error: {{IgniteUtils#forName}}
{{java.lang.ClassNotFoundException: sun.reflect.GeneratedMethodAccessor##}}

It is called by {{OptimizedMarshallerUtils#classDescriptor}} via 
{{MarshallerContextImpl#getClass}}
{code}
cls = ctx.getClass(typeId, ldr); // couldn't load class for current typeId
// cls is null, but mustn't be null
OptimizedClassDescriptor desc = clsMap.get(cls); // NullPointerException
{code}

As far I know GeneratedMethodAccessor are classes wich generated at runtime by 
the Java-reflection to call methods and constructors.

As I understand, one node serialized self-generated reflection class, and other 
node tryed to deserialize it.

> Update Spring dependency to latest stable version
> -
>
> Key: IGNITE-4211
> URL: https://issues.apache.org/jira/browse/IGNITE-4211
> Project: Ignite
>  Issue Type: Improvement
>  Components: build
>Affects Versions: 1.7
>Reporter: Sergey Kozlov
>Assignee: Vyacheslav Daradur
> Fix For: 2.0
>
>
> It seems the Spring dependency looks outdated for now. Apache Ignite still 
> uses 4.1.0 released two years ago. Could we to update to latest stable 
> version (4.3.4 at the moment)?



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

[jira] [Commented] (IGNITE-3581) CPP: Place different enums and constants in separate namespaces or structs.

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-3581:
-

[~ptupitsyn] well, yeah, it's common practice. In C++11 there are special enum 
types for that - {{enum class}}, but previously it was ordinary achieved by 
placing enums in separate namespaces or struct. I like structs more because you 
can place them inside other classes and because of the naming consistency 
(namespaces usually use snake_case). You can see details 
[here|http://stackoverflow.com/questions/7090130/enum-in-a-namespace] for 
example.

> CPP: Place different enums and constants in separate namespaces or structs.
> ---
>
> Key: IGNITE-3581
> URL: https://issues.apache.org/jira/browse/IGNITE-3581
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.0
>
>
> The common practice is to place enums and constants in separate namespaces or 
> structs. This way we can group them and avoid name clashes without the need 
> to use long names.
> [Details|http://stackoverflow.com/questions/7090130/enum-in-a-namespace].



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

[jira] [Commented] (IGNITE-4951) Discontinue AffintiyKeyMapper interface

[Konstantin Dudkov (JIRA)]

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

Konstantin Dudkov commented on IGNITE-4951:
---

in IgfsUtils#prepareCacheConfigurations we got following:

{code:java}
// Set co-located affinity mapper if needed.
if (igfsCfg.isColocateMetadata() && 
ccfgMeta.getAffinityMapper() == null)
ccfgMeta.setAffinityMapper(new 
IgfsColocatedMetadataAffinityKeyMapper());

// Set affinity mapper if needed.
if (ccfgData.getAffinityMapper() == null)
ccfgData.setAffinityMapper(new 
IgfsGroupDataBlocksKeyMapper());
{code}

IgfsGroupDataBlocksKeyMapper file's data blocks together on one node. It can be 
done using custom AffinityKey class with annotated affinityKey field filled 
according to same logic, but in my opinion it's more clear to keep this logic 
within AffintiyKeyMapper class.


> Discontinue AffintiyKeyMapper interface
> ---
>
> Key: IGNITE-4951
> URL: https://issues.apache.org/jira/browse/IGNITE-4951
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Vladimir Ozerov
>Assignee: Konstantin Dudkov
>  Labels: important
> Fix For: 2.0
>
>




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

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

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-4915:
--

[~vozerov], please review the changes.

> Remove deprecated methods and properties 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.
> - deprecated properties of the {{TcpCommunicationSpi}};
> - {{GridTupleV}};
> - {{AffinityNideHashResolver}}.



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

[jira] [Comment Edited] (IGNITE-4915) Remove deprecated methods and properties at the public API

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-4915 at 4/13/17 10:35 AM:


Tests 
[results|http://195.239.208.174/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull%2F1734%2Fhead]
 don't contain significant difference with the master branch.


was (Author: tledkov-gridgain):
Waits for TC 
[results|http://195.239.208.174/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull%2F1734%2Fhead]

> Remove deprecated methods and properties 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.
> - deprecated properties of the {{TcpCommunicationSpi}};
> - {{GridTupleV}};
> - {{AffinityNideHashResolver}}.



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

[jira] [Comment Edited] (IGNITE-3523) IGFS: Remove "initialize default path modes" feature.

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-3523 at 4/13/17 10:20 AM:


Tests 
[results|http://195.239.208.174/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull%2F1786%2Fhead]
 are OK with me


was (Author: tledkov-gridgain):
Waits for TC 
[results|http://195.239.208.174/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull%2F1786%2Fhead]

> IGFS: Remove "initialize default path modes" feature.
> -
>
> Key: IGNITE-3523
> URL: https://issues.apache.org/jira/browse/IGNITE-3523
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> Currently IGFS can create several paths by default, which will forcefully 
> work in different modes. This will never require in practice, but caused some 
> problems, e.g. performance degradation in our Hadoop FileSystem implementaions
> Let's just remove that feature along with relevant property in 
> {{FileSystemConfiguration}}.



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

[jira] [Commented] (IGNITE-4943) Web Console: Improve design of tables with grouping on Admin Panel screen

[Vica Abramova (JIRA)]

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

Vica Abramova commented on IGNITE-4943:
---

Also please fix:
1. Delete checkbox on collapsed items on Admin Panel screen
2. Add tooltip to the disabled checkbox "Select all' - You can select only one 
user.
3. If user filter the data, on "Select all" action we should select only 
filtered items.

> Web Console: Improve design of tables with grouping on Admin Panel screen
> -
>
> Key: IGNITE-4943
> URL: https://issues.apache.org/jira/browse/IGNITE-4943
> Project: Ignite
>  Issue Type: Sub-task
>  Components: UI, wizards
>Affects Versions: 1.9
>Reporter: Andrey Novikov
>Assignee: Dmitriy Shabalin
> Attachments: Advanced Table.png
>
>




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

[jira] [Assigned] (IGNITE-3524) IGFS: Do not allow nulls for FileSystemConfiguration.name.

[Taras Ledkov (JIRA)]

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

Taras Ledkov reassigned IGNITE-3524:


Assignee: Taras Ledkov

> IGFS: Do not allow nulls for FileSystemConfiguration.name.
> --
>
> Key: IGNITE-3524
> URL: https://issues.apache.org/jira/browse/IGNITE-3524
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> As a part of our general approach, let's do not allow nulls as IGFS names.



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

[jira] [Commented] (IGNITE-3523) IGFS: Remove "initialize default path modes" feature.

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-3523:
--

Waits for TC 
[results|http://195.239.208.174/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull%2F1786%2Fhead]

> IGFS: Remove "initialize default path modes" feature.
> -
>
> Key: IGNITE-3523
> URL: https://issues.apache.org/jira/browse/IGNITE-3523
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> Currently IGFS can create several paths by default, which will forcefully 
> work in different modes. This will never require in practice, but caused some 
> problems, e.g. performance degradation in our Hadoop FileSystem implementaions
> Let's just remove that feature along with relevant property in 
> {{FileSystemConfiguration}}.



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