[jira] [Commented] (IGNITE-2415) Add an example of usage for CacheLoadOnlyStoreAdapter

2016-03-21 Thread Roman Shtykh (JIRA) 

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

Roman Shtykh commented on IGNITE-2415:
--

[~dmagda] Denis, would you be able to review this example?

> Add an example of usage for CacheLoadOnlyStoreAdapter
> -
>
> Key: IGNITE-2415
> URL: https://issues.apache.org/jira/browse/IGNITE-2415
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Roman Shtykh
> Fix For: 1.6
>
>
> There is a high demand on the functionality provided by 
> {{CacheLoadOnlyStoreAdapter}} from the community.
> It's quite often needed to preload a cache from a read only storage that can 
> be a DB, CSV or other file.
> Definately it's time to add the example.
>  



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

[jira] [Commented] (IGNITE-2415) Add an example of usage for CacheLoadOnlyStoreAdapter

2016-03-21 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on IGNITE-2415:


GitHub user shroman opened a pull request:

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

IGNITE-2415: CacheLoadOnlyStoreAdapter use example.



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

$ git pull https://github.com/shroman/ignite ignite-2415

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

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


commit ad704391e8d6f4019d4401a43b3cede197b860a0
Author: shtykh_roman 
Date:   2016-03-22T05:27:34Z

IGNITE-2415: CacheLoadOnlyStoreAdapter use example.




> Add an example of usage for CacheLoadOnlyStoreAdapter
> -
>
> Key: IGNITE-2415
> URL: https://issues.apache.org/jira/browse/IGNITE-2415
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Roman Shtykh
> Fix For: 1.6
>
>
> There is a high demand on the functionality provided by 
> {{CacheLoadOnlyStoreAdapter}} from the community.
> It's quite often needed to preload a cache from a read only storage that can 
> be a DB, CSV or other file.
> Definately it's time to add the example.
>  



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

[jira] [Commented] (IGNITE-2870) .NET: Attribute-based SQL configuration handles nested indexed field incorrectly

2016-03-21 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on IGNITE-2870:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-2870 .NET: Fix index names for nested fields in attribute-based SQL 
configuration



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

$ git pull https://github.com/ptupitsyn/ignite ignite-2870

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

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


commit 5a54b3c272d9aa0f5500ab649a54599c9aa3b0a8
Author: Pavel Tupitsyn 
Date:   2016-03-21T17:02:13Z

IGNITE-2870 .NET: Attribute-based SQL configuration handles nested indexed 
field incorrectly

commit e02c00ac1002e49309776c5926f1ab62fe041d06
Author: Pavel Tupitsyn 
Date:   2016-03-21T17:18:39Z

Fix index names




> .NET: Attribute-based SQL configuration handles nested indexed field 
> incorrectly
> 
>
> Key: IGNITE-2870
> URL: https://issues.apache.org/jira/browse/IGNITE-2870
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Blocker
> Fix For: 1.6
>
>
> For nested fields (Employee.Address.Zip, for example)
> * QueryEntity.fields expects dot notation: address.zip
> * QueryEntity.indexes expects only field name: zip
> [QuerySqlField(IsIndexed=true)] results in dot notation in both cases, which 
> causes hang on cache creation.



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

[jira] [Created] (IGNITE-2870) .NET: Attribute-based SQL configuration handles nested indexed field incorrectly

2016-03-21 Thread Pavel Tupitsyn (JIRA) 
Pavel Tupitsyn created IGNITE-2870:
--

 Summary: .NET: Attribute-based SQL configuration handles nested 
indexed field incorrectly
 Key: IGNITE-2870
 URL: https://issues.apache.org/jira/browse/IGNITE-2870
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 1.6
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Priority: Blocker
 Fix For: 1.6


For nested fields (Employee.Address.Zip, for example)
* QueryEntity.fields expects dot notation: address.zip
* QueryEntity.indexes expects only field name: zip

[QuerySqlField(IsIndexed=true)] results in dot notation in both cases, which 
causes hand on cache creation.



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

[jira] [Updated] (IGNITE-2870) .NET: Attribute-based SQL configuration handles nested indexed field incorrectly

2016-03-21 Thread Pavel Tupitsyn (JIRA) 

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

Pavel Tupitsyn updated IGNITE-2870:
---
Description: 
For nested fields (Employee.Address.Zip, for example)
* QueryEntity.fields expects dot notation: address.zip
* QueryEntity.indexes expects only field name: zip

[QuerySqlField(IsIndexed=true)] results in dot notation in both cases, which 
causes hang on cache creation.

  was:
For nested fields (Employee.Address.Zip, for example)
* QueryEntity.fields expects dot notation: address.zip
* QueryEntity.indexes expects only field name: zip

