[jira] [Assigned] (IGNITE-5302) Empty LOST partition may be used as OWNING after resetting lost partitions

2018-11-15 Thread Pavel Pereslegin (JIRA)


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

Pavel Pereslegin reassigned IGNITE-5302:


Assignee: Pavel Pereslegin

> Empty LOST partition may be used as OWNING after resetting lost partitions
> --
>
> Key: IGNITE-5302
> URL: https://issues.apache.org/jira/browse/IGNITE-5302
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Pavel Pereslegin
>Priority: Blocker
>  Labels: MakeTeamcityGreenAgain, Muted_test, test-fail
> Fix For: 2.8
>
>
> h2. Notes
> Test *testPartitionLossAndRecover* reproducing the issue can be found in 
> ignite-5267 branch with PDS functionality.
> h2. Steps to reproduce
> # Four nodes are started, some key is added to partitioned cache
> # Primary and backup nodes for the key are stopped, key's partition is 
> declared LOST on remaining nodes
> # Primary and backup nodes are started again, cache's lost partitions are 
> reset
> # Key is requested from cache
> h2. Expected behavior
> Correct value is returned from primary for this partition
> h2. Actual behavior
> Request for value is sent to node where partition is empty (not to primary 
> node), null is returned
> h2. Latest findings
> # The main problem with the scenario is that request for key gets mapped not 
> only to P/B nodes with real value but also to the node where that partition 
> existed only in LOST state after P/B shutdown on step #2
> # It was found that on step #3 after primary and backup are joined partition 
> counter is increased for empty partition in LOST state which looks wrong



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-9525) Ignite + Informatica Integration

2018-11-15 Thread Artem Budnikov (JIRA)


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

Artem Budnikov commented on IGNITE-9525:


[~pgarg] Thanks, look good to me.

> Ignite + Informatica Integration
> 
>
> Key: IGNITE-9525
> URL: https://issues.apache.org/jira/browse/IGNITE-9525
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Prachi Garg
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.7
>
> Attachments: Ignite_Informatica_Integration.pdf
>
>
> Mentioned in https://cwiki.apache.org/confluence/display/IGNITE/Required+Docs



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10265) PDOStatement::rowCount returns 0

2018-11-15 Thread Roman Shtykh (JIRA)


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

Roman Shtykh updated IGNITE-10265:
--
Priority: Minor  (was: Major)

> PDOStatement::rowCount returns 0
> 
>
> Key: IGNITE-10265
> URL: https://issues.apache.org/jira/browse/IGNITE-10265
> Project: Ignite
>  Issue Type: Wish
>  Components: odbc
>Affects Versions: 2.6
> Environment: CentOS, unixODBC
>Reporter: Roman Shtykh
>Priority: Minor
>
> How to reproduce:
> {noformat}
> $ cat ~/odbc.php
>   
> try {
> echo PHP_EOL,PHP_EOL,"# Using PDO",PHP_EOL;
> $dbh = new PDO('odbc:DRIVER={ApacheIgnite};Server=127.0.0.1;PORT=10800');
> $dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
>  
> $sql = 'SELECT * FROM "Person".Person';
> $statement = $dbh->prepare($sql);
> $statement->execute();
>  
> $data = $statement->fetchAll();
>  
> foreach($data as $row) {
> var_dump($row);
> }
>  
> echo "array Count : " . count($data) . "\n";
> echo "rowCount : " . $statement->rowCount() . "\n";
>  
> } catch (PDOException $e) {
> print "Error!: " . $e->getMessage() . "\n";
> die();
> }
>  
> $ php ~/odbc.php
>  
> # Using PDO
> array(10) {
>   ["ORGID"]=>
>   string(1) "1"
>   [0]=>
>   string(1) "1"
>   ["FIRSTNAME"]=>
>   string(4) "John"
>   [1]=>
>   string(4) "John"
>   ["LASTNAME"]=>
>   string(3) "Doe"
>   [2]=>
>   string(3) "Doe"
>   ["RESUME"]=>
>   string(14) "Master Degree."
>   [3]=>
>   string(14) "Master Degree."
>   ["SALARY"]=>
>   string(4) "2200"
>   [4]=>
>   string(4) "2200"
> }
> ・
> ・
> ・
> array(10) {
>   ["ORGID"]=>
>   string(1) "2"
>   [0]=>
>   string(1) "2"
>   ["FIRSTNAME"]=>
>   string(4) "Mary"
>   [1]=>
>   string(4) "Mary"
>   ["LASTNAME"]=>
>   string(5) "Major"
>   [2]=>
>   string(5) "Major"
>   ["RESUME"]=>
>   string(16) "Bachelor Degree."
>   [3]=>
>   string(16) "Bachelor Degree."
>   ["SALARY"]=>
>   string(4) "1200"
>   [4]=>
>   string(4) "1200"
> }
> array Count : 6
> rowCount : 0
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-10265) PDOStatement::rowCount returns 0

2018-11-15 Thread Roman Shtykh (JIRA)


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

Roman Shtykh commented on IGNITE-10265:
---

Agree, thanks!

> PDOStatement::rowCount returns 0
> 
>
> Key: IGNITE-10265
> URL: https://issues.apache.org/jira/browse/IGNITE-10265
> Project: Ignite
>  Issue Type: Wish
>  Components: odbc
>Affects Versions: 2.6
> Environment: CentOS, unixODBC
>Reporter: Roman Shtykh
>Priority: Minor
>
> How to reproduce:
> {noformat}
> $ cat ~/odbc.php
>   
> try {
> echo PHP_EOL,PHP_EOL,"# Using PDO",PHP_EOL;
> $dbh = new PDO('odbc:DRIVER={ApacheIgnite};Server=127.0.0.1;PORT=10800');
> $dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
>  
> $sql = 'SELECT * FROM "Person".Person';
> $statement = $dbh->prepare($sql);
> $statement->execute();
>  
> $data = $statement->fetchAll();
>  
> foreach($data as $row) {
> var_dump($row);
> }
>  
> echo "array Count : " . count($data) . "\n";
> echo "rowCount : " . $statement->rowCount() . "\n";
>  
> } catch (PDOException $e) {
> print "Error!: " . $e->getMessage() . "\n";
> die();
> }
>  
> $ php ~/odbc.php
>  
> # Using PDO
> array(10) {
>   ["ORGID"]=>
>   string(1) "1"
>   [0]=>
>   string(1) "1"
>   ["FIRSTNAME"]=>
>   string(4) "John"
>   [1]=>
>   string(4) "John"
>   ["LASTNAME"]=>
>   string(3) "Doe"
>   [2]=>
>   string(3) "Doe"
>   ["RESUME"]=>
>   string(14) "Master Degree."
>   [3]=>
>   string(14) "Master Degree."
>   ["SALARY"]=>
>   string(4) "2200"
>   [4]=>
>   string(4) "2200"
> }
> ・
> ・
> ・
> array(10) {
>   ["ORGID"]=>
>   string(1) "2"
>   [0]=>
>   string(1) "2"
>   ["FIRSTNAME"]=>
>   string(4) "Mary"
>   [1]=>
>   string(4) "Mary"
>   ["LASTNAME"]=>
>   string(5) "Major"
>   [2]=>
>   string(5) "Major"
>   ["RESUME"]=>
>   string(16) "Bachelor Degree."
>   [3]=>
>   string(16) "Bachelor Degree."
>   ["SALARY"]=>
>   string(4) "1200"
>   [4]=>
>   string(4) "1200"
> }
> array Count : 6
> rowCount : 0
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10265) PDOStatement::rowCount returns 0

2018-11-15 Thread Roman Shtykh (JIRA)


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

Roman Shtykh updated IGNITE-10265:
--
Issue Type: Wish  (was: Bug)

> PDOStatement::rowCount returns 0
> 
>
> Key: IGNITE-10265
> URL: https://issues.apache.org/jira/browse/IGNITE-10265
> Project: Ignite
>  Issue Type: Wish
>  Components: odbc
>Affects Versions: 2.6
> Environment: CentOS, unixODBC
>Reporter: Roman Shtykh
>Priority: Major
>
> How to reproduce:
> {noformat}
> $ cat ~/odbc.php
>   
> try {
> echo PHP_EOL,PHP_EOL,"# Using PDO",PHP_EOL;
> $dbh = new PDO('odbc:DRIVER={ApacheIgnite};Server=127.0.0.1;PORT=10800');
> $dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
>  
> $sql = 'SELECT * FROM "Person".Person';
> $statement = $dbh->prepare($sql);
> $statement->execute();
>  
> $data = $statement->fetchAll();
>  
> foreach($data as $row) {
> var_dump($row);
> }
>  
> echo "array Count : " . count($data) . "\n";
> echo "rowCount : " . $statement->rowCount() . "\n";
>  
> } catch (PDOException $e) {
> print "Error!: " . $e->getMessage() . "\n";
> die();
> }
>  
> $ php ~/odbc.php
>  
> # Using PDO
> array(10) {
>   ["ORGID"]=>
>   string(1) "1"
>   [0]=>
>   string(1) "1"
>   ["FIRSTNAME"]=>
>   string(4) "John"
>   [1]=>
>   string(4) "John"
>   ["LASTNAME"]=>
>   string(3) "Doe"
>   [2]=>
>   string(3) "Doe"
>   ["RESUME"]=>
>   string(14) "Master Degree."
>   [3]=>
>   string(14) "Master Degree."
>   ["SALARY"]=>
>   string(4) "2200"
>   [4]=>
>   string(4) "2200"
> }
> ・
> ・
> ・
> array(10) {
>   ["ORGID"]=>
>   string(1) "2"
>   [0]=>
>   string(1) "2"
>   ["FIRSTNAME"]=>
>   string(4) "Mary"
>   [1]=>
>   string(4) "Mary"
>   ["LASTNAME"]=>
>   string(5) "Major"
>   [2]=>
>   string(5) "Major"
>   ["RESUME"]=>
>   string(16) "Bachelor Degree."
>   [3]=>
>   string(16) "Bachelor Degree."
>   ["SALARY"]=>
>   string(4) "1200"
>   [4]=>
>   string(4) "1200"
> }
> array Count : 6
> rowCount : 0
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10290) Map.Entry interface for key cache may lead to incorrect calculation hash code

2018-11-15 Thread Dmitriy Govorukhin (JIRA)


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

Dmitriy Govorukhin updated IGNITE-10290:

Description: 
In case if use Map.Entry interface for a key, we can try to find (key, value) 
in store with incorrect calculated hash code for binary representation, it lead 
to result null.
The problem is in the 
GridPartitionedSingleGetFuture#localGet() and 
GridPartitionedGetFuture#localGet() does not execute prepareForCache before 
reading cacheDataRow from row store.

  was:
In case if use Map.Entry interface for a key, we can try to find (key, value) 
in store with incorrect calculated hash code for binary representation.
The problem is in the 
GridPartitionedSingleGetFuture#localGet() and 
GridPartitionedGetFuture#localGet() does not execute prepareForCache before 
reading cacheDataRow from row store.


> Map.Entry interface for key cache may lead to incorrect calculation hash code
> -
>
> Key: IGNITE-10290
> URL: https://issues.apache.org/jira/browse/IGNITE-10290
> Project: Ignite
>  Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
> Attachments: Reproducer.java
>
>
> In case if use Map.Entry interface for a key, we can try to find (key, value) 
> in store with incorrect calculated hash code for binary representation, it 
> lead to result null.
> The problem is in the 
> GridPartitionedSingleGetFuture#localGet() and 
> GridPartitionedGetFuture#localGet() does not execute prepareForCache before 
> reading cacheDataRow from row store.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-10290) Map.Entry interface for key cache may lead to incorrect calculation hash code

2018-11-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-10290:
-

GitHub user dgovorukhin opened a pull request:

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

IGNITE-10290 Fix missed prepareForCache in localGet operation

Signed-off-by: Dmitriy Govorukhin 

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

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

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

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


commit 71308b18d891e707c801959f5fe92460b3bde69b
Author: Dmitriy Govorukhin 
Date:   2018-11-15T23:15:18Z

IGNITE-10290 Fix missed prepareForCache in localGet operation

Signed-off-by: Dmitriy Govorukhin 




> Map.Entry interface for key cache may lead to incorrect calculation hash code
> -
>
> Key: IGNITE-10290
> URL: https://issues.apache.org/jira/browse/IGNITE-10290
> Project: Ignite
>  Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
> Attachments: Reproducer.java
>
>
> In case if use Map.Entry interface for a key, we can try to find (key, value) 
> in store with incorrect calculated hash code for binary representation.
> The problem is in the 
> GridPartitionedSingleGetFuture#localGet() and 
> GridPartitionedGetFuture#localGet() does not execute prepareForCache before 
> reading cacheDataRow from row store.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10290) Map.Entry interface for key cache may lead to incorrect calculation hash code

2018-11-15 Thread Dmitriy Govorukhin (JIRA)


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

Dmitriy Govorukhin updated IGNITE-10290:

Ignite Flags:   (was: Docs Required)

> Map.Entry interface for key cache may lead to incorrect calculation hash code
> -
>
> Key: IGNITE-10290
> URL: https://issues.apache.org/jira/browse/IGNITE-10290
> Project: Ignite
>  Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
> Attachments: Reproducer.java
>
>
> In case if use Map.Entry interface for a key, we can try to find (key, value) 
> in store with incorrect calculated hash code for binary representation.
> The problem is in the 
> GridPartitionedSingleGetFuture#localGet() and 
> GridPartitionedGetFuture#localGet() does not execute prepareForCache before 
> reading cacheDataRow from row store.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (IGNITE-10290) Map.Entry interface for key cache may lead to incorrect calculation hash code

2018-11-15 Thread Dmitriy Govorukhin (JIRA)


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

Dmitriy Govorukhin reassigned IGNITE-10290:
---

Assignee: Dmitriy Govorukhin

> Map.Entry interface for key cache may lead to incorrect calculation hash code
> -
>
> Key: IGNITE-10290
> URL: https://issues.apache.org/jira/browse/IGNITE-10290
> Project: Ignite
>  Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
> Attachments: Reproducer.java
>
>
> In case if use Map.Entry interface for a key, we can try to find (key, value) 
> in store with incorrect calculated hash code for binary representation.
> The problem is in the 
> GridPartitionedSingleGetFuture#localGet() and 
> GridPartitionedGetFuture#localGet() does not execute prepareForCache before 
> reading cacheDataRow from row store.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10290) Map.Entry interface for key cache may lead to incorrect calculation hash code

2018-11-15 Thread Dmitriy Govorukhin (JIRA)


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

Dmitriy Govorukhin updated IGNITE-10290:

Fix Version/s: 2.8

> Map.Entry interface for key cache may lead to incorrect calculation hash code
> -
>
> Key: IGNITE-10290
> URL: https://issues.apache.org/jira/browse/IGNITE-10290
> Project: Ignite
>  Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
> Attachments: Reproducer.java
>
>
> In case if use Map.Entry interface for a key, we can try to find (key, value) 
> in store with incorrect calculated hash code for binary representation.
> The problem is in the 
> GridPartitionedSingleGetFuture#localGet() and 
> GridPartitionedGetFuture#localGet() does not execute prepareForCache before 
> reading cacheDataRow from row store.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-10290) Map.Entry interface for key cache may lead to incorrect calculation hash code

