[jira] [Assigned] (IGNITE-7996) Web console: move cluster configuration form templates

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-7996:


Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Please do a smoke test of configuration screens + preview + download project.

If OK, assign issue to me for merge to master.

> Web console: move cluster configuration form templates
> --
>
> Key: IGNITE-7996
> URL: https://issues.apache.org/jira/browse/IGNITE-7996
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Pavel Konstantinov
>Priority: Minor
>
> The IGNITE-5466 introduced individual components for each of cluster 
> configuration forms, but  template files were left in the same place to 
> decrease incoming changes merge conflicts during development time. When 
> IGNITE-5466 gets merged into master, it should be safe to move all the 
> templates into component directories.



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

[jira] [Assigned] (IGNITE-7996) Web console: move cluster configuration form templates

[Ilya Borisov (JIRA)]

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

Ilya Borisov reassigned IGNITE-7996:


Assignee: Alexey Kuznetsov  (was: Ilya Borisov)

Please review and merge.

> Web console: move cluster configuration form templates
> --
>
> Key: IGNITE-7996
> URL: https://issues.apache.org/jira/browse/IGNITE-7996
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Alexey Kuznetsov
>Priority: Minor
>
> The IGNITE-5466 introduced individual components for each of cluster 
> configuration forms, but  template files were left in the same place to 
> decrease incoming changes merge conflicts during development time. When 
> IGNITE-5466 gets merged into master, it should be safe to move all the 
> templates into component directories.



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

[jira] [Comment Edited] (IGNITE-7077) Spark Data Frame Support. Strategy to convert complete query to Ignite SQL

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov edited comment on IGNITE-7077 at 4/6/18 4:28 AM:
-

[~vkulichenko]

First, thank you for paying attention to my task!

> I thought this task implied implementation of Strategy to convert Spark's 
> logical plan to physical plan that would be executed directly on Ignite as a 
> SQL query. 

1. LogicalPlan is the representation of SQL query. 

2. Leave of LogicalPlan is wrapper for {{IgniteSQLRealtion}}.

3. As far as I can see we don't need to provide some custom {{SparkStrategy}}. 
At least, for a query optimization described in this issue.
Because {{SparkStrategy}} contains Spark 'physical' operations: how to select 
and process data from the underlying data sources optimally.
This differs from {{LogicalPlan}} - tree representation of SQL query.

> Here I see the implementation of Optimization. Can you please clarify why is 
> that and what is the difference? How the current implementation work?

My implementation does the following:

1. Transform part(or the whole) LogicalPlan from the bottom to the up and 
pushes all possible SQL operator to the Ignite accumulator. 
If operator pushed to the accumulator then tree node are removed from the plan, 
because we execute it internally in Iginte.

2. If on some level unsupported operator founded(some UDF or similar) then this 
and upper layers of LogicalPlan remains unchanged. 

3. Create SQL query from accumulator. It will be executed directly in Ignite.

4. Replace accumulator with a `IgniteSQLAccumulatorRelation` which is relation 
containing resulting SQL query.

After step 4 we have a LogicalPlan that will execute all supported SQL operator 
directly in Ignite.

> Also I think we should add some examples demonstrating the new functionality.

If it works correctly then we don't need any new examples, because 
implementation details are hidden from the user.
Here what changed:

This how spark plan looks like *before* Ignite optimization:

{noformat}
== Analyzed Logical Plan ==
id: bigint, name: string
Sort [id#180L ASC NULLS FIRST], true
+- Project [id#180L, name#179]
   +- Filter (id#180L > cast(1 as bigint))
  +- SubqueryAlias city
 +- Relation[NAME#179,ID#180L] IgniteSQLRelation[table=CITY]
{noformat}

After optimization, we got following plan. Please note, that query inside 
IgniteSQLAccumulatorRelation identical to the query representation from the 
previous plan.

{noformat}
== Optimized Logical Plan ==
Relation[ID#180L,NAME#179] IgniteSQLAccumulatorRelation(columns=[ID, NAME], 
qry=SELECT ID, NAME FROM CITY WHERE id IS NOT NULL AND id > 1 ORDER BY id)
{noformat}

Please, see debug output of IgniteOptimization*Spec. {{IgniteOptimizationSpec}} 
[1] or {{IgniteOptimizationStringFuncSpec}} [2], for example.
You can see additional examples of LogicalPlan transformation there.

[1] 
https://github.com/apache/ignite/pull/3397/files#diff-18f77858494b6316b7aa3cbe3ad4980f
[2] 
https://github.com/apache/ignite/pull/3397/files#diff-b16f783323111273ab93d0797542649b


was (Author: nizhikov):
[~vkulichenko]

First, thank you for paying attention to my task!

> I thought this task implied implementation of Strategy to convert Spark's 
> logical plan to physical plan that would be executed directly on Ignite as a 
> SQL query. 

1. LogicalPlan is the representation of SQL query. 

2. Leave of LogicalPlan is wrapper for {{IgniteSQLRealtion}}.

3. As far as I can see we don't need to provide some custom {{SparkStrategy}}. 
At least, for a query optimization described in this issue.
Because {{SparkStrategy}} contains Spark 'physical' operations: how to select 
and process data from the underlying data sources optimally.
This differs from {{LogicalPlan}} - tree representation of SQL query.

> Here I see the implementation of Optimization. Can you please clarify why is 
> that and what is the difference? How the current implementation work?

My implementation does the following:

1. Transform part(or the whole) LogicalPlan from the bottom to the up and 
pushes all possible SQL operator to the Ignite accumulator. 
If operator pushed to the accumulator then tree node are removed from the plan, 
because we execute it internally in Iginte.

2. If on some level unsupported operator founded(some UDF or similar) then this 
and upper layers of LogicalPlan remains unchanged. 

3. Create SQL query from accumulator. It will be executed directly in Ignite.

4. Replace accumulator with a `IgniteSQLAccumulatorRelation` which is relation 
containing resulting SQL query.

After step 4 we have a LogicalPlan that will execute all supported SQL operator 
directly in Ignite.

> Also I think we should add some examples demonstrating the new functionality.

If it works correctly then we don't need any new examples, because 
implementation details 

[jira] [Commented] (IGNITE-7996) Web console: move cluster configuration form templates

[Ilya Borisov (JIRA)]

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

Ilya Borisov commented on IGNITE-7996:
--

[~kuaw26] all one, I've moved all configuration assets into page-configure 
module, except for generators, but these were in a different module anyway. 
Please make sure the git file move history remains intact, I payed special 
attention to it while committing the changes.

> Web console: move cluster configuration form templates
> --
>
> Key: IGNITE-7996
> URL: https://issues.apache.org/jira/browse/IGNITE-7996
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Ilya Borisov
>Priority: Minor
>
> The IGNITE-5466 introduced individual components for each of cluster 
> configuration forms, but  template files were left in the same place to 
> decrease incoming changes merge conflicts during development time. When 
> IGNITE-5466 gets merged into master, it should be safe to move all the 
> templates into component directories.



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

[jira] [Comment Edited] (IGNITE-7077) Spark Data Frame Support. Strategy to convert complete query to Ignite SQL

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov edited comment on IGNITE-7077 at 4/6/18 4:25 AM:
-

[~vkulichenko]

First, thank you for paying attention to my task!

> I thought this task implied implementation of Strategy to convert Spark's 
> logical plan to physical plan that would be executed directly on Ignite as a 
> SQL query. 

1. LogicalPlan is the representation of SQL query. 

2. Leave of LogicalPlan is wrapper for {{IgniteSQLRealtion}}.

3. As far as I can see we don't need to provide some custom {{SparkStrategy}}. 
At least, for a query optimization described in this issue.
Because {{SparkStrategy}} contains Spark 'physical' operations: how to select 
and process data from the underlying data sources optimally.
This differs from {{LogicalPlan}} - tree representation of SQL query.

> Here I see the implementation of Optimization. Can you please clarify why is 
> that and what is the difference? How the current implementation work?

My implementation does the following:

1. Transform part(or the whole) LogicalPlan from the bottom to the up and 
pushes all possible SQL operator to the Ignite accumulator. 
If operator pushed to the accumulator then tree node are removed from the plan, 
because we execute it internally in Iginte.

2. If on some level unsupported operator founded(some UDF or similar) then this 
and upper layers of LogicalPlan remains unchanged. 

3. Create SQL query from accumulator. It will be executed directly in Ignite.

4. Replace accumulator with a `IgniteSQLAccumulatorRelation` which is relation 
containing resulting SQL query.

After step 4 we have a LogicalPlan that will execute all supported SQL operator 
directly in Ignite.

> Also I think we should add some examples demonstrating the new functionality.

If it works correctly then we don't need any new examples, because 
implementation details are hidden from the user.
Here what changed:

This how spark plan looks like *before* Ignite optimization:

{noformat}
== Analyzed Logical Plan ==
id: bigint, name: string
Sort [id#180L ASC NULLS FIRST], true
+- Project [id#180L, name#179]
   +- Filter (id#180L > cast(1 as bigint))
  +- SubqueryAlias city
 +- Relation[NAME#179,ID#180L] IgniteSQLRelation[table=CITY]
{noformat}

After optimization, we got following plan. Please note, that query inside 
IgniteSQLAccumulatorRelation identical to the query representation from the 
previous plan.

{noformat}
== Optimized Logical Plan ==
Relation[ID#180L,NAME#179] IgniteSQLAccumulatorRelation(columns=[ID, NAME], 
qry=SELECT ID, NAME FROM CITY WHERE id IS NOT NULL AND id > 1 ORDER BY id)
{noformat}

Please, see debug output of IgniteOptimization*Spec. {{IgniteOptimizationSpec}} 
or {{IgniteOptimizationStringFuncSpec}}, for example.
You can see additional examples of LogicalPlan transformation there.


was (Author: nizhikov):
[~vkulichenko]

First, thank you for paying attention to my task!

> I thought this task implied implementation of Strategy to convert Spark's 
> logical plan to physical plan that would be executed directly on Ignite as a 
> SQL query. 

1. LogicalPlan is the representation of SQL query. 

2. Leave of LogicalPlan is wrapper for {{IgniteSQLRealtion}}.

3. As far as I can see we don't need to provide some custom {{SparkStrategy}}. 
At least for a query optimization described in this issue.
Because {{SparkStrategy}} contains Spark 'physical' operations: how to select 
and process data from the underlying data sources optimally.
This differs from {{LogicalPlan}} - tree representation of SQL query.

> Here I see the implementation of Optimization. Can you please clarify why is 
> that and what is the difference? How the current implementation work?

My implementation does the following:

1. Transform part(or the whole) LogicalPlan from the bottom to the up and 
pushes all possible SQL operator to the Ignite accumulator. 
If operator pushed to the accumulator then tree node are removed from the plan, 
because we execute it internally in Iginte.

2. If on some level unsupported operator founded(some UDF or similar) then this 
and upper layers of LogicalPlan remains unchanged. 

3. Create SQL query from accumulator. It will be executed directly in Ignite.

4. Replace accumulator with a `IgniteSQLAccumulatorRelation` which is relation 
containing resulting SQL query.

After step 4 we have a LogicalPlan that will execute all supported SQL operator 
directly in Ignite.

> Also I think we should add some examples demonstrating the new functionality.

If it works correctly then we don't need any new examples, because 
implementation details are hidden from the user.
Here what changed:

This how spark plan looks like *before* Ignite optimization:

{noformat}
== Analyzed Logical Plan ==
id: bigint, name: string
Sort [id#180L ASC 

[jira] [Commented] (IGNITE-7077) Spark Data Frame Support. Strategy to convert complete query to Ignite SQL

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-7077:
-

[~vkulichenko]

First, thank you for paying attention to my task!

> I thought this task implied implementation of Strategy to convert Spark's 
> logical plan to physical plan that would be executed directly on Ignite as a 
> SQL query. 

1. LogicalPlan is the representation of SQL query. 

2. Leave of LogicalPlan is wrapper for {{IgniteSQLRealtion}}.

3. As far as I can see we don't need to provide some custom {{SparkStrategy}}. 
At least for a query optimization described in this issue.
Because {{SparkStrategy}} contains Spark 'physical' operations: how to select 
and process data from the underlying data sources optimally.
This differs from {{LogicalPlan}} - tree representation of SQL query.

> Here I see the implementation of Optimization. Can you please clarify why is 
> that and what is the difference? How the current implementation work?

My implementation does the following:

1. Transform part(or the whole) LogicalPlan from the bottom to the up and 
pushes all possible SQL operator to the Ignite accumulator. 
If operator pushed to the accumulator then tree node are removed from the plan, 
because we execute it internally in Iginte.

2. If on some level unsupported operator founded(some UDF or similar) then this 
and upper layers of LogicalPlan remains unchanged. 

3. Create SQL query from accumulator. It will be executed directly in Ignite.

4. Replace accumulator with a `IgniteSQLAccumulatorRelation` which is relation 
containing resulting SQL query.

After step 4 we have a LogicalPlan that will execute all supported SQL operator 
directly in Ignite.

> Also I think we should add some examples demonstrating the new functionality.

If it works correctly then we don't need any new examples, because 
implementation details are hidden from the user.
Here what changed:

This how spark plan looks like *before* Ignite optimization:

{noformat}
== Analyzed Logical Plan ==
id: bigint, name: string
Sort [id#180L ASC NULLS FIRST], true
+- Project [id#180L, name#179]
   +- Filter (id#180L > cast(1 as bigint))
  +- SubqueryAlias city
 +- Relation[NAME#179,ID#180L] IgniteSQLRelation[table=CITY]
{noformat}

After optimization, we got following plan. Please note, that query inside 
IgniteSQLAccumulatorRelation identical to the query representation from the 
previous plan.

{noformat}
== Optimized Logical Plan ==
Relation[ID#180L,NAME#179] IgniteSQLAccumulatorRelation(columns=[ID, NAME], 
qry=SELECT ID, NAME FROM CITY WHERE id IS NOT NULL AND id > 1 ORDER BY id)
{noformat}

Please, see debug output of IgniteOptimization*Spec. {{IgniteOptimizationSpec}} 
or {{IgniteOptimizationStringFuncSpec}}, for example.
You can see additional examples of LogicalPlan transformation there.

> Spark Data Frame Support. Strategy to convert complete query to Ignite SQL
> --
>
> Key: IGNITE-7077
> URL: https://issues.apache.org/jira/browse/IGNITE-7077
> Project: Ignite
>  Issue Type: New Feature
>  Components: spark
>Affects Versions: 2.3
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: bigdata
> Fix For: 2.5
>
>
> Basic support of Spark Data Frame for Ignite implemented in IGNITE-3084.
> We need to implement custom spark strategy that can convert whole Spark SQL 
> query to Ignite SQL Query if query consists of only Ignite tables.
> The strategy does nothing if spark query includes not only Ignite tables.
> Memsql implementation can be taken as an example - 
> https://github.com/memsql/memsql-spark-connector



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

[jira] [Assigned] (IGNITE-4091) Refactor direct usage of Angular API

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-4091:


Assignee: Alexander Kalinin

[~alexdel], please take a look.

> Refactor direct usage of Angular API
> 
>
> Key: IGNITE-4091
> URL: https://issues.apache.org/jira/browse/IGNITE-4091
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Affects Versions: 1.7
>Reporter: Alexey Kuznetsov
>Assignee: Alexander Kalinin
>Priority: Major
>
> It is not recommended to use Angular API in user code (because it may be 
> changed by Angular developers).
> All usage of angular.XXX should be replaced with appropriate functions from 
> lodash library.



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

[jira] [Resolved] (IGNITE-3843) Web console: Not work basic validations.

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov resolved IGNITE-3843.
--
Resolution: Won't Fix

> Web console: Not work basic validations.
> 
>
> Key: IGNITE-3843
> URL: https://issues.apache.org/jira/browse/IGNITE-3843
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
>Priority: Major
>
> F.e. On cluster add empty Cache key configuration and try to save cluster.
> Also field with wrong value should be focused.



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

[jira] [Closed] (IGNITE-3843) Web console: Not work basic validations.

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov closed IGNITE-3843.


This issue is not actual any more.

> Web console: Not work basic validations.
> 
>
> Key: IGNITE-3843
> URL: https://issues.apache.org/jira/browse/IGNITE-3843
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
>Priority: Major
>
> F.e. On cluster add empty Cache key configuration and try to save cluster.
> Also field with wrong value should be focused.



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

[jira] [Created] (IGNITE-8155) Warning in log on opening of cluster tab in advanced mode

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-8155:
-

 Summary: Warning in log on opening of cluster tab in advanced mode
 Key: IGNITE-8155
 URL: https://issues.apache.org/jira/browse/IGNITE-8155
 Project: Ignite
  Issue Type: Bug
Reporter: Vasiliy Sisko
Assignee: Ilya Borisov


# Create new cluster
# Save cluster
# Open cluster tab in advanced mode
In browser console next message is shown:
{code}
The specified value "value" is not a valid number. The value must match to the 
following regular expression: -?(\d+|\d+\.\d+|\.\d+)([eE][-+]?\d+)?
{code}



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

[jira] [Commented] (IGNITE-7927) Web console: failed to execute query in demo

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-7927:


Test failed.

> Web console: failed to execute query in demo
> 
>
> Key: IGNITE-7927
> URL: https://issues.apache.org/jira/browse/IGNITE-7927
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Vasiliy Sisko
>Priority: Major
>
> If I set 'Allow non-collocated joins' option  for demo query
> {code}
> SELECT p.name, count(*) AS cnt
> FROM "ParkingCache".Parking p
> INNER JOIN "CarCache".Car c
>   ON (p.id) = (c.parkingId)
> GROUP BY P.NAME
> {code}
> then I got the following error
> {code}
> Error: Failed to prepare distributed join query: join condition does not use 
> index [joinedCache=CarCache, plan=SELECT P__Z0.NAME AS __C0_0, COUNT(*) AS 
> __C0_1 FROM "ParkingCache".PARKING P__Z0 /* "ParkingCache".PARKING.__SCAN_ */ 
> INNER JOIN "CarCache".CAR C__Z1 /* batched:broadcast "CarCache".CAR.__SCAN_ 
> */ ON 1=1 WHERE P__Z0.ID = C__Z1.PARKINGID GROUP BY P__Z0.NAME]
> {code}
> Please add necessary indices



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

[jira] [Reopened] (IGNITE-7927) Web console: failed to execute query in demo

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reopened IGNITE-7927:


> Web console: failed to execute query in demo
> 
>
> Key: IGNITE-7927
> URL: https://issues.apache.org/jira/browse/IGNITE-7927
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Vasiliy Sisko
>Priority: Major
>
> If I set 'Allow non-collocated joins' option  for demo query
> {code}
> SELECT p.name, count(*) AS cnt
> FROM "ParkingCache".Parking p
> INNER JOIN "CarCache".Car c
>   ON (p.id) = (c.parkingId)
> GROUP BY P.NAME
> {code}
> then I got the following error
> {code}
> Error: Failed to prepare distributed join query: join condition does not use 
> index [joinedCache=CarCache, plan=SELECT P__Z0.NAME AS __C0_0, COUNT(*) AS 
> __C0_1 FROM "ParkingCache".PARKING P__Z0 /* "ParkingCache".PARKING.__SCAN_ */ 
> INNER JOIN "CarCache".CAR C__Z1 /* batched:broadcast "CarCache".CAR.__SCAN_ 
> */ ON 1=1 WHERE P__Z0.ID = C__Z1.PARKINGID GROUP BY P__Z0.NAME]
> {code}
> Please add necessary indices



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

[jira] [Assigned] (IGNITE-7927) Web console: failed to execute query in demo

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-7927:
--

Assignee: Vasiliy Sisko  (was: Pavel Konstantinov)

> Web console: failed to execute query in demo
> 
>
> Key: IGNITE-7927
> URL: https://issues.apache.org/jira/browse/IGNITE-7927
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Vasiliy Sisko
>Priority: Major
>
> If I set 'Allow non-collocated joins' option  for demo query
> {code}
> SELECT p.name, count(*) AS cnt
> FROM "ParkingCache".Parking p
> INNER JOIN "CarCache".Car c
>   ON (p.id) = (c.parkingId)
> GROUP BY P.NAME
> {code}
> then I got the following error
> {code}
> Error: Failed to prepare distributed join query: join condition does not use 
> index [joinedCache=CarCache, plan=SELECT P__Z0.NAME AS __C0_0, COUNT(*) AS 
> __C0_1 FROM "ParkingCache".PARKING P__Z0 /* "ParkingCache".PARKING.__SCAN_ */ 
> INNER JOIN "CarCache".CAR C__Z1 /* batched:broadcast "CarCache".CAR.__SCAN_ 
> */ ON 1=1 WHERE P__Z0.ID = C__Z1.PARKINGID GROUP BY P__Z0.NAME]
> {code}
> Please add necessary indices



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

[jira] [Assigned] (IGNITE-8126) Web console: the method 'LoadCaches' should not be generated if cache doesn't contain cache store configuration

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-8126:
--

Assignee: Vasiliy Sisko  (was: Pavel Konstantinov)

> Web console: the method 'LoadCaches' should not be generated if cache doesn't 
> contain cache store configuration
> ---
>
> Key: IGNITE-8126
> URL: https://issues.apache.org/jira/browse/IGNITE-8126
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Vasiliy Sisko
>Priority: Major
>
> # create cluster, save
> # create cache, save
> # see project structure



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

[jira] [Comment Edited] (IGNITE-8126) Web console: the method 'LoadCaches' should not be generated if cache doesn't contain cache store configuration

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov edited comment on IGNITE-8126 at 4/6/18 2:57 AM:


Error on branch build



was (Author: pkonstantinov):
Error on branch build
{code}
{code}

> Web console: the method 'LoadCaches' should not be generated if cache doesn't 
> contain cache store configuration
> ---
>
> Key: IGNITE-8126
> URL: https://issues.apache.org/jira/browse/IGNITE-8126
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Major
>
> # create cluster, save
> # create cache, save
> # see project structure



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

[jira] [Commented] (IGNITE-8126) Web console: the method 'LoadCaches' should not be generated if cache doesn't contain cache store configuration

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-8126:


Error on branch build
{code}
{code}

> Web console: the method 'LoadCaches' should not be generated if cache doesn't 
> contain cache store configuration
> ---
>
> Key: IGNITE-8126
> URL: https://issues.apache.org/jira/browse/IGNITE-8126
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Major
>
> # create cluster, save
> # create cache, save
> # see project structure



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

[jira] [Commented] (IGNITE-7993) Striped pool can't be disabled

[Roman Guseinov (JIRA)]

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

Roman Guseinov commented on IGNITE-7993:


[~yzhdanov] , thank you for the review. I will provide answers and make changes 
according to your comments.

> Striped pool can't be disabled
> --
>
> Key: IGNITE-7993
> URL: https://issues.apache.org/jira/browse/IGNITE-7993
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Valentin Kulichenko
>Assignee: Roman Guseinov
>Priority: Major
> Fix For: 2.5
>
>
> Javadoc for {{IgniteConfiguration#setStripedPoolSize}} states that striped 
> pool can be disabled by providing value less or equal than zero:
> {noformat}
> If set to non-positive value then requests get processed in system pool.
> {noformat}
> However, doing that prevents node from startup, it fails with the following 
> exception:
> {noformat}
> Caused by: class org.apache.ignite.IgniteCheckedException: Invalid 
> stripedPool thread pool size (must be greater than 0), actual value: 0
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.validateThreadPoolSize(IgnitionEx.java:2061)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1799)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
>   at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:664)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
>   at org.apache.ignite.Ignition.start(Ignition.java:322)
>   ... 7 more
> {noformat}



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

[jira] [Commented] (IGNITE-7944) Disconnected client node tries to send JOB_CANCEL message

[Roman Guseinov (JIRA)]

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

Roman Guseinov commented on IGNITE-7944:


[~dpavlov] , thanks for your comment and for restarting "Ignite Queries [1]".

The test was passed: 
[https://ci.ignite.apache.org/viewLog.html?buildId=1181645=IgniteTests24Java8_IgniteQueries=buildResultsDiv]

 

> Disconnected client node tries to send JOB_CANCEL message
> -
>
> Key: IGNITE-7944
> URL: https://issues.apache.org/jira/browse/IGNITE-7944
> Project: Ignite
>  Issue Type: Bug
>  Components: messaging
>Affects Versions: 1.9, 2.3
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
> Fix For: 2.5
>
> Attachments: Reproducer7944.java
>
>
> In case the network is blocked (socket connections not closed) and failure is 
> detected, tcp-client-disco-msg-worker thread can be stuck in process of 
> TcpClient creating:
> {code:java}
> "tcp-client-disco-msg-worker-#4%wd5prsvtots0016a-tg-QueryFabric%" #494 prio=5 
> os_prio=0 tid=0x7f94c067c800 nid=0x2bdf runnable [0x7f960ecf1000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.Net.poll(Native Method)
> at sun.nio.ch.SocketChannelImpl.poll(SocketChannelImpl.java:954)
> - locked <0x7fa140f520c0> (a java.lang.Object)
> at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:110)
> - locked <0x7fa140f520b0> (a java.lang.Object)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2950)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2681)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2568)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2429)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2393)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1590)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1659)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.cancelChildren(GridTaskWorker.java:1305)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1609)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1581)
> at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.onDisconnected(GridTaskProcessor.java:168)
> at 
> org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:3460)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:601)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2407)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2386)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1714)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> It looks like msg-worker is trying to send JOB_CANCEL message for each job 
> with timeout equals failureDetectionTimeout.
> Reproducer is attached.



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

