[jira] [Commented] (IGNITE-5696) A localListenAsync method is missing in the IgniteMessaging interface.

[Yujue Li (JIRA)]

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

Yujue Li commented on IGNITE-5696:
--

import java.util.UUID;
import org.apache.ignite.Ignite;
import org.apache.ignite.IgniteMessaging;
import org.apache.ignite.Ignition;
import org.apache.ignite.lang.IgniteBiPredicate;

public class IgniteMsgAsyncTest {
public static void main(String[] args) {
try (Ignite ignite = Ignition.start()) {
IgniteMessaging msg = ignite.message().withAsync();
msg.localListen("Topic", new IgniteBiPredicate() {
@Override
public boolean apply(UUID nodeId, String msg) {
try {

Thread.currentThread().sleep(2000);
} catch (InterruptedException e) {
// TODO Auto-generated catch 
block
e.printStackTrace();
}
System.out.println("Received message 
[msg=" + msg + ", from=" + nodeId + ']');
return true; // Return true to continue 
listening.
}
});
for (int i = 0; i < 5; i++) {
msg.send("Topic", Integer.toString(i));
System.out.println("MSG:" + i);
}
}
}
}
In the 2.0.0 version, such code can be executed correctly, but the withAsync 
method is abandoned and no new solution is provided.

> A localListenAsync method is missing in the IgniteMessaging interface.
> --
>
> Key: IGNITE-5696
> URL: https://issues.apache.org/jira/browse/IGNITE-5696
> Project: Ignite
>  Issue Type: Bug
>  Components: messaging
>Affects Versions: 2.0
>Reporter: Yujue Li
> Fix For: 2.2
>
>
> Prior to version 2.0, the localListen method supports asynchronous mode 
> because of the presence of the withAsync method.
> But in version 2.0, this is a problem because the withAsync method is 
> obsolete and does not provide a localListenAsync method.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5713) The ignite-spring module should not rely on the ignite-indexing module.

[Yujue Li (JIRA)]

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

Yujue Li updated IGNITE-5713:
-
Priority: Minor  (was: Major)

> The ignite-spring module should not rely on the ignite-indexing module.
> ---
>
> Key: IGNITE-5713
> URL: https://issues.apache.org/jira/browse/IGNITE-5713
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.0
>Reporter: Yujue Li
>Priority: Minor
> Fix For: 2.2
>
>
> In version 2.0, the ignite-spring module has increased reliance on the 
> ignite-indexing module, which is not appropriate.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5838) The IgniteCache.loadCacheAsync method is not executed asynchronously.

[Yujue Li (JIRA)]

Yujue Li created IGNITE-5838:


 Summary: The IgniteCache.loadCacheAsync method is not executed 
asynchronously.
 Key: IGNITE-5838
 URL: https://issues.apache.org/jira/browse/IGNITE-5838
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.0
Reporter: Yujue Li
Priority: Blocker
 Fix For: 2.2


The IgniteCache.loadCacheAsync method is not executed asynchronously.
for example,in the 
https://github.com/apache/ignite/blob/master/examples/src/main/java/org/apache/ignite/examples/datagrid/store/spring/CacheSpringStoreExample.java:
line 129:
If modified to:
cache.loadCacheAsync(null, ENTRY_COUNT);
We will find that the cache is not loaded asynchronously.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5241) Redis hash table support

[Roman Shtykh (JIRA)]

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

Roman Shtykh commented on IGNITE-5241:
--

[~anovikov] I have started implementing HASH commands, and would be thankful if 
you can comment on the approach I take now. 
https://github.com/shroman/ignite/commits/IGNITE-5241

As you see, HASH commands are very similar to STRING commands, and it might be 
good to extends STRING commands to use as HASH commands. But they sometimes 
differ in responses etc, therefore I chose to create another thin package for 
HASH commands to implement it as closer to Redis behavior as possible.

> Redis hash table support
> 
>
> Key: IGNITE-5241
> URL: https://issues.apache.org/jira/browse/IGNITE-5241
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> STRING commands use {{redis-ignite-internal-cache-n}}. 
> {{KEY_NAME}} in HASH commands (https://redis.io/commands#hash) can be 
> considered as a cache name, and HASH commands can work on 
> {{redis-ignite-internal-cache-KEY_NAME}} caches.
> With this, server commands like _SELECT_, _FLUSHDB_, _DBSIZE_ will work only 
> on STRING caches (selected by _SELECT_ command). All HASH caches will be 
> treated by hash commands.
> _FLASHALL_ will purge all Redis caches.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5241) Redis hash table support

[Roman Shtykh (JIRA)]

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

Roman Shtykh updated IGNITE-5241:
-
Description: 
STRING commands use {{redis-ignite-internal-cache-n}}. 
{{KEY_NAME}} in HASH commands (https://redis.io/commands#hash) can be 
considered as a cache name, and HASH commands can work on 
{{redis-ignite-internal-cache-KEY_NAME}} caches.

With this, server commands like _SELECT_, _FLUSHDB_, _DBSIZE_ will work only on 
STRING caches (selected by _SELECT_ command). All HASH caches will be treated 
by hash commands.

_FLASHALL_ will purge all Redis caches.

  was:
STRING commands use {{redis-ignite-internal-cache-n}}. 
{{KEY_NAME}} in HASH commands (https://redis.io/commands#hash) can be 
considered as a cache name, and HASH commands can work on 
{{redis-ignite-internal-cache-KEY_NAME}} caches.

With this, server commands like _SELECT_, _FLUSHDB_ will work only on STRING 
caches.
_FLASHALL_ will purge all Redis caches.


> Redis hash table support
> 
>
> Key: IGNITE-5241
> URL: https://issues.apache.org/jira/browse/IGNITE-5241
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> STRING commands use {{redis-ignite-internal-cache-n}}. 
> {{KEY_NAME}} in HASH commands (https://redis.io/commands#hash) can be 
> considered as a cache name, and HASH commands can work on 
> {{redis-ignite-internal-cache-KEY_NAME}} caches.
> With this, server commands like _SELECT_, _FLUSHDB_, _DBSIZE_ will work only 
> on STRING caches (selected by _SELECT_ command). All HASH caches will be 
> treated by hash commands.
> _FLASHALL_ will purge all Redis caches.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5241) Redis hash table support

[Roman Shtykh (JIRA)]

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

Roman Shtykh updated IGNITE-5241:
-
Description: 
STRING commands use {{redis-ignite-internal-cache-n}}. 
{{KEY_NAME}} in HASH commands (https://redis.io/commands#hash) can be 
considered as a cache name, and HASH commands can work on 
{{redis-ignite-internal-cache-KEY_NAME}} caches.

With this, server commands like _SELECT_, _FLUSHDB_ will work only on STRING 
caches.
_FLASHALL_ will purge all Redis caches.

  was:
STRING commands use {{redis-ignite-internal-cache-n}}. 
Then HASH commands (https://redis.io/commands#hash) can work on 
{{redis-ignite-internal-cache-KEY_NAME}} caches.

With this, server commands like _SELECT_, _FLUSHDB_ will work only on STRING 
caches.
_FLASHALL_ will purge all Redis caches.


> Redis hash table support
> 
>
> Key: IGNITE-5241
> URL: https://issues.apache.org/jira/browse/IGNITE-5241
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> STRING commands use {{redis-ignite-internal-cache-n}}. 
> {{KEY_NAME}} in HASH commands (https://redis.io/commands#hash) can be 
> considered as a cache name, and HASH commands can work on 
> {{redis-ignite-internal-cache-KEY_NAME}} caches.
> With this, server commands like _SELECT_, _FLUSHDB_ will work only on STRING 
> caches.
> _FLASHALL_ will purge all Redis caches.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5241) Redis hash table support

[Roman Shtykh (JIRA)]

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

Roman Shtykh updated IGNITE-5241:
-
Description: 
STRING commands use {{redis-ignite-internal-cache-n}}. 
Then HASH commands (https://redis.io/commands#hash) can work on 
{{redis-ignite-internal-cache-KEY_NAME}} caches.

With this, server commands like _SELECT_, _FLUSHDB_ will work only on STRING 
caches.
_FLASHALL_ will purge all Redis caches.

> Redis hash table support
> 
>
> Key: IGNITE-5241
> URL: https://issues.apache.org/jira/browse/IGNITE-5241
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> STRING commands use {{redis-ignite-internal-cache-n}}. 
> Then HASH commands (https://redis.io/commands#hash) can work on 
> {{redis-ignite-internal-cache-KEY_NAME}} caches.
> With this, server commands like _SELECT_, _FLUSHDB_ will work only on STRING 
> caches.
> _FLASHALL_ will purge all Redis caches.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5241) Redis hash table support

[Roman Shtykh (JIRA)]

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

Roman Shtykh commented on IGNITE-5241:
--

Added HLEN command.

> Redis hash table support
> 
>
> Key: IGNITE-5241
> URL: https://issues.apache.org/jira/browse/IGNITE-5241
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5706) Redis FLUSHDB command support

[Roman Shtykh (JIRA)]

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

Roman Shtykh commented on IGNITE-5706:
--

Hi [~anovikov],

Thank you for your comments!
I got rid of {{redisCaches}} creation and use Map from the beginning, as you 
suggested.

As for iteration over all caches, I need to find and clear all Redis caches, 
and don't know what can {{database}} be in 
{{ctx.cache().cache(CACHE_NAME_PREFIX + database)}}. It can be 1 or 1000, or 
even something else (I use it in IGNITE-5241 I am working on). How do you 
suggest to fix it?

> Redis FLUSHDB command support
> -
>
> Key: IGNITE-5706
> URL: https://issues.apache.org/jira/browse/IGNITE-5706
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
> Fix For: 2.2
>
>
> https://redis.io/commands/flushdb



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (IGNITE-5156) Apache Ignite 2.1 Documentation

[Denis Magda (JIRA)]

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

Denis Magda closed IGNITE-5156.
---

> Apache Ignite 2.1 Documentation
> ---
>
> Key: IGNITE-5156
> URL: https://issues.apache.org/jira/browse/IGNITE-5156
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 2.1
>
>
> This is an umbrella ticket for 2.1 related documentation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5837) Fix logic in DynamicIndexAbstractConcurrentSelfTest

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5837:


GitHub user alexpaschenko opened a pull request:

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

IGNITE-5837 Test logic fix.



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

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

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

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


commit 9b91cecdd2cc2fc62a6d8b2eb87f7cd2240f7703
Author: Alexander Paschenko 
Date:   2017-07-25T23:01:34Z

IGNITE-5837 Test logic fix.




> Fix logic in DynamicIndexAbstractConcurrentSelfTest
> ---
>
> Key: IGNITE-5837
> URL: https://issues.apache.org/jira/browse/IGNITE-5837
> Project: Ignite
>  Issue Type: Test
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
>
> {{DynamicIndexAbstractConcurrentSelfTest}} has logic flaws that need to be 
> fixed (namely with indexing blocking/unblocking), currently it seems to work 
> by (steadily recurring) lucky occasion.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5572) DDL: Support ALTER TABLE ADD COLUMN

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5572:


GitHub user alexpaschenko opened a pull request:

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

IGNITE-5572

ALTER TABLE ADD COLUMN

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

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

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

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


commit 5ccc0e250e91f662fe012bd2c000d67974582b19
Author: Alexander Paschenko 
Date:   2017-07-19T19:00:47Z

IGNITE-5572 ALTER TABLE ADD COLUMN parsing

commit 1602c29f1e4c73f6b926da12f1ad944564529acc
Author: Alexander Paschenko 
Date:   2017-07-25T15:37:48Z

IGNITE-5572 ALTER TABLE ADD COLUMN (no tests)

commit 4a6b39c1f93676f45a3ab0da9b39ec691357a547
Author: Alexander Paschenko 
Date:   2017-07-25T20:51:43Z

IGNITE-5572 First ALTER TABLE ADD COLUMN tests

commit e15e7da7914dd6f73e7bd995bbf4ff166c1e24c3
Author: Alexander Paschenko 
Date:   2017-07-25T22:49:27Z

IGNITE-5572 Minors

commit 4f26e00dc48af1d50c08adb683d6006b590cea9e
Author: Alexander Paschenko 
Date:   2017-07-25T22:57:35Z

Merge remote-tracking branch 'apache/master' into ignite-5572




> DDL: Support ALTER TABLE ADD COLUMN
> ---
>
> Key: IGNITE-5572
> URL: https://issues.apache.org/jira/browse/IGNITE-5572
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.2
>
>
> We should start gradual implementation of {{ALTER TABLE}} command. Let's 
> start with the most simple part - {{ADD COLUMN}}. Proposed design:
> 1) Send a message over a ring, similar to how we do that for create index
> 2) On local node: update relevant QueryEntity, update data strcutrues in 
> {{GridQueryProcessor}}, update {{IgniteH2Indexing}} data structures, execute 
> {{ALTER TABLE}} command on H2 database (global table lock must be acquired).
> 3) Make sure that update to {{QueryEntity}} is properly saved if persistence 
> is enabled.
> Feature should be covered with tests thoroughly:
> 1) Positive cases
> 2) Negative cases (no schema, no table, column already exists)
> 3) Test with concurrent SQL operations
> 4) Test with concurrent node restarts



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (IGNITE-5350) Document ordinary least squares (OLS) linear regression

