[jira] [Issue Comment Deleted] (IGNITE-3356) Browser incorrectly save user password.

[Maxim Afanasiev (JIRA)]

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

Maxim Afanasiev updated IGNITE-3356:

Comment: was deleted

(was: Fixed. Please test.)

> Browser incorrectly save user password.
> ---
>
> Key: IGNITE-3356
> URL: https://issues.apache.org/jira/browse/IGNITE-3356
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.6
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
> Fix For: 1.7
>
>
> On sign in page and on profile page browser orders to save password to 
> incorrect user name (Input company name).
> Reproduced on Chrome browser.



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

[jira] [Resolved] (IGNITE-3356) Browser incorrectly save user password.

[Maxim Afanasiev (JIRA)]

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

Maxim Afanasiev resolved IGNITE-3356.
-
Resolution: Fixed

Fixed. Please test.

> Browser incorrectly save user password.
> ---
>
> Key: IGNITE-3356
> URL: https://issues.apache.org/jira/browse/IGNITE-3356
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.6
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
> Fix For: 1.7
>
>
> On sign in page and on profile page browser orders to save password to 
> incorrect user name (Input company name).
> Reproduced on Chrome browser.



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

[jira] [Assigned] (IGNITE-3356) Browser incorrectly save user password.

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-3356:


Assignee: Vasiliy Sisko  (was: Maxim Afanasiev)

Fixed. Please test.

> Browser incorrectly save user password.
> ---
>
> Key: IGNITE-3356
> URL: https://issues.apache.org/jira/browse/IGNITE-3356
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.6
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
> Fix For: 1.7
>
>
> On sign in page and on profile page browser orders to save password to 
> incorrect user name (Input company name).
> Reproduced on Chrome browser.



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

[jira] [Commented] (IGNITE-3227) IgniteCache: add method to calculate size per partition

[Saikat Maitra (JIRA)]

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

Saikat Maitra commented on IGNITE-3227:
---

[~ilantukh]

Thank you Ilya. I have modified the implementation.

Regards
Saikat

> IgniteCache: add method to calculate size per partition
> ---
>
> Key: IGNITE-3227
> URL: https://issues.apache.org/jira/browse/IGNITE-3227
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Denis Magda
>Assignee: Saikat Maitra
>  Labels: community, important
>
> It makes sense to add size calculation per partition. Actually the following 
> methods should be added to the {{IgniteCache}} API.
> {code}
> public int size(int partition, CachePeekMode... peekModes) throws 
> CacheException;
> public int localSize(int partition, CachePeekMode... peekModes);
> {code}



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

[jira] [Commented] (IGNITE-3355) CPP: Implement Compute::Call() for C++ client.

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-3355:
-

We need to implement Futures to be able to execute Compute jobs.

> CPP: Implement Compute::Call() for C++ client.
> --
>
> Key: IGNITE-3355
> URL: https://issues.apache.org/jira/browse/IGNITE-3355
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.7
>
>
> Need to implement {{Compute}} class with {{Compute::Call}} method.



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

[jira] [Updated] (IGNITE-1466) CPP: Implement binary objects support.

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-1466:

Description: We need to support portable objects in the same way as it is 
done in .Net and Java: if some flag ({{keepBinary}}) is set, then we should 
return not real object, but rather a wrapper around it.  (was: We need to 
support portable objects in the same way as it is done in .Net and Java: if 
some flag ("keepPortable") is set, then we should return not real object, but 
rather a wrapper around it.)

> CPP: Implement binary objects support.
> --
>
> Key: IGNITE-1466
> URL: https://issues.apache.org/jira/browse/IGNITE-1466
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Priority: Critical
>
> We need to support portable objects in the same way as it is done in .Net and 
> Java: if some flag ({{keepBinary}}) is set, then we should return not real 
> object, but rather a wrapper around it.



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

[jira] [Updated] (IGNITE-1466) CPP: Implement binary objects support.

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-1466:

Summary: CPP: Implement binary objects support.  (was: CPP: Implement 
portable objects support.)

> CPP: Implement binary objects support.
> --
>
> Key: IGNITE-1466
> URL: https://issues.apache.org/jira/browse/IGNITE-1466
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Priority: Critical
>
> We need to support portable objects in the same way as it is done in .Net and 
> Java: if some flag ("keepPortable") is set, then we should return not real 
> object, but rather a wrapper around it.



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

[jira] [Commented] (IGNITE-1445) CPP: Implement cache invoke.

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-1445:
-

Resolved by IGNITE-3330.

> CPP: Implement cache invoke.
> 
>
> Key: IGNITE-1445
> URL: https://issues.apache.org/jira/browse/IGNITE-1445
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.7
>
>
> This will require well-defined architecture for generic callback calls from 
> Java core to CPP.



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

[jira] [Resolved] (IGNITE-1445) CPP: Implement cache invoke.

[Igor Sapego (JIRA)]

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

Igor Sapego resolved IGNITE-1445.
-
   Resolution: Duplicate
 Assignee: Vladimir Ozerov
Fix Version/s: 1.7

> CPP: Implement cache invoke.
> 
>
> Key: IGNITE-1445
> URL: https://issues.apache.org/jira/browse/IGNITE-1445
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.7
>
>
> This will require well-defined architecture for generic callback calls from 
> Java core to CPP.



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

[jira] [Commented] (IGNITE-2680) Terminating running SQL queries

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov commented on IGNITE-2680:
---

1, 3 fixed.

> Terminating running SQL queries
> ---
>
> Key: IGNITE-2680
> URL: https://issues.apache.org/jira/browse/IGNITE-2680
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Alexei Scherbakov
>  Labels: important
>
> If to start a long running SQL query over a huge cache will millions of 
> entries there should be a way terminate it. Even if {{QueryCursor}} is closed 
> the query won't be cancelled consuming available resources.
> There should be a way to close a query having using an object that is related 
> to it. Seems that ideally we can use {{QueryCursor.close()}} method for that;



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

[jira] [Commented] (IGNITE-3185) Hadoop: Improve Hadoop JAR search logic.

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky commented on IGNITE-3185:
-

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