[jira] [Updated] (IGNITE-8143) Fetching EXTERNAL_LIBS for docker container fails

[Roman Shtykh (JIRA)]

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

Roman Shtykh updated IGNITE-8143:
-
Fix Version/s: 2.5

> Fetching EXTERNAL_LIBS for docker container fails
> -
>
> Key: IGNITE-8143
> URL: https://issues.apache.org/jira/browse/IGNITE-8143
> Project: Ignite
>  Issue Type: Bug
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>Priority: Major
>  Labels: docker
> Fix For: 2.5
>
>
> *EXTERNAL_LIBS* are fetched by _wget_ with *-i* option, which does not exist 
> in CoreOS(busybox).



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

[jira] [Commented] (IGNITE-7077) Spark Data Frame Support. Strategy to convert complete query to Ignite SQL

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-7077:
-

[~NIzhikov], I'm a bit confused. I thought this task implied implementation of 
{{Strategy}} to convert Spark's logical plan to physical plan that would be 
executed directly on Ignite as a SQL query. Here I see the implementation of 
{{Optimization}}. Can you please clarify why is that and what is the 
difference? How the current implementation work?

Also I think we should add some examples demonstrating the new functionality.

> Spark Data Frame Support. Strategy to convert complete query to Ignite SQL
> --
>
> Key: IGNITE-7077
> URL: https://issues.apache.org/jira/browse/IGNITE-7077
> Project: Ignite
>  Issue Type: New Feature
>  Components: spark
>Affects Versions: 2.3
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: bigdata
> Fix For: 2.5
>
>
> Basic support of Spark Data Frame for Ignite implemented in IGNITE-3084.
> We need to implement custom spark strategy that can convert whole Spark SQL 
> query to Ignite SQL Query if query consists of only Ignite tables.
> The strategy does nothing if spark query includes not only Ignite tables.
> Memsql implementation can be taken as an example - 
> https://github.com/memsql/memsql-spark-connector



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

[jira] [Created] (IGNITE-8154) Add an ability to provide ExceptionListener to JmsStreamer

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-8154:
---

 Summary: Add an ability to provide ExceptionListener to JmsStreamer
 Key: IGNITE-8154
 URL: https://issues.apache.org/jira/browse/IGNITE-8154
 Project: Ignite
  Issue Type: Improvement
  Components: streaming
Affects Versions: 2.4
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
 Fix For: 2.5


JMS API allows to provide custom {{ExceptionListener}} that is invoked when an 
exception occurs within JMS queue/topic. Currently, {{JmsStreamer}} doesn't use 
this in any way which creates two issues:
* If there is an exception, it's lost and not even logged.
* User can't provide their own listener.



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

[jira] [Commented] (IGNITE-6826) Change default DiscoverySpi ipFinder type for examples

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii commented on IGNITE-6826:


[~antkr], I did the same, but Pavel said that .NET tests don't work with nodes, 
started by {{Ignite.bat/sh}}. I don't know what he meant, because I have same 
fail on 2.4.0 binary release with nodes started by {{Ignite.bat/sh}} and 
{{Apache.Ignite.exe}}, which means this fail exist not only in my branch, but 
in the master too. Or I do something wrong (what can be more simple than launch 
.exe file and build example?).

Anton, what do you mean by "examples are working fine"? How you ran them?

> Change default DiscoverySpi ipFinder type for examples
> --
>
> Key: IGNITE-6826
> URL: https://issues.apache.org/jira/browse/IGNITE-6826
> Project: Ignite
>  Issue Type: Improvement
>  Components: examples
>Affects Versions: 2.3
>Reporter: Alexey Popov
>Assignee: Ryabov Dmitrii
>Priority: Major
>  Labels: newbie
> Fix For: 2.5
>
>
> It is better to change multicast ipFinder to static (vm) ipFinder for java 
> examples, .NET examples and C++ examples.
> http://apache-ignite-developers.2346864.n4.nabble.com/ipFinder-configuration-for-Samples-td23818.html



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

[jira] [Created] (IGNITE-8153) Nodes fail to connect each other when SSL is enabled

[Mikhail Cherkasov (JIRA)]

Mikhail Cherkasov created IGNITE-8153:
-

 Summary: Nodes fail to connect each other when SSL is enabled
 Key: IGNITE-8153
 URL: https://issues.apache.org/jira/browse/IGNITE-8153
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.4
Reporter: Mikhail Cherkasov
Assignee: Mikhail Cherkasov
 Fix For: 2.5


Nodes can fail to connect each other when SSL is enabled under some 
circumstances.

 



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

[jira] [Commented] (IGNITE-8078) Add new metrics for data storage

[Max Shonichev (JIRA)]

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

Max Shonichev commented on IGNITE-8078:
---

[~ivandasch] Please, mind that getCurrentCoordinator should as well be 
available when ZookeeperDiscoverySpi is used instead of TcpDiscoverySpi, so 
better to put that attribute into single place, IgniteMxBean

> Add new metrics for data storage
> 
>
> Key: IGNITE-8078
> URL: https://issues.apache.org/jira/browse/IGNITE-8078
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
>  Labels: iep-6
> Fix For: 2.5
>
>
> 1. Create new MXbean for each index, IndexMxBean
> {code}
> class IndexMxBean{
> /** The number of PUT operations on the index. */
> long getProcessedPuts();
> /** The number of GET operations on the index. */
> long getProcessedGets();
> /** The total index size in bytes. */
> long getIndexSize();
> /** Index name.*/
> String getName();
> }
> {code}
> 2. Add new metrics for data storage and cache group.
> {code}
> class CacheGroupMetricsMXBean{
> /** The total index size in bytes */
> long getIndexesSize();
> /** Total size in bytes for primary key indexes. */
> long getPKIndexesSize();
> /** Total size in bytes for reuse list.*/
> long getReuseListSize();
> /** Total size in bytes. */
> long getTotalSize();
> /** Total size in bytes for pure data.*/
> long getDataSize();
> /** Total size in bytes for data pages.*/
> long getDataPagesSize();
> /** CacheGroup type. PARTITIONED, REPLICATED, LOCAL.*/
> String getType();
> /** Partitions currently assigned to the local node in this cache group. */
> int[] getPartitions();
> }
> {code}
> {code}
> class DataRegionMXBean{
> /** Total size in bytes for indexes. */
> long getIndexesSize();
> /** Total size in bytes for primary key indexes. */
> long getPKIndexesSize();
> /** Total size in bytes. */
> long getTotalSize();
> /** Total size in bytes for pure data.*/
> long getDataSize();
> /** Total size in bytes for data pages.*/
> long getDataPagesSize();
> /** Total used offheap size in bytes. */
> long getOffheapUsedSize();
> /** The number of read pages from last restart. */
> long getPagesRead();
> /** The number of writen pages from last restart. */
> long getPagesWriten();
> /** The number of replaced pages from last restart . */
> long getPagesReplaced();
> /** Total dirty pages for the next checkpoint. */
> long getDirtyPagesForNextCheckpoint();
> }
> {code}
> {code}
> class DataStorageMXbean{
> /** Total size in bytes for indexes. */
> long getIndexesSize();
> /** Total size in bytes for primary key indexes. */
> long getPKIndexesSize();
> /** Total size in bytes for all storages. */
> long getTotalSize();
> /** Total offheap size in bytes. */
> long getOffHeapSize();
> /** Total used offheap size in bytes for all data regions. */
> long getOffheapUsedSize();
> /** Total size in bytes for pure data.*/
> long getDataSize();
> /** The number of read pages from last restart. */
> long getPagesRead();
> /** The number of writen pages from last restart. */
> long getPagesWriten();
> /** The number of replaced pages from last restart. */
> long getPagesReplaced();
> /** Total checkpoint time from last restart. */
> long getCheckpointTotalTime();
> /** Total dirty pages for the next checkpoint. */
> long getDirtyPagesForNextCheckpoint();
> /** Total size in bytes for storage wal files. */
> long getWalTotalSize();
> /** Time of the last WAL segment rollover. */
> long getWalLastSwitchTime();
> }
> {code}
> {code}
> class IgniteMxBean {
> /** Returns string containing Node ID, Consistent ID, Node Order */
> String getCurrentCoordinator();
> }
> {code}
> Depricate CacheMetrics.getRebalancingPartitionsCount(); and move to 
> CacheGroupMetricsMXBean.getRebalancingPartitionsCount();



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