[QuerySqlField(IsIndexed=true)] results in dot notation in both cases, which 
causes hand on cache creation.


> .NET: Attribute-based SQL configuration handles nested indexed field 
> incorrectly
> 
>
> Key: IGNITE-2870
> URL: https://issues.apache.org/jira/browse/IGNITE-2870
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Blocker
> Fix For: 1.6
>
>
> For nested fields (Employee.Address.Zip, for example)
> * QueryEntity.fields expects dot notation: address.zip
> * QueryEntity.indexes expects only field name: zip
> [QuerySqlField(IsIndexed=true)] results in dot notation in both cases, which 
> causes hang on cache creation.



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

[jira] [Updated] (IGNITE-708) Need to remove background partition exchange

2016-03-21 Thread Anton Vinogradov (JIRA) 

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

Anton Vinogradov updated IGNITE-708:

Assignee: (was: Gianfranco Murador)

> Need to remove background partition exchange
> 
>
> Key: IGNITE-708
> URL: https://issues.apache.org/jira/browse/IGNITE-708
> Project: Ignite
>  Issue Type: Task
>Affects Versions: ignite-1.4
>Reporter: Yakov Zhdanov
>Priority: Blocker
>  Labels: datagrid
> Fix For: 1.6
>
>
> Now every node sends its partition map to cache coordinator (which is the 
> oldest node in topology) and coordinator spreads full partition map to every 
> node in topology. This happens for each cache separately. This seems to take 
> place even if there were no changes to local partition maps. Given we 
> guarantee communication message delivery this background process seems to be 
> an overkill.
> Exchange should happen only if any changes took place.
> After dynamic cache start has been introduced, we can have significant amount 
> of live caches at some point of app lifecycle and app may suffer from  
> background exchange which is obviously not a requirement (and may be never 
> has been the one).



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

[jira] [Commented] (IGNITE-2801) Coordinator floods network with partitions full map exchange messages

2016-03-21 Thread Denis Magda (JIRA) 

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

Denis Magda commented on IGNITE-2801:
-

Quite weird place. [~sboikov], [~agoncharuk] please comment on why do we need 
this stuff at line 1270

> Coordinator floods network with partitions full map exchange messages
> -
>
> Key: IGNITE-2801
> URL: https://issues.apache.org/jira/browse/IGNITE-2801
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Anton Vinogradov
>Priority: Critical
>  Labels: community, important
> Fix For: 1.6
>
> Attachments: basic_node.nps, basic_node.png, coordinator.nps, 
> coordinator.png
>
>
> It is detected that the more machines in the cluster we have and the more 
> caches are started then the more outgoing traffic is produced by a 
> coordinator node.
> As an example in the current deployment
> - 30 nodes;
> - 67 caches;
> - caches are empty and the cluster is not used at all (idle).
> the coordinator constantly uses 300 Mbit/s of outgoing traffic. In contrast 
> each other node shows constant 10 Mbit/s usage of incoming traffic.
> Most likely the reason is that the coordinator indefinitely sends partitions 
> full map for all the caches to all the nodes. This shouldn't happen.
> Need to debug the reason of the issue and fix it.
> Attached snapshots taken from the coordinator and on of cluster's nodes. 
> Probably they would help.



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

[jira] [Commented] (IGNITE-2801) Coordinator floods network with partitions full map exchange messages

2016-03-21 Thread Anton Vinogradov (JIRA) 

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

Anton Vinogradov commented on IGNITE-2801:
--

Removal of refreshPartitions(timeout); at 
org/apache/ignite/internal/processors/cache/GridCachePartitionExchangeManager.java:1270
 
solves problem by turning off redundand background exchange.

Am I missed something?

> Coordinator floods network with partitions full map exchange messages
> -
>
> Key: IGNITE-2801
> URL: https://issues.apache.org/jira/browse/IGNITE-2801
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Anton Vinogradov
>Priority: Critical
>  Labels: community, important
> Fix For: 1.6
>
> Attachments: basic_node.nps, basic_node.png, coordinator.nps, 
> coordinator.png
>
>
> It is detected that the more machines in the cluster we have and the more 
> caches are started then the more outgoing traffic is produced by a 
> coordinator node.
> As an example in the current deployment
> - 30 nodes;
> - 67 caches;
> - caches are empty and the cluster is not used at all (idle).
> the coordinator constantly uses 300 Mbit/s of outgoing traffic. In contrast 
> each other node shows constant 10 Mbit/s usage of incoming traffic.
> Most likely the reason is that the coordinator indefinitely sends partitions 
> full map for all the caches to all the nodes. This shouldn't happen.
> Need to debug the reason of the issue and fix it.
> Attached snapshots taken from the coordinator and on of cluster's nodes. 
> Probably they would help.



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

