[jira] [Resolved] (IGNITE-7907) Revisit and update the DBeaver documentations

[Akmal Chaudhri (JIRA)]

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

Akmal Chaudhri resolved IGNITE-7907.

Resolution: Fixed

Documentation updated.

> Revisit and update the DBeaver documentations
> -
>
> Key: IGNITE-7907
> URL: https://issues.apache.org/jira/browse/IGNITE-7907
> Project: Ignite
>  Issue Type: New Feature
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Akmal Chaudhri
>Priority: Blocker
> Fix For: 2.5
>
>
> Seems that our documentation is outdated:
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-with-dBeaver-td20368.html#a20376
> Need to go from the beginning and update the existing parts.



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

[jira] [Commented] (IGNITE-7909) Java code examples are needed for Spark Data Frames.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7909:


GitHub user VeryFatBoy opened a pull request:

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

IGNITE-7909 Java code examples are needed for Spark Data Frames.

New source files and test file for Java code examples.

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

$ git pull https://github.com/VeryFatBoy/ignite master

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

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


commit 3708d74c6cb035700199d54262509975604cf369
Author: Akmal Chaudhri 
Date:   2018-04-20T04:57:53Z

IGNITE-7909 Java code examples are needed for Spark Data Frames.

New source files and test file for Java code examples.




> Java code examples are needed for Spark Data Frames.
> 
>
> Key: IGNITE-7909
> URL: https://issues.apache.org/jira/browse/IGNITE-7909
> Project: Ignite
>  Issue Type: Improvement
>  Components: spark
>Affects Versions: 2.5
>Reporter: Akmal Chaudhri
>Assignee: Akmal Chaudhri
>Priority: Major
>  Labels: spark
> Fix For: 2.5
>
> Attachments: JavaIgniteCatalogExample.java, 
> JavaIgniteDataFrameExample.java, JavaIgniteDataFrameWriteExample.java
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Existing Scala code examples have been developed to illustrate Ignite support 
> for Spark Data Frames. But Java code examples are also required. Some Java 
> code has already been developed but requires further testing.



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

[jira] [Commented] (IGNITE-7909) Java code examples are needed for Spark Data Frames.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7909:


Github user VeryFatBoy closed the pull request at:

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


> Java code examples are needed for Spark Data Frames.
> 
>
> Key: IGNITE-7909
> URL: https://issues.apache.org/jira/browse/IGNITE-7909
> Project: Ignite
>  Issue Type: Improvement
>  Components: spark
>Affects Versions: 2.5
>Reporter: Akmal Chaudhri
>Assignee: Akmal Chaudhri
>Priority: Major
>  Labels: spark
> Fix For: 2.5
>
> Attachments: JavaIgniteCatalogExample.java, 
> JavaIgniteDataFrameExample.java, JavaIgniteDataFrameWriteExample.java
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Existing Scala code examples have been developed to illustrate Ignite support 
> for Spark Data Frames. But Java code examples are also required. Some Java 
> code has already been developed but requires further testing.



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

[jira] [Commented] (IGNITE-7909) Java code examples are needed for Spark Data Frames.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7909:


Github user VeryFatBoy closed the pull request at:

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


> Java code examples are needed for Spark Data Frames.
> 
>
> Key: IGNITE-7909
> URL: https://issues.apache.org/jira/browse/IGNITE-7909
> Project: Ignite
>  Issue Type: Improvement
>  Components: spark
>Affects Versions: 2.5
>Reporter: Akmal Chaudhri
>Assignee: Akmal Chaudhri
>Priority: Major
>  Labels: spark
> Fix For: 2.5
>
> Attachments: JavaIgniteCatalogExample.java, 
> JavaIgniteDataFrameExample.java, JavaIgniteDataFrameWriteExample.java
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Existing Scala code examples have been developed to illustrate Ignite support 
> for Spark Data Frames. But Java code examples are also required. Some Java 
> code has already been developed but requires further testing.



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

[jira] [Commented] (IGNITE-7909) Java code examples are needed for Spark Data Frames.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7909:


Github user VeryFatBoy closed the pull request at:

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


> Java code examples are needed for Spark Data Frames.
> 
>
> Key: IGNITE-7909
> URL: https://issues.apache.org/jira/browse/IGNITE-7909
> Project: Ignite
>  Issue Type: Improvement
>  Components: spark
>Affects Versions: 2.5
>Reporter: Akmal Chaudhri
>Assignee: Akmal Chaudhri
>Priority: Major
>  Labels: spark
> Fix For: 2.5
>
> Attachments: JavaIgniteCatalogExample.java, 
> JavaIgniteDataFrameExample.java, JavaIgniteDataFrameWriteExample.java
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Existing Scala code examples have been developed to illustrate Ignite support 
> for Spark Data Frames. But Java code examples are also required. Some Java 
> code has already been developed but requires further testing.



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

[jira] [Commented] (IGNITE-7909) Java code examples are needed for Spark Data Frames.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7909:


GitHub user VeryFatBoy reopened a pull request:

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

IGNITE-7909 - Java code example.

Java version of IgniteDataFrameExample.scala

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

$ git pull https://github.com/VeryFatBoy/ignite VeryFatBoy-patch-2

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

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


commit 52026e922b670289d928a2b711f3c53e0ea23a2a
Author: VeryFatBoy 
Date:   2018-04-17T17:33:41Z

IGNITE-7909 - Java code example.




> Java code examples are needed for Spark Data Frames.
> 
>
> Key: IGNITE-7909
> URL: https://issues.apache.org/jira/browse/IGNITE-7909
> Project: Ignite
>  Issue Type: Improvement
>  Components: spark
>Affects Versions: 2.5
>Reporter: Akmal Chaudhri
>Assignee: Akmal Chaudhri
>Priority: Major
>  Labels: spark
> Fix For: 2.5
>
> Attachments: JavaIgniteCatalogExample.java, 
> JavaIgniteDataFrameExample.java, JavaIgniteDataFrameWriteExample.java
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Existing Scala code examples have been developed to illustrate Ignite support 
> for Spark Data Frames. But Java code examples are also required. Some Java 
> code has already been developed but requires further testing.



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

[jira] [Commented] (IGNITE-7909) Java code examples are needed for Spark Data Frames.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7909:


Github user VeryFatBoy closed the pull request at:

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


> Java code examples are needed for Spark Data Frames.
> 
>
> Key: IGNITE-7909
> URL: https://issues.apache.org/jira/browse/IGNITE-7909
> Project: Ignite
>  Issue Type: Improvement
>  Components: spark
>Affects Versions: 2.5
>Reporter: Akmal Chaudhri
>Assignee: Akmal Chaudhri
>Priority: Major
>  Labels: spark
> Fix For: 2.5
>
> Attachments: JavaIgniteCatalogExample.java, 
> JavaIgniteDataFrameExample.java, JavaIgniteDataFrameWriteExample.java
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Existing Scala code examples have been developed to illustrate Ignite support 
> for Spark Data Frames. But Java code examples are also required. Some Java 
> code has already been developed but requires further testing.



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

[jira] [Updated] (IGNITE-8333) Web console: Editors for table values have wrong baseline

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko updated IGNITE-8333:
--
Attachment: Selection_120.png

> Web console: Editors for table values have wrong baseline
> -
>
> Key: IGNITE-8333
> URL: https://issues.apache.org/jira/browse/IGNITE-8333
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Vasiliy Sisko
>Assignee: Ilya Borisov
>Priority: Major
> Attachments: Selection_120.png, Selection_121.png
>
>
> Baseline for table editor is higher than label baseline.



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

[jira] [Updated] (IGNITE-8333) Web console: Editors for table values have wrong baseline

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko updated IGNITE-8333:
--
Attachment: Selection_121.png

> Web console: Editors for table values have wrong baseline
> -
>
> Key: IGNITE-8333
> URL: https://issues.apache.org/jira/browse/IGNITE-8333
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Vasiliy Sisko
>Assignee: Ilya Borisov
>Priority: Major
> Attachments: Selection_120.png, Selection_121.png
>
>
> Baseline for table editor is higher than label baseline.



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

[jira] [Created] (IGNITE-8333) Web console: Editors for table values have wrong baseline

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-8333:
-

 Summary: Web console: Editors for table values have wrong baseline
 Key: IGNITE-8333
 URL: https://issues.apache.org/jira/browse/IGNITE-8333
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.5
Reporter: Vasiliy Sisko
Assignee: Ilya Borisov
 Attachments: Selection_120.png, Selection_121.png

Baseline for table editor is higher than label baseline.



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

[jira] [Created] (IGNITE-8332) Web console: Empty cells in SQL Scheme table

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-8332:
-

 Summary: Web console: Empty cells in SQL Scheme table
 Key: IGNITE-8332
 URL: https://issues.apache.org/jira/browse/IGNITE-8332
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Affects Versions: 2.5
Reporter: Vasiliy Sisko
Assignee: Ilya Borisov
 Attachments: Selection_118.png

# Open SQL Scheme tab of configuration.
 # Add new SQL Scheme

Row for new scheme is appeared but it's cells are empty.

See attached screenshot.



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

[jira] [Updated] (IGNITE-8332) Web console: Empty cells in SQL Scheme table

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko updated IGNITE-8332:
--
Attachment: Selection_118.png

> Web console: Empty cells in SQL Scheme table
> 
>
> Key: IGNITE-8332
> URL: https://issues.apache.org/jira/browse/IGNITE-8332
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.5
>Reporter: Vasiliy Sisko
>Assignee: Ilya Borisov
>Priority: Major
> Attachments: Selection_118.png
>
>
> # Open SQL Scheme tab of configuration.
>  # Add new SQL Scheme
> Row for new scheme is appeared but it's cells are empty.
> See attached screenshot.



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

[jira] [Comment Edited] (IGNITE-8245) Web console: "Warning" icon is displayed above "secured key" icon.

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov edited comment on IGNITE-8245 at 4/20/18 2:35 AM:
-

 !screenshot-1.png! 
"Warning" icon overlay "cross" icon under Edge.
Please fix.

The same issue in Confirm (password) field.


was (Author: pkonstantinov):
 !screenshot-1.png! 
"Warning" icon overlay "cross" icon under Edge.
Please fix.

> Web console: "Warning" icon is displayed above "secured key" icon.
> --
>
> Key: IGNITE-8245
> URL: https://issues.apache.org/jira/browse/IGNITE-8245
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.4
>Reporter: Andrey Novikov
>Assignee: Dmitriy Shabalin
>Priority: Major
> Fix For: 2.6
>
> Attachments: screenshot-1.png, warning_icon.png
>
>
> See attachment. Reproduced in Safari.
> Make the actual input borderless, move the border to outer element, shrink 
> the input element when an error notification has to be shown.



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

[jira] [Commented] (IGNITE-8215) Web console: some fields are not generated

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko commented on IGNITE-8215:
---

Fixed:
Data Region Configuration
# Metrics sub interval count.
# Metrics rate time interval.
# Swap file path.

Discovery
Specified fields are available only for Ignite 1.x.

> Web console: some fields are not generated
> --
>
> Key: IGNITE-8215
> URL: https://issues.apache.org/jira/browse/IGNITE-8215
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.6
>
>
> Data Region Configuration 
> - Metrics sub interval count
> - Metrics rate time interval
> Discovery
> - Max heartbeats miss w/o init:
> - Max missed client heartbeats



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

[jira] [Commented] (IGNITE-7691) Provide info about DECIMAL column scale and precision

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-7691:
-

This patch was discussed with [~vozerov] and [~dpavlov].
We came to the next agreements:

1. To make this patch correct we should implement support for a BigDecimal and 
Varchar constraints.
2. If we can't do that when 2.6 will be ready we should revert this patch.

> Provide info about DECIMAL column scale and precision
> -
>
> Key: IGNITE-7691
> URL: https://issues.apache.org/jira/browse/IGNITE-7691
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.4
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Minor
> Fix For: 2.6
>
>
> Currently, it impossible to obtain scale and precision of DECIMAL column from 
> sql table metadata.
> Ignite should provide those type of meta information.



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

[jira] [Created] (IGNITE-8331) SQL: Add Decimal precision and scale constraint

[Nikolay Izhikov (JIRA)]

Nikolay Izhikov created IGNITE-8331:
---

 Summary: SQL: Add Decimal precision and scale constraint
 Key: IGNITE-8331
 URL: https://issues.apache.org/jira/browse/IGNITE-8331
 Project: Ignite
  Issue Type: Bug
Reporter: Nikolay Izhikov
Assignee: Nikolay Izhikov


We should support DECIMAL(X, Y) syntax. 
Currently, we ignore it. 
It affects semantics. 
E.g., one can insert a DECIMAL with greater precision into a cache/table 
without any problems. 



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

[jira] [Assigned] (IGNITE-6055) SQL: Add String length constraint

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov reassigned IGNITE-6055:
---

Assignee: Nikolay Izhikov

> SQL: Add String length constraint
> -
>
> Key: IGNITE-6055
> URL: https://issues.apache.org/jira/browse/IGNITE-6055
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: sql-engine
>
> We should support {{CHAR(X)}} and {{VARCHAR{X}} syntax. Currently, we ignore 
> it. First, it affects semantics. E.g., one can insert a string with greater 
> length into a cache/table without any problems. Second, it limits efficiency 
> of our default configuration. E.g., index inline cannot be applied to 
> {{String}} data type as we cannot guess it's length.



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

[jira] [Created] (IGNITE-8330) Docs: Put JDBC/ODBC URL in Brackets When Connecting From Bash

[Denis Magda (JIRA)]

Denis Magda created IGNITE-8330:
---

 Summary: Docs: Put JDBC/ODBC URL in Brackets When Connecting From 
Bash
 Key: IGNITE-8330
 URL: https://issues.apache.org/jira/browse/IGNITE-8330
 Project: Ignite
  Issue Type: Task
  Components: documentation
Reporter: Denis Magda
Assignee: Prachi Garg
 Fix For: 2.5


We need to add a warning callout with the content below to both JDBC and ODBC 
documentation pages:
Title: Put JDBC/ODBC URL in Brackets When Connecting From Bash
Description:
Make sure to put the connection URL in " brackets when opening it up from a 
bash environment, as follows: 
"jdbc:ignite:thin://[address]:[port];user=ignite;password=[password]"



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

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

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-8154:
-

[~antkr], just changing to {{U.error}} is not enough, you need to pass the 
exception as a parameter. Currently you concatenate it with the message, 
therefore losing the stack trace. BTW, you should see that in the logs when 
running the test.

Please fix this and I will merge.

> 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: Anton Kurbanov
>Priority: Major
> Fix For: 2.6
>
>
> 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-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=16444600#comment-16444600
 ] 

Valentin Kulichenko commented on IGNITE-7077:
-

[~NIzhikov], OK, this naming makes sense to me then. I believe it's good to 
merge. Thanks!

> 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] [Resolved] (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:all-tabpanel
 ]

Yashasvi Kotamraju resolved IGNITE-6252.

Resolution: Fixed

> 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.6
>
>
> 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-6252) Cassandra Cache Store Session does not retry if prepare statement failed

[Igor Rudyak (JIRA)]

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

Igor Rudyak commented on IGNITE-6252:
-