[jira] [Commented] (IGNITE-8148) JDBC thin driver: use semicolon as parameter's delimiter

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-8148:
-

[~vozerov], shouldn't we do the same for ODBC?

> JDBC thin driver: use semicolon as parameter's delimiter
> 
>
> Key: IGNITE-8148
> URL: https://issues.apache.org/jira/browse/IGNITE-8148
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Affects Versions: 2.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.5
>
>
> Currently we split JDBC parameters using ampersand. This causes a number of 
> usability concerns with escaping, especially when it is needed to pass 
> connection URL to command line (e.g. sqlline in bash or PowerShell). A number 
> of other vendors use either parentheses or semicolon as a delimiter. I 
> propose to choose semicolon. 
> Also it is necessary to make sure that old-style connection URLs work fine 
> after this change.



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

[jira] [Commented] (IGNITE-8046) New flaky tests added in JettyRestProcessorAuthenticationSelfTest

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8046:


These test failures probably causes more serios failures in subsequent test 
run. Please fix or remove these tests.

> New flaky tests added in JettyRestProcessorAuthenticationSelfTest
> -
>
> Key: IGNITE-8046
> URL: https://issues.apache.org/jira/browse/IGNITE-8046
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
> Attachments: hs_err_pid24340.log.txt
>
>
> Latest examle of failure 
> https://ci.ignite.apache.org/viewLog.html?buildId=1159028
>Test runs count is low < 10, probably new test introduced  
> IgniteClientTestSuite: 
> - JettyRestProcessorAuthenticationSelfTest.testAddWithExpiration (fail rate 
> 100,0%) 
> - JettyRestProcessorAuthenticationSelfTest.testPutWithExpiration (fail rate 
> 100,0%) 
> - JettyRestProcessorAuthenticationSelfTest.testReplaceWithExpiration (fail 
> rate 100,0%) 
> JettyRestProcessorAuthenticationSelfTest
> https://github.com/apache/ignite/commit/921f0cf9b3ab6454339fa57b929093f56372c61e



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

[jira] [Updated] (IGNITE-8046) New flaky tests added in JettyRestProcessorAuthenticationSelfTest

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-8046:
---
Attachment: hs_err_pid24340.log.txt

> New flaky tests added in JettyRestProcessorAuthenticationSelfTest
> -
>
> Key: IGNITE-8046
> URL: https://issues.apache.org/jira/browse/IGNITE-8046
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
> Attachments: hs_err_pid24340.log.txt
>
>
> Latest examle of failure 
> https://ci.ignite.apache.org/viewLog.html?buildId=1159028
>Test runs count is low < 10, probably new test introduced  
> IgniteClientTestSuite: 
> - JettyRestProcessorAuthenticationSelfTest.testAddWithExpiration (fail rate 
> 100,0%) 
> - JettyRestProcessorAuthenticationSelfTest.testPutWithExpiration (fail rate 
> 100,0%) 
> - JettyRestProcessorAuthenticationSelfTest.testReplaceWithExpiration (fail 
> rate 100,0%) 
> JettyRestProcessorAuthenticationSelfTest
> https://github.com/apache/ignite/commit/921f0cf9b3ab6454339fa57b929093f56372c61e



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

[jira] [Updated] (IGNITE-8046) New flaky tests added in JettyRestProcessorAuthenticationSelfTest

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-8046:
---
Priority: Critical  (was: Major)

> New flaky tests added in JettyRestProcessorAuthenticationSelfTest
> -
>
> Key: IGNITE-8046
> URL: https://issues.apache.org/jira/browse/IGNITE-8046
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
>
> Latest examle of failure 
> https://ci.ignite.apache.org/viewLog.html?buildId=1159028
>Test runs count is low < 10, probably new test introduced  
> IgniteClientTestSuite: 
> - JettyRestProcessorAuthenticationSelfTest.testAddWithExpiration (fail rate 
> 100,0%) 
> - JettyRestProcessorAuthenticationSelfTest.testPutWithExpiration (fail rate 
> 100,0%) 
> - JettyRestProcessorAuthenticationSelfTest.testReplaceWithExpiration (fail 
> rate 100,0%) 
> JettyRestProcessorAuthenticationSelfTest
> https://github.com/apache/ignite/commit/921f0cf9b3ab6454339fa57b929093f56372c61e



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

[jira] [Commented] (IGNITE-7933) The error writing wal point to cp/node-start file can lead to the inability to start node

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7933:


I've checked fix itself and it is looking good. I suggest to wait new TC run 
and merge it.

> The error writing wal point to cp/node-start file can lead to the inability 
> to start node
> -
>
> Key: IGNITE-7933
> URL: https://issues.apache.org/jira/browse/IGNITE-7933
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Dmitriy Govorukhin
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: cache
> Fix For: 2.5
>
>
> The problem is that the file exists on the disk but file content corrupted.
> Neet to write content via .tmp files.
> See:
> - writeCheckpointEntry
> - nodeStart



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

[jira] [Commented] (IGNITE-7933) The error writing wal point to cp/node-start file can lead to the inability to start node

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7933:


I've retriggered TC run. It seems several tests were failed because of 
incorrect failure handler setup.


> The error writing wal point to cp/node-start file can lead to the inability 
> to start node
> -
>
> Key: IGNITE-7933
> URL: https://issues.apache.org/jira/browse/IGNITE-7933
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Dmitriy Govorukhin
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: cache
> Fix For: 2.5
>
>
> The problem is that the file exists on the disk but file content corrupted.
> Neet to write content via .tmp files.
> See:
> - writeCheckpointEntry
> - nodeStart



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

[jira] [Assigned] (IGNITE-2096) AtomicConfiguration and CollectionConfiguration should be properly checked for consistency

[Anton Kurbanov (JIRA)]

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

Anton Kurbanov reassigned IGNITE-2096:
--

Assignee: Anton Kurbanov

> AtomicConfiguration and CollectionConfiguration should be properly checked 
> for consistency
> --
>
> Key: IGNITE-2096
> URL: https://issues.apache.org/jira/browse/IGNITE-2096
> Project: Ignite
>  Issue Type: Bug
>  Components: data structures
>Reporter: Valentin Kulichenko
>Assignee: Anton Kurbanov
>Priority: Major
>  Labels: newbie, usability
>
> Currently {{AtomicConfiguration}} and {{CollectionConfiguration}} are mapped 
> to system caches configuration and consistency is checked like for any other 
> cache. This leads to unintuitive errors.



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

[jira] [Resolved] (IGNITE-4031) SQL: Optimize Date\Time\Timestamp function arguments conversion.

[Andrew Mashenkov (JIRA)]

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

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

Resolved within H2 version upgrade.

> SQL: Optimize Date\Time\Timestamp function arguments conversion.
> 
>
> Key: IGNITE-4031
> URL: https://issues.apache.org/jira/browse/IGNITE-4031
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 1.6
>Reporter: Andrew Mashenkov
>Priority: Major
>  Labels: sql-performance
>
> When sql function with Date\Time\Timestamp arguments is used, H2 internals 
> convert these objects using java.util.Calendar before pass them as arguments.
> In current H2 version we use: DateTimeUtils holds cache java.util.Calendar 
> instance in static field and synchronize every operation on it.
> If its possible, we need to have workaround to use java.util.Calendar more 
> effectively as it done for timestamp fields. See IgniteH2Indexing.wrap() 
> method.
> Startpoint: GridSQLQueryParser.FUNC_ALIAS



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

[jira] [Commented] (IGNITE-7743) JDBC driver allows to connect to non existent schema

[Pavel Kuznetsov (JIRA)]

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

Pavel Kuznetsov commented on IGNITE-7743:
-

note: Empty sql schema ("") is handled on the driver side without performing 
connection to server.

> JDBC driver allows to connect to non existent schema
> 
>
> Key: IGNITE-7743
> URL: https://issues.apache.org/jira/browse/IGNITE-7743
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Pavel Kuznetsov
>Priority: Major
>  Labels: usability
> Fix For: 2.5
>
>
> Currently, if one creates a cache without DDL (via {{QueryEntity}} or 
> {{indexedTypes}}), separate schema for this cache is created. Schema name is 
> case sensitive, so to connect to it with JDBC driver, it's required to 
> provide the name in quotes. Here is how it looks like in SqlLine:
> {noformat}
> ./bin/sqlline.sh -u jdbc:ignite:thin://127.0.0.1/\"CacheQueryExamplePersons\"
> {noformat}
> However, if name is provided without quotes, driver still connects, but then 
> fails with a very unclear exception when a query is executed:
> {noformat}
> ./bin/sqlline.sh -u 
> jdbc:ignite:thin://127.0.0.1/CacheQueryExamplePersons{noformat}
> This is a huge usability issue. We should disallow connections to schema that 
> does not exist, throw exception in this case. Exception should provide proper 
> explanation how to connect properly.



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

[jira] [Comment Edited] (IGNITE-8141) Improve OS config suggestions: SWAPPINESS

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov edited comment on IGNITE-8141 at 4/5/18 4:42 PM:


[~amashenkov], could you please confirm it would be useful for all users to set 
swap space lower than 10% (and we should include this suggestion to Ignite 
2.5(2.6) )?

AI docs recommends set this parameter to zero: 
https://apacheignite.readme.io/docs/durable-memory-tuning#section-adjust-swappiness-settings



was (Author: dpavlov):
[~amashenkov], could you please confirm it would be useful for all users to set 
swap space lower than 10% (and we should include this suggestion to Ignite 
2.5(2.6) )?

> Improve OS config suggestions: SWAPPINESS
> -
>
> Key: IGNITE-8141
> URL: https://issues.apache.org/jira/browse/IGNITE-8141
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 2.4
>Reporter: Reed Sandberg
>Assignee: Reed Sandberg
>Priority: Minor
>  Labels: pull-request-available
>
> Acknowledge suggested SWAPPINESS OS param adjustment using a range (<= 10).



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

[jira] [Created] (IGNITE-8152) Forbid empty sql schema name

[Pavel Kuznetsov (JIRA)]

Pavel Kuznetsov created IGNITE-8152:
---

 Summary: Forbid empty sql schema name
 Key: IGNITE-8152
 URL: https://issues.apache.org/jira/browse/IGNITE-8152
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Kuznetsov
Assignee: Vladimir Ozerov


Currently we allow empty schema name (quoted) in cache configuration
org.apache.ignite.configuration.CacheConfiguration#setSqlSchema :
{noformat}
When sqlSchema is not specified, quoted cacheName is used instead.

sqlSchema could not be an empty string. Has to be "\"\"" instead.

Params:
sqlSchema - Schema name for current cache according to SQL ANSI-99. Should not 
be null.
{noformat}

Specifying schema \"\" results in empty string schema name.
No schema in sql query is treated as PUBLIC, but \"\" is regular schema name.

It's better to disallow usage of \"\" schema




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

[jira] [Commented] (IGNITE-8141) Improve OS config suggestions: SWAPPINESS

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8141:


[~amashenkov], could you please confirm it would be useful for all users to set 
swap space lower than 10% (and we should include this suggestion to Ignite 
2.5(2.6) )?

> Improve OS config suggestions: SWAPPINESS
> -
>
> Key: IGNITE-8141
> URL: https://issues.apache.org/jira/browse/IGNITE-8141
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 2.4
>Reporter: Reed Sandberg
>Assignee: Reed Sandberg
>Priority: Minor
>  Labels: pull-request-available
>
> Acknowledge suggested SWAPPINESS OS param adjustment using a range (<= 10).



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

[jira] [Assigned] (IGNITE-6793) NPE in InitNewCoordinatorFuture leading to Cache3 suite hang

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov reassigned IGNITE-6793:


Assignee: Vitaliy Biryukov

> NPE in InitNewCoordinatorFuture leading to Cache3 suite hang
> 
>
> Key: IGNITE-6793
> URL: https://issues.apache.org/jira/browse/IGNITE-6793
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Alexey Goncharuk
>Assignee: Vitaliy Biryukov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Got the following exception in the IgniteCacheGroupsTest run:
> {code}
> [17:59:25]W:   [org.apache.ignite:ignite-core] [2017-10-30 
> 14:59:25,159][ERROR][sys-#35070%cache.IgniteCacheGroupsTest2%][GridCacheIoManager]
>  Failed processing message [senderId=9a523ce6-a252-457f-8175-7246b6c4, 
> msg=GridDhtPartitionsSingleMessage [parts={3181548=GridDhtPartitionMap 
> [moving=0, top=AffinityTopologyVersion [topVer=42, minorTopVer=2], 
> updateSeq=1098, size=191], -2100569601=GridDhtPartitionMap [moving=0, 
> top=AffinityTopologyVersion [topVer=42, minorTopVer=2], updateSeq=654, 
> size=100]}, 
> partCntrs={3181548=o.a.i.i.processors.cache.distributed.dht.preloader.CachePartitionPartialCountersMap@78b1774,
>  
> -2100569601=o.a.i.i.processors.cache.distributed.dht.preloader.CachePartitionPartialCountersMap@3cb0c48a},
>  partHistCntrs=null, err=null, client=false, compress=false, 
> finishMsg=GridDhtPartitionsFullMessage [parts=null, partCntrs=null, 
> partCntrs2=null, partHistSuppliers=null, partsToReload=null, 
> topVer=AffinityTopologyVersion [topVer=42, minorTopVer=2], errs=null, 
> compress=false, resTopVer=null, partCnt=0, 
> super=GridDhtPartitionsAbstractMessage [exchId=GridDhtPartitionExchangeId 
> [topVer=AffinityTopologyVersion [topVer=42, minorTopVer=2], discoEvt=null, 
> nodeId=33c058c3, evt=DISCOVERY_CUSTOM_EVT], lastVer=GridCacheVersion 
> [topVer=120855515, order=1509375572161, nodeOrder=32], super=GridCacheMessage 
> [msgId=4153599, depInfo=null, err=null, skipPrepare=false]]], 
> super=GridDhtPartitionsAbstractMessage [exchId=GridDhtPartitionExchangeId 
> [topVer=AffinityTopologyVersion [topVer=42, minorTopVer=2], discoEvt=null, 
> nodeId=33c058c3, evt=DISCOVERY_CUSTOM_EVT], lastVer=GridCacheVersion 
> [topVer=120855515, order=1509375572153, nodeOrder=38], super=GridCacheMessage 
> [msgId=4153605, depInfo=null, err=null, skipPrepare=false
> [17:59:25]W:   [org.apache.ignite:ignite-core] 
> java.lang.NullPointerException
> [17:59:25]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.InitNewCoordinatorFuture.onMessage(InitNewCoordinatorFuture.java:238)
> [17:59:25]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:1749)
> [17:59:25]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1484)
> [17:59:25]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1000(GridCachePartitionExchangeManager.java:131)
> [17:59:25]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:327)
> [17:59:25]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:307)
> [17:59:25]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2627)
> [17:59:25]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2606)
> [17:59:25]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
> [17:59:25]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> [17:59:25]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> [17:59:25]W: 