[jira] [Created] (IGNITE-2868) IGFS: Investigate whether trash require further striping.

2016-03-21 Thread Vladimir Ozerov (JIRA) 
Vladimir Ozerov created IGNITE-2868:
---

 Summary: IGFS: Investigate whether trash require further striping.
 Key: IGNITE-2868
 URL: https://issues.apache.org/jira/browse/IGNITE-2868
 Project: Ignite
  Issue Type: Task
  Components: IGFS
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Ivan Veselovsky
 Fix For: 1.6


Currently trash is striped into 16 items. It seems that this is not enough for 
distributed environment where dozens and even hundreds threads might perform 
concurrent removes.

Let's try increasing amount of stripes and see it it helps anyhow.

The only line needs to be changes is {{IgfsUtils.TRASH_CONCURRENCY}}. Let's try 
setting it to 128 or 256.



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

[jira] [Created] (IGNITE-2867) IgniteConsistencyException during running load test (cache-atomic-invoke-retry-validator)

2016-03-21 Thread Ilya Suntsov (JIRA) 
Ilya Suntsov created IGNITE-2867:


 Summary: IgniteConsistencyException during running load test 
(cache-atomic-invoke-retry-validator)
 Key: IGNITE-2867
 URL: https://issues.apache.org/jira/browse/IGNITE-2867
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.6
 Environment: Yardstick driver's host: Ubuntu 14.04.3 LTS
Yardstick server's hosts: Ubuntu 14.04.3 LTS and CentOS release 6.7 (Final)

Yardstick configuration: 2 clients, 3 servers, PRIMARY_SYNC, 1 and 2 backups
Reporter: Ilya Suntsov
Assignee: Artem Shutak
Priority: Critical
 Fix For: 1.6
 Attachments: logs_configs_2103.zip

I've add one more client and run load test with 2 clients and 3 servers (all on 
different hosts).
Test runs for ~ 3 min and stops with exception:
{noformat}
 Got exception: 
org.apache.ignite.yardstick.cache.failover.IgniteConsistencyException: Cache 
and local map are in inconsistent state.
{noformat}

Logs and configs you can find in attachment. 



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

[jira] [Updated] (IGNITE-2867) IgniteConsistencyException during running load test (cache-atomic-invoke-retry-validator)

2016-03-21 Thread Ilya Suntsov (JIRA) 

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

Ilya Suntsov updated IGNITE-2867:
-
Attachment: logs_configs_2103.zip

> IgniteConsistencyException during running load test 
> (cache-atomic-invoke-retry-validator)
> -
>
> Key: IGNITE-2867
> URL: https://issues.apache.org/jira/browse/IGNITE-2867
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.6
> Environment: Yardstick driver's host: Ubuntu 14.04.3 LTS
> Yardstick server's hosts: Ubuntu 14.04.3 LTS and CentOS release 6.7 (Final)
> Yardstick configuration: 2 clients, 3 servers, PRIMARY_SYNC, 1 and 2 backups
>Reporter: Ilya Suntsov
>Assignee: Artem Shutak
>Priority: Critical
> Fix For: 1.6
>
> Attachments: logs_configs_2103.zip
>
>
> I've add one more client and run load test with 2 clients and 3 servers (all 
> on different hosts).
> Test runs for ~ 3 min and stops with exception:
> {noformat}
>  Got exception: 
> org.apache.ignite.yardstick.cache.failover.IgniteConsistencyException: Cache 
> and local map are in inconsistent state.
> {noformat}
> Logs and configs you can find in attachment. 



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

[jira] [Commented] (IGNITE-2686) .NET: Call Java services

2016-03-21 Thread Vladimir Ozerov (JIRA) 

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

Vladimir Ozerov commented on IGNITE-2686:
-

I think we should mark arguments passed as varargs with a kind of special flag 
(or wrapper). Otherwise it will be hard to distinguish between invalid 
arguments and varargs.
Or may be I am completely wrong and all is fine? Reflection in both Java and 
.NET should show varargs as arrays, right? Need to better understand and test 
this. 

> .NET: Call Java services
> 
>
> Key: IGNITE-2686
> URL: https://issues.apache.org/jira/browse/IGNITE-2686
> Project: Ignite
>  Issue Type: New Feature
>  Components: managed services, platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.6
>
>
> Add support for Java service calls (see OP_DOTNET_INVOKE in PlatformServices).



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

[jira] [Commented] (IGNITE-2663) ODBC: Add protocol version to protocol packet header.