[~kotamrajuyashasvi] right after 
[handlePreparedStatementClusterError|https://github.com/apache/ignite/blob/master/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L252]
 method call, there is a call to 
[refresh|https://github.com/apache/ignite/blob/master/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L253]
  prepared statement using new Cassandra session. Thus subsequent statements 
running by the *same thread* should be good.

However there could be other threads trying to refresh session because they are 
also failed to execute prepared statement. Here we have two cases:

1) All threads trying to refresh Cassandra session at the same time. This case 
should be handled properly by this 
[logic|https://github.com/apache/ignite/blob/master/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L879],
 preventing threads to refresh session multiple times. Also because of this you 
may see [such 
warnings|https://github.com/apache/ignite/blob/master/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L880],
 which is fine.

2) It's possible that some threads will try to refresh Cassandra session 
sequentially, because scheduling among threads is unpredictable and while 
refreshing session other threads which are trying to 
[execute|https://github.com/apache/ignite/blob/master/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L231]
 prepared statement will be locked, cause 
[session()|https://github.com/apache/ignite/blob/master/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L538]
 call is synchronized. Thus we are running into number of extra (and 
unnecessary) refreshments of Cassandra session which is a problem. 

[~kotamrajuyashasvi] Could you please create a separate ticket for this issue 
(case 2)?  Current ticket is about another problem which is fixed now.

 

> 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.6
>
>
> 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-8197) ignite won't start with spring-boot 1.5.11 - h2 property NESTED_JOINS doesn't exist

[JIRA]

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

Łukasz Byjoś commented on IGNITE-8197:
--

I updated spring boot from 2.0.0.RC1 to 2.0.1.RELEASE and have the same issue

> ignite won't start with spring-boot 1.5.11 - h2 property NESTED_JOINS doesn't 
> exist
> ---
>
> Key: IGNITE-8197
> URL: https://issues.apache.org/jira/browse/IGNITE-8197
> Project: Ignite
>  Issue Type: Bug
>Reporter: Scott Feldstein
>Priority: Major
> Attachments: spring-boot-ignite.zip
>
>
> I just upgraded to spring-boot 1.5.11 and am seeing the error below. I think 
> this is an issue with the version of h2 associated with spring boot 1.5.11. 
> In 1.5.10 the h2 version was 1.4.196 and with 1.5.11 it is 1.4.197. The 
> NESTED_JOINS property comes from 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing, i assume it 
> was deprecated but not sure. When I lock in my h2 version to 1.4.196 by 
> overriding the spring-dependencies parent everything works fine
> {code:java}
> Caused by: org.h2.jdbc.JdbcSQLException: Unsupported connection setting 
> "NESTED_JOINS" [90113-197]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:357) 
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.message.DbException.get(DbException.java:179) 
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.message.DbException.get(DbException.java:155) 
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.engine.ConnectionInfo.readSettingsFromURL(ConnectionInfo.java:268) 
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.engine.ConnectionInfo.(ConnectionInfo.java:76) 
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.jdbc.JdbcConnection.(JdbcConnection.java:103) 
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.Driver.connect(Driver.java:69) ~[h2-1.4.197.jar:1.4.197]
> at java.sql.DriverManager.getConnection(DriverManager.java:664) ~[?:1.8.0_131]
> at java.sql.DriverManager.getConnection(DriverManager.java:270) ~[?:1.8.0_131]
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$1.initialValue(IgniteH2Indexing.java:317)
>  ~[ignite-indexing-2.4.0.jar:2.4.0]
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$1.initialValue(IgniteH2Indexing.java:288)
>  ~[ignite-indexing-2.4.0.jar:2.4.0]
> at java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:180) ~[?:1.8.0_131]
> at java.lang.ThreadLocal.get(ThreadLocal.java:170) ~[?:1.8.0_131]
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$1.get(IgniteH2Indexing.java:290)
>  ~[ignite-indexing-2.4.0.jar:2.4.0]
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$1.get(IgniteH2Indexing.java:288)
>  ~[ignite-indexing-2.4.0.jar:2.4.0]
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.connectionForThread(IgniteH2Indexing.java:514)
>  ~[ignite-indexing-2.4.0.jar:2.4.0]
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeStatement(IgniteH2Indexing.java:582)
>  ~[ignite-indexing-2.4.0.jar:2.4.0]
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.createSchema(IgniteH2Indexing.java:551)
>  ~[ignite-indexing-2.4.0.jar:2.4.0]
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.registerCache(IgniteH2Indexing.java:2667)
>  ~[ignite-indexing-2.4.0.jar:2.4.0]
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.registerCache0(GridQueryProcessor.java:1594)
>  ~[ignite-core-2.4.0.jar:2.4.0]
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:800)
>  ~[ignite-core-2.4.0.jar:2.4.0]
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:861)
>  ~[ignite-core-2.4.0.jar:2.4.0]
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1158)
>  ~[ignite-core-2.4.0.jar:2.4.0]
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1900)
>  ~[ignite-core-2.4.0.jar:2.4.0]
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1764)
>  ~[ignite-core-2.4.0.jar:2.4.0]
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:744)
>  ~[ignite-core-2.4.0.jar:2.4.0]
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:626)
>  ~[ignite-core-2.4.0.jar:2.4.0]
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2337)
>  

[jira] [Comment Edited] (IGNITE-7791) Ignite Client Nodes: failed test IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov edited comment on IGNITE-7791 at 4/19/18 5:29 PM:
---