[jira] [Commented] (IGNITE-8106) In control.sh -active, exception will be eaten and not displayed

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-8106:
--

Looks good form me.

Couple of notes:
 # Remove assert
 # Add test for new method

> In control.sh -active, exception will be eaten and not displayed
> 
>
> Key: IGNITE-8106
> URL: https://issues.apache.org/jira/browse/IGNITE-8106
> Project: Ignite
>  Issue Type: Bug
>  Components: clients
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Minor
>
> Here is the relevant code from GridChangeStateCommandHandler:
> {code}
> sb.a(e.getMessage()).a("\n").a("suppressed: \n");
> for (Throwable t:e.getSuppressed())
> sb.a(t.getMessage()).a("\n");
> {code}
> However, before that code the exception will pass through 
> IgniteUtils.convertException(), which will wrap the old 
> IgniteCheckedException with suppressed parts with a new IgniteException with 
> 0 suppressed.



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

[jira] [Commented] (IGNITE-8059) Integrate decision tree with partition based dataset

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8059:


GitHub user dmitrievanthony opened a pull request:

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

IGNITE-8059 Integrate decision tree with partition based dataset



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

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

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

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


commit 820694f2e8a47847e43167cbbc30fbc7d9b47c7b
Author: Anton Dmitriev 
Date:   2018-04-05T08:16:28Z

IGNITE-8059 Initial version of decision trees implemented on top of
partition based dataset.

commit 3860e5a171c8cae1f38c73fe30c8d3d2e2a46246
Author: Anton Dmitriev 
Date:   2018-04-05T10:07:55Z

IGNITE-8059 Add tests for impurity (decision trees).

commit b8dbb817d288f3f57ed6373e76dacab5c48a68c1
Author: Anton Dmitriev 
Date:   2018-04-05T12:57:25Z

IGNITE-8059 Add tests for decision trees regression and classification
trainers, add special decision tree partition data class.

commit c3b54ed2663c8a8ab2697146f0437d9f104f25cf
Author: Anton Dmitriev 
Date:   2018-04-05T13:19:45Z

IGNITE-8059 Add step function compressor (initial version).

commit 08798caa274a60d065a7b716253b8c6fa54ee5b1
Author: Anton Dmitriev 
Date:   2018-04-05T14:04:13Z

IGNITE-8059 Add MNIST test for decision tree algorithm.

commit 01e9b1c6a7ed74ae5c71ecedc13aee7df341980a
Author: Anton Dmitriev 
Date:   2018-04-05T16:02:03Z

IGNITE-8059 Add MNIST tests and remove UI part of decision tree.




> Integrate decision tree with partition based dataset
> 
>
> Key: IGNITE-8059
> URL: https://issues.apache.org/jira/browse/IGNITE-8059
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Anton Dmitriev
>Assignee: Anton Dmitriev
>Priority: Major
> Fix For: 2.5
>
>
> A partition based dataset (new underlying infrastructure component) was added 
> as part of IGNITE-7437 and now we need to adopt decision tree algorithm to 
> work on top of this infrastructure. 



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

[jira] [Commented] (IGNITE-8106) In control.sh -active, exception will be eaten and not displayed

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8106:


I've retriggered tests run, because there are a lot of failures ocurred.

> In control.sh -active, exception will be eaten and not displayed
> 
>
> Key: IGNITE-8106
> URL: https://issues.apache.org/jira/browse/IGNITE-8106
> Project: Ignite
>  Issue Type: Bug
>  Components: clients
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Minor
>
> Here is the relevant code from GridChangeStateCommandHandler:
> {code}
> sb.a(e.getMessage()).a("\n").a("suppressed: \n");
> for (Throwable t:e.getSuppressed())
> sb.a(t.getMessage()).a("\n");
> {code}
> However, before that code the exception will pass through 
> IgniteUtils.convertException(), which will wrap the old 
> IgniteCheckedException with suppressed parts with a new IgniteException with 
> 0 suppressed.



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

[jira] [Commented] (IGNITE-8106) In control.sh -active, exception will be eaten and not displayed

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8106:


[~kuaw26], could you please take a look to proposed changes?

> In control.sh -active, exception will be eaten and not displayed
> 
>
> Key: IGNITE-8106
> URL: https://issues.apache.org/jira/browse/IGNITE-8106
> Project: Ignite
>  Issue Type: Bug
>  Components: clients
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Minor
>
> Here is the relevant code from GridChangeStateCommandHandler:
> {code}
> sb.a(e.getMessage()).a("\n").a("suppressed: \n");
> for (Throwable t:e.getSuppressed())
> sb.a(t.getMessage()).a("\n");
> {code}
> However, before that code the exception will pass through 
> IgniteUtils.convertException(), which will wrap the old 
> IgniteCheckedException with suppressed parts with a new IgniteException with 
> 0 suppressed.



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

[jira] [Created] (IGNITE-8151) ODBC driver should scheck schema on connection start

[Pavel Kuznetsov (JIRA)]

Pavel Kuznetsov created IGNITE-8151:
---

 Summary: ODBC driver should scheck schema on connection start
 Key: IGNITE-8151
 URL: https://issues.apache.org/jira/browse/IGNITE-8151
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.5
Reporter: Pavel Kuznetsov
Assignee: Igor Sapego


We need to add validation of schema in odbc driver.
1) Need to update protocol to send schema with connection start.
2) Forbid empty sql id (\"\") as sql schema. 
see IGNITE-7743 for details




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

[jira] [Commented] (IGNITE-6252) Cassandra Cache Store Session does not retry if prepare statement failed

[Yashasvi Kotamraju (JIRA)]

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

Yashasvi Kotamraju commented on IGNITE-6252:


Also whenever session refresh() is called to handle Exception, new session is 
created. But there might be many preparedstatements created with old session. 
So when we execute the preparedstatements created with old session on a new 
session created , we get the the Exception 
"com.datastax.driver.core.exceptions.InvalidQueryException  Tried to execute 
unknown prepared query " which would again refresh and create new cassandra 
session and so on ...refresh() will be called continuosly

> Cassandra Cache Store Session does not retry if prepare statement failed
> 
>
> Key: IGNITE-6252
> URL: https://issues.apache.org/jira/browse/IGNITE-6252
> Project: Ignite
>  Issue Type: Bug
>  Components: cassandra
>Affects Versions: 2.0, 2.1
>Reporter: Sunny Chan
>Assignee: Igor Rudyak
>Priority: Major
> Fix For: 2.5
>
>
> During our testing, we have found that certain warning about prepared 
> statement:
> 2017-08-31 11:27:19.479 
> org.apache.ignite.cache.store.cassandra.CassandraCacheStore 
> flusher-0-#265%% WARN CassandraCacheStore - Prepared statement cluster 
> error detected, refreshing Cassandra session
> com.datastax.driver.core.exceptions.InvalidQueryException: Tried to execute 
> unknown prepared query : 0xc7647611fd755386ef63478ee7de577b. You may have 
> used a PreparedStatement that was created with another Cluster instance.
> We notice that after this warning occurs some of the data didn't persist 
> properly in cassandra cache. After further examining the Ignite's 
> CassandraSessionImpl code in method 
> execute(BatchExecutionAssistance,Iterable), we found that at around [line 
> 283|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L283],
>  if the prepare statement fails in the asnyc call, it will not retry the 
> operation as the error is stored in [line 
> 269|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L269]
>  and cleared in [line 
> 277|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L277]
>  but it was not checked again after going through the [ResultSetFuture 
> |https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L307].
> I believe in line 307 you should check for error != null such that any 
> failure will be retry.



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

[jira] [Commented] (IGNITE-8150) Fix suite [Prepare Vote #1] .Net & C++

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8150:


Github user isapego closed the pull request at:

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


> Fix suite [Prepare Vote #1] .Net & C++
> --
>
> Key: IGNITE-8150
> URL: https://issues.apache.org/jira/browse/IGNITE-8150
> Project: Ignite
>  Issue Type: Task
>  Components: build, odbc
>Affects Versions: 2.4
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.5
>
>
> There is two different OpenSSL versions for Win32 and Win64 suites. However, 
> there is only one environment variable - {{OPENSSL_HOME}}, which can not be 
> set to different values during build.



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

[jira] [Commented] (IGNITE-8150) Fix suite [Prepare Vote #1] .Net & C++

[Igor Seliverstov (JIRA)]

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

Igor Seliverstov commented on IGNITE-8150:
--

[~isapego], looks OK

> Fix suite [Prepare Vote #1] .Net & C++
> --
>
> Key: IGNITE-8150
> URL: https://issues.apache.org/jira/browse/IGNITE-8150
> Project: Ignite
>  Issue Type: Task
>  Components: build, odbc
>Affects Versions: 2.4
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.5
>
>
> There is two different OpenSSL versions for Win32 and Win64 suites. However, 
> there is only one environment variable - {{OPENSSL_HOME}}, which can not be 
> set to different values during build.



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

[jira] [Commented] (IGNITE-7904) ComputeTaskFuture.get() throws incorrect exception if ComputeTask.result() throws IgniteException

[Stanislav Lukyanov (JIRA)]

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

Stanislav Lukyanov commented on IGNITE-7904:


Confirmed tests pass:
Compute (Grid): 
https://ci.ignite.apache.org/viewLog.html?buildId=1181097=buildResultsDiv=IgniteTests24Java8_ComputeGrid
Java Client: 
https://ci.ignite.apache.org/viewLog.html?buildId=1181095=buildResultsDiv=IgniteTests24Java8_JavaClient

Cache (Restarts) seems to fail with timeout error in different branches: 
https://ci.ignite.apache.org/viewLog.html?buildId=1181083=buildResultsDiv=IgniteTests24Java8_CacheRestarts1
https://ci.ignite.apache.org/viewLog.html?buildId=1178979=buildResultsDiv=IgniteTests24Java8_CacheRestarts1

> ComputeTaskFuture.get() throws incorrect exception if ComputeTask.result() 
> throws IgniteException
> -
>
> Key: IGNITE-7904
> URL: https://issues.apache.org/jira/browse/IGNITE-7904
> Project: Ignite
>  Issue Type: Bug
>Reporter: Stanislav Lukyanov
>Assignee: Stanislav Lukyanov
>Priority: Major
> Fix For: 2.5
>
>
> ComputeTask.result() javadoc says: "Throws: IgniteException - If handling a 
> job result caused an error effectively rejecting a failover. This exception 
> will be thrown out of ComputeTaskFuture.get() method."
> However, GridFutureAdapter calls IgniteUtils.cast(Throwable) on the exception 
> before throwing it from get(), and the latter method trims the stack trace to 
> the first occurence of an IgniteCheckedException. Because of that, get() 
> throws not the IgniteException thrown from the ComputeTask.result() but one 
> of its causes.



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

[jira] [Commented] (IGNITE-5994) IgniteInternalCache.invokeAsync().get() can return null

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov commented on IGNITE-5994:
-

I gonna take Zhang Yuan's PR and bring it to merged state.

> IgniteInternalCache.invokeAsync().get() can return null
> ---
>
> Key: IGNITE-5994
> URL: https://issues.apache.org/jira/browse/IGNITE-5994
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Alexander Menshikov
>Assignee: Alexander Menshikov
>Priority: Minor
>  Labels: newbie
> Attachments: IgniteCacheSelfTest.java, 
> master_8629b50d6f_ignite-5994.patch
>
>
> The IgniteInternalCache.invoke() always return an EntryProcessorResult, but 
> the IgniteInternalCache.invokeAsync().get() can return the null in case when 
> an EntryProcessor has returned the null.
> Code from reproducer:
> {noformat}
> final EntryProcessor ep = new EntryProcessor Object, Object>() {
> @Override
> public Object process(MutableEntry entry,
> Object... objects) throws EntryProcessorException {
> return null;
> }
> };
> EntryProcessorResult result = utilCache.invoke("test", ep);
> assertNotNull(result);
> assertNull(result.get());
> result = utilCache.invokeAsync("test", ep).get();
> // Assert here!!!
> assertNotNull(result);
> assertNull(result.get());
> {noformat}
> It can be optimization. Nevertheless results of invoke() must be equals with 
> results of invokeAsync().get(). So there are two options:
> 1) To do so would be the invokeAsync(key, ep).get() returned the null too for 
> the optimization.
> 2) Or to do so would be the invoke(key, ep) returned an EntryProcessorResult 
> for a logical consistency.
> NOTE: Don't confuse with IgniteCache.invoke.



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

[jira] [Assigned] (IGNITE-5994) IgniteInternalCache.invokeAsync().get() can return null

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov reassigned IGNITE-5994:
---

Assignee: Alexander Menshikov

> IgniteInternalCache.invokeAsync().get() can return null
> ---
>
> Key: IGNITE-5994
> URL: https://issues.apache.org/jira/browse/IGNITE-5994
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Alexander Menshikov
>Assignee: Alexander Menshikov
>Priority: Minor
>  Labels: newbie
> Attachments: IgniteCacheSelfTest.java, 
> master_8629b50d6f_ignite-5994.patch
>
>
> The IgniteInternalCache.invoke() always return an EntryProcessorResult, but 
> the IgniteInternalCache.invokeAsync().get() can return the null in case when 
> an EntryProcessor has returned the null.
> Code from reproducer:
> {noformat}
> final EntryProcessor ep = new EntryProcessor Object, Object>() {
> @Override
> public Object process(MutableEntry entry,
> Object... objects) throws EntryProcessorException {
> return null;
> }
> };
> EntryProcessorResult result = utilCache.invoke("test", ep);
> assertNotNull(result);
> assertNull(result.get());
> result = utilCache.invokeAsync("test", ep).get();
> // Assert here!!!
> assertNotNull(result);
> assertNull(result.get());
> {noformat}
> It can be optimization. Nevertheless results of invoke() must be equals with 
> results of invokeAsync().get(). So there are two options:
> 1) To do so would be the invokeAsync(key, ep).get() returned the null too for 
> the optimization.
> 2) Or to do so would be the invoke(key, ep) returned an EntryProcessorResult 
> for a logical consistency.
> NOTE: Don't confuse with IgniteCache.invoke.



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

[jira] [Commented] (IGNITE-6113) Partition eviction prevents exchange from completion

[Joel Lang (JIRA)]

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

Joel Lang commented on IGNITE-6113:
---

Is there a workaround for this issue?

> Partition eviction prevents exchange from completion
> 
>
> Key: IGNITE-6113
> URL: https://issues.apache.org/jira/browse/IGNITE-6113
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, persistence
>Affects Versions: 2.1
>Reporter: Vladislav Pyatkov
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.5
>
>
> I has waited for 3 hours for completion without any success.
> exchange-worker is blocked.
> {noformat}
> "exchange-worker-#92%DPL_GRID%grid554.ca.sbrf.ru%" #173 prio=5 os_prio=0 
> tid=0x7f0835c2e000 nid=0xb907 runnable [0x7e74ab1d]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0x7efee630a7c0> (a 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition$1)
> at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:189)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:139)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.assign(GridDhtPreloader.java:340)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1801)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
>Locked ownable synchronizers:
> - None
> {noformat}
> {noformat}
> "sys-#124%DPL_GRID%grid554.ca.sbrf.ru%" #278 prio=5 os_prio=0 
> tid=0x7e731c02d000 nid=0xbf4d runnable [0x7e734e7f7000]
>java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.FileDispatcherImpl.write(FileDispatcherImpl.java:60)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:51)
> at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:211)
> - locked <0x7f056161bf88> (a java.lang.Object)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.writeBuffer(FileWriteAheadLogManager.java:1829)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.flush(FileWriteAheadLogManager.java:1572)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.addRecord(FileWriteAheadLogManager.java:1421)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.access$800(FileWriteAheadLogManager.java:1331)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager.log(FileWriteAheadLogManager.java:339)
> at 
> org.gridgain.grid.internal.processors.cache.database.pagemem.PageMemoryImpl.beforeReleaseWrite(PageMemoryImpl.java:1287)
> at 
> org.gridgain.grid.internal.processors.cache.database.pagemem.PageMemoryImpl.writeUnlockPage(PageMemoryImpl.java:1142)
> at 
> org.gridgain.grid.internal.processors.cache.database.pagemem.PageImpl.releaseWrite(PageImpl.java:167)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writeUnlock(PageHandler.java:193)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writePage(PageHandler.java:242)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writePage(PageHandler.java:119)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.doRemoveFromLeaf(BPlusTree.java:2886)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.removeFromLeaf(BPlusTree.java:2865)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.access$6900(BPlusTree.java:2515)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.removeDown(BPlusTree.java:1607)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.removeDown(BPlusTree.java:1574)
> at 
> 

