[jira] [Commented] (IGNITE-3066) Set of Redis commands that can be easily implemented via existing REST commands

[Roman Shtykh (JIRA)]

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

Roman Shtykh commented on IGNITE-3066:
--

Denis, the listed commands work, but with the above-mentioned limitations. The 
limitations are caused (as I see it) because we wrap REST, which has a poorer 
set of commands compared to Redis protocol.

Maybe it can be released as an experimental feature. What do you think?

It is in branch https://github.com/apache/ignite/tree/ignite-2788


> Set of Redis commands that can be easily implemented via existing REST 
> commands
> ---
>
> Key: IGNITE-3066
> URL: https://issues.apache.org/jira/browse/IGNITE-3066
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> As the 1st iteration of IGNITE-2788 the following commands can be implemented 
> via existing REST commands,
> GET
> MGET
> SET
> MSET
> INCR
> DECR
> INCRBY
> DECRBY
> APPEND
> STRLEN
> GETSET
> SETRANGE
> GETRANGE
> DEL
> EXISTS
> DBSIZE
> http://redis.io/commands



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

[jira] [Comment Edited] (IGNITE-3891) Enable writing hostname, rather than ipaddress for zookeeper discovery

[John Watson (JIRA)]

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

John Watson edited comment on IGNITE-3891 at 11/1/16 2:12 AM:
--

Hm. In this case, I'm not sure it will. We *do* know the external hostname of 
the docker host, but we do not know its external IP address. AddressResolver 
requires knowing the external IP address, doesn't it?


was (Author: jwatsonnr):
Hm. In this case, I'm not sure it will. We *do* know the external hostname of 
the docker host, but we do now know its external IP address. AddressResolver 
requires knowing the external IP address, doesn't it?

> Enable writing hostname, rather than ipaddress for zookeeper discovery
> --
>
> Key: IGNITE-3891
> URL: https://issues.apache.org/jira/browse/IGNITE-3891
> Project: Ignite
>  Issue Type: Improvement
>  Components: ignite-zookeeper
>Affects Versions: 1.7
> Environment: docker
>Reporter: John Watson
>Assignee: Roman Shtykh
>
> We are using ignite in docker, with zookeeper discovery. We need to be able 
> to use the hostname, rather than the ip address, since the container-visible 
> ip address is not externally usable.
> We would like an option in the TcpDiscoveryZookeeperIpFinder to use the 
> hostname, rather than ipaddress.  This change would impact line 231, where 
> currently the ip address is being written. We suggest adding an option to the 
> class to use the hostname, rather than the ip address.



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

[jira] [Commented] (IGNITE-3891) Enable writing hostname, rather than ipaddress for zookeeper discovery

[John Watson (JIRA)]

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

John Watson commented on IGNITE-3891:
-

Hm. In this case, I'm not sure it will. We *do* know the external hostname of 
the docker host, but we do now know its external IP address. AddressResolver 
requires knowing the external IP address, doesn't it?

> Enable writing hostname, rather than ipaddress for zookeeper discovery
> --
>
> Key: IGNITE-3891
> URL: https://issues.apache.org/jira/browse/IGNITE-3891
> Project: Ignite
>  Issue Type: Improvement
>  Components: ignite-zookeeper
>Affects Versions: 1.7
> Environment: docker
>Reporter: John Watson
>Assignee: Roman Shtykh
>
> We are using ignite in docker, with zookeeper discovery. We need to be able 
> to use the hostname, rather than the ip address, since the container-visible 
> ip address is not externally usable.
> We would like an option in the TcpDiscoveryZookeeperIpFinder to use the 
> hostname, rather than ipaddress.  This change would impact line 231, where 
> currently the ip address is being written. We suggest adding an option to the 
> class to use the hostname, rather than the ip address.



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

[jira] [Commented] (IGNITE-3066) Set of Redis commands that can be easily implemented via existing REST commands

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-3066:
-

[~roman_s], please send a message to the dev list with a link to the 
pull-request asking for the review. I came across this ticket  by chance. In 
the middle of November we're planning to release Ignite 1.8 and it will be 
great to see your improvements there. 

> Set of Redis commands that can be easily implemented via existing REST 
> commands
> ---
>
> Key: IGNITE-3066
> URL: https://issues.apache.org/jira/browse/IGNITE-3066
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> As the 1st iteration of IGNITE-2788 the following commands can be implemented 
> via existing REST commands,
> GET
> MGET
> SET
> MSET
> INCR
> DECR
> INCRBY
> DECRBY
> APPEND
> STRLEN
> GETSET
> SETRANGE
> GETRANGE
> DEL
> EXISTS
> DBSIZE
> http://redis.io/commands



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

[jira] [Commented] (IGNITE-2788) Mediator layer for Ignite to work with data via the Redis protocol

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-2788:
-

[~roman_s], sorry for the late reply from our side. if you prefer to keep 
working on this ticket please send a message to the dev list asking for review.

> Mediator layer for Ignite to work with data via the Redis protocol
> --
>
> Key: IGNITE-2788
> URL: https://issues.apache.org/jira/browse/IGNITE-2788
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Roman Shtykh
>
> Introduce a mediator layer that works with the Redis clients/protocol but 
> uses Ignite grid for storage.
> Needless to say, Redis is an extremely popular caching solution. Such API 
> will enable smooth migration to Ignite.
> As a first phase we can start with most frequently used commands and enhance 
> gradually.
> Redis commands http://redis.io/commands



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

[jira] [Commented] (IGNITE-640) Implement IgniteMultimap data structures

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-640:


The memory footprint will be negligible. However, the second concern about the 
removal sounds reasonable to me. [~dsetrakyan], do you see how the design 
proposed by you can handle a removal based on key and val efficiently, so that 
there is no need to update all the indexes if we remove a value in the middle 
of the "list"? 