2016-03-21 Thread Igor Sapego (JIRA) 

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

Igor Sapego commented on IGNITE-2663:
-

I guess, we can. I will implement discussed approach and resubmit result for 
review.

> ODBC: Add protocol version to protocol packet header.
> -
>
> Key: IGNITE-2663
> URL: https://issues.apache.org/jira/browse/IGNITE-2663
> Project: Ignite
>  Issue Type: Sub-task
>  Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.6
>
>
> Currently, there is no way for server to find out that ODBC driver uses 
> incompatible protocol version. Consider adding {{protocolVersion}} field to 
> ODBC protocol message header.



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

[jira] [Assigned] (IGNITE-2550) .NET: Simplify examples configuration

2016-03-21 Thread Pavel Tupitsyn (JIRA) 

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

Pavel Tupitsyn reassigned IGNITE-2550:
--

Assignee: Pavel Tupitsyn

> .NET: Simplify examples configuration
> -
>
> Key: IGNITE-2550
> URL: https://issues.apache.org/jira/browse/IGNITE-2550
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.6
>
>
> We now have in-code configuration (IGNITE-1906), need to demonstrate it in 
> examples, and simplify them where possible.
> 1) First, start all caches programmatically. This may reduce number of spring 
> configs.
> 2) Second, see if we can benefit from full in-code config for some of the 
> examples (compute).



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

[jira] [Commented] (IGNITE-2663) ODBC: Add protocol version to protocol packet header.

2016-03-21 Thread Igor Sapego (JIRA) 

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

Igor Sapego commented on IGNITE-2663:
-

On second thought it's not that good idea to list all the supported Apache 
Ignite versions because we may not have all information on which protocol 
version used by which Apache Ignite version. For example lets imagine that 
Apache Ignite versions 1.5, 1.6, 1.7 are all using the same protocol version. 
But if the client with unknown version will try to connect to Apache Ignite 1.6 
it would get only 1.5 and 1.6 in a list of supported versions, while 1.7 is 
also supported.

So instead I propose to respond with the following message: "Can not perform 
connection: unsupported protocol version. The last known protocol version 
supported by host released with Apache Ignite 1.6. Driver uses protocol version 
released with Apache Ignite 1.8"


> ODBC: Add protocol version to protocol packet header.
> -
>
> Key: IGNITE-2663
> URL: https://issues.apache.org/jira/browse/IGNITE-2663
> Project: Ignite
>  Issue Type: Sub-task
>  Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.6
>
>
> Currently, there is no way for server to find out that ODBC driver uses 
> incompatible protocol version. Consider adding {{protocolVersion}} field to 
> ODBC protocol message header.



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

[jira] [Comment Edited] (IGNITE-2694) .NET: AnyCPU build

2016-03-21 Thread Pavel Tupitsyn (JIRA) 

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

Pavel Tupitsyn edited comment on IGNITE-2694 at 3/21/16 12:29 PM:
--

QA info:
* There is now a single set of binaries in the distribution 
(platforms/dotnet/bin no longer has x86 folder)
* These binaries can be used both in x86 and x64 modes. Mode depends on the 
parent application platform and OS. 
** "Parent app" is the application that uses Ignite.NET binaries. Bundled 
examples are such an application.
** If the parent app is x86, or OS is x86, then Ignite runs in x86 mode
** If the parent app is x64, then Ignite runs in x64 mode
** If the parent app is AnyCPU (examples are), then the OS defines execution 
mode

=> To test examples in x86 mode, either use x86 OS, or add x86 solution 
configuration via Build->Configuration Manager menu (don't forget about proper 
JAVA_HOME).

By default, examples solution should only have AnyCPU build platform.


was (Author: ptupitsyn):
QA info:
* There is now a single set of binaries in the distribution 
(platforms/dotnet/bin no longer has x86 folder)
* These binaries can be used both in x86 and x64 modes. Mode depends on the 
parent application platform and OS. 
** "Parent app" is the application that uses Ignite.NET binaries. Bundled 
examples are such an application.
** If the parent app is x86, or OS is x86, then Ignite runs in x86 mode
** If the parent app is x64, then Ignite runs in x64 mode
** If the parent app is AnyCPU (examples are), then the OS defines execution 
mode

=> To test examples in x86 mode, either use x86 OS, or add x86 solution 
configuration via Build->Configuration Manager menu (don't forget about proper 
JAVA_HOME).