[jira] [Commented] (IGNITE-5813) Inconsistent cache store state when originating node fails on commit.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5813:


Github user AMashenkov closed the pull request at:

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


> Inconsistent cache store state when originating node fails on commit.
> -
>
> Key: IGNITE-5813
> URL: https://issues.apache.org/jira/browse/IGNITE-5813
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Andrew Mashenkov
>Priority: Major
> Attachments: IgniteTxRecoveryAfterStoreCommitSelfTest.java
>
>
> Same tx can be rolled back by cache and commited by CacheStore.
> It is possible when originating tx node commit tx successfully, but fails to 
> notify other nodes. 
> PFA reproducer.



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

[jira] [Commented] (IGNITE-5473) Create ignite troubleshooting logger

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5473:


Github user AMashenkov closed the pull request at:

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


> Create ignite troubleshooting logger
> 
>
> Key: IGNITE-5473
> URL: https://issues.apache.org/jira/browse/IGNITE-5473
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.0
>Reporter: Alexey Goncharuk
>Priority: Critical
>  Labels: important, observability
> Fix For: 2.5
>
>
> Currently, we have two extremes of logging - either INFO wich logs almost 
> nothing, or DEBUG, which will pollute logs with too verbose messages.
> We should create a 'troubleshooting' logger, which should be easily enabled 
> (via a system property, for example) and log all stability-critical node and 
> cluster events:
>  * Connection events (both communication and discovery), handshake status
>  * ALL ignored messages and skipped actions (even those we assume are safe to 
> ignore)
>  * Partition exchange stages and timings
>  * Verbose discovery state changes (this should make it easy to understand 
> the reason for 'Node has not been connected to the topology')
>  * Transaction failover stages and actions
>  * All unlogged exceptions
>  * Responses that took more than N milliseconds when in normal they should 
> return right away
>  * Long discovery SPI messages processing times
>  * Managed service deployment stages
>  * Marshaller mappings registration and notification
>  * Binary metadata registration and notification
>  * Continuous query registration / notification
> (add more)
> The amount of logging should be chosen accurately so that it would be safe to 
> enable this logger in production clusters.



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

[jira] [Commented] (IGNITE-7944) Disconnected client node tries to send JOB_CANCEL message

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7944:


Test looks like a newly introduced failure:
 Ignite Queries [1] [ tests 1 ]
   IgniteBinaryCacheQueryTestSuite: 
IgniteSqlSplitterSelfTest.testReplicatedTablesUsingPartitionedCacheClientRO 
(master fail rate 0,0%) 

[~guseinov], could you please check reasons of this failure?

> Disconnected client node tries to send JOB_CANCEL message
> -
>
> Key: IGNITE-7944
> URL: https://issues.apache.org/jira/browse/IGNITE-7944
> Project: Ignite
>  Issue Type: Bug
>  Components: messaging
>Affects Versions: 1.9, 2.3
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
> Fix For: 2.5
>
> Attachments: Reproducer7944.java
>
>
> In case the network is blocked (socket connections not closed) and failure is 
> detected, tcp-client-disco-msg-worker thread can be stuck in process of 
> TcpClient creating:
> {code:java}
> "tcp-client-disco-msg-worker-#4%wd5prsvtots0016a-tg-QueryFabric%" #494 prio=5 
> os_prio=0 tid=0x7f94c067c800 nid=0x2bdf runnable [0x7f960ecf1000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.Net.poll(Native Method)
> at sun.nio.ch.SocketChannelImpl.poll(SocketChannelImpl.java:954)
> - locked <0x7fa140f520c0> (a java.lang.Object)
> at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:110)
> - locked <0x7fa140f520b0> (a java.lang.Object)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2950)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2681)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2568)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2429)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2393)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1590)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1659)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.cancelChildren(GridTaskWorker.java:1305)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1609)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1581)
> at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.onDisconnected(GridTaskProcessor.java:168)
> at 
> org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:3460)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:601)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2407)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2386)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1714)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> It looks like msg-worker is trying to send JOB_CANCEL message for each job 
> with timeout equals failureDetectionTimeout.
> Reproducer is attached.



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

[jira] [Commented] (IGNITE-8150) Fix suite [Prepare Vote #1] .Net & C++

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8150:


GitHub user isapego opened a pull request:

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

IGNITE-8150: Fix for release suite step 1



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

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

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

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


commit 981c5917372b15b2b4607e540de4b8c027dd5110
Author: Igor Sapego 
Date:   2018-04-05T14:31:32Z

IGNITE-8150: Fix




> Fix suite [Prepare Vote #1] .Net & C++
> --
>
> Key: IGNITE-8150
> URL: https://issues.apache.org/jira/browse/IGNITE-8150
> Project: Ignite
>  Issue Type: Task
>  Components: build, odbc
>Affects Versions: 2.4
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.5
>
>
> There is two different OpenSSL versions for Win32 and Win64 suites. However, 
> there is only one environment variable - {{OPENSSL_HOME}}, which can not be 
> set to different values during build.



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

[jira] [Commented] (IGNITE-7944) Disconnected client node tries to send JOB_CANCEL message

[Roman Guseinov (JIRA)]

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

Roman Guseinov commented on IGNITE-7944:


[~dpavlov] , 

could you review PR [https://github.com/apache/ignite/pull/3737], please? 

TC results: 
[https://ci.ignite.apache.org/viewLog.html?buildId=1180152=queuedBuildOverviewTab]

23 new failed test. I checked them and they look flaky.

Thanks.

> Disconnected client node tries to send JOB_CANCEL message
> -
>
> Key: IGNITE-7944
> URL: https://issues.apache.org/jira/browse/IGNITE-7944
> Project: Ignite
>  Issue Type: Bug
>  Components: messaging
>Affects Versions: 1.9, 2.3
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
> Fix For: 2.5
>
> Attachments: Reproducer7944.java
>
>
> In case the network is blocked (socket connections not closed) and failure is 
> detected, tcp-client-disco-msg-worker thread can be stuck in process of 
> TcpClient creating:
> {code:java}
> "tcp-client-disco-msg-worker-#4%wd5prsvtots0016a-tg-QueryFabric%" #494 prio=5 
> os_prio=0 tid=0x7f94c067c800 nid=0x2bdf runnable [0x7f960ecf1000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.Net.poll(Native Method)
> at sun.nio.ch.SocketChannelImpl.poll(SocketChannelImpl.java:954)
> - locked <0x7fa140f520c0> (a java.lang.Object)
> at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:110)
> - locked <0x7fa140f520b0> (a java.lang.Object)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2950)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2681)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2568)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2429)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2393)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1590)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1659)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.cancelChildren(GridTaskWorker.java:1305)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1609)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1581)
> at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.onDisconnected(GridTaskProcessor.java:168)
> at 
> org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:3460)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:601)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2407)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2386)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1714)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> It looks like msg-worker is trying to send JOB_CANCEL message for each job 
> with timeout equals failureDetectionTimeout.
> Reproducer is attached.



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

[jira] [Commented] (IGNITE-7944) Disconnected client node tries to send JOB_CANCEL message

[Roman Guseinov (JIRA)]

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

Roman Guseinov commented on IGNITE-7944:


[~amashenkov] , thank you

> Disconnected client node tries to send JOB_CANCEL message
> -
>
> Key: IGNITE-7944
> URL: https://issues.apache.org/jira/browse/IGNITE-7944
> Project: Ignite
>  Issue Type: Bug
>  Components: messaging
>Affects Versions: 1.9, 2.3
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
> Fix For: 2.5
>
> Attachments: Reproducer7944.java
>
>
> In case the network is blocked (socket connections not closed) and failure is 
> detected, tcp-client-disco-msg-worker thread can be stuck in process of 
> TcpClient creating:
> {code:java}
> "tcp-client-disco-msg-worker-#4%wd5prsvtots0016a-tg-QueryFabric%" #494 prio=5 
> os_prio=0 tid=0x7f94c067c800 nid=0x2bdf runnable [0x7f960ecf1000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.Net.poll(Native Method)
> at sun.nio.ch.SocketChannelImpl.poll(SocketChannelImpl.java:954)
> - locked <0x7fa140f520c0> (a java.lang.Object)
> at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:110)
> - locked <0x7fa140f520b0> (a java.lang.Object)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2950)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2681)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2568)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2429)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2393)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1590)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1659)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.cancelChildren(GridTaskWorker.java:1305)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1609)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1581)
> at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.onDisconnected(GridTaskProcessor.java:168)
> at 
> org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:3460)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:601)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2407)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2386)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1714)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> It looks like msg-worker is trying to send JOB_CANCEL message for each job 
> with timeout equals failureDetectionTimeout.
> Reproducer is attached.



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

[jira] [Commented] (IGNITE-7944) Disconnected client node tries to send JOB_CANCEL message

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-7944:
--

[~guseinov],

Fix looks good for me can be merged if there is no TC issues.

> Disconnected client node tries to send JOB_CANCEL message
> -
>
> Key: IGNITE-7944
> URL: https://issues.apache.org/jira/browse/IGNITE-7944
> Project: Ignite
>  Issue Type: Bug
>  Components: messaging
>Affects Versions: 1.9, 2.3
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
> Fix For: 2.5
>
> Attachments: Reproducer7944.java
>
>
> In case the network is blocked (socket connections not closed) and failure is 
> detected, tcp-client-disco-msg-worker thread can be stuck in process of 
> TcpClient creating:
> {code:java}
> "tcp-client-disco-msg-worker-#4%wd5prsvtots0016a-tg-QueryFabric%" #494 prio=5 
> os_prio=0 tid=0x7f94c067c800 nid=0x2bdf runnable [0x7f960ecf1000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.Net.poll(Native Method)
> at sun.nio.ch.SocketChannelImpl.poll(SocketChannelImpl.java:954)
> - locked <0x7fa140f520c0> (a java.lang.Object)
> at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:110)
> - locked <0x7fa140f520b0> (a java.lang.Object)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2950)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2681)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2568)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2429)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2393)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1590)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1659)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.cancelChildren(GridTaskWorker.java:1305)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1609)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1581)
> at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.onDisconnected(GridTaskProcessor.java:168)
> at 
> org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:3460)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:601)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2407)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2386)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1714)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> It looks like msg-worker is trying to send JOB_CANCEL message for each job 
> with timeout equals failureDetectionTimeout.
> Reproducer is attached.



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