2018-11-15 Thread Dmitriy Govorukhin (JIRA)
Dmitriy Govorukhin created IGNITE-10290:
---

 Summary: Map.Entry interface for key cache may lead to incorrect 
calculation hash code
 Key: IGNITE-10290
 URL: https://issues.apache.org/jira/browse/IGNITE-10290
 Project: Ignite
  Issue Type: Bug
Reporter: Dmitriy Govorukhin
 Attachments: Reproducer.java

In case if use Map.Entry interface for a key, we can try to find (key, value) 
in store with incorrect calculated hash code for binary representation.
The problem is in the 
GridPartitionedSingleGetFuture#localGet() and 
GridPartitionedGetFuture#localGet() does not execute prepareForCache before 
reading cacheDataRow from row store.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-9312) Remove unnecessary @SuppressWarnings annotation

2018-11-15 Thread PetrovMikhail (JIRA)


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

PetrovMikhail commented on IGNITE-9312:
---

{panel:title=No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All 
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2209589buildTypeId=IgniteTests24Java8_MvccCache_2]

> Remove unnecessary @SuppressWarnings annotation
> ---
>
> Key: IGNITE-9312
> URL: https://issues.apache.org/jira/browse/IGNITE-9312
> Project: Ignite
>  Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: PetrovMikhail
>Priority: Minor
>  Labels: inspections
> Fix For: 2.8
>
>
> New `Code Inspections` profile can be found 
> \idea\ignite_inspections.xml.
> We will need to fix all methods with unnecessary {{@SuppressWarnings}} 
> annotation regarding this inscpetion profile.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-9312) Remove unnecessary @SuppressWarnings annotation

2018-11-15 Thread PetrovMikhail (JIRA)


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

PetrovMikhail commented on IGNITE-9312:
---

{panel:title=No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All 
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2209589buildTypeId=IgniteTests24Java8_MvccCache_2]

> Remove unnecessary @SuppressWarnings annotation
> ---
>
> Key: IGNITE-9312
> URL: https://issues.apache.org/jira/browse/IGNITE-9312
> Project: Ignite
>  Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: PetrovMikhail
>Priority: Minor
>  Labels: inspections
> Fix For: 2.8
>
>
> New `Code Inspections` profile can be found 
> \idea\ignite_inspections.xml.
> We will need to fix all methods with unnecessary {{@SuppressWarnings}} 
> annotation regarding this inscpetion profile.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-10285) U.doInParallel may lead to deadlock

2018-11-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-10285:
-

GitHub user dgovorukhin opened a pull request:

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

IGNITE-10285 Implement job stealing for U.doInParallel 



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

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

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

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


commit 37d1310d24996966c60d673754033051f02abccb
Author: Dmitriy Govorukhin 
Date:   2018-11-15T22:37:40Z

IGNITE-10285 Implement job stealing for U.doInParallel in case if executor 
busy and cannot perform task immediately

Signed-off-by: Dmitriy Govorukhin 




> U.doInParallel may lead to deadlock
> ---
>
> Key: IGNITE-10285
> URL: https://issues.apache.org/jira/browse/IGNITE-10285
> Project: Ignite
>  Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Critical
> Fix For: 2.8
>
> Attachments: dump.rtf
>
>
> There are exist case when we can get a deadlock on the thread pool.
> If we try doInParallel in the thread of sys-pool in the number of 
> hreads==sys-pool.size we lead to deadlock because threads in sys-pool will 
> try doInParallel through the same sys-pool, and they will wait on future 
> infinitely because no one thread cannot complete operation doInParallel which 
> require threads from sys-pool.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-10289) [ML] Import models from XGBoost

2018-11-15 Thread Yury Babak (JIRA)
Yury Babak created IGNITE-10289:
---

 Summary: [ML] Import models from XGBoost
 Key: IGNITE-10289
 URL: https://issues.apache.org/jira/browse/IGNITE-10289
 Project: Ignite
  Issue Type: New Feature
  Components: ml
Reporter: Yury Babak
Assignee: Anton Dmitriev


We want to have the ability of import model from 3rd part ml libraries into 
Apache Ignite. We could start this process from XGBoost library for trees and 
GDB.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10285) U.doInParallel may lead to deadlock

2018-11-15 Thread Dmitriy Govorukhin (JIRA)


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

Dmitriy Govorukhin updated IGNITE-10285:

Ignite Flags:   (was: Docs Required)

> U.doInParallel may lead to deadlock
> ---
>
> Key: IGNITE-10285
> URL: https://issues.apache.org/jira/browse/IGNITE-10285
> Project: Ignite
>  Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Critical
> Fix For: 2.8
>
> Attachments: dump.rtf
>
>
> There are exist case when we can get a deadlock on the thread pool.
> If we try doInParallel in the thread of sys-pool in the number of 
> hreads==sys-pool.size we lead to deadlock because threads in sys-pool will 
> try doInParallel through the same sys-pool, and they will wait on future 
> infinitely because no one thread cannot complete operation doInParallel which 
> require threads from sys-pool.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-10288) [ML] Model inference

2018-11-15 Thread Yury Babak (JIRA)
Yury Babak created IGNITE-10288:
---

 Summary: [ML] Model inference
 Key: IGNITE-10288
 URL: https://issues.apache.org/jira/browse/IGNITE-10288
 Project: Ignite
  Issue Type: New Feature
  Components: ml
Reporter: Yury Babak


We need a convenient API for model inference. The current idea is to utilize 
Service Grid for this purpose. We should have two options, first is deliver a 
model to any node(server or client) and infer this model on that node. The 
second approach is to pin a model to a specific server and infer model on that 
server, it could be useful in case if we need some specific hardware which we 
don't have at any server like a GPU or TPU.

So the first approach is suitable for lightweight models and the second 
approach is suitable for some complex models like Neural Networks.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-10287) [ML] Model storage

2018-11-15 Thread Yury Babak (JIRA)
Yury Babak created IGNITE-10287:
---

 Summary: [ML] Model storage
 Key: IGNITE-10287
 URL: https://issues.apache.org/jira/browse/IGNITE-10287
 Project: Ignite
  Issue Type: New Feature
  Components: ml
Reporter: Yury Babak


We want to have some storage for any kind of models in Apache Ignite. It should 
allow storing 
a model from any node after training and evaluation(MB with some meta info and 
model metrics) and provide API to get this model to any node.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (IGNITE-10285) U.doInParallel may lead to deadlock

2018-11-15 Thread Dmitriy Govorukhin (JIRA)


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

Dmitriy Govorukhin reassigned IGNITE-10285:
---

Assignee: Dmitriy Govorukhin

> U.doInParallel may lead to deadlock
> ---
>
> Key: IGNITE-10285
> URL: https://issues.apache.org/jira/browse/IGNITE-10285
> Project: Ignite
>  Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Critical
> Fix For: 2.8
>
> Attachments: dump.rtf
>
>
> There are exist case when we can get a deadlock on the thread pool.
> If we try doInParallel in the thread of sys-pool in the number of 
> hreads==sys-pool.size we lead to deadlock because threads in sys-pool will 
> try doInParallel through the same sys-pool, and they will wait on future 
> infinitely because no one thread cannot complete operation doInParallel which 
> require threads from sys-pool.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10285) U.doInParallel may lead to deadlock

2018-11-15 Thread Dmitriy Govorukhin (JIRA)


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

Dmitriy Govorukhin updated IGNITE-10285:

Fix Version/s: 2.8

> U.doInParallel may lead to deadlock
> ---
>
> Key: IGNITE-10285
> URL: https://issues.apache.org/jira/browse/IGNITE-10285
> Project: Ignite
>  Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Priority: Critical
> Fix For: 2.8
>
> Attachments: dump.rtf
>
>
> There are exist case when we can get a deadlock on the thread pool.
> If we try doInParallel in the thread of sys-pool in the number of 
> hreads==sys-pool.size we lead to deadlock because threads in sys-pool will 
> try doInParallel through the same sys-pool, and they will wait on future 
> infinitely because no one thread cannot complete operation doInParallel which 
> require threads from sys-pool.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-10285) U.doInParallel may lead to deadlock

2018-11-15 Thread Dmitriy Govorukhin (JIRA)
Dmitriy Govorukhin created IGNITE-10285:
---

 Summary: U.doInParallel may lead to deadlock
 Key: IGNITE-10285
 URL: https://issues.apache.org/jira/browse/IGNITE-10285
 Project: Ignite
  Issue Type: Bug
Reporter: Dmitriy Govorukhin
 Attachments: dump.rtf

There are exist case when we can get a deadlock on the thread pool.
If we try doInParallel in the thread of sys-pool in the number of 
hreads==sys-pool.size we lead to deadlock because threads in sys-pool will try 
doInParallel through the same sys-pool, and they will wait on future infinitely 
because no one thread cannot complete operation doInParallel which require 
threads from sys-pool.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-10286) [ML] Umbrella: Model serving

2018-11-15 Thread Yury Babak (JIRA)
Yury Babak created IGNITE-10286:
---

 Summary: [ML] Umbrella: Model serving
 Key: IGNITE-10286
 URL: https://issues.apache.org/jira/browse/IGNITE-10286
 Project: Ignite
  Issue Type: New Feature
  Components: ml
Reporter: Yury Babak
Assignee: Yury Babak


We want to have convenient API for model serving. It means that we need a 
mechanism for storing models and infer them inside Apache Ignite.

For now, I see 2 important features - distributed storage for any models and 
inference.

>From my point of view, we could use some built-in(predefined) cache as model 
>storage. And use service grid for model inference. We could implement some 
>"ModelService" for access to our storage, receive the list of all suitable 
>model(including model metrics and some other information about a model), 
>choose one(or several) and infer it from this service.

Model from TF should also use the same mechanisms for storing and inference.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Issue Comment Deleted] (IGNITE-9312) Remove unnecessary @SuppressWarnings annotation

2018-11-15 Thread PetrovMikhail (JIRA)


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

PetrovMikhail updated IGNITE-9312:
--
Comment: was deleted