> .NET: AnyCPU build
> --
>
> Key: IGNITE-2694
> URL: https://issues.apache.org/jira/browse/IGNITE-2694
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Vasilisa  Sidorova
> Fix For: 1.6
>
>
> Currently we provide separate x86 & x64 binaries. NuGet is x64-only.
> This is inconvenient both for us and the user.
> The only thing that prevents AnyCPU is unmanaged "common" project.
> But we load it dynamically from resources, and we may as well detect current 
> process platform (x64 or not) and load a proper unmanaged resource.



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

[jira] [Closed] (IGNITE-1957) .NET: Collections, dictionaries, object arrays and tuples must use handles.

2016-03-21 Thread Vladimir Ozerov (JIRA) 

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

Vladimir Ozerov closed IGNITE-1957.
---

> .NET: Collections, dictionaries, object arrays and tuples must use handles.
> ---
>
> Key: IGNITE-1957
> URL: https://issues.apache.org/jira/browse/IGNITE-1957
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.6
>
>
> We must track handles for the following cases:
> - Collections
> - Dictionaries
> - Entries
> - Object arrays
> Reason: they may have cyclic deps on other collections what will lead to 
> infinite loops.
> This change must be tested thoroughly:
> 1) Can we get such field which is handle?
> 2) Can we resolve infinite loops with collections/maps/arrays?
> 3) Are they referential equal after deserialization?



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

[jira] [Commented] (IGNITE-1957) .NET: Collections, dictionaries, object arrays and tuples must use handles.

2016-03-21 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on IGNITE-1957:


Github user asfgit closed the pull request at:

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


> .NET: Collections, dictionaries, object arrays and tuples must use handles.
> ---
>
> Key: IGNITE-1957
> URL: https://issues.apache.org/jira/browse/IGNITE-1957
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.6
>
>
> We must track handles for the following cases:
> - Collections
> - Dictionaries
> - Entries
> - Object arrays
> Reason: they may have cyclic deps on other collections what will lead to 
> infinite loops.
> This change must be tested thoroughly:
> 1) Can we get such field which is handle?
> 2) Can we resolve infinite loops with collections/maps/arrays?
> 3) Are they referential equal after deserialization?



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

[jira] [Assigned] (IGNITE-2694) .NET: AnyCPU build

2016-03-21 Thread Vasilisa Sidorova (JIRA) 

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

Vasilisa  Sidorova reassigned IGNITE-2694:
--

Assignee: Vasilisa  Sidorova  (was: Pavel Tupitsyn)

> .NET: AnyCPU build
> --
>
> Key: IGNITE-2694
> URL: https://issues.apache.org/jira/browse/IGNITE-2694
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Vasilisa  Sidorova
> Fix For: 1.6
>
>
> Currently we provide separate x86 & x64 binaries. NuGet is x64-only.
> This is inconvenient both for us and the user.
> The only thing that prevents AnyCPU is unmanaged "common" project.
> But we load it dynamically from resources, and we may as well detect current 
> process platform (x64 or not) and load a proper unmanaged resource.



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

[jira] [Commented] (IGNITE-2694) .NET: AnyCPU build

2016-03-21 Thread Pavel Tupitsyn (JIRA) 

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

Pavel Tupitsyn commented on IGNITE-2694:


QA info:
* There is now a single set of binaries in the distribution 
(platforms/dotnet/bin no longer has x86 folder)
* These binaries can be used both in x86 and x64 modes. Mode depends on the 
parent application platform and OS. 
** "Parent app" is the application that uses Ignite.NET binaries. Bundled 
examples are such an application.
** If the parent app is x86, or OS is x86, then Ignite runs in x86 mode
** If the parent app is x64, then Ignite runs in x64 mode
** If the parent app is AnyCPU (examples are), then the OS defines execution 
mode

=> To test examples in x86 mode, either use x86 OS, or add x86 solution 
configuration via Build->Configuration Manager menu (don't forget about proper 
JAVA_HOME).

> .NET: AnyCPU build
> --
>
> Key: IGNITE-2694
> URL: https://issues.apache.org/jira/browse/IGNITE-2694
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.6
>
>
> Currently we provide separate x86 & x64 binaries. NuGet is x64-only.
> This is inconvenient both for us and the user.
> The only thing that prevents AnyCPU is unmanaged "common" project.
> But we load it dynamically from resources, and we may as well detect current 
> process platform (x64 or not) and load a proper unmanaged resource.



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

[jira] [Created] (IGNITE-2866) .NET: Automatic JAVA_HOME detection

2016-03-21 Thread Pavel Tupitsyn (JIRA) 
Pavel Tupitsyn created IGNITE-2866:
--

 Summary: .NET: Automatic JAVA_HOME detection
 Key: IGNITE-2866
 URL: https://issues.apache.org/jira/browse/IGNITE-2866
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 1.1.4
Reporter: Pavel Tupitsyn
 Fix For: 1.6