[jira] [Created] (IGNITE-8150) Fix suite [Prepare Vote #1] .Net & C++

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-8150:
---

 Summary: Fix suite [Prepare Vote #1] .Net & C++
 Key: IGNITE-8150
 URL: https://issues.apache.org/jira/browse/IGNITE-8150
 Project: Ignite
  Issue Type: Task
  Components: build, odbc
Affects Versions: 2.4
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 2.5


There is two different OpenSSL versions for Win32 and Win64 suites. However, 
there is only one environment variable - {{OPENSSL_HOME}}, which can not be set 
to different values during build.



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

[jira] [Created] (IGNITE-8149) MVCC TX Size method should use tx snapshot

[Igor Seliverstov (JIRA)]

Igor Seliverstov created IGNITE-8149:


 Summary: MVCC TX Size method should use tx snapshot
 Key: IGNITE-8149
 URL: https://issues.apache.org/jira/browse/IGNITE-8149
 Project: Ignite
  Issue Type: Task
  Components: cache
Reporter: Igor Seliverstov


Currently cache.size() returns number of entries in cache trees while there can 
be several versions of one key-value pairs.

We should use tx snapshot and count all passed mvcc filter entries instead.



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

[jira] [Commented] (IGNITE-6879) Support Spring 2.0

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii commented on IGNITE-6879:


Ok for me.

> Support Spring 2.0
> --
>
> Key: IGNITE-6879
> URL: https://issues.apache.org/jira/browse/IGNITE-6879
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.3
>Reporter: Alexey Kukushkin
>Assignee: Roman Meerson
>Priority: Major
>
> Ignite-spring and ignite-spring-data now use Spring 1.1 and cannot be rebuilt 
> with Spring 2.0. Trying to change the Spring dependency version to 
> 2.0.0.release results in compile errors like below and requires regression in 
> general. 
> This improvement was created to either migrate from Spring 1.1 to 2.0 or 
> create another set of modules ignite-spring-xxx-2 to have backward 
> compatibility with Spring 1.1.
> [ERROR] 
> /Users/kukushal/Dev/incubator-ignite/modules/spring-data/src/main/java/org/apache/ignite/springdata/repository/IgniteRepository.java:[57,10]
>  name clash: deleteAll(java.lang.Iterable) in 
> org.apache.ignite.springdata.repository.IgniteRepository and 
> deleteAll(java.lang.Iterable) in 
> org.springframework.data.repository.CrudRepository have the same erasure, yet 
> neither overrides the other



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

[jira] [Comment Edited] (IGNITE-8049) Limit the number of operation cycles in B+Tree

[Ivan Rakov (JIRA)]

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

Ivan Rakov edited comment on IGNITE-8049 at 4/5/18 1:34 PM:


[~astelmak], I've looked through your changes and have some comments:
1. If you want to introduce new Ignite system property, it's better to declare 
it along with other ones as static field of IgniteSystemProperties class.
2. It's arguable and depends on personal sense of code clarity, but I expect 
that method "*can*LockRetry" will return boolean. I'd rename it into 
"*check*LockRetryCount" or something like that.
3. BPlusTree#getLockRetries accesses property map on every B+ tree operation. 
It's unlikely that it will be changed in runtime - so I guess map lookup result 
can be memoized as static field of B+ tree class (you still will be able to 
override it via overriding #getLockRetries).

Also, few comments regarding code style (see 
https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines for more 
info):
1. New field BPlusTree.Get#lockRetriesCnt lacks a meaningful javadoc.
2. BPlusTree.Get#canLockRetry lacks blank line
3. BPlusTreeSelfTest - unused imports
4. BPlusTreeSelfTest#testRetries lacks blank line (between put and fail)


was (Author: ivan.glukos):
[~astelmak], I've looked through your changes and have some comments:
1. If you want to introduce new Ignite system property, it's better to declare 
it along with other ones as static field of IgniteSystemProperties class.
2. It's arguable and depends on personal sense of code clarity, but I expect 
that method "*can*LockRetry" will return boolean. I'd rename it into 
"*check*LockRetryCount" or something like that.
3. BPlusTree#getLockRetries accesses property map on every B+ tree operation. 
It's unlikely that it will be changed in runtime - so I guess map lookup result 
can be memoized as static field of B+ tree class (you still will be able to 
override it via overriding #getLockRetries).

Also, few comments regarding code style:
1. New field BPlusTree.Get#lockRetriesCnt lacks a meaningful javadoc.
2. BPlusTree.Get#canLockRetry lacks blank line
3. BPlusTreeSelfTest - unused imports
4. BPlusTreeSelfTest#testRetries lacks blank line (between put and fail)

> Limit the number of operation cycles in B+Tree
> --
>
> Key: IGNITE-8049
> URL: https://issues.apache.org/jira/browse/IGNITE-8049
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Alexey Goncharuk
>Assignee: Alexey Stelmak
>Priority: Major
> Fix For: 2.5
>
>
> When a tree is corrupted, a B+Tree operation may result in an infinite loop. 
> We should limit the number of retries and fail if this limit is exceeded.



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

[jira] [Commented] (IGNITE-8049) Limit the number of operation cycles in B+Tree

[Ivan Rakov (JIRA)]

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

Ivan Rakov commented on IGNITE-8049:


[~astelmak], I've looked through your changes and have some comments:
1. If you want to introduce new Ignite system property, it's better to declare 
it along with other ones as static field of IgniteSystemProperties class.
2. It's arguable and depends on personal sense of code clarity, but I expect 
that method "*can*LockRetry" will return boolean. I'd rename it into 
"*check*LockRetryCount" or something like that.
3. BPlusTree#getLockRetries accesses property map on every B+ tree operation. 
It's unlikely that it will be changed in runtime - so I guess map lookup result 
can be memoized as static field of B+ tree class (you still will be able to 
override it via overriding #getLockRetries).

Also, few comments regarding code style:
1. New field BPlusTree.Get#lockRetriesCnt lacks a meaningful javadoc.
2. BPlusTree.Get#canLockRetry lacks blank line
3. BPlusTreeSelfTest - unused imports
4. BPlusTreeSelfTest#testRetries lacks blank line (between put and fail)

> Limit the number of operation cycles in B+Tree
> --
>
> Key: IGNITE-8049
> URL: https://issues.apache.org/jira/browse/IGNITE-8049
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Alexey Goncharuk
>Assignee: Alexey Stelmak
>Priority: Major
> Fix For: 2.5
>
>
> When a tree is corrupted, a B+Tree operation may result in an infinite loop. 
> We should limit the number of retries and fail if this limit is exceeded.



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

[jira] [Commented] (IGNITE-6879) Support Spring 2.0

[Roman Meerson (JIRA)]

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

Roman Meerson commented on IGNITE-6879:
---

[~SomeFire] done

> Support Spring 2.0
> --
>
> Key: IGNITE-6879
> URL: https://issues.apache.org/jira/browse/IGNITE-6879
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.3
>Reporter: Alexey Kukushkin
>Assignee: Roman Meerson
>Priority: Major
>
> Ignite-spring and ignite-spring-data now use Spring 1.1 and cannot be rebuilt 
> with Spring 2.0. Trying to change the Spring dependency version to 
> 2.0.0.release results in compile errors like below and requires regression in 
> general. 
> This improvement was created to either migrate from Spring 1.1 to 2.0 or 
> create another set of modules ignite-spring-xxx-2 to have backward 
> compatibility with Spring 1.1.
> [ERROR] 
> /Users/kukushal/Dev/incubator-ignite/modules/spring-data/src/main/java/org/apache/ignite/springdata/repository/IgniteRepository.java:[57,10]
>  name clash: deleteAll(java.lang.Iterable) in 
> org.apache.ignite.springdata.repository.IgniteRepository and 
> deleteAll(java.lang.Iterable) in 
> org.springframework.data.repository.CrudRepository have the same erasure, yet 
> neither overrides the other



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

[jira] [Updated] (IGNITE-5714) Implementation of suspend/resume for pessimistic transactions

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov updated IGNITE-5714:

Summary: Implementation of suspend/resume for pessimistic transactions  
(was: Context switching for pessimistic transactions)

> Implementation of suspend/resume for pessimistic transactions
> -
>
> Key: IGNITE-5714
> URL: https://issues.apache.org/jira/browse/IGNITE-5714
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
>
> Support transaction suspend()\resume() operations for pessimistic 
> transactions. Resume can be called in another thread.
>_+But there is a problem+_: Imagine, we started pessimistic transaction in 
> thread T1 and then perform put operation, which leads to sending 
> GridDistributedLockRequest to another node. Lock request contains thread id 
> of the transaction. Then we call suspend, resume in another thread and we 
> also must send messages to other nodes to change thread id. 
> It seems complicated task.It’s better to get rid of sending thread id to the 
> nodes.
> We can use transaction xid on other nodes instead of thread id. Xid is sent 
> to nodes in GridDistributedLockRequest#nearXidVer
>_+Proposed solution+_ : On remote nodes instead of thread id of near 
> transaction GridDistributedLockRequest#threadId use its xid 
> GridDistributedLockRequest#nearXidVer.
> Remove usages of near transaction's thread id on remote nodes.



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

[jira] [Commented] (IGNITE-5714) Context switching for pessimistic transactions

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-5714:
-

[~Alexey Kuznetsov]

Let's make sure that:

1. We support backward compatibility for a network messages.
2. We don't allow user to use new feature unless some nodes in the cluster have 
version {{X-1}}. Where {{X}} is version when we merge this feature.

As far as I can see current changes contains changes for network messages. 
We need to address this issues to complete this task.

> Context switching for pessimistic transactions
> --
>
> Key: IGNITE-5714
> URL: https://issues.apache.org/jira/browse/IGNITE-5714
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
>
> Support transaction suspend()\resume() operations for pessimistic 
> transactions. Resume can be called in another thread.
>_+But there is a problem+_: Imagine, we started pessimistic transaction in 
> thread T1 and then perform put operation, which leads to sending 
> GridDistributedLockRequest to another node. Lock request contains thread id 
> of the transaction. Then we call suspend, resume in another thread and we 
> also must send messages to other nodes to change thread id. 
> It seems complicated task.It’s better to get rid of sending thread id to the 
> nodes.
> We can use transaction xid on other nodes instead of thread id. Xid is sent 
> to nodes in GridDistributedLockRequest#nearXidVer
>_+Proposed solution+_ : On remote nodes instead of thread id of near 
> transaction GridDistributedLockRequest#threadId use its xid 
> GridDistributedLockRequest#nearXidVer.
> Remove usages of near transaction's thread id on remote nodes.



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

[jira] [Commented] (IGNITE-7904) ComputeTaskFuture.get() throws incorrect exception if ComputeTask.result() throws IgniteException

[Stanislav Lukyanov (JIRA)]

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

Stanislav Lukyanov commented on IGNITE-7904:


I don't think this change can cause timeout errors in tests. I've checked the 
IgniteBinaryObjectsComputeGridTestSuite: 
GridMultinodeRedeployPrivateModeSelfTest.testPrivateMode - it passes. I'll 
rerun TC to confirm.

> ComputeTaskFuture.get() throws incorrect exception if ComputeTask.result() 
> throws IgniteException
> -
>
> Key: IGNITE-7904
> URL: https://issues.apache.org/jira/browse/IGNITE-7904
> Project: Ignite
>  Issue Type: Bug
>Reporter: Stanislav Lukyanov
>Assignee: Stanislav Lukyanov
>Priority: Major
> Fix For: 2.5
>
>
> ComputeTask.result() javadoc says: "Throws: IgniteException - If handling a 
> job result caused an error effectively rejecting a failover. This exception 
> will be thrown out of ComputeTaskFuture.get() method."
> However, GridFutureAdapter calls IgniteUtils.cast(Throwable) on the exception 
> before throwing it from get(), and the latter method trims the stack trace to 
> the first occurence of an IgniteCheckedException. Because of that, get() 
> throws not the IgniteException thrown from the ComputeTask.result() but one 
> of its causes.



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

[jira] [Updated] (IGNITE-6856) SQL: invalid security checks during query execution

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6856:

Fix Version/s: (was: 2.5)

> SQL: invalid security checks during query execution
> ---
>
> Key: IGNITE-6856
> URL: https://issues.apache.org/jira/browse/IGNITE-6856
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Priority: Major
>
> Currently security check is performed inside {{IgniteCacheProxy}}. This is 
> wrong place. Instead, we should perform it inside query processor after 
> parsing when all affected caches are known.



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

[jira] [Commented] (IGNITE-7282) .NET: Thin client: Failover

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-7282:
-

[~ptupitsyn], agree on p.2 and p.3, thank you for clarification.
As far as p.1, I would say yes, they could be deprecated.

> .NET: Thin client: Failover
> ---
>
> Key: IGNITE-7282
> URL: https://issues.apache.org/jira/browse/IGNITE-7282
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.5
>
>
> Currently user has to manually connect to some specific Ignite server.
> Implement some kind of automatic failover where Thin Client knows about 
> multiple nodes.



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

[jira] [Commented] (IGNITE-7944) Disconnected client node tries to send JOB_CANCEL message

[Roman Guseinov (JIRA)]

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

Roman Guseinov commented on IGNITE-7944:


[~amashenkov] , according to your comments, I added the following changes:
* set job synchronization using Latch instead of Thread.sleep()
* set test timeout = 2 minutes
* use existing LOCAL_IP_FINDER

"assert ignite instanceof IgniteKernal" wasn't added because some tests use 
mock objects instead of IgniteKernal
(GridTcpCommunicationSpiConcurrentConnectSelfTest for example)

Please take a look.

> Disconnected client node tries to send JOB_CANCEL message
> -
>
> Key: IGNITE-7944
> URL: https://issues.apache.org/jira/browse/IGNITE-7944
> Project: Ignite
>  Issue Type: Bug
>  Components: messaging
>Affects Versions: 1.9, 2.3
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
> Fix For: 2.5
>
> Attachments: Reproducer7944.java
>
>
> In case the network is blocked (socket connections not closed) and failure is 
> detected, tcp-client-disco-msg-worker thread can be stuck in process of 
> TcpClient creating:
> {code:java}
> "tcp-client-disco-msg-worker-#4%wd5prsvtots0016a-tg-QueryFabric%" #494 prio=5 
> os_prio=0 tid=0x7f94c067c800 nid=0x2bdf runnable [0x7f960ecf1000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.Net.poll(Native Method)
> at sun.nio.ch.SocketChannelImpl.poll(SocketChannelImpl.java:954)
> - locked <0x7fa140f520c0> (a java.lang.Object)
> at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:110)
> - locked <0x7fa140f520b0> (a java.lang.Object)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2950)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2681)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2568)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2429)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2393)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1590)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1659)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.cancelChildren(GridTaskWorker.java:1305)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1609)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1581)
> at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.onDisconnected(GridTaskProcessor.java:168)
> at 
> org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:3460)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:601)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2407)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2386)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1714)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> It looks like msg-worker is trying to send JOB_CANCEL message for each job 
> with timeout equals failureDetectionTimeout.
> Reproducer is attached.



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

[jira] [Updated] (IGNITE-8070) .Net: FailureHandler should be added to Ignite configuration

[Andrey Gura (JIRA)]

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

Andrey Gura updated IGNITE-8070:

Fix Version/s: (was: 2.5)

> .Net: FailureHandler should be added to Ignite configuration
> 
>
> Key: IGNITE-8070
> URL: https://issues.apache.org/jira/browse/IGNITE-8070
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Andrey Gura
>Priority: Major
>  Labels: iep-14
>
> {{IgniteConfiguration}} class was extended by new methods: 
> {{setFailureHandler}} and {{getFailureHandler}}. Corresponding changes should 
> be done in ignite .Net 



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

[jira] [Commented] (IGNITE-8110) GridCacheWriteBehindStore.Flusher thread uses the wrong transformation from milliseconds to nanoseconds.

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8110:


Status: In progress. could you set it to PA?

> GridCacheWriteBehindStore.Flusher thread uses the wrong transformation from 
> milliseconds to nanoseconds.
> 
>
> Key: IGNITE-8110
> URL: https://issues.apache.org/jira/browse/IGNITE-8110
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Vyacheslav Koptilin
>Assignee: Anton Kurbanov
>Priority: Minor
>
> The initial value of a cache flushing frequency is defined as follows:
> {code}
> /** Cache flushing frequence in nanos. */
> protected long cacheFlushFreqNanos = cacheFlushFreq * 1000;
> {code}
> where is {{cacheFlushFreq}} is equal to
> {code}
> /** Default flush frequency for write-behind cache store in milliseconds. 
> */
> public static final long DFLT_WRITE_BEHIND_FLUSH_FREQUENCY = 5000;
> {code}



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

[jira] [Comment Edited] (IGNITE-6879) Support Spring 2.0

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii edited comment on IGNITE-6879 at 4/5/18 12:54 PM:
-

I pointed some codestyle issues on Github for {{Spring 2.0 module}} commit. I 
know, you just copied Spring module, but such tickets are the only way to make 
codestyle fixes and minor refactoring in the whole module.


was (Author: somefire):
I know, you just copied Spring module, but such tickets are the only way to 
make codestyle fixes and minor refactoring in the whole module.

> Support Spring 2.0
> --
>
> Key: IGNITE-6879
> URL: https://issues.apache.org/jira/browse/IGNITE-6879
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.3
>Reporter: Alexey Kukushkin
>Assignee: Roman Meerson
>Priority: Major
>
> Ignite-spring and ignite-spring-data now use Spring 1.1 and cannot be rebuilt 
> with Spring 2.0. Trying to change the Spring dependency version to 
> 2.0.0.release results in compile errors like below and requires regression in 
> general. 
> This improvement was created to either migrate from Spring 1.1 to 2.0 or 
> create another set of modules ignite-spring-xxx-2 to have backward 
> compatibility with Spring 1.1.
> [ERROR] 
> /Users/kukushal/Dev/incubator-ignite/modules/spring-data/src/main/java/org/apache/ignite/springdata/repository/IgniteRepository.java:[57,10]
>  name clash: deleteAll(java.lang.Iterable) in 
> org.apache.ignite.springdata.repository.IgniteRepository and 
> deleteAll(java.lang.Iterable) in 
> org.springframework.data.repository.CrudRepository have the same erasure, yet 
> neither overrides the other



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

[jira] [Commented] (IGNITE-6879) Support Spring 2.0

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii commented on IGNITE-6879:


I know, you just copied Spring module, but such tickets are the only way to 
make codestyle fixes and minor refactoring in the whole module.

> Support Spring 2.0
> --
>
> Key: IGNITE-6879
> URL: https://issues.apache.org/jira/browse/IGNITE-6879
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.3
>Reporter: Alexey Kukushkin
>Assignee: Roman Meerson
>Priority: Major
>
> Ignite-spring and ignite-spring-data now use Spring 1.1 and cannot be rebuilt 
> with Spring 2.0. Trying to change the Spring dependency version to 
> 2.0.0.release results in compile errors like below and requires regression in 
> general. 
> This improvement was created to either migrate from Spring 1.1 to 2.0 or 
> create another set of modules ignite-spring-xxx-2 to have backward 
> compatibility with Spring 1.1.
> [ERROR] 
> /Users/kukushal/Dev/incubator-ignite/modules/spring-data/src/main/java/org/apache/ignite/springdata/repository/IgniteRepository.java:[57,10]
>  name clash: deleteAll(java.lang.Iterable) in 
> org.apache.ignite.springdata.repository.IgniteRepository and 
> deleteAll(java.lang.Iterable) in 
> org.springframework.data.repository.CrudRepository have the same erasure, yet 
> neither overrides the other



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

[jira] [Created] (IGNITE-8148) JDBC thin driver: use semicolon as parameter's delimiter

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-8148:
---

 Summary: JDBC thin driver: use semicolon as parameter's delimiter
 Key: IGNITE-8148
 URL: https://issues.apache.org/jira/browse/IGNITE-8148
 Project: Ignite
  Issue Type: Task
  Components: jdbc
Affects Versions: 2.4
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.5


Currently we split JDBC parameters using ampersand. This causes a number of 
usability concerns with escaping, especially when it is needed to pass 
connection URL to command line (e.g. sqlline in bash or PowerShell). A number 
of other vendors use either parentheses or semicolon as a delimiter. I propose 
to choose semicolon. 

Also it is necessary to make sure that old-style connection URLs work fine 
after this change.



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

[jira] [Assigned] (IGNITE-8146) IgniteUtils classLoaderUrls() JDK9 bug

[Andrey Gura (JIRA)]

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

Andrey Gura reassigned IGNITE-8146:
---

Assignee: Andrey Gura