> Hadoop: Improve Hadoop JAR search logic.
> 
>
> Key: IGNITE-3185
> URL: https://issues.apache.org/jira/browse/IGNITE-3185
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Ivan Veselovsky
> Fix For: 1.7
>
>
> *Problem*
> Currently our {{HadoopClassLoader}} is trying to find common/hdfs/mapred JARs 
> automatically if {{HADOOP_HOME}} is set. However, it checks only for standard 
> Apache Hadoop distribution paths (/share/hadoop/*). For other distributions 
> (CDH, HDP), user has to bother with additional env variables manually.
> *Solution*
> Try to search for the following folders as well:
> $HADOOP_HOME/hadoop
> $HADOOP_HOME/hadoop-hdfs
> $HADOOP_HOME/hadoop-mapreduce
> If all these folders are found, then this is either HDP or CDH deployment and 
> we can create the classpath without additional env vars.



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

[jira] [Closed] (IGNITE-1223) Use Gson instead of net.sf.json-lib:json-lib:2.4

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov closed IGNITE-1223.


> Use Gson instead of net.sf.json-lib:json-lib:2.4
> 
>
> Key: IGNITE-1223
> URL: https://issues.apache.org/jira/browse/IGNITE-1223
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Sergey Evdokimov
> Fix For: 1.7
>
> Attachments: master_ae11e9b_ignite-1223.patch
>
>
> Gson faster then "net.sf.json-lib:json-lib:2.4" 4 times. (Serialization of 
> GridRestCommand#NODE responce 2 times take 1,45 seconds with Gson and 5,8 
> seconds with json-lib. Also json-lib cannot work with gridgain-style getters 
> and setters.



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

[jira] [Comment Edited] (IGNITE-3227) IgniteCache: add method to calculate size per partition

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh edited comment on IGNITE-3227 at 6/27/16 3:03 PM:
---

Hi Saikat,

I don't think that implementation of GridCacheAdapter#localSizeLong(int 
partition, CachePeekMode[] peekModes) is correct. Currently it will count all 
local entries, even from other partitions.
To obtain partition size, you should use GridDhtLocalPartition#publicSize() 
method. It also has methods to check whether partition is primary or backup for 
a given topology version. An instance of GridDhtLocalPartition can be accessed 
from GridCacheAdapter by calling {code}ctx.topology().localPartition(int p, 
AffinityTopologyVersion topVer, boolean create){code}.
To count entries in swap and offheap, methods 
GridCacheSwapManager#swapEntriesCount(int partId) and 
GridCacheSwapManager#offheapEntriesCount(int partId) should be used, 
respectively.


was (Author: ilantukh):
Hi [~saikatr],

I don't think that implementation of GridCacheAdapter#localSizeLong(int 
partition, CachePeekMode[] peekModes) is correct. Currently it will count all 
local entries, even from other partitions.
To obtain partition size, you should use GridDhtLocalPartition#publicSize() 
method. It also has methods to check whether partition is primary or backup for 
a given topology version. An instance of GridDhtLocalPartition can be accessed 
from GridCacheAdapter by calling {code}ctx.topology().localPartition(int p, 
AffinityTopologyVersion topVer, boolean create){code}.
To count entries in swap and offheap, methods 
GridCacheSwapManager#swapEntriesCount(int partId) and 
GridCacheSwapManager#offheapEntriesCount(int partId) should be used, 
respectively.

> IgniteCache: add method to calculate size per partition
> ---
>
> Key: IGNITE-3227
> URL: https://issues.apache.org/jira/browse/IGNITE-3227
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Denis Magda
>Assignee: Saikat Maitra
>  Labels: community, important
>
> It makes sense to add size calculation per partition. Actually the following 
> methods should be added to the {{IgniteCache}} API.
> {code}
> public int size(int partition, CachePeekMode... peekModes) throws 
> CacheException;
> public int localSize(int partition, CachePeekMode... peekModes);
> {code}



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

[jira] [Commented] (IGNITE-3227) IgniteCache: add method to calculate size per partition

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh commented on IGNITE-3227:
--

Hi [~samaitra],

I have a few comments regarding GridCacheAdapter#localSizeLong(int partition, 
CachePeekMode[] peekModes) implementation:

1. When you obtain an instance of GridDhtLocalPartition:
{code}GridDhtLocalPartition gridDthLocalPartition = 
ctx.topology().localPartition(partition, topVer, true);{code}
I think it's better to set create flag (last parameter) to false, and in case 
it returns null assume that publicSize() == 0.

2. When you check partition for being primary or backup:
{code}if (modes.primary && gridDthLocalPartition.primary(topVer)) {
size += gridDthLocalPartition.publicSize();
}
if (modes.backup && gridDthLocalPartition.backup(topVer)) {
size += gridDthLocalPartition.publicSize();
}{code}
These conditions are mutually exclusive. Please use "else if".

> IgniteCache: add method to calculate size per partition
> ---
>
> Key: IGNITE-3227
> URL: https://issues.apache.org/jira/browse/IGNITE-3227
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Denis Magda
>Assignee: Saikat Maitra
>  Labels: community, important
>
> It makes sense to add size calculation per partition. Actually the following 
> methods should be added to the {{IgniteCache}} API.
> {code}
> public int size(int partition, CachePeekMode... peekModes) throws 
> CacheException;
> public int localSize(int partition, CachePeekMode... peekModes);
> {code}



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

[jira] [Commented] (IGNITE-1525) Return value for cache operation can be lost with onePhaseCommit

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-1525:
--

Discussed with Nick.
My scenario should be fixed to send {{GridNearTxPreparePreliminaryResponse}} 
from Backup node to guarantee Client will receive this message in case Primary 
fail.
But anyway found that Alexey's case is better. Because at regular scenario 
result will be resend only once instead of couple resends in my case.

> Return value for cache operation can be lost with onePhaseCommit
> 
>
> Key: IGNITE-1525
> URL: https://issues.apache.org/jira/browse/IGNITE-1525
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Semen Boikov
>Assignee: Anton Vinogradov
>Priority: Blocker
> Fix For: 1.7
>
>
> Looks like with {{onePhaseCommit}} return value for cache operation can be 
> lost if primary node fails, {{GridNearTxPrepareResponse}} with return value 
> is not received, but transaction executes 'check backup' step and finishes 
> without error.
> Reproduces in {{IgniteCachePutRetryTransactionalSelfTest.testInvoke}}, also 
> added one more test to check return value 
> {{IgniteCachePutRetryTransactionalSelfTest.testGetAndPut}}.
> Please unmute tests on TC when fixed.



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

[jira] [Commented] (IGNITE-3363) Forward Java output to the .NET console

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3363:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-3363 Forward Java output to the .NET console



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

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

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

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


commit 575b06f966a3962e32ff67b3d7a29e442428a3c7
Author: Pavel Tupitsyn 
Date:   2016-06-27T12:53:46Z

IGNITE-3363 Forward Java output to the .NET console

commit 9aee7208193a0cc35730a9722f977d29a307b0ae
Author: Pavel Tupitsyn 
Date:   2016-06-27T13:27:40Z

Java part done

commit 5839f7602e4ff6a90578721b6f32d55e1ee64cdd
Author: Pavel Tupitsyn 
Date:   2016-06-27T13:47:17Z

wip cpp

commit 92f48771af0bc4d84d0bbae68c6c657cb207ae7a
Author: Pavel Tupitsyn 
Date:   2016-06-27T13:56:03Z

wip

commit 9b09892c2a5d5f7a9094e94342d87688613b579b
Author: Pavel Tupitsyn 
Date:   2016-06-27T14:17:04Z

wip

commit ef3e450d71bb4e18835aa4b8e2ea8597defff7c2
Author: Pavel Tupitsyn 
Date:   2016-06-27T14:28:54Z

wip

commit 699529f3c18489af504fbdfa027e831e3e5f4872
Author: Pavel Tupitsyn 
Date:   2016-06-27T14:35:24Z

CPP done

commit d919503cb8cf6a7b6b0ef0cd73e348ef863c3314
Author: Pavel Tupitsyn 
Date:   2016-06-27T14:49:48Z

InitConsole done

commit f9a33faf8090ad9c5fe03f8b723304e29b34c9ee
Author: Pavel Tupitsyn 
Date:   2016-06-27T14:52:36Z

It works!




> Forward Java output to the .NET console
> ---
>
> Key: IGNITE-3363
> URL: https://issues.apache.org/jira/browse/IGNITE-3363
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.7
>
>
> Java console output is not visible in .NET tools (unit test runners, linqpad, 
> etc).
> On JVM start we should redirect all output via 
> java.lang.System.setOut()
> java.lang.System.setErr()



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

[jira] [Updated] (IGNITE-3373) Distributed IgniteSet shows size() == 0 for any new node

[Andrey Velichko (JIRA)]

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

Andrey Velichko updated IGNITE-3373:

Description: For distributed IgniteSet new node shows incorrdet size 
igniteSet.size() == 0, but igniteSet.contains(42L) == true  (was: For 
distributed IgniteSet new node shows incorrdet set size igniteSet.size() == 0)

> Distributed IgniteSet shows size() == 0 for any new node
> 
>
> Key: IGNITE-3373
> URL: https://issues.apache.org/jira/browse/IGNITE-3373
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey Velichko
> Attachments: DistributedSetDemo.java
>
>
> For distributed IgniteSet new node shows incorrdet size igniteSet.size() == 
> 0, but igniteSet.contains(42L) == true



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

[jira] [Updated] (IGNITE-3373) Distributed IgniteSet shows size() == 0 for any new node

[Andrey Velichko (JIRA)]

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

Andrey Velichko updated IGNITE-3373:

Description: For distributed IgniteSet new node shows incorrdet set size 
igniteSet.size() == 0  (was: For distributed IgniteSet new node shows incorrdet 
set size
igniteSet.size() == 0

CollectionConfiguration collectionConfiguration = new 
CollectionConfiguration();
collectionConfiguration.setCollocated(true); 

IgniteSet numbers = ignite.set("numbers", null);
if (numbers == null) {
System.out.println("[local] creating collection [numbers]");
numbers = ignite.set("numbers", collectionConfiguration);
}

boolean cont = numbers.contains(42L);   // true - OK
int num = numbers.size();   // 0 Error ???
System.out.println("size=" + num + ", contains=" + cont);

numbers.forEach(val -> {
System.out.println(val); // Iterator is not iterate :(
});

numbers.add(42L);
Thread.sleep(1000 * 6000);)

> Distributed IgniteSet shows size() == 0 for any new node
> 
>
> Key: IGNITE-3373
> URL: https://issues.apache.org/jira/browse/IGNITE-3373
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey Velichko
> Attachments: DistributedSetDemo.java
>
>
> For distributed IgniteSet new node shows incorrdet set size igniteSet.size() 
> == 0



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

[jira] [Comment Edited] (IGNITE-3373) Distributed IgniteSet shows size() == 0 for any new node

[Andrey Velichko (JIRA)]

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

Andrey Velichko edited comment on IGNITE-3373 at 6/27/16 2:09 PM:
--

1 Run first instance

[17:06:52] Topology snapshot [ver=1, servers=1, clients=0, CPUs=8, heap=3.5GB]
Started node fff3de00-bf3b-4555-a22a-a7310c0f3a79
[local] creating collection [numbers]
[local] size=0, contains=false
[local] Size of the numbers distributed set is 0, and items are []
[local] Is collocated? true
[local] numbers contains 42? false
[affinity] Running on fff3de00-bf3b-4555-a22a-a7310c0f3a79 node
[affinity] Size of the numbers distributed set is 0, and items are []
[affinity] Is collocated? true
[affinity] numbers contains 42? false

2 Run second instance, size at line 3 incorrect

[17:07:38] Topology snapshot [ver=2, servers=2, clients=0, CPUs=8, heap=7.1GB]
Started node 287b112b-c06b-4e46-bf5d-04f4d5616734
[local] size=0, contains=true   ---> ERROR
[local] Size of the numbers distributed set is 0, and items are []
[local] Is collocated? true
[local] numbers contains 42? true

See details  
http://apache-ignite-users.70518.x6.nabble.com/Strange-collocated-distributed-set-behavior-td5643.html


was (Author: andreyvel):
Need run2 instances. Second instance shows size==0.

> Distributed IgniteSet shows size() == 0 for any new node
> 
>
> Key: IGNITE-3373
> URL: https://issues.apache.org/jira/browse/IGNITE-3373
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey Velichko
> Attachments: DistributedSetDemo.java
>
>
> For distributed IgniteSet new node shows incorrdet set size
> igniteSet.size() == 0
> CollectionConfiguration collectionConfiguration = new 
> CollectionConfiguration();
> collectionConfiguration.setCollocated(true); 
> IgniteSet numbers = ignite.set("numbers", null);
> if (numbers == null) {
> System.out.println("[local] creating collection [numbers]");
> numbers = ignite.set("numbers", collectionConfiguration);
> }
> boolean cont = numbers.contains(42L); // true - OK
> int num = numbers.size(); // 0 Error ???
> System.out.println("size=" + num + ", contains=" + cont);
> numbers.forEach(val -> {
> System.out.println(val); // Iterator is not iterate :(
> });
>   numbers.add(42L);
>   Thread.sleep(1000 * 6000);



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

[jira] [Updated] (IGNITE-3373) Distributed IgniteSet shows size() == 0 for any new node

[Andrey Velichko (JIRA)]

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

Andrey Velichko updated IGNITE-3373:

Attachment: DistributedSetDemo.java

Need run2 instances. Second instance shows size==0.

> Distributed IgniteSet shows size() == 0 for any new node
> 
>
> Key: IGNITE-3373
> URL: https://issues.apache.org/jira/browse/IGNITE-3373
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey Velichko
> Attachments: DistributedSetDemo.java
>
>
> For distributed IgniteSet new node shows incorrdet set size
> igniteSet.size() == 0
> CollectionConfiguration collectionConfiguration = new 
> CollectionConfiguration();
> collectionConfiguration.setCollocated(true); 
> IgniteSet numbers = ignite.set("numbers", null);
> if (numbers == null) {
> System.out.println("[local] creating collection [numbers]");
> numbers = ignite.set("numbers", collectionConfiguration);
> }
> boolean cont = numbers.contains(42L); // true - OK
> int num = numbers.size(); // 0 Error ???
> System.out.println("size=" + num + ", contains=" + cont);
> numbers.forEach(val -> {
> System.out.println(val); // Iterator is not iterate :(
> });
>   numbers.add(42L);
>   Thread.sleep(1000 * 6000);



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

[jira] [Updated] (IGNITE-3373) Distributed IgniteSet shows size() == 0 for any new node

[Andrey Velichko (JIRA)]

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

Andrey Velichko updated IGNITE-3373:

Description: 
For distributed IgniteSet new node shows incorrdet set size
igniteSet.size() == 0

CollectionConfiguration collectionConfiguration = new 
CollectionConfiguration();
collectionConfiguration.setCollocated(true); 

IgniteSet numbers = ignite.set("numbers", null);
if (numbers == null) {
System.out.println("[local] creating collection [numbers]");
numbers = ignite.set("numbers", collectionConfiguration);
}

boolean cont = numbers.contains(42L);   // true - OK
int num = numbers.size();   // 0 Error ???
System.out.println("size=" + num + ", contains=" + cont);

numbers.forEach(val -> {
System.out.println(val); // Iterator is not iterate :(
});

numbers.add(42L);
Thread.sleep(1000 * 6000);

  was:
For distributed IgniteSet new node shows incorrdet set size
igniteSet.size() == 0 shows 0, 

CollectionConfiguration collectionConfiguration = new 
CollectionConfiguration();
collectionConfiguration.setCollocated(true); 

IgniteSet numbers = ignite.set("numbers", null);
if (numbers == null) {

System.out.println("[local] creating collection [numbers]");
numbers = ignite.set("numbers", collectionConfiguration);

}

boolean cont = numbers.contains(42L);   // true - OK
int num = numbers.size();   // 0 Error ???
System.out.println("size=" + num + ", contains=" + cont);

numbers.forEach(val -> {
System.out.println(val); // Iterator is not iterate :(
});

numbers.add(42L);
Thread.sleep(1000 * 6000);


> Distributed IgniteSet shows size() == 0 for any new node
> 
>
> Key: IGNITE-3373
> URL: https://issues.apache.org/jira/browse/IGNITE-3373
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey Velichko
>
> For distributed IgniteSet new node shows incorrdet set size
> igniteSet.size() == 0
> CollectionConfiguration collectionConfiguration = new 
> CollectionConfiguration();
> collectionConfiguration.setCollocated(true); 
> IgniteSet numbers = ignite.set("numbers", null);
> if (numbers == null) {
> System.out.println("[local] creating collection [numbers]");
> numbers = ignite.set("numbers", collectionConfiguration);
> }
> boolean cont = numbers.contains(42L); // true - OK
> int num = numbers.size(); // 0 Error ???
> System.out.println("size=" + num + ", contains=" + cont);
> numbers.forEach(val -> {
> System.out.println(val); // Iterator is not iterate :(
> });
>   numbers.add(42L);
>   Thread.sleep(1000 * 6000);



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

[jira] [Updated] (IGNITE-3373) Distributed IgniteSet shows size() == 0 for any new node

[Andrey Velichko (JIRA)]

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

Andrey Velichko updated IGNITE-3373:

Description: 
For distributed IgniteSet new node shows incorrdet set size
igniteSet.size() == 0 shows 0, 

CollectionConfiguration collectionConfiguration = new 
CollectionConfiguration();
collectionConfiguration.setCollocated(true); 

IgniteSet numbers = ignite.set("numbers", null);
if (numbers == null) {

System.out.println("[local] creating collection [numbers]");
numbers = ignite.set("numbers", collectionConfiguration);

}

boolean cont = numbers.contains(42L);   // true - OK
int num = numbers.size();   // 0 Error ???
System.out.println("size=" + num + ", contains=" + cont);

numbers.forEach(val -> {
System.out.println(val); // Iterator is not iterate :(
});

numbers.add(42L);
Thread.sleep(1000 * 6000);

  was:
For distributed IgniteSet new node shows incorrdet set size
igniteSet.size() == 0 shows 0, 

CollectionConfiguration collectionConfiguration = new 
CollectionConfiguration();
collectionConfiguration.setCollocated(true); 

IgniteSet numbers = ignite.set("numbers", null);
if (numbers == null) {
System.out.println("[local] creating collection [numbers]");
numbers = ignite.set("numbers", collectionConfiguration);
}

boolean cont = numbers.contains(42L);   // true - OK
int num = numbers.size();   // 0 Error ???
System.out.println("size=" + num + ", contains=" + cont);

numbers.forEach(val -> {
System.out.println(val); // Iterator is not iterate :(
});

numbers.add(42L);
Thread.sleep(1000 * 6000);


> Distributed IgniteSet shows size() == 0 for any new node
> 
>
> Key: IGNITE-3373
> URL: https://issues.apache.org/jira/browse/IGNITE-3373
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey Velichko
>
> For distributed IgniteSet new node shows incorrdet set size
> igniteSet.size() == 0 shows 0, 
> CollectionConfiguration collectionConfiguration = new 
> CollectionConfiguration();
> collectionConfiguration.setCollocated(true); 
> IgniteSet numbers = ignite.set("numbers", null);
> if (numbers == null) {
> System.out.println("[local] creating collection [numbers]");
> numbers = ignite.set("numbers", collectionConfiguration);
> }
> boolean cont = numbers.contains(42L); // true - OK
> int num = numbers.size(); // 0 Error ???
> System.out.println("size=" + num + ", contains=" + cont);
> numbers.forEach(val -> {
> System.out.println(val); // Iterator is not iterate :(
> });
>   numbers.add(42L);
>   Thread.sleep(1000 * 6000);



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

[jira] [Updated] (IGNITE-3365) .NET: User-defined affinity mapper

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-3365:
---
Assignee: (was: Pavel Tupitsyn)

> .NET: User-defined affinity mapper
> --
>
> Key: IGNITE-3365
> URL: https://issues.apache.org/jira/browse/IGNITE-3365
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Priority: Critical
> Fix For: 1.7
>
>




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

[jira] [Commented] (IGNITE-3361) Service is not redeployed after a node is left topology

[Semen Boikov (JIRA)]

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

Semen Boikov commented on IGNITE-3361:
--

Looks like this is incorrect condition in GridServiceProcessor:reassign
{noformat}
if (!used.contains(e.getKey())) {
if (e.getValue() < maxPerNodeCnt) {
e.setValue(e.getValue() + 1);

if (--remainder == 0)
break;
}
}
{noformat}

With the attached test maxPerNodeCnt=0 which means unlimited, but check 'if 
(e.getValue() < maxPerNodeCnt)' fails and service is not redeployed.

> Service is not redeployed after a node is left topology
> ---
>
> Key: IGNITE-3361
> URL: https://issues.apache.org/jira/browse/IGNITE-3361
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Denis Magda
>Assignee: Semen Boikov
>Priority: Blocker
> Fix For: 1.7
>
> Attachments: SingletonServiceLostAfterToplogyChangeMain.java
>
>
> In attach you will find an example demonstrating the issue when a service is 
> not being redeployed after several nodes are started and stopped.
> The stack trace of the issue is the following
> {code}
> Exception in thread "main" class org.apache.ignite.IgniteException: Failed to 
> find deployed service: DummyService
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProxy$ProxyInvocationHandler.invoke(GridServiceProxy.java:168)
>   at com.sun.proxy.$Proxy24.foo(Unknown Source)
>   at 
> org.apache.ignite.examples.SingletonServiceLostAfterToplogyChangeMain.failingSequence(SingletonServiceLostAfterToplogyChangeMain.java:95)
>   at 
> org.apache.ignite.examples.SingletonServiceLostAfterToplogyChangeMain.main(SingletonServiceLostAfterToplogyChangeMain.java:18)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> {code}



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

[jira] [Commented] (IGNITE-3154) More efficient field lookup in binary protocol.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-3154:
-

Looks too complex for me. I implemented another approach: just a proxy instance 
around BinaryTypeImpl. Waiting for tests to pass.

> More efficient field lookup in binary protocol.
> ---
>
> Key: IGNITE-3154
> URL: https://issues.apache.org/jira/browse/IGNITE-3154
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
>  Labels: customer
> Fix For: 1.7
>
>
> *Problem*
> Currently creation of binary field is performed as follows: 
> {{BinaryObject.type().field(...)}}. Call to {{BinaryObject.type()}} is pretty 
> expensive as it requires metadata lookup. Interesting thing is that 
> subsequent call to {{BinaryType.field()}} doesn't require metadata at all. 
> *Solution*
> Implement lazy metadata load for this case.



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

[jira] [Closed] (IGNITE-2879) ODBC: Add support for Decimal type (SQL_NUMERIC_STRUCT).

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-2879.
---

> ODBC: Add support for Decimal type (SQL_NUMERIC_STRUCT).
> 
>
> Key: IGNITE-2879
> URL: https://issues.apache.org/jira/browse/IGNITE-2879
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>
> We need reasonable Decimal type support at least for the ODBC.



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

[jira] [Commented] (IGNITE-3372) IgniteDataStreamer: pre-loading starvation if multiple streamers preload the same cache

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-3372:
-

Checking with TC

> IgniteDataStreamer: pre-loading starvation if multiple streamers preload the 
> same cache
> ---
>
> Key: IGNITE-3372
> URL: https://issues.apache.org/jira/browse/IGNITE-3372
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Critical
> Attachments: jstack2.log
>
>
> If to start preloading a cache from multiple streamers on a node that owns 
> partitions that are being preloaded then we will get performance degradation 
> at some point in cases if:
> - BinaryMarshaller is used;
> - an entry key is a custom object for which we store data in metadata cache.
> The main reason according to the thread dumps attached is a race-condition 
> around 
> {{org.apache.ignite.internal.processors.cache.GridCacheMapEntry.obsolete(GridCacheMapEntry.java:2888)}}
> To improve the performance both {{GridDhtPartitionTopologyImpl.onRemove}} and 
> {{GridDhtPartitionTopologyImpl.onAdded}} must reuse a partition number that 
> is hold in entry.



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

[jira] [Commented] (IGNITE-3371) .NET: Configure PlatformAffinityFunction in Spring

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3371:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-3371 .NET: Configure PlatformAffinityFunction in Spring



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

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

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

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


commit c6d8da072f3b957012e97d69ae6b6af0ba9ad84d
Author: Pavel Tupitsyn 
Date:   2016-06-27T09:30:53Z

IGNITE-3371 .NET: Configure PlatformAffinityFunction in Spring

commit 0bb1ca4ca5a1bf2153db27a9b921747e5ab38d37
Author: Pavel Tupitsyn 
Date:   2016-06-27T10:20:49Z

wip

commit ca1f61325cec26148394aba7d2c4ac35c9028509
Author: Pavel Tupitsyn 
Date:   2016-06-27T10:23:39Z

Adding tests

commit b8f39d5194d59bc6ff73697975b2f3db31ff6c82
Author: Pavel Tupitsyn 
Date:   2016-06-27T10:29:35Z

Revert some changes

commit 688f57418e71d60e62dae9094ba0e9a004c9908e
Author: Pavel Tupitsyn 
Date:   2016-06-27T10:51:03Z

wip

commit 757f9cb050cbeccb4de34782a585a2e8cce3e052
Author: Pavel Tupitsyn 
Date:   2016-06-27T10:54:32Z

wip

commit f377a507c03784650945debdf3415f09b32173e4
Author: Pavel Tupitsyn 
Date:   2016-06-27T11:42:47Z

Java part done

commit e8bc9e26eafbb2ef94df1f6c2ca9b7a0f8ab9e47
Author: Pavel Tupitsyn 
Date:   2016-06-27T11:49:51Z

wip

commit c77974a07444b08ba23e63f680a8c4e39b041125
Author: Pavel Tupitsyn 
Date:   2016-06-27T12:01:26Z

Test works




> .NET: Configure PlatformAffinityFunction in Spring
> --
>
> Key: IGNITE-3371
> URL: https://issues.apache.org/jira/browse/IGNITE-3371
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.7
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.7
>
>
> Add PlatformAffinityFunction.typeName property to initialize a user-defined 
> function with Reflection.



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

[jira] [Commented] (IGNITE-3372) IgniteDataStreamer: pre-loading starvation if multiple streamers preload the same cache

[Semen Boikov (JIRA)]

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

Semen Boikov commented on IGNITE-3372:
--

Reviewed change, looks good.

> IgniteDataStreamer: pre-loading starvation if multiple streamers preload the 
> same cache
> ---
>
> Key: IGNITE-3372
> URL: https://issues.apache.org/jira/browse/IGNITE-3372
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Critical
> Attachments: jstack2.log
>
>
> If to start preloading a cache from multiple streamers on a node that owns 
> partitions that are being preloaded then we will get performance degradation 
> at some point in cases if:
> - BinaryMarshaller is used;
> - an entry key is a custom object for which we store data in metadata cache.
> The main reason according to the thread dumps attached is a race-condition 
> around 
> {{org.apache.ignite.internal.processors.cache.GridCacheMapEntry.obsolete(GridCacheMapEntry.java:2888)}}
> To improve the performance both {{GridDhtPartitionTopologyImpl.onRemove}} and 
> {{GridDhtPartitionTopologyImpl.onAdded}} must reuse a partition number that 
> is hold in entry.



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

[jira] [Commented] (IGNITE-3372) IgniteDataStreamer: pre-loading starvation if multiple streamers preload the same cache

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-3372:
-

GitHub user dmagda opened a pull request:

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

   ignite-3372: IgniteDataStreamer: pre-loading starvation if multiple 
streamers preload the same cache



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

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

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

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


> IgniteDataStreamer: pre-loading starvation if multiple streamers preload the 
> same cache
> ---
>
> Key: IGNITE-3372
> URL: https://issues.apache.org/jira/browse/IGNITE-3372
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Critical
> Attachments: jstack2.log
>
>
> If to start preloading a cache from multiple streamers on a node that owns 
> partitions that are being preloaded then we will get performance degradation 
> at some point in cases if:
> - BinaryMarshaller is used;
> - an entry key is a custom object for which we store data in metadata cache.
> The main reason according to the thread dumps attached is a race-condition 
> around 
> {{org.apache.ignite.internal.processors.cache.GridCacheMapEntry.obsolete(GridCacheMapEntry.java:2888)}}
> To improve the performance both {{GridDhtPartitionTopologyImpl.onRemove}} and 
> {{GridDhtPartitionTopologyImpl.onAdded}} must reuse a partition number that 
> is hold in entry.



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

[jira] [Updated] (IGNITE-3372) IgniteDataStreamer: pre-loading starvation if multiple streamers preload the same cache

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-3372:

Attachment: jstack2.log

> IgniteDataStreamer: pre-loading starvation if multiple streamers preload the 
> same cache
> ---
>
> Key: IGNITE-3372
> URL: https://issues.apache.org/jira/browse/IGNITE-3372
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Critical
> Attachments: jstack2.log
>
>
> If to start preloading a cache from multiple streamers on a node that owns 
> partitions that are being preloaded then we will get performance degradation 
> at some point in cases if:
> - BinaryMarshaller is used;
> - an entry key is a custom object for which we store data in metadata cache.
> The main reason according to the thread dumps attached is a race-condition 
> around 
> {{org.apache.ignite.internal.processors.cache.GridCacheMapEntry.obsolete(GridCacheMapEntry.java:2888)}}
> To improve the performance both {{GridDhtPartitionTopologyImpl.onRemove}} and 
> {{GridDhtPartitionTopologyImpl.onAdded}} must reuse a partition number that 
> is hold in entry.



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

[jira] [Created] (IGNITE-3372) IgniteDataStreamer: pre-loading starvation if multiple streamers preload the same cache

[Denis Magda (JIRA)]

Denis Magda created IGNITE-3372:
---

 Summary: IgniteDataStreamer: pre-loading starvation if multiple 
streamers preload the same cache
 Key: IGNITE-3372
 URL: https://issues.apache.org/jira/browse/IGNITE-3372
 Project: Ignite
  Issue Type: Bug
Reporter: Denis Magda
Assignee: Denis Magda
Priority: Critical


If to start preloading a cache from multiple streamers on a node that owns 
partitions that are being preloaded then we will get performance degradation at 
some point in cases if:

- BinaryMarshaller is used;
- an entry key is a custom object for which we store data in metadata cache.

The main reason according to the thread dumps attached is a race-condition 
around 
{{org.apache.ignite.internal.processors.cache.GridCacheMapEntry.obsolete(GridCacheMapEntry.java:2888)}}

To improve the performance both {{GridDhtPartitionTopologyImpl.onRemove}} and 
{{GridDhtPartitionTopologyImpl.onAdded}} must reuse a partition number that is 
hold in entry.




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

[jira] [Comment Edited] (IGNITE-1525) Return value for cache operation can be lost with onePhaseCommit

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov edited comment on IGNITE-1525 at 6/27/16 10:51 AM:


Sounds good, 
but I have another idea, 
Seems we can get rid of {{GridDhtTxFinishRequest}} and 
{{GridDhtTxFinishResponse}} in case of onePhaseCommit.

Tx steps in this case:
1) Client sends {{GridNearTxPrepareRequest}} to Primary (nothing changed)
2) Primary sends {{GridDhtTxPrepareRequest}} to Backup (nothing changed)
3) #1 Point where Primary or Backup can fail with possible committed Tx (at 
Backup).
4) Backup sends {{GridNearTxPrepareResponse}} (or its analog) to Client. Client 
informed that Tx committed.
5) #2 Point where Primary or Backup can fail with committed Tx (at Backup).
6) Backup sends {{GridDhtTxPrepareResponse}} to Primary. Primary commits data 
and release locks.

Possible fails and solutions:
#1 Primary fails. Ok, go to the step 4, skip step 6.
#1 Backup fails. Primary node, at Backup left, finishes Tx and sends 
{{GridNearTxPrepareResponse}} to Client.
#2 Primary fails. Ok, skip step 6.
#2 Backup fails. Primary node, at Backup left, finishes Tx.

Thoughts?


was (Author: avinogradov):
Sounds good, 
but I have another idea, 
Seems we can get rid of {{GridDhtTxFinishRequest}} and 
{{GridDhtTxFinishResponse}} in case of onePhaseCommit.

Tx steps in this case:
1) Client sends {{GridNearTxPrepareRequest}} to Primary (nothing changed)
2) Primary sends {{GridDhtTxPrepareRequest}} to Backup (nothing changed)
3) #1 Point where Primary or Backup can fail with possible committed Tx (at 
Backup).
4) Backup sends {{GridNearTxPrepareResponse}} (or its analog) to Client. Client 
informed that Tx committed.
5) #2 Point where Primary or Backup can fail with committed Tx (at Backup).
6) Backup sends {{GridDhtTxPrepareResponse}} to Primary. Primary commits data 
and release locks.

Possible fails and solutions:
#1 Primary fails. Ok, go to the step 4, skip step 6.
#1 Backup fails. Primary node, at backup left, finishes Tx and sends 
{{GridNearTxPrepareResponse}} to Client.
#2 Primary fails. Ok, skip step 6.
#2 Backup fails. Primary node, at backup left, finishes Tx.

Thoughts?

> Return value for cache operation can be lost with onePhaseCommit
> 
>
> Key: IGNITE-1525
> URL: https://issues.apache.org/jira/browse/IGNITE-1525
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Semen Boikov
>Assignee: Anton Vinogradov
>Priority: Blocker
> Fix For: 1.7
>
>
> Looks like with {{onePhaseCommit}} return value for cache operation can be 
> lost if primary node fails, {{GridNearTxPrepareResponse}} with return value 
> is not received, but transaction executes 'check backup' step and finishes 
> without error.
> Reproduces in {{IgniteCachePutRetryTransactionalSelfTest.testInvoke}}, also 
> added one more test to check return value 
> {{IgniteCachePutRetryTransactionalSelfTest.testGetAndPut}}.
> Please unmute tests on TC when fixed.



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

[jira] [Comment Edited] (IGNITE-1525) Return value for cache operation can be lost with onePhaseCommit

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov edited comment on IGNITE-1525 at 6/27/16 10:51 AM:


Sounds good, 
but I have another idea, 
Seems we can get rid of {{GridDhtTxFinishRequest}} and 
{{GridDhtTxFinishResponse}} in case of onePhaseCommit.

Tx steps in this case:
1) Client sends {{GridNearTxPrepareRequest}} to Primary (nothing changed)
2) Primary sends {{GridDhtTxPrepareRequest}} to Backup (nothing changed)
3) #1 Point where Primary or Backup can fail with possible committed Tx (at 
Backup).
4) Backup sends {{GridNearTxPrepareResponse}} (or its analog) to Client. Client 
informed that Tx committed.
5) #2 Point where Primary or Backup can fail with committed Tx (at Backup).
6) Backup sends {{GridDhtTxPrepareResponse}} to Primary. Primary commits data 
and release locks.

Possible fails and solutions:
#1 Primary fails. Ok, go to the step 4, skip step 6.
#1 Backup fails. Primary node, at backup left, finishes Tx and sends 
{{GridNearTxPrepareResponse}} to Client.
#2 Primary fails. Ok, skip step 6.
#2 Backup fails. Primary node, at backup left, finishes Tx.

Thoughts?


was (Author: avinogradov):
Sounds good, 
but I have another idea, 
Seems we can get rid of {{GridDhtTxFinishRequest}} and 
{{GridDhtTxFinishResponse}} in case of onePhaseCommit.

Tx steps in this case:
1) Client sends {{GridNearTxPrepareRequest}} to Primary (nothing changed)
2) Primary sends {{GridDhtTxPrepareRequest}} to Backup (nothing changed)
3) #1 Point where Primary or Backup can fail with possible committed Tx (at 
Backup).
4) Backup sends {{GridNearTxPrepareResponse}} (or its analog) to Client. Client 
informed that Tx committed.
5) #2 Point where Primary or Backup can fail with committed Tx (at Backup).
6) Backup sends {{GridDhtTxPrepareResponse}} to Primary. Primary committs data 
and release locks.

Possible fails and solutions:
#1 Primary fails. Ok, go to the step 4, skip step 6.
#1 Backup fails. Primary node, at backup left finishes Tx and sends 
{{GridNearTxPrepareResponse}} to Client.
#2 Primary fails. Ok, skip step 6.
#2 Backup fails. Primary node, at backup left finishes Tx.

Thoughts?

> Return value for cache operation can be lost with onePhaseCommit
> 
>
> Key: IGNITE-1525
> URL: https://issues.apache.org/jira/browse/IGNITE-1525
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Semen Boikov
>Assignee: Anton Vinogradov
>Priority: Blocker
> Fix For: 1.7
>
>
> Looks like with {{onePhaseCommit}} return value for cache operation can be 
> lost if primary node fails, {{GridNearTxPrepareResponse}} with return value 
> is not received, but transaction executes 'check backup' step and finishes 
> without error.
> Reproduces in {{IgniteCachePutRetryTransactionalSelfTest.testInvoke}}, also 
> added one more test to check return value 
> {{IgniteCachePutRetryTransactionalSelfTest.testGetAndPut}}.
> Please unmute tests on TC when fixed.



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

[jira] [Closed] (IGNITE-3184) Hadoop: HADOOP_HOME should not be required if all other environment variables are set.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-3184.
---

> Hadoop: HADOOP_HOME should not be required if all other environment variables 
> are set.
> --
>
> Key: IGNITE-3184
> URL: https://issues.apache.org/jira/browse/IGNITE-3184
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>
> *Problem*
> Ignite internals require three pieces to create correct Hadoop classpath:
> 1) Path to common JARs;
> 2) Path to HDFS JARs;
> 3) Path map-reduce JARs.
> These three paths could be set with environment variables HADOOP_COMMON_HOME, 
> HADOOP_HDFS_HOME and HADOOP_MAPRED_HOME respectively. 
> When all of them are set, HADOOP_HOME is no longer needed, but we will throw 
> an exception in this case. We should not do that.
> *Solution*
> Throw exception only in case we cannot resolve any of these paths.



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

[jira] [Commented] (IGNITE-1525) Return value for cache operation can be lost with onePhaseCommit

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-1525:
--

Sounds good, 
but I have another idea, 
Seems we can get rid of {{GridDhtTxFinishRequest}} and 
{{GridDhtTxFinishResponse}} in case of onePhaseCommit.

Tx steps in this case:
1) Client sends {{GridNearTxPrepareRequest}} to Primary (nothing changed)
2) Primary sends {{GridDhtTxPrepareRequest}} to Backup (nothing changed)
3) #1 Point where Primary or Backup can fail with possible committed Tx (at 
Backup).
4) Backup sends {{GridNearTxPrepareResponse}} (or its analog) to Client. Client 
informed that Tx committed.
5) #2 Point where Primary or Backup can fail with committed Tx (at Backup).
6) Backup sends {{GridDhtTxPrepareResponse}} to Primary. Primary committs data 
and release locks.

Possible fails and solutions:
#1 Primary fails. Ok, go to the step 4, skip step 6.
#1 Backup fails. Primary node, at backup left finishes Tx and sends 
{{GridNearTxPrepareResponse}} to Client.
#2 Primary fails. Ok, skip step 6.
#2 Backup fails. Primary node, at backup left finishes Tx.

Thoughts?

> Return value for cache operation can be lost with onePhaseCommit
> 
>
> Key: IGNITE-1525
> URL: https://issues.apache.org/jira/browse/IGNITE-1525
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Semen Boikov
>Assignee: Anton Vinogradov
>Priority: Blocker
> Fix For: 1.7
>
>
> Looks like with {{onePhaseCommit}} return value for cache operation can be 
> lost if primary node fails, {{GridNearTxPrepareResponse}} with return value 
> is not received, but transaction executes 'check backup' step and finishes 
> without error.
> Reproduces in {{IgniteCachePutRetryTransactionalSelfTest.testInvoke}}, also 
> added one more test to check return value 
> {{IgniteCachePutRetryTransactionalSelfTest.testGetAndPut}}.
> Please unmute tests on TC when fixed.



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

[jira] [Reopened] (IGNITE-3318) Web console: schema name must be unique for each cache

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reopened IGNITE-3318:
---
  Assignee: Alexey Kuznetsov  (was: Vasiliy Sisko)

Added showing of message when SQL query name is cleared. ignite-3318

> Web console: schema name must be unique for each cache
> --
>
> Key: IGNITE-3318
> URL: https://issues.apache.org/jira/browse/IGNITE-3318
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
> Fix For: 1.7
>
>
> Currently we don't check that schema name is unique.
> Just clone cache with schema name ans Save.



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

[jira] [Comment Edited] (IGNITE-3319) Web Console: speed up bundle rebuild and watch

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko edited comment on IGNITE-3319 at 6/27/16 10:38 AM:
-

Wrong sort direction symbol on table sort.


was (Author: vsisko):
Wrong sort direction symbol on table sort.
gulp eslint command is lost. 

> Web Console: speed up bundle rebuild and watch
> --
>
> Key: IGNITE-3319
> URL: https://issues.apache.org/jira/browse/IGNITE-3319
> Project: Ignite
>  Issue Type: Bug
>  Components: UI
>Reporter: Maxim Afanasiev
>Assignee: Maxim Afanasiev
>
> Try to use WebPack instead of JSPM.



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

[jira] [Reopened] (IGNITE-3319) Web Console: speed up bundle rebuild and watch

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reopened IGNITE-3319:
---
  Assignee: Maxim Afanasiev  (was: Vasiliy Sisko)

> Web Console: speed up bundle rebuild and watch
> --
>
> Key: IGNITE-3319
> URL: https://issues.apache.org/jira/browse/IGNITE-3319
> Project: Ignite
>  Issue Type: Bug
>  Components: UI
>Reporter: Maxim Afanasiev
>Assignee: Maxim Afanasiev
>
> Try to use WebPack instead of JSPM.



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

[jira] [Commented] (IGNITE-3319) Web Console: speed up bundle rebuild and watch

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko commented on IGNITE-3319:
---

Wrong sort direction symbol on table sort.
gulp eslint command is lost. 

> Web Console: speed up bundle rebuild and watch
> --
>
> Key: IGNITE-3319
> URL: https://issues.apache.org/jira/browse/IGNITE-3319
> Project: Ignite
>  Issue Type: Bug
>  Components: UI
>Reporter: Maxim Afanasiev
>Assignee: Vasiliy Sisko
>
> Try to use WebPack instead of JSPM.



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

[jira] [Created] (IGNITE-3371) .NET: Configure PlatformAffinityFunction in Spring

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-3371:
--

 Summary: .NET: Configure PlatformAffinityFunction in Spring
 Key: IGNITE-3371
 URL: https://issues.apache.org/jira/browse/IGNITE-3371
 Project: Ignite
  Issue Type: New Feature
  Components: platforms
Affects Versions: 1.7
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 1.7


Add PlatformAffinityFunction.typeName property to initialize a user-defined 
function with Reflection.



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

[jira] [Updated] (IGNITE-3319) Web Console: speed up bundle rebuild and watch

[Andrey Novikov (JIRA)]

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

Andrey Novikov updated IGNITE-3319:
---
Assignee: Vasiliy Sisko  (was: Andrey Novikov)

> Web Console: speed up bundle rebuild and watch
> --
>
> Key: IGNITE-3319
> URL: https://issues.apache.org/jira/browse/IGNITE-3319
> Project: Ignite
>  Issue Type: Bug
>  Components: UI
>Reporter: Maxim Afanasiev
>Assignee: Vasiliy Sisko
>
> Try to use WebPack instead of JSPM.



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

[jira] [Commented] (IGNITE-3319) Web Console: speed up bundle rebuild and watch

[Andrey Novikov (JIRA)]

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

Andrey Novikov commented on IGNITE-3319:


Vasiliy, please check that all works fine.

> Web Console: speed up bundle rebuild and watch
> --
>
> Key: IGNITE-3319
> URL: https://issues.apache.org/jira/browse/IGNITE-3319
> Project: Ignite
>  Issue Type: Bug
>  Components: UI
>Reporter: Maxim Afanasiev
>Assignee: Andrey Novikov
>
> Try to use WebPack instead of JSPM.



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

[jira] [Commented] (IGNITE-3319) Web Console: speed up bundle rebuild and watch

[Andrey Novikov (JIRA)]

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

Andrey Novikov commented on IGNITE-3319:


Reviewed. Merged.

> Web Console: speed up bundle rebuild and watch
> --
>
> Key: IGNITE-3319
> URL: https://issues.apache.org/jira/browse/IGNITE-3319
> Project: Ignite
>  Issue Type: Bug
>  Components: UI
>Reporter: Maxim Afanasiev
>Assignee: Andrey Novikov
>
> Try to use WebPack instead of JSPM.



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

[jira] [Created] (IGNITE-3370) Add possibility to add handlers in ignite-rest-http module using jetty configuration

[Andrey Novikov (JIRA)]

Andrey Novikov created IGNITE-3370:
--

 Summary: Add possibility to add handlers in ignite-rest-http 
module using jetty configuration
 Key: IGNITE-3370
 URL: https://issues.apache.org/jira/browse/IGNITE-3370
 Project: Ignite
  Issue Type: Bug
  Components: clients
Affects Versions: 1.6
Reporter: Andrey Novikov


http://apache-ignite-users.70518.x6.nabble.com/Jetty-configuration-for-adding-new-Handler-td5841.html



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

[jira] [Updated] (IGNITE-3138) IgniteDataStreamer: failures are not shown on the streaming side

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-3138:

Description: 
If an exception happens during the streaming, the side that streams the data 
won't printed out anything in its logs even if IGNITE_QUIET set to false.

This makes it's inconvenient to see whether there an issue happened during the 
streaming or not.

Suggested improvements:
- print out errors that happened during the streaming on the streaming side;
- Future that is returned from {{addData}} methods is not called in case of 
error. This must be fixed. So that the user is able to write a custom logic 
around this feature and process errors somehow.

  was:
If an exception happens during the streaming, the side that streams the data 
won't printed out anything in its logs even if IGNITE_QUIET set to false.

This makes it's inconvenient to see whether there an issue happened during the 
streaming or not.

Suggested improvements:
- print out errors that happened during the streaming on the streaming side;
- Future that is returned from {{addData}} methods are not called in case of 
error. This must be fixed. So that the user is able to write a custom logic 
around this issue.


> IgniteDataStreamer: failures are not shown on the streaming side
> 
>
> Key: IGNITE-3138
> URL: https://issues.apache.org/jira/browse/IGNITE-3138
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>
> If an exception happens during the streaming, the side that streams the data 
> won't printed out anything in its logs even if IGNITE_QUIET set to false.
> This makes it's inconvenient to see whether there an issue happened during 
> the streaming or not.
> Suggested improvements:
> - print out errors that happened during the streaming on the streaming side;
> - Future that is returned from {{addData}} methods is not called in case of 
> error. This must be fixed. So that the user is able to write a custom logic 
> around this feature and process errors somehow.



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

[jira] [Updated] (IGNITE-3138) IgniteDataStreamer: failures are not shown on the streaming side

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-3138:

Description: 
If an exception happens during the streaming, the side that streams the data 
won't printed out anything in its logs even if IGNITE_QUIET set to false.

This makes it's inconvenient to see whether there an issue happened during the 
streaming or not.

Suggested improvements:
- print out errors that happened during the streaming on the streaming side;
- Future that is returned from {{addData}} methods are not called in case of 
error. This must be fixed. So that the user is able to write a custom logic 
around this issue.

  was:
If an exception happens during the streaming, the side that streams the data 
won't printed out anything in its logs even if IGNITE_QUIET set to false.

This makes it's inconvenient to see whether there an issue happened during the 
streaming or not.

Suggested improvements:
- print out errors that happened during the streaming on the streaming side;
- give an ability to register a callback that will be executed in case of error 
so that the user code can decide whether it makes sense to proceed with the 
streaming or not.


> IgniteDataStreamer: failures are not shown on the streaming side
> 
>
> Key: IGNITE-3138
> URL: https://issues.apache.org/jira/browse/IGNITE-3138
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>
> If an exception happens during the streaming, the side that streams the data 
> won't printed out anything in its logs even if IGNITE_QUIET set to false.
> This makes it's inconvenient to see whether there an issue happened during 
> the streaming or not.
> Suggested improvements:
> - print out errors that happened during the streaming on the streaming side;
> - Future that is returned from {{addData}} methods are not called in case of 
> error. This must be fixed. So that the user is able to write a custom logic 
> around this issue.



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

[jira] [Created] (IGNITE-3369) Add code generation for C++ in download project and configuration preview.

[Andrey Novikov (JIRA)]

Andrey Novikov created IGNITE-3369:
--

 Summary: Add code generation for C++ in download project and 
configuration preview.
 Key: IGNITE-3369
 URL: https://issues.apache.org/jira/browse/IGNITE-3369
 Project: Ignite
  Issue Type: Sub-task
  Components: wizards
Affects Versions: 1.6
Reporter: Andrey Novikov






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

[jira] [Updated] (IGNITE-1929) Add code generation for and C# in download project and configuration preview.

[Andrey Novikov (JIRA)]

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

Andrey Novikov updated IGNITE-1929:
---
Summary: Add code generation for and C# in download project and 
configuration preview.  (was: Add code generation for C++ and C# in download 
project and preview.)

> Add code generation for and C# in download project and configuration preview.
> -
>
> Key: IGNITE-1929
> URL: https://issues.apache.org/jira/browse/IGNITE-1929
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.5.0.final
>Reporter: Alexey Kuznetsov
>Priority: Minor
>
> We need to generate code for C++ and C# the same way we do for Java.



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

[jira] [Updated] (IGNITE-1929) Add code generation for C# in download project and configuration preview.

[Andrey Novikov (JIRA)]

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

Andrey Novikov updated IGNITE-1929:
---
Summary: Add code generation for C# in download project and configuration 
preview.  (was: Add code generation for and C# in download project and 
configuration preview.)

> Add code generation for C# in download project and configuration preview.
> -
>
> Key: IGNITE-1929
> URL: https://issues.apache.org/jira/browse/IGNITE-1929
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.5.0.final
>Reporter: Alexey Kuznetsov
>Priority: Minor
>
> We need to generate code for C++ and C# the same way we do for Java.



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

[jira] [Commented] (IGNITE-3350) Add support several users for web agent

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko commented on IGNITE-3350:
---

Tested. 

> Add support several users for web agent
> ---
>
> Key: IGNITE-3350
> URL: https://issues.apache.org/jira/browse/IGNITE-3350
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Andrey Novikov
>Assignee: Vasiliy Sisko
> Fix For: 1.7
>
>




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

[jira] [Closed] (IGNITE-3350) Add support several users for web agent

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko closed IGNITE-3350.
-
Assignee: (was: Vasiliy Sisko)

> Add support several users for web agent
> ---
>
> Key: IGNITE-3350
> URL: https://issues.apache.org/jira/browse/IGNITE-3350
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Andrey Novikov
> Fix For: 1.7
>
>




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

[jira] [Assigned] (IGNITE-3361) Service is not redeployed after a node is left topology

[Semen Boikov (JIRA)]

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

Semen Boikov reassigned IGNITE-3361:


Assignee: Semen Boikov

> Service is not redeployed after a node is left topology
> ---
>
> Key: IGNITE-3361
> URL: https://issues.apache.org/jira/browse/IGNITE-3361
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Denis Magda
>Assignee: Semen Boikov
>Priority: Blocker
> Fix For: 1.7
>
> Attachments: SingletonServiceLostAfterToplogyChangeMain.java
>
>
> In attach you will find an example demonstrating the issue when a service is 
> not being redeployed after several nodes are started and stopped.
> The stack trace of the issue is the following
> {code}
> Exception in thread "main" class org.apache.ignite.IgniteException: Failed to 
> find deployed service: DummyService
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProxy$ProxyInvocationHandler.invoke(GridServiceProxy.java:168)
>   at com.sun.proxy.$Proxy24.foo(Unknown Source)
>   at 
> org.apache.ignite.examples.SingletonServiceLostAfterToplogyChangeMain.failingSequence(SingletonServiceLostAfterToplogyChangeMain.java:95)
>   at 
> org.apache.ignite.examples.SingletonServiceLostAfterToplogyChangeMain.main(SingletonServiceLostAfterToplogyChangeMain.java:18)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> {code}



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