[jira] [Commented] (IGNITE-9353) Remove "Known issue, possible deadlock in case of low priority cache rebalancing delayed" comment from GridCacheRebalancingSyncSelfTest#getConfiguration
[ https://issues.apache.org/jira/browse/IGNITE-9353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16589720#comment-16589720 ] Roman Shtykh commented on IGNITE-9353: -- [~Mmuzaf] Can you please approve? Btw, what failure handler have you mentioned in the mailing list? > Remove "Known issue, possible deadlock in case of low priority cache > rebalancing delayed" comment from > GridCacheRebalancingSyncSelfTest#getConfiguration > > > Key: IGNITE-9353 > URL: https://issues.apache.org/jira/browse/IGNITE-9353 > Project: Ignite > Issue Type: Task >Reporter: Roman Shtykh >Assignee: Roman Shtykh >Priority: Trivial > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9180) IgniteSparkSession Should Copy State on cloneSession()
[ https://issues.apache.org/jira/browse/IGNITE-9180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16589705#comment-16589705 ] ASF GitHub Bot commented on IGNITE-9180: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4531 > IgniteSparkSession Should Copy State on cloneSession() > -- > > Key: IGNITE-9180 > URL: https://issues.apache.org/jira/browse/IGNITE-9180 > Project: Ignite > Issue Type: Bug > Components: spark >Affects Versions: 2.6 >Reporter: Stuart Macdonald >Assignee: Stuart Macdonald >Priority: Major > Fix For: 2.7 > > > The IgniteSparkSession class extends SparkSession and overrides the > cloneSession() method. The contract for cloneSession() explicitly states that > it should clone all state (ie. the sharedState and sessionState fields), > however the IgniteSparkSession implementation doesn't clone its state fields. > This has the side-effect of breaking stateful operations for anything which > uses cloneSession(), for example a Spark streaming job will not be able to > use cached data across streaming microbatches, which is a significant issue > for such applications. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9353) Remove "Known issue, possible deadlock in case of low priority cache rebalancing delayed" comment from GridCacheRebalancingSyncSelfTest#getConfiguration
[ https://issues.apache.org/jira/browse/IGNITE-9353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16589681#comment-16589681 ] ASF GitHub Bot commented on IGNITE-9353: GitHub user shroman opened a pull request: https://github.com/apache/ignite/pull/4599 IGNITE-9353: Removed "Known issue, possible deadlock in case of low p… …riority cache rebalancing delayed" comment from GridCacheRebalancingSyncSelfTest#getConfiguration. You can merge this pull request into a Git repository by running: $ git pull https://github.com/shroman/ignite IGNITE-9353 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4599.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 #4599 commit f4b5e92082a5fc3f5f74a4e2ba71a1d75be8917b Author: shroman Date: 2018-08-23T04:22:23Z IGNITE-9353: Removed "Known issue, possible deadlock in case of low priority cache rebalancing delayed" comment from GridCacheRebalancingSyncSelfTest#getConfiguration. > Remove "Known issue, possible deadlock in case of low priority cache > rebalancing delayed" comment from > GridCacheRebalancingSyncSelfTest#getConfiguration > > > Key: IGNITE-9353 > URL: https://issues.apache.org/jira/browse/IGNITE-9353 > Project: Ignite > Issue Type: Task >Reporter: Roman Shtykh >Assignee: Roman Shtykh >Priority: Trivial > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9353) Remove "Known issue, possible deadlock in case of low priority cache rebalancing delayed" comment from GridCacheRebalancingSyncSelfTest#getConfiguration
[ https://issues.apache.org/jira/browse/IGNITE-9353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16589676#comment-16589676 ] ASF GitHub Bot commented on IGNITE-9353: Github user shroman closed the pull request at: https://github.com/apache/ignite/pull/4598 > Remove "Known issue, possible deadlock in case of low priority cache > rebalancing delayed" comment from > GridCacheRebalancingSyncSelfTest#getConfiguration > > > Key: IGNITE-9353 > URL: https://issues.apache.org/jira/browse/IGNITE-9353 > Project: Ignite > Issue Type: Task >Reporter: Roman Shtykh >Assignee: Roman Shtykh >Priority: Trivial > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9350) Web Console backend should not fail if null received via web sockets
[
https://issues.apache.org/jira/browse/IGNITE-9350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16589666#comment-16589666
]
ASF GitHub Bot commented on IGNITE-9350:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4597
> Web Console backend should not fail if null received via web sockets
>
>
> Key: IGNITE-9350
> URL: https://issues.apache.org/jira/browse/IGNITE-9350
> Project: Ignite
> Issue Type: Bug
> Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.7
>
>
> Backend failed with error:
> {code}
> app/browsersHandler.js:207
> sock.on('node:rest', (\{clusterId, params, credentials}, cb) => {
> ^
> TypeError: Cannot destructure property `clusterId` of 'undefined' or 'null'.
> {code}
>
> We should check for null data received via web sockets
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9353) Remove "Known issue, possible deadlock in case of low priority cache rebalancing delayed" comment from GridCacheRebalancingSyncSelfTest#getConfiguration
[ https://issues.apache.org/jira/browse/IGNITE-9353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16589661#comment-16589661 ] ASF GitHub Bot commented on IGNITE-9353: GitHub user shroman opened a pull request: https://github.com/apache/ignite/pull/4598 IGNITE-9353: Removed "Known issue, possible deadlock in case of low p… …riority cache rebalancing delayed" comment from GridCacheRebalancingSyncSelfTest#getConfiguration. You can merge this pull request into a Git repository by running: $ git pull https://github.com/shroman/ignite master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4598.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 #4598 commit fa2c8e72e7559803eee250f35c5120e0b7270de2 Author: shroman Date: 2018-08-23T03:45:15Z IGNITE-9353: Removed "Known issue, possible deadlock in case of low priority cache rebalancing delayed" comment from GridCacheRebalancingSyncSelfTest#getConfiguration. > Remove "Known issue, possible deadlock in case of low priority cache > rebalancing delayed" comment from > GridCacheRebalancingSyncSelfTest#getConfiguration > > > Key: IGNITE-9353 > URL: https://issues.apache.org/jira/browse/IGNITE-9353 > Project: Ignite > Issue Type: Task >Reporter: Roman Shtykh >Assignee: Roman Shtykh >Priority: Trivial > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9353) Remove "Known issue, possible deadlock in case of low priority cache rebalancing delayed" comment from GridCacheRebalancingSyncSelfTest#getConfiguration
Roman Shtykh created IGNITE-9353: Summary: Remove "Known issue, possible deadlock in case of low priority cache rebalancing delayed" comment from GridCacheRebalancingSyncSelfTest#getConfiguration Key: IGNITE-9353 URL: https://issues.apache.org/jira/browse/IGNITE-9353 Project: Ignite Issue Type: Task Reporter: Roman Shtykh Assignee: Roman Shtykh -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9352) Web Console: Investigate how correctly use package-lock.json
Alexey Kuznetsov created IGNITE-9352: Summary: Web Console: Investigate how correctly use package-lock.json Key: IGNITE-9352 URL: https://issues.apache.org/jira/browse/IGNITE-9352 Project: Ignite Issue Type: Bug Components: wizards Reporter: Alexey Kuznetsov Fix For: 2.7 We need to investigate how correctly use package-lock.json and "^" symbol in package.json. Using "^" allows to use latest version of dependencies, but sometimes it can break build or application just before release. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9350) Web Console backend should not fail if null received via web sockets
[
https://issues.apache.org/jira/browse/IGNITE-9350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16589593#comment-16589593
]
ASF GitHub Bot commented on IGNITE-9350:
GitHub user akuznetsov-gridgain opened a pull request:
https://github.com/apache/ignite/pull/4597
IGNITE-9350 Added checks for empty data in web sockets events.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9350
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4597.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 #4597
commit 3ae0edf6e6cd740517c0283ab0fed6c03b72362c
Author: Alexey Kuznetsov
Date: 2018-08-22T16:24:19Z
IGNITE-9350 Web Console: Added checks for unexpected response.
commit fa42c77d1403bee80b58b2871552e5ba8b29b410
Author: Alexey Kuznetsov
Date: 2018-08-22T17:01:09Z
IGNITE-9350 Web Console: Added checks for unexpected data in web socket
event data.
> Web Console backend should not fail if null received via web sockets
>
>
> Key: IGNITE-9350
> URL: https://issues.apache.org/jira/browse/IGNITE-9350
> Project: Ignite
> Issue Type: Bug
> Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.7
>
>
> Backend failed with error:
> {code}
> app/browsersHandler.js:207
> sock.on('node:rest', (\{clusterId, params, credentials}, cb) => {
> ^
> TypeError: Cannot destructure property `clusterId` of 'undefined' or 'null'.
> {code}
>
> We should check for null data received via web sockets
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9302) Java Thin Clients TC configuration hangs because of no timeout on tests
[ https://issues.apache.org/jira/browse/IGNITE-9302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16589426#comment-16589426 ] Eduard Shangareev commented on IGNITE-9302: --- https://ci.ignite.apache.org/viewLog.html?buildId=1709581=buildResultsDiv=IgniteTests24Java8_RunAll Looks OK. [~agoncharuk], could you help with merge? > Java Thin Clients TC configuration hangs because of no timeout on tests > --- > > Key: IGNITE-9302 > URL: https://issues.apache.org/jira/browse/IGNITE-9302 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_JavaThinClient=buildTypeHistoryList_IgniteTests24Java8=__all_branches__ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6055) SQL: Add String length constraint
[
https://issues.apache.org/jira/browse/IGNITE-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16589353#comment-16589353
]
Nikolay Izhikov commented on IGNITE-6055:
-
[~isapego] [~vozerov]
I've added support of length constraints to ODBC meta information.
C++ tests are OK.
Igor, please, review C++ changes.
https://ci.ignite.apache.org/viewLog.html?buildId=1710821
https://ci.ignite.apache.org/viewLog.html?buildId=1710936
https://ci.ignite.apache.org/viewQueued.html?itemId=1710825
https://ci.ignite.apache.org/viewLog.html?buildId=1710827
> 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
> Fix For: 2.7
>
>
> 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] [Resolved] (IGNITE-9296) Stopping node by Failure Handler hangs up in IgniteWalFlushBackgroundSelfTest
[
https://issues.apache.org/jira/browse/IGNITE-9296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Gura resolved IGNITE-9296.
-
Resolution: Fixed
[~macrergate] LGTM! Merged to master branch. Thanks for contribution!
> Stopping node by Failure Handler hangs up in IgniteWalFlushBackgroundSelfTest
> --
>
> Key: IGNITE-9296
> URL: https://issues.apache.org/jira/browse/IGNITE-9296
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Kosarev
>Assignee: Sergey Kosarev
>Priority: Major
> Fix For: 2.7
>
> Attachments: logs.zip
>
>
> Here are log messages:
> {code}
> [18:46:27]W: [org.apache.ignite:ignite-core] [2018-08-15
> 15:46:27,442][ERROR][main][root] Test has been timed out and will be
> interrupted (threads dump will be taken before interruption)
> [test=testFailWhileStart, timeout=6]
> {code}
> And later on all the suite also hangs up:
> {code}
> [22:22:49]E: [Step 3/4] The build Ignite Tests 2.4+ (Java 8)::PDS 2 #2184
> {buildId=1662285} has been running for more than 240 minutes. Terminating...
> Main thread locked by node-stopper:
> [18:46:27] : [Step 3/4] Thread
> [name="test-runner-#7695%wal.IgniteWalFlushBackgroundSelfTest%", id=9150,
> state=BLOCKED, blockCnt=4, waitCnt=142]
> [18:46:27] : [Step 3/4] Lock
> [object=o.a.i.i.IgnitionEx$IgniteNamedInstance@7c251f90,
> ownerName=node-stopper, ownerId=9267]
> [18:46:27] : [Step 3/4] at
> o.a.i.i.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2565)
> [18:46:27] : [Step 3/4] at
> o.a.i.i.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2557)
> [18:46:27] : [Step 3/4] at
> o.a.i.i.IgnitionEx.stop(IgnitionEx.java:374)
> [18:46:27] : [Step 3/4] at o.a.i.Ignition.stop(Ignition.java:229)
> [18:46:27] : [Step 3/4] at
> o.a.i.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1088)
> [18:46:27] : [Step 3/4] at
> o.a.i.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1131)
> [18:46:27] : [Step 3/4] at
> o.a.i.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1109)
> [18:46:27] : [Step 3/4] at
> o.a.i.i.processors.cache.persistence.db.wal.IgniteWalFlushMultiNodeFailoverAbstractSelfTest.failWhilePut(IgniteWalFlushMultiNodeFailoverAbstractSelfTest.java:213)
> [18:46:27] : [Step 3/4] at
> o.a.i.i.processors.cache.persistence.db.wal.IgniteWalFlushMultiNodeFailoverAbstractSelfTest.testFailWhileStart(IgniteWalFlushMultiNodeFailoverAbstractSelfTest.java:147)
> node-stopper waits for the wal-segment-syncer stopping
> [18:46:28]W: [org.apache.ignite:ignite-core] Thread
> [name="node-stopper", id=9267, state=WAITING, blockCnt=19, waitCnt=22]
> [18:46:28]W: [org.apache.ignite:ignite-core] Lock
> [object=java.lang.Object@5ba26eb0, ownerName=null, ownerId=-1]
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> java.lang.Object.wait(Native Method)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> java.lang.Object.wait(Object.java:502)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.util.worker.GridWorker.join(GridWorker.java:233)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.util.IgniteUtils.join(IgniteUtils.java:4692)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.processors.cache.persistence.wal.FileWriteAheadLogManager$WalSegmentSyncer.shutdown(FileWriteAheadLogManager.java:3562)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.processors.cache.persistence.wal.FileWriteAheadLogManager$WalSegmentSyncer.access$700(FileWriteAheadLogManager.java:3527)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.processors.cache.persistence.wal.FileWriteAheadLogManager.stop0(FileWriteAheadLogManager.java:578)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.processors.cache.GridCacheSharedManagerAdapter.stop(GridCacheSharedManagerAdapter.java:94)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.processors.cache.GridCacheProcessor.stop(GridCacheProcessor.java:951)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.IgniteKernal.stop0(IgniteKernal.java:2303)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.IgniteKernal.stop(IgniteKernal.java:2181)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2594)
> [18:46:28]W: [org.apache.ignite:ignite-core] -
[jira] [Updated] (IGNITE-9296) Stopping node by Failure Handler hangs up in IgniteWalFlushBackgroundSelfTest
[
https://issues.apache.org/jira/browse/IGNITE-9296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Gura updated IGNITE-9296:
Fix Version/s: 2.7
> Stopping node by Failure Handler hangs up in IgniteWalFlushBackgroundSelfTest
> --
>
> Key: IGNITE-9296
> URL: https://issues.apache.org/jira/browse/IGNITE-9296
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Kosarev
>Assignee: Sergey Kosarev
>Priority: Major
> Fix For: 2.7
>
> Attachments: logs.zip
>
>
> Here are log messages:
> {code}
> [18:46:27]W: [org.apache.ignite:ignite-core] [2018-08-15
> 15:46:27,442][ERROR][main][root] Test has been timed out and will be
> interrupted (threads dump will be taken before interruption)
> [test=testFailWhileStart, timeout=6]
> {code}
> And later on all the suite also hangs up:
> {code}
> [22:22:49]E: [Step 3/4] The build Ignite Tests 2.4+ (Java 8)::PDS 2 #2184
> {buildId=1662285} has been running for more than 240 minutes. Terminating...
> Main thread locked by node-stopper:
> [18:46:27] : [Step 3/4] Thread
> [name="test-runner-#7695%wal.IgniteWalFlushBackgroundSelfTest%", id=9150,
> state=BLOCKED, blockCnt=4, waitCnt=142]
> [18:46:27] : [Step 3/4] Lock
> [object=o.a.i.i.IgnitionEx$IgniteNamedInstance@7c251f90,
> ownerName=node-stopper, ownerId=9267]
> [18:46:27] : [Step 3/4] at
> o.a.i.i.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2565)
> [18:46:27] : [Step 3/4] at
> o.a.i.i.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2557)
> [18:46:27] : [Step 3/4] at
> o.a.i.i.IgnitionEx.stop(IgnitionEx.java:374)
> [18:46:27] : [Step 3/4] at o.a.i.Ignition.stop(Ignition.java:229)
> [18:46:27] : [Step 3/4] at
> o.a.i.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1088)
> [18:46:27] : [Step 3/4] at
> o.a.i.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1131)
> [18:46:27] : [Step 3/4] at
> o.a.i.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1109)
> [18:46:27] : [Step 3/4] at
> o.a.i.i.processors.cache.persistence.db.wal.IgniteWalFlushMultiNodeFailoverAbstractSelfTest.failWhilePut(IgniteWalFlushMultiNodeFailoverAbstractSelfTest.java:213)
> [18:46:27] : [Step 3/4] at
> o.a.i.i.processors.cache.persistence.db.wal.IgniteWalFlushMultiNodeFailoverAbstractSelfTest.testFailWhileStart(IgniteWalFlushMultiNodeFailoverAbstractSelfTest.java:147)
> node-stopper waits for the wal-segment-syncer stopping
> [18:46:28]W: [org.apache.ignite:ignite-core] Thread
> [name="node-stopper", id=9267, state=WAITING, blockCnt=19, waitCnt=22]
> [18:46:28]W: [org.apache.ignite:ignite-core] Lock
> [object=java.lang.Object@5ba26eb0, ownerName=null, ownerId=-1]
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> java.lang.Object.wait(Native Method)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> java.lang.Object.wait(Object.java:502)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.util.worker.GridWorker.join(GridWorker.java:233)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.util.IgniteUtils.join(IgniteUtils.java:4692)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.processors.cache.persistence.wal.FileWriteAheadLogManager$WalSegmentSyncer.shutdown(FileWriteAheadLogManager.java:3562)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.processors.cache.persistence.wal.FileWriteAheadLogManager$WalSegmentSyncer.access$700(FileWriteAheadLogManager.java:3527)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.processors.cache.persistence.wal.FileWriteAheadLogManager.stop0(FileWriteAheadLogManager.java:578)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.processors.cache.GridCacheSharedManagerAdapter.stop(GridCacheSharedManagerAdapter.java:94)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.processors.cache.GridCacheProcessor.stop(GridCacheProcessor.java:951)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.IgniteKernal.stop0(IgniteKernal.java:2303)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.IgniteKernal.stop(IgniteKernal.java:2181)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2594)
> [18:46:28]W: [org.apache.ignite:ignite-core] - locked
> o.a.i.i.IgnitionEx$IgniteNamedInstance@7c251f90
> [18:46:28]W:
[jira] [Commented] (IGNITE-9351) Log restore partition state start and finish events with elapsed time
[
https://issues.apache.org/jira/browse/IGNITE-9351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16589128#comment-16589128
]
Dmitriy Pavlov commented on IGNITE-9351:
Example of message
{noformat}
2018-08-22 20:05:16.629 INFO [exchange-worker-#42] - Applying lost cache
updates since last checkpoint record [lastMarked=FileWALPointer [idx=3321,
fileOff=41319391, len=593891],
lastCheckpointId=7e73b2f7-4bfa-439f-ac8a-e521020d8f58]
2018-08-22 20:05:16.663 INFO [exchange-worker-#42] - Restoring partition state
for local groups [cntPartStateWal=0,
lastCheckpointId=7e73b2f7-4bfa-439f-ac8a-e521020d8f58]
2018-08-22 20:05:25.700 INFO [exchange-worker-#42] - Finished restoring
partition state for local groups [cntProcessed=31236, cntPartStateWal=0,
time=9037ms]
2018-08-22 20:05:25.706 INFO [exchange-worker-#42] - Finished applying WAL
changes [updatesApplied=0, time=9070ms]
{noformat}
[~agoncharuk] could you please take a look at
https://github.com/apache/ignite/pull/4595 ?
> Log restore partition state start and finish events with elapsed time
> -
>
> Key: IGNITE-9351
> URL: https://issues.apache.org/jira/browse/IGNITE-9351
> Project: Ignite
> Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Minor
> Fix For: 2.7
>
>
> During startup of Ignite in addition to applying logical updates, there can
> be a huge operation of restoring partition states, which for slow HDD and
> relatively big count of partitions can require significant time.
> It is suggested to add start and finish messages with elapsed time.
> {noformat}
> "exchange-worker-#42@3605" prio=5 tid=0x57 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.getUninterruptibly(GridFutureAdapter.java:145)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIO.read(AsyncFileIO.java:95)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:351)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:328)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:312)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:779)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:624)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:142)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.init(PagesList.java:212)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.(AbstractFreeList.java:370)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.CacheFreeListImpl.(CacheFreeListImpl.java:47)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore$1.(GridCacheOffheapManager.java:1203)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.init0(GridCacheOffheapManager.java:1203)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.updateCounter(GridCacheOffheapManager.java:1420)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.updateCounter(GridDhtLocalPartition.java:942)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.(GridDhtLocalPartition.java:222)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.forceCreatePartition(GridDhtPartitionTopologyImpl.java:843)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restorePartitionStates(GridCacheDatabaseSharedManager.java:2380)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLastUpdates(GridCacheDatabaseSharedManager.java:2333)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1443)
> at
>
[jira] [Commented] (IGNITE-7967) DataRegionMetrics#totalAllocatedPages is invalid if metrics were enabled at runtime
[
https://issues.apache.org/jira/browse/IGNITE-7967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16589126#comment-16589126
]
Dmitriy Sorokin commented on IGNITE-7967:
-
[~agura] While working on this task, I discovered several problems that I also
fixed in this context:
# Wrong points of metric update at PageMemoryNoStoreImpl class;
# File header size was added to value of 'allocated' field of FilePageStore
class, but substracted at usages of that value;
# Incorrect calculation of totalPersistenceSize variable value at the
checkMetricsConsistency method of IgnitePdsDataRegionMetricsTest class;
# Every-time creation of no-op implementation of AllocatedPageTracker
interface instead usage of singleton;
# ClusterNodeMetricsSelfTest and DataRegionMetricsSelfTest was fixed according
to new metric behaviour.
> DataRegionMetrics#totalAllocatedPages is invalid if metrics were enabled at
> runtime
> ---
>
> Key: IGNITE-7967
> URL: https://issues.apache.org/jira/browse/IGNITE-7967
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.3
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Sorokin
>Priority: Major
> Labels: iep-6
> Fix For: 2.7
>
>
> {{totalAllocatedPages}} is updated during runtime via callback. When metrics
> are enabled at runtime, some pages may be already allocated, thus the metric
> shows invalid value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9351) Log restore partition state start and finish events with elapsed time
[
https://issues.apache.org/jira/browse/IGNITE-9351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16589124#comment-16589124
]
ASF GitHub Bot commented on IGNITE-9351:
GitHub user dspavlov opened a pull request:
https://github.com/apache/ignite/pull/4595
IGNITE-9351 Log restore partition state start and finish events with …
…elapsed time
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9351
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4595.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 #4595
commit 563d12f34385a9f8ead0046cafb44f7bc1beb797
Author: Dmitriy Pavlov
Date: 2018-08-22T16:57:39Z
IGNITE-9351 Log restore partition state start and finish events with
elapsed time
> Log restore partition state start and finish events with elapsed time
> -
>
> Key: IGNITE-9351
> URL: https://issues.apache.org/jira/browse/IGNITE-9351
> Project: Ignite
> Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Minor
> Fix For: 2.7
>
>
> During startup of Ignite in addition to applying logical updates, there can
> be a huge operation of restoring partition states, which for slow HDD and
> relatively big count of partitions can require significant time.
> It is suggested to add start and finish messages with elapsed time.
> {noformat}
> "exchange-worker-#42@3605" prio=5 tid=0x57 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.getUninterruptibly(GridFutureAdapter.java:145)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIO.read(AsyncFileIO.java:95)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:351)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:328)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:312)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:779)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:624)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:142)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.init(PagesList.java:212)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.(AbstractFreeList.java:370)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.CacheFreeListImpl.(CacheFreeListImpl.java:47)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore$1.(GridCacheOffheapManager.java:1203)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.init0(GridCacheOffheapManager.java:1203)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.updateCounter(GridCacheOffheapManager.java:1420)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.updateCounter(GridDhtLocalPartition.java:942)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.(GridDhtLocalPartition.java:222)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.forceCreatePartition(GridDhtPartitionTopologyImpl.java:843)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restorePartitionStates(GridCacheDatabaseSharedManager.java:2380)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLastUpdates(GridCacheDatabaseSharedManager.java:2333)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1443)
> at
>
[jira] [Assigned] (IGNITE-9350) Web Console backend should not fail if null received via web sockets
[
https://issues.apache.org/jira/browse/IGNITE-9350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov reassigned IGNITE-9350:
Assignee: Andrey Novikov (was: Alexey Kuznetsov)
[~anovikov], please review my changes in ignite-9350 branch.
> Web Console backend should not fail if null received via web sockets
>
>
> Key: IGNITE-9350
> URL: https://issues.apache.org/jira/browse/IGNITE-9350
> Project: Ignite
> Issue Type: Bug
> Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.7
>
>
> Backend failed with error:
> {code}
> app/browsersHandler.js:207
> sock.on('node:rest', (\{clusterId, params, credentials}, cb) => {
> ^
> TypeError: Cannot destructure property `clusterId` of 'undefined' or 'null'.
> {code}
>
> We should check for null data received via web sockets
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9351) Log restore partition state start and finish events with elapsed time
[
https://issues.apache.org/jira/browse/IGNITE-9351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-9351:
---
Fix Version/s: 2.7
> Log restore partition state start and finish events with elapsed time
> -
>
> Key: IGNITE-9351
> URL: https://issues.apache.org/jira/browse/IGNITE-9351
> Project: Ignite
> Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Minor
> Fix For: 2.7
>
>
> During startup of Ignite in addition to applying logical updates, there can
> be a huge operation of restoring partition states, which for slow HDD and
> relatively big count of partitions can require significant time.
> It is suggested to add start and finish messages with elapsed time.
> {noformat}
> "exchange-worker-#42@3605" prio=5 tid=0x57 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.getUninterruptibly(GridFutureAdapter.java:145)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIO.read(AsyncFileIO.java:95)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:351)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:328)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:312)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:779)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:624)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:142)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.init(PagesList.java:212)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.(AbstractFreeList.java:370)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.CacheFreeListImpl.(CacheFreeListImpl.java:47)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore$1.(GridCacheOffheapManager.java:1203)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.init0(GridCacheOffheapManager.java:1203)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.updateCounter(GridCacheOffheapManager.java:1420)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.updateCounter(GridDhtLocalPartition.java:942)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.(GridDhtLocalPartition.java:222)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.forceCreatePartition(GridDhtPartitionTopologyImpl.java:843)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restorePartitionStates(GridCacheDatabaseSharedManager.java:2380)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLastUpdates(GridCacheDatabaseSharedManager.java:2333)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1443)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java:1183)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1132)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:712)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2419)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2299)
> at
>
[jira] [Updated] (IGNITE-9351) Log restore partition state start and finish events with elapsed time
[
https://issues.apache.org/jira/browse/IGNITE-9351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-9351:
---
Ignite Flags: (was: Docs Required)
> Log restore partition state start and finish events with elapsed time
> -
>
> Key: IGNITE-9351
> URL: https://issues.apache.org/jira/browse/IGNITE-9351
> Project: Ignite
> Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Minor
>
> During startup of Ignite in addition to applying logical updates, there can
> be a huge operation of restoring partition states, which for slow HDD and
> relatively big count of partitions can require significant time.
> It is suggested to add start and finish messages with elapsed time.
> {noformat}
> "exchange-worker-#42@3605" prio=5 tid=0x57 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.getUninterruptibly(GridFutureAdapter.java:145)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIO.read(AsyncFileIO.java:95)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:351)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:328)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:312)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:779)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:624)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:142)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.init(PagesList.java:212)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.(AbstractFreeList.java:370)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.CacheFreeListImpl.(CacheFreeListImpl.java:47)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore$1.(GridCacheOffheapManager.java:1203)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.init0(GridCacheOffheapManager.java:1203)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.updateCounter(GridCacheOffheapManager.java:1420)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.updateCounter(GridDhtLocalPartition.java:942)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.(GridDhtLocalPartition.java:222)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.forceCreatePartition(GridDhtPartitionTopologyImpl.java:843)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restorePartitionStates(GridCacheDatabaseSharedManager.java:2380)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLastUpdates(GridCacheDatabaseSharedManager.java:2333)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1443)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java:1183)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1132)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:712)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2419)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2299)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>
[jira] [Commented] (IGNITE-9302) Java Thin Clients TC configuration hangs because of no timeout on tests
[ https://issues.apache.org/jira/browse/IGNITE-9302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16589103#comment-16589103 ] Anton Kalashnikov commented on IGNITE-9302: --- [~EdShangGG], looks good for me. After finish the tests it can be merged. > Java Thin Clients TC configuration hangs because of no timeout on tests > --- > > Key: IGNITE-9302 > URL: https://issues.apache.org/jira/browse/IGNITE-9302 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_JavaThinClient=buildTypeHistoryList_IgniteTests24Java8=__all_branches__ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9249) Tests hang when different threads try to start and stop nodes at the same time.
[
https://issues.apache.org/jira/browse/IGNITE-9249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev updated IGNITE-9249:
--
Labels: MakeTeamcityGreenAgain (was: )
> Tests hang when different threads try to start and stop nodes at the same
> time.
> ---
>
> Key: IGNITE-9249
> URL: https://issues.apache.org/jira/browse/IGNITE-9249
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> An example of such test is
> GridCachePartitionedNearDisabledOptimisticTxNodeRestartTest.testRestartWithPutFourNodesOneBackupsOffheapEvict().
> Hanged threads:
> {code}
> "restart-worker-1@63424" prio=5 tid=0x7f5e nid=NA waiting
> java.lang.Thread.State: WAITING
> at java.lang.Object.wait(Object.java:-1)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:949)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:389)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2002)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:916)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1754)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1050)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
> - locked <0xfc36> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:651)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:920)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:858)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:846)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:812)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.access$1000(GridCacheAbstractNodeRestartSelfTest.java:64)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest$2.run(GridCacheAbstractNodeRestartSelfTest.java:665)
> at java.lang.Thread.run(Thread.java:748)
> "restart-worker-0@63423" prio=5 tid=0x7f5d nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at
> org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:7584)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.grid(IgnitionEx.java:1666)
> at
> org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1284)
> at
> org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1262)
> at org.apache.ignite.Ignition.allGrids(Ignition.java:502)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.awaitTopologyChange(GridAbstractTest.java:2258)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1158)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1133)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1433)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.access$800(GridCacheAbstractNodeRestartSelfTest.java:64)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest$2.run(GridCacheAbstractNodeRestartSelfTest.java:661)
> at java.lang.Thread.run(Thread.java:748)
>
[jira] [Created] (IGNITE-9351) Log restore partition state start and finish events with elapsed time
Dmitriy Pavlov created IGNITE-9351:
--
Summary: Log restore partition state start and finish events with
elapsed time
Key: IGNITE-9351
URL: https://issues.apache.org/jira/browse/IGNITE-9351
Project: Ignite
Issue Type: Task
Reporter: Dmitriy Pavlov
Assignee: Dmitriy Pavlov
During startup of Ignite in addition to applying logical updates, there can be
a huge operation of restoring partition states, which for slow HDD and
relatively big count of partitions can require significant time.
It is suggested to add start and finish messages with elapsed time.
{noformat}
"exchange-worker-#42@3605" prio=5 tid=0x57 nid=NA waiting
java.lang.Thread.State: WAITING
at sun.misc.Unsafe.park(Unsafe.java:-1)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.getUninterruptibly(GridFutureAdapter.java:145)
at
org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIO.read(AsyncFileIO.java:95)
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:351)
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:328)
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:312)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:779)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:624)
at
org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:142)
at
org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.init(PagesList.java:212)
at
org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.(AbstractFreeList.java:370)
at
org.apache.ignite.internal.processors.cache.persistence.freelist.CacheFreeListImpl.(CacheFreeListImpl.java:47)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore$1.(GridCacheOffheapManager.java:1203)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.init0(GridCacheOffheapManager.java:1203)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.updateCounter(GridCacheOffheapManager.java:1420)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.updateCounter(GridDhtLocalPartition.java:942)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.(GridDhtLocalPartition.java:222)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.forceCreatePartition(GridDhtPartitionTopologyImpl.java:843)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restorePartitionStates(GridCacheDatabaseSharedManager.java:2380)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLastUpdates(GridCacheDatabaseSharedManager.java:2333)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1443)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java:1183)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1132)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:712)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2419)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2299)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8867) Bootstrapping for learning sample
[ https://issues.apache.org/jira/browse/IGNITE-8867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Ignatenko reassigned IGNITE-8867: -- Assignee: Oleg Ignatenko > Bootstrapping for learning sample > - > > Key: IGNITE-8867 > URL: https://issues.apache.org/jira/browse/IGNITE-8867 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Yury Babak >Assignee: Oleg Ignatenko >Priority: Major > Fix For: 2.7 > > > Need to implement bootstrapping algorithm in Bagging-classifier -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-5102) Fix fold/map behavior for sparse matrices .
[ https://issues.apache.org/jira/browse/IGNITE-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak resolved IGNITE-5102. Resolution: Won't Fix We purged related functionality for release 2.7 > Fix fold/map behavior for sparse matrices . > --- > > Key: IGNITE-5102 > URL: https://issues.apache.org/jira/browse/IGNITE-5102 > Project: Ignite > Issue Type: Bug > Components: ml >Reporter: Artem Malykh >Assignee: Artem Malykh >Priority: Major > Fix For: 2.7 > > > For now when doing 'map' and 'fold' over a sparse matrix, only non-default > values are considered. This is bad because this is in conflict with semantics > of 'fold' and 'map' for other matrix implementations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-5221) Investigate possibility of integrating with dl4j
[ https://issues.apache.org/jira/browse/IGNITE-5221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak resolved IGNITE-5221. Resolution: Won't Fix For deep learning and other NN-related features we have chosen TensorFlow > Investigate possibility of integrating with dl4j > > > Key: IGNITE-5221 > URL: https://issues.apache.org/jira/browse/IGNITE-5221 > Project: Ignite > Issue Type: Task > Components: ml >Affects Versions: 2.1 >Reporter: Artem Malykh >Assignee: Yury Babak >Priority: Major > Fix For: 2.7 > > > Investigate if there is an easy possibility for integration of apache ignite > with dl4j. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7410) IgniteSparseDistributedMatrixMulBenchmark(Mul2) hangs
[ https://issues.apache.org/jira/browse/IGNITE-7410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak resolved IGNITE-7410. Resolution: Fixed For release 2.7 we purged this benchmark > IgniteSparseDistributedMatrixMulBenchmark(Mul2) hangs > -- > > Key: IGNITE-7410 > URL: https://issues.apache.org/jira/browse/IGNITE-7410 > Project: Ignite > Issue Type: Bug > Components: ml, yardstick >Affects Versions: 2.4 >Reporter: Ilya Suntsov >Assignee: Oleg Ignatenko >Priority: Major > Fix For: 2.7 > > Attachments: logs_sparse-distributed-matrix-mul.zip > > > I tried to run the benchmarks bellow on 2 servers and 3 clients: > * IgniteSparseDistributedMatrixMulBenchmark > * IgniteSparseDistributedMatrixMul2Benchmark > They hang. > I've attached logs and configs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6346) Distributed set does not work in REPLICATED mode
[
https://issues.apache.org/jira/browse/IGNITE-6346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16589012#comment-16589012
]
Anton Vinogradov commented on IGNITE-6346:
--
[~vk],
Fix looks good to me.
But, the following should be done before the merge.
- TC should be checked. [~dpavlov], do we have a clear explanation for how it
should be checked?
- License should be set to each file
- Code should be formatted according to
https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
- Junit asserts should be used inside test instead of regular {{assert}}
- {{assert set.iterator().hasNext();}} should be replaced with equals check.
- {{SET_NAME}} used only once, it should be replaced with a regular inlined
string.
- I do not see any reason to check tx cache here, atomic is enough.
> Distributed set does not work in REPLICATED mode
>
>
> Key: IGNITE-6346
> URL: https://issues.apache.org/jira/browse/IGNITE-6346
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.1
>Reporter: Valentin Kulichenko
>Assignee: vk
>Priority: Major
>
> When {{IgniteSet}} is created with {{REPLICATED}} cache mode, any attempt to
> read it fails with exception:
> {noformat}
> Exception in thread "main" class org.apache.ignite.IgniteException: Cluster
> group is empty.
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:48)
> at ReplicatedSet.main(ReplicatedSet.java:36)
> 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> Caused by: class
> org.apache.ignite.internal.cluster.ClusterGroupEmptyCheckedException: Cluster
> group is empty.
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.execute0(GridCacheQueryAdapter.java:481)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.execute(GridCacheQueryAdapter.java:442)
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheSetImpl.iterator0(GridCacheSetImpl.java:420)
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheSetImpl.iterator(GridCacheSetImpl.java:375)
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheSetProxy.iterator(GridCacheSetProxy.java:342)
> ... 6 more
> {noformat}
> To reproduce run the following code:
> {code}
> Ignition.start(new IgniteConfiguration().setIgniteInstanceName("server-1"));
> Ignition.start(new IgniteConfiguration().setIgniteInstanceName("server-2"));
> Ignition.setClientMode(true);
> Ignite ignite = Ignition.start();
> IgniteSet set = ignite.set("my-set", new
> CollectionConfiguration().setCacheMode(CacheMode.REPLICATED));
> for (String s : set) {
> System.out.println(s);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9348) ML examples improvements, follow-up to IGNITE-9297
[ https://issues.apache.org/jira/browse/IGNITE-9348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9348: - Ignite Flags: (was: Docs Required) > ML examples improvements, follow-up to IGNITE-9297 > -- > > Key: IGNITE-9348 > URL: https://issues.apache.org/jira/browse/IGNITE-9348 > Project: Ignite > Issue Type: Task > Components: ml >Affects Versions: 2.6 >Reporter: Oleg Ignatenko >Assignee: Oleg Ignatenko >Priority: Major > Fix For: 2.7 > > > After IGNITE-9297 was resolved, ML examples were discussed with some folks > ([~skozlov], [~avolkov], [~chief]) in order to check if some other > improvements may be desired. This ticket is to address obtained feedback. > List of points that look worth taking care of includes (but is not limited > to): > * some examples javadocs still looks like missing details (eg random forest) > * some mentions of algorithms (eg kNN, gradient boosting etc) are better to > be linked to respective introductory articles in order to help less > experienced users easier grasp the examples > * presence of some examples doesn't look justified (eg LocalDatasetExample) > * logging in some examples looks sub-optimal, either too brief or too lengthy -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9350) Web Console backend should not fail if null received via web sockets
Alexey Kuznetsov created IGNITE-9350:
Summary: Web Console backend should not fail if null received via
web sockets
Key: IGNITE-9350
URL: https://issues.apache.org/jira/browse/IGNITE-9350
Project: Ignite
Issue Type: Bug
Components: wizards
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov
Fix For: 2.7
Backend failed with error:
{code}
app/browsersHandler.js:207
sock.on('node:rest', (\{clusterId, params, credentials}, cb) => {
^
TypeError: Cannot destructure property `clusterId` of 'undefined' or 'null'.
{code}
We should check for null data received via web sockets
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9348) ML examples improvements, follow-up to IGNITE-9297
[ https://issues.apache.org/jira/browse/IGNITE-9348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9348: - Ignite Flags: Docs Required > ML examples improvements, follow-up to IGNITE-9297 > -- > > Key: IGNITE-9348 > URL: https://issues.apache.org/jira/browse/IGNITE-9348 > Project: Ignite > Issue Type: Task > Components: ml >Affects Versions: 2.6 >Reporter: Oleg Ignatenko >Assignee: Oleg Ignatenko >Priority: Major > Fix For: 2.7 > > > After IGNITE-9297 was resolved, ML examples were discussed with some folks > ([~skozlov], [~avolkov], [~chief]) in order to check if some other > improvements may be desired. This ticket is to address obtained feedback. > List of points that look worth taking care of includes (but is not limited > to): > * some examples javadocs still looks like missing details (eg random forest) > * some mentions of algorithms (eg kNN, gradient boosting etc) are better to > be linked to respective introductory articles in order to help less > experienced users easier grasp the examples > * presence of some examples doesn't look justified (eg LocalDatasetExample) > * logging in some examples looks sub-optimal, either too brief or too lengthy -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9054) ScanQuery responses are serialized with Optimized Marshaller
[ https://issues.apache.org/jira/browse/IGNITE-9054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588987#comment-16588987 ] ASF GitHub Bot commented on IGNITE-9054: Github user alamar closed the pull request at: https://github.com/apache/ignite/pull/4529 > ScanQuery responses are serialized with Optimized Marshaller > > > Key: IGNITE-9054 > URL: https://issues.apache.org/jira/browse/IGNITE-9054 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.5 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Labels: easyfix > Attachments: 22530.diff > > > When you do ContinuousQuery on a cache, its initial query sends results via > OptimizedMarshaller (which has binary compatibility implications) but its > continuous part uses BinaryMarshaller. They should both be using > BinaryMarshaller. Fix seems to be one-liner, see patch and userlist thread. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9082) Throwing checked exception during tx commit without node stopping leads to data corruption
[ https://issues.apache.org/jira/browse/IGNITE-9082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexei Scherbakov reassigned IGNITE-9082: - Assignee: Alexei Scherbakov > Throwing checked exception during tx commit without node stopping leads to > data corruption > -- > > Key: IGNITE-9082 > URL: https://issues.apache.org/jira/browse/IGNITE-9082 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.4, 2.5, 2.6 >Reporter: Pavel Kovalenko >Assignee: Alexei Scherbakov >Priority: Major > Fix For: 2.7 > > > If we get checked exception during tx commit on a primary node and this > exception is not supposed to be handled as NodeStopping OR doesn't lead to > node stop using Failure Handler, in this case, we may get data loss on a node > which is a backup node for this tx. > Possible solution: > If we get any checked or unchecked exception during tx commit we should stop > this node after that to prevent further data loss. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9054) ScanQuery responses are serialized with Optimized Marshaller
[ https://issues.apache.org/jira/browse/IGNITE-9054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588977#comment-16588977 ] Ilya Kasnacheev commented on IGNITE-9054: - [~slukyanov] please review new PR > ScanQuery responses are serialized with Optimized Marshaller > > > Key: IGNITE-9054 > URL: https://issues.apache.org/jira/browse/IGNITE-9054 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.5 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Labels: easyfix > Attachments: 22530.diff > > > When you do ContinuousQuery on a cache, its initial query sends results via > OptimizedMarshaller (which has binary compatibility implications) but its > continuous part uses BinaryMarshaller. They should both be using > BinaryMarshaller. Fix seems to be one-liner, see patch and userlist thread. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9305) Wrong off-heap size is reported for a node
[
https://issues.apache.org/jira/browse/IGNITE-9305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588967#comment-16588967
]
ASF GitHub Bot commented on IGNITE-9305:
GitHub user xtern opened a pull request:
https://github.com/apache/ignite/pull/4593
IGNITE-9305
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/xtern/ignite IGNITE-9305
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4593.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 #4593
commit bd7a871d1cc20101bfba68fb05d07cd4f4c31206
Author: pereslegin-pa
Date: 2018-08-22T12:19:34Z
IGNITE-9305 Non heap mem metrics logging.
commit bf8eb41ed66363adffaec56e86c828f6bb14
Author: pereslegin-pa
Date: 2018-08-22T13:42:14Z
IGNITE-9305 Log mem metrics separately for each region.
commit 5014b414969689152dc6fe4d6ea268c17fb8d543
Author: pereslegin-pa
Date: 2018-08-22T14:52:01Z
IGNITE-9305 Persistence region metrics log format check.
> Wrong off-heap size is reported for a node
> --
>
> Key: IGNITE-9305
> URL: https://issues.apache.org/jira/browse/IGNITE-9305
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Denis Magda
>Assignee: Pavel Pereslegin
>Priority: Blocker
> Fix For: 2.7
>
>
> Was troubleshooting an Ignite deployment today and couldn't find out from the
> logs what was the actual off-heap space used.
> Those were the given memory resoures (Ignite 2.6):
> {code}
> [2018-08-16 15:07:49,961][INFO ][main][GridDiscoveryManager] Topology
> snapshot [ver=1, servers=1, clients=0, CPUs=64, offheap=30.0GB, heap=24.0GB]
> {code}
> And that weird stuff was reported by the node (pay attention to the last
> line):
> {code}
> [2018-08-16 15:45:50,211][INFO
> ][grid-timeout-worker-#135%cluster_31-Dec-2017%][IgniteKernal%cluster_31-Dec-2017]
>
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=c033026e, name=cluster_31-Dec-2017, uptime=00:38:00.257]
> ^-- H/N/C [hosts=1, nodes=1, CPUs=64]
> ^-- CPU [cur=0.03%, avg=5.54%, GC=0%]
> ^-- PageMemory [pages=6997377]
> ^-- Heap [used=9706MB, free=61.18%, comm=22384MB]
> ^-- Non heap [used=144MB, free=-1%, comm=148MB] - this line is always the
> same!
> {code}
> Had to change the code by using
> {code}dataRegion.getPhysicalMemoryPages(){code} to find out that actual
> off-heap usage size was
> {code}
> >>> Physical Memory Size: 28651614208 => 27324 MB, 26 GB
> {code}
> The logs have to report the following instead:
> {code}
> ^-- Off-heap {Data Region 1} [used={dataRegion1.getPhysicalMemorySize()},
> free=X%, comm=dataRegion1.maxSize()]
> ^-- Off-heap {Data Region 2} [used={dataRegion2.getPhysicalMemorySize()},
> free=X%, comm=dataRegion2.maxSize()]
> {code}
> If Ignite persistence is enabled then the following extra lines have to be
> added to see the disk used space:
> {code}
> ^-- Ignite persistence {Data Region 1}:
> used={dataRegion1.getTotalAllocatedSize() -
> dataRegion1.getPhysicalMemorySize()}
> ^-- Ignite persistence {Data Region 2}
> [used={dataRegion2.getTotalAllocatedSize() -
> dataRegion2.getPhysicalMemorySize()}]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9054) ScanQuery responses are serialized with Optimized Marshaller
[ https://issues.apache.org/jira/browse/IGNITE-9054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588958#comment-16588958 ] ASF GitHub Bot commented on IGNITE-9054: GitHub user alamar opened a pull request: https://github.com/apache/ignite/pull/4592 IGNITE-9054 Avoid using OptimizedMarshaller with initial ScanQuery. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-gg-14092 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4592.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 #4592 commit a9e41f07d78f9b64d827303763155bc77da23224 Author: Ilya Kasnacheev Date: 2018-08-22T14:47:52Z IGNITE-9054 Avoid using OptimizedMarshaller with initial ScanQuery. > ScanQuery responses are serialized with Optimized Marshaller > > > Key: IGNITE-9054 > URL: https://issues.apache.org/jira/browse/IGNITE-9054 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.5 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Labels: easyfix > Attachments: 22530.diff > > > When you do ContinuousQuery on a cache, its initial query sends results via > OptimizedMarshaller (which has binary compatibility implications) but its > continuous part uses BinaryMarshaller. They should both be using > BinaryMarshaller. Fix seems to be one-liner, see patch and userlist thread. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9256) SQL: make sure that fetched results are cleared from iterator when last element is fetched
[
https://issues.apache.org/jira/browse/IGNITE-9256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588953#comment-16588953
]
Vladimir Ozerov edited comment on IGNITE-9256 at 8/22/18 2:48 PM:
--
[~SGrimstad], my comments:
1) {{H2ResultSetIterator.onClose}} - let's do not throw any exception from
here. To achieve this pay attention to {{closeStmt}} field - it is always
{{false}}, so we can simply delete it.
2) {{H2ResultSetIteratorNullifyOnEnd}} - test is not included into any suite
3) {{H2ResultSetIteratorNullifyOnEnd}} - please fix styling violations (missing
headers, blank lines)
4) Test coverage is insufficient - only local SQL fields query is tested.
Moreover, private API is used for some reason, what increases a risk to
something. Instead, queries should be executed through public API, and the
following scenarios should be tested:
* SqlQuery
* SqlQuery with setLocal(true)
* SqlFieldsQuery
* SqlFieldsQuery with setLocal(true)
was (Author: vozerov):
[~SGrimstad], my comments:
1) {{H2ResultSetIterator.onClose}} - let's do not throw any exception from
here. To achieve this pay attention to {{closeStmt}} field - it is always
{{false}}, so we can simply delete it.
2) {{H2ResultSetIteratorNullifyOnEnd}} - test is not included into any suite
3) {{H2ResultSetIteratorNullifyOnEnd}} - please fix styling violations (missing
headers, blank lines,
4) Test coverage is insufficient - only local SQL fields query is tested.
Moreover, private API is used for some reason, what increases a risk to
something. Instead, queries should be executed through public API, and the
following scenarios should be tested:
* SqlQuery
* SqlQuery with setLocal(true)
* SqlFieldsQuery
* SqlFieldsQuery with setLocal(true)
> SQL: make sure that fetched results are cleared from iterator when last
> element is fetched
> --
>
> Key: IGNITE-9256
> URL: https://issues.apache.org/jira/browse/IGNITE-9256
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.6
>Reporter: Vladimir Ozerov
>Assignee: Sergey Grimstad
>Priority: Major
> Labels: sql-stability
> Fix For: 2.7
>
> Attachments: IGNITE-9256__Implemented.patch
>
>
> In practice it is possible for user to forget to nullify Ignite's result set
> after iteration is finished. Or he may delay cleanup for some reason.
> The problem is that we hold the whole H2's result set inside our iterator
> even after all results are delivered to the user.
> We should forcibly close and then nullify all H2 objects once all results are
> returned.
> Key code pieces:
> {{IgniteH2Indexing.executeSqlQueryWithTimer}} - how we get result from H2
> {{H2ResultSetIterator}} - base iterator with H2 objects inside
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9188) Unexpected eviction leading to data loss in a scenario with stopping/restarting nodes during rebalancing
[
https://issues.apache.org/jira/browse/IGNITE-9188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588933#comment-16588933
]
ASF GitHub Bot commented on IGNITE-9188:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4578
> Unexpected eviction leading to data loss in a scenario with
> stopping/restarting nodes during rebalancing
>
>
> Key: IGNITE-9188
> URL: https://issues.apache.org/jira/browse/IGNITE-9188
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.7
>
>
> Scenario:
> 1. Split grid nodes in two groups with distinct partition mapping. One group
> holds even partitions, other - odd. Rebalancing of "odd" partitions is only
> triggered when number of nodes in grid exceeds n/2 threshold.
> 2. Start n/2 nodes, activate, put data into "even" partitions.
> 3. Start other n/2 nodes, change BLT, delay rebalancing of "odd" partitions.
> 4. Stop newly started nodes before rebalancing is finished.
> Expected behavior: parttiions in "odd" group will keep owning state.
> Actual behavior: "odd" partitions are evicted leading to data loss.
> Unit test reproducer:
> {noformat}
> /*
> * Licensed to the Apache Software Foundation (ASF) under one or more
> * contributor license agreements. See the NOTICE file distributed with
> * this work for additional information regarding copyright ownership.
> * The ASF licenses this file to You under the Apache License, Version 2.0
> * (the "License"); you may not use this file except in compliance with
> * the License. You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
> package org.apache.ignite.internal.processors.cache.distributed;
> import java.util.ArrayList;
> import java.util.Collection;
> import java.util.HashMap;
> import java.util.List;
> import java.util.Map;
> import java.util.UUID;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.affinity.AffinityFunctionContext;
> import org.apache.ignite.cache.affinity.rendezvous.RendezvousAffinityFunction;
> import org.apache.ignite.cluster.ClusterNode;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.DataRegionConfiguration;
> import org.apache.ignite.configuration.DataStorageConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.configuration.WALMode;
> import org.apache.ignite.internal.TestRecordingCommunicationSpi;
> import org.apache.ignite.internal.processors.cache.GridCacheUtils;
> import
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition;
> import
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemandMessage;
> import org.apache.ignite.internal.util.typedef.G;
> import org.apache.ignite.internal.util.typedef.internal.CU;
> import org.apache.ignite.internal.util.typedef.internal.U;
> import org.apache.ignite.lang.IgniteBiPredicate;
> import org.apache.ignite.plugin.extensions.communication.Message;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.jetbrains.annotations.Nullable;
> import static
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionState.OWNING;
> /**
> *
> */
> public class CacheLostPartitionsRestoreStateTest extends
> GridCommonAbstractTest {
> /** */
> public static final long MB = 1024 * 1024L;
> /** */
> public static final String GRP_ATTR = "grp";
> /** */
> public static final int GRIDS_CNT = 6;
> /** */
> public static final String CACHE_1 = "filled";
> /** */
> public static final String CACHE_2 = "empty";
> /** */
> public static final String EVEN_GRP = "event";
> /** */
> public static final String ODD_GRP = "odd";
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setCommunicationSpi(new TestRecordingCommunicationSpi());
> CacheConfiguration ccfg = new CacheConfiguration("default");
> ccfg.setAffinity(new
[jira] [Updated] (IGNITE-9188) Unexpected eviction leading to data loss in a scenario with stopping/restarting nodes during rebalancing
[
https://issues.apache.org/jira/browse/IGNITE-9188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-9188:
-
Ignite Flags: (was: Docs Required)
> Unexpected eviction leading to data loss in a scenario with
> stopping/restarting nodes during rebalancing
>
>
> Key: IGNITE-9188
> URL: https://issues.apache.org/jira/browse/IGNITE-9188
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.7
>
>
> Scenario:
> 1. Split grid nodes in two groups with distinct partition mapping. One group
> holds even partitions, other - odd. Rebalancing of "odd" partitions is only
> triggered when number of nodes in grid exceeds n/2 threshold.
> 2. Start n/2 nodes, activate, put data into "even" partitions.
> 3. Start other n/2 nodes, change BLT, delay rebalancing of "odd" partitions.
> 4. Stop newly started nodes before rebalancing is finished.
> Expected behavior: parttiions in "odd" group will keep owning state.
> Actual behavior: "odd" partitions are evicted leading to data loss.
> Unit test reproducer:
> {noformat}
> /*
> * Licensed to the Apache Software Foundation (ASF) under one or more
> * contributor license agreements. See the NOTICE file distributed with
> * this work for additional information regarding copyright ownership.
> * The ASF licenses this file to You under the Apache License, Version 2.0
> * (the "License"); you may not use this file except in compliance with
> * the License. You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
> package org.apache.ignite.internal.processors.cache.distributed;
> import java.util.ArrayList;
> import java.util.Collection;
> import java.util.HashMap;
> import java.util.List;
> import java.util.Map;
> import java.util.UUID;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.affinity.AffinityFunctionContext;
> import org.apache.ignite.cache.affinity.rendezvous.RendezvousAffinityFunction;
> import org.apache.ignite.cluster.ClusterNode;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.DataRegionConfiguration;
> import org.apache.ignite.configuration.DataStorageConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.configuration.WALMode;
> import org.apache.ignite.internal.TestRecordingCommunicationSpi;
> import org.apache.ignite.internal.processors.cache.GridCacheUtils;
> import
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition;
> import
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemandMessage;
> import org.apache.ignite.internal.util.typedef.G;
> import org.apache.ignite.internal.util.typedef.internal.CU;
> import org.apache.ignite.internal.util.typedef.internal.U;
> import org.apache.ignite.lang.IgniteBiPredicate;
> import org.apache.ignite.plugin.extensions.communication.Message;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.jetbrains.annotations.Nullable;
> import static
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionState.OWNING;
> /**
> *
> */
> public class CacheLostPartitionsRestoreStateTest extends
> GridCommonAbstractTest {
> /** */
> public static final long MB = 1024 * 1024L;
> /** */
> public static final String GRP_ATTR = "grp";
> /** */
> public static final int GRIDS_CNT = 6;
> /** */
> public static final String CACHE_1 = "filled";
> /** */
> public static final String CACHE_2 = "empty";
> /** */
> public static final String EVEN_GRP = "event";
> /** */
> public static final String ODD_GRP = "odd";
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setCommunicationSpi(new TestRecordingCommunicationSpi());
> CacheConfiguration ccfg = new CacheConfiguration("default");
> ccfg.setAffinity(new RendezvousAffinityFunction(false,
> CacheConfiguration.MAX_PARTITIONS_COUNT));
>
[jira] [Commented] (IGNITE-9318) SQL system view for list of baseline topology nodes
[ https://issues.apache.org/jira/browse/IGNITE-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588926#comment-16588926 ] Aleksey Plekhanov commented on IGNITE-9318: --- [~vozerov], thanks for review. Fixed. Please have a look again. > SQL system view for list of baseline topology nodes > --- > > Key: IGNITE-9318 > URL: https://issues.apache.org/jira/browse/IGNITE-9318 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-13 > > Implement SQL system view to show list of baseline topology nodes. View must > contain information about node consistentId and online/offline status. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9348) ML examples improvements, follow-up to IGNITE-9297
[ https://issues.apache.org/jira/browse/IGNITE-9348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588919#comment-16588919 ] Oleg Ignatenko commented on IGNITE-9348: https://github.com/gridgain/apache-ignite/tree/ignite-9348 > ML examples improvements, follow-up to IGNITE-9297 > -- > > Key: IGNITE-9348 > URL: https://issues.apache.org/jira/browse/IGNITE-9348 > Project: Ignite > Issue Type: Task > Components: ml >Affects Versions: 2.6 >Reporter: Oleg Ignatenko >Assignee: Oleg Ignatenko >Priority: Major > Fix For: 2.7 > > > After IGNITE-9297 was resolved, ML examples were discussed with some folks > ([~skozlov], [~avolkov], [~chief]) in order to check if some other > improvements may be desired. This ticket is to address obtained feedback. > List of points that look worth taking care of includes (but is not limited > to): > * some examples javadocs still looks like missing details (eg random forest) > * some mentions of algorithms (eg kNN, gradient boosting etc) are better to > be linked to respective introductory articles in order to help less > experienced users easier grasp the examples > * presence of some examples doesn't look justified (eg LocalDatasetExample) > * logging in some examples looks sub-optimal, either too brief or too lengthy -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8920) Node should be failed when during tx finish indices are corrupted.
[ https://issues.apache.org/jira/browse/IGNITE-8920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588914#comment-16588914 ] ASF GitHub Bot commented on IGNITE-8920: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4432 > Node should be failed when during tx finish indices are corrupted. > -- > > Key: IGNITE-8920 > URL: https://issues.apache.org/jira/browse/IGNITE-8920 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.5 >Reporter: Ivan Daschinskiy >Assignee: Pavel Kovalenko >Priority: Major > Fix For: 2.7 > > > While transaction is processed after receiving finish request > (IgniteTxHandler.finish) , node should be failed by FailureHandler if page > content of indices is corrupted. Currently this case is not handled properly > and cause to long running transactions over the grid. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9348) ML examples improvements, follow-up to IGNITE-9297
[ https://issues.apache.org/jira/browse/IGNITE-9348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Ignatenko updated IGNITE-9348: --- Fix Version/s: 2.7 > ML examples improvements, follow-up to IGNITE-9297 > -- > > Key: IGNITE-9348 > URL: https://issues.apache.org/jira/browse/IGNITE-9348 > Project: Ignite > Issue Type: Task > Components: ml >Affects Versions: 2.6 >Reporter: Oleg Ignatenko >Assignee: Oleg Ignatenko >Priority: Major > Fix For: 2.7 > > > After IGNITE-9297 was resolved, ML examples were discussed with some folks > ([~skozlov], [~avolkov], [~chief]) in order to check if some other > improvements may be desired. This ticket is to address obtained feedback. > List of points that look worth taking care of includes (but is not limited > to): > * some examples javadocs still looks like missing details (eg random forest) > * some mentions of algorithms (eg kNN, gradient boosting etc) are better to > be linked to respective introductory articles in order to help less > experienced users easier grasp the examples > * presence of some examples doesn't look justified (eg LocalDatasetExample) > * logging in some examples looks sub-optimal, either too brief or too lengthy -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9348) ML examples improvements, follow-up to IGNITE-9297
[ https://issues.apache.org/jira/browse/IGNITE-9348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Ignatenko reassigned IGNITE-9348: -- Assignee: Oleg Ignatenko > ML examples improvements, follow-up to IGNITE-9297 > -- > > Key: IGNITE-9348 > URL: https://issues.apache.org/jira/browse/IGNITE-9348 > Project: Ignite > Issue Type: Task > Components: ml >Affects Versions: 2.6 >Reporter: Oleg Ignatenko >Assignee: Oleg Ignatenko >Priority: Major > > After IGNITE-9297 was resolved, ML examples were discussed with some folks > ([~skozlov], [~avolkov], [~chief]) in order to check if some other > improvements may be desired. This ticket is to address obtained feedback. > List of points that look worth taking care of includes (but is not limited > to): > * some examples javadocs still looks like missing details (eg random forest) > * some mentions of algorithms (eg kNN, gradient boosting etc) are better to > be linked to respective introductory articles in order to help less > experienced users easier grasp the examples > * presence of some examples doesn't look justified (eg LocalDatasetExample) > * logging in some examples looks sub-optimal, either too brief or too lengthy -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9348) ML examples improvements, follow-up to IGNITE-9297
Oleg Ignatenko created IGNITE-9348: -- Summary: ML examples improvements, follow-up to IGNITE-9297 Key: IGNITE-9348 URL: https://issues.apache.org/jira/browse/IGNITE-9348 Project: Ignite Issue Type: Task Components: ml Affects Versions: 2.6 Reporter: Oleg Ignatenko After IGNITE-9297 was resolved, ML examples were discussed with some folks ([~skozlov], [~avolkov], [~chief]) in order to check if some other improvements may be desired. This ticket is to address obtained feedback. List of points that look worth taking care of includes (but is not limited to): * some examples javadocs still looks like missing details (eg random forest) * some mentions of algorithms (eg kNN, gradient boosting etc) are better to be linked to respective introductory articles in order to help less experienced users easier grasp the examples * presence of some examples doesn't look justified (eg LocalDatasetExample) * logging in some examples looks sub-optimal, either too brief or too lengthy -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9318) SQL system view for list of baseline topology nodes
[
https://issues.apache.org/jira/browse/IGNITE-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588905#comment-16588905
]
Vladimir Ozerov edited comment on IGNITE-9318 at 8/22/18 2:19 PM:
--
[~alex_pl], my comments:
# We avoid abbreviations in user-facing parts of the system, hence
{{BLT_NODES}} name is not valid. Let's use {{BASELINE_TOPOLOGY}} instead (or
{{BASELINE_TOPOLOGY_NODES}}, {{BASELINE_NODES)}}, as it maps well to other
parts of Ignite's API.
# {{clusterState().hasBaselineTopology()}} check and subsequent
{{clusterState().baselineTopology().consistentIds()}} call are not atomic, so
you may get NPR here. Instead, it is better to get baseline topology and check
it for {{null}}
was (Author: vozerov):
[~alex_pl], my comments:
# We avoid abbreviations in user-facing parts of the system, hence
{{BLT_NODES}} name is not valid. Let's use {{BASELINE_TOPOLOGY}} instead (or
{{BASELINE_TOPOLOGY_NODES}}, {{BASELINE_NODES}}, as it maps well to other parts
of Ignite's API.
# {{clusterState().hasBaselineTopology()}} check and subsequent
{{clusterState().baselineTopology().consistentIds()}} call are not atomic, so
you may get NPR here. Instead, it is better to get baseline topology and check
it for {{null}}
> SQL system view for list of baseline topology nodes
> ---
>
> Key: IGNITE-9318
> URL: https://issues.apache.org/jira/browse/IGNITE-9318
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: iep-13
>
> Implement SQL system view to show list of baseline topology nodes. View must
> contain information about node consistentId and online/offline status.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9318) SQL system view for list of baseline topology nodes
[
https://issues.apache.org/jira/browse/IGNITE-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588905#comment-16588905
]
Vladimir Ozerov edited comment on IGNITE-9318 at 8/22/18 2:18 PM:
--
[~alex_pl], my comments:
# We avoid abbreviations in user-facing parts of the system, hence
{{BLT_NODES}} name is not valid. Let's use {{BASELINE_TOPOLOGY}} instead (or
{{BASELINE_TOPOLOGY_NODES}}, {{BASELINE_NODES}}, as it maps well to other parts
of Ignite's API.
# {{clusterState().hasBaselineTopology()}} check and subsequent
{{clusterState().baselineTopology().consistentIds()}} call are not atomic, so
you may get NPR here. Instead, it is better to get baseline topology and check
if tor \{{null}}
was (Author: vozerov):
[~alex_pl], my comments:
# We avoid abbreviations in user-facing parts of the system, hence
{{BLT_NODES}} name is not valid. Let's use \{{BASELINE_TOPOLOGY}} instead (or
\{{BASELINE_TOPOLOGY_NODES}}, \{{BASELINE_NODES}}, as it maps well to other
parts of Ignite's API.
# {\{clusterState().hasBaselineTopology()}} check and subsequent
\{{clusterState().baselineTopology().consistentIds()}} call are not atomic, so
you may get NPR here. Instead, it is better to get baseline topology and check
if tor \{{null}}
> SQL system view for list of baseline topology nodes
> ---
>
> Key: IGNITE-9318
> URL: https://issues.apache.org/jira/browse/IGNITE-9318
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: iep-13
>
> Implement SQL system view to show list of baseline topology nodes. View must
> contain information about node consistentId and online/offline status.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9318) SQL system view for list of baseline topology nodes
[
https://issues.apache.org/jira/browse/IGNITE-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588905#comment-16588905
]
Vladimir Ozerov edited comment on IGNITE-9318 at 8/22/18 2:18 PM:
--
[~alex_pl], my comments:
# We avoid abbreviations in user-facing parts of the system, hence
{{BLT_NODES}} name is not valid. Let's use {{BASELINE_TOPOLOGY}} instead (or
{{BASELINE_TOPOLOGY_NODES}}, {{BASELINE_NODES}}, as it maps well to other parts
of Ignite's API.
# {{clusterState().hasBaselineTopology()}} check and subsequent
{{clusterState().baselineTopology().consistentIds()}} call are not atomic, so
you may get NPR here. Instead, it is better to get baseline topology and check
it for {{null}}
was (Author: vozerov):
[~alex_pl], my comments:
# We avoid abbreviations in user-facing parts of the system, hence
{{BLT_NODES}} name is not valid. Let's use {{BASELINE_TOPOLOGY}} instead (or
{{BASELINE_TOPOLOGY_NODES}}, {{BASELINE_NODES}}, as it maps well to other parts
of Ignite's API.
# {{clusterState().hasBaselineTopology()}} check and subsequent
{{clusterState().baselineTopology().consistentIds()}} call are not atomic, so
you may get NPR here. Instead, it is better to get baseline topology and check
if tor \{{null}}
> SQL system view for list of baseline topology nodes
> ---
>
> Key: IGNITE-9318
> URL: https://issues.apache.org/jira/browse/IGNITE-9318
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: iep-13
>
> Implement SQL system view to show list of baseline topology nodes. View must
> contain information about node consistentId and online/offline status.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8640) If first createCache fail - Ignite is freezing on next createCache
[
https://issues.apache.org/jira/browse/IGNITE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588870#comment-16588870
]
Vladimir Ozerov edited comment on IGNITE-8640 at 8/22/18 1:55 PM:
--
[~NIzhikov], [~garus.d.g],
Igniters,
Please also pay attention to IGNITE-9347. This might be complete duplicate, but
I am not sure whether this ticket covers described situation as well. I see at
least two problems:
# In my case exchange worker fails due to assertion, not due to unhandled
exception from {{GridCacheProcessor#validate}}, as IGNITE-1094 appears to
already handle this error.
# I think it makes sense to additionally validate cache configuration
{{before}} it is sent through custom discovery message. This way, 99%
validation problems will be handled without involving exchange worker at all.
Probably the same {{GridCacheProcessor#validate}} method may be used here. The
only thing that concerns me is instantiation of cache store inside this method.
Need to understand whether it is legal or not (I think it is ok).
was (Author: vozerov):
[~NIzhikov], [~garus.d.g],
Igniters,
Please also pay attention to IGNITE-9347. This might be complete duplicate, but
I am not sure whether this ticket covers described situation as well. I see at
least two problems:
# In my case exchange worker fails due to assertion, not due to unhandled
exception from \{{GridCacheProcessor#validate}}, as IGNITE-1094 appears to
already handle this error.
# I think it makes to additionally validate cache configuration \{{before}} it
is sent through custom discovery message. This way, 99% validation problems
will be handled without involving exchange worker at all. Probably the same
\{{GridCacheProcessor#validate}} method may be used here. The only thing that
concerns me is instantiation of cache store inside this method. Need to
understand whether it is legal or not (I think it is ok).
> If first createCache fail - Ignite is freezing on next createCache
> --
>
> Key: IGNITE-8640
> URL: https://issues.apache.org/jira/browse/IGNITE-8640
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Nikolay Izhikov
>Assignee: Denis Garus
>Priority: Critical
> Fix For: 2.7
>
>
> If first {{createCache}} operation fails on some condition inside
> {{GridCacheProcessor#validate}} then second {{createCache}} will freeze
> forever.
> Reproducer:
> {code:java}
> package org.apache.ignite.internal.processors.cache;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.IgniteCheckedException;
> import org.apache.ignite.cache.eviction.fifo.FifoEvictionPolicy;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.testframework.GridTestUtils;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> public class CreateCacheFreezeTest extends GridCommonAbstractTest {
> public void testCreateEncryptedNotPersistedCacheFail() throws Exception {
> IgniteEx ignite = startGrid(0);
>
> GridTestUtils.assertThrowsWithCause(() -> {
> CacheConfiguration cc = new
> CacheConfiguration<>("failed");
> cc.setEvictionPolicy(new FifoEvictionPolicy());
> cc.setOnheapCacheEnabled(false);
> ignite.createCache(cc);
> return 0;
> }, IgniteCheckedException.class);
> IgniteCache cache = ignite.createCache(new
> CacheConfiguration<>("default"));
> assertNotNull(cache);
> }
> }
> {code}
> Log message:
> {noformat}
> [2018-05-29
> 16:38:11,958][ERROR][exchange-worker-#38%cache.CreateCacheFreezeTest0%][GridDhtPartitionsExchangeFuture]
> Failed to reinitialize local partitions (preloading will be stopped):
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=1,
> minorTopVer=1], discoEvt=DiscoveryCustomEvent
> [customMsg=DynamicCacheChangeBatch
> [id=67cce1ca361-993dd9c2-f4fe-443b-af43-27e06424e1b0,
> reqs=[DynamicCacheChangeRequest [cacheName=failed, hasCfg=true,
> nodeId=a525b74c-aec5-4c62-855a-ff96ef30, clientStartOnly=false,
> stop=false, destroy=false, disabledAfterStartfalse]],
> exchangeActions=ExchangeActions [startCaches=[failed], stopCaches=null,
> startGrps=[failed], stopGrps=[], resetParts=null, stateChangeRequest=null],
> startCaches=false], affTopVer=AffinityTopologyVersion [topVer=1,
> minorTopVer=1], super=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=a525b74c-aec5-4c62-855a-ff96ef30, addrs=[127.0.0.1],
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
> lastExchangeTime=1527601090538, loc=true, ver=2.5.0#19700101-sha1:,
> isClient=false],
[jira] [Updated] (IGNITE-9347) Attempt to start a dynamic cache with invalid configuration leads to exchange worker death
[
https://issues.apache.org/jira/browse/IGNITE-9347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-9347:
Description:
Reproducer - {{SqlIllegalSchemaSelfTest}}. Technically, this test pass. But
note the following:
1) See logs of {{*Dynamic}} tests - instead of normal stop, node gets killed by
failure detector:
{code:java}
[2018-08-22
14:20:39,777][ERROR][exchange-worker-#77%query.SqlIllegalSchemaSelfTest%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=class o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext
[type=SYSTEM_WORKER_TERMINATION, err=java.lang.AssertionError: stopping=true,
groupName=null, caches=[]]]
java.lang.AssertionError: stopping=true, groupName=null, caches=[]
at
org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:371){code}
2) Similar behavior is observed if one tries to start caches with invalid
configuration twice. Pick any {{*Dynamic}} test and just copy/paste
{{GridTestUtils.assertThrows}} logic one after another. Expected - two expected
exceptions, actual - node is killed.
Possibly duplicate of IGNITE-8640 (need to double-check)
was:
Reproducer - {{SqlIllegalSchemaSelfTest}}. Technically, this test pass. But
note the following:
1) See logs of {{*Dynamic}} tests - instead of normal stop, node gets killed by
failure detector:
{code:java}
[2018-08-22
14:20:39,777][ERROR][exchange-worker-#77%query.SqlIllegalSchemaSelfTest%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=class o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext
[type=SYSTEM_WORKER_TERMINATION, err=java.lang.AssertionError: stopping=true,
groupName=null, caches=[]]]
java.lang.AssertionError: stopping=true, groupName=null, caches=[]
at
org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:371){code}
2) Similar behavior is observed if one tries to start caches with invalid
configuration twice. Pick any {{*Dynamic}} test and just copy/paste
{{GridTestUtils.assertThrows}} logic one after another. Expected - two expected
exceptions, actual - node is killed.
> Attempt to start a dynamic cache with invalid configuration leads to exchange
> worker death
> --
>
> Key: IGNITE-9347
> URL: https://issues.apache.org/jira/browse/IGNITE-9347
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.5, 2.6
>Reporter: Vladimir Ozerov
>Priority: Blocker
> Fix For: 2.7
>
>
> Reproducer - {{SqlIllegalSchemaSelfTest}}. Technically, this test pass. But
> note the following:
> 1) See logs of {{*Dynamic}} tests - instead of normal stop, node gets killed
> by failure detector:
> {code:java}
> [2018-08-22
> 14:20:39,777][ERROR][exchange-worker-#77%query.SqlIllegalSchemaSelfTest%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=class o.a.i.failure.NoOpFailureHandler,
> failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION,
> err=java.lang.AssertionError: stopping=true, groupName=null, caches=[]]]
> java.lang.AssertionError: stopping=true, groupName=null, caches=[]
> at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:371){code}
> 2) Similar behavior is observed if one tries to start caches with invalid
> configuration twice. Pick any {{*Dynamic}} test and just copy/paste
> {{GridTestUtils.assertThrows}} logic one after another. Expected - two
> expected exceptions, actual - node is killed.
>
> Possibly duplicate of IGNITE-8640 (need to double-check)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8640) If first createCache fail - Ignite is freezing on next createCache
[
https://issues.apache.org/jira/browse/IGNITE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588870#comment-16588870
]
Vladimir Ozerov commented on IGNITE-8640:
-
[~NIzhikov], [~garus.d.g],
Igniters,
Please also pay attention to IGNITE-9347. This might be complete duplicate, but
I am not sure whether this ticket covers described situation as well. I see at
least two problems:
# In my case exchange worker fails due to assertion, not due to unhandled
exception from \{{GridCacheProcessor#validate}}, as IGNITE-1094 appears to
already handle this error.
# I think it makes to additionally validate cache configuration \{{before}} it
is sent through custom discovery message. This way, 99% validation problems
will be handled without involving exchange worker at all. Probably the same
\{{GridCacheProcessor#validate}} method may be used here. The only thing that
concerns me is instantiation of cache store inside this method. Need to
understand whether it is legal or not (I think it is ok).
> If first createCache fail - Ignite is freezing on next createCache
> --
>
> Key: IGNITE-8640
> URL: https://issues.apache.org/jira/browse/IGNITE-8640
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Nikolay Izhikov
>Assignee: Denis Garus
>Priority: Critical
> Fix For: 2.7
>
>
> If first {{createCache}} operation fails on some condition inside
> {{GridCacheProcessor#validate}} then second {{createCache}} will freeze
> forever.
> Reproducer:
> {code:java}
> package org.apache.ignite.internal.processors.cache;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.IgniteCheckedException;
> import org.apache.ignite.cache.eviction.fifo.FifoEvictionPolicy;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.testframework.GridTestUtils;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> public class CreateCacheFreezeTest extends GridCommonAbstractTest {
> public void testCreateEncryptedNotPersistedCacheFail() throws Exception {
> IgniteEx ignite = startGrid(0);
>
> GridTestUtils.assertThrowsWithCause(() -> {
> CacheConfiguration cc = new
> CacheConfiguration<>("failed");
> cc.setEvictionPolicy(new FifoEvictionPolicy());
> cc.setOnheapCacheEnabled(false);
> ignite.createCache(cc);
> return 0;
> }, IgniteCheckedException.class);
> IgniteCache cache = ignite.createCache(new
> CacheConfiguration<>("default"));
> assertNotNull(cache);
> }
> }
> {code}
> Log message:
> {noformat}
> [2018-05-29
> 16:38:11,958][ERROR][exchange-worker-#38%cache.CreateCacheFreezeTest0%][GridDhtPartitionsExchangeFuture]
> Failed to reinitialize local partitions (preloading will be stopped):
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=1,
> minorTopVer=1], discoEvt=DiscoveryCustomEvent
> [customMsg=DynamicCacheChangeBatch
> [id=67cce1ca361-993dd9c2-f4fe-443b-af43-27e06424e1b0,
> reqs=[DynamicCacheChangeRequest [cacheName=failed, hasCfg=true,
> nodeId=a525b74c-aec5-4c62-855a-ff96ef30, clientStartOnly=false,
> stop=false, destroy=false, disabledAfterStartfalse]],
> exchangeActions=ExchangeActions [startCaches=[failed], stopCaches=null,
> startGrps=[failed], stopGrps=[], resetParts=null, stateChangeRequest=null],
> startCaches=false], affTopVer=AffinityTopologyVersion [topVer=1,
> minorTopVer=1], super=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=a525b74c-aec5-4c62-855a-ff96ef30, addrs=[127.0.0.1],
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
> lastExchangeTime=1527601090538, loc=true, ver=2.5.0#19700101-sha1:,
> isClient=false], topVer=1, nodeId8=a525b74c, msg=null,
> type=DISCOVERY_CUSTOM_EVT, tstamp=1527601091938]], nodeId=a525b74c,
> evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: stopping=false, groupName=null, caches=[]
> at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:375)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.(GridDhtLocalPartition.java:197)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.getOrCreatePartition(GridDhtPartitionTopologyImpl.java:828)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.initPartitions(GridDhtPartitionTopologyImpl.java:369)
> at
>
[jira] [Resolved] (IGNITE-1094) Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization
[ https://issues.apache.org/jira/browse/IGNITE-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-1094. - Resolution: Fixed > Ignite.createCache(CacheConfiguration) hangs if some exception occurs during > cache initialization > - > > Key: IGNITE-1094 > URL: https://issues.apache.org/jira/browse/IGNITE-1094 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Sergey Evdokimov >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: Muted_test > Fix For: 2.7 > > > User can pass broken configuration, for example, store factory that throws > exception from create() method. I created test to demonstrate the problem. > See IgniteDynamicCacheStartSelfTest#testBrokenStoreFactory in 'ignite-1094' > branch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-1094) Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization
[ https://issues.apache.org/jira/browse/IGNITE-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-1094. --- > Ignite.createCache(CacheConfiguration) hangs if some exception occurs during > cache initialization > - > > Key: IGNITE-1094 > URL: https://issues.apache.org/jira/browse/IGNITE-1094 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Sergey Evdokimov >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: Muted_test > Fix For: 2.7 > > > User can pass broken configuration, for example, store factory that throws > exception from create() method. I created test to demonstrate the problem. > See IgniteDynamicCacheStartSelfTest#testBrokenStoreFactory in 'ignite-1094' > branch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-1094) Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization
[ https://issues.apache.org/jira/browse/IGNITE-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588858#comment-16588858 ] Vladimir Ozerov commented on IGNITE-1094: - Created blocker for 2.7 - https://issues.apache.org/jira/browse/IGNITE-9347 Closing this one. > Ignite.createCache(CacheConfiguration) hangs if some exception occurs during > cache initialization > - > > Key: IGNITE-1094 > URL: https://issues.apache.org/jira/browse/IGNITE-1094 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Sergey Evdokimov >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: Muted_test > Fix For: 2.7 > > > User can pass broken configuration, for example, store factory that throws > exception from create() method. I created test to demonstrate the problem. > See IgniteDynamicCacheStartSelfTest#testBrokenStoreFactory in 'ignite-1094' > branch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9347) Attempt to start a dynamic cache with invalid configuration leads to exchange worker death
Vladimir Ozerov created IGNITE-9347:
---
Summary: Attempt to start a dynamic cache with invalid
configuration leads to exchange worker death
Key: IGNITE-9347
URL: https://issues.apache.org/jira/browse/IGNITE-9347
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.6, 2.5
Reporter: Vladimir Ozerov
Fix For: 2.7
Reproducer - {{SqlIllegalSchemaSelfTest}}. Technically, this test pass. But
note the following:
1) See logs of {{*Dynamic}} tests - instead of normal stop, node gets killed by
failure detector:
{code:java}
[2018-08-22
14:20:39,777][ERROR][exchange-worker-#77%query.SqlIllegalSchemaSelfTest%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=class o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext
[type=SYSTEM_WORKER_TERMINATION, err=java.lang.AssertionError: stopping=true,
groupName=null, caches=[]]]
java.lang.AssertionError: stopping=true, groupName=null, caches=[]
at
org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:371){code}
2) Similar behavior is observed if one tries to start caches with invalid
configuration twice. Pick any {{*Dynamic}} test and just copy/paste
{{GridTestUtils.assertThrows}} logic one after another. Expected - two expected
exceptions, actual - node is killed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9346) md5 should be removed from release
[ https://issues.apache.org/jira/browse/IGNITE-9346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-9346: - Fix Version/s: 2.7 > md5 should be removed from release > -- > > Key: IGNITE-9346 > URL: https://issues.apache.org/jira/browse/IGNITE-9346 > Project: Ignite > Issue Type: Task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Fix For: 2.7 > > > The board communicated the following release policy changes: > -- for new releases : > -- you MUST supply a SHA-256 and/or SHA-512 file > -- you SHOULD NOT supply MD5 or SHA-1 files > So, we should get rid of md5 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9346) md5 should be removed from release
Anton Vinogradov created IGNITE-9346: Summary: md5 should be removed from release Key: IGNITE-9346 URL: https://issues.apache.org/jira/browse/IGNITE-9346 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Assignee: Anton Vinogradov The board communicated the following release policy changes: -- for new releases : -- you MUST supply a SHA-256 and/or SHA-512 file -- you SHOULD NOT supply MD5 or SHA-1 files So, we should get rid of md5 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-1094) Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization
[ https://issues.apache.org/jira/browse/IGNITE-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588823#comment-16588823 ] Vladimir Ozerov commented on IGNITE-1094: - [~agura], >From what I see it is in 2.7, which is not released yet. > Ignite.createCache(CacheConfiguration) hangs if some exception occurs during > cache initialization > - > > Key: IGNITE-1094 > URL: https://issues.apache.org/jira/browse/IGNITE-1094 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Sergey Evdokimov >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: Muted_test > Fix For: 2.7 > > > User can pass broken configuration, for example, store factory that throws > exception from create() method. I created test to demonstrate the problem. > See IgniteDynamicCacheStartSelfTest#testBrokenStoreFactory in 'ignite-1094' > branch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9246) Transactions can wait for topology future on remap for a long time even if timeout is set.
[ https://issues.apache.org/jira/browse/IGNITE-9246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588796#comment-16588796 ] Alexei Scherbakov commented on IGNITE-9246: --- [~Jokser], https://reviews.ignite.apache.org/ignite/review/IGNT-CR-735 > Transactions can wait for topology future on remap for a long time even if > timeout is set. > -- > > Key: IGNITE-9246 > URL: https://issues.apache.org/jira/browse/IGNITE-9246 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov >Priority: Major > Fix For: 2.7 > > > This is possible if long PME is occured during tx remap phase. > Fix: wait for new topology on remap with timeout if set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8971) GridRestProcessor should propagate error message
[ https://issues.apache.org/jira/browse/IGNITE-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588794#comment-16588794 ] Alexey Goncharuk commented on IGNITE-8971: -- [~andmed] In the latest TC run there are 171 test failures. This seems a bit odd, so I re-launched the TC. > GridRestProcessor should propagate error message > > > Key: IGNITE-8971 > URL: https://issues.apache.org/jira/browse/IGNITE-8971 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Andrew Medvedev >Assignee: Andrew Medvedev >Priority: Major > > GridRestProcessor should propagate error message (stack trace) for handling > disk full error messages -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9248) CPP: Support Clang compiler
[ https://issues.apache.org/jira/browse/IGNITE-9248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588789#comment-16588789 ] ASF GitHub Bot commented on IGNITE-9248: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4527 > CPP: Support Clang compiler > --- > > Key: IGNITE-9248 > URL: https://issues.apache.org/jira/browse/IGNITE-9248 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.7 > > > Currently Ignite C++ can not be compiled with the clang compiler. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-1094) Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization
[ https://issues.apache.org/jira/browse/IGNITE-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588787#comment-16588787 ] Andrey Gura commented on IGNITE-1094: - [~vozerov] It's bad idea to reopen issue that was included in some release. Could you please create new ticket and close this one? > Ignite.createCache(CacheConfiguration) hangs if some exception occurs during > cache initialization > - > > Key: IGNITE-1094 > URL: https://issues.apache.org/jira/browse/IGNITE-1094 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Sergey Evdokimov >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: Muted_test > Fix For: 2.7 > > > User can pass broken configuration, for example, store factory that throws > exception from create() method. I created test to demonstrate the problem. > See IgniteDynamicCacheStartSelfTest#testBrokenStoreFactory in 'ignite-1094' > branch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9248) CPP: Support Clang compiler
[ https://issues.apache.org/jira/browse/IGNITE-9248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588782#comment-16588782 ] Igor Sapego commented on IGNITE-9248: - [~tledkov-gridgain] done, everything pass. > CPP: Support Clang compiler > --- > > Key: IGNITE-9248 > URL: https://issues.apache.org/jira/browse/IGNITE-9248 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.7 > > > Currently Ignite C++ can not be compiled with the clang compiler. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9290) Make remove explicit locks async when node left.
[ https://issues.apache.org/jira/browse/IGNITE-9290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-9290: - Labels: deadlock iep-25 (was: deadlock) > Make remove explicit locks async when node left. > > > Key: IGNITE-9290 > URL: https://issues.apache.org/jira/browse/IGNITE-9290 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Labels: deadlock, iep-25 > > GridCacheMvccManager.removeExplicitNodeLocks() run synchronously in discovery > and exchange threads. This introduce unnecessary delays in discovery and > exchange process. > Also, this may cause a deadlock on node stop if user transaction holds an > entry lock and awaits some Ignite manager response (e.g. cache store or DR or > CQ), as manager stops right after last exchange has finished so managers > can't detect node is stopping. > > [1] > [http://apache-ignite-developers.2346864.n4.nabble.com/Synchronous-tx-entries-unlocking-in-discovery-exchange-threads-td33827.html] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9290) Make remove explicit locks async when node left.
[ https://issues.apache.org/jira/browse/IGNITE-9290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-9290: - Labels: deadlock (was: ) > Make remove explicit locks async when node left. > > > Key: IGNITE-9290 > URL: https://issues.apache.org/jira/browse/IGNITE-9290 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Labels: deadlock > > GridCacheMvccManager.removeExplicitNodeLocks() run synchronously in discovery > and exchange threads. This introduce unnecessary delays in discovery and > exchange process. > Also, this may cause a deadlock on node stop if user transaction holds an > entry lock and awaits some Ignite manager response (e.g. cache store or DR or > CQ), as manager stops right after last exchange has finished so managers > can't detect node is stopping. > > [1] > [http://apache-ignite-developers.2346864.n4.nabble.com/Synchronous-tx-entries-unlocking-in-discovery-exchange-threads-td33827.html] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9327) Client Nodes hangs because client reconnect not handled
[ https://issues.apache.org/jira/browse/IGNITE-9327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588752#comment-16588752 ] ASF GitHub Bot commented on IGNITE-9327: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4579 > Client Nodes hangs because client reconnect not handled > > > Key: IGNITE-9327 > URL: https://issues.apache.org/jira/browse/IGNITE-9327 > Project: Ignite > Issue Type: Test >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > Reproduced by > IgniteCacheClientReconnectTest#testClientInForceServerModeStopsOnExchangeHistoryExhaustion > If IgniteNeedReconnectException happend we should stop the node if reconnect > doesn't supported. But after > https://issues.apache.org/jira/browse/IGNITE-8673 we started to ignore this > case. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9327) Client Nodes hangs because client reconnect not handled
[ https://issues.apache.org/jira/browse/IGNITE-9327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9327: - Labels: MakeTeamcityGreenAgain (was: ) > Client Nodes hangs because client reconnect not handled > > > Key: IGNITE-9327 > URL: https://issues.apache.org/jira/browse/IGNITE-9327 > Project: Ignite > Issue Type: Test >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > Reproduced by > IgniteCacheClientReconnectTest#testClientInForceServerModeStopsOnExchangeHistoryExhaustion > If IgniteNeedReconnectException happend we should stop the node if reconnect > doesn't supported. But after > https://issues.apache.org/jira/browse/IGNITE-8673 we started to ignore this > case. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9327) Client Nodes hangs because client reconnect not handled
[ https://issues.apache.org/jira/browse/IGNITE-9327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9327: - Fix Version/s: 2.7 > Client Nodes hangs because client reconnect not handled > > > Key: IGNITE-9327 > URL: https://issues.apache.org/jira/browse/IGNITE-9327 > Project: Ignite > Issue Type: Test >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.7 > > > Reproduced by > IgniteCacheClientReconnectTest#testClientInForceServerModeStopsOnExchangeHistoryExhaustion > If IgniteNeedReconnectException happend we should stop the node if reconnect > doesn't supported. But after > https://issues.apache.org/jira/browse/IGNITE-8673 we became to ignore this > case. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9327) Client Nodes hangs because client reconnect not handled
[ https://issues.apache.org/jira/browse/IGNITE-9327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9327: - Description: Reproduced by IgniteCacheClientReconnectTest#testClientInForceServerModeStopsOnExchangeHistoryExhaustion If IgniteNeedReconnectException happend we should stop the node if reconnect doesn't supported. But after https://issues.apache.org/jira/browse/IGNITE-8673 we started to ignore this case. was: Reproduced by IgniteCacheClientReconnectTest#testClientInForceServerModeStopsOnExchangeHistoryExhaustion If IgniteNeedReconnectException happend we should stop the node if reconnect doesn't supported. But after https://issues.apache.org/jira/browse/IGNITE-8673 we became to ignore this case. > Client Nodes hangs because client reconnect not handled > > > Key: IGNITE-9327 > URL: https://issues.apache.org/jira/browse/IGNITE-9327 > Project: Ignite > Issue Type: Test >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.7 > > > Reproduced by > IgniteCacheClientReconnectTest#testClientInForceServerModeStopsOnExchangeHistoryExhaustion > If IgniteNeedReconnectException happend we should stop the node if reconnect > doesn't supported. But after > https://issues.apache.org/jira/browse/IGNITE-8673 we started to ignore this > case. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9327) Client Nodes hangs because client reconnect not handled
[ https://issues.apache.org/jira/browse/IGNITE-9327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9327: - Ignite Flags: (was: Docs Required) > Client Nodes hangs because client reconnect not handled > > > Key: IGNITE-9327 > URL: https://issues.apache.org/jira/browse/IGNITE-9327 > Project: Ignite > Issue Type: Test >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.7 > > > Reproduced by > IgniteCacheClientReconnectTest#testClientInForceServerModeStopsOnExchangeHistoryExhaustion > If IgniteNeedReconnectException happend we should stop the node if reconnect > doesn't supported. But after > https://issues.apache.org/jira/browse/IGNITE-8673 we became to ignore this > case. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (IGNITE-1094) Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization
[ https://issues.apache.org/jira/browse/IGNITE-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reopened IGNITE-1094: - > Ignite.createCache(CacheConfiguration) hangs if some exception occurs during > cache initialization > - > > Key: IGNITE-1094 > URL: https://issues.apache.org/jira/browse/IGNITE-1094 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Sergey Evdokimov >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: Muted_test > Fix For: 2.7 > > > User can pass broken configuration, for example, store factory that throws > exception from create() method. I created test to demonstrate the problem. > See IgniteDynamicCacheStartSelfTest#testBrokenStoreFactory in 'ignite-1094' > branch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-1094) Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization
[
https://issues.apache.org/jira/browse/IGNITE-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588722#comment-16588722
]
Vladimir Ozerov edited comment on IGNITE-1094 at 8/22/18 11:25 AM:
---
[~agura], [~Jokser], [~agoncharuk], [~slava.koptilin], [~dpavlov],
Igniters,
It seems that real problem is not fixed. This is true, that after the fix cache
with invalid configuration no longer hangs a client. However, it breaks
exchange worker on other nodes, and moves it into unrecoverable state. Any
subsequent exchange-related operation, such as node stop or cache start/stop
will kill the node. Essentially, we just delayed exchange worker death/hang a
bit.
Reproducer - {{SqlIllegalSchemaSelfTest}}. Technically, this test pass. But
note the following:
1) See logs of {{*Dynamic}} tests - instead of normal stop, node gets killed by
failure detector:
{code:java}
[2018-08-22
14:20:39,777][ERROR][exchange-worker-#77%query.SqlIllegalSchemaSelfTest%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=class o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext
[type=SYSTEM_WORKER_TERMINATION, err=java.lang.AssertionError: stopping=true,
groupName=null, caches=[]]]
java.lang.AssertionError: stopping=true, groupName=null, caches=[]
at
org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:371){code}
2) Similar behavior is observed if one tries to start caches with invalid
configuration twice. Pick any {{*Dynamic}} test and just copy/paste
{{GridTestUtils.assertThrows}} logic one after another. Expected - two expected
exceptions, actual - node is killed.
Reopening the ticket. Please feel free to create another ticket to handle it,
if you find it more convenient. But my opinion is that we should fix it here,
because cluster is broken and it is just a matter of chance that we didn't spot
it in original test.
was (Author: vozerov):
[~agura], [~Jokser], [~agoncharuk], [~slava.koptilin], [~dpavlov],
Igniters,
It seems that real problem is not fixed. This is true, that after the fix cache
with invalid configuration no longer hangs a client. However, it breaks
exchange worker on other nodes, and moves it into unrecoverable state. Any
subsequent exchange-related operation, such as node stop or cache start/stop
will kill the node. Essentially, we just delayed exchange worker death/hang a
bit.
Reproducer - \{{SqlIllegalSchemaSelfTest}}. Technically, this test pass. But
note the following:
# See logs of \{{*Dynamic}} tests - instead of normal stop, node gets killed
by failure detector:
{code:java}
[2018-08-22
14:20:39,777][ERROR][exchange-worker-#77%query.SqlIllegalSchemaSelfTest%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=class o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext
[type=SYSTEM_WORKER_TERMINATION, err=java.lang.AssertionError: stopping=true,
groupName=null, caches=[]]]
java.lang.AssertionError: stopping=true, groupName=null, caches=[]
at
org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:371){code}
# Similar behavior is observed if one tries to start caches with invalid
configuration twice. Pick any \{{*Dynamic}} test and just copy/paste
\{{GridTestUtils.assertThrows}} logic one after another. Expected - two
expected exceptions, actual - node is killed.
Reopening the ticket. Please feel free to create another ticket to handle it,
if you find it more convenient. But my opinion is that we should fix it here,
because cluster is broken and it is just a matter of chance that we didn't spot
it in original test.
> Ignite.createCache(CacheConfiguration) hangs if some exception occurs during
> cache initialization
> -
>
> Key: IGNITE-1094
> URL: https://issues.apache.org/jira/browse/IGNITE-1094
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Sergey Evdokimov
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Labels: Muted_test
> Fix For: 2.7
>
>
> User can pass broken configuration, for example, store factory that throws
> exception from create() method. I created test to demonstrate the problem.
> See IgniteDynamicCacheStartSelfTest#testBrokenStoreFactory in 'ignite-1094'
> branch
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-1094) Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization
[
https://issues.apache.org/jira/browse/IGNITE-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588722#comment-16588722
]
Vladimir Ozerov commented on IGNITE-1094:
-
[~agura], [~Jokser], [~agoncharuk], [~slava.koptilin], [~dpavlov],
Igniters,
It seems that real problem is not fixed. This is true, that after the fix cache
with invalid configuration no longer hangs a client. However, it breaks
exchange worker on other nodes, and moves it into unrecoverable state. Any
subsequent exchange-related operation, such as node stop or cache start/stop
will kill the node. Essentially, we just delayed exchange worker death/hang a
bit.
Reproducer - \{{SqlIllegalSchemaSelfTest}}. Technically, this test pass. But
note the following:
# See logs of \{{*Dynamic}} tests - instead of normal stop, node gets killed
by failure detector:
{code:java}
[2018-08-22
14:20:39,777][ERROR][exchange-worker-#77%query.SqlIllegalSchemaSelfTest%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=class o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext
[type=SYSTEM_WORKER_TERMINATION, err=java.lang.AssertionError: stopping=true,
groupName=null, caches=[]]]
java.lang.AssertionError: stopping=true, groupName=null, caches=[]
at
org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:371){code}
# Similar behavior is observed if one tries to start caches with invalid
configuration twice. Pick any \{{*Dynamic}} test and just copy/paste
\{{GridTestUtils.assertThrows}} logic one after another. Expected - two
expected exceptions, actual - node is killed.
Reopening the ticket. Please feel free to create another ticket to handle it,
if you find it more convenient. But my opinion is that we should fix it here,
because cluster is broken and it is just a matter of chance that we didn't spot
it in original test.
> Ignite.createCache(CacheConfiguration) hangs if some exception occurs during
> cache initialization
> -
>
> Key: IGNITE-1094
> URL: https://issues.apache.org/jira/browse/IGNITE-1094
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Sergey Evdokimov
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Labels: Muted_test
> Fix For: 2.7
>
>
> User can pass broken configuration, for example, store factory that throws
> exception from create() method. I created test to demonstrate the problem.
> See IgniteDynamicCacheStartSelfTest#testBrokenStoreFactory in 'ignite-1094'
> branch
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9262) Web console: missed generation of query entities for imported domain modelss
[ https://issues.apache.org/jira/browse/IGNITE-9262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9262: - Fix Version/s: 2.7 > Web console: missed generation of query entities for imported domain modelss > > > Key: IGNITE-9262 > URL: https://issues.apache.org/jira/browse/IGNITE-9262 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > Time Spent: 20m > Remaining Estimate: 0h > > # Open configuration overview. > # Import cluster from dabase. > # Open cluster configuration. > # Download generated project. > Downloaded project does not contains generated QueryEntities, that are > visible in project preview. > They appear on configuration page refresh. > Second problem: > # Import domain models with new cluster creation. > # Quickly open cluster > # Quickly Save and download cluster. > Error in log is received: angular.js:13018 GET > [http://localhost:9000/api/v1/configuration/5b72b9ca7396bb79794a1a9b] 500 > (Internal Server Error) > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9296) Stopping node by Failure Handler hangs up in IgniteWalFlushBackgroundSelfTest
[
https://issues.apache.org/jira/browse/IGNITE-9296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588705#comment-16588705
]
Sergey Kosarev commented on IGNITE-9296:
[~agura], well, I've updated fix to your vision and added new TC Run.
> Stopping node by Failure Handler hangs up in IgniteWalFlushBackgroundSelfTest
> --
>
> Key: IGNITE-9296
> URL: https://issues.apache.org/jira/browse/IGNITE-9296
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Kosarev
>Assignee: Sergey Kosarev
>Priority: Major
> Attachments: logs.zip
>
>
> Here are log messages:
> {code}
> [18:46:27]W: [org.apache.ignite:ignite-core] [2018-08-15
> 15:46:27,442][ERROR][main][root] Test has been timed out and will be
> interrupted (threads dump will be taken before interruption)
> [test=testFailWhileStart, timeout=6]
> {code}
> And later on all the suite also hangs up:
> {code}
> [22:22:49]E: [Step 3/4] The build Ignite Tests 2.4+ (Java 8)::PDS 2 #2184
> {buildId=1662285} has been running for more than 240 minutes. Terminating...
> Main thread locked by node-stopper:
> [18:46:27] : [Step 3/4] Thread
> [name="test-runner-#7695%wal.IgniteWalFlushBackgroundSelfTest%", id=9150,
> state=BLOCKED, blockCnt=4, waitCnt=142]
> [18:46:27] : [Step 3/4] Lock
> [object=o.a.i.i.IgnitionEx$IgniteNamedInstance@7c251f90,
> ownerName=node-stopper, ownerId=9267]
> [18:46:27] : [Step 3/4] at
> o.a.i.i.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2565)
> [18:46:27] : [Step 3/4] at
> o.a.i.i.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2557)
> [18:46:27] : [Step 3/4] at
> o.a.i.i.IgnitionEx.stop(IgnitionEx.java:374)
> [18:46:27] : [Step 3/4] at o.a.i.Ignition.stop(Ignition.java:229)
> [18:46:27] : [Step 3/4] at
> o.a.i.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1088)
> [18:46:27] : [Step 3/4] at
> o.a.i.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1131)
> [18:46:27] : [Step 3/4] at
> o.a.i.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1109)
> [18:46:27] : [Step 3/4] at
> o.a.i.i.processors.cache.persistence.db.wal.IgniteWalFlushMultiNodeFailoverAbstractSelfTest.failWhilePut(IgniteWalFlushMultiNodeFailoverAbstractSelfTest.java:213)
> [18:46:27] : [Step 3/4] at
> o.a.i.i.processors.cache.persistence.db.wal.IgniteWalFlushMultiNodeFailoverAbstractSelfTest.testFailWhileStart(IgniteWalFlushMultiNodeFailoverAbstractSelfTest.java:147)
> node-stopper waits for the wal-segment-syncer stopping
> [18:46:28]W: [org.apache.ignite:ignite-core] Thread
> [name="node-stopper", id=9267, state=WAITING, blockCnt=19, waitCnt=22]
> [18:46:28]W: [org.apache.ignite:ignite-core] Lock
> [object=java.lang.Object@5ba26eb0, ownerName=null, ownerId=-1]
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> java.lang.Object.wait(Native Method)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> java.lang.Object.wait(Object.java:502)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.util.worker.GridWorker.join(GridWorker.java:233)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.util.IgniteUtils.join(IgniteUtils.java:4692)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.processors.cache.persistence.wal.FileWriteAheadLogManager$WalSegmentSyncer.shutdown(FileWriteAheadLogManager.java:3562)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.processors.cache.persistence.wal.FileWriteAheadLogManager$WalSegmentSyncer.access$700(FileWriteAheadLogManager.java:3527)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.processors.cache.persistence.wal.FileWriteAheadLogManager.stop0(FileWriteAheadLogManager.java:578)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.processors.cache.GridCacheSharedManagerAdapter.stop(GridCacheSharedManagerAdapter.java:94)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.processors.cache.GridCacheProcessor.stop(GridCacheProcessor.java:951)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.IgniteKernal.stop0(IgniteKernal.java:2303)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.IgniteKernal.stop(IgniteKernal.java:2181)
> [18:46:28]W: [org.apache.ignite:ignite-core] at
> o.a.i.i.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2594)
> [18:46:28]W: [org.apache.ignite:ignite-core] - locked
[jira] [Assigned] (IGNITE-9262) Web console: missed generation of query entities for imported domain modelss
[ https://issues.apache.org/jira/browse/IGNITE-9262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-9262: Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) [~pkonstantinov], Please test in master. > Web console: missed generation of query entities for imported domain modelss > > > Key: IGNITE-9262 > URL: https://issues.apache.org/jira/browse/IGNITE-9262 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov >Priority: Major > Labels: web-console-configuration > Fix For: 2.7 > > Time Spent: 20m > Remaining Estimate: 0h > > # Open configuration overview. > # Import cluster from dabase. > # Open cluster configuration. > # Download generated project. > Downloaded project does not contains generated QueryEntities, that are > visible in project preview. > They appear on configuration page refresh. > Second problem: > # Import domain models with new cluster creation. > # Quickly open cluster > # Quickly Save and download cluster. > Error in log is received: angular.js:13018 GET > [http://localhost:9000/api/v1/configuration/5b72b9ca7396bb79794a1a9b] 500 > (Internal Server Error) > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9273) IgnitePdsDynamicCacheTest.testRestartAndCreate is very flaky in master
[ https://issues.apache.org/jira/browse/IGNITE-9273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9273: - Ignite Flags: (was: Docs Required) > IgnitePdsDynamicCacheTest.testRestartAndCreate is very flaky in master > --- > > Key: IGNITE-9273 > URL: https://issues.apache.org/jira/browse/IGNITE-9273 > Project: Ignite > Issue Type: Bug >Reporter: Ilya Kasnacheev >Assignee: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > > Such as: > https://ci.ignite.apache.org/viewLog.html?buildId=1655341=buildResultsDiv=IgniteTests24Java8_Pds1 > https://ci.ignite.apache.org/viewLog.html?buildId=1655880=buildResultsDiv=IgniteTests24Java8_Pds1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9262) Web console: missed generation of query entities for imported domain modelss
[ https://issues.apache.org/jira/browse/IGNITE-9262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9262: - Labels: web-console-configuration (was: ) > Web console: missed generation of query entities for imported domain modelss > > > Key: IGNITE-9262 > URL: https://issues.apache.org/jira/browse/IGNITE-9262 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > Labels: web-console-configuration > Fix For: 2.7 > > Time Spent: 20m > Remaining Estimate: 0h > > # Open configuration overview. > # Import cluster from dabase. > # Open cluster configuration. > # Download generated project. > Downloaded project does not contains generated QueryEntities, that are > visible in project preview. > They appear on configuration page refresh. > Second problem: > # Import domain models with new cluster creation. > # Quickly open cluster > # Quickly Save and download cluster. > Error in log is received: angular.js:13018 GET > [http://localhost:9000/api/v1/configuration/5b72b9ca7396bb79794a1a9b] 500 > (Internal Server Error) > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9262) Web console: missed generation of query entities for imported domain modelss
[ https://issues.apache.org/jira/browse/IGNITE-9262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9262: - Ignite Flags: (was: Docs Required) > Web console: missed generation of query entities for imported domain modelss > > > Key: IGNITE-9262 > URL: https://issues.apache.org/jira/browse/IGNITE-9262 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > Labels: web-console-configuration > Fix For: 2.7 > > Time Spent: 20m > Remaining Estimate: 0h > > # Open configuration overview. > # Import cluster from dabase. > # Open cluster configuration. > # Download generated project. > Downloaded project does not contains generated QueryEntities, that are > visible in project preview. > They appear on configuration page refresh. > Second problem: > # Import domain models with new cluster creation. > # Quickly open cluster > # Quickly Save and download cluster. > Error in log is received: angular.js:13018 GET > [http://localhost:9000/api/v1/configuration/5b72b9ca7396bb79794a1a9b] 500 > (Internal Server Error) > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9273) IgnitePdsDynamicCacheTest.testRestartAndCreate is very flaky in master
[ https://issues.apache.org/jira/browse/IGNITE-9273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk reassigned IGNITE-9273: Assignee: Alexey Goncharuk > IgnitePdsDynamicCacheTest.testRestartAndCreate is very flaky in master > --- > > Key: IGNITE-9273 > URL: https://issues.apache.org/jira/browse/IGNITE-9273 > Project: Ignite > Issue Type: Bug >Reporter: Ilya Kasnacheev >Assignee: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > > Such as: > https://ci.ignite.apache.org/viewLog.html?buildId=1655341=buildResultsDiv=IgniteTests24Java8_Pds1 > https://ci.ignite.apache.org/viewLog.html?buildId=1655880=buildResultsDiv=IgniteTests24Java8_Pds1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9279) Support custom default SQL schema name.
[ https://issues.apache.org/jira/browse/IGNITE-9279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588689#comment-16588689 ] ASF GitHub Bot commented on IGNITE-9279: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4550 > Support custom default SQL schema name. > --- > > Key: IGNITE-9279 > URL: https://issues.apache.org/jira/browse/IGNITE-9279 > Project: Ignite > Issue Type: Wish > Components: sql >Reporter: Andrew Mashenkov >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.7 > > > Default SQL schema is PUBLIC and there is no way to customize. > This may be useful when dynamic schema creation will be implemented. > Let's make default schema name configurable via node properties and then add > it to ignite configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9345) Document custom SQL schemas
Vladimir Ozerov created IGNITE-9345:
---
Summary: Document custom SQL schemas
Key: IGNITE-9345
URL: https://issues.apache.org/jira/browse/IGNITE-9345
Project: Ignite
Issue Type: Task
Components: documentation, sql
Reporter: Vladimir Ozerov
Fix For: 2.7
Key highlights:
1) DDL operations \{{CREATE TABLE}} and \{{DROP TABLE}} are no longer tied to
\{{PUBLIC}} schema. They can be executed on any schema. Need to remove this
from docs (if there is such paragraph)
2) Added a property \{{IgniteConfiguration.sqlSchemas}} which creates local
schemas with provided names.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9279) Support custom default SQL schema name.
[ https://issues.apache.org/jira/browse/IGNITE-9279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588684#comment-16588684 ] ASF GitHub Bot commented on IGNITE-9279: Github user devozerov closed the pull request at: https://github.com/apache/ignite/pull/4586 > Support custom default SQL schema name. > --- > > Key: IGNITE-9279 > URL: https://issues.apache.org/jira/browse/IGNITE-9279 > Project: Ignite > Issue Type: Wish > Components: sql >Reporter: Andrew Mashenkov >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.7 > > > Default SQL schema is PUBLIC and there is no way to customize. > This may be useful when dynamic schema creation will be implemented. > Let's make default schema name configurable via node properties and then add > it to ignite configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8157) Remove boilerplate and unused code due to grids stopping by default
[
https://issues.apache.org/jira/browse/IGNITE-8157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov reassigned IGNITE-8157:
---
Assignee: (was: Maxim Muzafarov)
> Remove boilerplate and unused code due to grids stopping by default
> ---
>
> Key: IGNITE-8157
> URL: https://issues.apache.org/jira/browse/IGNITE-8157
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.4
>Reporter: Maxim Muzafarov
>Priority: Minor
> Labels: test
> Fix For: 2.7
>
>
> Changes IGNITE-6842 guarantee us stopping all Ignite instances after test
> completion by default.
> # We should remove a lot of bolerplate code in our test-classes.
> e.g.
> {code:java|title=BaseDecisionTreeTest.java|borderStyle=solid}
> /** {@inheritDoc} */
> @Override protected void afterTestsStopped() throws Exception {
> stopAllGrids();
> }
> {code}
> # We shuold carefully review whole usages of stopAllGrids method in our
> test-classes and remove if it not necessary anymore or change for using in
> proper way\position.
> e.g.
> {code:java|title=TcpClientDiscoverySpiSelfTest.java|borderStyle=solid}
> /** {@inheritDoc} */
> @Override protected void afterTest() throws Exception {
> stopAllClients(true);
> stopAllServers(true);
>
> ...
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-4150) B-Tree index cannot be used efficiently with IN clause.
[
https://issues.apache.org/jira/browse/IGNITE-4150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588620#comment-16588620
]
Taras Ledkov commented on IGNITE-4150:
--
[~vozerov], the CPP & .NET tests are fixed according with SQL standard.
H2 updates change default scale of TIMESTAMP type. According with SQL standard
default scale for TIMESTAMP's nanos is 6. In previous H2 version was 9.
> B-Tree index cannot be used efficiently with IN clause.
> ---
>
> Key: IGNITE-4150
> URL: https://issues.apache.org/jira/browse/IGNITE-4150
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: performance, sql-stability
> Fix For: 2.7
>
>
> Consider the following query:
> {code}
> SELECT * FROM table
> WHERE a = ? AND b IN (?, ?)
> {code}
> If there is an index {{(a, b)}}, it will not be used properly: only column
> {{a}} will be used. This will leads to multiple unnecessary comparisons.
> Most obvious way to fix that - use temporary table and {{JOIN}}. However,
> this approach doesn't work well when there are multiple {{IN}}'s.
> Proper solution would be to hack deeper into H2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9279) Support custom default SQL schema name.
[ https://issues.apache.org/jira/browse/IGNITE-9279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588604#comment-16588604 ] Vladimir Ozerov commented on IGNITE-9279: - Reworked solution: now it is possible to define custom schema names at startup. Waiting for test run; https://ci.ignite.apache.org/viewQueued.html?itemId=1706879 > Support custom default SQL schema name. > --- > > Key: IGNITE-9279 > URL: https://issues.apache.org/jira/browse/IGNITE-9279 > Project: Ignite > Issue Type: Wish > Components: sql >Reporter: Andrew Mashenkov >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.7 > > > Default SQL schema is PUBLIC and there is no way to customize. > This may be useful when dynamic schema creation will be implemented. > Let's make default schema name configurable via node properties and then add > it to ignite configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9279) Support custom default SQL schema name.
[ https://issues.apache.org/jira/browse/IGNITE-9279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-9279: Fix Version/s: 2.7 > Support custom default SQL schema name. > --- > > Key: IGNITE-9279 > URL: https://issues.apache.org/jira/browse/IGNITE-9279 > Project: Ignite > Issue Type: Wish > Components: sql >Reporter: Andrew Mashenkov >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.7 > > > Default SQL schema is PUBLIC and there is no way to customize. > This may be useful when dynamic schema creation will be implemented. > Let's make default schema name configurable via node properties and then add > it to ignite configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9279) Support custom default SQL schema name.
[ https://issues.apache.org/jira/browse/IGNITE-9279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-9279: --- Assignee: Vladimir Ozerov (was: Andrew Mashenkov) > Support custom default SQL schema name. > --- > > Key: IGNITE-9279 > URL: https://issues.apache.org/jira/browse/IGNITE-9279 > Project: Ignite > Issue Type: Wish > Components: sql >Reporter: Andrew Mashenkov >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.7 > > > Default SQL schema is PUBLIC and there is no way to customize. > This may be useful when dynamic schema creation will be implemented. > Let's make default schema name configurable via node properties and then add > it to ignite configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9344) Flaky test `testClientReconnectClusterActivated` detected
[
https://issues.apache.org/jira/browse/IGNITE-9344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-9344:
Description:
The test has long been flaky and need to be fixed --
{{IgniteClusterActivateDeactivateTestWithPersistence.testClientReconnectClusterActivated}}
Please, check related TC history
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-390174676041430081=%3Cdefault%3E=testDetails
Probable reason:
{code}
class org.apache.ignite.IgniteCheckedException: Failed to start processor:
GridProcessorAdapter []
at
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1774)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1002)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:651)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:920)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:858)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:846)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:812)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrids(GridAbstractTest.java:696)
at
org.apache.ignite.internal.processors.cache.IgniteClusterActivateDeactivateTestWithPersistence.testActivateCacheRestoreConfigurationConflict(IgniteClusterActivateDeactivateTestWithPersistence.java:269)
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:2159)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:143)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2074)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
configured cache. Cache group name conflict with existing cache (change group
name) [cacheName=default1, conflictingCacheName=default]
at
org.apache.ignite.internal.processors.cache.ClusterCachesInfo.onStart(ClusterCachesInfo.java:156)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.start(GridCacheProcessor.java:696)
at
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1771)
... 20 more
{code}
was:
{{IgniteClusterActivateDeactivateTestWithPersistence.testClientReconnectClusterActivated}}
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-390174676041430081=%3Cdefault%3E=testDetails
> Flaky test `testClientReconnectClusterActivated` detected
> -
>
> Key: IGNITE-9344
> URL: https://issues.apache.org/jira/browse/IGNITE-9344
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> The test has long been flaky and need to be fixed --
> {{IgniteClusterActivateDeactivateTestWithPersistence.testClientReconnectClusterActivated}}
> Please, check related TC history
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-390174676041430081=%3Cdefault%3E=testDetails
> Probable reason:
> {code}
> class org.apache.ignite.IgniteCheckedException: Failed to start processor:
> GridProcessorAdapter []
> at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1774)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1002)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:651)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:920)
> at
>
[jira] [Created] (IGNITE-9344) Flaky test `testClientReconnectClusterActivated` detected
Maxim Muzafarov created IGNITE-9344:
---
Summary: Flaky test `testClientReconnectClusterActivated` detected
Key: IGNITE-9344
URL: https://issues.apache.org/jira/browse/IGNITE-9344
Project: Ignite
Issue Type: Bug
Reporter: Maxim Muzafarov
{{IgniteClusterActivateDeactivateTestWithPersistence.testClientReconnectClusterActivated}}
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-390174676041430081=%3Cdefault%3E=testDetails
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (IGNITE-9233) MVCC SQL: False write conflicts on fast updates
[ https://issues.apache.org/jira/browse/IGNITE-9233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin reopened IGNITE-9233: Ignite Flags: (was: Docs Required) MERGE behavior was broken it such way that it acts like UPDATE. > MVCC SQL: False write conflicts on fast updates > --- > > Key: IGNITE-9233 > URL: https://issues.apache.org/jira/browse/IGNITE-9233 > Project: Ignite > Issue Type: Bug > Components: mvcc, sql >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > Attachments: MvccInsertDeleteConcurrent.java > > > Currently is possible to encounter query failure e.g. in case when DELETE > with directly specified key encounters write conflict for row which is > created by concurrent INSERT. From SNAPSHOT isolation point of view DELETE > either should not see a row and do nothing or should remove a row gracefully. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9276) Multi-Get from NodeJS platform return empty or partial result
[ https://issues.apache.org/jira/browse/IGNITE-9276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588432#comment-16588432 ] Orel Weinstock commented on IGNITE-9276: Try to get and multi-get from any freshly created cache (e.g. start a new ignite process) that is mapped to a MySQL table. That is my scenario. We've created this mapping using the Web Console, and used the Web Console generated startup code to create an ignite server for testing. We've noticed that the Java thin client performs more communication with the Ignite server than the NodeJS one for multi-get, if that's any help. We've abandoned this project so I don't think I can give you any more insights into this. Maybe when the NodeJS client is officially released we'll get back to it. > Multi-Get from NodeJS platform return empty or partial result > - > > Key: IGNITE-9276 > URL: https://issues.apache.org/jira/browse/IGNITE-9276 > Project: Ignite > Issue Type: Bug > Components: platforms >Reporter: Eran Betzalel >Assignee: ekaterina.vergizova >Priority: Major > > The same test run with the JAVA client and it worked flawlessly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