[Denis Magda (JIRA)]

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

Denis Magda closed IGNITE-5350.
---

> Document ordinary least squares (OLS) linear regression
> ---
>
> Key: IGNITE-5350
> URL: https://issues.apache.org/jira/browse/IGNITE-5350
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation, ml
>Affects Versions: 2.1
>Reporter: Denis Magda
>Assignee: Prachi Garg
> Fix For: 2.1
>
>
> Someone should document OLS algorithm under the ML section on readme.io 
> pasting code snippets. I'll help to create new pages and rework the content 
> if needed.
> Plus, it makes sense to add an example to the source code and refer to it 
> from the readme.io documentation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (IGNITE-5156) Apache Ignite 2.1 Documentation

[Denis Magda (JIRA)]

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

Denis Magda resolved IGNITE-5156.
-
Resolution: Fixed

> Apache Ignite 2.1 Documentation
> ---
>
> Key: IGNITE-5156
> URL: https://issues.apache.org/jira/browse/IGNITE-5156
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 2.1
>
>
> This is an umbrella ticket for 2.1 related documentation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (IGNITE-5345) Update JDBC driver documentation considering the new implementation

[Prachi Garg (JIRA)]

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

Prachi Garg closed IGNITE-5345.
---

Reviewed.

> Update JDBC driver documentation considering the new implementation
> ---
>
> Key: IGNITE-5345
> URL: https://issues.apache.org/jira/browse/IGNITE-5345
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
> Fix For: 2.1
>
>
> The next version of the JDBC driver is to be released in 2.1. We need to 
> refine the existing documentation explaining:
> * how to connect to the cluster.
> * what's the schema format and options.
> * move the legacy driver versions (like the Ignite client based) to the end 
> of the documentation.
> Here is a documentation page for 2.1:
> https://apacheignite.readme.io/v2.1/docs/jdbc-driver
> [~vozerov], let's discuss how to format the page if needed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5837) Fix logic in DynamicIndexAbstractConcurrentSelfTest

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko updated IGNITE-5837:

Description: {{DynamicIndexAbstractConcurrentSelfTest}} has logic flaws 
that need to be fixed (namely with indexing blocking/unblocking), currently it 
seems to work by (steadily recurring) lucky occasion.

> Fix logic in DynamicIndexAbstractConcurrentSelfTest
> ---
>
> Key: IGNITE-5837
> URL: https://issues.apache.org/jira/browse/IGNITE-5837
> Project: Ignite
>  Issue Type: Test
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
>
> {{DynamicIndexAbstractConcurrentSelfTest}} has logic flaws that need to be 
> fixed (namely with indexing blocking/unblocking), currently it seems to work 
> by (steadily recurring) lucky occasion.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5837) Fix logic in DynamicIndexAbstractConcurrentSelfTest

[Alexander Paschenko (JIRA)]

Alexander Paschenko created IGNITE-5837:
---

 Summary: Fix logic in DynamicIndexAbstractConcurrentSelfTest
 Key: IGNITE-5837
 URL: https://issues.apache.org/jira/browse/IGNITE-5837
 Project: Ignite
  Issue Type: Test
Reporter: Alexander Paschenko
Assignee: Alexander Paschenko






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5495) TcpDiscoveryS3IpFinder tests fail

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-5495:


Suite now became useless because all 2 tests are muted

Probably we need to disable suite at all to save agents time
http://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteAws

> TcpDiscoveryS3IpFinder tests fail
> -
>
> Key: IGNITE-5495
> URL: https://issues.apache.org/jira/browse/IGNITE-5495
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Vladimir Ozerov
>Assignee: Dmitriy Pavlov
>Priority: Minor
>  Labels: MakeTeamcityGreenAgain, Muted_test, test-fail
> Fix For: 2.2
>
>
> Affected test:
> {{TcpDiscoveryS3IpFinderAwsCredentialsProviderSelfTest.testIpFinder}}
> {{TcpDiscoveryS3IpFinderAwsCredentialsSelfTest.testIpFinder}}
> Root cause:
> {code}
> Caused by: com.amazonaws.services.s3.model.AmazonS3Exception: The AWS Access 
> Key Id you provided does not exist in our records. (Service: Amazon S3; 
> Status Code: 403; Error Code: InvalidAccessKeyId; Request ID: 
> 3E504B75D197BC05)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5495) TcpDiscoveryS3IpFinder tests fail

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-5495:
---
Labels: MakeTeamcityGreenAgain Muted_test test-fail  (was: Muted_test 
test-fail)

> TcpDiscoveryS3IpFinder tests fail
> -
>
> Key: IGNITE-5495
> URL: https://issues.apache.org/jira/browse/IGNITE-5495
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Vladimir Ozerov
>Assignee: Dmitriy Pavlov
>Priority: Minor
>  Labels: MakeTeamcityGreenAgain, Muted_test, test-fail
> Fix For: 2.2
>
>
> Affected test:
> {{TcpDiscoveryS3IpFinderAwsCredentialsProviderSelfTest.testIpFinder}}
> {{TcpDiscoveryS3IpFinderAwsCredentialsSelfTest.testIpFinder}}
> Root cause:
> {code}
> Caused by: com.amazonaws.services.s3.model.AmazonS3Exception: The AWS Access 
> Key Id you provided does not exist in our records. (Service: Amazon S3; 
> Status Code: 403; Error Code: InvalidAccessKeyId; Request ID: 
> 3E504B75D197BC05)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-2420) [Test] Ignite AWS lacks amazon credentials.

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov reassigned IGNITE-2420:
--

Assignee: Dmitriy Pavlov

> [Test] Ignite AWS lacks amazon credentials.
> ---
>
> Key: IGNITE-2420
> URL: https://issues.apache.org/jira/browse/IGNITE-2420
> Project: Ignite
>  Issue Type: Task
>  Components: aws
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ershov
>Assignee: Dmitriy Pavlov
>Priority: Minor
>  Labels: Muted_test
>   Original Estimate: 8h
>  Remaining Estimate: 8h
>
> There is an issue with amazon credentials. We have to invent a secure way to 
> apply it for AWS tests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-2190) ScanQuery without a filter triggers object's deserialization on the server side

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-2190:


Hi, [~NIzhikov], ok, thank you for clarification

> ScanQuery without a filter triggers object's deserialization on the server 
> side
> ---
>
> Key: IGNITE-2190
> URL: https://issues.apache.org/jira/browse/IGNITE-2190
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: ignite-1.4, 2.0
>Reporter: Denis Magda
>Assignee: Nikolay Izhikov
>Priority: Critical
>  Labels: newbie
> Fix For: 2.2
>
> Attachments: ScanQueryBug.java
>
>
> The issue is reproduced on version 1.4 where legacy PortableMarshaller is 
> used. However, I'm quiet sure that the issue happens when BinaryMarshaller is 
> used as well in 1.5.
> 1) Start a server using ignite.sh/bat
> 2) Create a simple app, that uses binary or portable marshaller, creates a 
> cache dynamically and executes a ScanQuery like below
> {{int size=employees1.query(new ScanQuery()).getAll().size();}}
> 3) As you see the query doesn't use any filters. However on the server side 
> some filter is still being checked 
> {{org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$5.checkPredicate(GridCacheQueryManager.java:963)}}
>  which makes the server to deserialize a value.
> According to the stack trace there is some internal filter that triggered 
> checkPredicate function - 
> filter=o.a.i.i.processors.cache.IgniteCacheProxy$1@3224ff7b.
> {noformat}
> [11:05:22,725][SEVERE][ignite-#25%sys-null%][GridCacheDistributedQueryManager]
>   Failed to run query [qry=GridCacheQueryInfo [loc=false, 
> trans=null, rdc=null, qry=GridCacheQueryAdapter [type=SCAN, clsName=null, 
> clause=null, filter=o.a.i.i.processors.cache.IgniteCacheProxy$1@3224ff7b, 
> part=null, incMeta=false, metrics=null, pageSize=1024, timeout=0, 
> keepAll=false, incBackups=false, dedup=false, prj=null, keepPortable=false, 
> subjId=c6aeb542-1693-4b5f-89db-96db50e3435f, taskHash=0], locFut=null, 
> sndId=c6aeb542-1693-4b5f-89db-96db50e3435f, reqId=14, incMeta=false, 
> all=false], node=209c237a-9e33-4d05-abe4-bbc14f93c439]
> class org.apache.ignite.IgniteCheckedException: 
> **.SubMessageB
> at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:6979)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:166)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:115)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$CachedResult.iterator(GridCacheQueryManager.java:2784)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.runQuery(GridCacheQueryManager.java:1376)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.processQueryRequest(GridCacheDistributedQueryManager.java:226)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$2.apply(GridCacheDistributedQueryManager.java:105)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$2.apply(GridCacheDistributedQueryManager.java:103)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:580)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:198)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:77)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:160)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:811)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1500(GridIoManager.java:106)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:774)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ClassNotFoundException: 
> **.SubMessageB
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at 

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

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko resolved IGNITE-4765.
-
Resolution: Won't Fix

This will be fixed here: https://issues.apache.org/jira/browse/IGNITE-5836

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



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko closed IGNITE-4765.
---

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



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5836) AffinityFunctionContext should provide consistent previous assignment

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-5836:
---

 Summary: AffinityFunctionContext should provide consistent 
previous assignment
 Key: IGNITE-5836
 URL: https://issues.apache.org/jira/browse/IGNITE-5836
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.0
Reporter: Valentin Kulichenko
Priority: Critical
 Fix For: 2.2


Currently each cache maintains its own {{AffinityFunctionContext}}. This leads 
to the case that {{previousAssignment}} can be different for two caches created 
on different topology versions. In particular, this broke 
{{FairAffinityFunction}} which was removed because of that.

We should do the following:
* Make sure that {{previousAssignment}} is consistent for all caches with same 
affinity function, regardless of topology versions caches were created on.
* Add mechanism to enforce equality check for affinity functions. We probably 
will need to force user to implement {{equals}} for cache node filter and 
backup filter.
* When above is done, bring back {{FairAffinityFunction}}.

This is also discussed on dev list: 
http://apache-ignite-developers.2346864.n4.nabble.com/Resurrect-FairAffinityFunction-td19987.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-2190) ScanQuery without a filter triggers object's deserialization on the server side

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-2190:
-

Hi, [~dpavlov]. As far as I can understand we are waiting to [~avinogradov] 
merge my patch into master.
No review from Vladimir is required.

> ScanQuery without a filter triggers object's deserialization on the server 
> side
> ---
>
> Key: IGNITE-2190
> URL: https://issues.apache.org/jira/browse/IGNITE-2190
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: ignite-1.4, 2.0
>Reporter: Denis Magda
>Assignee: Nikolay Izhikov
>Priority: Critical
>  Labels: newbie
> Fix For: 2.2
>
> Attachments: ScanQueryBug.java
>
>
> The issue is reproduced on version 1.4 where legacy PortableMarshaller is 
> used. However, I'm quiet sure that the issue happens when BinaryMarshaller is 
> used as well in 1.5.
> 1) Start a server using ignite.sh/bat
> 2) Create a simple app, that uses binary or portable marshaller, creates a 
> cache dynamically and executes a ScanQuery like below
> {{int size=employees1.query(new ScanQuery()).getAll().size();}}
> 3) As you see the query doesn't use any filters. However on the server side 
> some filter is still being checked 
> {{org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$5.checkPredicate(GridCacheQueryManager.java:963)}}
>  which makes the server to deserialize a value.
> According to the stack trace there is some internal filter that triggered 
> checkPredicate function - 
> filter=o.a.i.i.processors.cache.IgniteCacheProxy$1@3224ff7b.
> {noformat}
> [11:05:22,725][SEVERE][ignite-#25%sys-null%][GridCacheDistributedQueryManager]
>   Failed to run query [qry=GridCacheQueryInfo [loc=false, 
> trans=null, rdc=null, qry=GridCacheQueryAdapter [type=SCAN, clsName=null, 
> clause=null, filter=o.a.i.i.processors.cache.IgniteCacheProxy$1@3224ff7b, 
> part=null, incMeta=false, metrics=null, pageSize=1024, timeout=0, 
> keepAll=false, incBackups=false, dedup=false, prj=null, keepPortable=false, 
> subjId=c6aeb542-1693-4b5f-89db-96db50e3435f, taskHash=0], locFut=null, 
> sndId=c6aeb542-1693-4b5f-89db-96db50e3435f, reqId=14, incMeta=false, 
> all=false], node=209c237a-9e33-4d05-abe4-bbc14f93c439]
> class org.apache.ignite.IgniteCheckedException: 
> **.SubMessageB
> at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:6979)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:166)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:115)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$CachedResult.iterator(GridCacheQueryManager.java:2784)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.runQuery(GridCacheQueryManager.java:1376)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.processQueryRequest(GridCacheDistributedQueryManager.java:226)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$2.apply(GridCacheDistributedQueryManager.java:105)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$2.apply(GridCacheDistributedQueryManager.java:103)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:580)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:198)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:77)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:160)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:811)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1500(GridIoManager.java:106)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:774)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ClassNotFoundException: 
> **.SubMessageB
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at 