If JAVA_HOME env var and IgniteConfiguration.JavaHome property are not set, we 
can attempt automatic detection.

For Oracle JVM there is information in the registry at 
{code}HKEY_LOCAL_MACHINE\Software\JavaSoft{code}



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

[jira] [Commented] (IGNITE-2663) ODBC: Add protocol version to protocol packet header.

2016-03-21 Thread Igor Sapego (JIRA) 

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

Igor Sapego commented on IGNITE-2663:
-

Vladimir,

I was thinking about the several versions support issue as well and my thoughts 
about this issue are pretty much the same. Thats why I have not included 
expected version in the response message.

If we want to have more informational user error message we can make something 
like that:

- Server (node) stores all the supported version of the protocol and associated 
list of the Apache Ignite versions.
- Client stores only it's own protocol version and Apache Ignite version.
- Resulting error message looks like this: "Can not perform connection: 
unsupported protocol version. Supported versions: [1, 2, ...], corresponding 
Apache Ignite versions: [1.6, ...], driver uses protocol version X and is part 
of Apache Ignite X.X".


> ODBC: Add protocol version to protocol packet header.
> -
>
> Key: IGNITE-2663
> URL: https://issues.apache.org/jira/browse/IGNITE-2663
> Project: Ignite
>  Issue Type: Sub-task
>  Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.6
>
>
> Currently, there is no way for server to find out that ODBC driver uses 
> incompatible protocol version. Consider adding {{protocolVersion}} field to 
> ODBC protocol message header.



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

[jira] [Commented] (IGNITE-813) Apache Flink Integration -- data streaming connector

2016-03-21 Thread Roman Shtykh (JIRA) 

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

Roman Shtykh commented on IGNITE-813:
-

Saikat,

Please see my comments on github.
Also please increase the number of events you are streaming in the tests to, 
say, 1, and see what happens ;) You'll have to use the event listener and 
make sure the events are delivered to the cache. Please refer other Ignite 
streamers.

[~rmetzger] Thanks for your comments!

> Apache Flink Integration -- data streaming connector
> 
>
> Key: IGNITE-813
> URL: https://issues.apache.org/jira/browse/IGNITE-813
> Project: Ignite
>  Issue Type: New Feature
>  Components: streaming
>Reporter: Suminda Dharmasena
>Assignee: Saikat Maitra
>




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

[jira] [Created] (IGNITE-2865) Continuous query event passed to filter should be immutable for users.

2016-03-21 Thread Vladimir Ozerov (JIRA) 
Vladimir Ozerov created IGNITE-2865:
---

 Summary: Continuous query event passed to filter should be 
immutable for users.
 Key: IGNITE-2865
 URL: https://issues.apache.org/jira/browse/IGNITE-2865
 Project: Ignite
  Issue Type: Task
  Components: cache
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Priority: Critical
 Fix For: 1.6


*Problem*
When event is passed to continuous query filter, it can be used only in scope 
of this method. The reason is that if filter returns {{false}}, the method 
{{CacheContinuousQueryEntry.markFiltered()}} is called. This method *clears* 
key and values.

*Solution*
We should not clear key and values. Instead, we should properly check for 
{{FILTERED_ENTRY}} flag in all methods where {{key/newVal/oldVal/depInfo}} are 
used. This includes generated {{readFrom()/writeTo()}} methods as well - their 
manual change will be required.



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

[jira] [Comment Edited] (IGNITE-2801) Coordinator floods network with partitions full map exchange messages

2016-03-21 Thread Anton Vinogradov (JIRA) 

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

Anton Vinogradov edited comment on IGNITE-2801 at 3/21/16 9:28 AM:
---

Reproduced. 

Started 10 nodes with 35 caches. 
Gained 37 MB of GridDhtPartitionsFullMessage per minute -> 49 Mb/s
Rough multiplication to 30 nodes & 65 caches (x6) gives exactly 300Mb/s 


was (Author: avinogradov):
Reproduced. 

Started 10 nodes with 35 caches. 
Gained 37 MB of GridDhtPartitionsFullMessage per minute -> 49 Mb/s
Rrough multiplication to 30 nodes & 65 caches (x6) gives exactly 300Mb/s 