[~dpavlov],
My idea is that current logic is correct. 
Only one issue that {{caches.clear();}} inside 
{{org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager#initCachesOnLocalJoin}}
 kills survived cache group's descriptors (ignite-sys-cache in this reproducer).

This kill affects only *rare* operation like delayed AffinityChangeRequest, 
that's why it was not fixed during BLT development.

{{caches.clear();}} removal fixes the reproducer Maxim created and that's the 
fix I'm proposing.

Solution merged to master fixes reproducer too, but looks like some kind of 
hotfix without any warranty that logic is not broken now.
As far as I understand, [~Mmuzaf] proposed this solution not as final, but with 
question "Will this breaks something?"


[~agoncharuk], could you please finally check that logic related to 
{{locJoinCachesCtx.removeSurvivedCacheGroups(survivedCacheGrps)}} was removed 
properly and this removal will not cause issues at production/design?



was (Author: avinogradov):
[~dpavlov],
My idea is that current logic is correct. 
Only one issue that {{caches.clear();}} inside 
{{org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager#initCachesOnLocalJoin}}
 kills survived cache group's descriptors (ignite-sys-cache it this reproducer).

This kill affects only *rare* operation like delayed AffinityChangeRequest, 
that's why it was not fixed during BLT development.

{{caches.clear();}} removal fixes the reproducer Maxim created and that's the 
fix I'm proposing.

Solution merged to master fixes reproducer too, but looks like some kind of 
hotfix without any warranty that logic is not broken now.
As far as I understand, [~Mmuzaf] proposed this solution not as final, but with 
question "Will this breaks something?"


[~agoncharuk], could you please finally check that logic related to 
{{locJoinCachesCtx.removeSurvivedCacheGroups(survivedCacheGrps)}} was removed 
properly and this removal will not cause issues at production/design?


> Ignite Client Nodes: failed test 
> IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()
> ---
>
> Key: IGNITE-7791
> URL: https://issues.apache.org/jira/browse/IGNITE-7791
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
> Attachments: IgniteClientReconnectCacheDelayExchangeTest.java
>
>
> Test is flaky, success rate: 32.4%, test history is 
> [here|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-9174769196124217030=testDetails]
> Reproducible locally.
> Test fails on waiting for disco cache content:
> {noformat}
> junit.framework.AssertionFailedError
>   at junit.framework.Assert.fail(Assert.java:55)
>   at junit.framework.Assert.assertTrue(Assert.java:22)
>   at junit.framework.Assert.assertTrue(Assert.java:31)
>   at junit.framework.TestCase.assertTrue(TestCase.java:201)
>   at 
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.checkCacheDiscoveryData(IgniteClientReconnectCacheTest.java:1414)
>   at 
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated(IgniteClientReconnectCacheTest.java:897)
>   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:745)
> {noformat}
> This fail may be caused by another exception earlier in the log:
> {noformat}
> [2018-02-22 
> 14:32:57,972][ERROR][exchange-worker-#3025%internal.IgniteClientReconnectCacheTest3%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=6, 
> minorTopVer=1], discoEvt=DiscoveryCustomEvent 
> [customMsg=CacheAffinityChangeMessage 
> 

[jira] [Commented] (IGNITE-8312) .NET: CacheAbstractTransactionalTest.TestTxRollbackOnly failure

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-8312:
--

[~dpavlov], current PR mentions this in javadoc. I've created [1] in order to 
make a change in docs.

[1] https://issues.apache.org/jira/browse/IGNITE-8329

> .NET: CacheAbstractTransactionalTest.TestTxRollbackOnly failure
> ---
>
> Key: IGNITE-8312
> URL: https://issues.apache.org/jira/browse/IGNITE-8312
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> {noformat}
> Test(s) failed.   Expected: 
> 
>   But was:   (Invalid transaction 
> state for prepare [state=MARKED_ROLLBACK, 
> tx=GridNearPessimisticTxPrepareFuture [innerFuts=[], super=GridCompoundFuture 
> [rdc=org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxPrepareFutureAdapter$1@62e703a4,
>  initFlag=0, lsnrCalls=0, done=false, cancelled=false, err=null, futs=[)
> {noformat}
> Caused by changes made in [1]
> [1] https://issues.apache.org/jira/browse/IGNITE-7770



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

[jira] [Updated] (IGNITE-8329) Clarify TransactionRollbackException-related paragraph in documentation

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov updated IGNITE-8329:
-
Component/s: documentation

> Clarify TransactionRollbackException-related paragraph in documentation
> ---
>
> Key: IGNITE-8329
> URL: https://issues.apache.org/jira/browse/IGNITE-8329
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Andrey Kuznetsov
>Priority: Trivial
>
> As documentation states currently [1], TransactionRollbackException is thrown 
> "if the transaction was rolled back automatically". This should be extended 
> to manual rollback as well, if it took place before commit for some reason.
> [1] 
> https://apacheignite.readme.io/docs/transactions#section-handling-failed-transactions



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

[jira] [Created] (IGNITE-8329) Clarify TransactionRollbackException-related paragraph in documentation

[Andrey Kuznetsov (JIRA)]

Andrey Kuznetsov created IGNITE-8329:


 Summary: Clarify TransactionRollbackException-related paragraph in 
documentation
 Key: IGNITE-8329
 URL: https://issues.apache.org/jira/browse/IGNITE-8329
 Project: Ignite
  Issue Type: Task
Reporter: Andrey Kuznetsov


As documentation states currently [1], TransactionRollbackException is thrown 
"if the transaction was rolled back automatically". This should be extended to 
manual rollback as well, if it took place before commit for some reason.

[1] 
https://apacheignite.readme.io/docs/transactions#section-handling-failed-transactions



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

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

[Anton Kurbanov (JIRA)]

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

Anton Kurbanov commented on IGNITE-8154:


[~vkulichenko], thank you for review! Made some changes as per your 
suggestions, PR refreshed: [PR|https://github.com/apache/ignite/pull/3828]

> 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: Anton Kurbanov
>Priority: Major
> Fix For: 2.6
>
>
> 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] [Updated] (IGNITE-8328) .NET: Thin client: Run in browser with Blazor

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-8328:
---
Issue Type: Task  (was: Bug)

> .NET: Thin client: Run in browser with Blazor
> -
>
> Key: IGNITE-8328
> URL: https://issues.apache.org/jira/browse/IGNITE-8328
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
>
> Blazor runs .NET IL code in browser with WebAssembly.
> Investigate if we can make Ignite.NET thin client run there.



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

[jira] [Created] (IGNITE-8328) .NET: Thin client: Run in browser with Blazor

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-8328:
--

 Summary: .NET: Thin client: Run in browser with Blazor
 Key: IGNITE-8328
 URL: https://issues.apache.org/jira/browse/IGNITE-8328
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn


Blazor runs .NET IL code in browser with WebAssembly.

Investigate if we can make Ignite.NET thin client run there.



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

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

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko edited comment on IGNITE-8154 at 4/19/18 4:47 PM:
--

[~antkr], please replace {{U.warn}} with {{U.error}} so that the whole stack 
trace is logged in case of exception.

In the test, you should avoid loops that can possibly never finish, like these 
ones:
{code}
while(lsnrExceptions.isEmpty())
Thread.sleep(200);
{code}
Instead, you should have a {{CountDownLatch}} that is counted down from the 
exception listener. Test itself should then call {{await()}} with a timeout and 
assert that it returns {{true}}.


was (Author: vkulichenko):
[~antkr], please replace `U.warn` with `U.error` so that the whole stack trace 
is logged in case of exception.

In the test, you should avoid loops that can possibly never finish, like these 
ones:
{code}
while(lsnrExceptions.isEmpty())
Thread.sleep(200);
{code}
Instead, you should have a {CountDownLatch} that is counted down from the 
exception listener. Test itself should then call `await()` with a timeout and 
assert that it returns `true`.

> 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: Anton Kurbanov
>Priority: Major
> Fix For: 2.6
>
>
> 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-8312) .NET: CacheAbstractTransactionalTest.TestTxRollbackOnly failure

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8312:


{{TransactionRollbackException}}  is thrown in case automatic rollback. 

[https://apacheignite.readme.io/docs/transactions#section-handling-failed-transactions]

Probably we need to mention case of not automatic (manual) rollback in javadoc 
& docs

> .NET: CacheAbstractTransactionalTest.TestTxRollbackOnly failure
> ---
>
> Key: IGNITE-8312
> URL: https://issues.apache.org/jira/browse/IGNITE-8312
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> {noformat}
> Test(s) failed.   Expected: 
> 
>   But was:   (Invalid transaction 
> state for prepare [state=MARKED_ROLLBACK, 
> tx=GridNearPessimisticTxPrepareFuture [innerFuts=[], super=GridCompoundFuture 
> [rdc=org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxPrepareFutureAdapter$1@62e703a4,
>  initFlag=0, lsnrCalls=0, done=false, cancelled=false, err=null, futs=[)
> {noformat}
> Caused by changes made in [1]
> [1] https://issues.apache.org/jira/browse/IGNITE-7770



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

[jira] [Commented] (IGNITE-8077) Implement new JMX metrics for transactions

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-8077:
--

Guys,

1) Please rename TxMxBean to TransactionMetricsMxBean
2) MxBean should extend TransactionMetrics - we should not have two not 
connected transaction metrics, so we should return existing metrics from mx 
bean and add new metrics to TransactionMetrics

> Implement new JMX metrics for transactions
> --
>
> Key: IGNITE-8077
> URL: https://issues.apache.org/jira/browse/IGNITE-8077
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Dmitriy Govorukhin
>Assignee: Anton Kalashnikov
>Priority: Major
>  Labels: iep-6
> Fix For: 2.5
>
>
> These additional metrics should be implemented to monitor transactions.
> {code}
> class TransactionsMXbean{
> /** The number of transactions which was commited. */
> long getTxCommited();
> /** The number of transactions which was rollbacked. */
> long getTxRolledBack();
> /** The number of transactions holding at least one key lock. */
> long getTxHoldingLock();
> /** The number of keys locked on the node. */
> long getLockedKeys();
> /** The number of transactions for which node is the initiator. */
> int getOwnerTxs();
> }
> {code}
> For more details see in IgniteTxAdapter and IgniteTxManager.



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

[jira] [Comment Edited] (IGNITE-7791) Ignite Client Nodes: failed test IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov edited comment on IGNITE-7791 at 4/19/18 4:32 PM:
---

[~dpavlov],
My idea is that current logic is correct. 
Only one issue that {{caches.clear();}} inside 
{{org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager#initCachesOnLocalJoin}}
 kills survived cache group's descriptors (ignite-sys-cache it this reproducer).

This kill affects only *rare* operation like delayed AffinityChangeRequest, 
that's why it was not fixed during BLT development.

{{caches.clear();}} removal fixes the reproducer Maxim created and that's the 
fix I'm proposing.

Solution merged to master fixes reproducer too, but looks like some kind of 
hotfix without any warranty that logic is not broken now.
As far as I understand, [~Mmuzaf] proposed this solution not as final, but with 
question "Will this breaks something?"


[~agoncharuk], could you please finally check that logic related to 
{{locJoinCachesCtx.removeSurvivedCacheGroups(survivedCacheGrps)}} was removed 
properly and this removal will not cause issues at production/design?



was (Author: avinogradov):
[~dpavlov],
My idea is that current logic is correct. 
Only one issue that {{caches.clear();}} inside 
{{org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager#initCachesOnLocalJoin}}
 kills survived cache group's descriptors (ignite-sys-cache it this reproducer).

This kill affects only *rare* operation like delayed AffinityChangeRequest, 
that's why it was not fixed during BLT development.

{{caches.clear();}} removal fixes the reproducer Maxim created and that's the 
fix I'm proposing.

Solution merged to master fixes reproducer too, but looks like some kind of 
hotfix without any warranty that logic is not broken now.
As far as I understand, [~Mmuzaf] proposed this solution not as final, but with 
question "Will this breaks something?"


[~agoncharuk], could you please finally check that logic related to 
{{locJoinCachesCtx.removeSurvivedCacheGroups(survivedCacheGrps);}} was removed 
properly and this removal will not cause issues at production/design?


> Ignite Client Nodes: failed test 
> IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()
> ---
>
> Key: IGNITE-7791
> URL: https://issues.apache.org/jira/browse/IGNITE-7791
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
> Attachments: IgniteClientReconnectCacheDelayExchangeTest.java
>
>
> Test is flaky, success rate: 32.4%, test history is 
> [here|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-9174769196124217030=testDetails]
> Reproducible locally.
> Test fails on waiting for disco cache content:
> {noformat}
> junit.framework.AssertionFailedError
>   at junit.framework.Assert.fail(Assert.java:55)
>   at junit.framework.Assert.assertTrue(Assert.java:22)
>   at junit.framework.Assert.assertTrue(Assert.java:31)
>   at junit.framework.TestCase.assertTrue(TestCase.java:201)
>   at 
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.checkCacheDiscoveryData(IgniteClientReconnectCacheTest.java:1414)
>   at 
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated(IgniteClientReconnectCacheTest.java:897)
>   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:745)
> {noformat}
> This fail may be caused by another exception earlier in the log:
> {noformat}
> [2018-02-22 
> 14:32:57,972][ERROR][exchange-worker-#3025%internal.IgniteClientReconnectCacheTest3%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=6, 
> minorTopVer=1], discoEvt=DiscoveryCustomEvent 
> [customMsg=CacheAffinityChangeMessage 
> 

[jira] [Comment Edited] (IGNITE-7791) Ignite Client Nodes: failed test IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov edited comment on IGNITE-7791 at 4/19/18 4:19 PM:
---

[~dpavlov],
My idea is that current logic is correct. 
Only one issue that {{caches.clear();}} inside 
{{org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager#initCachesOnLocalJoin}}
 kills survived cache group's descriptors (ignite-sys-cache it this reproducer).

This kill affects only *rare* operation like delayed AffinityChangeRequest, 
that's why it was not fixed during BLT development.

{{caches.clear();}} removal fixes the reproducer Maxim created and that's the 
fix I'm proposing.

Solution merged to master fixes reproducer too, but looks like some kind of 
hotfix without any warranty that logic is not broken now.
As far as I understand, [~Mmuzaf] proposed this solution not as final, but with 
question "Will this breaks something?"


[~agoncharuk], could you please finally check that logic related to 
{{locJoinCachesCtx.removeSurvivedCacheGroups(survivedCacheGrps);}} was removed 
properly and this removal will not cause issues at production/design?



was (Author: avinogradov):
[~dpavlov],
My idea is that current logic is correct. 
Only one issue that {{caches.clear();}} inside 
{{org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager#initCachesOnLocalJoin}}
 kills survived cache group's descriptors (ignite-sys-cache it this reproducer).

This kill affects only *rare* operation like delayed AffinityChangeRequest, 
that's why it was not fixed during BLT development.

{{caches.clear();}} removal fixes the reproducer Maxim created and that's the 
fix I'm proposing.

Solution merged to master fixes reproducer too, but looks like some kind of 
hotfix without any warranty logic is not broken now.
As far as I understand, [~Mmuzaf] proposed this solution not as final, but with 
question "Will this breaks something?"


[~agoncharuk], could you please finally check that logic related to 
{{locJoinCachesCtx.removeSurvivedCacheGroups(survivedCacheGrps);}} was removed 
properly and this removal will not cause issues at production/design?


> Ignite Client Nodes: failed test 
> IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()
> ---
>
> Key: IGNITE-7791
> URL: https://issues.apache.org/jira/browse/IGNITE-7791
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
> Attachments: IgniteClientReconnectCacheDelayExchangeTest.java
>
>
> Test is flaky, success rate: 32.4%, test history is 
> [here|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-9174769196124217030=testDetails]
> Reproducible locally.
> Test fails on waiting for disco cache content:
> {noformat}
> junit.framework.AssertionFailedError
>   at junit.framework.Assert.fail(Assert.java:55)
>   at junit.framework.Assert.assertTrue(Assert.java:22)
>   at junit.framework.Assert.assertTrue(Assert.java:31)
>   at junit.framework.TestCase.assertTrue(TestCase.java:201)
>   at 
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.checkCacheDiscoveryData(IgniteClientReconnectCacheTest.java:1414)
>   at 
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated(IgniteClientReconnectCacheTest.java:897)
>   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:745)
> {noformat}
> This fail may be caused by another exception earlier in the log:
> {noformat}
> [2018-02-22 
> 14:32:57,972][ERROR][exchange-worker-#3025%internal.IgniteClientReconnectCacheTest3%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=6, 
> minorTopVer=1], discoEvt=DiscoveryCustomEvent 
> [customMsg=CacheAffinityChangeMessage 
> 

[jira] [Comment Edited] (IGNITE-7791) Ignite Client Nodes: failed test IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov edited comment on IGNITE-7791 at 4/19/18 4:18 PM:
---

[~dpavlov],
My idea is that current logic is correct. 
Only one issue that {{caches.clear();}} inside 
{{org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager#initCachesOnLocalJoin}}
 kills survived cache group's descriptors (ignite-sys-cache it this reproducer).

This kill affects only *rare* operation like delayed AffinityChangeRequest, 
that's why it was not fixed during BLT development.

{{caches.clear();}} removal fixes the reproducer Maxim created and that's the 
fix I'm proposing.

Solution merged to master fixes reproducer too, but looks like some kind of 
hotfix without any warranty logic is not broken now.
As far as I understand, [~Mmuzaf] proposed this solution not as final, but with 
question "Will this breaks something?"


[~agoncharuk], could you please finally check that logic related to 
{{locJoinCachesCtx.removeSurvivedCacheGroups(survivedCacheGrps);}} was removed 
properly and this removal will not cause issues at production/design?



was (Author: avinogradov):
[~dpavlov],
My idea is that current logic is correct. 
Only one issue that {{caches.clear();}} inside 
{{org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager#initCachesOnLocalJoin.}}
 kills survived cache group's descriptors (ignite-sys-cache it this reproducer).

This kill affects only *rare* operation like delayed AffinityChangeRequest, 
that's why it was not fixed during BLT development.

{{caches.clear();}} removal fixes the reproducer Maxim created and that's the 
fix I'm proposing.

Solution merged to master fixes reproducer too, but looks like some kind of 
hotfix without any warranty logic is not broken now.
As far as I understand, [~Mmuzaf] proposed this solution not as final, but with 
question "Will this breaks something?"


[~agoncharuk], could you please finally check that logic related to 
{{locJoinCachesCtx.removeSurvivedCacheGroups(survivedCacheGrps);}} was removed 
properly and this removal will not cause issues at production/design?


> Ignite Client Nodes: failed test 
> IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()
> ---
>
> Key: IGNITE-7791
> URL: https://issues.apache.org/jira/browse/IGNITE-7791
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
> Attachments: IgniteClientReconnectCacheDelayExchangeTest.java
>
>
> Test is flaky, success rate: 32.4%, test history is 
> [here|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-9174769196124217030=testDetails]
> Reproducible locally.
> Test fails on waiting for disco cache content:
> {noformat}
> junit.framework.AssertionFailedError
>   at junit.framework.Assert.fail(Assert.java:55)
>   at junit.framework.Assert.assertTrue(Assert.java:22)
>   at junit.framework.Assert.assertTrue(Assert.java:31)
>   at junit.framework.TestCase.assertTrue(TestCase.java:201)
>   at 
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.checkCacheDiscoveryData(IgniteClientReconnectCacheTest.java:1414)
>   at 
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated(IgniteClientReconnectCacheTest.java:897)
>   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:745)
> {noformat}
> This fail may be caused by another exception earlier in the log:
> {noformat}
> [2018-02-22 
> 14:32:57,972][ERROR][exchange-worker-#3025%internal.IgniteClientReconnectCacheTest3%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=6, 
> minorTopVer=1], discoEvt=DiscoveryCustomEvent 
> [customMsg=CacheAffinityChangeMessage 
> 

[jira] [Commented] (IGNITE-7791) Ignite Client Nodes: failed test IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-7791:
--

[~dpavlov],
My idea is that current logic is correct. 
Only one issue that {{caches.clear();}} inside 
{{org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager#initCachesOnLocalJoin.}}
 kills survived cache group's descriptors (ignite-sys-cache it this reproducer).

This kill affects only *rare* operation like delayed AffinityChangeRequest, 
that's why it was not fixed during BLT development.

{{caches.clear();}} removal fixes the reproducer Maxim created and that's the 
fix I'm proposing.

Solution merged to master fixes reproducer too, but looks like some kind of 
hotfix without any warranty logic is not broken now.
As far as I understand, [~Mmuzaf] proposed this solution not as final, but with 
question "Will this breaks something?"


[~agoncharuk], could you please finally check that logic related to 
{{locJoinCachesCtx.removeSurvivedCacheGroups(survivedCacheGrps);}} was removed 
properly and this removal will not cause issues at production/design?


> Ignite Client Nodes: failed test 
> IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()
> ---
>
> Key: IGNITE-7791
> URL: https://issues.apache.org/jira/browse/IGNITE-7791
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
> Attachments: IgniteClientReconnectCacheDelayExchangeTest.java
>
>
> Test is flaky, success rate: 32.4%, test history is 
> [here|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-9174769196124217030=testDetails]
> Reproducible locally.
> Test fails on waiting for disco cache content:
> {noformat}
> junit.framework.AssertionFailedError
>   at junit.framework.Assert.fail(Assert.java:55)
>   at junit.framework.Assert.assertTrue(Assert.java:22)
>   at junit.framework.Assert.assertTrue(Assert.java:31)
>   at junit.framework.TestCase.assertTrue(TestCase.java:201)
>   at 
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.checkCacheDiscoveryData(IgniteClientReconnectCacheTest.java:1414)
>   at 
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated(IgniteClientReconnectCacheTest.java:897)
>   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:745)
> {noformat}
> This fail may be caused by another exception earlier in the log:
> {noformat}
> [2018-02-22 
> 14:32:57,972][ERROR][exchange-worker-#3025%internal.IgniteClientReconnectCacheTest3%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=6, 
> minorTopVer=1], discoEvt=DiscoveryCustomEvent 
> [customMsg=CacheAffinityChangeMessage 
> [id=3cea94db161-760b7b18-b776-4ee7-ae5a-64f9494eaa36, 
> topVer=AffinityTopologyVersion [topVer=3, minorTopVer=0], exchId=null, 
> partsMsg=null, exchangeNeeded=true], affTopVer=AffinityTopologyVersion 
> [topVer=6, minorTopVer=1], super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=1b7f7330-69d8-4bd0-b2e9-71773610, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1519299177395, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], topVer=6, nodeId8=658aeb36, msg=null, 
> type=DISCOVERY_CUSTOM_EVT, tstamp=1519299177971]], nodeId=1b7f7330, 
> evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: 236160867
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$CachesInfo.group(CacheAffinitySharedManager.java:2636)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$8.applyx(CacheAffinitySharedManager.java:989)
>   at 
> 

[jira] [Updated] (IGNITE-8315) Prevent printing the partition distribution on clients nodes

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-8315:
---
Description: 
The feature of partitions distribution logging has been added recently into 
IGNITE-4756.

One of community member [informed that clients nodes now routinely 
print|https://issues.apache.org/jira/browse/IGNITE-4756?focusedCommentId=16442633=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16442633]:
{CODE}2018-04-18T14:06:42,963]exchange-worker-#57[GridAffinityAssignmentCache] 
Local node affinity assignment distribution is not ideal [cache=data2, 
expectedPrimary=256.00, actualPrimary=0, expectedBackups=256.00, 
actualBackups=0, warningThreshold=50.00%]{CODE}

Clients nodes shouldn't print partitition distribution since they don't store 
data.

  was:
The feature of partitions distribution logging has been added recently into 
IGNITE-4756.

One of community member informed that clients nodes now routinely print:
{CODE}2018-04-18T14:06:42,963]exchange-worker-#57[GridAffinityAssignmentCache] 
Local node affinity assignment distribution is not ideal [cache=data2, 
expectedPrimary=256.00, actualPrimary=0, expectedBackups=256.00, 
actualBackups=0, warningThreshold=50.00%]{CODE}

Clients nodes shouldn't print partitition distribution since they don't store 
data.


> Prevent printing the partition distribution on clients nodes
> 
>
> Key: IGNITE-8315
> URL: https://issues.apache.org/jira/browse/IGNITE-8315
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.6
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Major
> Fix For: 2.6
>
>
> The feature of partitions distribution logging has been added recently into 
> IGNITE-4756.
> One of community member [informed that clients nodes now routinely 
> print|https://issues.apache.org/jira/browse/IGNITE-4756?focusedCommentId=16442633=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16442633]:
> {CODE}2018-04-18T14:06:42,963]exchange-worker-#57[GridAffinityAssignmentCache]
>  Local node affinity assignment distribution is not ideal [cache=data2, 
> expectedPrimary=256.00, actualPrimary=0, expectedBackups=256.00, 
> actualBackups=0, warningThreshold=50.00%]{CODE}
> Clients nodes shouldn't print partitition distribution since they don't store 
> data.



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

[jira] [Updated] (IGNITE-8315) Prevent printing the partition distribution on clients nodes

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-8315:
---
Description: 
The feature of partitions distribution logging has been added recently into 
IGNITE-4756.

One of community member informed that clients nodes now routinely print:
{CODE}2018-04-18T14:06:42,963]exchange-worker-#57[GridAffinityAssignmentCache] 
Local node affinity assignment distribution is not ideal [cache=data2, 
expectedPrimary=256.00, actualPrimary=0, expectedBackups=256.00, 
actualBackups=0, warningThreshold=50.00%]{CODE}

Clients nodes shouldn't print partitition distribution since they don't store 
data.

  was:
The feature of partitions distribution logging has been added recently into 
IGNITE-4756.

One of community member 
[informed|https://issues.apache.org/jira/browse/IGNITE-4756?focusedCommentId=16442633=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16442633]
 that clients nodes now routinely print:
{{NOFORMAT}} 
2018-04-18T14:06:42,963]exchange-worker-#57[GridAffinityAssignmentCache] Local 
node affinity assignment distribution is not ideal [cache=data2, 
expectedPrimary=256.00, actualPrimary=0, expectedBackups=256.00, 
actualBackups=0, warningThreshold=50.00%]{{NOFORMAT}} 

Clients nodes shouldn't print partitition distribution since they don't store 
data.




> Prevent printing the partition distribution on clients nodes
> 
>
> Key: IGNITE-8315
> URL: https://issues.apache.org/jira/browse/IGNITE-8315
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.6
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Major
> Fix For: 2.6
>
>
> The feature of partitions distribution logging has been added recently into 
> IGNITE-4756.
> One of community member informed that clients nodes now routinely print:
> {CODE}2018-04-18T14:06:42,963]exchange-worker-#57[GridAffinityAssignmentCache]
>  Local node affinity assignment distribution is not ideal [cache=data2, 
> expectedPrimary=256.00, actualPrimary=0, expectedBackups=256.00, 
> actualBackups=0, warningThreshold=50.00%]{CODE}
> Clients nodes shouldn't print partitition distribution since they don't store 
> data.



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

[jira] [Updated] (IGNITE-8315) Prevent printing the partition distribution on clients nodes

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-8315:
---
Description: 
The feature of partitions distribution logging has been added recently into 
IGNITE-4756.

One of community member 
[informed|https://issues.apache.org/jira/browse/IGNITE-4756?focusedCommentId=16442633=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16442633]
 that clients nodes now routinely print:
{{NOFORMAT}} 
2018-04-18T14:06:42,963]exchange-worker-#57[GridAffinityAssignmentCache] Local 
node affinity assignment distribution is not ideal [cache=data2, 
expectedPrimary=256.00, actualPrimary=0, expectedBackups=256.00, 
actualBackups=0, warningThreshold=50.00%]{{NOFORMAT}} 

Clients nodes shouldn't print partitition distribution since they don't store 
data.



  was:subj


> Prevent printing the partition distribution on clients nodes
> 
>
> Key: IGNITE-8315
> URL: https://issues.apache.org/jira/browse/IGNITE-8315
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.6
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Major
> Fix For: 2.6
>
>
> The feature of partitions distribution logging has been added recently into 
> IGNITE-4756.
> One of community member 
> [informed|https://issues.apache.org/jira/browse/IGNITE-4756?focusedCommentId=16442633=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16442633]
>  that clients nodes now routinely print:
> {{NOFORMAT}} 
> 2018-04-18T14:06:42,963]exchange-worker-#57[GridAffinityAssignmentCache] 
> Local node affinity assignment distribution is not ideal [cache=data2, 
> expectedPrimary=256.00, actualPrimary=0, expectedBackups=256.00, 
> actualBackups=0, warningThreshold=50.00%]{{NOFORMAT}} 
> Clients nodes shouldn't print partitition distribution since they don't store 
> data.



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

[jira] [Commented] (IGNITE-8313) Trace logs enhancement for exchange and affinity calculation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8313:


GitHub user Jokser opened a pull request:

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

IGNITE-8313 Add trace logs on exchange phases and affinity calculation.



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

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

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

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


commit b23bc4ba0af209facb7251d1579cd93ad24b746b
Author: Pavel Kovalenko 
Date:   2018-04-19T16:11:06Z

IGNITE-8313 Add trace logs on exchange phases and affinity calculation.




> Trace logs enhancement for exchange and affinity calculation
> 
>
> Key: IGNITE-8313
> URL: https://issues.apache.org/jira/browse/IGNITE-8313
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Minor
> Fix For: 2.6
>
>
> For better problems debugging we should add more trace logs to following 
> places:
> 1) Partition states before and after exchange.
> 2) Affinity distribution for each topology version.



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

[jira] [Commented] (IGNITE-8325) Compressor thread may miss notification on stop

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8325:


Github user asfgit closed the pull request at:

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


> Compressor thread may miss notification on stop
> ---
>
> Key: IGNITE-8325
> URL: https://issues.apache.org/jira/browse/IGNITE-8325
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Alexey Goncharuk
>Assignee: Ivan Rakov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> I saw the following hang on TC:
> {code}
> "main" #1 prio=5 os_prio=0 tid=0x7f76b800d000 nid=0x33bf in Object.wait() 
> [0x7f76be6ce000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Thread.join(Thread.java:1245)
>   - locked <0xa50d52e0> (a 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor)
>   at java.lang.Thread.join(Thread.java:1319)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:7688)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.shutdown(FileWriteAheadLogManager.java:1993)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.access$800(FileWriteAheadLogManager.java:1775)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.stop0(FileWriteAheadLogManager.java:520)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.stop(GridCacheSharedManagerAdapter.java:94)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.stop(GridCacheProcessor.java:941)
>   at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2240)
>   at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2118)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2588)
>   - locked <0xa58a3978> (a 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2551)
>   at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:372)
>   at org.apache.ignite.Ignition.stop(Ignition.java:229)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1081)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1124)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1102)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.db.wal.WalCompactionTest.afterTest(WalCompactionTest.java:98)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1687)
>   at 
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.tearDown(GridCommonAbstractTest.java:492)
>   at junit.framework.TestCase.runBare(TestCase.java:146)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:255)
>   at junit.framework.TestSuite.run(TestSuite.java:250)
>   at junit.framework.TestSuite.runTest(TestSuite.java:255)
>   at junit.framework.TestSuite.run(TestSuite.java:250)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:369)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:275)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:239)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:160)
>   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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:206)
>   at 
> 

[jira] [Updated] (IGNITE-8325) Compressor thread may miss notification on stop

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-8325:
-
Affects Version/s: 2.4

> Compressor thread may miss notification on stop
> ---
>
> Key: IGNITE-8325
> URL: https://issues.apache.org/jira/browse/IGNITE-8325
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Alexey Goncharuk
>Assignee: Ivan Rakov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> I saw the following hang on TC:
> {code}
> "main" #1 prio=5 os_prio=0 tid=0x7f76b800d000 nid=0x33bf in Object.wait() 
> [0x7f76be6ce000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Thread.join(Thread.java:1245)
>   - locked <0xa50d52e0> (a 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor)
>   at java.lang.Thread.join(Thread.java:1319)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:7688)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.shutdown(FileWriteAheadLogManager.java:1993)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.access$800(FileWriteAheadLogManager.java:1775)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.stop0(FileWriteAheadLogManager.java:520)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.stop(GridCacheSharedManagerAdapter.java:94)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.stop(GridCacheProcessor.java:941)
>   at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2240)
>   at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2118)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2588)
>   - locked <0xa58a3978> (a 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2551)
>   at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:372)
>   at org.apache.ignite.Ignition.stop(Ignition.java:229)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1081)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1124)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1102)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.db.wal.WalCompactionTest.afterTest(WalCompactionTest.java:98)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1687)
>   at 
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.tearDown(GridCommonAbstractTest.java:492)
>   at junit.framework.TestCase.runBare(TestCase.java:146)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:255)
>   at junit.framework.TestSuite.run(TestSuite.java:250)
>   at junit.framework.TestSuite.runTest(TestSuite.java:255)
>   at junit.framework.TestSuite.run(TestSuite.java:250)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:369)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:275)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:239)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:160)
>   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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:206)
>   at 
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:160)
>   at 
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:83)