> Implement IgniteMultimap data structures
> 
>
> Key: IGNITE-640
> URL: https://issues.apache.org/jira/browse/IGNITE-640
> Project: Ignite
>  Issue Type: Sub-task
>  Components: data structures
>Reporter: Dmitriy Setrakyan
>Assignee: Amir Akhmedov
>
> We need to add {{IgniteMultimap}} data structure in addition to other data 
> structures provided by Ignite. {{IgniteMultiMap}} should have similar API to 
> {{java.util.Map}} class in JDK, but support the semantics of multiple values 
> per key, similar to [Guava 
> Multimap|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Multimap.html].
>  
> However, unlike in Guava, our multi-map should work with Lists, not 
> Collections. Lists should make it possible to support the following methods:
> {code}
> // Gets value at a certain index for a key.
> V get(K, index);
> // Gets all values for a collection of keys at a certain index.
> Map getAll(Collection, index);
> // Gets values for specified indexes for a key.
> List get(K, Iterable indexes);
> // Gets all values for a collection of keys at specified indexes.
> Map getAll(Collection, Iterable indexes);
> // Gets values for specified range of indexes, between min and max.
> List get(K, int min, int max);
> // Gets all values for a collection of keys for a specified index range, 
> between min and max.
> Map getAll(Collection, int min, int max);
> // Gets all values for a specific key.
> List get(K);
> // Gets all values for a collection of keys.
> Map getAll(Collection);
> // Iterate through all elements with a certain index.
> Iterator> iterate(int idx);
> // Do we need this?
> Collection get(K, IgniteBiPredicate)
> {code}
> Multimap should also support colocated and non-colocated modes, similar to 
> [IgniteQueue|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteQueue.java]
>  and its implementation, 
> [GridAtomicCacheQueueImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridAtomicCacheQueueImpl.java].
> h2. Design Details
> The most natural way to implement such map, would be to store every value 
> under a separate key in an Ignite cache. For example, let's say that we have 
> a key {{K}} with multiple values: {{V0, V1, V2, ...}}. Then the cache should 
> end up with the following values {{K0, V0}}, {{K1, V1}}, {{K2, V2}}, etc. 
> This means that we need to wrap user key into our own, internal key, which 
> will also have {{index}} field. 
> Also note that we need to collocate all the values for the same key on the 
> same node, which means that we need to define user key K as the affinity key, 
> like so:
> {code}
> class MultiKey {
> @CacheAffinityMapped
> private K key;
> int index;
> }
> {code}
> Look ups of values at specific indexes becomes very simple. Just attach a 
> specific index to a key and do a cache lookup. Look ups for all values for a 
> key should work as following:
> {code}
> MultiKey key;
> V v = null;
> int index = 0;
> List res = new LinkedList<>();
> do {
> v = cache.get(MultiKey(K, index));
> if (v != null)
> res.add(v);
> index++;
> }
> while (v != null);
> return res;
> {code}
> We could also use batching for performance reason. In this case the batch 
> size should be configurable.
> {code}
> int index = 0;
> List res = new LinkedList<>();
> while (true) {
> List batch = new ArrayList<>(batchSize);
> // Populate batch.
> for (; index < batchSize; index++)
> batch.add(new MultiKey(K, index % batchSize);
> Map batchRes = cache.getAll(batch);
> // Potentially need to properly sort values, based on the key order,
> // if the returning map does not do it automatically.
> res.addAll(batchRes.values());
> if (res.size() < batch.size())
> break;
> }
> return res;
> {code}
> h2. Evictions
> Evictions in the {{IgniteMultiMap}} should have 2 levels: maximum number of 
> keys, and maximum number of values for a key. The maximum number of keys 
> should be controlled by Ignite standard eviction policy. The maximum number 
> of values for a key should be controlled by 

[jira] [Commented] (IGNITE-637) Implement IgniteReentrantReadWriteLock data structure

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-637:


[~vladisav], are you planning to complete this feature in the nearest time? In 
the middle of November we're planning to release Ignite 1.8 and it will be 
great to have this feature in the release.

> Implement IgniteReentrantReadWriteLock data structure
> -
>
> Key: IGNITE-637
> URL: https://issues.apache.org/jira/browse/IGNITE-637
> Project: Ignite
>  Issue Type: Sub-task
>  Components: data structures
>Reporter: Dmitriy Setrakyan
>Assignee: Vladisav Jelisavcic
>
> We need to add {{IgniteReentrantReadWriteLock}} data structure in addition to 
> other data structures provided by Ignite. {{IgniteReentrantReadWriteLock}} 
> should have similar API to 
> {{java.util.concurrent.locks.ReentrantReadWriteLock}} class in JDK.
> As an example, you can see how 
> [IgniteCountDownLatch|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteCountDownLatch.java]
>  is implemented in 
> [GridCacheCountDownLatchImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridCacheCountDownLatchImpl.java]
>  class.
> In general we need to have an entity in ATOMIC cache storing number of 
> readers and writers and allow user threads to block whenever needed to wait 
> for a lock.



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

[jira] [Updated] (IGNITE-536) Implement IgniteKinesisStreamer to stream data from Amazon Kinesis service

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-536:
---
Assignee: (was: Vishal Garg)

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



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

[jira] [Assigned] (IGNITE-536) Implement IgniteKinesisStreamer to stream data from Amazon Kinesis service

[Denis Magda (JIRA)]

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

Denis Magda reassigned IGNITE-536:
--

Assignee: Denis Magda

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



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

[jira] [Updated] (IGNITE-536) Implement IgniteKinesisStreamer to stream data from Amazon Kinesis service

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-536:
---
Assignee: (was: Denis Magda)

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



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

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

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-533:


[~Chandresh Pancholi], are you planning to work on this task? If you don't 
please unassign it from yourself so that someone else from the community can 
pick it up.

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



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

[jira] [Updated] (IGNITE-532) Implement IgniteAkkaStreamer to stream data from Akka actors.

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-532:
---
Assignee: (was: Chandresh Pancholi)

> Implement IgniteAkkaStreamer to stream data from Akka actors.
> -
>
> Key: IGNITE-532
> URL: https://issues.apache.org/jira/browse/IGNITE-532
> Project: Ignite
>  Issue Type: Sub-task
>  Components: streaming
>Reporter: Dmitriy Setrakyan
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under 
> high load. It was previously named {{IgniteDataLoader}}, see ticket 
> IGNITE-394.
> See [Akka|http://akka.io/] for more information. Given that Akka is a Scala 
> frameworks, this streamer should be available in Scala.
> We should create {{IgniteAkkaStreamer}} which will consume messages from Akka 
> Actors and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> * Convert data from Akka to Ignite using an optional pluggable converter. If 
> not provided, then we should have some default mechanism.
> * Specify the cache name for the Ignite cache to load data into.
> * Specify other flags available on {{IgniteDataStreamer}} class.



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

[jira] [Updated] (IGNITE-4139) .NET: improve the getting started guide

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4139:

Assignee: Pavel Tupitsyn  (was: Denis Magda)

> .NET: improve the getting started guide
> ---
>
> Key: IGNITE-4139
> URL: https://issues.apache.org/jira/browse/IGNITE-4139
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
> Fix For: 1.8
>
>
> The current guide 
> (https://apacheignite-net.readme.io/v1.7/docs/getting-started-2) is based on 
> the fact that you need to build a binary from sources. 
> We should demonstrate how it can be done with 
> ‘modules/platforms/dotnet/bin/Apache.Ignite.exe’ that is already available. 
> Next, we should showcase how we can change a configuration for this 
> Apache.Ignite.exe and refer to additional libs/dlls (aka assemblies).



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

[jira] [Commented] (IGNITE-4139) .NET: improve the getting started guide

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-4139:
-

Pavel, I've added instructions and other relevant information related to 
default `modules\platforms\dotnet\bin\Apache.Ignite.exe` under this section [1].

Specifically, the updates were appended to the end of these blocks [2], [3] and 
[4].

Please review on your side and assign on [~pgarg] for final validation.

[1] 
https://apacheignite-net.readme.io/v1.7/docs/getting-started-2#start-from-command-line
[2] 
https://apacheignite-net.readme.io/v1.7/docs/getting-started-2#section-with-default-configuration
[3] 
https://apacheignite-net.readme.io/v1.7/docs/getting-started-2#section-using-app-config
[4] 
https://apacheignite-net.readme.io/v1.7/docs/getting-started-2#section-passing-spring-xml-configuration-file

> .NET: improve the getting started guide
> ---
>
> Key: IGNITE-4139
> URL: https://issues.apache.org/jira/browse/IGNITE-4139
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 1.8
>
>
> The current guide 
> (https://apacheignite-net.readme.io/v1.7/docs/getting-started-2) is based on 
> the fact that you need to build a binary from sources. 
> We should demonstrate how it can be done with 
> ‘modules/platforms/dotnet/bin/Apache.Ignite.exe’ that is already available. 
> Next, we should showcase how we can change a configuration for this 
> Apache.Ignite.exe and refer to additional libs/dlls (aka assemblies).



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

[jira] [Commented] (IGNITE-4124) .NET: inconvenient to debug SQL issue from VisualStudio output

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-4124:
-

Pavel, now referring to your explanation I see how it works and how it 
simplifies the troubleshooting. I've put your explanation here [1] and there 
[2]. Please update it if needed. Finally, please add the table of content to 
SQL page [3]. There are already a lot of sections and it's becoming more 
difficult to navigate.

When you're done on your side please assign ticket on [~pgarg] for the final 
review of the documentation.

[1] 
https://apacheignite-net.readme.io/docs/sql-queries#troubleshooting-sql-queries
[2] 
https://apacheignite-net.readme.io/v1.7/docs/troubleshooting#getting-more-insights-on-exceptions
[3] https://apacheignite-net.readme.io/docs/sql-queries

> .NET: inconvenient to debug SQL issue from VisualStudio output
> --
>
> Key: IGNITE-4124
> URL: https://issues.apache.org/jira/browse/IGNITE-4124
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 1.8
>
>
> It's difficult or not clear how to debug wrong SQL queries from Visual 
> Studio. The output simply says that the query can't be parsed.
> Let's try to improve the user experience here somehow. If it's possible to 
> get more details from Java stack trace it would be perfect. If there are some 
> existed VisualStudio hints then let's document them on this page
> https://apacheignite-net.readme.io/docs/sql-queries



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

[jira] [Updated] (IGNITE-4124) .NET: inconvenient to debug SQL issue from VisualStudio output

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4124:

Assignee: Pavel Tupitsyn  (was: Denis Magda)

> .NET: inconvenient to debug SQL issue from VisualStudio output
> --
>
> Key: IGNITE-4124
> URL: https://issues.apache.org/jira/browse/IGNITE-4124
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
> Fix For: 1.8
>
>
> It's difficult or not clear how to debug wrong SQL queries from Visual 
> Studio. The output simply says that the query can't be parsed.
> Let's try to improve the user experience here somehow. If it's possible to 
> get more details from Java stack trace it would be perfect. If there are some 
> existed VisualStudio hints then let's document them on this page
> https://apacheignite-net.readme.io/docs/sql-queries



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

[jira] [Commented] (IGNITE-4144) ODBC with php PDO: data of Time type cannot be retrieved correctly

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-4144:
-

Seems like SQL engine returns value of type {{Time}}, which we can't serialize 
properly, using binary format. Continuing investigation.

> ODBC with php PDO: data of Time type cannot be retrieved correctly
> --
>
> Key: IGNITE-4144
> URL: https://issues.apache.org/jira/browse/IGNITE-4144
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 1.6
>Reporter: Ksenia Rybakova
>Assignee: Igor Sapego
> Fix For: 1.8
>
>
> Setup:
> Windows 10
> php7.0 + php PDO
> Ignite ODBC drivers is installed and DSN is configured
> Cache stores {{AllTypes}} objects, one of the field of this object is {{Time 
> timeCol}} that stores current time. When we retrieve this field using php pdo
> {noformat}
> $dbh = new PDO('odbc:Apache Ignite DSN');
> $result = $dbh->query('SELECT timeCol from "AllTypes".AllTypes');
> print_r($result->fetch(PDO::FETCH_ASSOC));
> {noformat}
> we get 
> {noformat}
> Array
> (
> [TIME] => 1970-01-01
> )
> {noformat}
> instead of correct hh:mm:ss value



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

[jira] [Commented] (IGNITE-3891) Enable writing hostname, rather than ipaddress for zookeeper discovery

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-3891:
-

Guys, I don't sure that understand correctly this issue, but it seems that 
{{AddressResolver}} should help in case of Ignite nodes in docker container are 
registered with internal addresses. If problem is in Zookeeper connection then 
you can provide connection string or Courator instance to 
{{TcpDiscoveryZookeeperIpFinder}}. It should be enough and doesn't require any 
code changes. See javadoc.

> Enable writing hostname, rather than ipaddress for zookeeper discovery
> --
>
> Key: IGNITE-3891
> URL: https://issues.apache.org/jira/browse/IGNITE-3891
> Project: Ignite
>  Issue Type: Improvement
>  Components: ignite-zookeeper
>Affects Versions: 1.7
> Environment: docker
>Reporter: John Watson
>Assignee: Roman Shtykh
>
> We are using ignite in docker, with zookeeper discovery. We need to be able 
> to use the hostname, rather than the ip address, since the container-visible 
> ip address is not externally usable.
> We would like an option in the TcpDiscoveryZookeeperIpFinder to use the 
> hostname, rather than ipaddress.  This change would impact line 231, where 
> currently the ip address is being written. We suggest adding an option to the 
> class to use the hostname, rather than the ip address.



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

[jira] [Commented] (IGNITE-4116) .NET: documentation and example for client reconnect feature

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4116:


Sure, done.

> .NET: documentation and example for client reconnect feature
> 
>
> Key: IGNITE-4116
> URL: https://issues.apache.org/jira/browse/IGNITE-4116
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
> Fix For: 1.8
>
> Attachments: Screen Shot 2016-10-31 at 8.53.01 AM.png
>
>
> Presently the documentation and example about the client reconnect feature is 
> missing on .NET side. Let's fill this gap.
> - Documentation can be taken from Java side 
> (https://apacheignite.readme.io/docs/clients-vs-servers#client-reconnect)
> - The example that can be (should be) added to the distribution is the 
> following 
> https://github.com/gridgain/apache-ignite/blob/ignite-net-advanced-examples/modules/platforms/dotnet/examples/Apache.Ignite.Examples/Advanced/ClientReconnectExample.cs



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

[jira] [Commented] (IGNITE-4116) .NET: documentation and example for client reconnect feature

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-4116:
-

Pavel, could you add a table of contents to this page similar to the one we 
have on Java side? Refer to the attached screenshot.


> .NET: documentation and example for client reconnect feature
> 
>
> Key: IGNITE-4116
> URL: https://issues.apache.org/jira/browse/IGNITE-4116
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
> Fix For: 1.8
>
> Attachments: Screen Shot 2016-10-31 at 8.53.01 AM.png
>
>
> Presently the documentation and example about the client reconnect feature is 
> missing on .NET side. Let's fill this gap.
> - Documentation can be taken from Java side 
> (https://apacheignite.readme.io/docs/clients-vs-servers#client-reconnect)
> - The example that can be (should be) added to the distribution is the 
> following 
> https://github.com/gridgain/apache-ignite/blob/ignite-net-advanced-examples/modules/platforms/dotnet/examples/Apache.Ignite.Examples/Advanced/ClientReconnectExample.cs



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

[jira] [Updated] (IGNITE-4116) .NET: documentation and example for client reconnect feature

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4116:

Attachment: Screen Shot 2016-10-31 at 8.53.01 AM.png

> .NET: documentation and example for client reconnect feature
> 
>
> Key: IGNITE-4116
> URL: https://issues.apache.org/jira/browse/IGNITE-4116
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
> Fix For: 1.8
>
> Attachments: Screen Shot 2016-10-31 at 8.53.01 AM.png
>
>
> Presently the documentation and example about the client reconnect feature is 
> missing on .NET side. Let's fill this gap.
> - Documentation can be taken from Java side 
> (https://apacheignite.readme.io/docs/clients-vs-servers#client-reconnect)
> - The example that can be (should be) added to the distribution is the 
> following 
> https://github.com/gridgain/apache-ignite/blob/ignite-net-advanced-examples/modules/platforms/dotnet/examples/Apache.Ignite.Examples/Advanced/ClientReconnectExample.cs



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

[jira] [Commented] (IGNITE-4139) .NET: improve the getting started guide

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4139:


> based on the fact that you need to build a binary from sources
That's not true, first two options are NuGet and binary distribution.

> we should showcase how we can change a configuration for this 
> Apache.Ignite.exe and refer to additional libs/dlls
Not sure if this is needed in Getting Started

> .NET: improve the getting started guide
> ---
>
> Key: IGNITE-4139
> URL: https://issues.apache.org/jira/browse/IGNITE-4139
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 1.8
>
>
> The current guide 
> (https://apacheignite-net.readme.io/v1.7/docs/getting-started-2) is based on 
> the fact that you need to build a binary from sources. 
> We should demonstrate how it can be done with 
> ‘modules/platforms/dotnet/bin/Apache.Ignite.exe’ that is already available. 
> Next, we should showcase how we can change a configuration for this 
> Apache.Ignite.exe and refer to additional libs/dlls (aka assemblies).



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

[jira] [Resolved] (IGNITE-4153) .NET: IgniteConfiguration.FailureDetectionTimeout property is missing

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-4153.

Resolution: Fixed
  Assignee: (was: Pavel Tupitsyn)

> .NET: IgniteConfiguration.FailureDetectionTimeout property is missing
> -
>
> Key: IGNITE-4153
> URL: https://issues.apache.org/jira/browse/IGNITE-4153
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 1.8
>
>




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

[jira] [Assigned] (IGNITE-4155) Minor issues wth IgniteSemaphoreExample and HIbernateL2CacheExample

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov reassigned IGNITE-4155:
---

Assignee: Sergey Chugunov

> 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.4#6332)

[jira] [Commented] (IGNITE-1943) ignitevisorcmd: wrong behavior for "mclear" command

[Andrey Novikov (JIRA)]

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

Andrey Novikov commented on IGNITE-1943:


Hi Saikat,
If you run visor {{mclear}} command and then try to execute command like: 
{{config -id8=@nl}} This command will not work, because variables was removed 
and will be restored only after execution of {{node}} command or node join.

{{mcompact}} functionality:
When node leave we can get gap in variable names. For example: {{node}} command 
show @n1, @n2, @n3 variables, then nodes @n1 and @n2 leave. {{node}} command 
show only @n3 After {{mcompact}} @n3 will be renamed to @n1. Also we may print 
changes in variables names or print all variables.

> ignitevisorcmd: wrong behavior for "mclear" command
> ---
>
> Key: IGNITE-1943
> URL: https://issues.apache.org/jira/browse/IGNITE-1943
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Vasilisa  Sidorova
>Assignee: Saikat Maitra
> Fix For: 1.8
>
>
> -
> DESCRIPTION
> -
> "mclear" should clears all Visor console variables before they will be 
> updated during next run of the corresponding command. It OK for all type of 
> shortcut (@cX, @tX, @aX, @eX) exept shortcut for node-id variables. After 
> "mclear" @nX are disappear from any statistics 
> -
> STEPS FOR REPRODUCE
> -
> # Start cluster
> # Start visorcmd ([IGNITE_HOME]/bin/ignitevisorcmd.sh)
> # Connect to the started cluster (visor> open)
> # Execute any tasks in it (for example, run any example from EventsExample, 
> DeploymentExample, ComputeContinuousMapperExample, ComputeTaskMapExample, 
> ComputeTaskSplitExample) 
> # Create several alerts (visor> alert)
> # Run visor "mclear" command
> # Run visor "node" command
> -
> ACTUAL RESULT
> -
> There isn't @nX values in the first table's column:
> {noformat}
> visor> node
> Select node from:
> +==+
> | # |   Node ID8(@), IP   | Up Time  | CPUs | CPU Load | Free Heap |
> +==+
> | 0 | 6B3E4033, 127.0.0.1 | 00:38:41 | 8| 0.20 %   | 97.00 %   |
> | 1 | 0A0D6989, 127.0.0.1 | 00:38:22 | 8| 0.17 %   | 97.00 %   |
> | 2 | 0941E33F, 127.0.0.1 | 00:35:46 | 8| 0.23 %   | 97.00 %   |
> +--+
> {noformat}
> -
> EXPECTED RESULT
> -
> There is @nX values in the first table's column:
> {noformat}
> visor> node
> Select node from:
> +===+
> | # | Node ID8(@), IP  | Up Time  | CPUs | CPU Load | Free Heap |
> +===+
> | 0 | 6B3E4033(@n0), 127.0.0.1 | 00:38:13 | 8| 0.23 %   | 97.00 %   |
> | 1 | 0A0D6989(@n1), 127.0.0.1 | 00:37:54 | 8| 0.27 %   | 97.00 %   |
> | 2 | 0941E33F(@n2), 127.0.0.1 | 00:35:18 | 8| 0.20 %   | 97.00 %   |
> +---+
> {noformat}
> "mclear" should get effect only for "mget @nX" command (with result "Missing 
> variable with name: '@nX'") and @nX variables  should get new values after 
> "node" (or "tasks") command execution. Like in case for all others @ 
> variables (@cX, @tX, @aX, @eX) 



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4106:


GitHub user AMashenkov opened a pull request:

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

IGNITE-4106: SQL: parallelize sql queries over cache local partitions



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

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

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

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


commit 87a1928a4f90b4f8a221041cfff9d22e3dd801cc
Author: vozerov-gridgain 
Date:   2016-08-26T12:22:15Z

IGNITE-3776: Removed code duplication in GridNearAtomicAbstractUpdateFuture.

commit 92f18bf353cc8c3821c6500ce9f1cd397a7cf17c
Author: Andrey V. Mashenkov 
Date:   2016-08-26T12:31:30Z

IGNITE-3745: ODBC: Implemented date/time/timestamp escape sequence parsing. 
This closes #991.

commit b5757642e135908d9baa027a605035dd0d4acfc9
Author: tledkov-gridgain 
Date:   2016-08-26T12:47:02Z

IGNITE-3670 IGFS: Improved symlink handling for delete operation and added 
more tests. This closes #975.

commit 289170346e40a89243b80d3743c1b66543a117ef
Author: Igor Sapego 
Date:   2016-08-29T12:00:08Z

IGNITE-3773: ODBC: Added tests for UUID data type. This closes #993.

commit 0465874d9dddcf962a82a2ef38589121201f0b75
Author: agura 
Date:   2016-08-24T18:13:29Z

ignite-2968 Deadlock detection for optimistic tx and near caches

commit fea3eeaac839381ec3662275a82f4d12af6f12dd
Author: agura 
Date:   2016-08-29T15:38:35Z

Merged ignite-1.6.7 to ignite-1.7.2

commit 407071e466d1a4fcec86571d4791ace8bb206f53
Author: Eduard Shangareev 
Date:   2016-08-30T00:32:31Z

IGNITE-2546 - Transformers for SCAN queries. Fixes #949.

commit f9ff97c91374dcd9cd8ad08d46d1d2de44193060
Author: Andrey V. Mashenkov 
Date:   2016-08-30T06:31:20Z

ignite-2560 Support resource injection for entry processor, optimizations 
for resource injection.

commit 3244a5c9dabf6d4fcaa32a661cc0adc6f8ea30de
Author: Andrey V. Mashenkov 
Date:   2016-08-30T08:49:11Z

IGNITE-3742: ODBC: Added support for OUTER JOIN escape sequence. This 
closes #1000.

commit fbbcaf4322548f61d2f63bf5d4e8f6d5284e73d3
Author: Andrey V. Mashenkov 
Date:   2016-08-30T10:22:29Z

IGNITE-3798: ODBC: Added literals support. This closes #1005.

commit 1ef150eba52eb63c2bfc3fafa0d036cf26be1c5b
Author: Alexey Kuznetsov 
Date:   2016-08-30T11:18:20Z

Revert wrong merge.

commit 4a259da296946740e180d25559e5cacba60a97ad
Author: EdShangGG 
Date:   2016-08-30T11:39:13Z

Merge remote-tracking branch 'ignite-gg/ignite-1.6.7' into ignite-1.7.2

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/query/GridCacheQueryManager.java
#   
modules/indexing/src/test/java/org/apache/ignite/testsuites/IgniteCacheQuerySelfTestSuite.java
#   
modules/spring/src/test/java/org/apache/ignite/testsuites/IgniteSpringTestSuite.java

commit 31dbc5d65f8ea51010d2129e7c6e9a27acbf8528
Author: isapego 
Date:   2016-08-30T14:28:34Z

Fix for C++ tests.

commit dabd86c62e39eb983ef3d198c8b8ee96d2623c84
Author: Andrey Novikov 
Date:   2016-08-31T09:00:19Z

IGNITE-3811 Fixed query for merge with complex key on SQL Server.

commit 70e69cb7aa08c268b07920838add4a40e28fe25d
Author: isapego 
Date:   2016-08-31T13:47:11Z

IGNITE-3390: Added DSN configuration window.

commit bdbc5a37c1924ba4427221ee6cdf506c7f3ba248
Author: isapego 
Date:   2016-08-31T14:13:34Z

Merge branch 'ignite-1.6.7' into ignite-1.7.2

commit 12f532986677c30a716f73aeaa7d3587dd701f55
Author: sboikov 
Date:   2016-09-01T14:05:15Z

Merge remote-tracking branch 'remotes/community/ignite-1.6.6' into 
ignite-1.6.7

commit ae7765329fd6f7d50d13183d13626f39c5682334
Author: dkarachentsev 
Date:   2016-09-02T15:01:12Z

IGNITE-2208 - Queries with object arguments doesn't work wth 
BinaryMarshaller.

commit 7a84ab6a9163ca31fbcfcc6d7ff27e06bf9babef
Author: vozerov-gridgain 
Date:   2016-09-02T15:05:16Z

IGNITE-3827: Removed double marshalling of keys in 
DataStreamerImpl.addData(Map) method.

commit 7bb961fd0a2e78334d33b6bc279c4edc323c246a
Author: vozerov-gridgain 

[jira] [Created] (IGNITE-4155) Minor issues wth IgniteSemaphoreExample and HIbernateL2CacheExample

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-4155:
---

 Summary: 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
Priority: Minor


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.4#6332)

[jira] [Commented] (IGNITE-3191) BinaryObjectBuilder: binary schema id depends on the order of fields addition

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-3191:
--

[Test 
results|http://195.239.208.174/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull%2F1197%2Fhead]

> BinaryObjectBuilder: binary schema id depends on the order of fields addition
> -
>
> Key: IGNITE-3191
> URL: https://issues.apache.org/jira/browse/IGNITE-3191
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 1.8
>
>
> Presently if an object is created using BinaryObjectBuilder then several 
> BinarySchemes can be generated for the same set of fields in case when fields 
> are added in a different order.
> This happens because {{LinkedHashMap}} is used underneath. However we should 
> rely on order-free structure like {{TreeMap}}.



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

[jira] [Comment Edited] (IGNITE-3191) BinaryObjectBuilder: binary schema id depends on the order of fields addition

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-3191 at 10/31/16 2:12 PM:


[Tests 
results|http://195.239.208.174/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull%2F1197%2Fhead]


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

> BinaryObjectBuilder: binary schema id depends on the order of fields addition
> -
>
> Key: IGNITE-3191
> URL: https://issues.apache.org/jira/browse/IGNITE-3191
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 1.8
>
>
> Presently if an object is created using BinaryObjectBuilder then several 
> BinarySchemes can be generated for the same set of fields in case when fields 
> are added in a different order.
> This happens because {{LinkedHashMap}} is used underneath. However we should 
> rely on order-free structure like {{TreeMap}}.



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

[jira] [Commented] (IGNITE-4116) .NET: documentation and example for client reconnect feature

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4116:


Documentation updated: 
https://apacheignite-net.readme.io/docs/clients-and-servers.

Waiting for IGNITE-4117.

> .NET: documentation and example for client reconnect feature
> 
>
> Key: IGNITE-4116
> URL: https://issues.apache.org/jira/browse/IGNITE-4116
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
> Fix For: 1.8
>
>
> Presently the documentation and example about the client reconnect feature is 
> missing on .NET side. Let's fill this gap.
> - Documentation can be taken from Java side 
> (https://apacheignite.readme.io/docs/clients-vs-servers#client-reconnect)
> - The example that can be (should be) added to the distribution is the 
> following 
> https://github.com/gridgain/apache-ignite/blob/ignite-net-advanced-examples/modules/platforms/dotnet/examples/Apache.Ignite.Examples/Advanced/ClientReconnectExample.cs



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

[jira] [Commented] (IGNITE-4117) .NET: after the reconnection client fails while trying to get a reference to a cache

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4117:
-

LGTM.

> .NET: after the reconnection client fails while trying to get a reference to 
> a cache
> 
>
> Key: IGNITE-4117
> URL: https://issues.apache.org/jira/browse/IGNITE-4117
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Denis Magda
>Assignee: Vladimir Ozerov
> Fix For: 1.8
>
>
> In the following example 
> https://github.com/gridgain/apache-ignite/blob/ignite-net-advanced-examples/modules/platforms/dotnet/examples/Apache.Ignite.Examples/Advanced/ClientReconnectExample.cs
> we deliberately added these lines of the code
> {code}
> while (!task.IsCompleted) // workaround.
> task.Wait();
> Console.WriteLine(">>> Client has reconnected 
> successfully");
> //Workaround.
> System.Threading.Thread.Sleep(3000);
> {code}
> because otherwise after the clients successfully reconnects to the cluster it 
> expects different issues that prevent from using it. In particular, the 
> example will throw cache related exception at the next line but this mustn't 
> happen
> {code}
> // Updating the reference to the cache. The 
> client reconnected to the new cluster.
> cache = ignite.GetOrCreateCache string>(CacheName);
> {code} 
> Step to reproduce:
> - Start remote .NET node;
> - Start the example;
> - Restart the remote node.
> The issue is 100% reproducible on my VirtualBox Windows 8.1 machine.



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

[jira] [Updated] (IGNITE-4144) ODBC with php PDO: data of Time type cannot be retrieved correctly

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-4144:

Fix Version/s: 1.8

> ODBC with php PDO: data of Time type cannot be retrieved correctly
> --
>
> Key: IGNITE-4144
> URL: https://issues.apache.org/jira/browse/IGNITE-4144
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 1.6
>Reporter: Ksenia Rybakova
>Assignee: Igor Sapego
> Fix For: 1.8
>
>
> Setup:
> Windows 10
> php7.0 + php PDO
> Ignite ODBC drivers is installed and DSN is configured
> Cache stores {{AllTypes}} objects, one of the field of this object is {{Time 
> timeCol}} that stores current time. When we retrieve this field using php pdo
> {noformat}
> $dbh = new PDO('odbc:Apache Ignite DSN');
> $result = $dbh->query('SELECT timeCol from "AllTypes".AllTypes');
> print_r($result->fetch(PDO::FETCH_ASSOC));
> {noformat}
> we get 
> {noformat}
> Array
> (
> [TIME] => 1970-01-01
> )
> {noformat}
> instead of correct hh:mm:ss value



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

[jira] [Commented] (IGNITE-4090) CPP: Make sure Ignite C++ can be compiled with g++ 4.4.7

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-4090:
-

Fixed.

> CPP: Make sure Ignite C++ can be compiled with g++ 4.4.7
> 
>
> Key: IGNITE-4090
> URL: https://issues.apache.org/jira/browse/IGNITE-4090
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.7
>Reporter: Igor Sapego
>Assignee: Vladimir Ozerov
>  Labels: cpp
> Fix For: 1.8
>
>
> Make sure that Ignite C++ can be compiled with particular compiler version. 
> Version details:
> {noformat}
> g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16)
> Copyright (C) 2010 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> {noformat}



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

[jira] [Assigned] (IGNITE-3075) Implement single key-value pair DHT request/response for ATOMIC cache.

[Konstantin Dudkov (JIRA)]

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

Konstantin Dudkov reassigned IGNITE-3075:
-

Assignee: Konstantin Dudkov  (was: Alexander Paschenko)

> Implement single key-value pair DHT request/response for ATOMIC cache.
> --
>
> Key: IGNITE-3075
> URL: https://issues.apache.org/jira/browse/IGNITE-3075
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Konstantin Dudkov
>  Labels: performance
> Fix For: 1.8
>
>
> Need to implement specialized light-weight version of DHT request/response to 
> make the most common case - single KV update - more performant.



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

[jira] [Created] (IGNITE-4154) Optimize amount of data stored in discovery history

[Semen Boikov (JIRA)]

Semen Boikov created IGNITE-4154:


 Summary: Optimize amount of data stored in discovery history
 Key: IGNITE-4154
 URL: https://issues.apache.org/jira/browse/IGNITE-4154
 Project: Ignite
  Issue Type: Task
  Components: general
Reporter: Semen Boikov
Assignee: Semen Boikov
 Fix For: 1.8


Currently on large clusters with lots of caches amount of data stored in tcp 
discovery history can grow too much.

What can be improved:
- TcpDiscoveryNodeAddedMessage.oldNodesDiscoData contains per-node discovery 
data. For cache component essentially this is list of configured caches, and 
for joined node at the time when 'collectDiscoveryData' is called this list 
should be the same on all nodes, so it can be stored once instead of per-node 
map
- even after message is discarded it is still stored in PendingMessages 
collection, looks like it can be safely removed after discarding
- now system property IGNITE_DISCOVERY_HISTORY_SIZE controls both size of 
events needed for client reconnects and number of topology snapshots stored in 
GridDiscoveryManager, need have two properies
- for clients TcpDiscoveryNodeAddFinishedMessage.clientDiscoData can be 
initialized only when message is sent to joining client 




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

[jira] [Reopened] (IGNITE-4090) CPP: Make sure Ignite C++ can be compiled with g++ 4.4.7

[Igor Sapego (JIRA)]

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

Igor Sapego reopened IGNITE-4090:
-
  Assignee: Igor Sapego  (was: Vladimir Ozerov)

Seems like issue can still be reproduced on Red Hat:
{noformat}
  CXXsrc/query/foreign_keys_query.lo
  CXXsrc/query/primary_keys_query.lo
  CXXsrc/query/table_metadata_query.lo
  CXXsrc/query/type_info_query.lo
  CXXsrc/query/special_columns_query.lo
  CXXsrc/protocol_version.lo
src/protocol_version.cpp:29: error: ‘INT64_MIN’ was not declared in this scope
make[3]: *** [src/protocol_version.lo] Error 1
{noformat}

> CPP: Make sure Ignite C++ can be compiled with g++ 4.4.7
> 
>
> Key: IGNITE-4090
> URL: https://issues.apache.org/jira/browse/IGNITE-4090
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.7
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 1.8
>
>
> Make sure that Ignite C++ can be compiled with particular compiler version. 
> Version details:
> {noformat}
> g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16)
> Copyright (C) 2010 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> {noformat}



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

[jira] [Commented] (IGNITE-500) CacheLoadingConcurrentGridStartSelfTest fails

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-500:
-

After conversation with Semen, 

3) replaced with 
{noformat}final boolean allowOverwrite = !(updater instanceof 
DataStreamerImpl.IsolatedUpdater);{noformat}
5) replaced with 
{noformat}catch (Exception ex) {noformat}
TeamCity will be rechecked to find issues.
6) added test with restarts.

> CacheLoadingConcurrentGridStartSelfTest fails
> -
>
> Key: IGNITE-500
> URL: https://issues.apache.org/jira/browse/IGNITE-500
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Yakov Zhdanov
>Assignee: Anton Vinogradov
>Priority: Critical
>  Labels: Muted_test, important, user-request
> Fix For: 1.8
>
> Attachments: ignite-500.log
>
>
> http://apacheignite.readme.io/v1.0/discuss/550865a8e35e9c3b0083af3e



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

[jira] [Commented] (IGNITE-3191) BinaryObjectBuilder: binary schema id depends on the order of fields addition

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-3191:
--

According with the IGNITE-1377 Vladimir's fix is properly. We cannot update 
metadata on deserialization.

> BinaryObjectBuilder: binary schema id depends on the order of fields addition
> -
>
> Key: IGNITE-3191
> URL: https://issues.apache.org/jira/browse/IGNITE-3191
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 1.8
>
>
> Presently if an object is created using BinaryObjectBuilder then several 
> BinarySchemes can be generated for the same set of fields in case when fields 
> are added in a different order.
> This happens because {{LinkedHashMap}} is used underneath. However we should 
> rely on order-free structure like {{TreeMap}}.



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

[jira] [Created] (IGNITE-4153) .NET: IgniteConfiguration.FailureDetectionTimeout property is missing

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4153:
--

 Summary: .NET: IgniteConfiguration.FailureDetectionTimeout 
property is missing
 Key: IGNITE-4153
 URL: https://issues.apache.org/jira/browse/IGNITE-4153
 Project: Ignite
  Issue Type: Sub-task
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn






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

[jira] [Assigned] (IGNITE-4117) .NET: after the reconnection client fails while trying to get a reference to a cache

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-4117:
--

Assignee: Pavel Tupitsyn

> .NET: after the reconnection client fails while trying to get a reference to 
> a cache
> 
>
> Key: IGNITE-4117
> URL: https://issues.apache.org/jira/browse/IGNITE-4117
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
> Fix For: 1.8
>
>
> In the following example 
> https://github.com/gridgain/apache-ignite/blob/ignite-net-advanced-examples/modules/platforms/dotnet/examples/Apache.Ignite.Examples/Advanced/ClientReconnectExample.cs
> we deliberately added these lines of the code
> {code}
> while (!task.IsCompleted) // workaround.
> task.Wait();
> Console.WriteLine(">>> Client has reconnected 
> successfully");
> //Workaround.
> System.Threading.Thread.Sleep(3000);
> {code}
> because otherwise after the clients successfully reconnects to the cluster it 
> expects different issues that prevent from using it. In particular, the 
> example will throw cache related exception at the next line but this mustn't 
> happen
> {code}
> // Updating the reference to the cache. The 
> client reconnected to the new cluster.
> cache = ignite.GetOrCreateCache string>(CacheName);
> {code} 
> Step to reproduce:
> - Start remote .NET node;
> - Start the example;
> - Restart the remote node.
> The issue is 100% reproducible on my VirtualBox Windows 8.1 machine.



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

[jira] [Updated] (IGNITE-1362) Update notifier causes Ignite instance leak.

[Semen Boikov (JIRA)]

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

Semen Boikov updated IGNITE-1362:
-
Description: 
IgniteKernal has private non-static anonymous class for GridTimerTask which 
forces update notify. 
As a result IgniteKernal instance leaks to it and stays in memory for a long 
time even after node is stopped.

  was:
IgniteKernal has private non-static anonymous class for GridTimerTask which 
forces üpdate notify. 
As a result IgniteKernal instance leaks to it and stays in memory for a long 
time even after node is stopped.


> Update notifier causes Ignite instance leak.
> 
>
> Key: IGNITE-1362
> URL: https://issues.apache.org/jira/browse/IGNITE-1362
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: ignite-1.4
>
>
> IgniteKernal has private non-static anonymous class for GridTimerTask which 
> forces update notify. 
> As a result IgniteKernal instance leaks to it and stays in memory for a long 
> time even after node is stopped.



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

[jira] [Updated] (IGNITE-2296) Apache copyright link opens 404 page

[Semen Boikov (JIRA)]

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

Semen Boikov updated IGNITE-2296:
-
Description: Scalar and Java docs pages has text "2015 Copyright Apache 
Software Foundation" on bottom and it linked on 
https://apache.org/projects/ignite.html. But now it's 404 page and a correct 
URL is https://ignite.apache.org/  (was: Scalar and Java docs pages has text 
"2015 Copyright © Apache Software Foundation" on bottom and it linked on 
https://apache.org/projects/ignite.html. But now it's 404 page and a correct 
URL is https://ignite.apache.org/)

> Apache copyright link opens 404 page
> 
>
> Key: IGNITE-2296
> URL: https://issues.apache.org/jira/browse/IGNITE-2296
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 1.5.0.final
>Reporter: Sergey Kozlov
> Fix For: 1.5.0.final
>
>
> Scalar and Java docs pages has text "2015 Copyright Apache Software 
> Foundation" on bottom and it linked on 
> https://apache.org/projects/ignite.html. But now it's 404 page and a correct 
> URL is https://ignite.apache.org/



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

[jira] [Comment Edited] (IGNITE-3191) BinaryObjectBuilder: binary schema id depends on the order of fields addition

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-3191 at 10/31/16 10:09 AM:
-

Root cause:
at the {{BinaryContext.registerUserClassDescriptor}} metadata is not updated on 
deserialize. 

So, the fail case is:
1. *New node* writes object to the cache, update system cache & local maps with 
*new-schema*;
2. *Old node* reads the object from binary. Create local 
{{BinaryClassDescriptor}} with *old-schema* as a stable schema. *New-chema* is 
available at the schemes registry. Does't update metadata (doesn't merge 
*old-schema* & *new-schema*);
3. *Old node* writes object to the cache. The new {{BinaryClassDescriptor}} 
isn't created because the descriptor is added to the local maps at the *step* 
2. The stable *old-schema* is used.
4. *New-node* cannot deserialize the object with *old-shema*.

The suggestion fix from Vladimir updates metadata on the *step 3*. 
So, in case the object has been created on the old node then the object is 
created on the new-node all works properly because new node updates the system 
cache with *new-schema*.

Conclusion:
1. I guess we have to fix the metadata & system caches update on the *step 2* 
(when the local instance of the {{BinaryClassDescriptor}} is created the 
first.) to prevent this problem in the future.
2. The fix for fields ordering should be switched by system property until the 
backward compatibility is required.



was (Author: tledkov-gridgain):
Root cause:
at the {{BinaryContext.registerUserClassDescriptor}} metadata is not updated on 
deserialize. 

So, the fail case is:
1. *New node* writes object to the cache, update system cache & local maps with 
*new-schema*;
2. *Old node* reads the object from binary. Create local 
{{BinaryClassDescriptor}} with *old-schema* as a stable schema. *New-chema* is 
available at the schemes registry. Does't update metadata (doesn't merge 
*old-schema* & *new-schema*);
3. *Old node* writes object to the cache. The new {{BinaryClassDescriptor}} 
isn't created because the descriptor is added to the local maps at the *step* 
2. The stable *old-schema* is used.
4. *New-node* cannot deserialize the object with *old-shema*.

The suggestion fix from Vladimir updates metadata on the *step 3*. 
So, in case the object has been created on the old node then the object is 
created on the new-node all works properly because new node updates the system 
cache with *new-schema*.

Conclusion:
1. I guess we have to fix the metadata & system caches update on the *step 2* 
(when the local instance of the {{BinaryClassDescriptor}} is created the 
first.) to prevent this problem in the future.
2. The fix for fields ordering should be switched by system property until the 
backward compatibility is required.


> BinaryObjectBuilder: binary schema id depends on the order of fields addition
> -
>
> Key: IGNITE-3191
> URL: https://issues.apache.org/jira/browse/IGNITE-3191
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 1.8
>
>
> Presently if an object is created using BinaryObjectBuilder then several 
> BinarySchemes can be generated for the same set of fields in case when fields 
> are added in a different order.
> This happens because {{LinkedHashMap}} is used underneath. However we should 
> rely on order-free structure like {{TreeMap}}.



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

[jira] [Commented] (IGNITE-3191) BinaryObjectBuilder: binary schema id depends on the order of fields addition

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-3191:
--

Root cause:
at the {{BinaryContext.registerUserClassDescriptor}} metadata is not updated on 
deserialize. 

So, the fail case is:
1. *New node* writes object to the cache, update system cache & local maps with 
*new-schema*;
2. *Old node* reads the object from binary. Create local 
{{BinaryClassDescriptor}} with *old-schema* as a stable schema. *New-chema* is 
available at the schemes registry. Does't update metadata (doesn't merge 
*old-schema* & *new-schema*);
3. *Old node* writes object to the cache. The new {{BinaryClassDescriptor}} 
isn't created because the descriptor is added to the local maps at the *step* 
2. The stable *old-schema* is used.
4. *New-node* cannot deserialize the object with *old-shema*.

The suggestion fix from Vladimir updates metadata on the *step 3*. 
So, in case the object has been created on the old node then the object is 
created on the new-node all works properly because new node updates the system 
cache with *new-schema*.

Conclusion:
1. I guess we have to fix the metadata & system caches update on the *step 2* 
(when the local instance of the {{BinaryClassDescriptor}} is created the 
first.) to prevent this problem in the future.
2. The fix for fields ordering should be switched by system property until the 
backward compatibility is required.


> BinaryObjectBuilder: binary schema id depends on the order of fields addition
> -
>
> Key: IGNITE-3191
> URL: https://issues.apache.org/jira/browse/IGNITE-3191
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 1.8
>
>
> Presently if an object is created using BinaryObjectBuilder then several 
> BinarySchemes can be generated for the same set of fields in case when fields 
> are added in a different order.
> This happens because {{LinkedHashMap}} is used underneath. However we should 
> rely on order-free structure like {{TreeMap}}.



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

[jira] [Comment Edited] (IGNITE-500) CacheLoadingConcurrentGridStartSelfTest fails

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov edited comment on IGNITE-500 at 10/31/16 9:42 AM:
---

Semen, thanks for review and fixes.

1){noformat}as I understand new streaming by 'current topology + affinity' is 
needed only when IsolatedUpdater is used (i.e. allowOverwrite=false)?{noformat}
Correct. 

2){noformat}I think you need fix DataStreamerImpl.nodes to use 
'cctx.topology().nodes' only for IsolatedUpdater{noformat}
It's already works this way

{noformat}
if (!allowOverwrite())
res = cctx.isLocal() ?
aff.mapKeyToPrimaryAndBackups(cacheName, key, topVer) :
cctx.topology().nodes(key.partition(), topVer);
{noformat} 

is that what you mention about?

3){noformat}, also you do not need to add new field in DataStreamerRequest, 
allowOverwriet is true is updater 'instance of IsolatedUpdater'{noformat}
Updater is an IsolatedUpdater instance from another node.
Possible, in future IsolatedUpdater will be refactored to IsolatedUpdaterV2 or 
relocated to another package and "instance of IsolatedUpdater" check at old 
nodes will fail. 

4){noformat}in DataStreamerImpl constructor you create cache if it does not 
exists only for clients. Why this is not needed for server nodes?{noformat}
Fixed & added test.

5){noformat}in Ignite code 'catch (Throwable ex)' is not usually used, why you 
need catch Throwable? If this is really needed then you must re-throw 
Errors.{noformat}
This catchs AssertionErrors as well. Agree that this should be refactored, can 
you give me some tips how to do that in proper way?