> IgniteUtils classLoaderUrls() JDK9 bug
> --
>
> Key: IGNITE-8146
> URL: https://issues.apache.org/jira/browse/IGNITE-8146
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Sujit Kumar Mahapatra
>Assignee: Andrey Gura
>Priority: Trivial
>  Labels: jdk9
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Reporting a probable miss that breaks JDK9 compatibility.
> As part of [this 
> commit|https://github.com/apache/ignite/commit/ee2a6f7c3f2e3c9bd8dc61c8dbdf171e933d9481#diff-309ab4ef2fc61d6b2570d390acfb9bd6]
>   in 
> [ignite|https://github.com/apache/ignite/tree/f1a853ded8e835ce8c98c029cce7d5d17fbd3f52]/modules/core/src/main/java/org/apache/ignite/internal/util/*IgniteUtils.java,*
>  below lines will throw *ClassCastException* in JDK9 during runtime.
> _return ((URLClassLoader)urlClsLdrField.get(clsLdr)).getURLs();_
>  
> Here, _urlClsLdrField.get(clsLdr)_ return an object of type 
> "___java.base/jdk.internal.loader.URLClassPath_" which can't be cast to 
> "_URLClassLoader"._
>  
> The fix seems to be to introduce another reflection call to invoke _getURLs_  
> method of the internal _URLClassPath_ class.



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

[jira] [Assigned] (IGNITE-8147) SQL: NPE during key/value pair validation

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-8147:
---

Assignee: Vladimir Ozerov

> SQL: NPE during key/value pair validation
> -
>
> Key: IGNITE-8147
> URL: https://issues.apache.org/jira/browse/IGNITE-8147
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.5
>
>
> NPE is possible during DELETE command. Exact use case is unknown, but from 
> code it is obvious that it is possible when entry processor return's {{null}}.
> {code}
> 2018-03-28 15:50:05,748 WARN  [engine 127.0.0.1] progress_monitor_2 unknown
> unknown {ProgressMonitorImpl.java:112} - Scan
> [ec7af5e8-a773-40fd-9722-f81103de73dc] is unable to process!
> javax.cache.CacheException: Failed to process key '247002'
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:618)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:557)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:382)
> at
> com.company.core.dao.ignite.IgniteFragmentDao.delete(IgniteFragmentDao.java:143)
> at
> com.company.core.dao.ignite.IgniteFragmentDao$$FastClassBySpringCGLIB$$c520aa1b.invoke()
> at 
> org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
> at
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:720)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
> at
> org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:136)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:655)
> at
> com.company.core.dao.ignite.IgniteFragmentDao$$EnhancerBySpringCGLIB$$ce60f71c.delete()
> at
> com.company.core.core.service.impl.InternalScanServiceImpl.purgeScanFromGrid(InternalScanServiceImpl.java:455)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:302)
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
> at com.sun.proxy.$Proxy417.purgeScanFromGrid(Unknown Source)
> at 
> com.company.core.core.async.tasks.PurgeTask.process(PurgeTask.java:85)
> at sun.reflect.GeneratedMethodAccessor197.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:302)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:190)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
> at
> org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:99)
> at
> org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:281)
> at
> org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:208)
> at com.sun.proxy.$Proxy418.process(Unknown Source)
> at
> com.company.core.core.async.impl.ProgressMonitorImpl._runTasks(ProgressMonitorImpl.java:128)
> at
> com.company.core.core.async.impl.ProgressMonitorImpl.lambda$null$0(ProgressMonitorImpl.java:98)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at
> 

[jira] [Commented] (IGNITE-8139) Need to have better control on the size of SQL on heap cache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8139:


Github user devozerov closed the pull request at:

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


> Need to have better control on the size of SQL on heap cache
> 
>
> Key: IGNITE-8139
> URL: https://issues.apache.org/jira/browse/IGNITE-8139
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.4
>Reporter: Valentin Kulichenko
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.5
>
>
> Currently, if SQL on heap cache is enabled, there is no clear way to control 
> the size of this cache. Looks like its evictions basically depend on 
> evictions in off-heap, so it's really to get OOME. Not very usable.
> The easiest improvement would be to have a knob (configuration parameter or 
> system property) that would control the size of underlying concurrent map 
> that stores cached rows.



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

[jira] [Commented] (IGNITE-7904) ComputeTaskFuture.get() throws incorrect exception if ComputeTask.result() throws IgniteException

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7904:


Test failure probably introduced here,Test failures count is low < 3, 
probably new test introduced 
 Compute (Grid) [ tests 1 ]  
   IgniteBinaryObjectsComputeGridTestSuite: 
GridMultinodeRedeployPrivateModeSelfTest.testPrivateMode (master fail rate 
0,0%) 

I'm not sure about failures
   Cache (Restarts) [1] [ tests 0 TIMEOUT , Exit Code ]  
 
GridCacheReplicatedNodeRestartSelfTest.testRestartWithPutEightNodesTwoBackups 
(last started) 
&
   Java Client [ tests 0 TIMEOUT , Out Of Memory Error , Exit Code ] 
 IgniteCache150ClientsTest.test150Clients (last started)

Please check 2 last failures and fix introduced failure

> ComputeTaskFuture.get() throws incorrect exception if ComputeTask.result() 
> throws IgniteException
> -
>
> Key: IGNITE-7904
> URL: https://issues.apache.org/jira/browse/IGNITE-7904
> Project: Ignite
>  Issue Type: Bug
>Reporter: Stanislav Lukyanov
>Assignee: Stanislav Lukyanov
>Priority: Major
> Fix For: 2.5
>
>
> ComputeTask.result() javadoc says: "Throws: IgniteException - If handling a 
> job result caused an error effectively rejecting a failover. This exception 
> will be thrown out of ComputeTaskFuture.get() method."
> However, GridFutureAdapter calls IgniteUtils.cast(Throwable) on the exception 
> before throwing it from get(), and the latter method trims the stack trace to 
> the first occurence of an IgniteCheckedException. Because of that, get() 
> throws not the IgniteException thrown from the ComputeTask.result() but one 
> of its causes.



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

[jira] [Resolved] (IGNITE-8147) SQL: NPE during key/value pair validation

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-8147.
-
Resolution: Fixed

> SQL: NPE during key/value pair validation
> -
>
> Key: IGNITE-8147
> URL: https://issues.apache.org/jira/browse/IGNITE-8147
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.4
>Reporter: Vladimir Ozerov
>Priority: Major
> Fix For: 2.5
>
>
> NPE is possible during DELETE command. Exact use case is unknown, but from 
> code it is obvious that it is possible when entry processor return's {{null}}.
> {code}
> 2018-03-28 15:50:05,748 WARN  [engine 127.0.0.1] progress_monitor_2 unknown
> unknown {ProgressMonitorImpl.java:112} - Scan
> [ec7af5e8-a773-40fd-9722-f81103de73dc] is unable to process!
> javax.cache.CacheException: Failed to process key '247002'
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:618)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:557)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:382)
> at
> com.company.core.dao.ignite.IgniteFragmentDao.delete(IgniteFragmentDao.java:143)
> at
> com.company.core.dao.ignite.IgniteFragmentDao$$FastClassBySpringCGLIB$$c520aa1b.invoke()
> at 
> org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
> at
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:720)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
> at
> org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:136)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:655)
> at
> com.company.core.dao.ignite.IgniteFragmentDao$$EnhancerBySpringCGLIB$$ce60f71c.delete()
> at
> com.company.core.core.service.impl.InternalScanServiceImpl.purgeScanFromGrid(InternalScanServiceImpl.java:455)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:302)
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
> at com.sun.proxy.$Proxy417.purgeScanFromGrid(Unknown Source)
> at 
> com.company.core.core.async.tasks.PurgeTask.process(PurgeTask.java:85)
> at sun.reflect.GeneratedMethodAccessor197.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:302)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:190)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
> at
> org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:99)
> at
> org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:281)
> at
> org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:208)
> at com.sun.proxy.$Proxy418.process(Unknown Source)
> at
> com.company.core.core.async.impl.ProgressMonitorImpl._runTasks(ProgressMonitorImpl.java:128)
> at
> com.company.core.core.async.impl.ProgressMonitorImpl.lambda$null$0(ProgressMonitorImpl.java:98)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at
> 

[jira] [Commented] (IGNITE-8101) Ability to terminate system workers by JMX for test purposes

[Dmitriy Sorokin (JIRA)]

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

Dmitriy Sorokin commented on IGNITE-8101:
-

[~agura], review my patch, please!

> Ability to terminate system workers by JMX for test purposes
> 
>
> Key: IGNITE-8101
> URL: https://issues.apache.org/jira/browse/IGNITE-8101
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
>  Labels: iep-14
> Fix For: 2.5
>
>




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

[jira] [Created] (IGNITE-8147) SQL: NPE during key/value pair validation

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-8147:
---

 Summary: SQL: NPE during key/value pair validation
 Key: IGNITE-8147
 URL: https://issues.apache.org/jira/browse/IGNITE-8147
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.4
Reporter: Vladimir Ozerov
 Fix For: 2.5


NPE is possible during DELETE command. Exact use case is unknown, but from code 
it is obvious that it is possible when entry processor return's {{null}}.

{code}
2018-03-28 15:50:05,748 WARN  [engine 127.0.0.1] progress_monitor_2 unknown
unknown {ProgressMonitorImpl.java:112} - Scan
[ec7af5e8-a773-40fd-9722-f81103de73dc] is unable to process!
javax.cache.CacheException: Failed to process key '247002'
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:618)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:557)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:382)
at
com.company.core.dao.ignite.IgniteFragmentDao.delete(IgniteFragmentDao.java:143)
at
com.company.core.dao.ignite.IgniteFragmentDao$$FastClassBySpringCGLIB$$c520aa1b.invoke()
at 
org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
at
org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:720)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
at
org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:136)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at
org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:655)
at
com.company.core.dao.ignite.IgniteFragmentDao$$EnhancerBySpringCGLIB$$ce60f71c.delete()
at
com.company.core.core.service.impl.InternalScanServiceImpl.purgeScanFromGrid(InternalScanServiceImpl.java:455)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:302)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
at com.sun.proxy.$Proxy417.purgeScanFromGrid(Unknown Source)
at 
com.company.core.core.async.tasks.PurgeTask.process(PurgeTask.java:85)
at sun.reflect.GeneratedMethodAccessor197.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:302)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:190)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
at
org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:99)
at
org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:281)
at
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:208)
at com.sun.proxy.$Proxy418.process(Unknown Source)
at
com.company.core.core.async.impl.ProgressMonitorImpl._runTasks(ProgressMonitorImpl.java:128)
at
com.company.core.core.async.impl.ProgressMonitorImpl.lambda$null$0(ProgressMonitorImpl.java:98)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at
com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:108)
at
com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:41)
at
com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:77)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at

[jira] [Commented] (IGNITE-7904) ComputeTaskFuture.get() throws incorrect exception if ComputeTask.result() throws IgniteException

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7904:


[~agura], [~agoncharuk], could both of you please take a look? I'm not able to 
sign-off such change because of possible impact.

> ComputeTaskFuture.get() throws incorrect exception if ComputeTask.result() 
> throws IgniteException
> -
>
> Key: IGNITE-7904
> URL: https://issues.apache.org/jira/browse/IGNITE-7904
> Project: Ignite
>  Issue Type: Bug
>Reporter: Stanislav Lukyanov
>Assignee: Stanislav Lukyanov
>Priority: Major
> Fix For: 2.5
>
>
> ComputeTask.result() javadoc says: "Throws: IgniteException - If handling a 
> job result caused an error effectively rejecting a failover. This exception 
> will be thrown out of ComputeTaskFuture.get() method."
> However, GridFutureAdapter calls IgniteUtils.cast(Throwable) on the exception 
> before throwing it from get(), and the latter method trims the stack trace to 
> the first occurence of an IgniteCheckedException. Because of that, get() 
> throws not the IgniteException thrown from the ComputeTask.result() but one 
> of its causes.



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

[jira] [Commented] (IGNITE-8110) GridCacheWriteBehindStore.Flusher thread uses the wrong transformation from milliseconds to nanoseconds.

[Vyacheslav Koptilin (JIRA)]

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

Vyacheslav Koptilin commented on IGNITE-8110:
-

Looks good to me.

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

> GridCacheWriteBehindStore.Flusher thread uses the wrong transformation from 
> milliseconds to nanoseconds.
> 
>
> Key: IGNITE-8110
> URL: https://issues.apache.org/jira/browse/IGNITE-8110
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Vyacheslav Koptilin
>Assignee: Anton Kurbanov
>Priority: Minor
>
> The initial value of a cache flushing frequency is defined as follows:
> {code}
> /** Cache flushing frequence in nanos. */
> protected long cacheFlushFreqNanos = cacheFlushFreq * 1000;
> {code}
> where is {{cacheFlushFreq}} is equal to
> {code}
> /** Default flush frequency for write-behind cache store in milliseconds. 
> */
> public static final long DFLT_WRITE_BEHIND_FLUSH_FREQUENCY = 5000;
> {code}



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

[jira] [Commented] (IGNITE-7904) ComputeTaskFuture.get() throws incorrect exception if ComputeTask.result() throws IgniteException

[Stanislav Lukyanov (JIRA)]

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

Stanislav Lukyanov commented on IGNITE-7904:


Dev-list thread on this issue: 
http://apache-ignite-developers.2346864.n4.nabble.com/Trimming-exceptions-in-IgniteUtils-cast-td27879.html

> ComputeTaskFuture.get() throws incorrect exception if ComputeTask.result() 
> throws IgniteException
> -
>
> Key: IGNITE-7904
> URL: https://issues.apache.org/jira/browse/IGNITE-7904
> Project: Ignite
>  Issue Type: Bug
>Reporter: Stanislav Lukyanov
>Assignee: Stanislav Lukyanov
>Priority: Major
> Fix For: 2.5
>
>
> ComputeTask.result() javadoc says: "Throws: IgniteException - If handling a 
> job result caused an error effectively rejecting a failover. This exception 
> will be thrown out of ComputeTaskFuture.get() method."
> However, GridFutureAdapter calls IgniteUtils.cast(Throwable) on the exception 
> before throwing it from get(), and the latter method trims the stack trace to 
> the first occurence of an IgniteCheckedException. Because of that, get() 
> throws not the IgniteException thrown from the ComputeTask.result() but one 
> of its causes.



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

[jira] [Updated] (IGNITE-8101) Ability to terminate system workers by JMX for test purposes

[Dmitriy Sorokin (JIRA)]

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

Dmitriy Sorokin updated IGNITE-8101:

Description: (was: [0] disco-event-worker [0] 
 [1] grid-timeout-worker [1] 
 [2] partition-exchanger [2])

> Ability to terminate system workers by JMX for test purposes
> 
>
> Key: IGNITE-8101
> URL: https://issues.apache.org/jira/browse/IGNITE-8101
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
>  Labels: iep-14
> Fix For: 2.5
>
>




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

[jira] [Commented] (IGNITE-8110) GridCacheWriteBehindStore.Flusher thread uses the wrong transformation from milliseconds to nanoseconds.

[Vyacheslav Koptilin (JIRA)]

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

Vyacheslav Koptilin commented on IGNITE-8110:
-

TeamCity: 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F3742%2Fhead

> GridCacheWriteBehindStore.Flusher thread uses the wrong transformation from 
> milliseconds to nanoseconds.
> 
>
> Key: IGNITE-8110
> URL: https://issues.apache.org/jira/browse/IGNITE-8110
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Vyacheslav Koptilin
>Assignee: Anton Kurbanov
>Priority: Minor
>
> The initial value of a cache flushing frequency is defined as follows:
> {code}
> /** Cache flushing frequence in nanos. */
> protected long cacheFlushFreqNanos = cacheFlushFreq * 1000;
> {code}
> where is {{cacheFlushFreq}} is equal to
> {code}
> /** Default flush frequency for write-behind cache store in milliseconds. 
> */
> public static final long DFLT_WRITE_BEHIND_FLUSH_FREQUENCY = 5000;
> {code}



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

[jira] [Commented] (IGNITE-8101) Ability to terminate system workers by JMX for test purposes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8101:


GitHub user x-kreator opened a pull request:

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

IGNITE-8101: Ability to terminate system workers by JMX for test purp…

…oses.

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

$ git pull https://github.com/x-kreator/ignite ignite-8101

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

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


commit 0a749fae51398184fd9964961880af2ab0ecad73
Author: Dmitriy Sorokin 
Date:   2018-04-05T04:42:54Z

IGNITE-8101: Ability to terminate system workers by JMX for test purposes.