> Coordinator floods network with partitions full map exchange messages
> -
>
> Key: IGNITE-2801
> URL: https://issues.apache.org/jira/browse/IGNITE-2801
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Anton Vinogradov
>Priority: Critical
>  Labels: community, important
> Fix For: 1.6
>
> Attachments: basic_node.nps, basic_node.png, coordinator.nps, 
> coordinator.png
>
>
> It is detected that the more machines in the cluster we have and the more 
> caches are started then the more outgoing traffic is produced by a 
> coordinator node.
> As an example in the current deployment
> - 30 nodes;
> - 67 caches;
> - caches are empty and the cluster is not used at all (idle).
> the coordinator constantly uses 300 Mbit/s of outgoing traffic. In contrast 
> each other node shows constant 10 Mbit/s usage of incoming traffic.
> Most likely the reason is that the coordinator indefinitely sends partitions 
> full map for all the caches to all the nodes. This shouldn't happen.
> Need to debug the reason of the issue and fix it.
> Attached snapshots taken from the coordinator and on of cluster's nodes. 
> Probably they would help.



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

[jira] [Updated] (IGNITE-2791) Continuous query listener is not notified during concurrent key put.

2016-03-21 Thread Vladimir Ozerov (JIRA) 

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

Vladimir Ozerov updated IGNITE-2791:

Labels: important  (was: )

> Continuous query listener is not notified during concurrent key put.
> 
>
> Key: IGNITE-2791
> URL: https://issues.apache.org/jira/browse/IGNITE-2791
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Nikolay Tikhonov
>Priority: Critical
>  Labels: important
> Fix For: 1.6
>
> Attachments: CacheListenersKillingMe3Main.java
>
>
> Attached the code reproducing the problem. What is evident from the log, is 
> that that filter was invoked, but the listener was not.



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

[jira] [Updated] (IGNITE-2844) .NET: ICache.LoadAll method is missing

2016-03-21 Thread Vladimir Ozerov (JIRA) 

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

Vladimir Ozerov updated IGNITE-2844:

Affects Version/s: (was: 1.6)
   1.5.0.final

> .NET: ICache.LoadAll method is missing
> --
>
> Key: IGNITE-2844
> URL: https://issues.apache.org/jira/browse/IGNITE-2844
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Blocker
> Fix For: 1.6
>
>
> See IgniteCache.loadAll, need the same in .NET.



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

[jira] [Commented] (IGNITE-1433) .Net: Add IgniteException.JavaStackTrace

2016-03-21 Thread Vladimir Ozerov (JIRA) 

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

Vladimir Ozerov commented on IGNITE-1433:
-

Ok, we agree that current implementation cannot go further. So there is no 
reason for "Patch Available". Also I moving it to 1.7.

> .Net: Add IgniteException.JavaStackTrace
> 
>
> Key: IGNITE-1433
> URL: https://issues.apache.org/jira/browse/IGNITE-1433
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>
> Propagate java stack trace as a string in ExceptionUtils.GetException and 
> write it to a new field in IgniteException class.
> This will simplify debugging for us both locally and when getting error 
> reports from clients.



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

[jira] [Updated] (IGNITE-1433) .Net: Add IgniteException.JavaStackTrace

2016-03-21 Thread Vladimir Ozerov (JIRA) 

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

Vladimir Ozerov updated IGNITE-1433:

Fix Version/s: (was: 1.6)
   1.7

> .Net: Add IgniteException.JavaStackTrace
> 
>
> Key: IGNITE-1433
> URL: https://issues.apache.org/jira/browse/IGNITE-1433
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>
> Propagate java stack trace as a string in ExceptionUtils.GetException and 
> write it to a new field in IgniteException class.
> This will simplify debugging for us both locally and when getting error 
> reports from clients.



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

[jira] [Created] (IGNITE-2864) Need update local store from primary and backups

2016-03-21 Thread Semen Boikov (JIRA) 
Semen Boikov created IGNITE-2864:


 Summary: Need update local store from primary and backups
 Key: IGNITE-2864
 URL: https://issues.apache.org/jira/browse/IGNITE-2864
 Project: Ignite
  Issue Type: Bug
  Components: cache
Reporter: Semen Boikov
Assignee: Anton Vinogradov
 Fix For: 1.6


Now cache local store is updated only from primary nodes, this means that data 
can be lost if primary node is not re-started after crash. Need fix it and 
update store from primaries and backups if store is local (for both tx and 
atomic caches).

This test should work:
- cache with 1 backup, two server nodes
- execute cache put for key K
- stop both nodes
- restart only node which was backup for K
- load data from local sore, update for K should be restored




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

[jira] [Closed] (IGNITE-2747) ODBC: Time cast returns wrong results for Linux.

2016-03-21 Thread Vladimir Ozerov (JIRA) 

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

Vladimir Ozerov closed IGNITE-2747.
---