[jira] [Commented] (IGNITE-2190) ScanQuery without a filter triggers object's deserialization on the server side

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-2190:


Hi, are we waiting of review from [~vozerov] now?

> ScanQuery without a filter triggers object's deserialization on the server 
> side
> ---
>
> Key: IGNITE-2190
> URL: https://issues.apache.org/jira/browse/IGNITE-2190
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: ignite-1.4, 2.0
>Reporter: Denis Magda
>Assignee: Nikolay Izhikov
>Priority: Critical
>  Labels: newbie
> Fix For: 2.2
>
> Attachments: ScanQueryBug.java
>
>
> The issue is reproduced on version 1.4 where legacy PortableMarshaller is 
> used. However, I'm quiet sure that the issue happens when BinaryMarshaller is 
> used as well in 1.5.
> 1) Start a server using ignite.sh/bat
> 2) Create a simple app, that uses binary or portable marshaller, creates a 
> cache dynamically and executes a ScanQuery like below
> {{int size=employees1.query(new ScanQuery()).getAll().size();}}
> 3) As you see the query doesn't use any filters. However on the server side 
> some filter is still being checked 
> {{org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$5.checkPredicate(GridCacheQueryManager.java:963)}}
>  which makes the server to deserialize a value.
> According to the stack trace there is some internal filter that triggered 
> checkPredicate function - 
> filter=o.a.i.i.processors.cache.IgniteCacheProxy$1@3224ff7b.
> {noformat}
> [11:05:22,725][SEVERE][ignite-#25%sys-null%][GridCacheDistributedQueryManager]
>   Failed to run query [qry=GridCacheQueryInfo [loc=false, 
> trans=null, rdc=null, qry=GridCacheQueryAdapter [type=SCAN, clsName=null, 
> clause=null, filter=o.a.i.i.processors.cache.IgniteCacheProxy$1@3224ff7b, 
> part=null, incMeta=false, metrics=null, pageSize=1024, timeout=0, 
> keepAll=false, incBackups=false, dedup=false, prj=null, keepPortable=false, 
> subjId=c6aeb542-1693-4b5f-89db-96db50e3435f, taskHash=0], locFut=null, 
> sndId=c6aeb542-1693-4b5f-89db-96db50e3435f, reqId=14, incMeta=false, 
> all=false], node=209c237a-9e33-4d05-abe4-bbc14f93c439]
> class org.apache.ignite.IgniteCheckedException: 
> **.SubMessageB
> at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:6979)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:166)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:115)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$CachedResult.iterator(GridCacheQueryManager.java:2784)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.runQuery(GridCacheQueryManager.java:1376)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.processQueryRequest(GridCacheDistributedQueryManager.java:226)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$2.apply(GridCacheDistributedQueryManager.java:105)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$2.apply(GridCacheDistributedQueryManager.java:103)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:580)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:198)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:77)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:160)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:811)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1500(GridIoManager.java:106)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:774)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ClassNotFoundException: 
> **.SubMessageB
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at 

[jira] [Commented] (IGNITE-5046) TcpDiscoverySpi.toString() method miss some fields.

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-5046:


Hi, [~neeraj.bhatt],

Could you also check this changes on Teamcity http://ci.ignite.apache.org/?

I suggest to start 'Run All' on pull/1890/head in 'Ignite 2.0 Tests'.

> TcpDiscoverySpi.toString() method miss some fields.
> ---
>
> Key: IGNITE-5046
> URL: https://issues.apache.org/jira/browse/IGNITE-5046
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.9
>Reporter: Andrew Mashenkov
>Assignee: neeraj
>Priority: Minor
>  Labels: newbie
> Fix For: 2.2
>
>
> We have a number of protected fields that is missed by toString method.
> Looks like we should annotate these fields with @GridToStringInclude.
> locAddr, locPort, locPortRange, netTimeout and others.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5432) Test IgniteMarshallerCacheClassNameConflictTest failed

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-5432:


Hi [~a1vanov],

Thank you for your contribution. It is imporant to have passing tests on 
continious integration server.

I've checked your PR changes. It seems original test was already fixed under 
[IGNITE-4947] during suites migration to Ignite Test 2.0.

But in your PR there is additional test introduced GridP2PPeerClassLoadingTest. 
Is it temprorary test? 
In this test I've found 
- outcommented code, which is better to be removed.
- and also for tests there is common unitity method startGrid(), this is common 
alternative to Ignition start. This is special version of start to be used on 
test env. Otherwise Ignite will discover all nodes of other running test and 
build cluster between Teamcity agents. To provide custom configuration method 
getConfiguration() may be overriden.

If new test GridP2PPeerClassLoadingTest is still required you can update your 
changes. If test is not needeed, you may take this considerations into accont 
for your future contributions.

>  Test IgniteMarshallerCacheClassNameConflictTest failed
> ---
>
> Key: IGNITE-5432
> URL: https://issues.apache.org/jira/browse/IGNITE-5432
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Alexey Ivanov
>Assignee: Alexey Ivanov
> Fix For: 2.2
>
>
> Test suit:
> IgniteBinarySimpleNameMapperBasicTestSuite
> Test:
> IgniteMarshallerCacheClassNameConflictTest



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5278) BLAS implementation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5278:


Github user artemmalykh closed the pull request at:

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


> BLAS implementation
> ---
>
> Key: IGNITE-5278
> URL: https://issues.apache.org/jira/browse/IGNITE-5278
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Affects Versions: 2.1
>Reporter: Yury Babak
>Assignee: Yury Babak
>  Labels: ml
> Fix For: 2.2
>
>
> We need BLAS implementation for local computations.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5834) .NET: Do not close transaction on async commit/rollback

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5834:
--

 Summary: .NET: Do not close transaction on async commit/rollback
 Key: IGNITE-5834
 URL: https://issues.apache.org/jira/browse/IGNITE-5834
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Priority: Critical
 Fix For: 2.2


Committed / rolled back transactions do not need to be closed. 
{{TransactionImpl.CloseWhenComplete}} and {{PlatformTransactions.txClose}} 
perform unnecessary work. This also causes problems with {{commitAsync}} and 
{{rollbackAsync}} since we close a transaction on another thread.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5835) Implement highlight item in non-multiple dropdown

[Dmitriy Shabalin (JIRA)]

Dmitriy Shabalin created IGNITE-5835:


 Summary: Implement highlight item in non-multiple dropdown
 Key: IGNITE-5835
 URL: https://issues.apache.org/jira/browse/IGNITE-5835
 Project: Ignite
  Issue Type: Improvement
  Components: UI, wizards
Affects Versions: 2.2
Reporter: Dmitriy Shabalin
Assignee: Dmitriy Shabalin


1) Hide checkboxes in single dropdown
2) Add highlight to selected item in single dropdown



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5046) TcpDiscoverySpi.toString() method miss some fields.

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-5046:


Hi, [~neeraj.bhatt],

I've checked your changed but it seems 
{code}
  /** Heartbeat messages issuing frequency. */
 @GridToStringInclude
 protected long hbFreq = DFLT_HEARTBEAT_FREQ;
{code}
is no actual anymore. I was not able to find this field in current master. 

Could you please update PR according to current master?

> TcpDiscoverySpi.toString() method miss some fields.
> ---
>
> Key: IGNITE-5046
> URL: https://issues.apache.org/jira/browse/IGNITE-5046
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.9
>Reporter: Andrew Mashenkov
>Assignee: neeraj
>Priority: Minor
>  Labels: newbie
> Fix For: 2.2
>
>
> We have a number of protected fields that is missed by toString method.
> Looks like we should annotate these fields with @GridToStringInclude.
> locAddr, locPort, locPortRange, netTimeout and others.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5278) BLAS implementation

[Yury Babak (JIRA)]

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

Yury Babak commented on IGNITE-5278:


[~isapego] thanks for review! The unnecessary double columns allocation fixed 
in last commit.

> BLAS implementation
> ---
>
> Key: IGNITE-5278
> URL: https://issues.apache.org/jira/browse/IGNITE-5278
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Affects Versions: 2.1
>Reporter: Yury Babak
>Assignee: Yury Babak
>  Labels: ml
> Fix For: 2.2
>
>
> We need BLAS implementation for local computations.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5278) BLAS implementation

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-5278:
-