6){noformat}please add test with server nodes restart in 
CacheLoadingConcurrentGridStartSelfTest{noformat}
In this case streamer should fail with exception, this checked at another 
tests, for example IgniteClientReconnectStreamerTest.

7){noformat}I did not understand changes in GridCompoundFuture, please 
explain{noformat}
Compound future can fail on exception from another node and it was hard to 
analyze where Compound future actually failed, so I extended exception with 
"current" stack trace. 
Yes, Better solution in to extend stack trace of exceptions gained from another 
nodes.
Fixed. GridCompoundFuture changes rollbacked.

8){noformat}Also for debug purpose please add topology version in data streamer 
future (which is created in GridCacheMvccManager) and print all these futures 
in GridCachePartitionExchangeManager.dumpPendingObjects.{noformat}
Done.


was (Author: avinogradov):
Semen, thanks for review and fixes.

1){noformat}as I understand new streaming by 'current topology + affinity' is 
needed only when IsolatedUpdater is used (i.e. allowOverwrite=false)?{noformat}
Correct. 

2){noformat}I think you need fix DataStreamerImpl.nodes to use 
'cctx.topology().nodes' only for IsolatedUpdater{noformat}
It's already works this way

{noformat}
if (!allowOverwrite())
res = cctx.isLocal() ?
aff.mapKeyToPrimaryAndBackups(cacheName, key, topVer) :
cctx.topology().nodes(key.partition(), topVer);
{noformat} 