[jira] [Updated] (IGNITE-7906) Create languages comparison page

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-7906:

Fix Version/s: (was: 2.6)
   2.5

> Create languages comparison page 
> -
>
> Key: IGNITE-7906
> URL: https://issues.apache.org/jira/browse/IGNITE-7906
> Project: Ignite
>  Issue Type: New Feature
>  Components: documentation
>Reporter: Denis Magda
>Priority: Major
> Fix For: 2.5
>
>
> In addition to Java, .NET and C++ thick clients, the community is going to 
> support a variety of thin client for many other languages such as Python, 
> Node.JS, etc. It will be beneficial to create a page that depicts 
> capabilities of every language like this one:
> https://hazelcast.org/clients-languages/



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

[jira] [Assigned] (IGNITE-7906) Create languages comparison page

[Denis Magda (JIRA)]

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

Denis Magda reassigned IGNITE-7906:
---

Assignee: Vladimir Ozerov

> Create languages comparison page 
> -
>
> Key: IGNITE-7906
> URL: https://issues.apache.org/jira/browse/IGNITE-7906
> Project: Ignite
>  Issue Type: New Feature
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.5
>
>
> In addition to Java, .NET and C++ thick clients, the community is going to 
> support a variety of thin client for many other languages such as Python, 
> Node.JS, etc. It will be beneficial to create a page that depicts 
> capabilities of every language like this one:
> https://hazelcast.org/clients-languages/



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

[jira] [Updated] (IGNITE-7587) SQL COPY: document the command

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-7587:

Description: 
SQL COPY command needs to be documented at readme.io.

COPY command is supported for Java API and JDBC only in 2.5

  was:SQL COPY command needs to be documented at readme.io.


> SQL COPY: document the command
> --
>
> Key: IGNITE-7587
> URL: https://issues.apache.org/jira/browse/IGNITE-7587
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, sql
>Affects Versions: 2.4
>Reporter: Kirill Shirokov
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.5
>
>
> SQL COPY command needs to be documented at readme.io.
> COPY command is supported for Java API and JDBC only in 2.5



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

[jira] [Commented] (IGNITE-8077) Implement new JMX metrics for transactions

[Anton Kalashnikov (JIRA)]

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

Anton Kalashnikov commented on IGNITE-8077:
---

TC - 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=projectOverview_IgniteTests24Java8=pull%2F3879%2Fhead

> Implement new JMX metrics for transactions
> --
>
> Key: IGNITE-8077
> URL: https://issues.apache.org/jira/browse/IGNITE-8077
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Dmitriy Govorukhin
>Assignee: Anton Kalashnikov
>Priority: Major
>  Labels: iep-6
> Fix For: 2.5
>
>
> These additional metrics should be implemented to monitor transactions.
> {code}
> class TransactionsMXbean{
> /** The number of transactions which was commited. */
> long getTxCommited();
> /** The number of transactions which was rollbacked. */
> long getTxRolledBack();
> /** The number of transactions holding at least one key lock. */
> long getTxHoldingLock();
> /** The number of keys locked on the node. */
> long getLockedKeys();
> /** The number of transactions for which node is the initiator. */
> int getOwnerTxs();
> }
> {code}
> For more details see in IgniteTxAdapter and IgniteTxManager.



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

[jira] [Commented] (IGNITE-7791) Ignite Client Nodes: failed test IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7791:


[~avinogradov] could you explain what you think can be improved? Could you 
contribute improvement of this fix?

> Ignite Client Nodes: failed test 
> IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()
> ---
>
> Key: IGNITE-7791
> URL: https://issues.apache.org/jira/browse/IGNITE-7791
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
> Attachments: IgniteClientReconnectCacheDelayExchangeTest.java
>
>
> Test is flaky, success rate: 32.4%, test history is 
> [here|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-9174769196124217030=testDetails]
> Reproducible locally.
> Test fails on waiting for disco cache content:
> {noformat}
> junit.framework.AssertionFailedError
>   at junit.framework.Assert.fail(Assert.java:55)
>   at junit.framework.Assert.assertTrue(Assert.java:22)
>   at junit.framework.Assert.assertTrue(Assert.java:31)
>   at junit.framework.TestCase.assertTrue(TestCase.java:201)
>   at 
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.checkCacheDiscoveryData(IgniteClientReconnectCacheTest.java:1414)
>   at 
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated(IgniteClientReconnectCacheTest.java:897)
>   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:745)
> {noformat}
> This fail may be caused by another exception earlier in the log:
> {noformat}
> [2018-02-22 
> 14:32:57,972][ERROR][exchange-worker-#3025%internal.IgniteClientReconnectCacheTest3%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=6, 
> minorTopVer=1], discoEvt=DiscoveryCustomEvent 
> [customMsg=CacheAffinityChangeMessage 
> [id=3cea94db161-760b7b18-b776-4ee7-ae5a-64f9494eaa36, 
> topVer=AffinityTopologyVersion [topVer=3, minorTopVer=0], exchId=null, 
> partsMsg=null, exchangeNeeded=true], affTopVer=AffinityTopologyVersion 
> [topVer=6, minorTopVer=1], super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=1b7f7330-69d8-4bd0-b2e9-71773610, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1519299177395, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], topVer=6, nodeId8=658aeb36, msg=null, 
> type=DISCOVERY_CUSTOM_EVT, tstamp=1519299177971]], nodeId=1b7f7330, 
> evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: 236160867
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$CachesInfo.group(CacheAffinitySharedManager.java:2636)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$8.applyx(CacheAffinitySharedManager.java:989)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$8.applyx(CacheAffinitySharedManager.java:983)
>   at 
> org.apache.ignite.internal.util.lang.IgniteInClosureX.apply(IgniteInClosureX.java:38)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.forAllCacheGroups(CacheAffinitySharedManager.java:1118)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onChangeAffinityMessage(CacheAffinitySharedManager.java:983)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAffinityChangeRequest(GridDhtPartitionsExchangeFuture.java:992)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:648)
>   at 
> 

[jira] [Commented] (IGNITE-8324) Ignite Cache Restarts 1 suite hangs with assertion error

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8324:


GitHub user Jokser opened a pull request:

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

IGNITE-8324 Update discovery cache as well as topology version



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

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

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

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


commit df540e065c34ea80fe6c6e874521cd130879
Author: Pavel Kovalenko 
Date:   2018-04-19T15:12:06Z

IGNITE-8324 Update discovery caches as well as topology version. Remove 
unnecessary `updateTopologies` calls.




> Ignite Cache Restarts 1 suite hangs with assertion error
> 
>
> Key: IGNITE-8324
> URL: https://issues.apache.org/jira/browse/IGNITE-8324
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.4
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> {noformat}
> [ERROR][exchange-worker-#620749%replicated.GridCacheReplicatedNodeRestartSelfTest0%][GridDhtPartitionsExchangeFuture]
>  Failed to notify listener: 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2@6dd7cc93
> java.lang.AssertionError: Invalid topology version [grp=ignite-sys-cache, 
> topVer=AffinityTopologyVersion [topVer=323, minorTopVer=0], 
> exchTopVer=AffinityTopologyVersion [topVer=322, minorTopVer=0], 
> discoCacheVer=AffinityTopologyVersion [topVer=322, minorTopVer=0], 
> exchDiscoCacheVer=AffinityTopologyVersion [topVer=323, minorTopVer=0], 
> fut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent 
> [evtNode=TcpDiscoveryNode [id=48a5d243-7f63-4069-aba1-868c6895, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47503], discPort=47503, order=322, 
> intOrder=163, lastExchangeTime=1524043684082, loc=false, 
> ver=2.5.0#20180417-sha1:56be24b9, isClient=false], topVer=322, 
> nodeId8=b51b3893, msg=Node joined: TcpDiscoveryNode 
> [id=48a5d243-7f63-4069-aba1-868c6895, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47503], discPort=47503, order=322, intOrder=163, 
> lastExchangeTime=1524043684082, loc=false, ver=2.5.0#20180417-sha1:56be24b9, 
> isClient=false], type=NODE_JOINED, tstamp=1524043684166], 
> crd=TcpDiscoveryNode [id=b51b3893-377a-465f-88ea-316a6560, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, 
> intOrder=1, lastExchangeTime=1524043633288, loc=true, 
> ver=2.5.0#20180417-sha1:56be24b9, isClient=false], 
> exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion 
> [topVer=322, minorTopVer=0], discoEvt=DiscoveryEvent 
> [evtNode=TcpDiscoveryNode [id=48a5d243-7f63-4069-aba1-868c6895, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47503], discPort=47503, order=322, 
> intOrder=163, lastExchangeTime=1524043684082, loc=false, 
> ver=2.5.0#20180417-sha1:56be24b9, isClient=false], topVer=322, 
> nodeId8=b51b3893, msg=Node joined: TcpDiscoveryNode 
> [id=48a5d243-7f63-4069-aba1-868c6895, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47503], discPort=47503, order=322, intOrder=163, 
> lastExchangeTime=1524043684082, loc=false, ver=2.5.0#20180417-sha1:56be24b9, 
> isClient=false], type=NODE_JOINED, tstamp=1524043684166], nodeId=48a5d243, 
> evt=NODE_JOINED], added=true, initFut=GridFutureAdapter 
> [ignoreInterrupts=false, state=DONE, res=true, hash=527135060], init=true, 
> lastVer=GridCacheVersion [topVer=135523955, order=1524043694535, 
> nodeOrder=3], partReleaseFut=PartitionReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=322, minorTopVer=0], 
> futures=[ExplicitLockReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=322, minorTopVer=0], futures=[]], AtomicUpdateReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=322, minorTopVer=0], futures=[]], 
> DataStreamerReleaseFuture [topVer=AffinityTopologyVersion [topVer=322, 
> minorTopVer=0], futures=[]], LocalTxReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=322, minorTopVer=0], futures=[]], 
> AllTxReleaseFuture [topVer=AffinityTopologyVersion [topVer=322, 
> minorTopVer=0], futures=[RemoteTxReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=322, minorTopVer=0], futures=[]], 
> exchActions=null, affChangeMsg=null, initTs=1524043684166, 
> centralizedAff=false, forceAffReassignment=false, changeGlobalStateE=null, 
> done=false, state=CRD, 

[jira] [Commented] (IGNITE-8077) Implement new JMX metrics for transactions

[Anton Kalashnikov (JIRA)]

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

Anton Kalashnikov commented on IGNITE-8077:
---