> Ability to terminate system workers by JMX for test purposes
> 
>
> Key: IGNITE-8101
> URL: https://issues.apache.org/jira/browse/IGNITE-8101
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
>  Labels: iep-14
> Fix For: 2.5
>
>
> [0] disco-event-worker [0] 
>  [1] grid-timeout-worker [1] 
>  [2] partition-exchanger [2]



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

[jira] [Commented] (IGNITE-5553) Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error

[Pavel Pereslegin (JIRA)]

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

Pavel Pereslegin commented on IGNITE-5553:
--

Hello [~ilantukh],
I updated this patch and test results, could you look again, please?

> Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error
> -
>
> Key: IGNITE-5553
> URL: https://issues.apache.org/jira/browse/IGNITE-5553
> Project: Ignite
>  Issue Type: Bug
>  Components: data structures, persistence
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test, test-fail
> Fix For: 2.5
>
>
> h2. Notes-4435
> When IgniteSet is restored from persistence, size of set is always 0, [link 
> to test 
> history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-7043871603266099589=testDetails].
> h2. Detailed description
> Unlike *IgniteQueue* which uses separate cache key to store its size 
> *IgniteSet* stores it in a field of some class.
> Test from the link above shows very clearly that after restoring memory state 
> from PDS all set values are restored correctly but size is lost.
> h2. Proposed solution
> One possible solution might be to do the same thing as *IgniteQueue* does: 
> size of *IgniteSet* must be stored is cache instead of volatile in-memory 
> fields of random classes.



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

[jira] [Commented] (IGNITE-5978) [Test Failed] IgnitePartitionedCountDownLatchSelfTest.testLatchMultinode1

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5978:


Github user asfgit closed the pull request at:

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


> [Test Failed] IgnitePartitionedCountDownLatchSelfTest.testLatchMultinode1
> -
>
> Key: IGNITE-5978
> URL: https://issues.apache.org/jira/browse/IGNITE-5978
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Vitaliy Biryukov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Fails locally.
> Example of failing - 
> http://ci.ignite.apache.org/viewLog.html?buildId=759891=buildResultsDiv=Ignite20Tests_IgniteDataStrucutures#testNameId677264269171099154.



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

[jira] [Updated] (IGNITE-8135) Missing SQL-DDL Authorization

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-8135:

Fix Version/s: 2.5

> Missing SQL-DDL Authorization
> -
>
> Key: IGNITE-8135
> URL: https://issues.apache.org/jira/browse/IGNITE-8135
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.5
>Reporter: Alexey Kukushkin
>Priority: Major
> Fix For: 2.5
>
>
> Ignite has infrastructure to support 3-rd party security plugins. To support 
> authorization, Ignite has security checks spread all over the code delegating 
> actual authorization to a 3rd party security plugins if configured.
> In addition to existing checks, Ignite 2.5 will authorise "create" and 
> "destroy" cache operations.
> The problem is authorization is not implemented for SQL at all - even if 
> authorization is enabled, it is currently possible to run any SQL to 
> create/drop/alter caches and read/modify/remove the cache data thus bypassing 
> security. The problem exists for both DDL (create/drop/alter table) and DML 
> (select/merge/insert/delete).
> This ticket addresses DDL only: DML will be addressed by a different ticket.
> The problem must be fixed for all clients: Ignite client and server nodes, 
> Java and .NET thin clients, ODBC and JDBC, REST.



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

[jira] [Updated] (IGNITE-7904) ComputeTaskFuture.get() throws incorrect exception if ComputeTask.result() throws IgniteException

[Stanislav Lukyanov (JIRA)]

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

Stanislav Lukyanov updated IGNITE-7904:
---
Fix Version/s: 2.5

> ComputeTaskFuture.get() throws incorrect exception if ComputeTask.result() 
> throws IgniteException
> -
>
> Key: IGNITE-7904
> URL: https://issues.apache.org/jira/browse/IGNITE-7904
> Project: Ignite
>  Issue Type: Bug
>Reporter: Stanislav Lukyanov
>Assignee: Stanislav Lukyanov
>Priority: Major
> Fix For: 2.5
>
>
> ComputeTask.result() javadoc says: "Throws: IgniteException - If handling a 
> job result caused an error effectively rejecting a failover. This exception 
> will be thrown out of ComputeTaskFuture.get() method."
> However, GridFutureAdapter calls IgniteUtils.cast(Throwable) on the exception 
> before throwing it from get(), and the latter method trims the stack trace to 
> the first occurence of an IgniteCheckedException. Because of that, get() 
> throws not the IgniteException thrown from the ComputeTask.result() but one 
> of its causes.



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

[jira] [Commented] (IGNITE-5978) [Test Failed] IgnitePartitionedCountDownLatchSelfTest.testLatchMultinode1

[Ivan Rakov (JIRA)]

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

Ivan Rakov commented on IGNITE-5978:


Looks good to me.

> [Test Failed] IgnitePartitionedCountDownLatchSelfTest.testLatchMultinode1
> -
>
> Key: IGNITE-5978
> URL: https://issues.apache.org/jira/browse/IGNITE-5978
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Vitaliy Biryukov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Fails locally.
> Example of failing - 
> http://ci.ignite.apache.org/viewLog.html?buildId=759891=buildResultsDiv=Ignite20Tests_IgniteDataStrucutures#testNameId677264269171099154.



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

[jira] [Commented] (IGNITE-7499) DataRegionMetricsImpl#getPageSize returns ZERO for system data regions

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-7499:
--

Unlike regular data regions, system data region configuration is hardcoded, and 
metrics are disabled there. [~kuaw26], do we have real reasons to query metrics 
for system data region? Depending on the answer to this question we can choose 
the way of fixing the issue.

> DataRegionMetricsImpl#getPageSize returns ZERO for system data regions
> --
>
> Key: IGNITE-7499
> URL: https://issues.apache.org/jira/browse/IGNITE-7499
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Alexey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> Working on IGNITE-7492 I found that DataRegionMetricsImpl#getPageSize returns 
> ZERO for system data regions.
> Meanwhile there is also 
> org.apache.ignite.internal.pagemem.PageMemory#systemPageSize method.
> That looks a bit strange, why we need PageSize and SystemPageSize ?
>  



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

[jira] [Updated] (IGNITE-8138) Incorrect uptime in Ignite metrics for long running server node (1+ days)

[Max Shonichev (JIRA)]

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

Max Shonichev updated IGNITE-8138:
--
Summary: Incorrect uptime in Ignite metrics for long running server node 
(1+ days)  (was: Incorrect uptime in GG metrics for long running server node 
(1+ days))

> Incorrect uptime in Ignite metrics for long running server node (1+ days)
> -
>
> Key: IGNITE-8138
> URL: https://issues.apache.org/jira/browse/IGNITE-8138
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.1, 2.4
>Reporter: Max Shonichev
>Priority: Major
> Fix For: 2.5
>
>
> Ignite prints a metrics to the log with uptime, formatted as 'XX:YY:ZZ:TTT'.
> It looks, like XX corresponds to hours, YY to minutes, ZZ to seconds, however 
> if we filter uptime metric from a long running server (few days), we would 
> see that :
> {noformat}
>  ^-- Node [id=684d2761, name=null, uptime=00:01:00:009]
>  ^-- Node [id=684d2761, name=null, uptime=00:02:00:009]
>  ^-- Node [id=684d2761, name=null, uptime=00:03:00:009]
>  ^-- Node [id=684d2761, name=null, uptime=00:04:00:021]
> ...
>  ^-- Node [id=684d2761, name=null, uptime=23:58:08:391]
>  ^-- Node [id=684d2761, name=null, uptime=23:59:08:393]
>  ^-- Node [id=684d2761, name=null, uptime=24:00:08:395]
>  ^-- Node [id=684d2761, name=null, uptime=24:01:08:406]
> ...
>  ^-- Node [id=684d2761, name=null, uptime=59:59:23:542]
>  ^-- Node [id=684d2761, name=null, uptime=00:00:23:554]
> ...
> {noformat}
> BUG:
> 1. hours do not rollover at 23:59:59
> 2. there's no simple means for user to get uptime days, because hours do 
> actually rollover after 59:59:59
> what is expected: 
>  1. add a day counter, init with 0
>  2. make hours correctly rollover after full day (24hrs) run
> {noformat}
>  ^-- Node [id=684d2761, name=null, uptime=0:00:01:00:009]
> ...
>  ^-- Node [id=684d2761, name=null, uptime=0:23:59:00:009]
>  ^-- Node [id=684d2761, name=null, uptime=1:00:00:00:009]
> ...
> {noformat}



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

[jira] [Updated] (IGNITE-7680) Ignite PDS 1 (Direct IO): failed test IgnitePdsCheckpointSimulationWithRealCpDisabledTest.testDirtyFlag()

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-7680:
---
Issue Type: Test  (was: Bug)

> Ignite PDS 1 (Direct IO): failed test 
> IgnitePdsCheckpointSimulationWithRealCpDisabledTest.testDirtyFlag()
> -
>
> Key: IGNITE-7680
> URL: https://issues.apache.org/jira/browse/IGNITE-7680
> Project: Ignite
>  Issue Type: Test
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
>  Ignite PDS 1 (Direct IO) [ tests failed ]   
>   org.apache.ignite.testsuites.IgnitePdsNativeIoTestSuite: 
> org.apache.ignite.internal.processors.cache.persistence.db.file.IgnitePdsCheckpointSimulationWithRealCpDisabledTest.testDirtyFlag
>  (fail rate 100%) 
> {noformat}
> class org.apache.ignite.IgniteException: Failed to begin checkpoint (it is 
> already in progress).
>   at 
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.beginCheckpoint(PageMemoryImpl.java:961)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.db.file.IgnitePdsCheckpointSimulationWithRealCpDisabledTest.testDirtyFlag(IgnitePdsCheckpointSimulationWithRealCpDisabledTest.java:564)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2001)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}



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

[jira] [Updated] (IGNITE-7379) .NET: CacheConfiguration.IsSqlOnheapCacheEnabled

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7379:

Description: 
Add {{CacheConfiguration.IsSqlOnheapCacheEnabled}}, see IGNITE-7173.
Also it is needed to add {{CacheConfiguration.SqlOnheapCacheMaxSize}}.

  was:Add {{CacheConfiguration.IsSqlOnheapCacheEnabled}}, see IGNITE-7173


> .NET: CacheConfiguration.IsSqlOnheapCacheEnabled
> 
>
> Key: IGNITE-7379
> URL: https://issues.apache.org/jira/browse/IGNITE-7379
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Priority: Trivial
>  Labels: .NET
>
> Add {{CacheConfiguration.IsSqlOnheapCacheEnabled}}, see IGNITE-7173.
> Also it is needed to add {{CacheConfiguration.SqlOnheapCacheMaxSize}}.



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

[jira] [Commented] (IGNITE-7743) JDBC driver allows to connect to non existent schema

[Pavel Kuznetsov (JIRA)]

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

Pavel Kuznetsov commented on IGNITE-7743:
-

[~tledkov-gridgain] , Could you please do the final review?

> JDBC driver allows to connect to non existent schema
> 
>
> Key: IGNITE-7743
> URL: https://issues.apache.org/jira/browse/IGNITE-7743
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Pavel Kuznetsov
>Priority: Major
>  Labels: usability
> Fix For: 2.5
>
>
> Currently, if one creates a cache without DDL (via {{QueryEntity}} or 
> {{indexedTypes}}), separate schema for this cache is created. Schema name is 
> case sensitive, so to connect to it with JDBC driver, it's required to 
> provide the name in quotes. Here is how it looks like in SqlLine:
> {noformat}
> ./bin/sqlline.sh -u jdbc:ignite:thin://127.0.0.1/\"CacheQueryExamplePersons\"
> {noformat}
> However, if name is provided without quotes, driver still connects, but then 
> fails with a very unclear exception when a query is executed:
> {noformat}
> ./bin/sqlline.sh -u 
> jdbc:ignite:thin://127.0.0.1/CacheQueryExamplePersons{noformat}
> This is a huge usability issue. We should disallow connections to schema that 
> does not exist, throw exception in this case. Exception should provide proper 
> explanation how to connect properly.



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

[jira] [Commented] (IGNITE-7743) JDBC driver allows to connect to non existent schema

[Pavel Kuznetsov (JIRA)]

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

Pavel Kuznetsov commented on IGNITE-7743:
-

Decided to keep code SqlStateCode.CONNECTION_REJECTED if user connects with 
incorrect schema

Have run compatibility tests, result is OK.

> JDBC driver allows to connect to non existent schema
> 
>
> Key: IGNITE-7743
> URL: https://issues.apache.org/jira/browse/IGNITE-7743
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Pavel Kuznetsov
>Priority: Major
>  Labels: usability
> Fix For: 2.5
>
>
> Currently, if one creates a cache without DDL (via {{QueryEntity}} or 
> {{indexedTypes}}), separate schema for this cache is created. Schema name is 
> case sensitive, so to connect to it with JDBC driver, it's required to 
> provide the name in quotes. Here is how it looks like in SqlLine:
> {noformat}
> ./bin/sqlline.sh -u jdbc:ignite:thin://127.0.0.1/\"CacheQueryExamplePersons\"
> {noformat}
> However, if name is provided without quotes, driver still connects, but then 
> fails with a very unclear exception when a query is executed:
> {noformat}
> ./bin/sqlline.sh -u 
> jdbc:ignite:thin://127.0.0.1/CacheQueryExamplePersons{noformat}
> This is a huge usability issue. We should disallow connections to schema that 
> does not exist, throw exception in this case. Exception should provide proper 
> explanation how to connect properly.



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

[jira] [Comment Edited] (IGNITE-7743) JDBC driver allows to connect to non existent schema

[Pavel Kuznetsov (JIRA)]

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

Pavel Kuznetsov edited comment on IGNITE-7743 at 4/5/18 11:44 AM:
--

One thing left to do is set correct jdbc fail code in thin driver


was (Author: pkouznet):
I thing left to do is set correct jdbc fail code in thin driver

> JDBC driver allows to connect to non existent schema
> 
>
> Key: IGNITE-7743
> URL: https://issues.apache.org/jira/browse/IGNITE-7743
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Pavel Kuznetsov
>Priority: Major
>  Labels: usability
> Fix For: 2.5
>
>
> Currently, if one creates a cache without DDL (via {{QueryEntity}} or 
> {{indexedTypes}}), separate schema for this cache is created. Schema name is 
> case sensitive, so to connect to it with JDBC driver, it's required to 
> provide the name in quotes. Here is how it looks like in SqlLine:
> {noformat}
> ./bin/sqlline.sh -u jdbc:ignite:thin://127.0.0.1/\"CacheQueryExamplePersons\"
> {noformat}
> However, if name is provided without quotes, driver still connects, but then 
> fails with a very unclear exception when a query is executed:
> {noformat}
> ./bin/sqlline.sh -u 
> jdbc:ignite:thin://127.0.0.1/CacheQueryExamplePersons{noformat}
> This is a huge usability issue. We should disallow connections to schema that 
> does not exist, throw exception in this case. Exception should provide proper 
> explanation how to connect properly.



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

[jira] [Commented] (IGNITE-8049) Limit the number of operation cycles in B+Tree

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev commented on IGNITE-8049:
---

PR - https://github.com/apache/ignite/pull/3740

> Limit the number of operation cycles in B+Tree
> --
>
> Key: IGNITE-8049
> URL: https://issues.apache.org/jira/browse/IGNITE-8049
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Alexey Goncharuk
>Assignee: Alexey Stelmak
>Priority: Major
> Fix For: 2.5
>
>
> When a tree is corrupted, a B+Tree operation may result in an infinite loop. 
> We should limit the number of retries and fail if this limit is exceeded.



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

[jira] [Assigned] (IGNITE-8142) Web Console: Fix change detection logic on configuration.

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-8142:


Resolution: Fixed
  Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Looks good now. Merged to master.

[~pkonstantinov], please do a smoke test of "Unsaved changes confirmation".

> Web Console: Fix change detection logic on configuration.
> -
>
> Key: IGNITE-8142
> URL: https://issues.apache.org/jira/browse/IGNITE-8142
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
> Attachments: ignite-8142.png
>
>
> How to reproduce:
>  # Input value in some EMPTY input.
>  # Delete content.
>  # Click on Profile link.
>  # You will see question about unsaved changes (see image attached).



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