[~chief],
Everything looks good. My only comment: {{CholeskyDecomposition#toDoubleArr}} - 
unnecessary double columns allocation.

> BLAS implementation
> ---
>
> Key: IGNITE-5278
> URL: https://issues.apache.org/jira/browse/IGNITE-5278
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Affects Versions: 2.1
>Reporter: Yury Babak
>Assignee: Yury Babak
>  Labels: ml
> Fix For: 2.2
>
>
> We need BLAS implementation for local computations.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5278) BLAS implementation

[Yury Babak (JIRA)]

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

Yury Babak commented on IGNITE-5278:


[~isapego] Could you take a look on this?

> BLAS implementation
> ---
>
> Key: IGNITE-5278
> URL: https://issues.apache.org/jira/browse/IGNITE-5278
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Affects Versions: 2.1
>Reporter: Yury Babak
>Assignee: Yury Babak
>  Labels: ml
> Fix For: 2.2
>
>
> We need BLAS implementation for local computations.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (IGNITE-4298) User exceptions cause IgniteException if Ignite services are deployed separately

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov closed IGNITE-4298.


> User exceptions cause IgniteException if Ignite services are deployed 
> separately
> 
>
> Key: IGNITE-4298
> URL: https://issues.apache.org/jira/browse/IGNITE-4298
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Ben
>
> 2 services, Service A and Service B, are deployed and restricted to 
> individual nodes. If A calls a method of B thru the service proxy and a user 
> exception is thrown inside that method, then an IgniteException is thrown due 
> to an InvocationTargetException. See code below for a reproducable example.
> {code:title=MyUserException.java|borderStyle=solid}
> package com.example.testing;
> public class MyUserException extends Throwable {}
> {code}
> {code:title=MyCounterService.java|borderStyle=solid}
> package com.example.testing;
> public interface MyCounterService {
> int increment() throws MyUserException;
> }
> {code}
> Note this error condition in the deployment of the two services: 
> {{ignite.cluster().forYoungest()}}
> {code:title=MyCounterServiceImpl.java|borderStyle=solid}
> package com.example.testing;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteServices;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.resources.IgniteInstanceResource;
> import org.apache.ignite.services.Service;
> import org.apache.ignite.services.ServiceContext;
> public class MyCounterServiceImpl implements MyCounterService, Service {
> @IgniteInstanceResource
> private Ignite ignite;
> private int value = 0;
> public int increment() throws MyUserException {
> if ((value % 2) == 0) {
> throw new MyUserException();
> } else {
> value++;
> }
> return value;
> }
> public static void main(String [] args) {
> Ignite ignite = Ignition.start();
> IgniteServices svcs = ignite.services(ignite.cluster().forYoungest());
> svcs.deployNodeSingleton("MyCounterService", new 
> MyCounterServiceImpl());
> }
> @Override
> public void cancel(ServiceContext ctx) {
> System.out.println("Service cancelled");
> }
> @Override
> public void init(ServiceContext ctx) throws Exception {
> System.out.println("Service initialized");
> }
> @Override
> public void execute(ServiceContext ctx) throws Exception {
> System.out.println("Service running");
> }
> }
> {code}
> {code:title=MyCallerService.java|borderStyle=solid}
> package com.example.testing;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteException;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.resources.IgniteInstanceResource;
> import org.apache.ignite.services.Service;
> import org.apache.ignite.services.ServiceContext;
> public class MyCallerService implements Service {
> @IgniteInstanceResource
> private Ignite ignite;
> private Boolean stopped;
> public void run() {
> stopped = false;
> MyCounterService service = 
> ignite.services().serviceProxy("MyCounterService", MyCounterService.class, 
> false);
> while (!stopped)
> {
> try {
> Thread.sleep(500);
> service.increment();
> } catch (MyUserException e) {
> System.out.println("Got exception");
> //e.printStackTrace();
> } catch (InterruptedException e) {
> //e.printStackTrace();
> }
> catch (IgniteException e) {
> System.out.println("Got critial exception");
> // would print the actual user exception
> //e.getCause().getCause().getCause().printStackTrace();
> break;
> }
> }
> }
> public static void main(String [] args) {
> Ignite ignite = Ignition.start();
> 
> ignite.services(ignite.cluster().forYoungest()).deployNodeSingleton("MyCallerService",
>  new MyCallerService());
> }
> @Override
> public void cancel(ServiceContext ctx) {
> stopped = true;
> }
> @Override
> public void init(ServiceContext ctx) throws Exception {
> }
> @Override
> public void execute(ServiceContext ctx) throws Exception {
> run();
> }
> }
> {code}
> {code:title=Output of MyCounterServiceImpl|borderStyle=solid}
> [18:23:23] Ignite node started OK (id=c82df19c)
> [18:23:23] Topology snapshot [ver=1, servers=1, clients=0, CPUs=4, heap=3.5GB]
> Service initialized
> Service running
> [18:23:27] Topology snapshot [ver=2, servers=2, clients=0, CPUs=4, heap=7.0GB]
> Nov 17, 2016 6:23:28 PM 

[jira] [Resolved] (IGNITE-4298) User exceptions cause IgniteException if Ignite services are deployed separately

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov resolved IGNITE-4298.
--
Resolution: Duplicate

> User exceptions cause IgniteException if Ignite services are deployed 
> separately
> 
>
> Key: IGNITE-4298
> URL: https://issues.apache.org/jira/browse/IGNITE-4298
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Ben
>
> 2 services, Service A and Service B, are deployed and restricted to 
> individual nodes. If A calls a method of B thru the service proxy and a user 
> exception is thrown inside that method, then an IgniteException is thrown due 
> to an InvocationTargetException. See code below for a reproducable example.
> {code:title=MyUserException.java|borderStyle=solid}
> package com.example.testing;
> public class MyUserException extends Throwable {}
> {code}
> {code:title=MyCounterService.java|borderStyle=solid}
> package com.example.testing;
> public interface MyCounterService {
> int increment() throws MyUserException;
> }
> {code}
> Note this error condition in the deployment of the two services: 
> {{ignite.cluster().forYoungest()}}
> {code:title=MyCounterServiceImpl.java|borderStyle=solid}
> package com.example.testing;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteServices;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.resources.IgniteInstanceResource;
> import org.apache.ignite.services.Service;
> import org.apache.ignite.services.ServiceContext;
> public class MyCounterServiceImpl implements MyCounterService, Service {
> @IgniteInstanceResource
> private Ignite ignite;
> private int value = 0;
> public int increment() throws MyUserException {
> if ((value % 2) == 0) {
> throw new MyUserException();
> } else {
> value++;
> }
> return value;
> }
> public static void main(String [] args) {
> Ignite ignite = Ignition.start();
> IgniteServices svcs = ignite.services(ignite.cluster().forYoungest());
> svcs.deployNodeSingleton("MyCounterService", new 
> MyCounterServiceImpl());
> }
> @Override
> public void cancel(ServiceContext ctx) {
> System.out.println("Service cancelled");
> }
> @Override
> public void init(ServiceContext ctx) throws Exception {
> System.out.println("Service initialized");
> }
> @Override
> public void execute(ServiceContext ctx) throws Exception {
> System.out.println("Service running");
> }
> }
> {code}
> {code:title=MyCallerService.java|borderStyle=solid}
> package com.example.testing;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteException;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.resources.IgniteInstanceResource;
> import org.apache.ignite.services.Service;
> import org.apache.ignite.services.ServiceContext;
> public class MyCallerService implements Service {
> @IgniteInstanceResource
> private Ignite ignite;
> private Boolean stopped;
> public void run() {
> stopped = false;
> MyCounterService service = 
> ignite.services().serviceProxy("MyCounterService", MyCounterService.class, 
> false);
> while (!stopped)
> {
> try {
> Thread.sleep(500);
> service.increment();
> } catch (MyUserException e) {
> System.out.println("Got exception");
> //e.printStackTrace();
> } catch (InterruptedException e) {
> //e.printStackTrace();
> }
> catch (IgniteException e) {
> System.out.println("Got critial exception");
> // would print the actual user exception
> //e.getCause().getCause().getCause().printStackTrace();
> break;
> }
> }
> }
> public static void main(String [] args) {
> Ignite ignite = Ignition.start();
> 
> ignite.services(ignite.cluster().forYoungest()).deployNodeSingleton("MyCallerService",
>  new MyCallerService());
> }
> @Override
> public void cancel(ServiceContext ctx) {
> stopped = true;
> }
> @Override
> public void init(ServiceContext ctx) throws Exception {
> }
> @Override
> public void execute(ServiceContext ctx) throws Exception {
> run();
> }
> }
> {code}
> {code:title=Output of MyCounterServiceImpl|borderStyle=solid}
> [18:23:23] Ignite node started OK (id=c82df19c)
> [18:23:23] Topology snapshot [ver=1, servers=1, clients=0, CPUs=4, heap=3.5GB]
> Service initialized
> Service running
> [18:23:27] Topology snapshot [ver=2, servers=2, clients=0, CPUs=4, heap=7.0GB]

[jira] [Commented] (IGNITE-5278) BLAS implementation

[Artem Malykh (JIRA)]

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

Artem Malykh commented on IGNITE-5278:
--

[~chief] Looks fine for me.

> BLAS implementation
> ---
>
> Key: IGNITE-5278
> URL: https://issues.apache.org/jira/browse/IGNITE-5278
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Affects Versions: 2.1
>Reporter: Yury Babak
>Assignee: Yury Babak
>  Labels: ml
> Fix For: 2.2
>
>
> We need BLAS implementation for local computations.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (IGNITE-3893) void type is not part of 'primitiveMap' in IgniteUtils class , this is causing class not found exception for void.

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov resolved IGNITE-3893.
--
Resolution: Fixed

Fixed by the following commit:

Fixed ClassNotFoundException for void.class
2a3a565 Valentin Kulichenko  on 12.03.2016 at 
1:35

> void type is not part of 'primitiveMap' in IgniteUtils class , this is 
> causing class not found exception for void.
> --
>
> Key: IGNITE-3893
> URL: https://issues.apache.org/jira/browse/IGNITE-3893
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Affects Versions: 1.5.0.final
>Reporter: Benakaraj K S
>
> I am doing dynamic code generation inside IgniteCallable which i am 
> broadcasting to all the nodes(this is to achieve Dynamic pojo support for 
> IgniteCache) using bytebuddy , my dynamically generated pojo class has setter 
> methods with return type void,  I am getting ClassNotFoundException : void  
> while generating Dynamic pojo, when i debugged i got to know that the 
> problem(?) is that, void is not part of 'primitiveMap' in IgniteUtils class. 
> Is there a reason for not having it in this MAP?. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (IGNITE-3893) void type is not part of 'primitiveMap' in IgniteUtils class , this is causing class not found exception for void.

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov closed IGNITE-3893.


> void type is not part of 'primitiveMap' in IgniteUtils class , this is 
> causing class not found exception for void.
> --
>
> Key: IGNITE-3893
> URL: https://issues.apache.org/jira/browse/IGNITE-3893
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Affects Versions: 1.5.0.final
>Reporter: Benakaraj K S
>
> I am doing dynamic code generation inside IgniteCallable which i am 
> broadcasting to all the nodes(this is to achieve Dynamic pojo support for 
> IgniteCache) using bytebuddy , my dynamically generated pojo class has setter 
> methods with return type void,  I am getting ClassNotFoundException : void  
> while generating Dynamic pojo, when i debugged i got to know that the 
> problem(?) is that, void is not part of 'primitiveMap' in IgniteUtils class. 
> Is there a reason for not having it in this MAP?. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5817) Changing checksum calculation methods

[Oleg Ostanin (JIRA)]

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

Oleg Ostanin updated IGNITE-5817:
-
Fix Version/s: 2.2

> Changing checksum calculation methods
> -
>
> Key: IGNITE-5817
> URL: https://issues.apache.org/jira/browse/IGNITE-5817
> Project: Ignite
>  Issue Type: Bug
>Reporter: Oleg Ostanin
>Assignee: Oleg Ostanin
> Fix For: 2.2
>
>
> Neither sha1 nor md5 are trustful checksum calculation methods. We should be 
> switching to at least sha265 or higher.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5807) Fixing signing artifacts

[Oleg Ostanin (JIRA)]

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

Oleg Ostanin updated IGNITE-5807:
-
Fix Version/s: 2.2

> Fixing signing artifacts
> 
>
> Key: IGNITE-5807
> URL: https://issues.apache.org/jira/browse/IGNITE-5807
> Project: Ignite
>  Issue Type: Bug
>Reporter: Oleg Ostanin
>Assignee: Oleg Ostanin
> Fix For: 2.2
>
>
> We need to fix pom.xml file to allow gpg plugin to sign .zip artifacts after 
> assembly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5833) Changing maven goal from "install" to "package" for building from sources

[Oleg Ostanin (JIRA)]

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

Oleg Ostanin updated IGNITE-5833:
-
Fix Version/s: 2.2

> Changing maven goal from "install" to "package" for building from sources
> -
>
> Key: IGNITE-5833
> URL: https://issues.apache.org/jira/browse/IGNITE-5833
> Project: Ignite
>  Issue Type: Bug
>Reporter: Oleg Ostanin
>Assignee: Oleg Ostanin
> Fix For: 2.2
>
>
> Currently we need to run 'mvn clean install' to build Apache Ignite from 
> sources, otherwise we can not perform javadoc generation in the next build 
> step in DEVNOTES.txt. We need to fix this issue before next release.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5833) Changing maven goal from "install" to "package" for building from sources

[Oleg Ostanin (JIRA)]

Oleg Ostanin created IGNITE-5833:


 Summary: Changing maven goal from "install" to "package" for 
building from sources
 Key: IGNITE-5833
 URL: https://issues.apache.org/jira/browse/IGNITE-5833
 Project: Ignite
  Issue Type: Bug
Reporter: Oleg Ostanin
Assignee: Oleg Ostanin


Currently we need to run 'mvn clean install' to build Apache Ignite from 
sources, otherwise we can not perform javadoc generation in the next build step 
in DEVNOTES.txt. We need to fix this issue before next release.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5832) .NET: Support transaction continuation in another thread

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5832:
--

 Summary: .NET: Support transaction continuation in another thread
 Key: IGNITE-5832
 URL: https://issues.apache.org/jira/browse/IGNITE-5832
 Project: Ignite
  Issue Type: Sub-task
  Components: platforms
Reporter: Pavel Tupitsyn


Update API according to the parent task, add tests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-4887) Support transaction continuation in another thread

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-4887:
---
Summary: Support transaction continuation in another thread  (was: Support 
for starting transaction in another thread)

> Support transaction continuation in another thread
> --
>
> Key: IGNITE-4887
> URL: https://issues.apache.org/jira/browse/IGNITE-4887
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.9
>Reporter: Alexey Kuznetsov
>Assignee: Nikolay Izhikov
> Attachments: HangTest.txt
>
>
> Consider the following pseudo-code:
> {code:xml}
> IgniteTransactions transactions = ignite1.transactions();
> Transaction tx = startTransaction(transactions);
> cache.put("key1", 1);
> tx.stop();
> {code}
> And in another thread:
> {code:xml}
> transactions.txStart(tx);
> cache.put("key3", 3);
> cache.remove("key2");
> tx.commit();
> {code}
> The Api should be implemented , that let you continue transaction in another 
> thread.
> method stop() should mark the transaction as unavailable for further commit.
> method txStart() should resume the transaction. 
> reason behind the proposal :
> Consider the next scenario:
> we begin transaction, doing some changes and start async future that will be 
> able to introduce futher changes into transaction and commit it in the end.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5831) .NET: Support TransactionScopeAsyncFlowOption.Enabled in TransactionScope

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5831:
--

 Summary: .NET: Support TransactionScopeAsyncFlowOption.Enabled in 
TransactionScope
 Key: IGNITE-5831
 URL: https://issues.apache.org/jira/browse/IGNITE-5831
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
 Fix For: 2.3


IGNITE-4887 introduces support for async transaction continuations (start tx in 
one thread, perform async cache update, continue transaction in async 
continuation).