UPsource - [https://reviews.ignite.apache.org/ignite/review/IGNT-CR-578]

> Implement new JMX metrics for transactions
> --
>
> Key: IGNITE-8077
> URL: https://issues.apache.org/jira/browse/IGNITE-8077
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Dmitriy Govorukhin
>Assignee: Anton Kalashnikov
>Priority: Major
>  Labels: iep-6
> Fix For: 2.5
>
>
> These additional metrics should be implemented to monitor transactions.
> {code}
> class TransactionsMXbean{
> /** The number of transactions which was commited. */
> long getTxCommited();
> /** The number of transactions which was rollbacked. */
> long getTxRolledBack();
> /** The number of transactions holding at least one key lock. */
> long getTxHoldingLock();
> /** The number of keys locked on the node. */
> long getLockedKeys();
> /** The number of transactions for which node is the initiator. */
> int getOwnerTxs();
> }
> {code}
> For more details see in IgniteTxAdapter and IgniteTxManager.



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

[jira] [Commented] (IGNITE-8077) Implement new JMX metrics for transactions

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8077:


GitHub user akalash opened a pull request:

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

IGNITE-8077 implemented getTxHoldingLockNum and getLockedKeysNum in 
TxMXBeanImpl



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

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

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

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


commit d5e1457006e042508b7394d38e878fd942851d2e
Author: AMedvedev 
Date:   2018-04-03T02:46:26Z

IGNITE-8077: wip

commit a0eef40e1b270276e1e75d15cb76303c7bcaaa37
Author: AMedvedev 
Date:   2018-04-03T04:33:20Z

IGNITE-8077: simplify

commit 830aeaedd9397835f6cf0fc6da224e4d6a8f014c
Author: Anton Kalashnikov 
Date:   2018-04-19T15:00:13Z

IGNITE-8077 implemented getTxHoldingLockNum and getLockedKeysNum in 
TxMXBeanImpl




> Implement new JMX metrics for transactions
> --
>
> Key: IGNITE-8077
> URL: https://issues.apache.org/jira/browse/IGNITE-8077
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Dmitriy Govorukhin
>Assignee: Anton Kalashnikov
>Priority: Major
>  Labels: iep-6
> Fix For: 2.5
>
>
> These additional metrics should be implemented to monitor transactions.
> {code}
> class TransactionsMXbean{
> /** The number of transactions which was commited. */
> long getTxCommited();
> /** The number of transactions which was rollbacked. */
> long getTxRolledBack();
> /** The number of transactions holding at least one key lock. */
> long getTxHoldingLock();
> /** The number of keys locked on the node. */
> long getLockedKeys();
> /** The number of transactions for which node is the initiator. */
> int getOwnerTxs();
> }
> {code}
> For more details see in IgniteTxAdapter and IgniteTxManager.



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

[jira] [Commented] (IGNITE-8327) Node stop hangs because thread sleep blocks gateway lock

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-8327:
--

Thanks, merged to master and ignite-2.5

> Node stop hangs because thread sleep blocks gateway lock
> 
>
> Key: IGNITE-8327
> URL: https://issues.apache.org/jira/browse/IGNITE-8327
> Project: Ignite
>  Issue Type: Test
>Reporter: Alexey Goncharuk
>Assignee: Ilya Lantukh
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> CacheBaselineTopologyTest#testAffinityAssignmentChangedAfterRestart 
> periodically hangs on TC because the test delay communication SPI blocks 
> thread under gateway lock for 1000 seconds.
> It looks like we can change the delay communication SPI to 
> {{setRebalanceDelay=-1}}.



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

[jira] [Comment Edited] (IGNITE-7791) Ignite Client Nodes: failed test IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov edited comment on IGNITE-7791 at 4/19/18 2:54 PM:
---

Looks like problem is with {{caches.clear();}} inside 
{{org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager#initCachesOnLocalJoin}}.
It causes ignite-sys-cache group descriptor removal.


was (Author: avinogradov):
Looks like problem is with {{caches.clear();}} inside 
{{org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager#initCachesOnLocalJoin}}.
It causes ignite-sys-cache group removal.

> Ignite Client Nodes: failed test 
> IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()
> ---
>
> Key: IGNITE-7791
> URL: https://issues.apache.org/jira/browse/IGNITE-7791
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
> Attachments: IgniteClientReconnectCacheDelayExchangeTest.java
>
>
> Test is flaky, success rate: 32.4%, test history is 
> [here|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-9174769196124217030=testDetails]
> Reproducible locally.
> Test fails on waiting for disco cache content:
> {noformat}
> junit.framework.AssertionFailedError
>   at junit.framework.Assert.fail(Assert.java:55)
>   at junit.framework.Assert.assertTrue(Assert.java:22)
>   at junit.framework.Assert.assertTrue(Assert.java:31)
>   at junit.framework.TestCase.assertTrue(TestCase.java:201)
>   at 
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.checkCacheDiscoveryData(IgniteClientReconnectCacheTest.java:1414)
>   at 
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated(IgniteClientReconnectCacheTest.java:897)
>   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:745)
> {noformat}
> This fail may be caused by another exception earlier in the log:
> {noformat}
> [2018-02-22 
> 14:32:57,972][ERROR][exchange-worker-#3025%internal.IgniteClientReconnectCacheTest3%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=6, 
> minorTopVer=1], discoEvt=DiscoveryCustomEvent 
> [customMsg=CacheAffinityChangeMessage 
> [id=3cea94db161-760b7b18-b776-4ee7-ae5a-64f9494eaa36, 
> topVer=AffinityTopologyVersion [topVer=3, minorTopVer=0], exchId=null, 
> partsMsg=null, exchangeNeeded=true], affTopVer=AffinityTopologyVersion 
> [topVer=6, minorTopVer=1], super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=1b7f7330-69d8-4bd0-b2e9-71773610, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1519299177395, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], topVer=6, nodeId8=658aeb36, msg=null, 
> type=DISCOVERY_CUSTOM_EVT, tstamp=1519299177971]], nodeId=1b7f7330, 
> evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: 236160867
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$CachesInfo.group(CacheAffinitySharedManager.java:2636)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$8.applyx(CacheAffinitySharedManager.java:989)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$8.applyx(CacheAffinitySharedManager.java:983)
>   at 
> org.apache.ignite.internal.util.lang.IgniteInClosureX.apply(IgniteInClosureX.java:38)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.forAllCacheGroups(CacheAffinitySharedManager.java:1118)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onChangeAffinityMessage(CacheAffinitySharedManager.java:983)
>   at 
> 

[jira] [Commented] (IGNITE-7791) Ignite Client Nodes: failed test IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-7791:
--

Looks like problem is with {{caches.clear();}} inside 
{{org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager#initCachesOnLocalJoin}}.
It causes ignite-sys-cache group removal.

> Ignite Client Nodes: failed test 
> IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()
> ---
>
> Key: IGNITE-7791
> URL: https://issues.apache.org/jira/browse/IGNITE-7791
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
> Attachments: IgniteClientReconnectCacheDelayExchangeTest.java
>
>
> Test is flaky, success rate: 32.4%, test history is 
> [here|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-9174769196124217030=testDetails]
> Reproducible locally.
> Test fails on waiting for disco cache content:
> {noformat}
> junit.framework.AssertionFailedError
>   at junit.framework.Assert.fail(Assert.java:55)
>   at junit.framework.Assert.assertTrue(Assert.java:22)
>   at junit.framework.Assert.assertTrue(Assert.java:31)
>   at junit.framework.TestCase.assertTrue(TestCase.java:201)
>   at 
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.checkCacheDiscoveryData(IgniteClientReconnectCacheTest.java:1414)
>   at 
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated(IgniteClientReconnectCacheTest.java:897)
>   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:745)
> {noformat}
> This fail may be caused by another exception earlier in the log:
> {noformat}
> [2018-02-22 
> 14:32:57,972][ERROR][exchange-worker-#3025%internal.IgniteClientReconnectCacheTest3%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=6, 
> minorTopVer=1], discoEvt=DiscoveryCustomEvent 
> [customMsg=CacheAffinityChangeMessage 
> [id=3cea94db161-760b7b18-b776-4ee7-ae5a-64f9494eaa36, 
> topVer=AffinityTopologyVersion [topVer=3, minorTopVer=0], exchId=null, 
> partsMsg=null, exchangeNeeded=true], affTopVer=AffinityTopologyVersion 
> [topVer=6, minorTopVer=1], super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=1b7f7330-69d8-4bd0-b2e9-71773610, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1519299177395, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], topVer=6, nodeId8=658aeb36, msg=null, 
> type=DISCOVERY_CUSTOM_EVT, tstamp=1519299177971]], nodeId=1b7f7330, 
> evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: 236160867
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$CachesInfo.group(CacheAffinitySharedManager.java:2636)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$8.applyx(CacheAffinitySharedManager.java:989)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$8.applyx(CacheAffinitySharedManager.java:983)
>   at 
> org.apache.ignite.internal.util.lang.IgniteInClosureX.apply(IgniteInClosureX.java:38)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.forAllCacheGroups(CacheAffinitySharedManager.java:1118)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onChangeAffinityMessage(CacheAffinitySharedManager.java:983)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAffinityChangeRequest(GridDhtPartitionsExchangeFuture.java:992)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:648)
>   at 
> 

[jira] [Commented] (IGNITE-7791) Ignite Client Nodes: failed test IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-7791:
--

[~dpavlov], [~ilantukh]
Looks NOT good to me. 
Can anybody explain fix?

> Ignite Client Nodes: failed test 
> IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()
> ---
>
> Key: IGNITE-7791
> URL: https://issues.apache.org/jira/browse/IGNITE-7791
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
> Attachments: IgniteClientReconnectCacheDelayExchangeTest.java
>
>
> Test is flaky, success rate: 32.4%, test history is 
> [here|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-9174769196124217030=testDetails]
> Reproducible locally.
> Test fails on waiting for disco cache content:
> {noformat}
> junit.framework.AssertionFailedError
>   at junit.framework.Assert.fail(Assert.java:55)
>   at junit.framework.Assert.assertTrue(Assert.java:22)
>   at junit.framework.Assert.assertTrue(Assert.java:31)
>   at junit.framework.TestCase.assertTrue(TestCase.java:201)
>   at 
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.checkCacheDiscoveryData(IgniteClientReconnectCacheTest.java:1414)
>   at 
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated(IgniteClientReconnectCacheTest.java:897)
>   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:745)
> {noformat}
> This fail may be caused by another exception earlier in the log:
> {noformat}
> [2018-02-22 
> 14:32:57,972][ERROR][exchange-worker-#3025%internal.IgniteClientReconnectCacheTest3%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=6, 
> minorTopVer=1], discoEvt=DiscoveryCustomEvent 
> [customMsg=CacheAffinityChangeMessage 
> [id=3cea94db161-760b7b18-b776-4ee7-ae5a-64f9494eaa36, 
> topVer=AffinityTopologyVersion [topVer=3, minorTopVer=0], exchId=null, 
> partsMsg=null, exchangeNeeded=true], affTopVer=AffinityTopologyVersion 
> [topVer=6, minorTopVer=1], super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=1b7f7330-69d8-4bd0-b2e9-71773610, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1519299177395, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], topVer=6, nodeId8=658aeb36, msg=null, 
> type=DISCOVERY_CUSTOM_EVT, tstamp=1519299177971]], nodeId=1b7f7330, 
> evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: 236160867
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$CachesInfo.group(CacheAffinitySharedManager.java:2636)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$8.applyx(CacheAffinitySharedManager.java:989)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$8.applyx(CacheAffinitySharedManager.java:983)
>   at 
> org.apache.ignite.internal.util.lang.IgniteInClosureX.apply(IgniteInClosureX.java:38)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.forAllCacheGroups(CacheAffinitySharedManager.java:1118)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onChangeAffinityMessage(CacheAffinitySharedManager.java:983)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAffinityChangeRequest(GridDhtPartitionsExchangeFuture.java:992)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:648)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2337)
> 

[jira] [Commented] (IGNITE-8327) Node stop hangs because thread sleep blocks gateway lock

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8327:


GitHub user ilantukh opened a pull request:

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

IGNITE-8327 : Removed delaying CommunicationSpi from test.



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

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

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

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


commit 70db1f31ccaa595b3587dcebb0a272376664fca3
Author: Ilya Lantukh 
Date:   2018-04-06T10:49:10Z

ignite-8327 : Removed delaying CommunicationSpi from test.




> Node stop hangs because thread sleep blocks gateway lock
> 
>
> Key: IGNITE-8327
> URL: https://issues.apache.org/jira/browse/IGNITE-8327
> Project: Ignite
>  Issue Type: Test
>Reporter: Alexey Goncharuk
>Assignee: Ilya Lantukh
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> CacheBaselineTopologyTest#testAffinityAssignmentChangedAfterRestart 
> periodically hangs on TC because the test delay communication SPI blocks 
> thread under gateway lock for 1000 seconds.
> It looks like we can change the delay communication SPI to 
> {{setRebalanceDelay=-1}}.



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

[jira] [Commented] (IGNITE-7791) Ignite Client Nodes: failed test IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7791:


Github user asfgit closed the pull request at:

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


> Ignite Client Nodes: failed test 
> IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()
> ---
>
> Key: IGNITE-7791
> URL: https://issues.apache.org/jira/browse/IGNITE-7791
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
> Attachments: IgniteClientReconnectCacheDelayExchangeTest.java
>
>
> Test is flaky, success rate: 32.4%, test history is 
> [here|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-9174769196124217030=testDetails]
> Reproducible locally.
> Test fails on waiting for disco cache content:
> {noformat}
> junit.framework.AssertionFailedError
>   at junit.framework.Assert.fail(Assert.java:55)
>   at junit.framework.Assert.assertTrue(Assert.java:22)
>   at junit.framework.Assert.assertTrue(Assert.java:31)
>   at junit.framework.TestCase.assertTrue(TestCase.java:201)
>   at 
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.checkCacheDiscoveryData(IgniteClientReconnectCacheTest.java:1414)
>   at 
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated(IgniteClientReconnectCacheTest.java:897)
>   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:745)
> {noformat}
> This fail may be caused by another exception earlier in the log:
> {noformat}
> [2018-02-22 
> 14:32:57,972][ERROR][exchange-worker-#3025%internal.IgniteClientReconnectCacheTest3%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=6, 
> minorTopVer=1], discoEvt=DiscoveryCustomEvent 
> [customMsg=CacheAffinityChangeMessage 
> [id=3cea94db161-760b7b18-b776-4ee7-ae5a-64f9494eaa36, 
> topVer=AffinityTopologyVersion [topVer=3, minorTopVer=0], exchId=null, 
> partsMsg=null, exchangeNeeded=true], affTopVer=AffinityTopologyVersion 
> [topVer=6, minorTopVer=1], super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=1b7f7330-69d8-4bd0-b2e9-71773610, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1519299177395, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], topVer=6, nodeId8=658aeb36, msg=null, 
> type=DISCOVERY_CUSTOM_EVT, tstamp=1519299177971]], nodeId=1b7f7330, 
> evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: 236160867
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$CachesInfo.group(CacheAffinitySharedManager.java:2636)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$8.applyx(CacheAffinitySharedManager.java:989)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$8.applyx(CacheAffinitySharedManager.java:983)
>   at 
> org.apache.ignite.internal.util.lang.IgniteInClosureX.apply(IgniteInClosureX.java:38)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.forAllCacheGroups(CacheAffinitySharedManager.java:1118)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onChangeAffinityMessage(CacheAffinitySharedManager.java:983)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAffinityChangeRequest(GridDhtPartitionsExchangeFuture.java:992)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:648)
>   at 
> 

[jira] [Updated] (IGNITE-8327) Node stop hangs because thread sleep blocks gateway lock

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-8327:
---
Labels: MakeTeamcityGreenAgain  (was: )

> Node stop hangs because thread sleep blocks gateway lock
> 
>
> Key: IGNITE-8327
> URL: https://issues.apache.org/jira/browse/IGNITE-8327
> Project: Ignite
>  Issue Type: Test
>Reporter: Alexey Goncharuk
>Assignee: Ilya Lantukh
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> CacheBaselineTopologyTest#testAffinityAssignmentChangedAfterRestart 
> periodically hangs on TC because the test delay communication SPI blocks 
> thread under gateway lock for 1000 seconds.
> It looks like we can change the delay communication SPI to 
> {{setRebalanceDelay=-1}}.



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

[jira] [Assigned] (IGNITE-8327) Node stop hangs because thread sleep blocks gateway lock

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh reassigned IGNITE-8327:


Assignee: Ilya Lantukh

> Node stop hangs because thread sleep blocks gateway lock
> 
>
> Key: IGNITE-8327
> URL: https://issues.apache.org/jira/browse/IGNITE-8327
> Project: Ignite
>  Issue Type: Test
>Reporter: Alexey Goncharuk
>Assignee: Ilya Lantukh
>Priority: Major
>
> CacheBaselineTopologyTest#testAffinityAssignmentChangedAfterRestart 
> periodically hangs on TC because the test delay communication SPI blocks 
> thread under gateway lock for 1000 seconds.
> It looks like we can change the delay communication SPI to 
> {{setRebalanceDelay=-1}}.



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

[jira] [Commented] (IGNITE-8134) Services can't be deployed on servers outside of baseline topology

[Dmitriy Govorukhin (JIRA)]

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

Dmitriy Govorukhin commented on IGNITE-8134:


[~dmekhanikov] Looks good for me, please merge.

> Services can't be deployed on servers outside of baseline topology
> --
>
> Key: IGNITE-8134
> URL: https://issues.apache.org/jira/browse/IGNITE-8134
> Project: Ignite
>  Issue Type: Bug
>  Components: managed services, persistence
>Affects Versions: 2.4
>Reporter: Stanislav Lukyanov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.6
>
>
> If a node is not a part of the baseline topology, the services will never be 
> deployed on it. In particular, if that node calls a synchronous deploy* 
> method, the method will hang.
>  After the node is added to the baseline, all previously initiated 
> deployments succeed (and deploy* methods return).
> It seems that the issue is with the continuous query started by the 
> GridServiceProcessor on the ignite-sys-cache.
> Example:
>  =
> {code}
> public class BltServicesBug {
> public static void main(String[] args) {
> // start one node
> IgniteConfiguration cfg1 = new IgniteConfiguration()
> .setIgniteInstanceName("node1")
> .setDataStorageConfiguration(
> new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(
> new DataRegionConfiguration()
> .setPersistenceEnabled(true)
> )
> );
> try (Ignite ignite1 = Ignition.start(cfg1)) {
> // activate and set baseline topology
> ignite1.cluster().active(true);
> // start another node
> IgniteConfiguration cfg2 = new IgniteConfiguration(cfg1)
> .setIgniteInstanceName("node2");
> try (Ignite ignite2 = Ignition.start(cfg2)) { 
> // try to deploy a service; 
> // this call hangs until the second node is added to the BLT 
> (e.g. externally via control.sh) 
> ignite2.services().deployNodeSingleton("myService", new 
> MyServiceImpl()); System.out.println("> Deployed"); }
> }
> }
> private static class MyServiceImpl implements Service {
> @Override public void cancel(ServiceContext ctx) { }
> @Override public void init(ServiceContext ctx) { }
> @Override public void execute(ServiceContext ctx) { }
> }
> }
> }
> {code}
>  =



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

[jira] [Created] (IGNITE-8327) Node stop hangs because thread sleep blocks gateway lock

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-8327:


 Summary: Node stop hangs because thread sleep blocks gateway lock
 Key: IGNITE-8327
 URL: https://issues.apache.org/jira/browse/IGNITE-8327
 Project: Ignite
  Issue Type: Test
Reporter: Alexey Goncharuk


CacheBaselineTopologyTest#testAffinityAssignmentChangedAfterRestart 
periodically hangs on TC because the test delay communication SPI blocks thread 
under gateway lock for 1000 seconds.

It looks like we can change the delay communication SPI to 
{{setRebalanceDelay=-1}}.



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

[jira] [Commented] (IGNITE-7791) Ignite Client Nodes: failed test IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh commented on IGNITE-7791:
--

Looks OK.

