[jira] [Assigned] (IGNITE-7766) Ignite Queries 2: Test always failed IgniteCacheQueryNodeRestartTxSelfTest.testRestarts
[ https://issues.apache.org/jira/browse/IGNITE-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zagumennov reassigned IGNITE-7766: -- Assignee: Evgenii Zagumennov (was: Alexei Scherbakov) > Ignite Queries 2: Test always failed > IgniteCacheQueryNodeRestartTxSelfTest.testRestarts > --- > > Key: IGNITE-7766 > URL: https://issues.apache.org/jira/browse/IGNITE-7766 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Dmitriy Pavlov >Assignee: Evgenii Zagumennov >Priority: Major > Labels: MakeTeamcityGreenAgain > >Ignite Queries 2 > IgniteBinaryCacheQueryTestSuite2: > IgniteCacheQueryNodeRestartTxSelfTest.testRestarts (fail rate 76,1%) > IgniteCacheQueryNodeRestartTxSelfTest.testRestarts > Current failure:refs/heads/master #345No changes > 11 Feb 18 03:03 > > junit.framework.AssertionFailedError: On large page size must retry. > > Last runs fails with 100% probability. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7907) Revisit and update the DBeaver documentations
[ 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.
[ https://issues.apache.org/jira/browse/IGNITE-7909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ https://issues.apache.org/jira/browse/IGNITE-7909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ https://issues.apache.org/jira/browse/IGNITE-7909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ https://issues.apache.org/jira/browse/IGNITE-7909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ https://issues.apache.org/jira/browse/IGNITE-7909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ https://issues.apache.org/jira/browse/IGNITE-7909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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] [Created] (IGNITE-8333) Web console: Editors for table values have wrong baseline
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] [Updated] (IGNITE-8333) Web console: Editors for table values have wrong baseline
[ 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-8332) Web console: Empty cells in SQL Scheme table
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
[ 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.
[ https://issues.apache.org/jira/browse/IGNITE-8245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-8215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-7691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ 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 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
[ https://issues.apache.org/jira/browse/IGNITE-8154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-7077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-8197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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()
[ https://issues.apache.org/jira/browse/IGNITE-7791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&testNameId=-9174769196124217030&tab=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=Cach
[jira] [Commented] (IGNITE-8312) .NET: CacheAbstractTransactionalTest.TestTxRollbackOnly failure
[ https://issues.apache.org/jira/browse/IGNITE-8312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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 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
[ https://issues.apache.org/jira/browse/IGNITE-8154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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 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
[ https://issues.apache.org/jira/browse/IGNITE-8154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-8312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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()
[ https://issues.apache.org/jira/browse/IGNITE-7791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&testNameId=-9174769196124217030&tab=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=Cac
[jira] [Comment Edited] (IGNITE-7791) Ignite Client Nodes: failed test IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()
[ https://issues.apache.org/jira/browse/IGNITE-7791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&testNameId=-9174769196124217030&tab=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=CacheAf
[jira] [Comment Edited] (IGNITE-7791) Ignite Client Nodes: failed test IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()
[ https://issues.apache.org/jira/browse/IGNITE-7791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&testNameId=-9174769196124217030&tab=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=CacheAffini
[jira] [Commented] (IGNITE-7791) Ignite Client Nodes: failed test IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()
[ https://issues.apache.org/jira/browse/IGNITE-7791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&testNameId=-9174769196124217030&tab=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.CacheAffinitySharedManag
[jira] [Updated] (IGNITE-8315) Prevent printing the partition distribution on clients nodes
[ 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&page=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&page=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
[ 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&page=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
[ 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&page=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&page=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
[ https://issues.apache.org/jira/browse/IGNITE-8313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(Provid
[jira] [Updated] (IGNITE-8325) Compressor thread may miss notification on stop
[ 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
[ 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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444272#comment-16444272 ] Anton Kalashnikov commented on IGNITE-8077: --- TC - https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&tab=projectOverview&branch_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()
[ https://issues.apache.org/jira/browse/IGNITE-7791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&testNameId=-9174769196124217030&tab=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$Exc
[jira] [Commented] (IGNITE-8324) Ignite Cache Restarts 1 suite hangs with assertion error
[ https://issues.apache.org/jira/browse/IGNITE-8324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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, e
[jira] [Commented] (IGNITE-8077) Implement new JMX metrics for transactions
[ https://issues.apache.org/jira/browse/IGNITE-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-8327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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()
[ https://issues.apache.org/jira/browse/IGNITE-7791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&testNameId=-9174769196124217030&tab=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
[jira] [Commented] (IGNITE-7791) Ignite Client Nodes: failed test IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()
[ https://issues.apache.org/jira/browse/IGNITE-7791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&testNameId=-9174769196124217030&tab=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) >
[jira] [Commented] (IGNITE-7791) Ignite Client Nodes: failed test IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()
[ https://issues.apache.org/jira/browse/IGNITE-7791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&testNameId=-9174769196124217030&tab=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(GridCachePartitionE
[jira] [Commented] (IGNITE-8327) Node stop hangs because thread sleep blocks gateway lock
[ https://issues.apache.org/jira/browse/IGNITE-8327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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()
[ https://issues.apache.org/jira/browse/IGNITE-7791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&testNameId=-9174769196124217030&tab=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
[jira] [Updated] (IGNITE-8327) Node stop hangs because thread sleep blocks gateway lock
[ 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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-8134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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()
[ https://issues.apache.org/jira/browse/IGNITE-7791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&testNameId=-9174769196124217030&tab=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 > org.apache.ignite.internal.uti
[jira] [Assigned] (IGNITE-8220) Discovery worker termination in PDS test
[ 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&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PdsDirectIo1&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ActivateDeactivateCluster&branch_IgniteTests24Java8=%3Cdefault%3E&tab=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 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
[ 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
[ 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&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PdsDirectIo1&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ActivateDeactivateCluster&branch_IgniteTests24Java8=%3Cdefault%3E&tab=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
[ https://issues.apache.org/jira/browse/IGNITE-7691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ https://issues.apache.org/jira/browse/IGNITE-8295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > org.apache.maven.surefire.booter.Pr
[jira] [Commented] (IGNITE-8325) Compressor thread may miss notification on stop
[ https://issues.apache.org/jira/browse/IGNITE-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.j
[jira] [Updated] (IGNITE-8325) Compressor thread may miss notification on stop
[ 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 > org.apache.maven.
[jira] [Updated] (IGNITE-8325) Compressor thread may miss notification on stop
[ 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) > at
[jira] [Created] (IGNITE-8325) Compressor thread may miss notification on stop
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
[ 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 > org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:8
[jira] [Commented] (IGNITE-5553) Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error
[ https://issues.apache.org/jira/browse/IGNITE-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&testNameId=-7043871603266099589&tab=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
[ https://issues.apache.org/jira/browse/IGNITE-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&testNameId=-7043871603266099589&tab=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
[ https://issues.apache.org/jira/browse/IGNITE-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ https://issues.apache.org/jira/browse/IGNITE-8092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-8219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444025#comment-16444025 ] Ilya Lantukh commented on IGNITE-8017: -- [~dpavlov], Issue with https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-4459509243019188454&branch=%3Cdefault%3E&tab=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 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 org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDht
[jira] [Commented] (IGNITE-8021) Destroyed caches can be return to life by restart grid
[ https://issues.apache.org/jira/browse/IGNITE-8021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-7691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-7691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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 aut
[jira] [Commented] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[ https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-8082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-8021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-7319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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 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
[ https://issues.apache.org/jira/browse/IGNITE-7691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-7691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-7691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-7691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)