is that what you mention about?

3){noformat}, also you do not need to add new field in DataStreamerRequest, 
allowOverwriet is true is updater 'instance of IsolatedUpdater'{noformat}
Updater is an IsolatedUpdater instance from another node.
Possible, in future IsolatedUpdater will be refactored to IsolatedUpdaterV2 or 
relocated to another package and "instance of IsolatedUpdater" check at old 
nodes will fail. 

4){noformat}in DataStreamerImpl constructor you create cache if it does not 
exists only for clients. Why this is not needed for server nodes?{noformat}
Fixed & added test.

5){noformat}in Ignite code 'catch (Throwable ex)' is not usually used, why you 
need catch Throwable? If this is really needed then you must re-throw 
Errors.{noformat}
This catchs AssertionErrors as well. Agree that this should be refactored, can 
you give me some tips how to do that in proper way?

6){noformat}please add test with server nodes restart in 
CacheLoadingConcurrentGridStartSelfTest{noformat}
In this case streamer should fail with exception, this checked at another 
tests, for example IgniteClientReconnectStreamerTest.

7){noformat}I did not understand changes in GridCompoundFuture, please 
explain{noformat}
Compound future can fail on exception from another node and it was hard to 
analyze where Compound future actually failed, so I extended exception with 
"current" stack trace. 
Yes, Better solution in to extend stack trace of exceptions gained from another 
nodes.
Fixed.

8){noformat}Also for debug purpose please add topology version in data streamer 
future (which is created in GridCacheMvccManager) and print all these futures 
in GridCachePartitionExchangeManager.dumpPendingObjects.{noformat}
Done.

> 

[jira] [Closed] (IGNITE-3944) Web console: Implement configuration of CheckpointSpi

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov closed IGNITE-3944.
--
Assignee: Alexey Kuznetsov  (was: Pavel Konstantinov)

> Web console: Implement configuration of CheckpointSpi
> -
>
> Key: IGNITE-3944
> URL: https://issues.apache.org/jira/browse/IGNITE-3944
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.8
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
> Fix For: 1.8
>
> Attachments: ig-3944.png
>
>




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