> Ignite Client Nodes: failed test 
> IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()
> ---
>
> Key: IGNITE-7791
> URL: https://issues.apache.org/jira/browse/IGNITE-7791
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
> Attachments: IgniteClientReconnectCacheDelayExchangeTest.java
>
>
> Test is flaky, success rate: 32.4%, test history is 
> [here|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-9174769196124217030=testDetails]
> Reproducible locally.
> Test fails on waiting for disco cache content:
> {noformat}
> junit.framework.AssertionFailedError
>   at junit.framework.Assert.fail(Assert.java:55)
>   at junit.framework.Assert.assertTrue(Assert.java:22)
>   at junit.framework.Assert.assertTrue(Assert.java:31)
>   at junit.framework.TestCase.assertTrue(TestCase.java:201)
>   at 
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.checkCacheDiscoveryData(IgniteClientReconnectCacheTest.java:1414)
>   at 
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated(IgniteClientReconnectCacheTest.java:897)
>   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:745)
> {noformat}
> This fail may be caused by another exception earlier in the log:
> {noformat}
> [2018-02-22 
> 14:32:57,972][ERROR][exchange-worker-#3025%internal.IgniteClientReconnectCacheTest3%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=6, 
> minorTopVer=1], discoEvt=DiscoveryCustomEvent 
> [customMsg=CacheAffinityChangeMessage 
> [id=3cea94db161-760b7b18-b776-4ee7-ae5a-64f9494eaa36, 
> topVer=AffinityTopologyVersion [topVer=3, minorTopVer=0], exchId=null, 
> partsMsg=null, exchangeNeeded=true], affTopVer=AffinityTopologyVersion 
> [topVer=6, minorTopVer=1], super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=1b7f7330-69d8-4bd0-b2e9-71773610, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1519299177395, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], topVer=6, nodeId8=658aeb36, msg=null, 
> type=DISCOVERY_CUSTOM_EVT, tstamp=1519299177971]], nodeId=1b7f7330, 
> evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: 236160867
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$CachesInfo.group(CacheAffinitySharedManager.java:2636)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$8.applyx(CacheAffinitySharedManager.java:989)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$8.applyx(CacheAffinitySharedManager.java:983)
>   at 
> org.apache.ignite.internal.util.lang.IgniteInClosureX.apply(IgniteInClosureX.java:38)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.forAllCacheGroups(CacheAffinitySharedManager.java:1118)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onChangeAffinityMessage(CacheAffinitySharedManager.java:983)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAffinityChangeRequest(GridDhtPartitionsExchangeFuture.java:992)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:648)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2337)
>   at 
> 

[jira] [Assigned] (IGNITE-8220) Discovery worker termination in PDS test

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk reassigned IGNITE-8220:


Assignee: Alexey Goncharuk  (was: Andrey Gura)

> Discovery worker termination in PDS test
> 
>
> Key: IGNITE-8220
> URL: https://issues.apache.org/jira/browse/IGNITE-8220
> Project: Ignite
>  Issue Type: Test
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Alexey Goncharuk
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.5
>
>
> 3 suites failed 
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgnitePds1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PdsDirectIo1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ActivateDeactivateCluster_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> Example of tests failed:
> - IgniteClusterActivateDeactivateTestWithPersistence.testActivateFailover3
> - IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateFailover3  
> {noformat}
> [2018-04-11 
> 02:43:09,769][ERROR][tcp-disco-srvr-#2298%cache.IgniteClusterActivateDeactivateTestWithPersistence0%][IgniteTestResources]
>  Critical failure. Will be handled accordingly to configured handler 
> [hnd=class o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext 
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Thread 
> tcp-disco-srvr-#2298%cache.IgniteClusterActivateDeactivateTestWithPersistence0%
>  is terminated unexpectedly.]] 
> {noformat}



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

[jira] [Created] (IGNITE-8326) Can't execute SQL query for create index

[Stepanov Mikhail (JIRA)]

Stepanov Mikhail created IGNITE-8326:


 Summary: Can't execute SQL query for create index
 Key: IGNITE-8326
 URL: https://issues.apache.org/jira/browse/IGNITE-8326
 Project: Ignite
  Issue Type: Bug
Reporter: Stepanov Mikhail


I try to execute SQL query
{code:java}
CREATE INDEX IF NOT EXISTS "personNameIndex" ON "person" ("name");{code}
using method 
{code:java}
cache.query(query).getColumnsCount(){code}
and this call is never ends, because it contains semicolon.

 

See the code in org.apache.ignite.internal.sql.command.SqlCreateIndexCommand 
method parseIndexProperties. This method doesn't break when tokenType is 
SEMICOLON, but break when tokenType is EOF



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

[jira] [Updated] (IGNITE-8077) Implement new JMX metrics for transactions

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-8077:
-
Fix Version/s: 2.5

> Implement new JMX metrics for transactions
> --
>
> Key: IGNITE-8077
> URL: https://issues.apache.org/jira/browse/IGNITE-8077
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Dmitriy Govorukhin
>Assignee: Anton Kalashnikov
>Priority: Major
>  Labels: iep-6
> Fix For: 2.5
>
>
> These additional metrics should be implemented to monitor transactions.
> {code}
> class TransactionsMXbean{
> /** The number of transactions which was commited. */
> long getTxCommited();
> /** The number of transactions which was rollbacked. */
> long getTxRolledBack();
> /** The number of transactions holding at least one key lock. */
> long getTxHoldingLock();
> /** The number of keys locked on the node. */
> long getLockedKeys();
> /** The number of transactions for which node is the initiator. */
> int getOwnerTxs();
> }
> {code}
> For more details see in IgniteTxAdapter and IgniteTxManager.



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

[jira] [Updated] (IGNITE-8220) Discovery worker termination in PDS test

[Andrey Gura (JIRA)]

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

Andrey Gura updated IGNITE-8220:

Fix Version/s: (was: 2.6)
   2.5

> Discovery worker termination in PDS test
> 
>
> Key: IGNITE-8220
> URL: https://issues.apache.org/jira/browse/IGNITE-8220
> Project: Ignite
>  Issue Type: Test
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Andrey Gura
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.5
>
>
> 3 suites failed 
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgnitePds1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PdsDirectIo1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ActivateDeactivateCluster_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> Example of tests failed:
> - IgniteClusterActivateDeactivateTestWithPersistence.testActivateFailover3
> - IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateFailover3  
> {noformat}
> [2018-04-11 
> 02:43:09,769][ERROR][tcp-disco-srvr-#2298%cache.IgniteClusterActivateDeactivateTestWithPersistence0%][IgniteTestResources]
>  Critical failure. Will be handled accordingly to configured handler 
> [hnd=class o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext 
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Thread 
> tcp-disco-srvr-#2298%cache.IgniteClusterActivateDeactivateTestWithPersistence0%
>  is terminated unexpectedly.]] 
> {noformat}



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

[jira] [Commented] (IGNITE-7691) Provide info about DECIMAL column scale and precision

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-7691:
-

[~vozerov]

As far as I can see there is no backward compatibility described in thin client 
protocol [1].
Actually, the documentation said opposite thing, you must ensure that your 
client and your server are compatible.

{quote}
The first message upon connection establishment must be a handshake. Handshake 
ensures that client and server versions are compatible.
{quote}

I'm really confused here.

[1] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-9+Thin+Client+Protocol#IEP-9ThinClientProtocol-ClientOperations

> Provide info about DECIMAL column scale and precision
> -
>
> Key: IGNITE-7691
> URL: https://issues.apache.org/jira/browse/IGNITE-7691
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.4
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Minor
> Fix For: 2.6
>
>
> Currently, it impossible to obtain scale and precision of DECIMAL column from 
> sql table metadata.
> Ignite should provide those type of meta information.



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

[jira] [Commented] (IGNITE-8295) Possible deadlock on partition eviction.

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh commented on IGNITE-8295:
--

Changes look good to me. Regarding your TODO - we don't need to log WAL record 
for partition re-creation, because we log partition state changes, which are 
enough to understand that store is inconsistent.

> Possible deadlock on partition eviction.
> 
>
> Key: IGNITE-8295
> URL: https://issues.apache.org/jira/browse/IGNITE-8295
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Major
> Fix For: 2.6
>
> Attachments: deadlock.stack
>
>
> GridCacheOffheapManager.recreateCacheDataStore() calls 
> updatePartitionCounter() under partStoreLock which may try to acquire 
> checkpointReadLock.
> recreateCacheDataStore() method can be called with checkpointReadLock (on 
> GridDhtPartitionsExchangeFuture.updatePartitionFullMap) 
> or without checkpointReadLock (GridDhtPartitionEvictor thread calls 
> evictPartitionAsync),
> So, checkpoint can cause a deadlock if it happens in between.
> Seems, we should acquire checkpointReadLock before partStoreLock. 
>   



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

[jira] [Assigned] (IGNITE-6587) Ignite watchdog service

[Andrey Gura (JIRA)]

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

Andrey Gura reassigned IGNITE-6587:
---

Assignee: Andrey Gura

> Ignite watchdog service
> ---
>
> Key: IGNITE-6587
> URL: https://issues.apache.org/jira/browse/IGNITE-6587
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>Assignee: Andrey Gura
>Priority: Major
>  Labels: IEP-5
> Fix For: 2.6
>
> Attachments: watchdog.sh
>
>
> We need to come up with a 'watchdog service' to monitor for Ignite node local 
> health and kill the process under some critical conditions.
> For example, if one of the mission-critical Ignite threads die, the Ignite 
> node must be stopped.
> At the first glance, the list of critical threads is:
> disco-event-worker
> tcp-disco-sock-reader
> tcp-disco-srvr
> tcp-disco-msg-worker
> tcp-comm-worker
> grid-nio-worker-tcp-comm
> exchange-worker
> sys-stripe
> grid-timeout-worker
> db-checkpoint-thread
> wal-file-archiver
> ttl-cleanup-worker
> nio-acceptor
> The mechanism should support pluggable components so that self-check can be 
> extended via plugins.



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

[jira] [Commented] (IGNITE-8325) Compressor thread may miss notification on stop

[Ivan Rakov (JIRA)]

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

Ivan Rakov commented on IGNITE-8325:


TC: https://ci.ignite.apache.org/viewLog.html?buildId=1227401

> Compressor thread may miss notification on stop
> ---
>
> Key: IGNITE-8325
> URL: https://issues.apache.org/jira/browse/IGNITE-8325
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Ivan Rakov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> I saw the following hang on TC:
> {code}
> "main" #1 prio=5 os_prio=0 tid=0x7f76b800d000 nid=0x33bf in Object.wait() 
> [0x7f76be6ce000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Thread.join(Thread.java:1245)
>   - locked <0xa50d52e0> (a 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor)
>   at java.lang.Thread.join(Thread.java:1319)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:7688)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.shutdown(FileWriteAheadLogManager.java:1993)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.access$800(FileWriteAheadLogManager.java:1775)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.stop0(FileWriteAheadLogManager.java:520)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.stop(GridCacheSharedManagerAdapter.java:94)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.stop(GridCacheProcessor.java:941)
>   at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2240)
>   at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2118)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2588)
>   - locked <0xa58a3978> (a 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2551)
>   at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:372)
>   at org.apache.ignite.Ignition.stop(Ignition.java:229)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1081)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1124)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1102)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.db.wal.WalCompactionTest.afterTest(WalCompactionTest.java:98)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1687)
>   at 
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.tearDown(GridCommonAbstractTest.java:492)
>   at junit.framework.TestCase.runBare(TestCase.java:146)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:255)
>   at junit.framework.TestSuite.run(TestSuite.java:250)
>   at junit.framework.TestSuite.runTest(TestSuite.java:255)
>   at junit.framework.TestSuite.run(TestSuite.java:250)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:369)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:275)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:239)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:160)
>   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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:206)
>   at 
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:160)
>   at 
> 

[jira] [Commented] (IGNITE-8325) Compressor thread may miss notification on stop

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8325:


GitHub user glukos opened a pull request:

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

IGNITE-8325 Compressor thread may miss notification on stop



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

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

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

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


commit d5916da01a041a870a930c90134dd95b8d2030f5
Author: Ivan Rakov 
Date:   2018-04-19T13:38:39Z

IGNITE-8325 Compressor thread may miss notification on stop




> Compressor thread may miss notification on stop
> ---
>
> Key: IGNITE-8325
> URL: https://issues.apache.org/jira/browse/IGNITE-8325
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Ivan Rakov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> I saw the following hang on TC:
> {code}
> "main" #1 prio=5 os_prio=0 tid=0x7f76b800d000 nid=0x33bf in Object.wait() 
> [0x7f76be6ce000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Thread.join(Thread.java:1245)
>   - locked <0xa50d52e0> (a 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor)
>   at java.lang.Thread.join(Thread.java:1319)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:7688)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.shutdown(FileWriteAheadLogManager.java:1993)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.access$800(FileWriteAheadLogManager.java:1775)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.stop0(FileWriteAheadLogManager.java:520)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.stop(GridCacheSharedManagerAdapter.java:94)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.stop(GridCacheProcessor.java:941)
>   at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2240)
>   at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2118)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2588)
>   - locked <0xa58a3978> (a 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2551)
>   at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:372)
>   at org.apache.ignite.Ignition.stop(Ignition.java:229)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1081)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1124)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1102)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.db.wal.WalCompactionTest.afterTest(WalCompactionTest.java:98)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1687)
>   at 
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.tearDown(GridCommonAbstractTest.java:492)
>   at junit.framework.TestCase.runBare(TestCase.java:146)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:255)
>   at junit.framework.TestSuite.run(TestSuite.java:250)
>   at junit.framework.TestSuite.runTest(TestSuite.java:255)
>   at junit.framework.TestSuite.run(TestSuite.java:250)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:369)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:275)
>   at 
> 

[jira] [Updated] (IGNITE-8325) Compressor thread may miss notification on stop

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-8325:
-
Fix Version/s: 2.5

> Compressor thread may miss notification on stop
> ---
>
> Key: IGNITE-8325
> URL: https://issues.apache.org/jira/browse/IGNITE-8325
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Ivan Rakov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> I saw the following hang on TC:
> {code}
> "main" #1 prio=5 os_prio=0 tid=0x7f76b800d000 nid=0x33bf in Object.wait() 
> [0x7f76be6ce000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Thread.join(Thread.java:1245)
>   - locked <0xa50d52e0> (a 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor)
>   at java.lang.Thread.join(Thread.java:1319)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:7688)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.shutdown(FileWriteAheadLogManager.java:1993)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.access$800(FileWriteAheadLogManager.java:1775)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.stop0(FileWriteAheadLogManager.java:520)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.stop(GridCacheSharedManagerAdapter.java:94)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.stop(GridCacheProcessor.java:941)
>   at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2240)
>   at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2118)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2588)
>   - locked <0xa58a3978> (a 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2551)
>   at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:372)
>   at org.apache.ignite.Ignition.stop(Ignition.java:229)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1081)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1124)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1102)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.db.wal.WalCompactionTest.afterTest(WalCompactionTest.java:98)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1687)
>   at 
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.tearDown(GridCommonAbstractTest.java:492)
>   at junit.framework.TestCase.runBare(TestCase.java:146)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:255)
>   at junit.framework.TestSuite.run(TestSuite.java:250)
>   at junit.framework.TestSuite.runTest(TestSuite.java:255)
>   at junit.framework.TestSuite.run(TestSuite.java:250)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:369)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:275)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:239)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:160)
>   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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:206)
>   at 
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:160)
>   at 
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:83)
>   at 
> 

[jira] [Updated] (IGNITE-8325) Compressor thread may miss notification on stop

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-8325:
-
Labels: MakeTeamcityGreenAgain  (was: )

> Compressor thread may miss notification on stop
> ---
>
> Key: IGNITE-8325
> URL: https://issues.apache.org/jira/browse/IGNITE-8325
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Ivan Rakov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> I saw the following hang on TC:
> {code}
> "main" #1 prio=5 os_prio=0 tid=0x7f76b800d000 nid=0x33bf in Object.wait() 
> [0x7f76be6ce000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Thread.join(Thread.java:1245)
>   - locked <0xa50d52e0> (a 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor)
>   at java.lang.Thread.join(Thread.java:1319)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:7688)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.shutdown(FileWriteAheadLogManager.java:1993)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.access$800(FileWriteAheadLogManager.java:1775)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.stop0(FileWriteAheadLogManager.java:520)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.stop(GridCacheSharedManagerAdapter.java:94)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.stop(GridCacheProcessor.java:941)
>   at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2240)
>   at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2118)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2588)
>   - locked <0xa58a3978> (a 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2551)
>   at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:372)
>   at org.apache.ignite.Ignition.stop(Ignition.java:229)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1081)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1124)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1102)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.db.wal.WalCompactionTest.afterTest(WalCompactionTest.java:98)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1687)
>   at 
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.tearDown(GridCommonAbstractTest.java:492)
>   at junit.framework.TestCase.runBare(TestCase.java:146)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:255)
>   at junit.framework.TestSuite.run(TestSuite.java:250)
>   at junit.framework.TestSuite.runTest(TestSuite.java:255)
>   at junit.framework.TestSuite.run(TestSuite.java:250)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:369)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:275)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:239)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:160)
>   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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:206)
>   at 
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:160)
>   at 
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:83)
>   

[jira] [Created] (IGNITE-8325) Compressor thread may miss notification on stop

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-8325:


 Summary: Compressor thread may miss notification on stop
 Key: IGNITE-8325
 URL: https://issues.apache.org/jira/browse/IGNITE-8325
 Project: Ignite
  Issue Type: Bug
Reporter: Alexey Goncharuk
Assignee: Alexey Goncharuk


I saw the following hang on TC:

{code}
"main" #1 prio=5 os_prio=0 tid=0x7f76b800d000 nid=0x33bf in Object.wait() 
[0x7f76be6ce000]
   java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Thread.join(Thread.java:1245)