(was: {panel:title=Possible 
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Queries 2{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=2209567]]
* IgniteBinaryCacheQueryTestSuite2: 
DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testDropColumnCoordinatorChange
 - 3,1% fails in last 100 master runs.

{color:#d04437}Continuous Query 1{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=2209547]]
* IgniteCacheQuerySelfTestSuite3: 
CacheContinuousQueryOrderingEventTest.testAtomicOnheapTwoBackupAsyncFullSync - 
0,0% fails in last 100 master runs.

{color:#d04437}Client Nodes{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=2209542]]
* IgniteClientNodesTestSuite: 
IgniteClientReconnectCacheTest.testReconnectOperationInProgress - 0,0% fails in 
last 100 master runs.

{color:#d04437}SPI{color} [[tests 
6|https://ci.ignite.apache.org/viewLog.html?buildId=2209572]]
* IgniteSpiTestSuite: TcpDiscoveryWithWrongServerTest.testDisconnectOnRequest - 
2,1% fails in last 100 master runs.
* IgniteSpiTestSuite: 
TcpDiscoveryWithWrongServerTest.testWrongHandshakeResponse - 2,1% fails in last 
100 master runs.
* IgniteSpiTestSuite: TcpDiscoveryWithWrongServerTest.testEarlyDisconnect - 
2,1% fails in last 100 master runs.
* IgniteSpiTestSuite: TcpDiscoveryWithWrongServerTest.testNoHandshakeResponse - 
2,1% fails in last 100 master runs.

{color:#d04437}Platform .NET{color} [[tests 
2|https://ci.ignite.apache.org/viewLog.html?buildId=2209633]]
* exe: ClientConnectionTest.TestServerConnectionAborted - 3,0% fails in last 
100 master runs.
* exe: ServicesTest.TestWithKeepBinaryClient - 0,0% fails in last 100 master 
runs.

{color:#d04437}PDS 2{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=2209630]]
* IgnitePdsTestSuite2: 
IgniteAbsentEvictionNodeOutOfBaselineTest.testPartitionsRemovedIfJoiningNodeNotInBaseline
 - 0,0% fails in last 100 master runs.

{color:#d04437}Cache (Failover) 3{color} [[tests 
11|https://ci.ignite.apache.org/viewLog.html?buildId=2209600]]
* IgniteCacheFailoverTestSuite3: IgniteCachePutRetryAtomicSelfTest.testPutAsync 
- 0,0% fails in last 100 master runs.
* IgniteCacheFailoverTestSuite3: 
IgniteCachePutRetryAtomicSelfTest.testPutAsyncStoreEnabled - 0,0% fails in last 
100 master runs.

{panel}
[TeamCity Run All 
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2209645buildTypeId=IgniteTests24Java8_RunAll])

> Remove unnecessary @SuppressWarnings annotation
> ---
>
> Key: IGNITE-9312
> URL: https://issues.apache.org/jira/browse/IGNITE-9312
> Project: Ignite
>  Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: PetrovMikhail
>Priority: Minor
>  Labels: inspections
> Fix For: 2.8
>
>
> New `Code Inspections` profile can be found 
> \idea\ignite_inspections.xml.
> We will need to fix all methods with unnecessary {{@SuppressWarnings}} 
> annotation regarding this inscpetion profile.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-10278) The checkpointReadLock must be acquired before calling MvccProcessor.updateState

2018-11-15 Thread Ignite TC Bot (JIRA)


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

Ignite TC Bot commented on IGNITE-10278:


{panel:title=Possible 
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Inspections: Core{color} [[tests 0 BuildFailureOnMetric 
|https://ci.ignite.apache.org/viewLog.html?buildId=2324803]]

{panel}
[TeamCity Run All 
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2324807buildTypeId=IgniteTests24Java8_RunAll]

> The checkpointReadLock must be acquired before calling 
> MvccProcessor.updateState
> 
>
> Key: IGNITE-10278
> URL: https://issues.apache.org/jira/browse/IGNITE-10278
> Project: Ignite
>  Issue Type: Bug
>  Components: mvcc
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
>
> It looks like acquiring \{{checkpointReadLock}} is missing when we are trying 
> to apply mvcc tx records.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-9312) Remove unnecessary @SuppressWarnings annotation

2018-11-15 Thread PetrovMikhail (JIRA)


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

PetrovMikhail commented on IGNITE-9312:
---

{panel:title=Possible 
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Queries 2{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=2209567]]
* IgniteBinaryCacheQueryTestSuite2: 
DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testDropColumnCoordinatorChange
 - 3,1% fails in last 100 master runs.

{color:#d04437}Continuous Query 1{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=2209547]]
* IgniteCacheQuerySelfTestSuite3: 
CacheContinuousQueryOrderingEventTest.testAtomicOnheapTwoBackupAsyncFullSync - 
0,0% fails in last 100 master runs.

{color:#d04437}Client Nodes{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=2209542]]
* IgniteClientNodesTestSuite: 
IgniteClientReconnectCacheTest.testReconnectOperationInProgress - 0,0% fails in 
last 100 master runs.

{color:#d04437}SPI{color} [[tests 
6|https://ci.ignite.apache.org/viewLog.html?buildId=2209572]]
* IgniteSpiTestSuite: TcpDiscoveryWithWrongServerTest.testDisconnectOnRequest - 
2,1% fails in last 100 master runs.
* IgniteSpiTestSuite: 
TcpDiscoveryWithWrongServerTest.testWrongHandshakeResponse - 2,1% fails in last 
100 master runs.
* IgniteSpiTestSuite: TcpDiscoveryWithWrongServerTest.testEarlyDisconnect - 
2,1% fails in last 100 master runs.
* IgniteSpiTestSuite: TcpDiscoveryWithWrongServerTest.testNoHandshakeResponse - 
2,1% fails in last 100 master runs.

{color:#d04437}Platform .NET{color} [[tests 
2|https://ci.ignite.apache.org/viewLog.html?buildId=2209633]]
* exe: ClientConnectionTest.TestServerConnectionAborted - 3,0% fails in last 
100 master runs.
* exe: ServicesTest.TestWithKeepBinaryClient - 0,0% fails in last 100 master 
runs.

{color:#d04437}PDS 2{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=2209630]]
* IgnitePdsTestSuite2: 
IgniteAbsentEvictionNodeOutOfBaselineTest.testPartitionsRemovedIfJoiningNodeNotInBaseline
 - 0,0% fails in last 100 master runs.

{color:#d04437}Cache (Failover) 3{color} [[tests 
11|https://ci.ignite.apache.org/viewLog.html?buildId=2209600]]
* IgniteCacheFailoverTestSuite3: IgniteCachePutRetryAtomicSelfTest.testPutAsync 
- 0,0% fails in last 100 master runs.
* IgniteCacheFailoverTestSuite3: 
IgniteCachePutRetryAtomicSelfTest.testPutAsyncStoreEnabled - 0,0% fails in last 
100 master runs.

{panel}
[TeamCity Run All 
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2209645buildTypeId=IgniteTests24Java8_RunAll]

> Remove unnecessary @SuppressWarnings annotation
> ---
>
> Key: IGNITE-9312
> URL: https://issues.apache.org/jira/browse/IGNITE-9312
> Project: Ignite
>  Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: PetrovMikhail
>Priority: Minor
>  Labels: inspections
> Fix For: 2.8
>
>
> New `Code Inspections` profile can be found 
> \idea\ignite_inspections.xml.
> We will need to fix all methods with unnecessary {{@SuppressWarnings}} 
> annotation regarding this inscpetion profile.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Issue Comment Deleted] (IGNITE-9312) Remove unnecessary @SuppressWarnings annotation

2018-11-15 Thread PetrovMikhail (JIRA)


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

PetrovMikhail updated IGNITE-9312:
--
Comment: was deleted

(was: {panel:title=Possible 
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Queries 2{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=2209567]]
* IgniteBinaryCacheQueryTestSuite2: 
DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testDropColumnCoordinatorChange
 - 3,1% fails in last 100 master runs.

{color:#d04437}Continuous Query 1{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=2209547]]
* IgniteCacheQuerySelfTestSuite3: 
CacheContinuousQueryOrderingEventTest.testAtomicOnheapTwoBackupAsyncFullSync - 
0,0% fails in last 100 master runs.

{color:#d04437}Client Nodes{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=2209542]]
* IgniteClientNodesTestSuite: 
IgniteClientReconnectCacheTest.testReconnectOperationInProgress - 0,0% fails in 
last 100 master runs.

{color:#d04437}SPI{color} [[tests 
6|https://ci.ignite.apache.org/viewLog.html?buildId=2209572]]
* IgniteSpiTestSuite: TcpDiscoveryWithWrongServerTest.testDisconnectOnRequest - 
2,1% fails in last 100 master runs.
* IgniteSpiTestSuite: 
TcpDiscoveryWithWrongServerTest.testWrongHandshakeResponse - 2,1% fails in last 
100 master runs.
* IgniteSpiTestSuite: TcpDiscoveryWithWrongServerTest.testEarlyDisconnect - 
2,1% fails in last 100 master runs.
* IgniteSpiTestSuite: TcpDiscoveryWithWrongServerTest.testNoHandshakeResponse - 
2,1% fails in last 100 master runs.

{color:#d04437}Platform .NET{color} [[tests 
2|https://ci.ignite.apache.org/viewLog.html?buildId=2209633]]
* exe: ClientConnectionTest.TestServerConnectionAborted - 3,0% fails in last 
100 master runs.
* exe: ServicesTest.TestWithKeepBinaryClient - 0,0% fails in last 100 master 
runs.

{color:#d04437}PDS 2{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=2209630]]
* IgnitePdsTestSuite2: 
IgniteAbsentEvictionNodeOutOfBaselineTest.testPartitionsRemovedIfJoiningNodeNotInBaseline
 - 0,0% fails in last 100 master runs.

{color:#d04437}Cache (Failover) 3{color} [[tests 
11|https://ci.ignite.apache.org/viewLog.html?buildId=2209600]]
* IgniteCacheFailoverTestSuite3: IgniteCachePutRetryAtomicSelfTest.testPutAsync 
- 0,0% fails in last 100 master runs.
* IgniteCacheFailoverTestSuite3: 
IgniteCachePutRetryAtomicSelfTest.testPutAsyncStoreEnabled - 0,0% fails in last 
100 master runs.

{panel}
[TeamCity Run All 
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2209645buildTypeId=IgniteTests24Java8_RunAll])

> Remove unnecessary @SuppressWarnings annotation
> ---
>
> Key: IGNITE-9312
> URL: https://issues.apache.org/jira/browse/IGNITE-9312
> Project: Ignite
>  Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: PetrovMikhail
>Priority: Minor
>  Labels: inspections
> Fix For: 2.8
>
>
> New `Code Inspections` profile can be found 
> \idea\ignite_inspections.xml.
> We will need to fix all methods with unnecessary {{@SuppressWarnings}} 
> annotation regarding this inscpetion profile.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-9312) Remove unnecessary @SuppressWarnings annotation

2018-11-15 Thread PetrovMikhail (JIRA)


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

PetrovMikhail commented on IGNITE-9312:
---

{panel:title=Possible 
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Queries 2{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=2209567]]
* IgniteBinaryCacheQueryTestSuite2: 
DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testDropColumnCoordinatorChange
 - 3,1% fails in last 100 master runs.

{color:#d04437}Continuous Query 1{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=2209547]]
* IgniteCacheQuerySelfTestSuite3: 
CacheContinuousQueryOrderingEventTest.testAtomicOnheapTwoBackupAsyncFullSync - 
0,0% fails in last 100 master runs.

{color:#d04437}Client Nodes{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=2209542]]
* IgniteClientNodesTestSuite: 
IgniteClientReconnectCacheTest.testReconnectOperationInProgress - 0,0% fails in 
last 100 master runs.

{color:#d04437}SPI{color} [[tests 
6|https://ci.ignite.apache.org/viewLog.html?buildId=2209572]]
* IgniteSpiTestSuite: TcpDiscoveryWithWrongServerTest.testDisconnectOnRequest - 
2,1% fails in last 100 master runs.
* IgniteSpiTestSuite: 
TcpDiscoveryWithWrongServerTest.testWrongHandshakeResponse - 2,1% fails in last 
100 master runs.
* IgniteSpiTestSuite: TcpDiscoveryWithWrongServerTest.testEarlyDisconnect - 
2,1% fails in last 100 master runs.
* IgniteSpiTestSuite: TcpDiscoveryWithWrongServerTest.testNoHandshakeResponse - 
2,1% fails in last 100 master runs.

{color:#d04437}Platform .NET{color} [[tests 
2|https://ci.ignite.apache.org/viewLog.html?buildId=2209633]]
* exe: ClientConnectionTest.TestServerConnectionAborted - 3,0% fails in last 
100 master runs.
* exe: ServicesTest.TestWithKeepBinaryClient - 0,0% fails in last 100 master 
runs.

{color:#d04437}PDS 2{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=2209630]]
* IgnitePdsTestSuite2: 
IgniteAbsentEvictionNodeOutOfBaselineTest.testPartitionsRemovedIfJoiningNodeNotInBaseline
 - 0,0% fails in last 100 master runs.

{color:#d04437}Cache (Failover) 3{color} [[tests 
11|https://ci.ignite.apache.org/viewLog.html?buildId=2209600]]
* IgniteCacheFailoverTestSuite3: IgniteCachePutRetryAtomicSelfTest.testPutAsync 
- 0,0% fails in last 100 master runs.
* IgniteCacheFailoverTestSuite3: 
IgniteCachePutRetryAtomicSelfTest.testPutAsyncStoreEnabled - 0,0% fails in last 
100 master runs.

{panel}
[TeamCity Run All 
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2209645buildTypeId=IgniteTests24Java8_RunAll]

> Remove unnecessary @SuppressWarnings annotation
> ---
>
> Key: IGNITE-9312
> URL: https://issues.apache.org/jira/browse/IGNITE-9312
> Project: Ignite
>  Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: PetrovMikhail
>Priority: Minor
>  Labels: inspections
> Fix For: 2.8
>
>
> New `Code Inspections` profile can be found 
> \idea\ignite_inspections.xml.
> We will need to fix all methods with unnecessary {{@SuppressWarnings}} 
> annotation regarding this inscpetion profile.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Issue Comment Deleted] (IGNITE-9312) Remove unnecessary @SuppressWarnings annotation

2018-11-15 Thread PetrovMikhail (JIRA)


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

PetrovMikhail updated IGNITE-9312:
--
Comment: was deleted

(was: {panel:title=No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All 
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2209634buildTypeId=IgniteTests24Java8_PlatformNetCoreLinux])

> Remove unnecessary @SuppressWarnings annotation
> ---
>
> Key: IGNITE-9312
> URL: https://issues.apache.org/jira/browse/IGNITE-9312
> Project: Ignite
>  Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: PetrovMikhail
>Priority: Minor
>  Labels: inspections
> Fix For: 2.8
>
>
> New `Code Inspections` profile can be found 
> \idea\ignite_inspections.xml.
> We will need to fix all methods with unnecessary {{@SuppressWarnings}} 
> annotation regarding this inscpetion profile.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-9939) [TC Bot] Add visa's cahing and monitoring

2018-11-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-9939:


ololo3000 closed pull request #71: IGNITE-9939   BuildObserver refactor. Visas 
request cancellation added
URL: https://github.com/apache/ignite-teamcity-bot/pull/71
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/TcHelper.java 
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/TcHelper.java
index 44facf29..cea883b6 100644
--- a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/TcHelper.java
+++ b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/TcHelper.java
@@ -164,8 +164,12 @@ private BranchesTracked getTrackedBranches() {
 
 String comment = generateJiraComment(suitesStatuses, build.webUrl);
 
-blockers = suitesStatuses.stream().mapToInt(suite ->
-suite.testFailures.size()).sum();
+blockers = suitesStatuses.stream().mapToInt(suite -> {
+if (suite.testFailures.isEmpty())
+return 1;
+
+return suite.testFailures.size();})
+.sum();
 
 res = objectMapper.readValue(teamcity.sendJiraComment(ticket, 
comment), JiraCommentResponse.class);
 }
diff --git 
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildObserver.java
 
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildObserver.java
index cf294684..954173fb 100644
--- 
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildObserver.java
+++ 
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildObserver.java
@@ -17,7 +17,6 @@
 
 package org.apache.ignite.ci.observer;
 
-import java.util.Collection;
 import java.util.Objects;
 import java.util.Timer;
 import javax.inject.Inject;
@@ -60,6 +59,11 @@ public void stop() {
 timer.cancel();
 }
 
+/** */
+public void stopObservation(String srv, String branchForTc) {
+observerTask.removeBuildInfo(srv, branchForTc);
+}
+
 /**
  * @param srvId Server id.
  * @param prov Credentials.
@@ -81,16 +85,13 @@ public void observe(String srvId, ICredentialsProv prov, 
String ticket, String b
 public String getObservationStatus(String srvId, String branch) {
 StringBuilder sb = new StringBuilder();
 
-Collection builds = observerTask.getInfos();
+BuildsInfo bi = observerTask.getInfo(srvId, branch);
 
-for (BuildsInfo bi : builds) {
-if (Objects.equals(bi.branchForTc, branch)
-&& Objects.equals(bi.srvId, srvId)) {
-sb.append(bi.ticket).append(" to be commented, waiting for 
builds. ");
-sb.append(bi.finishedBuildsCount());
-sb.append(" builds done from ");
-sb.append(bi.buildsCount());
-}
+if (Objects.nonNull(bi)) {
+sb.append(bi.ticket).append(" to be commented, waiting for builds. 
");
+sb.append(bi.finishedBuildsCount());
+sb.append(" builds done from ");
+sb.append(bi.buildsCount());
 }
 
 return sb.toString();
diff --git 
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildsInfo.java
 
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildsInfo.java
index 71171694..f52c5a04 100644
--- 
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildsInfo.java
+++ 
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildsInfo.java
@@ -71,7 +71,8 @@ public BuildsInfo(CompactBuildsInfo buildsInfo, 
IStringCompactor strCompactor) {
 this.ticket = strCompactor.getStringFromId(buildsInfo.ticket());
 this.branchForTc = 
strCompactor.getStringFromId(buildsInfo.branchForTc());
 this.buildTypeId = 
strCompactor.getStringFromId(buildsInfo.buildTypeId());
-this.finishedBuilds.putAll(buildsInfo.getFinishedBuilds());
+
+buildsInfo.getBuilds().forEach(id -> finishedBuilds.put(id, false));
 }
 
 /**
diff --git 
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/CompactBuildsInfo.java
 
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/CompactBuildsInfo.java
index c07f05af..69b3efed 100644
--- 
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/CompactBuildsInfo.java
+++ 
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/CompactBuildsInfo.java
@@ -17,10 +17,10 @@
 
 package org.apache.ignite.ci.observer;
 
+import java.util.ArrayList;
 import 

[jira] [Created] (IGNITE-10284) performance drop on PME time during 1 server node left

2018-11-15 Thread Max Shonichev (JIRA)
Max Shonichev created IGNITE-10284:
--

 Summary: performance drop on PME time during 1 server node left
 Key: IGNITE-10284
 URL: https://issues.apache.org/jira/browse/IGNITE-10284
 Project: Ignite
  Issue Type: Bug
Reporter: Max Shonichev


7 server nodes (1 node per host), 120 caches, G1GC, 32768 partitions 1 client 
tx loading

1. start cluster, fix baseline, preload data
2. start tx transfer task
3. kill 1 server node
4. wait for topology snapshot change, measure PME time
5. restart killed node
6. wait for topology snapshot change, measure PME time

for 1 server LEAVE, we see 7%-10% degradation, BUG

for 1 server JOIN, we see performance degradation on first exchange 
(evt=NODE_LEFT) and performance increase on second exchange 
(evt=CacheAffinityChange), overall 40-60% increase.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10284) performance drop on PME time during 1 server node left

2018-11-15 Thread Max Shonichev (JIRA)


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

Max Shonichev updated IGNITE-10284:
---
Ignite Flags:   (was: Docs Required)

> performance drop on PME time during 1 server node left
> --
>
> Key: IGNITE-10284
> URL: https://issues.apache.org/jira/browse/IGNITE-10284
> Project: Ignite
>  Issue Type: Bug
>Reporter: Max Shonichev
>Priority: Major
>
> 7 server nodes (1 node per host), 120 caches, G1GC, 32768 partitions 1 client 
> tx loading
> 1. start cluster, fix baseline, preload data
> 2. start tx transfer task
> 3. kill 1 server node
> 4. wait for topology snapshot change, measure PME time
> 5. restart killed node
> 6. wait for topology snapshot change, measure PME time
> for 1 server LEAVE, we see 7%-10% degradation, BUG
> for 1 server JOIN, we see performance degradation on first exchange 
> (evt=NODE_LEFT) and performance increase on second exchange 
> (evt=CacheAffinityChange), overall 40-60% increase.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (IGNITE-9786) MVCC: simplify TX wait list management

2018-11-15 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov closed IGNITE-9786.
---

> MVCC: simplify TX wait list management
> --
>
> Key: IGNITE-9786
> URL: https://issues.apache.org/jira/browse/IGNITE-9786
> Project: Ignite
>  Issue Type: Task
>  Components: mvcc
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Attachments: IGNITE_9786__Patch_.patch
>
>
> It seems that instead of having a lot of classes and complex synchronization 
> mechanics for MvccProcessorImpl.waitMap, we can use single wrapper with a 
> list of waiters. 
> Resulting code will be much more simpler and less prone to concurrency issues.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-9786) MVCC: simplify TX wait list management

2018-11-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-9786:


Github user devozerov closed the pull request at:

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


> MVCC: simplify TX wait list management
> --
>
> Key: IGNITE-9786
> URL: https://issues.apache.org/jira/browse/IGNITE-9786
> Project: Ignite
>  Issue Type: Task
>  Components: mvcc
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Attachments: IGNITE_9786__Patch_.patch
>
>
> It seems that instead of having a lot of classes and complex synchronization 
> mechanics for MvccProcessorImpl.waitMap, we can use single wrapper with a 
> list of waiters. 
> Resulting code will be much more simpler and less prone to concurrency issues.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-9786) MVCC: simplify TX wait list management

2018-11-15 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-9786:

Fix Version/s: (was: 2.8)

> MVCC: simplify TX wait list management
> --
>
> Key: IGNITE-9786
> URL: https://issues.apache.org/jira/browse/IGNITE-9786
> Project: Ignite
>  Issue Type: Task
>  Components: mvcc
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Attachments: IGNITE_9786__Patch_.patch
>
>
> It seems that instead of having a lot of classes and complex synchronization 
> mechanics for MvccProcessorImpl.waitMap, we can use single wrapper with a 
> list of waiters. 
> Resulting code will be much more simpler and less prone to concurrency issues.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-9786) MVCC: simplify TX wait list management

2018-11-15 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-9786:

Ignite Flags:   (was: Docs Required)

> MVCC: simplify TX wait list management
> --
>
> Key: IGNITE-9786
> URL: https://issues.apache.org/jira/browse/IGNITE-9786
> Project: Ignite
>  Issue Type: Task
>  Components: mvcc
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Attachments: IGNITE_9786__Patch_.patch
>
>
> It seems that instead of having a lot of classes and complex synchronization 
> mechanics for MvccProcessorImpl.waitMap, we can use single wrapper with a 
> list of waiters. 
> Resulting code will be much more simpler and less prone to concurrency issues.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-10283) `control.sh --baseline` does not output other nodes when cluster is inactive

2018-11-15 Thread Max Shonichev (JIRA)
Max Shonichev created IGNITE-10283:
--

 Summary: `control.sh --baseline` does not output other nodes when 
cluster is inactive
 Key: IGNITE-10283
 URL: https://issues.apache.org/jira/browse/IGNITE-10283
 Project: Ignite
  Issue Type: Bug
Reporter: Max Shonichev
 Fix For: 2.7


1. start 2 nodes from clean LFS
2. control.sh --baseline
expected: 0 baseline nodes, 2 other nodes
actual: 0 baseline nodes, 0 other nodes, BUG

{noformat}
Control utility [ver. 2.5.1-p150#20181101-sha1:b46a69df]
2018 Copyright(C) Apache Software Foundation
User: mshonichev

Cluster state: inactive
Current topology version: 2

Baseline nodes not found.

{noformat}




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-10282) control.sh: implement proper shell arguments escaping due to the possible usage of regular expression in --cache command

2018-11-15 Thread Max Shonichev (JIRA)
Max Shonichev created IGNITE-10282:
--

 Summary: control.sh: implement proper shell arguments escaping due 
to the possible usage of regular expression in --cache command
 Key: IGNITE-10282
 URL: https://issues.apache.org/jira/browse/IGNITE-10282
 Project: Ignite
  Issue Type: Bug
Reporter: Max Shonichev
 Fix For: 2.7


mandatory argument regexPattern after --cache list command is not 
shell-escaped, which leads to unexpected behaviour

{noformat}
$ IGNITE_HOME=`pwd` bin/control.sh --cache list '*' --config
Control utility [ver. 2.5.1-p150#20181101-sha1:b46a69df]
2018 Copyright(C) Apache Software Foundation
User: mshonichev

Check arguments.
Error: Invalid UUID string: benchmarks
{noformat}

{noformat}
$ IGNITE_HOME=`pwd` bin/control.sh --cache list '.*' --config
Control utility [ver. 2.5.1-p150#20181101-sha1:b46a69df]
2018 Copyright(C) Apache Software Foundation
User: mshonichev

Check arguments.
Error: Invalid UUID string: ..
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-10253) Merge SqlQuery logic with SqlFieldsQuery

2018-11-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-10253:
-

Github user devozerov closed the pull request at:

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


> Merge SqlQuery logic with SqlFieldsQuery
> 
>
> Key: IGNITE-10253
> URL: https://issues.apache.org/jira/browse/IGNITE-10253
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.8
>
>
> Currently execution of {{SqlQuery}} query is very non-trivial. First, it is 
> complex to understand. Second, it duplicates code. Third, the most important 
> - it is buggy. Because when new logic is added to {{SqlFieldsQuery}} it is 
> not added to {{SqlQuery}} with high probability. Moreover, we even have 
> discrepancies between local and non-local modes. E.g. it has different value 
> conversion logic. 
> We need to do the following:
> 1) Remove all {{SqlQuery}}-specific logic from {{GridQueryProcessor}} and 
> {{IgniteH2Indexing}}
> 2) Make {{SqlQuery}} work as follows: 
> - generate {{SqlFieldsQuery}} from {{SqlQuery}}
> - execute it
> - convert results to K-V pairs



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10253) Merge SqlQuery logic with SqlFieldsQuery

2018-11-15 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-10253:
-
Ignite Flags:   (was: Docs Required)

> Merge SqlQuery logic with SqlFieldsQuery
> 
>
> Key: IGNITE-10253
> URL: https://issues.apache.org/jira/browse/IGNITE-10253
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.8
>
>
> Currently execution of {{SqlQuery}} query is very non-trivial. First, it is 
> complex to understand. Second, it duplicates code. Third, the most important 
> - it is buggy. Because when new logic is added to {{SqlFieldsQuery}} it is 
> not added to {{SqlQuery}} with high probability. Moreover, we even have 
> discrepancies between local and non-local modes. E.g. it has different value 
> conversion logic. 
> We need to do the following:
> 1) Remove all {{SqlQuery}}-specific logic from {{GridQueryProcessor}} and 
> {{IgniteH2Indexing}}
> 2) Make {{SqlQuery}} work as follows: 
> - generate {{SqlFieldsQuery}} from {{SqlQuery}}
> - execute it
> - convert results to K-V pairs



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-10253) Merge SqlQuery logic with SqlFieldsQuery

2018-11-15 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov commented on IGNITE-10253:
--

Inspections - false positive.
Cache 1, PDS 2 - unrelated hangs, as per log
Compute (Affinity Run) - faulty test, fails even in master. Muted, as it 
already hadn't worked properly (see it's body).

> Merge SqlQuery logic with SqlFieldsQuery
> 
>
> Key: IGNITE-10253
> URL: https://issues.apache.org/jira/browse/IGNITE-10253
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.8
>
>
> Currently execution of {{SqlQuery}} query is very non-trivial. First, it is 
> complex to understand. Second, it duplicates code. Third, the most important 
> - it is buggy. Because when new logic is added to {{SqlFieldsQuery}} it is 
> not added to {{SqlQuery}} with high probability. Moreover, we even have 
> discrepancies between local and non-local modes. E.g. it has different value 
> conversion logic. 
> We need to do the following:
> 1) Remove all {{SqlQuery}}-specific logic from {{GridQueryProcessor}} and 
> {{IgniteH2Indexing}}
> 2) Make {{SqlQuery}} work as follows: 
> - generate {{SqlFieldsQuery}} from {{SqlQuery}}
> - execute it
> - convert results to K-V pairs



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-10278) The checkpointReadLock must be acquired before calling MvccProcessor.updateState

2018-11-15 Thread Ignite TC Bot (JIRA)


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

Ignite TC Bot commented on IGNITE-10278:


{panel:title=Possible 
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Queries 2{color} [[tests 
3|https://ci.ignite.apache.org/viewLog.html?buildId=2324727]]
* IgniteBinaryCacheQueryTestSuite2: 
DynamicColumnsConcurrentTransactionalReplicatedSelfTest.testConcurrentOperationsAndNodeStartStopMultithreaded
 - 0,0% fails in last 100 master runs.

{color:#d04437}SPI{color} [[tests 
4|https://ci.ignite.apache.org/viewLog.html?buildId=2324732]]
* IgniteSpiTestSuite: 
GridTcpCommunicationSpiSslSmallBuffersSelfTest.testCheckConnection1 - 0,0% 
fails in last 100 master runs.

{color:#d04437}MVCC Cache{color} [[tests 
2|https://ci.ignite.apache.org/viewLog.html?buildId=2324749]]
* IgniteCacheMvccTestSuite: 
CacheMvccReplicatedCoordinatorFailoverTest.testReadInProgressCoordinatorFailsSimple_FromClientPutGet
 - 0,0% fails in last 100 master runs.

{color:#d04437}PDS (Direct IO) 2{color} [[tests 
4|https://ci.ignite.apache.org/viewLog.html?buildId=2324785]]
* IgnitePdsNativeIoTestSuite2: 
IgniteUidAsConsistentIdMigrationTest.testStartTwoOldStyleNodes - 0,0% fails in 
last 100 master runs.
* IgnitePdsNativeIoTestSuite2: 
IgniteUidAsConsistentIdMigrationTest.testRestartOnExistingOldStyleId - 0,0% 
fails in last 100 master runs.

{color:#d04437}Activate | Deactivate Cluster{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=2324700]]
* IgniteStandByClusterSuite: 
IgniteStandByClientReconnectTest.testActiveClientReconnectToInActiveCluster - 
0,0% fails in last 100 master runs.

{color:#d04437}Spring{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=2324728]]
* IgniteSpringTestSuite: GridFactorySelfTest.testConcurrentStartStop - 0,0% 
fails in last 100 master runs.

{color:#d04437}Inspections: Core{color} [[tests 0 BuildFailureOnMetric 
|https://ci.ignite.apache.org/viewLog.html?buildId=2324803]]

{panel}
[TeamCity Run All 
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2324807buildTypeId=IgniteTests24Java8_RunAll]

> The checkpointReadLock must be acquired before calling 
> MvccProcessor.updateState
> 
>
> Key: IGNITE-10278
> URL: https://issues.apache.org/jira/browse/IGNITE-10278
> Project: Ignite
>  Issue Type: Bug
>  Components: mvcc
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
>
> It looks like acquiring \{{checkpointReadLock}} is missing when we are trying 
> to apply mvcc tx records.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (IGNITE-9907) Wrong index field name makes the whole cluster to fail

2018-11-15 Thread Mikhail Cherkasov (JIRA)


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

Mikhail Cherkasov reassigned IGNITE-9907:
-

Assignee: (was: Mikhail Cherkasov)

> Wrong index field name makes the whole cluster to fail
> --
>
> Key: IGNITE-9907
> URL: https://issues.apache.org/jira/browse/IGNITE-9907
> Project: Ignite
>  Issue Type: Bug
>Reporter: Mikhail Cherkasov
>Priority: Critical
> Attachments: WrongFields.java
>
>
> Wrong index field name makes the whole cluster to fail and there's now 
> reliable way to restore from this state, exchange fails with the exception:
>  
> 2018-10-16 
> 14:42:56,842][ERROR][exchange-worker-#42%server_0%][GridCachePartitionExchangeManager]
>  Failed to wait for completion of partition map exchange (preloading will not 
> start): GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryCustomEvent 
> [customMsg=null, affTopVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], 
> super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=6859ef9c-cceb-4d8a-8d5b-c1cd2cd192b7, addrs=[0:0:0:0:0:0:0:1%lo0, 
> 127.0.0.1, 192.168.75.84], sockAddrs=[/192.168.75.84:0, 
> /0:0:0:0:0:0:0:1%lo0:0, /127.0.0.1:0], discPort=0, order=2, intOrder=2, 
> lastExchangeTime=1539726176458, loc=false, ver=2.4.3#19691231-sha1:, 
> isClient=true], topVer=2, nodeId8=0d8b289d, msg=null, 
> type=DISCOVERY_CUSTOM_EVT, tstamp=1539726176684]], crd=TcpDiscoveryNode 
> [id=0d8b289d-32aa-402e-8e71-137977559979, addrs=[0:0:0:0:0:0:0:1%lo0, 
> 127.0.0.1, 192.168.75.84], sockAddrs=[/192.168.75.84:47500, 
> /0:0:0:0:0:0:0:1%lo0:47500, /127.0.0.1:47500], discPort=47500, order=1, 
> intOrder=1, lastExchangeTime=1539726176493, loc=true, 
> ver=2.4.3#19691231-sha1:, isClient=false], 
> exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=2, 
> minorTopVer=1], discoEvt=DiscoveryCustomEvent [customMsg=null, 
> affTopVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], 
> super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=6859ef9c-cceb-4d8a-8d5b-c1cd2cd192b7, addrs=[0:0:0:0:0:0:0:1%lo0, 
> 127.0.0.1, 192.168.75.84], sockAddrs=[/192.168.75.84:0, 
> /0:0:0:0:0:0:0:1%lo0:0, /127.0.0.1:0], discPort=0, order=2, intOrder=2, 
> lastExchangeTime=1539726176458, loc=false, ver=2.4.3#19691231-sha1:, 
> isClient=true], topVer=2, nodeId8=0d8b289d, msg=null, 
> type=DISCOVERY_CUSTOM_EVT, tstamp=1539726176684]], nodeId=6859ef9c, 
> evt=DISCOVERY_CUSTOM_EVT], added=true, initFut=GridFutureAdapter 
> [ignoreInterrupts=false, state=DONE, res=false, hash=1240595188], init=false, 
> lastVer=null, partReleaseFut=PartitionReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], 
> futures=[ExplicitLockReleaseFuture [topVer=AffinityTopologyVersion [topVer=2, 
> minorTopVer=1], futures=[]], TxReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=2, minorTopVer=1], futures=[]], AtomicUpdateReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], futures=[]], 
> DataStreamerReleaseFuture [topVer=AffinityTopologyVersion [topVer=2, 
> minorTopVer=1], futures=[, exchActions=null, affChangeMsg=null, 
> initTs=1539726176695, centralizedAff=false, forceAffReassignment=false, 
> changeGlobalStateE=null, done=true, state=CRD, evtLatch=0, remaining=[], 
> super=GridFutureAdapter [ignoreInterrupts=false, state=DONE, 
> res=java.lang.IndexOutOfBoundsException: Index: 0, Size: 0, hash=1559339235]]
> class org.apache.ignite.IgniteCheckedException: Index: 0, Size: 0
>  at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7332)
>  at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:259)
>  at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:207)
>  at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
>  at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2374)
>  at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>  at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
>  at java.util.ArrayList.rangeCheck(ArrayList.java:657)
>  at java.util.ArrayList.get(ArrayList.java:433)
>  at 
> org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:374)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.(GridDhtLocalPartition.java:194)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.getOrCreatePartition(GridDhtPartitionTopologyImpl.java:816)
>  at 
> 

[jira] [Updated] (IGNITE-10263) MVCC: Concurrent cache stop can cause vacuum failure.

2018-11-15 Thread Andrew Mashenkov (JIRA)


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

Andrew Mashenkov updated IGNITE-10263:
--
Description: 
 

Vacuum.cleanup() can fails on cctx.gate().enter() if cache is stopped 
concurrently.
ctx.gate().enter() method fails with IllegalStateException and we've got 
stacktrace in log for every cache partition.

Replacing enter() with enterIfNotStopped() resolves the issue.

  was:
The issue can be easily reproduced with IgniteCacheIncrementTxTest in Mvcc mode.

 

Vacuum.cleanup() fails on cctx.gate().enter() if cache is stopped concurrently.

ctx.gate().enter() method fails with IllegalStateException right after readLock 
has been taken.
 So, this lock will be never released and prevent writeLock being taken on node 
stop.

Replacing enter() with enterIfNotStopped() resolves the issue, but most likely 
we should release readLock on failure inside gateway.enter().


> MVCC: Concurrent cache stop can cause vacuum failure.
> -
>
> Key: IGNITE-10263
> URL: https://issues.apache.org/jira/browse/IGNITE-10263
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, mvcc
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Minor
>  Labels: Hanging
>
>  
> Vacuum.cleanup() can fails on cctx.gate().enter() if cache is stopped 
> concurrently.
> ctx.gate().enter() method fails with IllegalStateException and we've got 
> stacktrace in log for every cache partition.
> Replacing enter() with enterIfNotStopped() resolves the issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10263) MVCC: Concurrent cache stop can cause vacuum failure.

2018-11-15 Thread Andrew Mashenkov (JIRA)


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

Andrew Mashenkov updated IGNITE-10263:
--
Priority: Minor  (was: Critical)

> MVCC: Concurrent cache stop can cause vacuum failure.
> -
>
> Key: IGNITE-10263
> URL: https://issues.apache.org/jira/browse/IGNITE-10263
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, mvcc
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Minor
>  Labels: Hanging
>
> The issue can be easily reproduced with IgniteCacheIncrementTxTest in Mvcc 
> mode.
>  
> Vacuum.cleanup() fails on cctx.gate().enter() if cache is stopped 
> concurrently.
> ctx.gate().enter() method fails with IllegalStateException right after 
> readLock has been taken.
>  So, this lock will be never released and prevent writeLock being taken on 
> node stop.
> Replacing enter() with enterIfNotStopped() resolves the issue, but most 
> likely we should release readLock on failure inside gateway.enter().



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (IGNITE-10263) MVCC: Concurrent cache stop can cause vacuum failure.

2018-11-15 Thread Andrew Mashenkov (JIRA)


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

Andrew Mashenkov reassigned IGNITE-10263:
-

Assignee: (was: Andrew Mashenkov)

> MVCC: Concurrent cache stop can cause vacuum failure.
> -
>
> Key: IGNITE-10263
> URL: https://issues.apache.org/jira/browse/IGNITE-10263
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, mvcc
>Reporter: Andrew Mashenkov
>Priority: Minor
>  Labels: Hanging
>
>  
> Vacuum.cleanup() can fails on cctx.gate().enter() if cache is stopped 
> concurrently.
> ctx.gate().enter() method fails with IllegalStateException and we've got 
> stacktrace in log for every cache partition.
> Replacing enter() with enterIfNotStopped() resolves the issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-10207) Missed loss policy checks

2018-11-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-10207:
-

Github user asfgit closed the pull request at:

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


> Missed loss policy checks
> -
>
> Key: IGNITE-10207
> URL: https://issues.apache.org/jira/browse/IGNITE-10207
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Critical
> Fix For: 2.8
>
>
> In some cases (client reconnect, new client join, etc) PartitionLossPolicy 
> may incorrectly validate operation. Return null for READ_ONLY_SAFE for loss 
> partition.
> To reproduce run CacheResultIsNotNullOnPartitionLossTest (1000 times) with 
> random node stop.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-10207) Missed loss policy checks

2018-11-15 Thread Dmitriy Govorukhin (JIRA)


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

Dmitriy Govorukhin commented on IGNITE-10207:
-

Merged to master.

> Missed loss policy checks
> -
>
> Key: IGNITE-10207
> URL: https://issues.apache.org/jira/browse/IGNITE-10207
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Critical
> Fix For: 2.8
>
>
> In some cases (client reconnect, new client join, etc) PartitionLossPolicy 
> may incorrectly validate operation. Return null for READ_ONLY_SAFE for loss 
> partition.
> To reproduce run CacheResultIsNotNullOnPartitionLossTest (1000 times) with 
> random node stop.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (IGNITE-10197) unexpected IllegalArgumentException in IgniteDbPutGetAbstractTest#testRandomPutGetRemove

2018-11-15 Thread Ivan Bessonov (JIRA)


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

Ivan Bessonov reassigned IGNITE-10197:
--

Assignee: Ivan Bessonov

> unexpected IllegalArgumentException in 
> IgniteDbPutGetAbstractTest#testRandomPutGetRemove
> 
>
> Key: IGNITE-10197
> URL: https://issues.apache.org/jira/browse/IGNITE-10197
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Ivan Bessonov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> IgniteDbPutGetAbstractTest#testRandomPutGetRemove (in current codebase muted 
> by renaming to {{_testRandomPutGetRemove}}) fails with IAE:
> {noformat}java.lang.IllegalArgumentException: Ouch! Argument is invalid: 
> Cache name must not be null or empty.
>   at 
> org.apache.ignite.internal.util.GridArgumentCheck.ensure(GridArgumentCheck.java:109)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.validateCacheName(GridCacheUtils.java:1600)
>   at org.apache.ignite.internal.IgniteKernal.cache(IgniteKernal.java:2901)
>   at 
> org.apache.ignite.internal.processors.database.IgniteDbPutGetAbstractTest.cache(IgniteDbPutGetAbstractTest.java:74)
>   at 
> org.apache.ignite.internal.processors.database.IgniteDbPutGetAbstractTest.testRandomPutGetRemove(IgniteDbPutGetAbstractTest.java:814)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2208)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:144)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2124)
>   at java.lang.Thread.run(Thread.java:745){noformat}
> Note a while ago this test was muted by adding underscore prefix to its name 
> per [commit 
> 2e343b6|https://github.com/apache/ignite/commit/4282d802f16188cdea05d6b2d2c0f3c222e343b6]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-10281) Log to file all jars in classpath on start node.

2018-11-15 Thread Sergey Antonov (JIRA)
Sergey Antonov created IGNITE-10281:
---

 Summary: Log to file all jars in classpath on start node.
 Key: IGNITE-10281
 URL: https://issues.apache.org/jira/browse/IGNITE-10281
 Project: Ignite
  Issue Type: Improvement
Reporter: Sergey Antonov
 Fix For: 2.8


We should print all jars in classpath for analize jar's hell.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-10207) Missed loss policy checks

2018-11-15 Thread Ignite TC Bot (JIRA)


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

Ignite TC Bot commented on IGNITE-10207:


{panel:title=No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All 
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2315776buildTypeId=IgniteTests24Java8_RunAll]

> Missed loss policy checks
> -
>
> Key: IGNITE-10207
> URL: https://issues.apache.org/jira/browse/IGNITE-10207
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Critical
> Fix For: 2.8
>
>
> In some cases (client reconnect, new client join, etc) PartitionLossPolicy 
> may incorrectly validate operation. Return null for READ_ONLY_SAFE for loss 
> partition.
> To reproduce run CacheResultIsNotNullOnPartitionLossTest (1000 times) with 
> random node stop.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-10278) The checkpointReadLock must be acquired before calling MvccProcessor.updateState

2018-11-15 Thread Vyacheslav Koptilin (JIRA)


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

Vyacheslav Koptilin commented on IGNITE-10278:
--

[~amashenkov] could you please take a look at this pull-request?

> The checkpointReadLock must be acquired before calling 
> MvccProcessor.updateState
> 
>
> Key: IGNITE-10278
> URL: https://issues.apache.org/jira/browse/IGNITE-10278
> Project: Ignite
>  Issue Type: Bug
>  Components: mvcc
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
>
> It looks like acquiring \{{checkpointReadLock}} is missing when we are trying 
> to apply mvcc tx records.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-10278) The checkpointReadLock must be acquired before calling MvccProcessor.updateState

2018-11-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-10278:
-

GitHub user sk0x50 opened a pull request:

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

IGNITE-10278 The checkpointReadLock must be acquired before calling 
MvccProcessor.updateState



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

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

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

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


commit beaf05fbef68fb7933738a501533317158566abe
Author: Slava Koptilin 
Date:   2018-11-15T15:07:33Z

IGNITE-10278 The checkpointReadLock must be acquired before calling 
MvccProcessor.updateState




> The checkpointReadLock must be acquired before calling 
> MvccProcessor.updateState
> 
>
> Key: IGNITE-10278
> URL: https://issues.apache.org/jira/browse/IGNITE-10278
> Project: Ignite
>  Issue Type: Bug
>  Components: mvcc
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
>
> It looks like acquiring \{{checkpointReadLock}} is missing when we are trying 
> to apply mvcc tx records.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-10280) Create Yardstick IgniteGetAllTxBenchmark

2018-11-15 Thread Ivan Artukhov (JIRA)
Ivan Artukhov created IGNITE-10280:
--

 Summary: Create Yardstick IgniteGetAllTxBenchmark
 Key: IGNITE-10280
 URL: https://issues.apache.org/jira/browse/IGNITE-10280
 Project: Ignite
  Issue Type: Improvement
  Components: yardstick
Reporter: Ivan Artukhov


Yardstick module has no transactional getAll benchmark. Only atomic 
IgniteGetAllBenchmark.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10279) Control.sh utility unify options naming format

2018-11-15 Thread Sergey Antonov (JIRA)


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

Sergey Antonov updated IGNITE-10279:

Description: 
Now we have options in several styles:
{noformat}
--ping-interval 
{noformat}
{noformat}
--skipZeros
{noformat}
I think, we must unify options naming format and we should use linux like 
format, i.e. {{--word1-word2}}

 

  was:
Now we have options in several styles:  
{noformat}
--ping-interval 
{noformat}
{noformat}
--skipZeros
{noformat}
I think, we must unify options naming format. We should follow linux format, 
i.e. {{--word1-word2}}

 


> Control.sh utility unify options naming format
> --
>
> Key: IGNITE-10279
> URL: https://issues.apache.org/jira/browse/IGNITE-10279
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
>
> Now we have options in several styles:
> {noformat}
> --ping-interval 
> {noformat}
> {noformat}
> --skipZeros
> {noformat}
> I think, we must unify options naming format and we should use linux like 
> format, i.e. {{--word1-word2}}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10279) Control.sh utility unify options naming format

2018-11-15 Thread Sergey Antonov (JIRA)


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

Sergey Antonov updated IGNITE-10279:

Description: 
Now we have options in several styles:  
{noformat}
--ping-interval 
{noformat}
{noformat}
--skipZeros
{noformat}
I think, we must unify options naming format. We should follow linux format, 
i.e. {{--word1-word2}}

 

  was:
Now we have options in several styles:  --ping-interval , --skipZeros. 
I think, we must unify options naming format. We should follow linux format, 
i.e. --word1-word2

 


> Control.sh utility unify options naming format
> --
>
> Key: IGNITE-10279
> URL: https://issues.apache.org/jira/browse/IGNITE-10279
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
>
> Now we have options in several styles:  
> {noformat}
> --ping-interval 
> {noformat}
> {noformat}
> --skipZeros
> {noformat}
> I think, we must unify options naming format. We should follow linux format, 
> i.e. {{--word1-word2}}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10279) Control.sh utility unify options naming format

2018-11-15 Thread Sergey Antonov (JIRA)


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

Sergey Antonov updated IGNITE-10279:

Description: 
Now we have options in several styles:  --ping-interval , --skipZeros. 
I think, we must unify options naming format. We should follow linux format, 
i.e. --word1-word2

 

  was:
Now we have options in several styles:  --ping-interval, --skipZeros. 
I think, we must unify options naming format. We should follow linux format, 
i.e. --word1-word2

 


> Control.sh utility unify options naming format
> --
>
> Key: IGNITE-10279
> URL: https://issues.apache.org/jira/browse/IGNITE-10279
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
>
> Now we have options in several styles:  --ping-interval , --skipZeros. 
> I think, we must unify options naming format. We should follow linux format, 
> i.e. --word1-word2
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-10279) Control.sh utility unify options naming format

2018-11-15 Thread Sergey Antonov (JIRA)
Sergey Antonov created IGNITE-10279:
---

 Summary: Control.sh utility unify options naming format
 Key: IGNITE-10279
 URL: https://issues.apache.org/jira/browse/IGNITE-10279
 Project: Ignite
  Issue Type: Improvement
Reporter: Sergey Antonov
Assignee: Sergey Antonov
 Fix For: 2.8


Now we have options in several styles:  --ping-interval, --skipZeros. 
I think, we must unify options naming format. We should follow linux format, 
i.e. --word1-word2

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-10244) Peer classloading creates a new class on each call for nested compute tasks

2018-11-15 Thread Evgenii Zhuravlev (JIRA)


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

Evgenii Zhuravlev commented on IGNITE-10244:


Hi Yakov,

I've rewritten the test to use Junit. Looks like it's the regression after the 
fix that David mentioned: 
https://github.com/apache/ignite/commit/d2050237ee2b760d1c9cbc906b281790fd0976b4#diff-3fae20691c16a617d0c6158b0f61df3c.
 Also, it's not reproducible with CONTINUOUS mode.


> Peer classloading creates a new class on each call for nested compute tasks
> ---
>
> Key: IGNITE-10244
> URL: https://issues.apache.org/jira/browse/IGNITE-10244
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Mikhail Cherkasov
>Priority: Critical
> Attachments: IGNITE_10244_Test_for_metaspace_OOM.patch, 
> JustServer.java, MyCall.java, NestedCall.java, Test.java
>
>
> If a compute task has embedded compute tasks, embeded task will be loaded by 
> peer class loading as a new class on each call, which leads to metadata OOM.
> Reproducer is attached. Make sure that you run ignite nodes with 
> -XX:MaxMetaspaceSize=64m , by default JVM doesn't limit meta space size.
> Also, we need to keep client and server in different JVM to make peer 
> classloading be engaged.
> So what happens:
>  # client sends compute taks MyCall to server_1
>  # server_1 execute MyCall and MyCall sends NestedCall task to server_2
>  # server_2 loads NestedCall as a new class and execute it
>  # repeat it's again and on second iteration server_2 will load NestedCall as 
> new class again, after few iterations this will lead to OOM



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10244) Peer classloading creates a new class on each call for nested compute tasks

2018-11-15 Thread Evgenii Zhuravlev (JIRA)


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

Evgenii Zhuravlev updated IGNITE-10244:
---
Attachment: IGNITE_10244_Test_for_metaspace_OOM.patch

> Peer classloading creates a new class on each call for nested compute tasks
> ---
>
> Key: IGNITE-10244
> URL: https://issues.apache.org/jira/browse/IGNITE-10244
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Mikhail Cherkasov
>Priority: Critical
> Attachments: IGNITE_10244_Test_for_metaspace_OOM.patch, 
> JustServer.java, MyCall.java, NestedCall.java, Test.java
>
>
> If a compute task has embedded compute tasks, embeded task will be loaded by 
> peer class loading as a new class on each call, which leads to metadata OOM.
> Reproducer is attached. Make sure that you run ignite nodes with 
> -XX:MaxMetaspaceSize=64m , by default JVM doesn't limit meta space size.
> Also, we need to keep client and server in different JVM to make peer 
> classloading be engaged.
> So what happens:
>  # client sends compute taks MyCall to server_1
>  # server_1 execute MyCall and MyCall sends NestedCall task to server_2
>  # server_2 loads NestedCall as a new class and execute it
>  # repeat it's again and on second iteration server_2 will load NestedCall as 
> new class again, after few iterations this will lead to OOM



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-10278) The checkpointReadLock must be acquired before calling MvccProcessor.updateState

2018-11-15 Thread Vyacheslav Koptilin (JIRA)
Vyacheslav Koptilin created IGNITE-10278:


 Summary: The checkpointReadLock must be acquired before calling 
MvccProcessor.updateState
 Key: IGNITE-10278
 URL: https://issues.apache.org/jira/browse/IGNITE-10278
 Project: Ignite
  Issue Type: Bug
  Components: mvcc
Affects Versions: 2.7
Reporter: Vyacheslav Koptilin
Assignee: Vyacheslav Koptilin
 Fix For: 2.8


It looks like acquiring \{{checkpointReadLock}} is missing when we are trying 
to apply mvcc tx records.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10277) Transaction prepare-commit ordering is violated in one-phase commit scenario

2018-11-15 Thread Ivan Rakov (JIRA)


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

Ivan Rakov updated IGNITE-10277:

Attachment: IGNITE_10277_reproducer.patch

> Transaction prepare-commit ordering is violated in one-phase commit scenario
> 
>
> Key: IGNITE-10277
> URL: https://issues.apache.org/jira/browse/IGNITE-10277
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Rakov
>Priority: Major
> Fix For: 2.8
>
> Attachments: IGNITE_10277_reproducer.patch
>
>
> Basic transactions invariant (all prepares should happen-before all commits) 
> is violated in one-phase commit scenario.
> Reproducer is attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10277) Transaction prepare-commit ordering is violated in one-phase commit scenario

2018-11-15 Thread Ivan Rakov (JIRA)


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

Ivan Rakov updated IGNITE-10277:

Summary: Transaction prepare-commit ordering is violated in one-phase 
commit scenario  (was: Prepare-commit ordering is violated for one-phase commit 
transactions)

> Transaction prepare-commit ordering is violated in one-phase commit scenario
> 
>
> Key: IGNITE-10277
> URL: https://issues.apache.org/jira/browse/IGNITE-10277
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Rakov
>Priority: Major
> Fix For: 2.8
>
>
> Basic transactions invariant (all prepares should happen-before all commits) 
> is violated in one-phase commit scenario.
> Reproducer is attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-10277) Prepare-commit ordering is violated for one-phase commit transactions

2018-11-15 Thread Ivan Rakov (JIRA)
Ivan Rakov created IGNITE-10277:
---

 Summary: Prepare-commit ordering is violated for one-phase commit 
transactions
 Key: IGNITE-10277
 URL: https://issues.apache.org/jira/browse/IGNITE-10277
 Project: Ignite
  Issue Type: Improvement
Reporter: Ivan Rakov
 Fix For: 2.8


Basic transactions invariant (all prepares should happen-before all commits) is 
violated in one-phase commit scenario.
Reproducer is attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-10009) ODBC: SQLColumns does not work for tables with escape sequences in name

2018-11-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-10009:
-

Github user asfgit closed the pull request at:

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


> ODBC: SQLColumns does not work for tables with escape sequences in name
> ---
>
> Key: IGNITE-10009
> URL: https://issues.apache.org/jira/browse/IGNITE-10009
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
>  Labels: odbc
> Fix For: 2.8
>
>
> Table names with escaped underscore '\_' or percent '\%' characters is not 
> recognized by the ODBC driver. I.e. the following table pattern:
> {noformat}
> TEST\_TABLE
> {noformat}
> Should match the following table:
> {noformat}
> TEST_TABLE
> {noformat}
> But currently it does not. Needs to be fixed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-10276) MVCC TX: Optimize logger creations

2018-11-15 Thread Igor Seliverstov (JIRA)
Igor Seliverstov created IGNITE-10276:
-

 Summary: MVCC TX: Optimize logger creations
 Key: IGNITE-10276
 URL: https://issues.apache.org/jira/browse/IGNITE-10276
 Project: Ignite
  Issue Type: Improvement
  Components: mvcc
Reporter: Igor Seliverstov
 Fix For: 2.8


We need to initialize loggers in all new classes like it was done in 
*GridDhtAtomicAbstractUpdateFuture* for example.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-9897) Quering with PDO returns null for all column values except the 1st one

2018-11-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-9897:


Github user asfgit closed the pull request at:

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


> Quering with PDO returns null for all column values except the 1st one
> --
>
> Key: IGNITE-9897
> URL: https://issues.apache.org/jira/browse/IGNITE-9897
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.6
> Environment: CentOS
>Reporter: Roman Shtykh
>Assignee: Igor Sapego
>Priority: Major
> Attachments: odbc.log, phpPDO2.out, phpPdo.out, unixOdbc.log
>
>
> Using _odbc_connect_ returns all column values, but with _PDO_ only the 1st 
> one – all the rest are null.
>  Reproduced on CentOS.
>  # Start a server node with Ignite CPP
>  # Run odbc-example (which will create two tables)
>  # Run a simple PHP script
> {code:php}
>  try {
> echo PHP_EOL,PHP_EOL,"# Using PDO",PHP_EOL;
> $dbh = new PDO('odbc:ApacheIgnite');
> $dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
> $sql = 'SELECT * FROM "Person".Person';
> $data = $dbh->query($sql);
> foreach($data as $row) {
> var_export($row);
>   }
> echo PHP_EOL,PHP_EOL,"# Using odbc_*( ) Functions",PHP_EOL;
>   
> $conn = odbc_connect('ApacheIgnite','','');
> $rs = odbc_exec($conn, $sql);
>   
> while($row = odbc_fetch_array($rs)) {
> var_export($row);
>   }
> 
> } catch (PDOException $e) {
> print "Error!: " . $e->getMessage() . "\n";
> die();
> }
> ?>
> {code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-10192) OptimizedMarshallerTest#testAllocationOverflow throws OOME instead of expected IOE

2018-11-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-10192:
-

GitHub user ibessonov opened a pull request:

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

IGNITE-10192 OptimizedMarshallerTest#testAllocationOverflow throws OOME 
instead of expected IOE



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

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

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

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


commit 1a45b39e522574721710d938472a3e454cd79611
Author: ibessonov 
Date:   2018-11-15T13:54:45Z

IGNITE-10192 Optimized MarshallerTest#_testAllocationOverflow. Buffer 
expansion in GridUnsafeDataOutput improved.




> OptimizedMarshallerTest#testAllocationOverflow throws OOME instead of 
> expected IOE
> --
>
> Key: IGNITE-10192
> URL: https://issues.apache.org/jira/browse/IGNITE-10192
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Ivan Bessonov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> OptimizedMarshallerTest#_testAllocationOverflow (in current codebase muted by 
> renaming to {{_testAllocationOverflow}}) throws OOME instead of expected IOE 
> when trying to marshal {{HugeObject}} - which in turn writes 4 times {{new 
> byte\[1 << 31 - 2]}}.
> Note test javadocs say: "WARNING! Requires a lot of heap space. Should not be 
> run on CI."



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-10273) CPP Thin: Client is unable to get affinity mapping in some cases

2018-11-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-10273:
-

GitHub user isapego opened a pull request:

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

IGNITE-10273: Fixed retrieval of affinity mapping



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

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

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

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


commit 904d22f164baac4f206f84b0e1276f31369c8fa2
Author: Igor Sapego 
Date:   2018-11-15T12:44:17Z

IGNITE-10273: Added test that shows the issue

commit 4a86945cb3ea11d77978ecabe35f836afa29d10f
Author: Igor Sapego 
Date:   2018-11-15T12:46:56Z

IGNITE-10273: Fix




> CPP Thin: Client is unable to get affinity mapping in some cases
> 
>
> Key: IGNITE-10273
> URL: https://issues.apache.org/jira/browse/IGNITE-10273
> Project: Ignite
>  Issue Type: Bug
>  Components: thin client
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
>  Labels: cpp
> Fix For: 2.8
>
>
> Reproducer test:
> {code:cpp}
> BOOST_AUTO_TEST_CASE(CacheClientDefaultDynamicCacheThreeNodes)
> {
> StartNode("node1");
> StartNode("node2");
> IgniteClientConfiguration cfg;
> cfg.SetEndPoints("127.0.0.1:0..11120");
> IgniteClient client = IgniteClient::Start(cfg);
> cache::CacheClient cache =
> client.CreateCache("defaultdynamic3");
> cache.RefreshAffinityMapping();
> for (int64_t i = 1; i < 1000; ++i)
> cache.Put(ignite::common::LexicalCast(i * 39916801), i * 
> 5039);
> for (int64_t i = 1; i < 1000; ++i)
> {
> int64_t val;
> LocalPeek(cache, ignite::common::LexicalCast(i * 
> 39916801), val);
> BOOST_CHECK_EQUAL(val, i * 5039);
> }
> }
> {code:cpp}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-9622) MVCC Cache API: prohibit non PESSIMISTIC REPEATABLE_READ transactions

2018-11-15 Thread Igor Seliverstov (JIRA)


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

Igor Seliverstov commented on IGNITE-9622:
--

[~Pavlukhin], looks good except one thing; yes, it's a bad way to throw SQL 
exceptions from generic methods (which used by both Cache API and SQL) but 
anyway we need to convert such exceptions to SQL ones with right error codes 
for DML calls.

Please add cache exceptions to sql ones conversion.

> MVCC Cache API: prohibit non PESSIMISTIC REPEATABLE_READ transactions
> -
>
> Key: IGNITE-9622
> URL: https://issues.apache.org/jira/browse/IGNITE-9622
> Project: Ignite
>  Issue Type: Bug
>  Components: mvcc
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.8
>
>
> For cache with enabled mvcc we should allow running only PESSIMISTIC 
> REPEATABLE_READ transactions. For other modes exception should be thrown 
> (like is done for SQL API).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-9992) Add some command to calculate hash sum per primary partition in product

2018-11-15 Thread Vyacheslav Koptilin (JIRA)


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

Vyacheslav Koptilin updated IGNITE-9992:

Summary: Add some command to calculate hash sum per primary partition in 
product  (was: Add some command to calculate hast sum per primary partition in 
product)

> Add some command to calculate hash sum per primary partition in product
> ---
>
> Key: IGNITE-9992
> URL: https://issues.apache.org/jira/browse/IGNITE-9992
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.7
>Reporter: ARomantsov
>Priority: Major
>
> Some util to quick check cluster data is ok
> Or mode to control.sh --cache idle_verify --dump to calculate primary without 
> log node info
> Example
> Cache - 1:
> Part - hash
> 1 - 13123213213
> 2 - 1313123213
> ... etc



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (IGNITE-10257) Control.sh utility should request a SSL keystore password and SSL truststore password if necessary

2018-11-15 Thread Sergey Antonov (JIRA)


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

Sergey Antonov reassigned IGNITE-10257:
---

Assignee: Sergey Antonov

> Control.sh utility should request a SSL keystore password and SSL truststore 
> password if necessary
> --
>
> Key: IGNITE-10257
> URL: https://issues.apache.org/jira/browse/IGNITE-10257
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
>
> Using passwords (–ssl_key_strore_password and --ssl_trust_store_password) in 
> command line parametrs is not safe. We must request them if necessary.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10273) CPP Thin: Client is unable to get affinity mapping in some cases

2018-11-15 Thread Igor Sapego (JIRA)


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

Igor Sapego updated IGNITE-10273:
-
Description: 
Reproducer test:

{code:cpp}
BOOST_AUTO_TEST_CASE(CacheClientDefaultDynamicCacheThreeNodes)
{
StartNode("node1");
StartNode("node2");

IgniteClientConfiguration cfg;
cfg.SetEndPoints("127.0.0.1:0..11120");

IgniteClient client = IgniteClient::Start(cfg);

cache::CacheClient cache =
client.CreateCache("defaultdynamic3");

cache.RefreshAffinityMapping();

for (int64_t i = 1; i < 1000; ++i)
cache.Put(ignite::common::LexicalCast(i * 39916801), i * 
5039);

for (int64_t i = 1; i < 1000; ++i)
{
int64_t val;
LocalPeek(cache, ignite::common::LexicalCast(i * 
39916801), val);

BOOST_CHECK_EQUAL(val, i * 5039);
}
}
{code}

  was:
Reproducer test:

{code:cpp}
BOOST_AUTO_TEST_CASE(CacheClientDefaultDynamicCacheThreeNodes)
{
StartNode("node1");
StartNode("node2");

IgniteClientConfiguration cfg;
cfg.SetEndPoints("127.0.0.1:0..11120");

IgniteClient client = IgniteClient::Start(cfg);

cache::CacheClient cache =
client.CreateCache("defaultdynamic3");

cache.RefreshAffinityMapping();

for (int64_t i = 1; i < 1000; ++i)
cache.Put(ignite::common::LexicalCast(i * 39916801), i * 
5039);

for (int64_t i = 1; i < 1000; ++i)
{
int64_t val;
LocalPeek(cache, ignite::common::LexicalCast(i * 
39916801), val);

BOOST_CHECK_EQUAL(val, i * 5039);
}
}
{code:cpp}


> CPP Thin: Client is unable to get affinity mapping in some cases
> 
>
> Key: IGNITE-10273
> URL: https://issues.apache.org/jira/browse/IGNITE-10273
> Project: Ignite
>  Issue Type: Bug
>  Components: thin client
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
>  Labels: cpp
> Fix For: 2.8
>
>
> Reproducer test:
> {code:cpp}
> BOOST_AUTO_TEST_CASE(CacheClientDefaultDynamicCacheThreeNodes)
> {
> StartNode("node1");
> StartNode("node2");
> IgniteClientConfiguration cfg;
> cfg.SetEndPoints("127.0.0.1:0..11120");
> IgniteClient client = IgniteClient::Start(cfg);
> cache::CacheClient cache =
> client.CreateCache("defaultdynamic3");
> cache.RefreshAffinityMapping();
> for (int64_t i = 1; i < 1000; ++i)
> cache.Put(ignite::common::LexicalCast(i * 39916801), i * 
> 5039);
> for (int64_t i = 1; i < 1000; ++i)
> {
> int64_t val;
> LocalPeek(cache, ignite::common::LexicalCast(i * 
> 39916801), val);
> BOOST_CHECK_EQUAL(val, i * 5039);
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10246) StandaloneWALRecordIterator must throw checkBounds exception

2018-11-15 Thread Ivan Rakov (JIRA)


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

Ivan Rakov updated IGNITE-10246:

Fix Version/s: 2.8

> StandaloneWALRecordIterator must throw checkBounds exception
> 
>
> Key: IGNITE-10246
> URL: https://issues.apache.org/jira/browse/IGNITE-10246
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexey Stelmak
>Assignee: Alexey Stelmak
>Priority: Major
> Fix For: 2.8
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-10246) StandaloneWALRecordIterator must throw checkBounds exception

2018-11-15 Thread Alexey Stelmak (JIRA)


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

Alexey Stelmak commented on IGNITE-10246:
-

PR: https://github.com/apache/ignite/pull/5398

> StandaloneWALRecordIterator must throw checkBounds exception
> 
>
> Key: IGNITE-10246
> URL: https://issues.apache.org/jira/browse/IGNITE-10246
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexey Stelmak
>Assignee: Alexey Stelmak
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10274) MVCC: Optimize get from local backup.

2018-11-15 Thread Andrew Mashenkov (JIRA)


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

Andrew Mashenkov updated IGNITE-10274:
--
Issue Type: Improvement  (was: Bug)

> MVCC: Optimize get from local backup.
> -
>
> Key: IGNITE-10274
> URL: https://issues.apache.org/jira/browse/IGNITE-10274
> Project: Ignite
>  Issue Type: Improvement
>  Components: mvcc
>Affects Versions: 2.7
>Reporter: Andrew Mashenkov
>Priority: Minor
>  Labels: performance
>
> Fix test GridCachePartitionedGetSelfTest.testGetFromBackupNode().
> Get from local backup with readFromBackup=true should not create 
> SingleGetRequest.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-10275) [TC Bot] Several JIRA comments are issued in case ignite.cache.remove failed

2018-11-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-10275:
-

asfgit closed pull request #72: IGNITE-10275 Jira spam fast fix
URL: https://github.com/apache/ignite-teamcity-bot/pull/72
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/ObserverTask.java
 
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/ObserverTask.java
index 5ad13505..86768688 100644
--- 
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/ObserverTask.java
+++ 
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/ObserverTask.java
@@ -141,7 +141,7 @@ protected String runObserverTask() {
 
 if (info.isFinishedWithFailures(teamcity)) {
 boolean rmv = compactInfos().remove(compactInfo);
-
+
 Preconditions.checkState(rmv, "Key not found: " + compactInfo);
 
 logger.error("JIRA will not be commented." +
@@ -157,34 +157,35 @@ protected String runObserverTask() {
 continue;
 }
 
-ICredentialsProv creds = tcHelper.getServerAuthorizerCreds();
+try {
+rmvdVisas.add(objMapper.writeValueAsString(compactInfo));
+}
+catch (Exception e) {
+logger.error("JSON string parse failed: " + e.getMessage(), e);
 
-Visa visa = jiraIntegration.notifyJira(info.srvId, creds, 
info.buildTypeId,
-info.branchForTc, info.ticket);
+return "Exception while JSON parsing: " + 
e.getClass().getSimpleName() + ": " + e.getMessage();
+}
 
-
visasHistoryStorage.updateVisaRequestRes(info.getContributionKey(), info.date, 
visa);
+try {
+boolean rmv = compactInfos().remove(compactInfo);
 
-if (visa.isSuccess()) {
-ticketsNotified.add(info.ticket);
+if (!rmv)
+continue;
+}
+catch (Exception e) {
+logger.error("cache remove: " + e.getMessage(), e);
+
+return X.getFullStackTrace(e);
+}
 
-try {
-rmvdVisas.add(objMapper.writeValueAsString(compactInfo));
-}
-catch (Exception e) {
-logger.error("JSON string parse failed: " + 
e.getMessage(), e);
+ICredentialsProv creds = tcHelper.getServerAuthorizerCreds();
 
-return "Exception while JSON parsing: " + 
e.getClass().getSimpleName() + ": " + e.getMessage();
-}
+Visa visa = jiraIntegration.notifyJira(info.srvId, creds, 
info.buildTypeId,
+info.branchForTc, info.ticket);
 
-try {
-compactInfos().remove(compactInfo);
-}
-catch (Exception e) {
-logger.error("cache remove: " + e.getMessage(), e);
+
visasHistoryStorage.updateVisaRequestRes(info.getContributionKey(), info.date, 
visa);
 
-return X.getFullStackTrace(e);
-}
-}
+ticketsNotified.add(info.ticket);
 }
 
 return "Checked " + checkedBuilds + " not finished " + 
notFinishedBuilds + " notified: " + ticketsNotified +


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> [TC Bot] Several JIRA comments are issued in case ignite.cache.remove failed
> 
>
> Key: IGNITE-10275
> URL: https://issues.apache.org/jira/browse/IGNITE-10275
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: PetrovMikhail
>Priority: Major
>
> Examples of spam:
> - https://issues.apache.org/jira/browse/IGNITE-9308
> - https://issues.apache.org/jira/browse/IGNITE-10141
> org/apache/ignite/ci/observer/ObserverTask.java:179
> org.apache.ignite.IgniteCache#remove(K)
> returns false, so bot tries to re-comment ticket in next cycle.
> It is possible as a fast fix at first check removes result, as a full fix we 
> can refactor visa requests queue to some new (probably synthetic key).



--
This message was sent by 

[jira] [Commented] (IGNITE-10275) [TC Bot] Several JIRA comments are issued in case ignite.cache.remove failed

2018-11-15 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-10275:
-

ololo3000 opened a new pull request #72: IGNITE-10275 Jira spam fast fix
URL: https://github.com/apache/ignite-teamcity-bot/pull/72
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> [TC Bot] Several JIRA comments are issued in case ignite.cache.remove failed
> 
>
> Key: IGNITE-10275
> URL: https://issues.apache.org/jira/browse/IGNITE-10275
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: PetrovMikhail
>Priority: Major
>
> Examples of spam:
> - https://issues.apache.org/jira/browse/IGNITE-9308
> - https://issues.apache.org/jira/browse/IGNITE-10141
> org/apache/ignite/ci/observer/ObserverTask.java:179
> org.apache.ignite.IgniteCache#remove(K)
> returns false, so bot tries to re-comment ticket in next cycle.
> It is possible as a fast fix at first check removes result, as a full fix we 
> can refactor visa requests queue to some new (probably synthetic key).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10274) MVCC: Optimize get from local backup.

2018-11-15 Thread Andrew Mashenkov (JIRA)


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

Andrew Mashenkov updated IGNITE-10274:
--
Priority: Major  (was: Minor)

> MVCC: Optimize get from local backup.
> -
>
> Key: IGNITE-10274
> URL: https://issues.apache.org/jira/browse/IGNITE-10274
> Project: Ignite
>  Issue Type: Improvement
>  Components: mvcc
>Affects Versions: 2.7
>Reporter: Andrew Mashenkov
>Priority: Major
>  Labels: performance
>
> Fix test GridCachePartitionedGetSelfTest.testGetFromBackupNode().
> Get from local backup with readFromBackup=true should not create 
> SingleGetRequest.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10274) MVCC: Optimize get from local backup.

2018-11-15 Thread Andrew Mashenkov (JIRA)


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

Andrew Mashenkov updated IGNITE-10274:
--
Labels: performance  (was: )

> MVCC: Optimize get from local backup.
> -
>
> Key: IGNITE-10274
> URL: https://issues.apache.org/jira/browse/IGNITE-10274
> Project: Ignite
>  Issue Type: Improvement
>  Components: mvcc
>Affects Versions: 2.7
>Reporter: Andrew Mashenkov
>Priority: Major
>  Labels: performance
>
> Fix test GridCachePartitionedGetSelfTest.testGetFromBackupNode().
> Get from local backup with readFromBackup=true should not create 
> SingleGetRequest.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10274) MVCC: Optimize get from local backup.

2018-11-15 Thread Andrew Mashenkov (JIRA)


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

Andrew Mashenkov updated IGNITE-10274:
--
Affects Version/s: 2.7

> MVCC: Optimize get from local backup.
> -
>
> Key: IGNITE-10274
> URL: https://issues.apache.org/jira/browse/IGNITE-10274
> Project: Ignite
>  Issue Type: Improvement
>  Components: mvcc
>Affects Versions: 2.7
>Reporter: Andrew Mashenkov
>Priority: Major
>  Labels: performance
>
> Fix test GridCachePartitionedGetSelfTest.testGetFromBackupNode().
> Get from local backup with readFromBackup=true should not create 
> SingleGetRequest.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Reopened] (IGNITE-10246) StandaloneWALRecordIterator must throw checkBounds exception

2018-11-15 Thread Alexey Stelmak (JIRA)


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

Alexey Stelmak reopened IGNITE-10246:
-

> StandaloneWALRecordIterator must throw checkBounds exception
> 
>
> Key: IGNITE-10246
> URL: https://issues.apache.org/jira/browse/IGNITE-10246
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexey Stelmak
>Assignee: Alexey Stelmak
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10274) MVCC: Optimize get from local backup.

2018-11-15 Thread Andrew Mashenkov (JIRA)


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

Andrew Mashenkov updated IGNITE-10274:
--
Priority: Minor  (was: Major)

> MVCC: Optimize get from local backup.
> -
>
> Key: IGNITE-10274
> URL: https://issues.apache.org/jira/browse/IGNITE-10274
> Project: Ignite
>  Issue Type: Bug
>  Components: mvcc
>Reporter: Andrew Mashenkov
>Priority: Minor
>
> Fix test GridCachePartitionedGetSelfTest.testGetFromBackupNode().
> Get from local backup with readFromBackup=true should not create 
> SingleGetRequest.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-10265) PDOStatement::rowCount returns 0

2018-11-15 Thread Albert Iskhakov (JIRA)


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

Albert Iskhakov commented on IGNITE-10265:
--

I suggest changing the issue type to "Wish" and lower the priority because the 
[PHP documentation|http://php.net/manual/en/pdostatement.rowcount.php] says 
that this behavior is not guaranteed by most databases.

> PDOStatement::rowCount returns 0
> 
>
> Key: IGNITE-10265
> URL: https://issues.apache.org/jira/browse/IGNITE-10265
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 2.6
> Environment: CentOS, unixODBC
>Reporter: Roman Shtykh
>Priority: Major
>
> How to reproduce:
> {noformat}
> $ cat ~/odbc.php
>   
> try {
> echo PHP_EOL,PHP_EOL,"# Using PDO",PHP_EOL;
> $dbh = new PDO('odbc:DRIVER={ApacheIgnite};Server=127.0.0.1;PORT=10800');
> $dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
>  
> $sql = 'SELECT * FROM "Person".Person';
> $statement = $dbh->prepare($sql);
> $statement->execute();
>  
> $data = $statement->fetchAll();
>  
> foreach($data as $row) {
> var_dump($row);
> }
>  
> echo "array Count : " . count($data) . "\n";
> echo "rowCount : " . $statement->rowCount() . "\n";
>  
> } catch (PDOException $e) {
> print "Error!: " . $e->getMessage() . "\n";
> die();
> }
>  
> $ php ~/odbc.php
>  
> # Using PDO
> array(10) {
>   ["ORGID"]=>
>   string(1) "1"
>   [0]=>
>   string(1) "1"
>   ["FIRSTNAME"]=>
>   string(4) "John"
>   [1]=>
>   string(4) "John"
>   ["LASTNAME"]=>
>   string(3) "Doe"
>   [2]=>
>   string(3) "Doe"
>   ["RESUME"]=>
>   string(14) "Master Degree."
>   [3]=>
>   string(14) "Master Degree."
>   ["SALARY"]=>
>   string(4) "2200"
>   [4]=>
>   string(4) "2200"
> }
> ・
> ・
> ・
> array(10) {
>   ["ORGID"]=>
>   string(1) "2"
>   [0]=>
>   string(1) "2"
>   ["FIRSTNAME"]=>
>   string(4) "Mary"
>   [1]=>
>   string(4) "Mary"
>   ["LASTNAME"]=>
>   string(5) "Major"
>   [2]=>
>   string(5) "Major"
>   ["RESUME"]=>
>   string(16) "Bachelor Degree."
>   [3]=>
>   string(16) "Bachelor Degree."
>   ["SALARY"]=>
>   string(4) "1200"
>   [4]=>
>   string(4) "1200"
> }
> array Count : 6
> rowCount : 0
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10275) [TC Bot] Several JIRA comments are issued in case ignite.cache.remove failed

2018-11-15 Thread Dmitriy Pavlov (JIRA)


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

Dmitriy Pavlov updated IGNITE-10275:

Description: 
Examples of spam:
- https://issues.apache.org/jira/browse/IGNITE-9308
- https://issues.apache.org/jira/browse/IGNITE-10141

org/apache/ignite/ci/observer/ObserverTask.java:179
org.apache.ignite.IgniteCache#remove(K)
returns false, so bot tries to re-comment ticket in next cycle.

It is possible as a fast fix at first check removes result, as a full fix we 
can refactor visa requests queue to some new (probably synthetic key).


  was:
Example of spam: https://issues.apache.org/jira/browse/IGNITE-9308

org/apache/ignite/ci/observer/ObserverTask.java:179
org.apache.ignite.IgniteCache#remove(K)
returns false, so bot tries to re-comment ticket in next cycle.

It is possible as a fast fix at first check removes result, as a full fix we 
can refactor visa requests queue to some new (probably synthetic key).



> [TC Bot] Several JIRA comments are issued in case ignite.cache.remove failed
> 
>
> Key: IGNITE-10275
> URL: https://issues.apache.org/jira/browse/IGNITE-10275
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: PetrovMikhail
>Priority: Major
>
> Examples of spam:
> - https://issues.apache.org/jira/browse/IGNITE-9308
> - https://issues.apache.org/jira/browse/IGNITE-10141
> org/apache/ignite/ci/observer/ObserverTask.java:179
> org.apache.ignite.IgniteCache#remove(K)
> returns false, so bot tries to re-comment ticket in next cycle.
> It is possible as a fast fix at first check removes result, as a full fix we 
> can refactor visa requests queue to some new (probably synthetic key).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-10275) [TC Bot] Several JIRA comments are issued in case ignite.cache.remove failed

2018-11-15 Thread Dmitriy Pavlov (JIRA)
Dmitriy Pavlov created IGNITE-10275:
---

 Summary: [TC Bot] Several JIRA comments are issued in case 
ignite.cache.remove failed
 Key: IGNITE-10275
 URL: https://issues.apache.org/jira/browse/IGNITE-10275
 Project: Ignite
  Issue Type: Task
Reporter: Dmitriy Pavlov
Assignee: PetrovMikhail


Example of spam: https://issues.apache.org/jira/browse/IGNITE-9308

org/apache/ignite/ci/observer/ObserverTask.java:179
org.apache.ignite.IgniteCache#remove(K)
returns false, so bot tries to re-comment ticket in next cycle.

It is possible as a fast fix at first check removes result, as a full fix we 
can refactor visa requests queue to some new (probably synthetic key).




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10274) MVCC: Optimize get from local backup.

2018-11-15 Thread Andrew Mashenkov (JIRA)


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

Andrew Mashenkov updated IGNITE-10274:
--
Ignite Flags:   (was: Docs Required)

> MVCC: Optimize get from local backup.
> -
>
> Key: IGNITE-10274
> URL: https://issues.apache.org/jira/browse/IGNITE-10274
> Project: Ignite
>  Issue Type: Bug
>  Components: mvcc
>Reporter: Andrew Mashenkov
>Priority: Minor
>
> Fix test GridCachePartitionedGetSelfTest.testGetFromBackupNode().
> Get from local backup with readFromBackup=true should not create 
> SingleGetRequest.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10274) MVCC: Optimize get from local backup.

2018-11-15 Thread Andrew Mashenkov (JIRA)


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

Andrew Mashenkov updated IGNITE-10274:
--
Component/s: mvcc

> MVCC: Optimize get from local backup.
> -
>
> Key: IGNITE-10274
> URL: https://issues.apache.org/jira/browse/IGNITE-10274
> Project: Ignite
>  Issue Type: Bug
>  Components: mvcc
>Reporter: Andrew Mashenkov
>Priority: Minor
>
> Fix test GridCachePartitionedGetSelfTest.testGetFromBackupNode().
> Get from local backup with readFromBackup=true should not create 
> SingleGetRequest.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-10274) MVCC: Optimize get from local backup.

2018-11-15 Thread Andrew Mashenkov (JIRA)
Andrew Mashenkov created IGNITE-10274:
-

 Summary: MVCC: Optimize get from local backup.
 Key: IGNITE-10274
 URL: https://issues.apache.org/jira/browse/IGNITE-10274
 Project: Ignite
  Issue Type: Bug
Reporter: Andrew Mashenkov


Fix test GridCachePartitionedGetSelfTest.testGetFromBackupNode().

Get from local backup with readFromBackup=true should not create 
SingleGetRequest.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-10273) CPP Thin: Client is unable to get affinity mapping in some cases

2018-11-15 Thread Igor Sapego (JIRA)
Igor Sapego created IGNITE-10273:


 Summary: CPP Thin: Client is unable to get affinity mapping in 
some cases
 Key: IGNITE-10273
 URL: https://issues.apache.org/jira/browse/IGNITE-10273
 Project: Ignite
  Issue Type: Bug
  Components: thin client
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 2.8


Reproducer test:

{code:cpp}
BOOST_AUTO_TEST_CASE(CacheClientDefaultDynamicCacheThreeNodes)
{
StartNode("node1");
StartNode("node2");

IgniteClientConfiguration cfg;
cfg.SetEndPoints("127.0.0.1:0..11120");

IgniteClient client = IgniteClient::Start(cfg);

cache::CacheClient cache =
client.CreateCache("defaultdynamic3");

cache.RefreshAffinityMapping();

for (int64_t i = 1; i < 1000; ++i)
cache.Put(ignite::common::LexicalCast(i * 39916801), i * 
5039);

for (int64_t i = 1; i < 1000; ++i)
{
int64_t val;
LocalPeek(cache, ignite::common::LexicalCast(i * 
39916801), val);

BOOST_CHECK_EQUAL(val, i * 5039);
}
}
{code:cpp}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Issue Comment Deleted] (IGNITE-9308) Add baseline topology command to REST API

2018-11-15 Thread Dmitriy Pavlov (JIRA)


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

Dmitriy Pavlov updated IGNITE-9308:
---
Comment: was deleted

(was: {panel:title=Possible 
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Inspections: Core{color} [[tests 0 BuildFailureOnMetric 
|https://ci.ignite.apache.org/viewLog.html?buildId=2322292]]

{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=2322296]]
* ZookeeperDiscoverySpiTestSuite1: 
ZookeeperDiscoverySpiTest.testNoOpCommunicationErrorResolve_2 - 0,0% fails in 
last 100 master runs.

{panel}
[TeamCity Run All 
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2321564buildTypeId=IgniteTests24Java8_RunAll])

> Add baseline topology command to REST API 
> --
>
> Key: IGNITE-9308
> URL: https://issues.apache.org/jira/browse/IGNITE-9308
> Project: Ignite
>  Issue Type: Bug
>  Components: rest
>Affects Versions: 2.6
>Reporter: ARomantsov
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.8
>
>
> Not found in https://apacheignite.readme.io/docs/rest-api info about baseline 
> command https://apacheignite.readme.io/docs/baseline-topology



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-9308) Add baseline topology command to REST API

2018-11-15 Thread Ignite TC Bot (JIRA)


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

Ignite TC Bot commented on IGNITE-9308:
---

{panel:title=Possible 
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Inspections: Core{color} [[tests 0 BuildFailureOnMetric 
|https://ci.ignite.apache.org/viewLog.html?buildId=2322292]]

{color:#d04437}Java Client{color} [[tests 
4|https://ci.ignite.apache.org/viewLog.html?buildId=2323456]]
* IgniteClientTestSuite: JettyRestProcessorBaselineSelfTest.testBaselineRemove
* IgniteClientTestSuite: JettyRestProcessorBaselineSelfTest.testBaseline
* IgniteClientTestSuite: JettyRestProcessorBaselineSelfTest.testBaselineAdd
* IgniteClientTestSuite: JettyRestProcessorBaselineSelfTest.testBaselineSet

{panel}
[TeamCity Run All 
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2321564buildTypeId=IgniteTests24Java8_RunAll]

> Add baseline topology command to REST API 
> --
>
> Key: IGNITE-9308
> URL: https://issues.apache.org/jira/browse/IGNITE-9308
> Project: Ignite
>  Issue Type: Bug
>  Components: rest
>Affects Versions: 2.6
>Reporter: ARomantsov
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.8
>
>
> Not found in https://apacheignite.readme.io/docs/rest-api info about baseline 
> command https://apacheignite.readme.io/docs/baseline-topology



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-9308) Add baseline topology command to REST API

2018-11-15 Thread Ignite TC Bot (JIRA)


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

Ignite TC Bot commented on IGNITE-9308:
---

{panel:title=Possible 
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Inspections: Core{color} [[tests 0 BuildFailureOnMetric 
|https://ci.ignite.apache.org/viewLog.html?buildId=2322292]]

{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=2322296]]
* ZookeeperDiscoverySpiTestSuite1: 
ZookeeperDiscoverySpiTest.testNoOpCommunicationErrorResolve_2 - 0,0% fails in 
last 100 master runs.

{color:#d04437}Java Client{color} [[tests 
4|https://ci.ignite.apache.org/viewLog.html?buildId=2323456]]
* IgniteClientTestSuite: JettyRestProcessorBaselineSelfTest.testBaselineRemove
* IgniteClientTestSuite: JettyRestProcessorBaselineSelfTest.testBaseline
* IgniteClientTestSuite: JettyRestProcessorBaselineSelfTest.testBaselineAdd
* IgniteClientTestSuite: JettyRestProcessorBaselineSelfTest.testBaselineSet

{panel}
[TeamCity Run All 
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2321564buildTypeId=IgniteTests24Java8_RunAll]

> Add baseline topology command to REST API 
> --
>
> Key: IGNITE-9308
> URL: https://issues.apache.org/jira/browse/IGNITE-9308
> Project: Ignite
>  Issue Type: Bug
>  Components: rest
>Affects Versions: 2.6
>Reporter: ARomantsov
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.8
>
>
> Not found in https://apacheignite.readme.io/docs/rest-api info about baseline 
> command https://apacheignite.readme.io/docs/baseline-topology



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-9308) Add baseline topology command to REST API

2018-11-15 Thread Ignite TC Bot (JIRA)


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

Ignite TC Bot commented on IGNITE-9308:
---

{panel:title=Possible 
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Inspections: Core{color} [[tests 0 BuildFailureOnMetric 
|https://ci.ignite.apache.org/viewLog.html?buildId=2322292]]

{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=2322296]]
* ZookeeperDiscoverySpiTestSuite1: 
ZookeeperDiscoverySpiTest.testNoOpCommunicationErrorResolve_2 - 0,0% fails in 
last 100 master runs.

{panel}
[TeamCity Run All 
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2321564buildTypeId=IgniteTests24Java8_RunAll]

> Add baseline topology command to REST API 
> --
>
> Key: IGNITE-9308
> URL: https://issues.apache.org/jira/browse/IGNITE-9308
> Project: Ignite
>  Issue Type: Bug
>  Components: rest
>Affects Versions: 2.6
>Reporter: ARomantsov
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.8
>
>
> Not found in https://apacheignite.readme.io/docs/rest-api info about baseline 
> command https://apacheignite.readme.io/docs/baseline-topology



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-9356) Ignite rest command http://localhost:8080/ignite?cmd=log=n=m return more line in linux than windows

2018-11-15 Thread Pavel Voronkin (JIRA)


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

Pavel Voronkin updated IGNITE-9356:
---
Priority: Minor  (was: Major)

> Ignite rest command http://localhost:8080/ignite?cmd=log=n=m return 
> more line in linux than windows  
> -
>
> Key: IGNITE-9356
> URL: https://issues.apache.org/jira/browse/IGNITE-9356
> Project: Ignite
>  Issue Type: Improvement
>  Components: rest
>Affects Versions: 2.5
> Environment: Centos/ Windows10
>Reporter: ARomantsov
>Priority: Minor
> Fix For: 2.8
>
>
> I run cluster in diffrent configuration (centos and windows 10) and notice 
> that log command return diffrent count of rows in same from and to
> Windows rest return 1 less rows



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-9308) Add baseline topology command to REST API

2018-11-15 Thread Ignite TC Bot (JIRA)


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

Ignite TC Bot commented on IGNITE-9308:
---

{panel:title=Possible 
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Inspections: Core{color} [[tests 0 BuildFailureOnMetric 
|https://ci.ignite.apache.org/viewLog.html?buildId=2322292]]

{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=2322296]]
* ZookeeperDiscoverySpiTestSuite1: 
ZookeeperDiscoverySpiTest.testNoOpCommunicationErrorResolve_2 - 0,0% fails in 
last 100 master runs.

{panel}
[TeamCity Run All 
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2321564buildTypeId=IgniteTests24Java8_RunAll]

> Add baseline topology command to REST API 
> --
>
> Key: IGNITE-9308
> URL: https://issues.apache.org/jira/browse/IGNITE-9308
> Project: Ignite
>  Issue Type: Bug
>  Components: rest
>Affects Versions: 2.6
>Reporter: ARomantsov
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.8
>
>
> Not found in https://apacheignite.readme.io/docs/rest-api info about baseline 
> command https://apacheignite.readme.io/docs/baseline-topology



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-9308) Add baseline topology command to REST API

2018-11-15 Thread Ignite TC Bot (JIRA)


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

Ignite TC Bot commented on IGNITE-9308:
---

{panel:title=Possible 
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Inspections: Core{color} [[tests 0 BuildFailureOnMetric 
|https://ci.ignite.apache.org/viewLog.html?buildId=2322292]]

{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=2322296]]
* ZookeeperDiscoverySpiTestSuite1: 
ZookeeperDiscoverySpiTest.testNoOpCommunicationErrorResolve_2 - 0,0% fails in 
last 100 master runs.

{panel}
[TeamCity Run All 
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2321564buildTypeId=IgniteTests24Java8_RunAll]

> Add baseline topology command to REST API 
> --
>
> Key: IGNITE-9308
> URL: https://issues.apache.org/jira/browse/IGNITE-9308
> Project: Ignite
>  Issue Type: Bug
>  Components: rest
>Affects Versions: 2.6
>Reporter: ARomantsov
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.8
>
>
> Not found in https://apacheignite.readme.io/docs/rest-api info about baseline 
> command https://apacheignite.readme.io/docs/baseline-topology



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-9308) Add baseline topology command to REST API

2018-11-15 Thread Ignite TC Bot (JIRA)


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

Ignite TC Bot commented on IGNITE-9308:
---

{panel:title=Possible 
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Inspections: Core{color} [[tests 0 BuildFailureOnMetric 
|https://ci.ignite.apache.org/viewLog.html?buildId=2322292]]

{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=2322296]]
* ZookeeperDiscoverySpiTestSuite1: 
ZookeeperDiscoverySpiTest.testNoOpCommunicationErrorResolve_2 - 0,0% fails in 
last 100 master runs.

{panel}
[TeamCity Run All 
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2321564buildTypeId=IgniteTests24Java8_RunAll]

> Add baseline topology command to REST API 
> --
>
> Key: IGNITE-9308
> URL: https://issues.apache.org/jira/browse/IGNITE-9308
> Project: Ignite
>  Issue Type: Bug
>  Components: rest
>Affects Versions: 2.6
>Reporter: ARomantsov
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.8
>
>
> Not found in https://apacheignite.readme.io/docs/rest-api info about baseline 
> command https://apacheignite.readme.io/docs/baseline-topology



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-10272) Inject learning environment into scope of dataset compute task

2018-11-15 Thread Artem Malykh (JIRA)
Artem Malykh created IGNITE-10272:
-

 Summary: Inject learning environment into scope of dataset compute 
task
 Key: IGNITE-10272
 URL: https://issues.apache.org/jira/browse/IGNITE-10272
 Project: Ignite
  Issue Type: Improvement
Reporter: Artem Malykh
Assignee: Artem Malykh






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-9308) Add baseline topology command to REST API

2018-11-15 Thread Ignite TC Bot (JIRA)


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

Ignite TC Bot commented on IGNITE-9308:
---

{panel:title=Possible 
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Inspections: Core{color} [[tests 0 BuildFailureOnMetric 
|https://ci.ignite.apache.org/viewLog.html?buildId=2322292]]

{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=2322296]]
* ZookeeperDiscoverySpiTestSuite1: 
ZookeeperDiscoverySpiTest.testNoOpCommunicationErrorResolve_2 - 0,0% fails in 
last 100 master runs.

{panel}
[TeamCity Run All 
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2321564buildTypeId=IgniteTests24Java8_RunAll]

> Add baseline topology command to REST API 
> --
>
> Key: IGNITE-9308
> URL: https://issues.apache.org/jira/browse/IGNITE-9308
> Project: Ignite
>  Issue Type: Bug
>  Components: rest
>Affects Versions: 2.6
>Reporter: ARomantsov
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.8
>
>
> Not found in https://apacheignite.readme.io/docs/rest-api info about baseline 
> command https://apacheignite.readme.io/docs/baseline-topology



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-9308) Add baseline topology command to REST API

2018-11-15 Thread Ignite TC Bot (JIRA)


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

Ignite TC Bot commented on IGNITE-9308:
---

{panel:title=Possible 
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Inspections: Core{color} [[tests 0 BuildFailureOnMetric 
|https://ci.ignite.apache.org/viewLog.html?buildId=2322292]]

{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=2322296]]
* ZookeeperDiscoverySpiTestSuite1: 
ZookeeperDiscoverySpiTest.testNoOpCommunicationErrorResolve_2 - 0,0% fails in 
last 100 master runs.

{panel}
[TeamCity Run All 
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2321564buildTypeId=IgniteTests24Java8_RunAll]

> Add baseline topology command to REST API 
> --
>
> Key: IGNITE-9308
> URL: https://issues.apache.org/jira/browse/IGNITE-9308
> Project: Ignite
>  Issue Type: Bug
>  Components: rest
>Affects Versions: 2.6
>Reporter: ARomantsov
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.8
>
>
> Not found in https://apacheignite.readme.io/docs/rest-api info about baseline 
> command https://apacheignite.readme.io/docs/baseline-topology



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


  1   2   >