This should allow us to support {{TransactionScopeAsyncFlowOption.Enabled}} 
([msdn|https://msdn.microsoft.com/en-us/library/system.transactions.transactionscopeasyncflowoption(v=vs.110).aspx])
 with {{TransactionScope}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5830) Introduce cache start & stop order on cluster activation

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-5830:
--

PR: 2337

> Introduce cache start & stop order on cluster activation
> 
>
> Key: IGNITE-5830
> URL: https://issues.apache.org/jira/browse/IGNITE-5830
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.1
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
> Fix For: 2.2
>
>
> Some of the cache components can rely on system/utility caches during start 
> operation, but the order of cache start & stop on cluster activation is not 
> determined. So there can be situation that user cache was started first than 
> system cache and it can lead to unexpected problems.
> We should start system & utility caches in first order on cluster activation 
> and stop it in last order on cluster deactivation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5830) Introduce cache start & stop order on cluster activation

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-5830:
---

 Summary: Introduce cache start & stop order on cluster activation
 Key: IGNITE-5830
 URL: https://issues.apache.org/jira/browse/IGNITE-5830
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 2.1
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko
 Fix For: 2.2


Some of the cache components can rely on system/utility caches during start 
operation, but the order of cache start & stop on cluster activation is not 
determined. So there can be situation that user cache started first than system 
cache and it can lead to unexpected problems.
We should start system & utility caches in first order on cluster activation 
and stop it in last order on cluster deactivation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5830) Introduce cache start & stop order on cluster activation

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko updated IGNITE-5830:

Description: 
Some of the cache components can rely on system/utility caches during start 
operation, but the order of cache start & stop on cluster activation is not 
determined. So there can be situation that user cache was started first than 
system cache and it can lead to unexpected problems.
We should start system & utility caches in first order on cluster activation 
and stop it in last order on cluster deactivation.

  was:
Some of the cache components can rely on system/utility caches during start 
operation, but the order of cache start & stop on cluster activation is not 
determined. So there can be situation that user cache started first than system 
cache and it can lead to unexpected problems.
We should start system & utility caches in first order on cluster activation 
and stop it in last order on cluster deactivation.


> Introduce cache start & stop order on cluster activation
> 
>
> Key: IGNITE-5830
> URL: https://issues.apache.org/jira/browse/IGNITE-5830
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.1
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
> Fix For: 2.2
>
>
> Some of the cache components can rely on system/utility caches during start 
> operation, but the order of cache start & stop on cluster activation is not 
> determined. So there can be situation that user cache was started first than 
> system cache and it can lead to unexpected problems.
> We should start system & utility caches in first order on cluster activation 
> and stop it in last order on cluster deactivation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5747) GridCommonAbstractTest.startGridsMultiThreaded works very slowly if persistence is enabled

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-5747:
--

Merged

> GridCommonAbstractTest.startGridsMultiThreaded works very slowly if 
> persistence is enabled
> --
>
> Key: IGNITE-5747
> URL: https://issues.apache.org/jira/browse/IGNITE-5747
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Eduard Shangareev
>Assignee: Alexey Goncharuk
> Fix For: 2.1
>
>
> GridCommonAbstractTest.startGridsMultiThreaded takes 2 minutes for 4 nodes if 
> persistence is enabled because we wait for topology update in affinity, but 
> it's not working while cluster is not active.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5278) BLAS implementation

[Yury Babak (JIRA)]

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

Yury Babak commented on IGNITE-5278:


[~amalykh], I`ve made a few changes so please take a look.

> BLAS implementation
> ---
>
> Key: IGNITE-5278
> URL: https://issues.apache.org/jira/browse/IGNITE-5278
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Affects Versions: 2.1
>Reporter: Yury Babak
>Assignee: Yury Babak
>  Labels: ml
> Fix For: 2.2
>
>
> We need BLAS implementation for local computations.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5806) IgniteCache5 suite timed out, assertions in sessions close logic

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-5806:


[~agoncharuk], this fix is ok from the point of tests.
Cache 5 timed out because of [IGNITE-5759] and in once other test.

Could you please merge fix from https://github.com/apache/ignite/pull/2335 ?

> IgniteCache5 suite timed out, assertions in sessions close logic
> 
>
> Key: IGNITE-5806
> URL: https://issues.apache.org/jira/browse/IGNITE-5806
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Blocker
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
> Attachments: Ignite_2.0_Tests_Ignite_Cache_5_748.log.zip
>
>
> Ignite Cache 5 timeouts observed in master
> http://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteCache5_Ignite20Tests=%3Cdefault%3E=buildTypeStatusDiv
> Reproduced for builds 725, 740 and 748 
> Log contains assertion coming from 
> {code}
> !sesHolder.get().ended(store); 
> {code}
> at
> {noformat} [2017-07-21 
> 07:59:44,774][ERROR][sys-stripe-3-#117%cache.CacheSerializableTransactionsTest2%][G]
>  Failed to execute runnable.
>  
> java.lang.AssertionError
> at 
> org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.sessionEnd0(GridCacheStoreManagerAdapter.java:878)
> at 
> org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.loadFromStore(GridCacheStoreManagerAdapter.java:335)
> at 
> org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.load(GridCacheStoreManagerAdapter.java:282)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.readThrough(GridCacheMapEntry.java:445)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerGet0(GridCacheMapEntry.java:699)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerGet(GridCacheMapEntry.java:461)
> {noformat}
> First time assertion came from test 
> org.apache.ignite.internal.processors.cache.CacheSerializableTransactionsTest#testRandomOperations
> Assertion is reproducible locally. But test is considered passed



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-5806) IgniteCache5 suite timed out, assertions in sessions close logic

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov edited comment on IGNITE-5806 at 7/25/17 1:23 PM:
-

[~agoncharuk], this fix is ok from the point of tests - 80 failed tests (79 is 
average for master)
http://ci.ignite.apache.org/viewLog.html?buildId=738855=buildResultsDiv=Ignite20Tests_RunAll

Cache 5 timed out because of [IGNITE-5759] and in once other test.

Could you please merge fix from https://github.com/apache/ignite/pull/2335 ?


was (Author: dpavlov):
[~agoncharuk], this fix is ok from the point of tests.
Cache 5 timed out because of [IGNITE-5759] and in once other test.

Could you please merge fix from https://github.com/apache/ignite/pull/2335 ?

> IgniteCache5 suite timed out, assertions in sessions close logic
> 
>
> Key: IGNITE-5806
> URL: https://issues.apache.org/jira/browse/IGNITE-5806
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Blocker
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
> Attachments: Ignite_2.0_Tests_Ignite_Cache_5_748.log.zip
>
>
> Ignite Cache 5 timeouts observed in master
> http://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteCache5_Ignite20Tests=%3Cdefault%3E=buildTypeStatusDiv
> Reproduced for builds 725, 740 and 748 
> Log contains assertion coming from 
> {code}
> !sesHolder.get().ended(store); 
> {code}
> at
> {noformat} [2017-07-21 
> 07:59:44,774][ERROR][sys-stripe-3-#117%cache.CacheSerializableTransactionsTest2%][G]
>  Failed to execute runnable.
>  
> java.lang.AssertionError
> at 
> org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.sessionEnd0(GridCacheStoreManagerAdapter.java:878)
> at 
> org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.loadFromStore(GridCacheStoreManagerAdapter.java:335)
> at 
> org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.load(GridCacheStoreManagerAdapter.java:282)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.readThrough(GridCacheMapEntry.java:445)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerGet0(GridCacheMapEntry.java:699)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerGet(GridCacheMapEntry.java:461)
> {noformat}
> First time assertion came from test 
> org.apache.ignite.internal.processors.cache.CacheSerializableTransactionsTest#testRandomOperations
> Assertion is reproducible locally. But test is considered passed



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5278) BLAS implementation

[Yury Babak (JIRA)]

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

Yury Babak updated IGNITE-5278:
---
Issue Type: New Feature  (was: Sub-task)
Parent: (was: IGNITE-5114)

> BLAS implementation
> ---
>
> Key: IGNITE-5278
> URL: https://issues.apache.org/jira/browse/IGNITE-5278
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Affects Versions: 2.1
>Reporter: Yury Babak
>Assignee: Yury Babak
>  Labels: ml
> Fix For: 2.2
>
>
> We need BLAS implementation for local computations.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-4181) The several runs of ServicesExample causes NPE

[Dmitriy Sorokin (JIRA)]

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

Dmitriy Sorokin reassigned IGNITE-4181:
---

Assignee: Dmitriy Sorokin  (was: Andrey Kuznetsov)

> The several runs of ServicesExample causes NPE
> --
>
> Key: IGNITE-4181
> URL: https://issues.apache.org/jira/browse/IGNITE-4181
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.6, 1.7, 2.0
> Environment: Windows 10, Oracle JDK 7
>Reporter: Sergey Kozlov
>Assignee: Dmitriy Sorokin
>  Labels: newbie
> Fix For: 2.2
>
>
> 0. Open example project in IDEA
> 1. Start 2-3 {{ExampleNodeStartup}}
> 2. Run {{ServicesExample}} several times.
> Sometimes it causes NullPointerException:
> {noformat}
> Executing closure [mapSize=10]
> Service was cancelled: myNodeSingletonService
> [15:37:20,020][INFO ][srvc-deploy-#24%null%][GridServiceProcessor] Cancelled 
> service instance [name=myNodeSingletonService, 
> execId=88a92a4d-c1cb-4a9b-8930-c67ac7f42bf3]
> [15:37:20,032][INFO ][sys-#33%null%][GridCacheProcessor] Stopped cache: 
> myNodeSingletonService
> [15:37:20,033][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=10, 
> minorTopVer=4], evt=DISCOVERY_CUSTOM_EVT, 
> node=5faac72a-72ab-4277-9643-0e962973b3f4]
> [15:37:20,045][INFO ][sys-#39%null%][GridCacheProcessor] Stopped cache: 
> myClusterSingletonService
> [15:37:20,046][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=10, 
> minorTopVer=5], evt=DISCOVERY_CUSTOM_EVT, 
> node=478f1752-fdce-42c6-aef6-55a5f4c08d90]
> [15:37:20,062][INFO ][disco-event-worker-#20%null%][GridDiscoveryManager] 
> Node left topology: TcpDiscoveryNode 
> [id=4f9cbc67-d756-4c25-9ee4-aee6528da024, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
> 172.25.4.107, 2001:0:9d38:6ab8:34b2:9f3e:3c6f:269], 
> sockAddrs=[/2001:0:9d38:6ab8:34b2:9f3e:3c6f:269:0, /127.0.0.1:0, 
> /0:0:0:0:0:0:0:1:0, work-pc/172.25.4.107:0], discPort=0, order=10, 
> intOrder=7, lastExchangeTime=1478522239236, loc=false, 
> ver=1.7.3#20161107-sha1:5132ac87, isClient=true]
> [15:37:20,063][INFO ][disco-event-worker-#20%null%][GridDiscoveryManager] 
> Topology snapshot [ver=11, servers=3, clients=0, CPUs=8, heap=11.0GB]
> [15:37:20,064][INFO ][sys-#44%null%][GridCacheProcessor] Stopped cache: 
> myMultiService
> [15:37:20,066][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=10, 
> minorTopVer=6], evt=DISCOVERY_CUSTOM_EVT, 
> node=5faac72a-72ab-4277-9643-0e962973b3f4]
> [15:37:20,076][INFO ][exchange-worker-#23%null%][GridCacheProcessor] Started 
> cache [name=myClusterSingletonService, mode=PARTITIONED]
> [15:37:20,115][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=10, 
> minorTopVer=7], evt=DISCOVERY_CUSTOM_EVT, 
> node=478f1752-fdce-42c6-aef6-55a5f4c08d90]
> [15:37:20,121][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=11, 
> minorTopVer=0], evt=NODE_LEFT, node=4f9cbc67-d756-4c25-9ee4-aee6528da024]
> [15:37:20,133][INFO ][exchange-worker-#23%null%][GridCacheProcessor] Started 
> cache [name=myMultiService, mode=PARTITIONED]
> [15:37:20,135][ERROR][exchange-worker-#23%null%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=11, 
> minorTopVer=1], nodeId=5faac72a, evt=DISCOVERY_CUSTOM_EVT]
> java.lang.NullPointerException
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.initStartedCacheOnCoordinator(CacheAffinitySharedManager.java:743)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:413)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:565)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:448)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1447)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:745)
> 

[jira] [Updated] (IGNITE-5829) Writing entry contents to WAL only single time

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko updated IGNITE-5829:

Description: Currently we write entry contents 2 times: once in logical 
record and once again when we write data page update records. We should do that 
only once. In data page updates we can write only a reference to the logical 
update record but not the whole entry contents.  (was: Now we write entry 
contents 2 times: once in logical record and once again when we write data page 
update records. We should do that only once. In data page updates we can write 
only a reference to the logical update record but not the whole entry contents.)

> Writing entry contents to WAL only single time
> --
>
> Key: IGNITE-5829
> URL: https://issues.apache.org/jira/browse/IGNITE-5829
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.1
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
> Fix For: 2.2
>
>
> Currently we write entry contents 2 times: once in logical record and once 
> again when we write data page update records. We should do that only once. In 
> data page updates we can write only a reference to the logical update record 
> but not the whole entry contents.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5829) Writing entry contents to WAL only single time

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko updated IGNITE-5829:

Summary: Writing entry contents to WAL only single time  (was: Writing 
entry contents only single time)

> Writing entry contents to WAL only single time
> --
>
> Key: IGNITE-5829
> URL: https://issues.apache.org/jira/browse/IGNITE-5829
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.1
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
> Fix For: 2.2
>
>
> Now we write entry contents 2 times: once in logical record and once again 
> when we write data page update records. We should do that only once. In data 
> page updates we can write only a reference to the logical update record but 
> not the whole entry contents.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5802) Fix all wrong TODO comments in ML component

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5802:


Github user asfgit closed the pull request at:

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


> Fix all wrong TODO comments in ML component
> ---
>
> Key: IGNITE-5802
> URL: https://issues.apache.org/jira/browse/IGNITE-5802
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
>  Labels: ml
> Fix For: 2.2
>
>
> (i) 
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-TODOs
> {quote}It's mandatory to use related JIRA ticket number.{quote} 
> Not all TODOs in ML component comply with above rules, that must be fixed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5802) Fix all wrong TODO comments in ML component

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5802:


Looks good to me. Merged to master: {{131847203d55f4f3907a7ff62d53ff69345fa605}}

> Fix all wrong TODO comments in ML component
> ---
>
> Key: IGNITE-5802
> URL: https://issues.apache.org/jira/browse/IGNITE-5802
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
>  Labels: ml
> Fix For: 2.2
>
>
> (i) 
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-TODOs
> {quote}It's mandatory to use related JIRA ticket number.{quote} 
> Not all TODOs in ML component comply with above rules, that must be fixed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5770) Refactor PlatformProcessor to PlatformTarget mechanism

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5770:


Github user asfgit closed the pull request at:

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


> Refactor PlatformProcessor to PlatformTarget mechanism
> --
>
> Key: IGNITE-5770
> URL: https://issues.apache.org/jira/browse/IGNITE-5770
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.2
>
>
> {{PlatformProcessor}} has a number of methods that are called over JNI 
> ({{createCache}} and so on). All other JNI calls (for {{PlatformCache}}, etc) 
> go through {{PlatformTarget}} mechanism.
> To avoid code duplication in JNI and ThinClient code all platform calls 
> should use the same mechanism.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5770) Refactor PlatformProcessor to PlatformTarget mechanism

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5770:


Merged to master: {{bdc9e4b91403595c496a5fa4aca70228665feaaa}}

> Refactor PlatformProcessor to PlatformTarget mechanism
> --
>
> Key: IGNITE-5770
> URL: https://issues.apache.org/jira/browse/IGNITE-5770
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.2
>
>
> {{PlatformProcessor}} has a number of methods that are called over JNI 
> ({{createCache}} and so on). All other JNI calls (for {{PlatformCache}}, etc) 
> go through {{PlatformTarget}} mechanism.
> To avoid code duplication in JNI and ThinClient code all platform calls 
> should use the same mechanism.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5770) Refactor PlatformProcessor to PlatformTarget mechanism

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-5770:
-

[~ptupitsyn] everything looks good now. Ship it.

> Refactor PlatformProcessor to PlatformTarget mechanism
> --
>
> Key: IGNITE-5770
> URL: https://issues.apache.org/jira/browse/IGNITE-5770
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.2
>
>
> {{PlatformProcessor}} has a number of methods that are called over JNI 
> ({{createCache}} and so on). All other JNI calls (for {{PlatformCache}}, etc) 
> go through {{PlatformTarget}} mechanism.
> To avoid code duplication in JNI and ThinClient code all platform calls 
> should use the same mechanism.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5829) Writing entry contents only single time

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-5829:
---

 Summary: Writing entry contents only single time
 Key: IGNITE-5829
 URL: https://issues.apache.org/jira/browse/IGNITE-5829
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 2.1
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko
 Fix For: 2.2


Now we write entry contents 2 times: once in logical record and once again when 
we write data page update records. We should do that only once. In data page 
updates we can write only a reference to the logical update record but not the 
whole entry contents.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5802) Fix all wrong TODO comments in ML component

[Yury Babak (JIRA)]

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

Yury Babak commented on IGNITE-5802:


[~ptupitsyn] could you please review those changes?

> Fix all wrong TODO comments in ML component
> ---
>
> Key: IGNITE-5802
> URL: https://issues.apache.org/jira/browse/IGNITE-5802
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
>  Labels: ml
> Fix For: 2.2
>
>
> (i) 
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-TODOs
> {quote}It's mandatory to use related JIRA ticket number.{quote} 
> Not all TODOs in ML component comply with above rules, that must be fixed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5770) Refactor PlatformProcessor to PlatformTarget mechanism

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5770:


[~isapego] replied.

> Refactor PlatformProcessor to PlatformTarget mechanism
> --
>
> Key: IGNITE-5770
> URL: https://issues.apache.org/jira/browse/IGNITE-5770
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.2
>
>
> {{PlatformProcessor}} has a number of methods that are called over JNI 
> ({{createCache}} and so on). All other JNI calls (for {{PlatformCache}}, etc) 
> go through {{PlatformTarget}} mechanism.
> To avoid code duplication in JNI and ThinClient code all platform calls 
> should use the same mechanism.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5648) NOT NULL constraint support for CREATE TABLE operator

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5648:


GitHub user skalashnikov opened a pull request:

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

IGNITE-5648: SQL: Added support for NOT NULL constraint



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

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

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

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


commit 5942441972c5e549253522b4981cb3bbd62db329
Author: skalashnikov 
Date:   2017-07-13T17:12:06Z

IGNITE-5648: SQL: Added support for NOT NULL constraint

commit 658f5a35d437f8bf38ae61173513b324cbc0f72e
Author: skalashnikov 
Date:   2017-07-25T11:35:47Z

Merge branch 'master' of https://github.com/apache/ignite into ignite-5648




> NOT NULL constraint support for CREATE TABLE operator
> -
>
> Key: IGNITE-5648
> URL: https://issues.apache.org/jira/browse/IGNITE-5648
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Sergey Kalashnikov
> Fix For: 2.3
>
>
> This is an umbrella ticket intended to aggregate all the activities related 
> to {{NOT NULL}} constraint support for {{CREATE TABLE}} commands.
> {code}
> CREATE TABLE legs(legid INT NOT NULL);
> {code}
> Ignite must prevent setting {{legid}} to {{null}} value.
> The feature has to be supported for:
> * ODBC and JDBC drivers.
> * Native APIs (Java, .NET, C++)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5770) Refactor PlatformProcessor to PlatformTarget mechanism

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-5770:
-

[~ptupitsyn], please, find my comments in review.

> Refactor PlatformProcessor to PlatformTarget mechanism
> --
>
> Key: IGNITE-5770
> URL: https://issues.apache.org/jira/browse/IGNITE-5770
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.2
>
>
> {{PlatformProcessor}} has a number of methods that are called over JNI 
> ({{createCache}} and so on). All other JNI calls (for {{PlatformCache}}, etc) 
> go through {{PlatformTarget}} mechanism.
> To avoid code duplication in JNI and ThinClient code all platform calls 
> should use the same mechanism.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5802) Fix all wrong TODO comments in ML component

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5802:


GitHub user ybabak opened a pull request:

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

IGNITE-5802: Fix all wrong TODO comments in ML component

- Added related tickets to all TODOs.
- Fixed some inspection problems.

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

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

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

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


commit 7924881e14f62f1f0e49e8018338c4cedac17433
Author: Yury Babak 
Date:   2017-07-25T11:13:39Z

IGNITE-5802: Fix all wrong TODO comments in ML component
- Added related tickets to all TODOs.
- Fixed some inspection problems.




> Fix all wrong TODO comments in ML component
> ---
>
> Key: IGNITE-5802
> URL: https://issues.apache.org/jira/browse/IGNITE-5802
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
>  Labels: ml
> Fix For: 2.2
>
>
> (i) 
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-TODOs
> {quote}It's mandatory to use related JIRA ticket number.{quote} 
> Not all TODOs in ML component comply with above rules, that must be fixed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (IGNITE-5818) SQL: query with condition on affinity column works incorrect in some cases.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov resolved IGNITE-5818.
--
Resolution: Won't Fix

> SQL: query with condition on affinity column works incorrect in some cases.
> ---
>
> Key: IGNITE-5818
> URL: https://issues.apache.org/jira/browse/IGNITE-5818
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Andrew Mashenkov
> Attachments: DecimalKeyTest.java
>
>
> Looks like query optimization IGNITE-4509 [1] makes some kind of keys to be 
> compared incorrectly.
> E.g. Decimal key. PFA repro.
> [1] https://issues.apache.org/jira/browse/IGNITE-4509



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5818) SQL: query with condition on affinity column works incorrect in some cases.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-5818:
-
Fix Version/s: (was: 2.2)

> SQL: query with condition on affinity column works incorrect in some cases.
> ---
>
> Key: IGNITE-5818
> URL: https://issues.apache.org/jira/browse/IGNITE-5818
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Andrew Mashenkov
> Attachments: DecimalKeyTest.java
>
>
> Looks like query optimization IGNITE-4509 [1] makes some kind of keys to be 
> compared incorrectly.
> E.g. Decimal key. PFA repro.
> [1] https://issues.apache.org/jira/browse/IGNITE-4509



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5828) Decompositions refactoring

[Yury Babak (JIRA)]

Yury Babak created IGNITE-5828:
--

 Summary: Decompositions refactoring
 Key: IGNITE-5828
 URL: https://issues.apache.org/jira/browse/IGNITE-5828
 Project: Ignite
  Issue Type: Bug
  Components: ml
Reporter: Yury Babak


(?) Externalization for decompositions.
(?) QRDecomposition performance.
(?) EigenDecompositionTest - corner case failure.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5827) Benchmarks refactoring

[Yury Babak (JIRA)]

Yury Babak created IGNITE-5827:
--

 Summary: Benchmarks refactoring
 Key: IGNITE-5827
 URL: https://issues.apache.org/jira/browse/IGNITE-5827
 Project: Ignite
  Issue Type: Bug
  Components: ml
Reporter: Yury Babak


See MathBenchmark.java and VectorBenchmarkTest.java



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5826) OLS refactoring

[Yury Babak (JIRA)]

Yury Babak created IGNITE-5826:
--

 Summary: OLS refactoring
 Key: IGNITE-5826
 URL: https://issues.apache.org/jira/browse/IGNITE-5826
 Project: Ignite
  Issue Type: Bug
  Components: ml
Reporter: Yury Babak


(?) Copying.
(?) Incremental formula.
(?) Tests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5298) .NET: DML update via LINQ

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5298:


Yes, please go ahead, [~GuruStron]!

> .NET: DML update via LINQ
> -
>
> Key: IGNITE-5298
> URL: https://issues.apache.org/jira/browse/IGNITE-5298
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Sergey Stronchinskiy
>  Labels: .NET, LINQ, important
>
> Bulk update with LINQ:
> {code}
> var persons = ignite.GetCache("persons").AsCacheQueryable();
> int affectedRows = persons.Where(x => x.Key > 10).UpdateAll(x => 
> x.Value.OrgId = 7);
> {code}
> See bulk delete with {{RemoveAll}}, IGNITE-4904.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5818) SQL: query with condition on affinity column works incorrect in some cases.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-5818:
--

Using {{double}} constructor without rounding also error prone.
I've got your point. This won't be supported and ticket can be closed.

[~dmagda],
should we update our docs to show users examples of good and bad practice of 
choosing key types?

> SQL: query with condition on affinity column works incorrect in some cases.
> ---
>
> Key: IGNITE-5818
> URL: https://issues.apache.org/jira/browse/IGNITE-5818
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Andrew Mashenkov
> Fix For: 2.2
>
> Attachments: DecimalKeyTest.java
>
>
> Looks like query optimization IGNITE-4509 [1] makes some kind of keys to be 
> compared incorrectly.
> E.g. Decimal key. PFA repro.
> [1] https://issues.apache.org/jira/browse/IGNITE-4509



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-5769) Abstract away .NET->Java calls

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-5769 at 7/25/17 10:32 AM:
--

{{IPlatformTarget}} looks like a good abstraction point. We can refactor the 
code to interact with Java solely via {{IPlatformTarget}}, and provide multiple 
implementations (for JNI and RPC).

* Split {{PlatformTarget}} into {{PlatformTargetAdapter}} (to inherit from) and 
{{PlatformJniTarget}} (which implements {{IPlatformTarget}})
* {{PlatformTargetAdapter}} takes {{IPlatformTarget}} in constructor instead of 
{{IUnmanagedTarget}}


was (Author: ptupitsyn):
{{IPlatformTarget}} looks like a good abstraction point. We can refactor the 
code to interact with Java solely via {{IPlatformTarget}}, and provide multiple 
implementations (for JNI and RPC).

> Abstract away .NET->Java calls
> --
>
> Key: IGNITE-5769
> URL: https://issues.apache.org/jira/browse/IGNITE-5769
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
>
> All JNI interaction goes through static {{UnmanagedUtils}} calls. This should 
> be refactored so that unmanaged call mechanism can be replaced with something 
> else for each particular node.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5298) .NET: DML update via LINQ

[Sergey Stronchinskiy (JIRA)]

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

Sergey Stronchinskiy commented on IGNITE-5298:
--

[~ptupitsyn],

??We may add another one as a separate task later??

Actually I thought about this too, that for now implement only more general 
approach and later in separate task the initializer syntax. 

So I will start implementation with {{IUpdateDescriptor}} approach(if you don't 
see any better name for it :) )

> .NET: DML update via LINQ
> -
>
> Key: IGNITE-5298
> URL: https://issues.apache.org/jira/browse/IGNITE-5298
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Sergey Stronchinskiy
>  Labels: .NET, LINQ, important
>
> Bulk update with LINQ:
> {code}
> var persons = ignite.GetCache("persons").AsCacheQueryable();
> int affectedRows = persons.Where(x => x.Key > 10).UpdateAll(x => 
> x.Value.OrgId = 7);
> {code}
> See bulk delete with {{RemoveAll}}, IGNITE-4904.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5825) K-Means refactoring

[Yury Babak (JIRA)]

Yury Babak created IGNITE-5825:
--

 Summary: K-Means refactoring
 Key: IGNITE-5825
 URL: https://issues.apache.org/jira/browse/IGNITE-5825
 Project: Ignite
  Issue Type: Bug
  Components: ml
Reporter: Yury Babak


Improve performance of points copying.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-5818) SQL: query with condition on affinity column works incorrect in some cases.

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko edited comment on IGNITE-5818 at 7/25/17 10:25 AM:
---

[~amashenkov]
In fact, it *does* work correctly.

Things go like this in this case:

1. {{new BigDecimal(8.3)}}, {{new BigDecimal("8.3")}} and {{new 
BigDecimal("8.30")}} are *all* different objects (i.e. have different hash 
codes and thus obviously are not "equal" in Java terms) - see [1], [2].

2. Ignite's affinity machinery relies on hash codes.

3. H2's {{BigDecimal}} comparison relies on {{compareTo}}, not on {{equals}}, 
therefore objects that are not equal from Java objects' standpoint *may* be 
equal from the point of {{BigDecimal}}'s inner representation - that's why your 
check passes when {{ID}} column is compared, as in this case no partitions 
prediction is done because {{_key}} column is not involved, and all nodes (or, 
as in your test, the only node) receive data request.

Per p. 1 and 2, the test fails absolutely right, *it should not pass* because 
the objects are *different*. To avoid confusion here, the best is just to avoid 
messing with {{_key}} column.

Another workaround would be to avoid {{String}} constructor and pass {{double}} 
instead - probably parsed from a {{String}}, but you'd have to be careful about 
precision in this case - please see [1] and [2] again.

Probably we should make that partitions detection optimization optional and 
turnable off. I'd like to hear [~vozerov] on this.

[1] 
https://stackoverflow.com/questions/3693014/bigdecimal-from-double-incorrect-value
[2] 
https://stackoverflow.com/questions/12395281/convert-double-to-bigdecimal-and-set-bigdecimal-precision


was (Author: al.psc):
[~amashenkov]
In fact, it *does* work correctly.

Things go like this in this case:

1. {{new BigDecimal(8.3)}}, {{new BigDecimal("8.3")}} and {{new 
BigDecimal("8.30")}} are *all* different objects (i.e. have different hash 
codes and thus obviously are not "equal" in Java terms) - see [1], [2].

2. Ignite's affinity machinery relies on hash codes.

3. H2's {{BigDecimal}} comparison relies on {{compareTo}}, not on {{equals}}, 
therefore objects that are not equal from Java objects' standpoint *may* be 
equal from the point of {{BigDecimal}}'s inner representation - that's why your 
check passes when {{ID}} column is compared, as in this case no partitions 
prediction is done because {{_key}} column is not involved, and all nodes (or, 
as in your test, the only node) receive data request.

Per p. 1 and 2, the test fails absolutely right, *it should not pass* because 
the objects are *different*. To avoid confusion here, the best is just to avoid 
messing with {{_key}} column.

Another workaround would be to avoid {{String}} constructor and pass {{double}} 
instead - probably parsed from a {{String}}.

Probably we should make that partitions detection optimization optional and 
turnable off. I'd like to hear [~vozerov] on this.

[1] 
https://stackoverflow.com/questions/3693014/bigdecimal-from-double-incorrect-value
[2] 
https://stackoverflow.com/questions/12395281/convert-double-to-bigdecimal-and-set-bigdecimal-precision

> SQL: query with condition on affinity column works incorrect in some cases.
> ---
>
> Key: IGNITE-5818
> URL: https://issues.apache.org/jira/browse/IGNITE-5818
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Andrew Mashenkov
> Fix For: 2.2
>
> Attachments: DecimalKeyTest.java
>
>
> Looks like query optimization IGNITE-4509 [1] makes some kind of keys to be 
> compared incorrectly.
> E.g. Decimal key. PFA repro.
> [1] https://issues.apache.org/jira/browse/IGNITE-4509



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-5818) SQL: query with condition on affinity column works incorrect in some cases.

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko edited comment on IGNITE-5818 at 7/25/17 10:22 AM:
---

[~amashenkov]
In fact, it *does* work correctly.

Things go like this in this case:

1. {{new BigDecimal(8.3)}}, {{new BigDecimal("8.3")}} and {{new 
BigDecimal("8.30")}} are *all* different objects (i.e. have different hash 
codes and thus obviously are not "equal" in Java terms) - see [1], [2].

2. Ignite's affinity machinery relies on hash codes.

3. H2's {{BigDecimal}} comparison relies on {{compareTo}}, not on {{equals}}, 
therefore objects that are not equal from Java objects' standpoint *may* be 
equal from the point of {{BigDecimal}}'s inner representation - that's why your 
check passes when {{ID}} column is compared, as in this case no partitions 
prediction is done because {{_key}} column is not involved, and all nodes (or, 
as in your test, the only node) receive data request.

Per p. 1 and 2, the test fails absolutely right, *it should not pass* because 
the objects are *different*. To avoid confusion here, the best is just to avoid 
messing with {{_key}} column.

Another workaround would be to avoid {{String}} constructor and pass {{double}} 
instead - probably parsed from a {{String}}.

Probably we should make that partitions detection optimization optional and 
turnable off. I'd like to hear [~vozerov] on this.

[1] 
https://stackoverflow.com/questions/3693014/bigdecimal-from-double-incorrect-value
[2] 
https://stackoverflow.com/questions/12395281/convert-double-to-bigdecimal-and-set-bigdecimal-precision


was (Author: al.psc):
In fact, it *does* work correctly.

Things go like this in this case:

1. {{new BigDecimal(8.3)}}, {{new BigDecimal("8.3")}} and {{new 
BigDecimal("8.30")}} are *all* different objects (i.e. have different hash 
codes and thus obviously are not "equal" in Java terms) - see [1], [2].

2. Ignite's affinity machinery relies on hash codes.

3. H2's {{BigDecimal}} comparison relies on {{compareTo}}, not on {{equals}}, 
therefore objects that are not equal from Java objects' standpoint *may* be 
equal from the point of {{BigDecimal}}'s inner representation - that's why your 
check passes when {{ID}} column is compared, as in this case no partitions 
prediction is done because {{_key}} column is not involved, and all nodes (or, 
as in your test, the only node) receive data request.

Per p. 1 and 2, the test fails absolutely right, *it should not pass* because 
the objects are *different*. To avoid confusion here, the best is just to avoid 
messing with {{_key}} column.

Probably we should make that partitions detection optimization optional and 
turnable off. I'd like to hear [~vozerov] on this.

> SQL: query with condition on affinity column works incorrect in some cases.
> ---
>
> Key: IGNITE-5818
> URL: https://issues.apache.org/jira/browse/IGNITE-5818
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Andrew Mashenkov
> Fix For: 2.2
>
> Attachments: DecimalKeyTest.java
>
>
> Looks like query optimization IGNITE-4509 [1] makes some kind of keys to be 
> compared incorrectly.
> E.g. Decimal key. PFA repro.
> [1] https://issues.apache.org/jira/browse/IGNITE-4509



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5824) Adjust precision in math unit tests.

[Yury Babak (JIRA)]

Yury Babak created IGNITE-5824:
--

 Summary: Adjust precision in math unit tests.
 Key: IGNITE-5824
 URL: https://issues.apache.org/jira/browse/IGNITE-5824
 Project: Ignite
  Issue Type: Bug
  Components: ml
Reporter: Yury Babak


Find which precision is sufficient for math related tests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5818) SQL: query with condition on affinity column works incorrect in some cases.

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko commented on IGNITE-5818:
-

In fact, it *does* work correctly.

Things go like this in this case:

1. {{new BigDecimal(8.3)}}, {{new BigDecimal("8.3")}} and {{new 
BigDecimal("8.30")}} are *all* different objects (i.e. have different hash 
codes and thus obviously are not "equal" in Java terms) - see [1], [2].

2. Ignite's affinity machinery relies on hash codes.

3. H2's {{BigDecimal}} comparison relies on {{compareTo}}, not on {{equals}}, 
therefore objects that are not equal from Java objects' standpoint *may* be 
equal from the point of {{BigDecimal}}'s inner representation - that's why your 
check passes when {{ID}} column is compared, as in this case no partitions 
prediction is done because {{_key}} column is not involved, and all nodes (or, 
as in your test, the only node) receive data request.

Per p. 1 and 2, the test fails absolutely right, *it should not pass* because 
the objects are *different*. To avoid confusion here, the best is just to avoid 
messing with {{_key}} column.

Probably we should make that partitions detection optimization optional and 
turnable off. I'd like to hear [~vozerov] on this.

> SQL: query with condition on affinity column works incorrect in some cases.
> ---
>
> Key: IGNITE-5818
> URL: https://issues.apache.org/jira/browse/IGNITE-5818
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Andrew Mashenkov
> Fix For: 2.2
>
> Attachments: DecimalKeyTest.java
>
>
> Looks like query optimization IGNITE-4509 [1] makes some kind of keys to be 
> compared incorrectly.
> E.g. Decimal key. PFA repro.
> [1] https://issues.apache.org/jira/browse/IGNITE-4509



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5769) Abstract away .NET->Java calls

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5769:


{{IPlatformTarget}} looks like a good abstraction point. We can refactor the 
code to interact with Java solely via {{IPlatformTarget}}, and provide multiple 
implementations (for JNI and RPC).

> Abstract away .NET->Java calls
> --
>
> Key: IGNITE-5769
> URL: https://issues.apache.org/jira/browse/IGNITE-5769
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
>
> All JNI interaction goes through static {{UnmanagedUtils}} calls. This should 
> be refactored so that unmanaged call mechanism can be replaced with something 
> else for each particular node.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5814) Service deploy fails with NPE if it implements ExecutorService interface

[Vyacheslav Koptilin (JIRA)]

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

Vyacheslav Koptilin reassigned IGNITE-5814:
---

Assignee: Vyacheslav Koptilin

> Service deploy fails with NPE if it implements ExecutorService interface
> 
>
> Key: IGNITE-5814
> URL: https://issues.apache.org/jira/browse/IGNITE-5814
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Evgenii Zhuravlev
>Assignee: Vyacheslav Koptilin
>
> Caused by: class org.apache.ignite.IgniteCheckedException: null
>   at 
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7239)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:170)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:119)
>   at 
> org.apache.ignite.internal.AsyncSupportAdapter.saveOrGet(AsyncSupportAdapter.java:112)
>   at 
> org.apache.ignite.internal.IgniteServicesImpl.deployNodeSingleton(IgniteServicesImpl.java:83)
>   ... 6 more
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.ignite.internal.processors.resource.GridResourceProcessor.inject(GridResourceProcessor.java:244)
>   at 
> org.apache.ignite.internal.processors.resource.GridResourceProcessor.inject(GridResourceProcessor.java:227)
>   at 
> org.apache.ignite.internal.processors.resource.GridResourceProcessor.injectGeneric(GridResourceProcessor.java:208)
>   at 
> org.apache.ignite.internal.processors.resource.GridResourceProcessor.inject(GridResourceProcessor.java:487)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.copyAndInject(GridServiceProcessor.java:1188)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.redeploy(GridServiceProcessor.java:1107)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.processAssignment(GridServiceProcessor.java:1758)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.onSystemCacheUpdated(GridServiceProcessor.java:1435)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.access$300(GridServiceProcessor.java:118)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor$ServiceEntriesListener$1.run0(GridServiceProcessor.java:1402)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor$BusyRunnable.run(GridServiceProcessor.java:1805)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5811) Detect internal Ignite problems (java-level deadlock, hangs, etc) and act according to a policy configured.

[Yakov Zhdanov (JIRA)]

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

Yakov Zhdanov updated IGNITE-5811:
--
Description: 
This has something in common with segmentation policy we currently have. User 
should get notified on a deadlock problem and node should take an action (stop 
by default).

Also Ignite may react on internal errors and hangs in the same way - fire event 
and take the appropriate action.

Current list of cases when node should (by default) stop itself:
# Discovery reports segmentation (already implemented)
# Critical discovery thread fails (already implemented)
# NIO communication thread fails (already implemented)

The following needs to be added
# Java-deadlock detected
# Internal threads stuck (no progress on current tasks during defined period)
# ExchangeWorker exits with error

We need to reapproach handling for all situations above to use the same 
mechanism and make node take the action according to a configured policy

  was:
This has something in common with segmentation policy we currently have. User 
should get notified on a deadlock problem and node should take an action (stop 
by default).

Also Ignite may react on internal errors and hangs in the same way - fire event 
and take the appropriate action.

Current list of cases when node should (by default) stop itself:
# Discovery reports segmentation (already implemented)
# Critical discovery thread fails (already implemented)
# NIO communication thread fails (already implemented)

The following needs to be added
# Java-deadlock detected
#   


> Detect internal Ignite problems (java-level deadlock, hangs, etc) and act 
> according to a policy configured.
> ---
>
> Key: IGNITE-5811
> URL: https://issues.apache.org/jira/browse/IGNITE-5811
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Yakov Zhdanov
>  Labels: usability
>
> This has something in common with segmentation policy we currently have. User 
> should get notified on a deadlock problem and node should take an action 
> (stop by default).
> Also Ignite may react on internal errors and hangs in the same way - fire 
> event and take the appropriate action.
> Current list of cases when node should (by default) stop itself:
> # Discovery reports segmentation (already implemented)
> # Critical discovery thread fails (already implemented)
> # NIO communication thread fails (already implemented)
> The following needs to be added
> # Java-deadlock detected
> # Internal threads stuck (no progress on current tasks during defined period)
> # ExchangeWorker exits with error
> We need to reapproach handling for all situations above to use the same 
> mechanism and make node take the action according to a configured policy



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5811) Detect internal Ignite problems (java-level deadlock, hangs, etc) and act according to a policy configured.

[Yakov Zhdanov (JIRA)]

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

Yakov Zhdanov updated IGNITE-5811:
--
Summary: Detect internal Ignite problems (java-level deadlock, hangs, etc) 
and act according to a policy configured.  (was: Detect java-level deadlock and 
act according to a policy configured.)

> Detect internal Ignite problems (java-level deadlock, hangs, etc) and act 
> according to a policy configured.
> ---
>
> Key: IGNITE-5811
> URL: https://issues.apache.org/jira/browse/IGNITE-5811
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Yakov Zhdanov
>  Labels: usability
>
> This has something in common with segmentation policy we currently have. User 
> should get notified on a deadlock problem and node should take an action 
> (stop by default).
> Also Ignite may react on internal errors and hangs in the same way - fire 
> event and take the appropriate action.
> Current list of cases when node should (by default) stop itself:
> # Discovery reports segmentation (already implemented)
> # Critical discovery thread fails (already implemented)
> # NIO communication thread fails (already implemented)
> The following needs to be added
> # Java-deadlock detected
> #   



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5811) Detect java-level deadlock and act according to a policy configured.

[Yakov Zhdanov (JIRA)]

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

Yakov Zhdanov updated IGNITE-5811:
--
Description: 
This has something in common with segmentation policy we currently have. User 
should get notified on a deadlock problem and node should take an action (stop 
by default).

Also Ignite may react on internal errors and hangs in the same way - fire event 
and take the appropriate action.

Current list of cases when node should (by default) stop itself:
# Discovery reports segmentation (already implemented)
# Critical discovery thread fails (already implemented)
# NIO communication thread fails (already implemented)

The following needs to be added
# Java-deadlock detected
#   

  was:
This has something in common with segmentation policy we currently have. User 
should get notified on a deadlock problem and node should take an action (stop 
by default).

Also Ignite may react on internal errors and hangs in the same way - fire event 
and take the appropriate action.


> Detect java-level deadlock and act according to a policy configured.
> 
>
> Key: IGNITE-5811
> URL: https://issues.apache.org/jira/browse/IGNITE-5811
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Yakov Zhdanov
>  Labels: usability
>
> This has something in common with segmentation policy we currently have. User 
> should get notified on a deadlock problem and node should take an action 
> (stop by default).
> Also Ignite may react on internal errors and hangs in the same way - fire 
> event and take the appropriate action.
> Current list of cases when node should (by default) stop itself:
> # Discovery reports segmentation (already implemented)
> # Critical discovery thread fails (already implemented)
> # NIO communication thread fails (already implemented)
> The following needs to be added
> # Java-deadlock detected
> #   



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5811) Detect java-level deadlock and act according to a policy configured.

[Yakov Zhdanov (JIRA)]

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

Yakov Zhdanov updated IGNITE-5811:
--
Description: 
This has something in common with segmentation policy we currently have. User 
should get notified on a deadlock problem and node should take an action (stop 
by default).

Also Ignite may react on internal errors and hangs in the same way - fire event 
and take the appropriate action.

  was:This has something in common with segmentation policy we currently have. 
User should get notified on a deadlock problem and node should take an action 
(stop by default)


> Detect java-level deadlock and act according to a policy configured.
> 
>
> Key: IGNITE-5811
> URL: https://issues.apache.org/jira/browse/IGNITE-5811
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Yakov Zhdanov
>  Labels: usability
>
> This has something in common with segmentation policy we currently have. User 
> should get notified on a deadlock problem and node should take an action 
> (stop by default).
> Also Ignite may react on internal errors and hangs in the same way - fire 
> event and take the appropriate action.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (IGNITE-5820) Implement ability to set auto adjust height of modal

[Andrey Novikov (JIRA)]

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

Andrey Novikov closed IGNITE-5820.
--
Assignee: Alexey Kuznetsov  (was: Andrey Novikov)

> Implement ability to set auto adjust height of modal
> 
>
> Key: IGNITE-5820
> URL: https://issues.apache.org/jira/browse/IGNITE-5820
> Project: Ignite
>  Issue Type: Improvement
>  Components: UI, wizards
>Reporter: Dmitriy Shabalin
>Assignee: Alexey Kuznetsov
> Fix For: 2.2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5823) Need to remove CacheAtomicUpdateTimeoutException

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-5823:
-

 Summary: Need to remove CacheAtomicUpdateTimeoutException
 Key: IGNITE-5823
 URL: https://issues.apache.org/jira/browse/IGNITE-5823
 Project: Ignite
  Issue Type: Task
Reporter: Yakov Zhdanov
Priority: Minor


And releated - CacheAtomicUpdateTimeoutCheckedException

These exceptions are not used any more and can be removed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5818) SQL: query with condition on affinity column works incorrect in some cases.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-5818:
-
Affects Version/s: 2.1

> SQL: query with condition on affinity column works incorrect in some cases.
> ---
>
> Key: IGNITE-5818
> URL: https://issues.apache.org/jira/browse/IGNITE-5818
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Andrew Mashenkov
> Fix For: 2.2
>
> Attachments: DecimalKeyTest.java
>
>
> Looks like query optimization IGNITE-4509 [1] makes some kind of keys to be 
> compared incorrectly.
> E.g. Decimal key. PFA repro.
> [1] https://issues.apache.org/jira/browse/IGNITE-4509



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5822) Abstract away Java->.NET calls

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5822:
--

 Summary: Abstract away Java->.NET calls
 Key: IGNITE-5822
 URL: https://issues.apache.org/jira/browse/IGNITE-5822
 Project: Ignite
  Issue Type: Sub-task
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.2


All calls from Java to platform go through static {{PlatformCallbackUtils}}. 
For thin client we are interested in {{inLongOutLong}} and 
{{inLongLongLongObjectOutLong}} only; these two should be abstracted in some 
way so we can replace JNI with RPC when needed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5809) SQL: Add precision and scale support for table fields.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-5809:
-
Issue Type: New Feature  (was: Bug)

> SQL: Add precision and scale support for table fields.
> --
>
> Key: IGNITE-5809
> URL: https://issues.apache.org/jira/browse/IGNITE-5809
> Project: Ignite
>  Issue Type: New Feature
>  Components: sql
>Reporter: Andrew Mashenkov
> Fix For: 2.3
>
> Attachments: DecimalPrecisionSqlTest.java
>
>
> PFA test.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5769) Abstract away .NET->Java calls

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-5769:
---
Summary: Abstract away .NET->Java calls  (was: Abstract away unmanaged 
calls)

> Abstract away .NET->Java calls
> --
>
> Key: IGNITE-5769
> URL: https://issues.apache.org/jira/browse/IGNITE-5769
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
>
> All JNI interaction goes through static {{UnmanagedUtils}} calls. This should 
> be refactored so that unmanaged call mechanism can be replaced with something 
> else for each particular node.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (IGNITE-5734) Web Console: update npm dependensies

[Andrey Novikov (JIRA)]

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

Andrey Novikov closed IGNITE-5734.
--
Assignee: Alexey Kuznetsov  (was: Andrey Novikov)

> Web Console: update npm dependensies
> 
>
> Key: IGNITE-5734
> URL: https://issues.apache.org/jira/browse/IGNITE-5734
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 2.2
>
>
> Before major release we can update npm dependencies.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5820) Implement ability to set auto adjust height of modal

[Dmitriy Shabalin (JIRA)]

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

Dmitriy Shabalin reassigned IGNITE-5820:


Assignee: Andrey Novikov  (was: Dmitriy Shabalin)

[~anovikov] added improvement, pls review it

> Implement ability to set auto adjust height of modal
> 
>
> Key: IGNITE-5820
> URL: https://issues.apache.org/jira/browse/IGNITE-5820
> Project: Ignite
>  Issue Type: Improvement
>  Components: UI, wizards
>Reporter: Dmitriy Shabalin
>Assignee: Andrey Novikov
> Fix For: 2.2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5821) Implement fuzzy checkpoints

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-5821:


 Summary: Implement fuzzy checkpoints
 Key: IGNITE-5821
 URL: https://issues.apache.org/jira/browse/IGNITE-5821
 Project: Ignite
  Issue Type: New Feature
  Components: persistence
Affects Versions: 2.1
Reporter: Alexey Goncharuk
 Fix For: 2.2


Currently, we are able to run only sharp checkpoints (all committed 
transactions are in the checkpoint, all non-committed are not included, all 
data structures are fully consistent).
This has the following disadvantages:

1) All transactions are blocked for the markCheckpointBegin call
2) We have an additional overhead for checkpoint COW buffer
3) If checkpoint buffer is exhausted, we block all transactions and 
synchronously wait for the checkpoint to be finished.

There is a technique called fuzzy checkpoints:
1) We keep a WAL LSN in every dirty page
2) When a page is being flushed to disk, we sync WAL up to the LSN
3) We maintain checkpoint low watermark so that WAL does not grow indefinitely
4) WAL logging is changed in a way that does not allow data structures updates 
to be mixed in WAL
5) The recovery procedure is changed to apply all physical deltas up to the end 
of WAL and have consistent memory state, then logical records revert all 
non-committed transactions



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5820) Implement ability to set auto adjust height of modal

[Dmitriy Shabalin (JIRA)]

Dmitriy Shabalin created IGNITE-5820:


 Summary: Implement ability to set auto adjust height of modal
 Key: IGNITE-5820
 URL: https://issues.apache.org/jira/browse/IGNITE-5820
 Project: Ignite
  Issue Type: Improvement
  Components: UI, wizards
Reporter: Dmitriy Shabalin
Assignee: Dmitriy Shabalin
 Fix For: 2.2






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5734) Web Console: update npm dependensies

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko commented on IGNITE-5734:
---

Tested. Problems not found.

> Web Console: update npm dependensies
> 
>
> Key: IGNITE-5734
> URL: https://issues.apache.org/jira/browse/IGNITE-5734
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Andrey Novikov
> Fix For: 2.2
>
>
> Before major release we can update npm dependencies.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)