- locked <0xa50d52e0> (a 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor)
at java.lang.Thread.join(Thread.java:1319)
at 
org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:7688)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.shutdown(FileWriteAheadLogManager.java:1993)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.access$800(FileWriteAheadLogManager.java:1775)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.stop0(FileWriteAheadLogManager.java:520)
at 
org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.stop(GridCacheSharedManagerAdapter.java:94)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.stop(GridCacheProcessor.java:941)
at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2240)
at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2118)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2588)
- locked <0xa58a3978> (a 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2551)
at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:372)
at org.apache.ignite.Ignition.stop(Ignition.java:229)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1081)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1124)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1102)
at 
org.apache.ignite.internal.processors.cache.persistence.db.wal.WalCompactionTest.afterTest(WalCompactionTest.java:98)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1687)
at 
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.tearDown(GridCommonAbstractTest.java:492)
at junit.framework.TestCase.runBare(TestCase.java:146)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:369)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:275)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:239)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:160)
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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:206)
at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:160)
at 
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:83)
at 
org.apache.maven.plugin.surefire.InPluginVMSurefireStarter.runSuitesInProcess(InPluginVMSurefireStarter.java:84)
at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1107)
at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:954)

[jira] [Assigned] (IGNITE-8325) Compressor thread may miss notification on stop

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk reassigned IGNITE-8325:


Assignee: Ivan Rakov  (was: Alexey Goncharuk)

> Compressor thread may miss notification on stop
> ---
>
> Key: IGNITE-8325
> URL: https://issues.apache.org/jira/browse/IGNITE-8325
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Ivan Rakov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> I saw the following hang on TC:
> {code}
> "main" #1 prio=5 os_prio=0 tid=0x7f76b800d000 nid=0x33bf in Object.wait() 
> [0x7f76be6ce000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Thread.join(Thread.java:1245)
>   - locked <0xa50d52e0> (a 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor)
>   at java.lang.Thread.join(Thread.java:1319)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:7688)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.shutdown(FileWriteAheadLogManager.java:1993)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.access$800(FileWriteAheadLogManager.java:1775)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.stop0(FileWriteAheadLogManager.java:520)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.stop(GridCacheSharedManagerAdapter.java:94)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.stop(GridCacheProcessor.java:941)
>   at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2240)
>   at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2118)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2588)
>   - locked <0xa58a3978> (a 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2551)
>   at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:372)
>   at org.apache.ignite.Ignition.stop(Ignition.java:229)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1081)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1124)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1102)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.db.wal.WalCompactionTest.afterTest(WalCompactionTest.java:98)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1687)
>   at 
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.tearDown(GridCommonAbstractTest.java:492)
>   at junit.framework.TestCase.runBare(TestCase.java:146)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:255)
>   at junit.framework.TestSuite.run(TestSuite.java:250)
>   at junit.framework.TestSuite.runTest(TestSuite.java:255)
>   at junit.framework.TestSuite.run(TestSuite.java:250)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:369)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:275)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:239)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:160)
>   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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:206)
>   at 
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:160)
>   at 
> 

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

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh commented on IGNITE-5553:
--

[~xtern], sorry for late reply.
New solution also have problems (explained in Upsource). We need to think about 
other possible approaches. I'll think for a while and summarize my thoughts on 
dev list. Feel free to share your ideas as well.

> 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.6
>
>
> 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] [Comment Edited] (IGNITE-5553) Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh edited comment on IGNITE-5553 at 4/19/18 1:25 PM:
---

[~xtern], sorry for late reply.
New solution also has problems (explained in Upsource). We need to think about 
other possible approaches. I'll think for a while and summarize my thoughts on 
dev list. Feel free to share your ideas as well.


was (Author: ilantukh):
[~xtern], sorry for late reply.
New solution also have problems (explained in Upsource). We need to think about 
other possible approaches. I'll think for a while and summarize my thoughts on 
dev list. Feel free to share your ideas as well.

> 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.6
>
>
> 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-8017) Disable WAL during initial preloading

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8017:


[~ilantukh], thank you for your research. Let's see if test will be statble.

> Disable WAL during initial preloading
> -
>
> Key: IGNITE-8017
> URL: https://issues.apache.org/jira/browse/IGNITE-8017
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
>  Labels: iep-16
> Fix For: 2.5
>
>
> While handling SupplyMessage, node handles each supplied data entry 
> separately, which causes a WAL record for each entry to be written. It 
> significantly limits preloading speed.
> We can improve rebalancing speed and reduce pressure on disk by disabling WAL 
> until all data is loaded. The disadvantage of this approach is that data 
> might get corrupted if node crashes - but node that crashed during preloading 
> has to clear all it's data anyway. However, it is important to distinguish 
> situations when new node joined cluster or added to baseline topology (and 
> doesn't hold any data) and when additional partitions got assigned to node 
> after baseline topology changed (in this case node has to keep all data in 
> consistent state).



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

[jira] [Commented] (IGNITE-8092) Put operation may hang if cache was destroyed asynchronously.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8092:


GitHub user xtern opened a pull request:

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

IGNITE-8092 Put hang on destroy.



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

$ git pull https://github.com/xtern/ignite IGNITE-8092

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

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


commit 14c62b87992013faf849d9d39f4a7bf9f0bdd715
Author: pereslegin-pa 
Date:   2018-04-19T13:06:59Z

IGNITE-8092 Put hang on destroy.




> Put operation may hang if cache was destroyed asynchronously.
> -
>
> Key: IGNITE-8092
> URL: https://issues.apache.org/jira/browse/IGNITE-8092
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.4
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>
> If there is more than one cache in the cache group then put operation on 
> cache may hang if it was destroyed asynchronously.
> For now this applies to all cache modes (PARTITIONED/REPLICATED/LOCAL) and to 
> all atomicity modes (ATOMIC/TRANSACTIONAL).
> This problem can not be reproduced if there is only one cache in the cache 
> group.
> Reproducer:
> {code:java}
> public class DestroyCacheTest extends GridCommonAbstractTest {
> private CacheConfiguration ccfg(String name, String 
> grp) {
> return new CacheConfiguration Boolean>(name).setCacheMode(CacheMode.PARTITIONED)
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
> 
> .setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC)
> .setGroupName(grp);
> }
> public void testDestroyAsync() throws Exception {
> String grpName = "testGroup";
> try (IgniteEx node = startGrid(0)) {
> node.createCache(ccfg("cache2", grpName));
> for (int n = 0; n < 100; n++) {
> IgniteCache cache1 = 
> node.createCache(ccfg("cache1", grpName));
> AtomicInteger cntr = new AtomicInteger();
> GridTestUtils.runMultiThreadedAsync(() -> {
> try {
> int key;
> while ((key = cntr.getAndIncrement()) < 10_000) {
> if (key == 1000)
> cache1.destroy();
> cache1.putIfAbsent(key, true);
> }
> }
> catch (Exception ignore) {
> log.warning(ignore.getMessage());
> }
> return null;
> }, 6, "put-thread").get();
> }
> }
> }
> }
> {code}
> p.s. for ATOMIC cache additional cache status check in 
> GridCacheGateway#onStopped busy wait resolve this problem.



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

[jira] [Commented] (IGNITE-8219) B+Tree operation may result in an infinite loop in some case

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh commented on IGNITE-8219:
--

Changes look good to me.

>  B+Tree operation may result in an infinite loop in some case
> -
>
> Key: IGNITE-8219
> URL: https://issues.apache.org/jira/browse/IGNITE-8219
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Alexey Stelmak
>Assignee: Alexey Stelmak
>Priority: Major
> Fix For: 2.5
>
>
> B+Tree operation may result in an infinite loop in case. Test 
> DynamicIndexServerCoordinatorBasicSelfTest#testCreateIndexWithInlineSizePartitionedAtomic
>  region size = 512Mb, KEY_BEFORE=1, KEY_AFTER=2



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

[jira] [Commented] (IGNITE-8017) Disable WAL during initial preloading

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh commented on IGNITE-8017:
--

[~dpavlov],

Issue with 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-4459509243019188454=%3Cdefault%3E=testDetails
 is not related to new functionality and already has been fixed in master.

> Disable WAL during initial preloading
> -
>
> Key: IGNITE-8017
> URL: https://issues.apache.org/jira/browse/IGNITE-8017
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
>  Labels: iep-16
> Fix For: 2.5
>
>
> While handling SupplyMessage, node handles each supplied data entry 
> separately, which causes a WAL record for each entry to be written. It 
> significantly limits preloading speed.
> We can improve rebalancing speed and reduce pressure on disk by disabling WAL 
> until all data is loaded. The disadvantage of this approach is that data 
> might get corrupted if node crashes - but node that crashed during preloading 
> has to clear all it's data anyway. However, it is important to distinguish 
> situations when new node joined cluster or added to baseline topology (and 
> doesn't hold any data) and when additional partitions got assigned to node 
> after baseline topology changed (in this case node has to keep all data in 
> consistent state).



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

[jira] [Created] (IGNITE-8324) Ignite Cache Restarts 1 suite hangs with assertion error

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-8324:
---

 Summary: Ignite Cache Restarts 1 suite hangs with assertion error
 Key: IGNITE-8324
 URL: https://issues.apache.org/jira/browse/IGNITE-8324
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.4
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko
 Fix For: 2.5


{noformat}
[ERROR][exchange-worker-#620749%replicated.GridCacheReplicatedNodeRestartSelfTest0%][GridDhtPartitionsExchangeFuture]
 Failed to notify listener: 
o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2@6dd7cc93
java.lang.AssertionError: Invalid topology version [grp=ignite-sys-cache, 
topVer=AffinityTopologyVersion [topVer=323, minorTopVer=0], 
exchTopVer=AffinityTopologyVersion [topVer=322, minorTopVer=0], 
discoCacheVer=AffinityTopologyVersion [topVer=322, minorTopVer=0], 
exchDiscoCacheVer=AffinityTopologyVersion [topVer=323, minorTopVer=0], 
fut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent 
[evtNode=TcpDiscoveryNode [id=48a5d243-7f63-4069-aba1-868c6895, 
addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47503], discPort=47503, order=322, 
intOrder=163, lastExchangeTime=1524043684082, loc=false, 
ver=2.5.0#20180417-sha1:56be24b9, isClient=false], topVer=322, 
nodeId8=b51b3893, msg=Node joined: TcpDiscoveryNode 
[id=48a5d243-7f63-4069-aba1-868c6895, addrs=[127.0.0.1], 
sockAddrs=[/127.0.0.1:47503], discPort=47503, order=322, intOrder=163, 
lastExchangeTime=1524043684082, loc=false, ver=2.5.0#20180417-sha1:56be24b9, 
isClient=false], type=NODE_JOINED, tstamp=1524043684166], crd=TcpDiscoveryNode 
[id=b51b3893-377a-465f-88ea-316a6560, addrs=[127.0.0.1], 
sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
lastExchangeTime=1524043633288, loc=true, ver=2.5.0#20180417-sha1:56be24b9, 
isClient=false], exchId=GridDhtPartitionExchangeId 
[topVer=AffinityTopologyVersion [topVer=322, minorTopVer=0], 
discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
[id=48a5d243-7f63-4069-aba1-868c6895, addrs=[127.0.0.1], 
sockAddrs=[/127.0.0.1:47503], discPort=47503, order=322, intOrder=163, 
lastExchangeTime=1524043684082, loc=false, ver=2.5.0#20180417-sha1:56be24b9, 
isClient=false], topVer=322, nodeId8=b51b3893, msg=Node joined: 
TcpDiscoveryNode [id=48a5d243-7f63-4069-aba1-868c6895, addrs=[127.0.0.1], 
sockAddrs=[/127.0.0.1:47503], discPort=47503, order=322, intOrder=163, 
lastExchangeTime=1524043684082, loc=false, ver=2.5.0#20180417-sha1:56be24b9, 
isClient=false], type=NODE_JOINED, tstamp=1524043684166], nodeId=48a5d243, 
evt=NODE_JOINED], added=true, initFut=GridFutureAdapter 
[ignoreInterrupts=false, state=DONE, res=true, hash=527135060], init=true, 
lastVer=GridCacheVersion [topVer=135523955, order=1524043694535, nodeOrder=3], 
partReleaseFut=PartitionReleaseFuture [topVer=AffinityTopologyVersion 
[topVer=322, minorTopVer=0], futures=[ExplicitLockReleaseFuture 
[topVer=AffinityTopologyVersion [topVer=322, minorTopVer=0], futures=[]], 
AtomicUpdateReleaseFuture [topVer=AffinityTopologyVersion [topVer=322, 
minorTopVer=0], futures=[]], DataStreamerReleaseFuture 
[topVer=AffinityTopologyVersion [topVer=322, minorTopVer=0], futures=[]], 
LocalTxReleaseFuture [topVer=AffinityTopologyVersion [topVer=322, 
minorTopVer=0], futures=[]], AllTxReleaseFuture [topVer=AffinityTopologyVersion 
[topVer=322, minorTopVer=0], futures=[RemoteTxReleaseFuture 
[topVer=AffinityTopologyVersion [topVer=322, minorTopVer=0], futures=[]], 
exchActions=null, affChangeMsg=null, initTs=1524043684166, 
centralizedAff=false, forceAffReassignment=false, changeGlobalStateE=null, 
done=false, state=CRD, evtLatch=0, remaining=[], super=GridFutureAdapter 
[ignoreInterrupts=false, state=INIT, res=null, hash=1570781250]]]
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.updateTopologyVersion(GridDhtPartitionTopologyImpl.java:257)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.updateTopologies(GridDhtPartitionsExchangeFuture.java:845)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:2461)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2200)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:127)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2057)
at 

[jira] [Commented] (IGNITE-8021) Destroyed caches can be return to life by restart grid

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8021:


Github user asfgit closed the pull request at:

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


> Destroyed caches can be return to life by restart grid
> --
>
> Key: IGNITE-8021
> URL: https://issues.apache.org/jira/browse/IGNITE-8021
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Ivan Daschinskiy
>Priority: Major
> Fix For: 2.5
>
> Attachments: 8021-patch-for-patch, DstroedCacheReturnTest.java
>
>
> Cache configuration files stay stored on file system after invoke {{destroy}} 
> method.
> By the reason after restart grid all removed caches are start.
>  
> Look at the test [^DstroedCacheReturnTest.java]



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

[jira] [Updated] (IGNITE-8323) Assertion error during simultaneous auto-activation and manual activation

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-8323:
-
Labels: MakeTeamcityGreenAgain  (was: )

> Assertion error during simultaneous auto-activation and manual activation
> -
>
> Key: IGNITE-8323
> URL: https://issues.apache.org/jira/browse/IGNITE-8323
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> I observe the following assertion in 
> IgnitePdsDestroyCacheTest.testDestroyCaches
> {code}
> [2018-04-19 
> 15:31:02,994][ERROR][tcp-disco-msg-worker-#131%persistence.IgnitePdsDestroyCacheTest0%][TcpDiscoverySpi]
>  Failed to unmarshal discovery custom message.
> java.lang.AssertionError: lastAffVer=AffinityTopologyVersion [topVer=3, 
> minorTopVer=1], topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1], 
> customMsg=ChangeGlobalStateMessage 
> [id=59bcd2ed261-f35bb298-fc8b-46dd-9d06-7800f7c11d67, 
> reqId=01b3cf41-63e0-4ddc-80bc-a3e9b5414c14, 
> initiatingNodeId=0fc03864-7d8a-49bb-ba8a-ff6fb8c0, activate=true, 
> baselineTopology=BaselineTopology [id=0, branchingHash=-1713401276, 
> branchingType='Cluster activation', 
> baselineNodes=[c2d35f40-7229-43b3-9342-305eb5a63897, 
> f79b6d68-feaa-4b75-805a-8287b396b3eb, 442fe461-480c-4b32-8b81-28af4f66e165]], 
> forceChangeBaselineTopology=false, timestamp=1524141062984]
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onDiscoveryEvent(CacheAffinitySharedManager.java:174)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onDiscoveryEvent(GridCacheProcessor.java:3371)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:694)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:589)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5479)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5305)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2765)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621)
>   at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> From a quick investigation I see that this topology version is updated from 
> both auto-activation and manual activation requests.



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

[jira] [Commented] (IGNITE-7691) Provide info about DECIMAL column scale and precision

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-7691:
-

[~NIzhikov]

> 1) Binary compatibility for thin .NET client is broken

OK. Let's fix it.
Can you name some broken tests?
Or give me an example how compatibility is implemented in current sources?

> 2) Binary client docs are not updated

OK. Let's update it.

> 3) And the most important question - why QueryField.precision and 
> QueryField.scale are not used?

You suggest to use precision and scale when returning BigDecimal value as a 
query result.
Am I understand you correctly?

I think it has to be done in the separate ticket.
The goal of this ticket provide meta information to a user.

> Provide info about DECIMAL column scale and precision
> -
>
> Key: IGNITE-7691
> URL: https://issues.apache.org/jira/browse/IGNITE-7691
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.4
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Minor
> Fix For: 2.6
>
>
> Currently, it impossible to obtain scale and precision of DECIMAL column from 
> sql table metadata.
> Ignite should provide those type of meta information.



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