> ODBC: Time cast returns wrong results for Linux.
> 
>
> Key: IGNITE-2747
> URL: https://issues.apache.org/jira/browse/IGNITE-2747
> Project: Ignite
>  Issue Type: Sub-task
>  Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.6
>
>
> Current time cast does not work for Linux because {{timezone}} variable does 
> not return right time offset for Linux.
> Also, {{gmtime}} is not thread-safe so it seems that we should use some 
> platform-specific functions for time-conversion operations.



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

[jira] [Updated] (IGNITE-2806) IGFS: re-create lock relaxed version

2016-03-21 Thread Vladimir Ozerov (JIRA) 

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

Vladimir Ozerov updated IGNITE-2806:

Priority: Critical  (was: Major)

> IGFS: re-create lock relaxed version
> 
>
> Key: IGNITE-2806
> URL: https://issues.apache.org/jira/browse/IGNITE-2806
> Project: Ignite
>  Issue Type: Bug
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
>Priority: Critical
> Fix For: 1.6
>
>
> Earlier we had IGFS implementation that seemed to be fast, but was not 
> absolutely correct in terms of synchronization logic. As now we suspect some 
> problems with IGFS performance, we need to create such version of the 
> implementation again.



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

[jira] [Closed] (IGNITE-2836) IGFS: Investigate why BinaryMarshaller is slower than OptimizedMarshaller in meta operations.

2016-03-21 Thread Vladimir Ozerov (JIRA) 

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

Vladimir Ozerov closed IGNITE-2836.
---

> IGFS: Investigate why BinaryMarshaller is slower than OptimizedMarshaller in 
> meta operations.
> -
>
> Key: IGNITE-2836
> URL: https://issues.apache.org/jira/browse/IGNITE-2836
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> *Problem*
> Running complex Hadoop tasks with default node settings typically shows worse 
> performance than with explicitly set {{OptimziedMarshaller}}. Most probably 
> it is caused by the fact that all our IGFS meta classes are Externalizable 
> and hence cannot be handled by {{BinaryMarshaller}} out-of-the box.
> *Solution*
> 1) Add all participating IGFS classes (IgniteUuid, IgfsFileInfo, 
> IgfsBlockKey, IgfsListingEntry + all processors) to exclusions in static 
> initializer of {{BinaryContext}}.
> 2) Mark all these classes as {{Binarylizable}} and implement writes/reads in 
> raw mode.
> Then check performance.



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

[jira] [Resolved] (IGNITE-2836) IGFS: Investigate why BinaryMarshaller is slower than OptimizedMarshaller in meta operations.

2016-03-21 Thread Vladimir Ozerov (JIRA) 

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

Vladimir Ozerov resolved IGNITE-2836.
-
Resolution: Fixed

> IGFS: Investigate why BinaryMarshaller is slower than OptimizedMarshaller in 
> meta operations.
> -
>
> Key: IGNITE-2836
> URL: https://issues.apache.org/jira/browse/IGNITE-2836
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> *Problem*
> Running complex Hadoop tasks with default node settings typically shows worse 
> performance than with explicitly set {{OptimziedMarshaller}}. Most probably 
> it is caused by the fact that all our IGFS meta classes are Externalizable 
> and hence cannot be handled by {{BinaryMarshaller}} out-of-the box.
> *Solution*
> 1) Add all participating IGFS classes (IgniteUuid, IgfsFileInfo, 
> IgfsBlockKey, IgfsListingEntry + all processors) to exclusions in static 
> initializer of {{BinaryContext}}.
> 2) Mark all these classes as {{Binarylizable}} and implement writes/reads in 
> raw mode.
> Then check performance.



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

[jira] [Assigned] (IGNITE-2836) IGFS: Investigate why BinaryMarshaller is slower than OptimizedMarshaller in meta operations.

2016-03-21 Thread Vladimir Ozerov (JIRA) 

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

Vladimir Ozerov reassigned IGNITE-2836:
---

Assignee: Vladimir Ozerov

> IGFS: Investigate why BinaryMarshaller is slower than OptimizedMarshaller in 
> meta operations.
> -
>
> Key: IGNITE-2836
> URL: https://issues.apache.org/jira/browse/IGNITE-2836
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> *Problem*
> Running complex Hadoop tasks with default node settings typically shows worse 
> performance than with explicitly set {{OptimziedMarshaller}}. Most probably 
> it is caused by the fact that all our IGFS meta classes are Externalizable 
> and hence cannot be handled by {{BinaryMarshaller}} out-of-the box.
> *Solution*
> 1) Add all participating IGFS classes (IgniteUuid, IgfsFileInfo, 
> IgfsBlockKey, IgfsListingEntry + all processors) to exclusions in static 
> initializer of {{BinaryContext}}.
> 2) Mark all these classes as {{Binarylizable}} and implement writes/reads in 
> raw mode.
> Then check performance.



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