[jira] [Commented] (IGNITE-7691) Provide info about DECIMAL column scale and precision

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-7691:
-

[~vozerov]

Actually, this ticket is based on your email [1]
Did you change your opinion now?

{quote}
...it is not possible at the moment unfortunately - we do not store information
about lengths, scales and precision, only actual data types are passed to
H2 (e.g. String, BigDecimal, etc.). This will be fixed at some point in
future, but I do not have any dates at the moment.
{quote}

[1] 
https://lists.apache.org/thread.html/13f733e13ce81130d94f9e8692dfbd8ad8bfda26056672d9f71f892c@%3Cdev.ignite.apache.org%3E

> Provide info about DECIMAL column scale and precision
> -
>
> Key: IGNITE-7691
> URL: https://issues.apache.org/jira/browse/IGNITE-7691
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.4
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Minor
> Fix For: 2.6
>
>
> Currently, it impossible to obtain scale and precision of DECIMAL column from 
> sql table metadata.
> Ignite should provide those type of meta information.



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

[jira] [Updated] (IGNITE-8323) Assertion error during simultaneous auto-activation and manual activation

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-8323:
-
Description: 
I observe the following assertion in IgnitePdsDestroyCacheTest.testDestroyCaches
{code}
[2018-04-19 
15:31:02,994][ERROR][tcp-disco-msg-worker-#131%persistence.IgnitePdsDestroyCacheTest0%][TcpDiscoverySpi]
 Failed to unmarshal discovery custom message.
java.lang.AssertionError: lastAffVer=AffinityTopologyVersion [topVer=3, 
minorTopVer=1], topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1], 
customMsg=ChangeGlobalStateMessage 
[id=59bcd2ed261-f35bb298-fc8b-46dd-9d06-7800f7c11d67, 
reqId=01b3cf41-63e0-4ddc-80bc-a3e9b5414c14, 
initiatingNodeId=0fc03864-7d8a-49bb-ba8a-ff6fb8c0, activate=true, 
baselineTopology=BaselineTopology [id=0, branchingHash=-1713401276, 
branchingType='Cluster activation', 
baselineNodes=[c2d35f40-7229-43b3-9342-305eb5a63897, 
f79b6d68-feaa-4b75-805a-8287b396b3eb, 442fe461-480c-4b32-8b81-28af4f66e165]], 
forceChangeBaselineTopology=false, timestamp=1524141062984]
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onDiscoveryEvent(CacheAffinitySharedManager.java:174)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onDiscoveryEvent(GridCacheProcessor.java:3371)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:694)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:589)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5479)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5305)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2765)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
{code}

>From a quick investigation I see that this topology version is updated from 
>both auto-activation and manual activation requests.
Even though this assertion does not affect this particular test, the assertion 
must be fixed.

  was:
I observe the following assertion in IgnitePdsDestroyCacheTest.testDestroyCaches
{code}
[2018-04-19 
15:31:02,994][ERROR][tcp-disco-msg-worker-#131%persistence.IgnitePdsDestroyCacheTest0%][TcpDiscoverySpi]
 Failed to unmarshal discovery custom message.
java.lang.AssertionError: lastAffVer=AffinityTopologyVersion [topVer=3, 
minorTopVer=1], topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1], 
customMsg=ChangeGlobalStateMessage 
[id=59bcd2ed261-f35bb298-fc8b-46dd-9d06-7800f7c11d67, 
reqId=01b3cf41-63e0-4ddc-80bc-a3e9b5414c14, 
initiatingNodeId=0fc03864-7d8a-49bb-ba8a-ff6fb8c0, activate=true, 
baselineTopology=BaselineTopology [id=0, branchingHash=-1713401276, 
branchingType='Cluster activation', 
baselineNodes=[c2d35f40-7229-43b3-9342-305eb5a63897, 
f79b6d68-feaa-4b75-805a-8287b396b3eb, 442fe461-480c-4b32-8b81-28af4f66e165]], 
forceChangeBaselineTopology=false, timestamp=1524141062984]
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onDiscoveryEvent(CacheAffinitySharedManager.java:174)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onDiscoveryEvent(GridCacheProcessor.java:3371)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:694)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:589)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5479)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5305)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2765)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
{code}

>From a quick investigation I see that this topology version is updated from 
>both auto-activation and manual activation requests.


> Assertion error during simultaneous 

[jira] [Commented] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages

[Peter Ivanov (JIRA)]

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

Peter Ivanov commented on IGNITE-7108:
--

[~ilyak], thanks for review!

> Apache Ignite 2.5 RPM and DEB packages
> --
>
> Key: IGNITE-7108
> URL: https://issues.apache.org/jira/browse/IGNITE-7108
> Project: Ignite
>  Issue Type: New Feature
>  Components: binary
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
>  Labels: important
> Fix For: 2.5
>
>
> # (/) Update RPM build process to unify with DEB build.
> # (/) Prepare build of DEB package (using architecture and layout from RPM 
> package).



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

[jira] [Commented] (IGNITE-8082) No management bean for ZookeeperDiscoverySpi

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-8082:
--

Merged to master and ignite-2.5

> No management bean for ZookeeperDiscoverySpi
> 
>
> Key: IGNITE-8082
> URL: https://issues.apache.org/jira/browse/IGNITE-8082
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Max Shonichev
>Assignee: Sergey Chugunov
>Priority: Major
> Fix For: 2.5
>
>
> TcpDiscoverySpi provides management bean, allowing user to obtain 
> configuration and metrics from it via JMX.
> However, Zookeeper discovery spi provides no management bean, please add it 
> with similar attributes.



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

[jira] [Commented] (IGNITE-8021) Destroyed caches can be return to life by restart grid

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-8021:
--

Thanks, merged the fix both in master and ignite-2.5

> Destroyed caches can be return to life by restart grid
> --
>
> Key: IGNITE-8021
> URL: https://issues.apache.org/jira/browse/IGNITE-8021
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Ivan Daschinskiy
>Priority: Major
> Fix For: 2.5
>
> Attachments: 8021-patch-for-patch, DstroedCacheReturnTest.java
>
>
> Cache configuration files stay stored on file system after invoke {{destroy}} 
> method.
> By the reason after restart grid all removed caches are start.
>  
> Look at the test [^DstroedCacheReturnTest.java]



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

[jira] [Commented] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev commented on IGNITE-7108:
-

I approve this commit, recommend for inclusion.

> Apache Ignite 2.5 RPM and DEB packages
> --
>
> Key: IGNITE-7108
> URL: https://issues.apache.org/jira/browse/IGNITE-7108
> Project: Ignite
>  Issue Type: New Feature
>  Components: binary
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
>  Labels: important
> Fix For: 2.5
>
>
> # (/) Update RPM build process to unify with DEB build.
> # (/) Prepare build of DEB package (using architecture and layout from RPM 
> package).



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

[jira] [Commented] (IGNITE-7319) Memory leak during creating/destroying local cache

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-7319:
--

[~aealeksandrov], looks ok for me.
Can be merged.

> Memory leak during creating/destroying local cache
> --
>
> Key: IGNITE-7319
> URL: https://issues.apache.org/jira/browse/IGNITE-7319
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Andrey Aleksandrov
>Priority: Major
> Fix For: 2.6
>
> Attachments: Demo.java
>
>
> The following code creates local caches:
> {code}
> private IgniteCache createLocalCache(String name) { 
> CacheConfiguration cCfg = new 
> CacheConfiguration<>(); 
> cCfg.setName(name); 
> cCfg.setGroupName("localCaches"); // without group leak is much 
> bigger! 
> cCfg.setStoreKeepBinary(true); 
> cCfg.setCacheMode(CacheMode.LOCAL); 
> cCfg.setOnheapCacheEnabled(false); 
> cCfg.setCopyOnRead(false); 
> cCfg.setBackups(0); 
> cCfg.setWriteBehindEnabled(false); 
> cCfg.setReadThrough(false); 
> cCfg.setReadFromBackup(false); 
> cCfg.setQueryEntities(); 
> return ignite.createCache(cCfg).withKeepBinary(); 
> } 
> {code}
> The caches are placed in the queue and are picked up by the worker thread 
> which just destroys them after removing from the queue. 
> This setup seems to generate a memory leak of about 1GB per day. 
> When looking at heap dump, I see all space is occupied by instances of 
> java.util.concurrent.ConcurrentSkipListMap$Node.
> User list: 
> http://apache-ignite-users.70518.x6.nabble.com/Memory-leak-in-GridCachePartitionExchangeManager-tt18995.html



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

[jira] [Updated] (IGNITE-8323) Assertion error during simultaneous auto-activation and manual activation

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-8323:
-
Fix Version/s: 2.5

> Assertion error during simultaneous auto-activation and manual activation
> -
>
> Key: IGNITE-8323
> URL: https://issues.apache.org/jira/browse/IGNITE-8323
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> I observe the following assertion in 
> IgnitePdsDestroyCacheTest.testDestroyCaches
> {code}
> [2018-04-19 
> 15:31:02,994][ERROR][tcp-disco-msg-worker-#131%persistence.IgnitePdsDestroyCacheTest0%][TcpDiscoverySpi]
>  Failed to unmarshal discovery custom message.
> java.lang.AssertionError: lastAffVer=AffinityTopologyVersion [topVer=3, 
> minorTopVer=1], topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1], 
> customMsg=ChangeGlobalStateMessage 
> [id=59bcd2ed261-f35bb298-fc8b-46dd-9d06-7800f7c11d67, 
> reqId=01b3cf41-63e0-4ddc-80bc-a3e9b5414c14, 
> initiatingNodeId=0fc03864-7d8a-49bb-ba8a-ff6fb8c0, activate=true, 
> baselineTopology=BaselineTopology [id=0, branchingHash=-1713401276, 
> branchingType='Cluster activation', 
> baselineNodes=[c2d35f40-7229-43b3-9342-305eb5a63897, 
> f79b6d68-feaa-4b75-805a-8287b396b3eb, 442fe461-480c-4b32-8b81-28af4f66e165]], 
> forceChangeBaselineTopology=false, timestamp=1524141062984]
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onDiscoveryEvent(CacheAffinitySharedManager.java:174)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onDiscoveryEvent(GridCacheProcessor.java:3371)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:694)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:589)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5479)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5305)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2765)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621)
>   at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> From a quick investigation I see that this topology version is updated from 
> both auto-activation and manual activation requests.



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

[jira] [Created] (IGNITE-8323) Assertion error during simultaneous auto-activation and manual activation

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-8323:


 Summary: Assertion error during simultaneous auto-activation and 
manual activation
 Key: IGNITE-8323
 URL: https://issues.apache.org/jira/browse/IGNITE-8323
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexey Goncharuk


I observe the following assertion in IgnitePdsDestroyCacheTest.testDestroyCaches
{code}
[2018-04-19 
15:31:02,994][ERROR][tcp-disco-msg-worker-#131%persistence.IgnitePdsDestroyCacheTest0%][TcpDiscoverySpi]
 Failed to unmarshal discovery custom message.
java.lang.AssertionError: lastAffVer=AffinityTopologyVersion [topVer=3, 
minorTopVer=1], topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1], 
customMsg=ChangeGlobalStateMessage 
[id=59bcd2ed261-f35bb298-fc8b-46dd-9d06-7800f7c11d67, 
reqId=01b3cf41-63e0-4ddc-80bc-a3e9b5414c14, 
initiatingNodeId=0fc03864-7d8a-49bb-ba8a-ff6fb8c0, activate=true, 
baselineTopology=BaselineTopology [id=0, branchingHash=-1713401276, 
branchingType='Cluster activation', 
baselineNodes=[c2d35f40-7229-43b3-9342-305eb5a63897, 
f79b6d68-feaa-4b75-805a-8287b396b3eb, 442fe461-480c-4b32-8b81-28af4f66e165]], 
forceChangeBaselineTopology=false, timestamp=1524141062984]
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onDiscoveryEvent(CacheAffinitySharedManager.java:174)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onDiscoveryEvent(GridCacheProcessor.java:3371)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:694)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:589)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5479)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5305)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2765)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
{code}

>From a quick investigation I see that this topology version is updated from 
>both auto-activation and manual activation requests.



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

[jira] [Commented] (IGNITE-7691) Provide info about DECIMAL column scale and precision

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7691:


[~vozerov] which compatibilty do you mean? All compatibilty tests are passing 
as far as I can see.

> Provide info about DECIMAL column scale and precision
> -
>
> Key: IGNITE-7691
> URL: https://issues.apache.org/jira/browse/IGNITE-7691
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.4
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Minor
> Fix For: 2.6
>
>
> Currently, it impossible to obtain scale and precision of DECIMAL column from 
> sql table metadata.
> Ignite should provide those type of meta information.



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

[jira] [Assigned] (IGNITE-8077) Implement new JMX metrics for transactions

[Anton Kalashnikov (JIRA)]

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

Anton Kalashnikov reassigned IGNITE-8077:
-

Assignee: Anton Kalashnikov

> Implement new JMX metrics for transactions
> --
>
> Key: IGNITE-8077
> URL: https://issues.apache.org/jira/browse/IGNITE-8077
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Dmitriy Govorukhin
>Assignee: Anton Kalashnikov
>Priority: Major
>  Labels: iep-6
>
> These additional metrics should be implemented to monitor transactions.
> {code}
> class TransactionsMXbean{
> /** The number of transactions which was commited. */
> long getTxCommited();
> /** The number of transactions which was rollbacked. */
> long getTxRolledBack();
> /** The number of transactions holding at least one key lock. */
> long getTxHoldingLock();
> /** The number of keys locked on the node. */
> long getLockedKeys();
> /** The number of transactions for which node is the initiator. */
> int getOwnerTxs();
> }
> {code}
> For more details see in IgniteTxAdapter and IgniteTxManager.



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

[jira] [Commented] (IGNITE-7691) Provide info about DECIMAL column scale and precision

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-7691:
-

[~NIzhikov], the main problem is that we implemented a lot of changes, broken 
compatibiltiy, but solved nothing. Ignite hadn't supported scale/precision 
before, it doesn't support it after.

> Provide info about DECIMAL column scale and precision
> -
>
> Key: IGNITE-7691
> URL: https://issues.apache.org/jira/browse/IGNITE-7691
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.4
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Minor
> Fix For: 2.6
>
>
> Currently, it impossible to obtain scale and precision of DECIMAL column from 
> sql table metadata.
> Ignite should provide those type of meta information.



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

[jira] [Commented] (IGNITE-7691) Provide info about DECIMAL column scale and precision

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-7691:
-

[~vozerov]

> Ignite hadn't supported scale/precision before, it doesn't support it after.

{quote}This will be fixed at some point in future, but I do not have any dates 
at the moment.{quote}

I'm fully confused here. 
Are we going to fix it or not?

> Provide info about DECIMAL column scale and precision
> -
>
> Key: IGNITE-7691
> URL: https://issues.apache.org/jira/browse/IGNITE-7691
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.4
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Minor
> Fix For: 2.6
>
>
> Currently, it impossible to obtain scale and precision of DECIMAL column from 
> sql table metadata.
> Ignite should provide those type of meta information.



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

[jira] [Commented] (IGNITE-7691) Provide info about DECIMAL column scale and precision

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-7691:
-

Solution which makes sense to me:
1) Revert current patch
2) Return zero for precision and scale in JDBC 
3) Return any sensible number in Spark, since we do not support scale/precision 
anyway. It could be 0, -1, MAX_VALUE, whatever fit our needs
4) Disallow custom precision/scale in our new parser by default [1]

[1] https://issues.apache.org/jira/browse/IGNITE-6861

> Provide info about DECIMAL column scale and precision
> -
>
> Key: IGNITE-7691
> URL: https://issues.apache.org/jira/browse/IGNITE-7691
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.4
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Minor
> Fix For: 2.6
>
>
> Currently, it impossible to obtain scale and precision of DECIMAL column from 
> sql table metadata.
> Ignite should provide those type of meta information.



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

[jira] [Commented] (IGNITE-8017) Disable WAL during initial preloading

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8017:


One more thing: 
[https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=all=1223695=all&_focus=16652]

I'll fix this w/o ticket and PR, but please keep an eye on test failures in PR.

> Disable WAL during initial preloading
> -
>
> Key: IGNITE-8017
> URL: https://issues.apache.org/jira/browse/IGNITE-8017
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
>  Labels: iep-16
> Fix For: 2.5
>
>
> While handling SupplyMessage, node handles each supplied data entry 
> separately, which causes a WAL record for each entry to be written. It 
> significantly limits preloading speed.
> We can improve rebalancing speed and reduce pressure on disk by disabling WAL 
> until all data is loaded. The disadvantage of this approach is that data 
> might get corrupted if node crashes - but node that crashed during preloading 
> has to clear all it's data anyway. However, it is important to distinguish 
> situations when new node joined cluster or added to baseline topology (and 
> doesn't hold any data) and when additional partitions got assigned to node 
> after baseline topology changed (in this case node has to keep all data in 
> consistent state).



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