[jira] [Commented] (IGNITE-13510) Getting status of snapshot execution via command line and jmx
[
https://issues.apache.org/jira/browse/IGNITE-13510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580490#comment-17580490
]
Sergei Ryzhov commented on IGNITE-13510:
[~NSAmelchev] Hi, i don't have time to continue this right now.
> Getting status of snapshot execution via command line and jmx
> -
>
> Key: IGNITE-13510
> URL: https://issues.apache.org/jira/browse/IGNITE-13510
> Project: Ignite
> Issue Type: Task
>Reporter: Sergei Ryzhov
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: iep-43, ise, snapshot
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> the control.sh utility immediately relinquishes control
> and without using metricExporter it is impossible to understand whether the
> snapshot completed or not
> Restoring
> {code:java}
> Control utility [ver. 2.12.0-SNAPSHOT#20211004-sha1:77de60a7]
> 2021 Copyright(C) Apache Software Foundation
> User: sega
> Time: 2021-10-07T14:18:59.523
> Command [SNAPSHOT] started
> Arguments: --snapshot status --yes
>
> Status of SNAPSHOT operations:
> gridCommandHandlerTest0 -> Restoring to snapshot with name: snapshot_02052020
> gridCommandHandlerTest1 -> Restoring to snapshot with name: snapshot_02052020
> Command [SNAPSHOT] finished with code: 0
> Control utility has completed execution at: 2021-10-07T14:18:59.546
> Execution time: 23 ms
> {code}
> Creating
> {code:java}
> Control utility [ver. 2.12.0-SNAPSHOT#20211004-sha1:77de60a7]
> 2021 Copyright(C) Apache Software Foundation
> User: sega
> Time: 2021-10-07T14:18:55.368
> Command [SNAPSHOT] started
> Arguments: --snapshot status --yes
>
> Status of SNAPSHOT operations:
> gridCommandHandlerTest0 -> Creating the snapshot with name: snapshot_02052020
> gridCommandHandlerTest1 -> Creating the snapshot with name: snapshot_02052020
> Command [SNAPSHOT] finished with code: 0
> Control utility has completed execution at: 2021-10-07T14:18:55.391
> Execution time: 23 ms
> {code}
> No snapshot operation
> {code:java}
> Control utility [ver. 2.12.0-SNAPSHOT#20211004-sha1:77de60a7]
> 2021 Copyright(C) Apache Software Foundation
> User: sega
> Time: 2021-10-07T14:18:58.408
> Command [SNAPSHOT] started
> Arguments: --snapshot status --yes
>
> Status of SNAPSHOT operations:
> gridCommandHandlerTest0 -> No snapshot operation.
> gridCommandHandlerTest1 -> No snapshot operation.
> Command [SNAPSHOT] finished with code: 0
> Control utility has completed execution at: 2021-10-07T14:18:58.439
> Execution time: 31 ms
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17540) Create error codes for volatile raft configuration
Roman Puchkovskiy created IGNITE-17540: -- Summary: Create error codes for volatile raft configuration Key: IGNITE-17540 URL: https://issues.apache.org/jira/browse/IGNITE-17540 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Fix For: 3.0.0-alpha6 VolatileLogStorageFactory throws deprecated IgniteInternalException without error codes. Explicit error codes need to be used. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17177) Implement PITR based on Consistent Cut algorithm
[ https://issues.apache.org/jira/browse/IGNITE-17177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-17177: --- Fix Version/s: 2.14 > Implement PITR based on Consistent Cut algorithm > > > Key: IGNITE-17177 > URL: https://issues.apache.org/jira/browse/IGNITE-17177 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-89, ise > Fix For: 2.14 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (IGNITE-17457) Cluster locks after the transaction recovery procedure if the tx primary node fail
[ https://issues.apache.org/jira/browse/IGNITE-17457 ]
Anton Vinogradov deleted comment on IGNITE-17457:
---
was (Author: ignitetcbot):
{panel:title=Branch: [pull/10178/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 12{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6717474]]
* IgniteCacheTestSuite12:
TxRecoveryWithConcurrentRollbackTest.testRecoveryNotDeadLockOnPrimaryFail - New
test duration 96s is more that 1 minute
{panel}
{panel:title=Branch: [pull/10178/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 12{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6717474]]
* {color:#013220}IgniteCacheTestSuite12:
TxRecoveryWithConcurrentRollbackTest.testRecoveryNotDeadLockOnPrimaryFail -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6710922buildTypeId=IgniteTests24Java8_RunAll]
> Cluster locks after the transaction recovery procedure if the tx primary node
> fail
> --
>
> Key: IGNITE-17457
> URL: https://issues.apache.org/jira/browse/IGNITE-17457
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Major
> Time Spent: 7h 20m
> Remaining Estimate: 0h
>
> Ignite cluster may be locked (all client operations would block) after the tx
> recovery procedure executed on the tx primary node failure.
> The prepared transaction may remain un-commited on the backup node after the
> tx recovery. So the partition exchange wouldn't complete. So cluster would
> be locked.
>
> The Immediate reason is the race condition in the method:
> {code:java}
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter::markFinalizing(RECOVERY_FINISH){code}
> If 2 or more backups are configured It may be called concurrently for the
> same transaction both from the recovery procedure:
> {code:java}
> IgniteTxManager::commitIfPrepared{code}
> and from the tx recovery request handler:
> {code:java}
> IgniteTxHandler::processCheckPreparedTxRequest{code}
> Problem occur if thread context is switched between old finalization status
> request and status update.
>
> The problematic sequence of events is as follows (the lock will be in the
> node1):
> 1. Start cluster with 3 nodes (node0, node1, node2) and cache with 2 backups.
> 2. On node2 start and prepare transaction choosing key with primary partition
> stored on node2.
> 3. Kill node2
> 4. The tx recovery procedure is started both on node0 and node1
> 5. In scope of the recovery procedure node0 sends tx recovery request to node1
> 6. The following steps are executed on the node1 in two threads ("procedure"
> which is a system pool thread executing the tx recovery procedure and
> "handler" which is a striped pool thread processing the tx recovery request
> sent from node0):
> - tx.finalization == NONE
> - "procedure": calls markFinalizing(RECOVERY_FINISH)
> - "handler": calls markFinalizing(RECOVERY_FINISH)
> - "procedure": gets old tx.finlalization - it's NONE
> - "handler": gets old tx.finalization - it's NONE
> - "handler": updates tx.finalization - now it's RECOVERY_FINISH
> - "procedure": tries to update tx.finalization via compareAndSet and fails
> since compare fails.
> - "procedure": stops transaction processing and does not try to commit it.
> - Transaction remains not finished on node1.
>
> Reproducer is in the pull request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-14703) Add merge-sort reducer for cache queries.
[ https://issues.apache.org/jira/browse/IGNITE-14703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-14703: --- Labels: IEP-71 ise (was: IEP-71) > Add merge-sort reducer for cache queries. > - > > Key: IGNITE-14703 > URL: https://issues.apache.org/jira/browse/IGNITE-14703 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-71, ise > Fix For: 2.12 > > Attachments: MasterPerfTest2.png, PRPerfTest2.png > > Time Spent: 26h 50m > Remaining Estimate: 0h > > MergeSort reducer is required for TextQueries (and IndexQuery in future) that > should provide a sorted result for user. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (IGNITE-17457) Cluster locks after the transaction recovery procedure if the tx primary node fail
[ https://issues.apache.org/jira/browse/IGNITE-17457 ]
Anton Vinogradov deleted comment on IGNITE-17457:
---
was (Author: ignitetcbot):
{panel:title=Branch: [pull/10178/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10178/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 12{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6710160]]
* {color:#013220}IgniteCacheTestSuite12:
TxRecoveryWithConcurrentRollbackTest.testRecoveryNotDeadLockOnPrimaryFail -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6710922buildTypeId=IgniteTests24Java8_RunAll]
> Cluster locks after the transaction recovery procedure if the tx primary node
> fail
> --
>
> Key: IGNITE-17457
> URL: https://issues.apache.org/jira/browse/IGNITE-17457
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Major
> Time Spent: 7h 20m
> Remaining Estimate: 0h
>
> Ignite cluster may be locked (all client operations would block) after the tx
> recovery procedure executed on the tx primary node failure.
> The prepared transaction may remain un-commited on the backup node after the
> tx recovery. So the partition exchange wouldn't complete. So cluster would
> be locked.
>
> The Immediate reason is the race condition in the method:
> {code:java}
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter::markFinalizing(RECOVERY_FINISH){code}
> If 2 or more backups are configured It may be called concurrently for the
> same transaction both from the recovery procedure:
> {code:java}
> IgniteTxManager::commitIfPrepared{code}
> and from the tx recovery request handler:
> {code:java}
> IgniteTxHandler::processCheckPreparedTxRequest{code}
> Problem occur if thread context is switched between old finalization status
> request and status update.
>
> The problematic sequence of events is as follows (the lock will be in the
> node1):
> 1. Start cluster with 3 nodes (node0, node1, node2) and cache with 2 backups.
> 2. On node2 start and prepare transaction choosing key with primary partition
> stored on node2.
> 3. Kill node2
> 4. The tx recovery procedure is started both on node0 and node1
> 5. In scope of the recovery procedure node0 sends tx recovery request to node1
> 6. The following steps are executed on the node1 in two threads ("procedure"
> which is a system pool thread executing the tx recovery procedure and
> "handler" which is a striped pool thread processing the tx recovery request
> sent from node0):
> - tx.finalization == NONE
> - "procedure": calls markFinalizing(RECOVERY_FINISH)
> - "handler": calls markFinalizing(RECOVERY_FINISH)
> - "procedure": gets old tx.finlalization - it's NONE
> - "handler": gets old tx.finalization - it's NONE
> - "handler": updates tx.finalization - now it's RECOVERY_FINISH
> - "procedure": tries to update tx.finalization via compareAndSet and fails
> since compare fails.
> - "procedure": stops transaction processing and does not try to commit it.
> - Transaction remains not finished on node1.
>
> Reproducer is in the pull request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (IGNITE-17457) Cluster locks after the transaction recovery procedure if the tx primary node fail
[ https://issues.apache.org/jira/browse/IGNITE-17457 ]
Anton Vinogradov deleted comment on IGNITE-17457:
---
was (Author: ignitetcbot):
{panel:title=Branch: [pull/10178/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10178/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 12{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6720371]]
* {color:#013220}IgniteCacheTestSuite12:
TxRecoveryConcurrentOnPrimaryFailTest.testRecoveryNotDeadLockOnPrimaryFail -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6710922buildTypeId=IgniteTests24Java8_RunAll]
> Cluster locks after the transaction recovery procedure if the tx primary node
> fail
> --
>
> Key: IGNITE-17457
> URL: https://issues.apache.org/jira/browse/IGNITE-17457
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Major
> Time Spent: 7h 20m
> Remaining Estimate: 0h
>
> Ignite cluster may be locked (all client operations would block) after the tx
> recovery procedure executed on the tx primary node failure.
> The prepared transaction may remain un-commited on the backup node after the
> tx recovery. So the partition exchange wouldn't complete. So cluster would
> be locked.
>
> The Immediate reason is the race condition in the method:
> {code:java}
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter::markFinalizing(RECOVERY_FINISH){code}
> If 2 or more backups are configured It may be called concurrently for the
> same transaction both from the recovery procedure:
> {code:java}
> IgniteTxManager::commitIfPrepared{code}
> and from the tx recovery request handler:
> {code:java}
> IgniteTxHandler::processCheckPreparedTxRequest{code}
> Problem occur if thread context is switched between old finalization status
> request and status update.
>
> The problematic sequence of events is as follows (the lock will be in the
> node1):
> 1. Start cluster with 3 nodes (node0, node1, node2) and cache with 2 backups.
> 2. On node2 start and prepare transaction choosing key with primary partition
> stored on node2.
> 3. Kill node2
> 4. The tx recovery procedure is started both on node0 and node1
> 5. In scope of the recovery procedure node0 sends tx recovery request to node1
> 6. The following steps are executed on the node1 in two threads ("procedure"
> which is a system pool thread executing the tx recovery procedure and
> "handler" which is a striped pool thread processing the tx recovery request
> sent from node0):
> - tx.finalization == NONE
> - "procedure": calls markFinalizing(RECOVERY_FINISH)
> - "handler": calls markFinalizing(RECOVERY_FINISH)
> - "procedure": gets old tx.finlalization - it's NONE
> - "handler": gets old tx.finalization - it's NONE
> - "handler": updates tx.finalization - now it's RECOVERY_FINISH
> - "procedure": tries to update tx.finalization via compareAndSet and fails
> since compare fails.
> - "procedure": stops transaction processing and does not try to commit it.
> - Transaction remains not finished on node1.
>
> Reproducer is in the pull request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17512) Load logger and test configuration from the classpath.
[
https://issues.apache.org/jira/browse/IGNITE-17512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580391#comment-17580391
]
Ignite TC Bot commented on IGNITE-17512:
{panel:title=Branch: [pull/10193/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10193/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6733427buildTypeId=IgniteTests24Java8_RunAll]
> Load logger and test configuration from the classpath.
> --
>
> Key: IGNITE-17512
> URL: https://issues.apache.org/jira/browse/IGNITE-17512
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Minor
> Labels: test-framework
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We currently only load log4j2-test.xml/test.properties from the ignite config
> directory. These files are not included in the test jar.
> This is very inconvenient for modules that use the Ignite test framework
> (extensions, for the most part).
> Suggestion:
> 1. include log4j2-test.xml and test.properties into test jar.
> 2. if log4j2-test.xml/test.properties was not found in ignite config
> directory - load them from the classpath.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17378) Check the replica is a primary before processing request at Replica
[ https://issues.apache.org/jira/browse/IGNITE-17378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580388#comment-17580388 ] Sergey Uttsel commented on IGNITE-17378: Merged into https://github.com/gridgain/apache-ignite-3/tree/ignite3_tx > Check the replica is a primary before processing request at Replica > --- > > Key: IGNITE-17378 > URL: https://issues.apache.org/jira/browse/IGNITE-17378 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3, transaction3_rw > > Need to check that a current leader and a leader from request are equals on > Replica#processRequest. For this purpose we need to use > RaftGroupService#refreshAndGetLeaderWithTerm in InternalTableImpl#enlist, > send Leader and Term with request and compare it in Replica#processRequest. > If they not equals then need to throw PrimaryReplicaMissException. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17526) NPE in GridCacheDistributedQueryFuture for node failure
[ https://issues.apache.org/jira/browse/IGNITE-17526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-17526: Ignite Flags: (was: Release Notes Required) > NPE in GridCacheDistributedQueryFuture for node failure > --- > > Key: IGNITE-17526 > URL: https://issues.apache.org/jira/browse/IGNITE-17526 > Project: Ignite > Issue Type: Bug >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: ise > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > NPE in #onNodeLeft as it doesn't check whether node is in the `#streams` or > not. > > java.lang.NullPointerException: null > at > org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryFuture.onNodeLeft(GridCacheDistributedQueryFuture.java:144) > ~[ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$3.onEvent(GridCacheDistributedQueryManager.java:118) > ~[ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager$LocalListenerWrapper.onEvent(GridEventStorageManager.java:1408) > ~[ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:903) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:888) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record0(GridEventStorageManager.java:359) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record(GridEventStorageManager.java:322) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.recordEvent(GridDiscoveryManager.java:3056) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body0(GridDiscoveryManager.java:3273) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body(GridDiscoveryManager.java:3076) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at java.lang.Thread.run(Thread.java:748) [?:1.8.0_291] > > [https://ci2.ignite.apache.org/test/-8353273041775919887?currentProjectId=IgniteTests24Java8=%3Cdefault%3E=true] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-14914) Support in() clause in IndexQuery.
[
https://issues.apache.org/jira/browse/IGNITE-14914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580365#comment-17580365
]
Ignite TC Bot commented on IGNITE-14914:
{panel:title=Branch: [pull/10195/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10195/head] Base: [master] : New Tests
(58)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Index Query API{color} [[tests
58|https://ci.ignite.apache.org/viewLog.html?buildId=6733518]]
* {color:#013220}IndexQueryTestSuite:
IndexQueryInCriterionDescTest.testSingleValueInCriterion - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInCriterionDescTest.testSingleInCriterionOnSecondField - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInCriterionDescTest.testMultipleInWithRangeCrossCriterionOnSecondField
- PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInCriterionDescTest.testSingleInWithSingleRangeCriterion -
PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInCriterionDescTest.testTwoValuesInCriterion - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInCriterionDescTest.testSingleInWithMultipleRangeCriterion -
PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInCriterionDescTest.testMultipleInWithSingleRangeCriterionCrossing -
PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInCriterionDescTest.testMultipleInCriteriaAndRangeCriteriaNoCross -
PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInCriterionTest.testExplcitiInCriterionWithNullVal - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInCriterionTest.testDuplicatedInCriterionFailure - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInCriterionDescTest.testMultipleInCriterion - PASSED{color}
... and 47 new tests
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6731947buildTypeId=IgniteTests24Java8_RunAll]
> Support in() clause in IndexQuery.
> --
>
> Key: IGNITE-14914
> URL: https://issues.apache.org/jira/browse/IGNITE-14914
> Project: Ignite
> Issue Type: New Feature
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Labels: IEP-71, ise
> Fix For: 2.14
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> IndexQuery should support IN criterion:
> {{IndexQuery.setCriteria(in("A", Arrays.asList(1, 2 ,3)));}}
> # IN criterion accepts collection of values to find. This collections is
> transformed to {{SortedSet(1, 2, 3)}} because IndexQuery provides to user
> sorted result.
> # When IN applies on first indexed field - IN(A0, A1) for index (A, B) - it
> converts to multiple {{eq}} operations are joint with OR operation:
> {{{}EQ(A0) or EQ(A1){}}}.
> # Other range criteria for other fields are applied to every such separate
> operation:
> {{IN(A0, A1) and GT(B)}} converts to {{{}(EQ(A0) and GT(B)) or (EQ(A1) and
> GT(B)){}}}.
> # When IN applies to non-leading indexed field - IN(B0, B1) for index (A, B)
> - it works like a filter for prepared range:
> {{GTE(A) and IN(B0, B1)}} converts to range {{[[A, B0]; [A, B1]]}} and every
> cache entry within this range is checked for being included to SortedSet(B0,
> B1).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17531) Tests covers consistency repair at inconsistent cluster with nonfinalized counters
[
https://issues.apache.org/jira/browse/IGNITE-17531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580364#comment-17580364
]
Ignite TC Bot commented on IGNITE-17531:
{panel:title=Branch: [pull/10199/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10199/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6561445buildTypeId=IgniteTests24Java8_RunAll]
> Tests covers consistency repair at inconsistent cluster with nonfinalized
> counters
> --
>
> Key: IGNITE-17531
> URL: https://issues.apache.org/jira/browse/IGNITE-17531
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Test must
> 1) Generate data with missed unordered update counter (gaps)
> 2) Perform restart with rebalance (full or historiical)
> 3) Check consistency on restart using idle_verify
> 4) Fix inconsistency using consistency_repair
> 5) Check result using idle_verify
> The main goal is to check recovery at production (where cluster may fail
> under the load) tools and approaches.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-16136) System Thread pool starvation and out of memory
[
https://issues.apache.org/jira/browse/IGNITE-16136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580356#comment-17580356
]
David Albrecht edited comment on IGNITE-16136 at 8/16/22 3:03 PM:
--
Yes we are using thick clients (Spring applications running in Tomcats) with
one single server node. *But we do not use continous queries at least not
intentionally.*
Up to now the problem has occurred on three different systems, each in a
different application acting as an Ignite node. However unfortunately, we do
not know how to reproduce the problem.
We investigated two of the systems according to your questions and the above
command returned:
System 1:
ignite\work\db\marshaller = 125 Files
System 2:
ignite\work\db\marshaller = 124 Files
We define the configuration using Spring configuration and properties. You can
find the corresponding files attached.
[^configuration.zip]
Please let me know if thats sufficient to proceed.
was (Author: sawfish):
Yes we are using thick clients (Spring applications running in Tomcats). *But
we do not use continous queries at least not intentionally.*
Up to now the problem has occurred on three different systems, each in a
different application acting as an Ignite node. However unfortunately, we do
not know how to reproduce the problem.
We investigated two of the systems according to your questions and the above
command returned:
System 1:
ignite\work\db\marshaller = 125 Files
System 2:
ignite\work\db\marshaller = 124 Files
We define the configuration using Spring configuration and properties. You can
find the corresponding files attached.
[^configuration.zip]
Please let me know if thats sufficient to proceed.
> System Thread pool starvation and out of memory
> ---
>
> Key: IGNITE-16136
> URL: https://issues.apache.org/jira/browse/IGNITE-16136
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7.6
>Reporter: David Albrecht
>Assignee: Maxim Muzafarov
>Priority: Critical
> Labels: ise
> Fix For: 2.14
>
> Attachments: configuration.zip, image-2021-12-15-21-13-43-775.png,
> image-2021-12-15-21-17-47-652.png
>
>
> We are experiencing thread pool starvations and after some time out of memory
> exceptions in some of our ignite client nodes while the server node seems to
> be running without any problems. It seems like all sys threads are stuck when
> calling MarshallerContextImpl.getClassName. Which in turn leads to a growing
> worker queue.
>
> First warnings regarding the thread pool starvation:
> {code:java}
> 10.12.21 11:22:34.603 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:27:34.654 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:32:34.713 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:37:34.764 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:42:34.796 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:47:34.839 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> {code}
> Out of memory error leading to a crash of the application:
> {code}
> Exception: java.lang.OutOfMemoryError thrown from the
> UncaughtExceptionHandler in thread "https-openssl-nio-16443-ClientPoller"
> Exception: java.lang.OutOfMemoryError thrown from the
> UncaughtExceptionHandler in thread "ajp-nio-16009-ClientPoller"
> 11-Dec-2021 03:07:24.446 SEVERE [Catalina-utility-1]
> org.apache.coyote.AbstractProtocol.startAsyncTimeout Error processing async
> timeouts
> java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError:
> Java heap space
> {code}
> The queue full of messages:
> !image-2021-12-15-21-17-47-652.png!
> It seems like all sys threads are stuck while waiting at:
> {code}
> sys-#170
> at jdk.internal.misc.Unsafe.park(ZJ)V (Native Method)
> at java.util.concurrent.locks.LockSupport.park()V
[jira] [Comment Edited] (IGNITE-16136) System Thread pool starvation and out of memory
[
https://issues.apache.org/jira/browse/IGNITE-16136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580356#comment-17580356
]
David Albrecht edited comment on IGNITE-16136 at 8/16/22 3:03 PM:
--
Yes we are using thick clients (Spring applications running in Tomcats) with
one single server node. *But we do not use continous queries at least not
intentionally.*
Up to now the problem has occurred on three different systems, each in a
different application acting as an Ignite client node. However unfortunately,
we do not know how to reproduce the problem.
We investigated two of the systems according to your questions and the above
command returned:
System 1:
ignite\work\db\marshaller = 125 Files
System 2:
ignite\work\db\marshaller = 124 Files
We define the configuration using Spring configuration and properties. You can
find the corresponding files attached.
[^configuration.zip]
Please let me know if thats sufficient to proceed.
was (Author: sawfish):
Yes we are using thick clients (Spring applications running in Tomcats) with
one single server node. *But we do not use continous queries at least not
intentionally.*
Up to now the problem has occurred on three different systems, each in a
different application acting as an Ignite node. However unfortunately, we do
not know how to reproduce the problem.
We investigated two of the systems according to your questions and the above
command returned:
System 1:
ignite\work\db\marshaller = 125 Files
System 2:
ignite\work\db\marshaller = 124 Files
We define the configuration using Spring configuration and properties. You can
find the corresponding files attached.
[^configuration.zip]
Please let me know if thats sufficient to proceed.
> System Thread pool starvation and out of memory
> ---
>
> Key: IGNITE-16136
> URL: https://issues.apache.org/jira/browse/IGNITE-16136
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7.6
>Reporter: David Albrecht
>Assignee: Maxim Muzafarov
>Priority: Critical
> Labels: ise
> Fix For: 2.14
>
> Attachments: configuration.zip, image-2021-12-15-21-13-43-775.png,
> image-2021-12-15-21-17-47-652.png
>
>
> We are experiencing thread pool starvations and after some time out of memory
> exceptions in some of our ignite client nodes while the server node seems to
> be running without any problems. It seems like all sys threads are stuck when
> calling MarshallerContextImpl.getClassName. Which in turn leads to a growing
> worker queue.
>
> First warnings regarding the thread pool starvation:
> {code:java}
> 10.12.21 11:22:34.603 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:27:34.654 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:32:34.713 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:37:34.764 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:42:34.796 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:47:34.839 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> {code}
> Out of memory error leading to a crash of the application:
> {code}
> Exception: java.lang.OutOfMemoryError thrown from the
> UncaughtExceptionHandler in thread "https-openssl-nio-16443-ClientPoller"
> Exception: java.lang.OutOfMemoryError thrown from the
> UncaughtExceptionHandler in thread "ajp-nio-16009-ClientPoller"
> 11-Dec-2021 03:07:24.446 SEVERE [Catalina-utility-1]
> org.apache.coyote.AbstractProtocol.startAsyncTimeout Error processing async
> timeouts
> java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError:
> Java heap space
> {code}
> The queue full of messages:
> !image-2021-12-15-21-17-47-652.png!
> It seems like all sys threads are stuck while waiting at:
> {code}
> sys-#170
> at jdk.internal.misc.Unsafe.park(ZJ)V (Native Method)
> at
[jira] [Updated] (IGNITE-16136) System Thread pool starvation and out of memory
[
https://issues.apache.org/jira/browse/IGNITE-16136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Albrecht updated IGNITE-16136:
Attachment: configuration.zip
> System Thread pool starvation and out of memory
> ---
>
> Key: IGNITE-16136
> URL: https://issues.apache.org/jira/browse/IGNITE-16136
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7.6
>Reporter: David Albrecht
>Assignee: Maxim Muzafarov
>Priority: Critical
> Labels: ise
> Fix For: 2.14
>
> Attachments: configuration.zip, image-2021-12-15-21-13-43-775.png,
> image-2021-12-15-21-17-47-652.png
>
>
> We are experiencing thread pool starvations and after some time out of memory
> exceptions in some of our ignite client nodes while the server node seems to
> be running without any problems. It seems like all sys threads are stuck when
> calling MarshallerContextImpl.getClassName. Which in turn leads to a growing
> worker queue.
>
> First warnings regarding the thread pool starvation:
> {code:java}
> 10.12.21 11:22:34.603 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:27:34.654 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:32:34.713 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:37:34.764 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:42:34.796 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:47:34.839 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> {code}
> Out of memory error leading to a crash of the application:
> {code}
> Exception: java.lang.OutOfMemoryError thrown from the
> UncaughtExceptionHandler in thread "https-openssl-nio-16443-ClientPoller"
> Exception: java.lang.OutOfMemoryError thrown from the
> UncaughtExceptionHandler in thread "ajp-nio-16009-ClientPoller"
> 11-Dec-2021 03:07:24.446 SEVERE [Catalina-utility-1]
> org.apache.coyote.AbstractProtocol.startAsyncTimeout Error processing async
> timeouts
> java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError:
> Java heap space
> {code}
> The queue full of messages:
> !image-2021-12-15-21-17-47-652.png!
> It seems like all sys threads are stuck while waiting at:
> {code}
> sys-#170
> at jdk.internal.misc.Unsafe.park(ZJ)V (Native Method)
> at java.util.concurrent.locks.LockSupport.park()V (LockSupport.java:323)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(Z)Ljava/lang/Object;
> (GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get()Ljava/lang/Object;
> (GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClassName(BI)Ljava/lang/String;
> (MarshallerContextImpl.java:379)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClass(ILjava/lang/ClassLoader;)Ljava/lang/Class;
> (MarshallerContextImpl.java:344)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(Ljava/util/concurrent/ConcurrentMap;ILjava/lang/ClassLoader;Lorg/apache/ignite/marshaller/MarshallerContext;Lorg/apache/ignite/internal/marshaller/optimized/OptimizedMarshallerIdMapper;)Lorg/apache/ignite/internal/marshaller/optimized/OptimizedClassDescriptor;
> (OptimizedMarshallerUtils.java:264)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0()Ljava/lang/Object;
> (OptimizedObjectInputStream.java:341)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride()Ljava/lang/Object;
> (OptimizedObjectInputStream.java:198)
> at
> java.io.ObjectInputStream.readObject(Ljava/lang/Class;)Ljava/lang/Object;
> (ObjectInputStream.java:484)
> at java.io.ObjectInputStream.readObject()Ljava/lang/Object;
> (ObjectInputStream.java:451)
> at
>
[jira] [Commented] (IGNITE-16136) System Thread pool starvation and out of memory
[
https://issues.apache.org/jira/browse/IGNITE-16136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580356#comment-17580356
]
David Albrecht commented on IGNITE-16136:
-
Yes we are using thick clients (Spring applications running in Tomcats). *But
we do not use continous queries at least not intentionally.*
Up to now the problem has occurred on three different systems, each in a
different application acting as an Ignite node. However unfortunately, we do
not know how to reproduce the problem.
We investigated two of the systems according to your questions and the above
command returned:
System 1:
ignite\work\db\marshaller = 125 Files
System 2:
ignite\work\db\marshaller = 124 Files
We define the configuration using Spring configuration and properties. You can
find the corresponding files attached.
[^configuration.zip]
Please let me know if thats sufficient to proceed.
> System Thread pool starvation and out of memory
> ---
>
> Key: IGNITE-16136
> URL: https://issues.apache.org/jira/browse/IGNITE-16136
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7.6
>Reporter: David Albrecht
>Assignee: Maxim Muzafarov
>Priority: Critical
> Labels: ise
> Fix For: 2.14
>
> Attachments: configuration.zip, image-2021-12-15-21-13-43-775.png,
> image-2021-12-15-21-17-47-652.png
>
>
> We are experiencing thread pool starvations and after some time out of memory
> exceptions in some of our ignite client nodes while the server node seems to
> be running without any problems. It seems like all sys threads are stuck when
> calling MarshallerContextImpl.getClassName. Which in turn leads to a growing
> worker queue.
>
> First warnings regarding the thread pool starvation:
> {code:java}
> 10.12.21 11:22:34.603 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:27:34.654 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:32:34.713 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:37:34.764 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:42:34.796 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:47:34.839 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> {code}
> Out of memory error leading to a crash of the application:
> {code}
> Exception: java.lang.OutOfMemoryError thrown from the
> UncaughtExceptionHandler in thread "https-openssl-nio-16443-ClientPoller"
> Exception: java.lang.OutOfMemoryError thrown from the
> UncaughtExceptionHandler in thread "ajp-nio-16009-ClientPoller"
> 11-Dec-2021 03:07:24.446 SEVERE [Catalina-utility-1]
> org.apache.coyote.AbstractProtocol.startAsyncTimeout Error processing async
> timeouts
> java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError:
> Java heap space
> {code}
> The queue full of messages:
> !image-2021-12-15-21-17-47-652.png!
> It seems like all sys threads are stuck while waiting at:
> {code}
> sys-#170
> at jdk.internal.misc.Unsafe.park(ZJ)V (Native Method)
> at java.util.concurrent.locks.LockSupport.park()V (LockSupport.java:323)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(Z)Ljava/lang/Object;
> (GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get()Ljava/lang/Object;
> (GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClassName(BI)Ljava/lang/String;
> (MarshallerContextImpl.java:379)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClass(ILjava/lang/ClassLoader;)Ljava/lang/Class;
> (MarshallerContextImpl.java:344)
> at
>
[jira] [Updated] (IGNITE-17286) Race between completing table creation and stopping TableManager
[
https://issues.apache.org/jira/browse/IGNITE-17286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-17286:
-
Description:
As IGNITE-17048 demonstrates, our tests sometimes fail with message like the
following:
java.lang.AssertionError: Raft groups are still running
The leftover Raft groups always relate to table partitions (and NOT
metastorage/cmg).
It looks like this can happen due to TableManager.stop() being called before
some table creation is completed (on some Ignite node). As a result,
TableManager.stop() does not see this table, so the table does not get stopped,
and its Raft groups are left forever.
Adding a delay to table creation completion
public void onSqlSchemaReady(long causalityToken) {
if (Math.random() < 0.33) {
try
{ Thread.sleep(1000); }
catch (InterruptedException e)
{ // ignore }
}
LOG.info("SCHEMA READY FOR " + causalityToken);
tablesByIdVv.complete(causalityToken);
}
makes the failure manifest itself easily.
The reproducer is in
[https://github.com/gridgain/apache-ignite-3/tree/ignite-17286-repr]
To run the reproducer, just run
ItComputeTest.executesColocatedByClassNameWithTupleKey()
It usually takes less than 10 iterations to bump into the assertion.
UPD:
As a result, a set of busylock were added to the table creation flow, in places
like {{SqlSchemaManagerImpl}} , {{SchemaManager}} and others. Also, added logic
of stopping resources in case of stopping node in the middle of the table
creation flow
was:
As IGNITE-17048 demonstrates, our tests sometimes fail with message like the
following:
java.lang.AssertionError: Raft groups are still running
The leftover Raft groups always relate to table partitions (and NOT
metastorage/cmg).
It looks like this can happen due to TableManager.stop() being called before
some table creation is completed (on some Ignite node). As a result,
TableManager.stop() does not see this table, so the table does not get stopped,
and its Raft groups are left forever.
Adding a delay to table creation completion
public void onSqlSchemaReady(long causalityToken) {
if (Math.random() < 0.33) {
try
{ Thread.sleep(1000); }
catch (InterruptedException e)
{ // ignore }
}
LOG.info("SCHEMA READY FOR " + causalityToken);
tablesByIdVv.complete(causalityToken);
}
makes the failure manifest itself easily.
The reproducer is in
[https://github.com/gridgain/apache-ignite-3/tree/ignite-17286-repr]
To run the reproducer, just run
ItComputeTest.executesColocatedByClassNameWithTupleKey()
It usually takes less than 10 iterations to bump into the assertion.
> Race between completing table creation and stopping TableManager
>
>
> Key: IGNITE-17286
> URL: https://issues.apache.org/jira/browse/IGNITE-17286
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> As IGNITE-17048 demonstrates, our tests sometimes fail with message like the
> following:
> java.lang.AssertionError: Raft groups are still running
> The leftover Raft groups always relate to table partitions (and NOT
> metastorage/cmg).
> It looks like this can happen due to TableManager.stop() being called before
> some table creation is completed (on some Ignite node). As a result,
> TableManager.stop() does not see this table, so the table does not get
> stopped, and its Raft groups are left forever.
> Adding a delay to table creation completion
> public void onSqlSchemaReady(long causalityToken) {
> if (Math.random() < 0.33) {
> try
> { Thread.sleep(1000); }
> catch (InterruptedException e)
> { // ignore }
> }
> LOG.info("SCHEMA READY FOR " + causalityToken);
> tablesByIdVv.complete(causalityToken);
> }
> makes the failure manifest itself easily.
> The reproducer is in
> [https://github.com/gridgain/apache-ignite-3/tree/ignite-17286-repr]
> To run the reproducer, just run
> ItComputeTest.executesColocatedByClassNameWithTupleKey()
> It usually takes less than 10 iterations to bump into the assertion.
> UPD:
> As a result, a set of busylock were added to the table creation flow, in
> places like {{SqlSchemaManagerImpl}} , {{SchemaManager}} and others. Also,
> added logic of stopping resources in case of stopping node in the middle of
> the table creation flow
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17378) Check the replica is a primary before processing request at Replica
[ https://issues.apache.org/jira/browse/IGNITE-17378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580344#comment-17580344 ] Vladislav Pyatkov commented on IGNITE-17378: LGTM > Check the replica is a primary before processing request at Replica > --- > > Key: IGNITE-17378 > URL: https://issues.apache.org/jira/browse/IGNITE-17378 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3, transaction3_rw > > Need to check that a current leader and a leader from request are equals on > Replica#processRequest. For this purpose we need to use > RaftGroupService#refreshAndGetLeaderWithTerm in InternalTableImpl#enlist, > send Leader and Term with request and compare it in Replica#processRequest. > If they not equals then need to throw PrimaryReplicaMissException. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-16136) System Thread pool starvation and out of memory
[
https://issues.apache.org/jira/browse/IGNITE-16136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov reassigned IGNITE-16136:
Assignee: Maxim Muzafarov
> System Thread pool starvation and out of memory
> ---
>
> Key: IGNITE-16136
> URL: https://issues.apache.org/jira/browse/IGNITE-16136
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7.6
>Reporter: David Albrecht
>Assignee: Maxim Muzafarov
>Priority: Critical
> Labels: ise
> Fix For: 2.14
>
> Attachments: image-2021-12-15-21-13-43-775.png,
> image-2021-12-15-21-17-47-652.png
>
>
> We are experiencing thread pool starvations and after some time out of memory
> exceptions in some of our ignite client nodes while the server node seems to
> be running without any problems. It seems like all sys threads are stuck when
> calling MarshallerContextImpl.getClassName. Which in turn leads to a growing
> worker queue.
>
> First warnings regarding the thread pool starvation:
> {code:java}
> 10.12.21 11:22:34.603 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:27:34.654 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:32:34.713 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:37:34.764 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:42:34.796 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:47:34.839 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> {code}
> Out of memory error leading to a crash of the application:
> {code}
> Exception: java.lang.OutOfMemoryError thrown from the
> UncaughtExceptionHandler in thread "https-openssl-nio-16443-ClientPoller"
> Exception: java.lang.OutOfMemoryError thrown from the
> UncaughtExceptionHandler in thread "ajp-nio-16009-ClientPoller"
> 11-Dec-2021 03:07:24.446 SEVERE [Catalina-utility-1]
> org.apache.coyote.AbstractProtocol.startAsyncTimeout Error processing async
> timeouts
> java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError:
> Java heap space
> {code}
> The queue full of messages:
> !image-2021-12-15-21-17-47-652.png!
> It seems like all sys threads are stuck while waiting at:
> {code}
> sys-#170
> at jdk.internal.misc.Unsafe.park(ZJ)V (Native Method)
> at java.util.concurrent.locks.LockSupport.park()V (LockSupport.java:323)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(Z)Ljava/lang/Object;
> (GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get()Ljava/lang/Object;
> (GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClassName(BI)Ljava/lang/String;
> (MarshallerContextImpl.java:379)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClass(ILjava/lang/ClassLoader;)Ljava/lang/Class;
> (MarshallerContextImpl.java:344)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(Ljava/util/concurrent/ConcurrentMap;ILjava/lang/ClassLoader;Lorg/apache/ignite/marshaller/MarshallerContext;Lorg/apache/ignite/internal/marshaller/optimized/OptimizedMarshallerIdMapper;)Lorg/apache/ignite/internal/marshaller/optimized/OptimizedClassDescriptor;
> (OptimizedMarshallerUtils.java:264)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0()Ljava/lang/Object;
> (OptimizedObjectInputStream.java:341)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride()Ljava/lang/Object;
> (OptimizedObjectInputStream.java:198)
> at
> java.io.ObjectInputStream.readObject(Ljava/lang/Class;)Ljava/lang/Object;
> (ObjectInputStream.java:484)
> at java.io.ObjectInputStream.readObject()Ljava/lang/Object;
> (ObjectInputStream.java:451)
> at
>
[jira] [Resolved] (IGNITE-17466) Remove TableStorage and PartitionStorage implementations
[ https://issues.apache.org/jira/browse/IGNITE-17466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov resolved IGNITE-17466. Resolution: Fixed > Remove TableStorage and PartitionStorage implementations > > > Key: IGNITE-17466 > URL: https://issues.apache.org/jira/browse/IGNITE-17466 > Project: Ignite > Issue Type: Task >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > Time Spent: 50m > Remaining Estimate: 0h > > All implementations of *TableStorage* and *PartitionStorage* should be > removed, as well as the code associated with them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17526) NPE in GridCacheDistributedQueryFuture for node failure
[ https://issues.apache.org/jira/browse/IGNITE-17526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-17526: --- Labels: ise (was: ) > NPE in GridCacheDistributedQueryFuture for node failure > --- > > Key: IGNITE-17526 > URL: https://issues.apache.org/jira/browse/IGNITE-17526 > Project: Ignite > Issue Type: Bug >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: ise > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > NPE in #onNodeLeft as it doesn't check whether node is in the `#streams` or > not. > > java.lang.NullPointerException: null > at > org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryFuture.onNodeLeft(GridCacheDistributedQueryFuture.java:144) > ~[ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$3.onEvent(GridCacheDistributedQueryManager.java:118) > ~[ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager$LocalListenerWrapper.onEvent(GridEventStorageManager.java:1408) > ~[ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:903) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:888) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record0(GridEventStorageManager.java:359) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record(GridEventStorageManager.java:322) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.recordEvent(GridDiscoveryManager.java:3056) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body0(GridDiscoveryManager.java:3273) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body(GridDiscoveryManager.java:3076) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at java.lang.Thread.run(Thread.java:748) [?:1.8.0_291] > > [https://ci2.ignite.apache.org/test/-8353273041775919887?currentProjectId=IgniteTests24Java8=%3Cdefault%3E=true] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15921) Vulnerability in thin client protocol leads to OOM
[ https://issues.apache.org/jira/browse/IGNITE-15921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-15921: --- Labels: ise ise.lts (was: ise.lts) > Vulnerability in thin client protocol leads to OOM > -- > > Key: IGNITE-15921 > URL: https://issues.apache.org/jira/browse/IGNITE-15921 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 2.11 >Reporter: Ilya Kazakov >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: ise, ise.lts > Fix For: 2.13 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > As thin client protocol interprets first 4 bytes as message size and allocate > array for it. Any "big" 4 bytes sent on thin client port could leads to OOM. > Some ideas to resolve: > - print WARN in case of big client message > - allocate array not for all message, but allocate it gradually. > - read more then first4 bytes to understand is it real client message, or it > is some trash. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17539) ErrorGroups is not called in CLI
Aleksandr created IGNITE-17539:
--
Summary: ErrorGroups is not called in CLI
Key: IGNITE-17539
URL: https://issues.apache.org/jira/browse/IGNITE-17539
Project: Ignite
Issue Type: Bug
Reporter: Aleksandr
{{ErrorGroups}} static initializers are not called in CLI. It leads to the NPE
here {{TcpClientChannel line 322: new IgniteException(traceId, code,
errClassName + ": " + errMsg, causeWithStackTrace)}} because
{{ErrorGroup#registeredGroups}} is an empty map.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17539) ErrorGroups is not called in CLI
[
https://issues.apache.org/jira/browse/IGNITE-17539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr reassigned IGNITE-17539:
--
Assignee: Vyacheslav Koptilin (was: Aleksandr)
> ErrorGroups is not called in CLI
>
>
> Key: IGNITE-17539
> URL: https://issues.apache.org/jira/browse/IGNITE-17539
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Labels: ignite-3
>
> {{ErrorGroups}} static initializers are not called in CLI. It leads to the
> NPE here {{TcpClientChannel line 322: new IgniteException(traceId, code,
> errClassName + ": " + errMsg, causeWithStackTrace)}} because
> {{ErrorGroup#registeredGroups}} is an empty map.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17539) ErrorGroups is not called in CLI
[
https://issues.apache.org/jira/browse/IGNITE-17539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr reassigned IGNITE-17539:
--
Assignee: Aleksandr
> ErrorGroups is not called in CLI
>
>
> Key: IGNITE-17539
> URL: https://issues.apache.org/jira/browse/IGNITE-17539
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr
>Assignee: Aleksandr
>Priority: Major
> Labels: ignite-3
>
> {{ErrorGroups}} static initializers are not called in CLI. It leads to the
> NPE here {{TcpClientChannel line 322: new IgniteException(traceId, code,
> errClassName + ": " + errMsg, causeWithStackTrace)}} because
> {{ErrorGroup#registeredGroups}} is an empty map.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17538) [Ignite Website] Ignite Summit Europe_Update website banners
Evgenia created IGNITE-17538: Summary: [Ignite Website] Ignite Summit Europe_Update website banners Key: IGNITE-17538 URL: https://issues.apache.org/jira/browse/IGNITE-17538 Project: Ignite Issue Type: Task Components: website Reporter: Evgenia Attachments: docs.jpg, event.jpg, ignite-Summit.jpg Please add a new Ignite Summit and update event banners. All the links should lead to [Ignite Summit November 9-10, 2022 |https://ignite-summit.org/2022-november/] Places to update banners: 1) Featured events [Distributed Database - Apache Ignite|https://ignite.apache.org/] 2) Doc's banner [https://ignite.apache.org/docs/latest/] 3) Text banner at the top (doc's page) Change from Ignite Summit—June 2022—Recordings Now Available! to Ignite Summit Europe—November 2022—Call For Speakers Is Now Open! 4) Update event page with a new event [Apache Ignite Events - Meetups, Summit, Conference|https://ignite.apache.org/events.html#summit] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17455) IndexQuery should support setPartition
[ https://issues.apache.org/jira/browse/IGNITE-17455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17455: - Fix Version/s: 2.14 > IndexQuery should support setPartition > -- > > Key: IGNITE-17455 > URL: https://issues.apache.org/jira/browse/IGNITE-17455 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-71, ise > Fix For: 2.14 > > Time Spent: 50m > Remaining Estimate: 0h > > Currently IndexQuery doesn't support querying specified partition. But other > types of queries provide this option - ScanQuery, SqlFieldsQuery. > It's useful option for working with affinity requests. Then IndexQuery should > work over single partition. > To make it possible to migrate to IndexQuery from others queries let's add > such opportunity. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17532) RocksDB partition destruction
[ https://issues.apache.org/jira/browse/IGNITE-17532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17532: - Labels: ignite-3 (was: ) > RocksDB partition destruction > - > > Key: IGNITE-17532 > URL: https://issues.apache.org/jira/browse/IGNITE-17532 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > Time Spent: 50m > Remaining Estimate: 0h > > Current implementation has WAL disabled. This means that deleted partition > can resurrect bu itself after restart and no one will delete it. > Partition should be treated as deleted only when it's deleted on disc. For > this reason "destroyPartition" method should return a future. > EDIT: current implementation does return a future, but with explicit flush, > which is technically unnecessary. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-17532) RocksDB partition destruction
[ https://issues.apache.org/jira/browse/IGNITE-17532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov resolved IGNITE-17532. Resolution: Fixed > RocksDB partition destruction > - > > Key: IGNITE-17532 > URL: https://issues.apache.org/jira/browse/IGNITE-17532 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > Time Spent: 50m > Remaining Estimate: 0h > > Current implementation has WAL disabled. This means that deleted partition > can resurrect bu itself after restart and no one will delete it. > Partition should be treated as deleted only when it's deleted on disc. For > this reason "destroyPartition" method should return a future. > EDIT: current implementation does return a future, but with explicit flush, > which is technically unnecessary. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17517) Clean up todo's with closed tickets in CLI
[ https://issues.apache.org/jira/browse/IGNITE-17517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17517: - Labels: ignite-3 (was: ignite,) > Clean up todo's with closed tickets in CLI > -- > > Key: IGNITE-17517 > URL: https://issues.apache.org/jira/browse/IGNITE-17517 > Project: Ignite > Issue Type: Task > Components: cli >Reporter: Aleksandr >Priority: Minor > Labels: ignite-3 > > There are a couple of todo's that are forgotten, clean them up or create new > tickets that are not in CLOSED state. > https://issues.apache.org/jira/browse/IGNITE-17091 > https://issues.apache.org/jira/browse/IGNITE-17092 > https://issues.apache.org/jira/browse/IGNITE-17162 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-13510) Getting status of snapshot execution via command line and jmx
[
https://issues.apache.org/jira/browse/IGNITE-13510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita reassigned IGNITE-13510:
Assignee: Amelchev Nikita (was: Sergei Ryzhov)
> Getting status of snapshot execution via command line and jmx
> -
>
> Key: IGNITE-13510
> URL: https://issues.apache.org/jira/browse/IGNITE-13510
> Project: Ignite
> Issue Type: Task
>Reporter: Sergei Ryzhov
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: iep-43, ise, snapshot
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> the control.sh utility immediately relinquishes control
> and without using metricExporter it is impossible to understand whether the
> snapshot completed or not
> Restoring
> {code:java}
> Control utility [ver. 2.12.0-SNAPSHOT#20211004-sha1:77de60a7]
> 2021 Copyright(C) Apache Software Foundation
> User: sega
> Time: 2021-10-07T14:18:59.523
> Command [SNAPSHOT] started
> Arguments: --snapshot status --yes
>
> Status of SNAPSHOT operations:
> gridCommandHandlerTest0 -> Restoring to snapshot with name: snapshot_02052020
> gridCommandHandlerTest1 -> Restoring to snapshot with name: snapshot_02052020
> Command [SNAPSHOT] finished with code: 0
> Control utility has completed execution at: 2021-10-07T14:18:59.546
> Execution time: 23 ms
> {code}
> Creating
> {code:java}
> Control utility [ver. 2.12.0-SNAPSHOT#20211004-sha1:77de60a7]
> 2021 Copyright(C) Apache Software Foundation
> User: sega
> Time: 2021-10-07T14:18:55.368
> Command [SNAPSHOT] started
> Arguments: --snapshot status --yes
>
> Status of SNAPSHOT operations:
> gridCommandHandlerTest0 -> Creating the snapshot with name: snapshot_02052020
> gridCommandHandlerTest1 -> Creating the snapshot with name: snapshot_02052020
> Command [SNAPSHOT] finished with code: 0
> Control utility has completed execution at: 2021-10-07T14:18:55.391
> Execution time: 23 ms
> {code}
> No snapshot operation
> {code:java}
> Control utility [ver. 2.12.0-SNAPSHOT#20211004-sha1:77de60a7]
> 2021 Copyright(C) Apache Software Foundation
> User: sega
> Time: 2021-10-07T14:18:58.408
> Command [SNAPSHOT] started
> Arguments: --snapshot status --yes
>
> Status of SNAPSHOT operations:
> gridCommandHandlerTest0 -> No snapshot operation.
> gridCommandHandlerTest1 -> No snapshot operation.
> Command [SNAPSHOT] finished with code: 0
> Control utility has completed execution at: 2021-10-07T14:18:58.439
> Execution time: 31 ms
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17537) Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
[
https://issues.apache.org/jira/browse/IGNITE-17537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-17537:
---
Description:
Execution of {{control.sh --tx}} command produces output of matching
transactions, eg.:
{quote}Matching transactions:
Tx: [xid=fdc4d720281--0fd8-0177--0012, label=null,
state=ACTIVE, startTime=2022-07-06 05:05:07.432,
{*}{color:#ff}duration=778{color}{*}, isolation=REPEATABLE_READ,
concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=199,
minorTopVer=0], {*}{color:#ff}timeout=4{color}{*}, ...]
{quote}
But, from the above line it is unclear, that in fact, duration is printed in
seconds [1], while timeout is printed in milliseconds.
We can improve output in one of the following ways:
# Explicitly append unit for seconds and milliseconds.
# Print duration and timeout in same units: both in seconds or both in
milliseconds.
Links:
#
https://github.com/apache/ignite/blob/bf9a460eccd07701cacac2a414c65707243350f1/modules/core/src/main/java/org/apache/ignite/internal/visor/tx/VisorTxInfo.java#L286
was:
Output of {{control.sh --tx}} command produces output of matching transactions,
eg.:
{quote}Matching transactions:
Tx: [xid=fdc4d720281--0fd8-0177--0012, label=null,
state=ACTIVE, startTime=2022-07-06 05:05:07.432,
{*}{color:#ff}duration=778{color}{*}, isolation=REPEATABLE_READ,
concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=199,
minorTopVer=0], {*}{color:#ff}timeout=4{color}{*}, ...]
{quote}
But, from the above line it is unclear, that in fact, duration is printed in
seconds [1], while timeout is printed in milliseconds.
We can improve output in one of the following ways:
# Explicitly append unit for seconds and milliseconds.
# Print duration and timeout in same units: both in seconds or both in
milliseconds.
Links:
#
https://github.com/apache/ignite/blob/bf9a460eccd07701cacac2a414c65707243350f1/modules/core/src/main/java/org/apache/ignite/internal/visor/tx/VisorTxInfo.java#L286
> Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
> --
>
> Key: IGNITE-17537
> URL: https://issues.apache.org/jira/browse/IGNITE-17537
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh
>Reporter: Ilya Shishkov
>Priority: Trivial
> Labels: ise, newbie
>
> Execution of {{control.sh --tx}} command produces output of matching
> transactions, eg.:
> {quote}Matching transactions:
> Tx: [xid=fdc4d720281--0fd8-0177--0012, label=null,
> state=ACTIVE, startTime=2022-07-06 05:05:07.432,
> {*}{color:#ff}duration=778{color}{*}, isolation=REPEATABLE_READ,
> concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=199,
> minorTopVer=0], {*}{color:#ff}timeout=4{color}{*}, ...]
> {quote}
> But, from the above line it is unclear, that in fact, duration is printed in
> seconds [1], while timeout is printed in milliseconds.
> We can improve output in one of the following ways:
> # Explicitly append unit for seconds and milliseconds.
> # Print duration and timeout in same units: both in seconds or both in
> milliseconds.
> Links:
> #
> https://github.com/apache/ignite/blob/bf9a460eccd07701cacac2a414c65707243350f1/modules/core/src/main/java/org/apache/ignite/internal/visor/tx/VisorTxInfo.java#L286
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17532) RocksDB partition destruction
[ https://issues.apache.org/jira/browse/IGNITE-17532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-17532: - Reviewer: Kirill Tkalenko > RocksDB partition destruction > - > > Key: IGNITE-17532 > URL: https://issues.apache.org/jira/browse/IGNITE-17532 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 3.0.0-alpha6 > > Time Spent: 20m > Remaining Estimate: 0h > > Current implementation has WAL disabled. This means that deleted partition > can resurrect bu itself after restart and no one will delete it. > Partition should be treated as deleted only when it's deleted on disc. For > this reason "destroyPartition" method should return a future. > EDIT: current implementation does return a future, but with explicit flush, > which is technically unnecessary. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17537) Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
[
https://issues.apache.org/jira/browse/IGNITE-17537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-17537:
---
Description:
Output of {{control.sh --tx}} command produces output of matching transactions,
eg.:
{quote}Matching transactions:
Tx: [xid=fdc4d720281--0fd8-0177--0012, label=null,
state=ACTIVE, startTime=2022-07-06 05:05:07.432,
{*}{color:#ff}duration=778{color}{*}, isolation=REPEATABLE_READ,
concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=199,
minorTopVer=0], {*}{color:#ff}timeout=4{color}{*}, ...]
{quote}
But, from the above line it is unclear, that in fact, duration is printed in
seconds [1], while timeout is printed in milliseconds.
We can improve output in one of the following ways:
# Explicitly append unit for seconds and milliseconds.
# Print duration and timeout in same units: both in seconds or both in
milliseconds.
Links:
#
https://github.com/apache/ignite/blob/bf9a460eccd07701cacac2a414c65707243350f1/modules/core/src/main/java/org/apache/ignite/internal/visor/tx/VisorTxInfo.java#L286
was:
Output of {{control.sh --tx}} command produces output of matching transactions,
eg.:
{quote}Matching transactions:
Tx: [xid=fdc4d720281--0fd8-0177--0012, label=null,
state=ACTIVE, startTime=2022-07-06 05:05:07.432,
{*}{color:#ff}duration=778{color}{*}, isolation=REPEATABLE_READ,
concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=199,
minorTopVer=0], {*}{color:#ff}timeout=4{color}{*}, ...]
{quote}
But, from the above line it is unclear, that in fact, duration is printed in
seconds [1], while timeout is printed in milliseconds.
We can improve output in the one of the following ways:
# Explicitly append unit for seconds and milliseconds.
# Print duration and timeout in same units: both in seconds or both in
milliseconds.
Links:
#
https://github.com/apache/ignite/blob/bf9a460eccd07701cacac2a414c65707243350f1/modules/core/src/main/java/org/apache/ignite/internal/visor/tx/VisorTxInfo.java#L286
> Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
> --
>
> Key: IGNITE-17537
> URL: https://issues.apache.org/jira/browse/IGNITE-17537
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh
>Reporter: Ilya Shishkov
>Priority: Trivial
> Labels: ise, newbie
>
> Output of {{control.sh --tx}} command produces output of matching
> transactions, eg.:
> {quote}Matching transactions:
> Tx: [xid=fdc4d720281--0fd8-0177--0012, label=null,
> state=ACTIVE, startTime=2022-07-06 05:05:07.432,
> {*}{color:#ff}duration=778{color}{*}, isolation=REPEATABLE_READ,
> concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=199,
> minorTopVer=0], {*}{color:#ff}timeout=4{color}{*}, ...]
> {quote}
> But, from the above line it is unclear, that in fact, duration is printed in
> seconds [1], while timeout is printed in milliseconds.
> We can improve output in one of the following ways:
> # Explicitly append unit for seconds and milliseconds.
> # Print duration and timeout in same units: both in seconds or both in
> milliseconds.
> Links:
> #
> https://github.com/apache/ignite/blob/bf9a460eccd07701cacac2a414c65707243350f1/modules/core/src/main/java/org/apache/ignite/internal/visor/tx/VisorTxInfo.java#L286
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17537) Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
[
https://issues.apache.org/jira/browse/IGNITE-17537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-17537:
---
Description:
Output of {{control.sh --tx}} command produces output of matching transactions,
eg.:
{quote}Matching transactions:
Tx: [xid=fdc4d720281--0fd8-0177--0012, label=null,
state=ACTIVE, startTime=2022-07-06 05:05:07.432,
{*}{color:#ff}duration=778{color}{*}, isolation=REPEATABLE_READ,
concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=199,
minorTopVer=0], {*}{color:#ff}timeout=4{color}{*}, ...]
{quote}
But, from the above line it is unclear, that in fact, duration is printed in
seconds [1], while timeout is printed in milliseconds.
We can improve output in the one of the following ways:
# Explicitly append unit for seconds and milliseconds.
# Print duration and timeout in same units: both in seconds or both in
milliseconds.
Links:
#
https://github.com/apache/ignite/blob/bf9a460eccd07701cacac2a414c65707243350f1/modules/core/src/main/java/org/apache/ignite/internal/visor/tx/VisorTxInfo.java#L286
was:
Output of {{control.sh --tx}} command produces output of matching transactions,
eg.:
{quote}Matching transactions:
Tx: [xid=fdc4d720281--0fd8-0177--0012, label=null,
state=ACTIVE, startTime=2022-07-06 05:05:07.432,
{*}{color:#ff}duration=778{color}{*}, isolation=REPEATABLE_READ,
concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=199,
minorTopVer=0], {*}{color:#ff}timeout=4{color}{*}, size=0, ...]
{quote}
But, from the above line it is unclear, that in fact, duration is printed in
seconds [1], while timeout is printed in milliseconds.
We can improve output in the one of the following ways:
# Explicitly append unit for seconds and milliseconds.
# Print duration and timeout in same units: both in seconds or both in
milliseconds.
Links:
#
https://github.com/apache/ignite/blob/bf9a460eccd07701cacac2a414c65707243350f1/modules/core/src/main/java/org/apache/ignite/internal/visor/tx/VisorTxInfo.java#L286
> Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
> --
>
> Key: IGNITE-17537
> URL: https://issues.apache.org/jira/browse/IGNITE-17537
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh
>Reporter: Ilya Shishkov
>Priority: Trivial
> Labels: ise, newbie
>
> Output of {{control.sh --tx}} command produces output of matching
> transactions, eg.:
> {quote}Matching transactions:
> Tx: [xid=fdc4d720281--0fd8-0177--0012, label=null,
> state=ACTIVE, startTime=2022-07-06 05:05:07.432,
> {*}{color:#ff}duration=778{color}{*}, isolation=REPEATABLE_READ,
> concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=199,
> minorTopVer=0], {*}{color:#ff}timeout=4{color}{*}, ...]
> {quote}
> But, from the above line it is unclear, that in fact, duration is printed in
> seconds [1], while timeout is printed in milliseconds.
> We can improve output in the one of the following ways:
> # Explicitly append unit for seconds and milliseconds.
> # Print duration and timeout in same units: both in seconds or both in
> milliseconds.
> Links:
> #
> https://github.com/apache/ignite/blob/bf9a460eccd07701cacac2a414c65707243350f1/modules/core/src/main/java/org/apache/ignite/internal/visor/tx/VisorTxInfo.java#L286
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17526) NPE in GridCacheDistributedQueryFuture for node failure
[ https://issues.apache.org/jira/browse/IGNITE-17526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580244#comment-17580244 ] Maksim Timonin commented on IGNITE-17526: - [~mmuzaf] thanks for review! > NPE in GridCacheDistributedQueryFuture for node failure > --- > > Key: IGNITE-17526 > URL: https://issues.apache.org/jira/browse/IGNITE-17526 > Project: Ignite > Issue Type: Bug >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > NPE in #onNodeLeft as it doesn't check whether node is in the `#streams` or > not. > > java.lang.NullPointerException: null > at > org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryFuture.onNodeLeft(GridCacheDistributedQueryFuture.java:144) > ~[ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$3.onEvent(GridCacheDistributedQueryManager.java:118) > ~[ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager$LocalListenerWrapper.onEvent(GridEventStorageManager.java:1408) > ~[ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:903) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:888) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record0(GridEventStorageManager.java:359) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record(GridEventStorageManager.java:322) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.recordEvent(GridDiscoveryManager.java:3056) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body0(GridDiscoveryManager.java:3273) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body(GridDiscoveryManager.java:3076) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at java.lang.Thread.run(Thread.java:748) [?:1.8.0_291] > > [https://ci2.ignite.apache.org/test/-8353273041775919887?currentProjectId=IgniteTests24Java8=%3Cdefault%3E=true] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17537) Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
[
https://issues.apache.org/jira/browse/IGNITE-17537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-17537:
---
Priority: Minor (was: Major)
> Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
> --
>
> Key: IGNITE-17537
> URL: https://issues.apache.org/jira/browse/IGNITE-17537
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: ise, newbie
>
> Output of {{control.sh --tx}} command produces output of matching
> transactions, eg.:
> {quote}Matching transactions:
> Tx: [xid=fdc4d720281--0fd8-0177--0012, label=null,
> state=ACTIVE, startTime=2022-07-06 05:05:07.432,
> {*}{color:#ff}duration=778{color}{*}, isolation=REPEATABLE_READ,
> concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=199,
> minorTopVer=0], {*}{color:#ff}timeout=4{color}{*}, size=0, ...]
> {quote}
> But, from the above line it is unclear, that in fact, duration is printed in
> seconds [1], while timeout is printed in milliseconds.
> We can improve output in the one of the following ways:
> # Explicitly append unit for seconds and milliseconds.
> # Print duration and timeout in same units: both in seconds or both in
> milliseconds.
> Links:
> #
> https://github.com/apache/ignite/blob/bf9a460eccd07701cacac2a414c65707243350f1/modules/core/src/main/java/org/apache/ignite/internal/visor/tx/VisorTxInfo.java#L286
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17537) Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
[
https://issues.apache.org/jira/browse/IGNITE-17537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-17537:
---
Priority: Trivial (was: Minor)
> Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
> --
>
> Key: IGNITE-17537
> URL: https://issues.apache.org/jira/browse/IGNITE-17537
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh
>Reporter: Ilya Shishkov
>Priority: Trivial
> Labels: ise, newbie
>
> Output of {{control.sh --tx}} command produces output of matching
> transactions, eg.:
> {quote}Matching transactions:
> Tx: [xid=fdc4d720281--0fd8-0177--0012, label=null,
> state=ACTIVE, startTime=2022-07-06 05:05:07.432,
> {*}{color:#ff}duration=778{color}{*}, isolation=REPEATABLE_READ,
> concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=199,
> minorTopVer=0], {*}{color:#ff}timeout=4{color}{*}, size=0, ...]
> {quote}
> But, from the above line it is unclear, that in fact, duration is printed in
> seconds [1], while timeout is printed in milliseconds.
> We can improve output in the one of the following ways:
> # Explicitly append unit for seconds and milliseconds.
> # Print duration and timeout in same units: both in seconds or both in
> milliseconds.
> Links:
> #
> https://github.com/apache/ignite/blob/bf9a460eccd07701cacac2a414c65707243350f1/modules/core/src/main/java/org/apache/ignite/internal/visor/tx/VisorTxInfo.java#L286
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17537) Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
[
https://issues.apache.org/jira/browse/IGNITE-17537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-17537:
---
Description:
Output of {{control.sh --tx}} command produces output of matching transactions,
eg.:
{quote}Matching transactions:
Tx: [xid=fdc4d720281--0fd8-0177--0012, label=null,
state=ACTIVE, startTime=2022-07-06 05:05:07.432,
{*}{color:#ff}duration=778{color}{*}, isolation=REPEATABLE_READ,
concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=199,
minorTopVer=0], {*}{color:#ff}timeout=4{color}{*}, size=0, ...]
{quote}
But, from the above line it is unclear, that in fact, duration is printed in
seconds [1], while timeout is printed in milliseconds.
We can improve output in the one of the following ways:
# Explicitly append unit for seconds and milliseconds.
# Print duration and timeout in same units: both in seconds or both in
milliseconds.
Links:
#
https://github.com/apache/ignite/blob/bf9a460eccd07701cacac2a414c65707243350f1/modules/core/src/main/java/org/apache/ignite/internal/visor/tx/VisorTxInfo.java#L286
was:
Output of {{control.sh --tx}} command produces output of matching transactions,
eg.:
{quote}Matching transactions:
Tx: [xid=fdc4d720281--0fd8-0177--0012, label=null,
state=ACTIVE, startTime=2022-07-06 05:05:07.432,
{*}{color:#FF}duration=778{color}{*}, isolation=REPEATABLE_READ,
concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=199,
minorTopVer=0], {*}{color:#FF}timeout=4{color}{*}, size=0, ...]
{quote}
But, from the above line it is unclear, that in fact, duration is printed in
seconds, while timeout is printed in milliseconds.
We can improve output in the one of the following ways:
# Explicitly append unit for seconds and milliseconds.
# Print duration and timeout in same units: both in seconds or both in
milliseconds.
> Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
> --
>
> Key: IGNITE-17537
> URL: https://issues.apache.org/jira/browse/IGNITE-17537
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh
>Reporter: Ilya Shishkov
>Priority: Major
> Labels: ise, newbie
>
> Output of {{control.sh --tx}} command produces output of matching
> transactions, eg.:
> {quote}Matching transactions:
> Tx: [xid=fdc4d720281--0fd8-0177--0012, label=null,
> state=ACTIVE, startTime=2022-07-06 05:05:07.432,
> {*}{color:#ff}duration=778{color}{*}, isolation=REPEATABLE_READ,
> concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=199,
> minorTopVer=0], {*}{color:#ff}timeout=4{color}{*}, size=0, ...]
> {quote}
> But, from the above line it is unclear, that in fact, duration is printed in
> seconds [1], while timeout is printed in milliseconds.
> We can improve output in the one of the following ways:
> # Explicitly append unit for seconds and milliseconds.
> # Print duration and timeout in same units: both in seconds or both in
> milliseconds.
> Links:
> #
> https://github.com/apache/ignite/blob/bf9a460eccd07701cacac2a414c65707243350f1/modules/core/src/main/java/org/apache/ignite/internal/visor/tx/VisorTxInfo.java#L286
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17537) Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
[
https://issues.apache.org/jira/browse/IGNITE-17537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-17537:
---
Labels: ise newbie (was: newbie)
> Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
> --
>
> Key: IGNITE-17537
> URL: https://issues.apache.org/jira/browse/IGNITE-17537
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ilya Shishkov
>Priority: Major
> Labels: ise, newbie
>
> Output of {{control.sh --tx}} command produces output of matching
> transactions, eg.:
> {quote}Matching transactions:
> Tx: [xid=fdc4d720281--0fd8-0177--0012, label=null,
> state=ACTIVE, startTime=2022-07-06 05:05:07.432,
> {*}{color:#FF}duration=778{color}{*}, isolation=REPEATABLE_READ,
> concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=199,
> minorTopVer=0], {*}{color:#FF}timeout=4{color}{*}, size=0, ...]
> {quote}
> But, from the above line it is unclear, that in fact, duration is printed in
> seconds, while timeout is printed in milliseconds.
> We can improve output in the one of the following ways:
> # Explicitly append unit for seconds and milliseconds.
> # Print duration and timeout in same units: both in seconds or both in
> milliseconds.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17537) Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
Ilya Shishkov created IGNITE-17537:
--
Summary: Make units of 'timeout' and 'duration' more explicit in
control.sh --tx output
Key: IGNITE-17537
URL: https://issues.apache.org/jira/browse/IGNITE-17537
Project: Ignite
Issue Type: Improvement
Reporter: Ilya Shishkov
Output of {{control.sh --tx}} command produces output of matching transactions,
eg.:
{quote}Matching transactions:
Tx: [xid=fdc4d720281--0fd8-0177--0012, label=null,
state=ACTIVE, startTime=2022-07-06 05:05:07.432,
{*}{color:#FF}duration=778{color}{*}, isolation=REPEATABLE_READ,
concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=199,
minorTopVer=0], {*}{color:#FF}timeout=4{color}{*}, size=0, ...]
{quote}
But, from the above line it is unclear, that in fact, duration is printed in
seconds, while timeout is printed in milliseconds.
We can improve output in the one of the following ways:
# Explicitly append unit for seconds and milliseconds.
# Print duration and timeout in same units: both in seconds or both in
milliseconds.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17537) Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
[
https://issues.apache.org/jira/browse/IGNITE-17537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-17537:
---
Component/s: control.sh
> Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
> --
>
> Key: IGNITE-17537
> URL: https://issues.apache.org/jira/browse/IGNITE-17537
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh
>Reporter: Ilya Shishkov
>Priority: Major
> Labels: ise, newbie
>
> Output of {{control.sh --tx}} command produces output of matching
> transactions, eg.:
> {quote}Matching transactions:
> Tx: [xid=fdc4d720281--0fd8-0177--0012, label=null,
> state=ACTIVE, startTime=2022-07-06 05:05:07.432,
> {*}{color:#FF}duration=778{color}{*}, isolation=REPEATABLE_READ,
> concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=199,
> minorTopVer=0], {*}{color:#FF}timeout=4{color}{*}, size=0, ...]
> {quote}
> But, from the above line it is unclear, that in fact, duration is printed in
> seconds, while timeout is printed in milliseconds.
> We can improve output in the one of the following ways:
> # Explicitly append unit for seconds and milliseconds.
> # Print duration and timeout in same units: both in seconds or both in
> milliseconds.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17383) IdleVerify hangs when called on inactive cluster with persistence
[
https://issues.apache.org/jira/browse/IGNITE-17383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-17383:
---
Description:
When you call {{control.sh --cache idle_verify}} on inactive cluster with
persistence, control script hangs and no actions are performed. As you can see
below in 'rest' thread dump, {{VerifyBackupPartitionsTaskV2}} waits for
checkpoint start in {{GridCacheDatabaseSharedManager#waitForCheckpoint}}.
It seems, that we can interrupt task execution and print message in control
script output, that IdleVerify can't work on inactive cluster.
{code:title=Thread dump}
"rest-#82%ignite-server%" #146 prio=5 os_prio=31 tid=0x7fe0cf97c000
nid=0x3607 waiting on condition [0x700010149000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.waitForCheckpoint(GridCacheDatabaseSharedManager.java:1869)
at
org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.waitForCheckpoint(IgniteCacheDatabaseSharedManager.java:1107)
at
org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:199)
at
org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:171)
at
org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
at
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
at
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
at
org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1444)
at
org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:674)
at
org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:540)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:860)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:470)
at
org.apache.ignite.internal.IgniteComputeImpl.executeAsync0(IgniteComputeImpl.java:514)
at
org.apache.ignite.internal.IgniteComputeImpl.executeAsync(IgniteComputeImpl.java:496)
at
org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:70)
at
org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:35)
at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
at
org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
at
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
at
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
at
org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1444)
at
org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:674)
at
org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:540)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:860)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:590)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:570)
at
[jira] [Updated] (IGNITE-17334) Basic volatile RAFT log storage
[ https://issues.apache.org/jira/browse/IGNITE-17334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-17334: --- Description: The storage should contain the following components: # An elastic (but with possible hard-limit) in-memory storage for log entries. On this iteration it will be on-heap data structure (for instance, a skip list). Later, we'll build something better (like an off-heap implementation, maybe using pagemem). # An algorithm for determining when the in-memory storage cannot accept new entries. On this iteration, the only supported algorithm will be simply limiting the store by the number of stored entries. Later we will add something smarter, like the total size of the stored entries and adaptive algorithms. # Logic for spilling out to disk. This should not be implemented on this iteration, but it will be implemented later, in IGNITE-17336 was: The storage should contain the following components: # An elastic (but with possible hard-limit) in-memory storage for log entries. On this iteration it will be on-heap data structure (for instance, a skip list). Later, we'll build something better (like an off-heap implementation, maybe using pagemem). # An algorithm for determining when the in-memory storage cannot accept new entries. On this iteration, the only supported algorithm will be simply limiting the store by the number of stored entries. Later we will add something smarter, like the total size of the stored entries and adaptive algorithms. # A policy for what to do if the store cannot accept a record. On this iteration, it will be just to reject the entry. Later, we can add support for spilling out to disk. > Basic volatile RAFT log storage > --- > > Key: IGNITE-17334 > URL: https://issues.apache.org/jira/browse/IGNITE-17334 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > Time Spent: 2h > Remaining Estimate: 0h > > The storage should contain the following components: > # An elastic (but with possible hard-limit) in-memory storage for log > entries. On this iteration it will be on-heap data structure (for instance, a > skip list). Later, we'll build something better (like an off-heap > implementation, maybe using pagemem). > # An algorithm for determining when the in-memory storage cannot accept new > entries. On this iteration, the only supported algorithm will be simply > limiting the store by the number of stored entries. Later we will add > something smarter, like the total size of the stored entries and adaptive > algorithms. > # Logic for spilling out to disk. This should not be implemented on this > iteration, but it will be implemented later, in IGNITE-17336 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17466) Remove TableStorage and PartitionStorage implementations
[ https://issues.apache.org/jira/browse/IGNITE-17466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580212#comment-17580212 ] Kirill Tkalenko commented on IGNITE-17466: -- [~ibessonov] Please make code review. > Remove TableStorage and PartitionStorage implementations > > > Key: IGNITE-17466 > URL: https://issues.apache.org/jira/browse/IGNITE-17466 > Project: Ignite > Issue Type: Task >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > Time Spent: 10m > Remaining Estimate: 0h > > All implementations of *TableStorage* and *PartitionStorage* should be > removed, as well as the code associated with them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17466) Remove TableStorage and PartitionStorage implementations
[ https://issues.apache.org/jira/browse/IGNITE-17466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-17466: - Reviewer: Ivan Bessonov > Remove TableStorage and PartitionStorage implementations > > > Key: IGNITE-17466 > URL: https://issues.apache.org/jira/browse/IGNITE-17466 > Project: Ignite > Issue Type: Task >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > Time Spent: 10m > Remaining Estimate: 0h > > All implementations of *TableStorage* and *PartitionStorage* should be > removed, as well as the code associated with them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-16370) Use precomputed hash of a SearchRow in storage
[
https://issues.apache.org/jira/browse/IGNITE-16370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev resolved IGNITE-16370.
--
Resolution: Won't Fix
Closing this issue as the Partition Storage implementation is deprecated
> Use precomputed hash of a SearchRow in storage
> ---
>
> Key: IGNITE-16370
> URL: https://issues.apache.org/jira/browse/IGNITE-16370
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> After IGNITE-16102, Partition Storage based on RocksDB uses
> {{Arrays.hashCode}} to compute the hash of the storage key. However, binary
> representation relies on {{BinaryRow}} serialization, which already contains
> a precomputed hash code. It is proposed to add a {{keyHash}} method to the
> {{SearchRow}} interface, which will provide the hash code from the underlying
> {{BinaryRow}} to the storage.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-14914) Support in() clause in IndexQuery.
[
https://issues.apache.org/jira/browse/IGNITE-14914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580197#comment-17580197
]
Taras Ledkov commented on IGNITE-14914:
---
[~timonin.maksim] , please file tickets for .NET, c++, python thin client to
support new feature.
> Support in() clause in IndexQuery.
> --
>
> Key: IGNITE-14914
> URL: https://issues.apache.org/jira/browse/IGNITE-14914
> Project: Ignite
> Issue Type: New Feature
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Labels: IEP-71, ise
> Fix For: 2.14
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> IndexQuery should support IN criterion:
> {{IndexQuery.setCriteria(in("A", Arrays.asList(1, 2 ,3)));}}
> # IN criterion accepts collection of values to find. This collections is
> transformed to {{SortedSet(1, 2, 3)}} because IndexQuery provides to user
> sorted result.
> # When IN applies on first indexed field - IN(A0, A1) for index (A, B) - it
> converts to multiple {{eq}} operations are joint with OR operation:
> {{{}EQ(A0) or EQ(A1){}}}.
> # Other range criteria for other fields are applied to every such separate
> operation:
> {{IN(A0, A1) and GT(B)}} converts to {{{}(EQ(A0) and GT(B)) or (EQ(A1) and
> GT(B)){}}}.
> # When IN applies to non-leading indexed field - IN(B0, B1) for index (A, B)
> - it works like a filter for prepared range:
> {{GTE(A) and IN(B0, B1)}} converts to range {{[[A, B0]; [A, B1]]}} and every
> cache entry within this range is checked for being included to SortedSet(B0,
> B1).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17496) LWM may be after HWM (reserved) on primary after the node restart
[
https://issues.apache.org/jira/browse/IGNITE-17496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580191#comment-17580191
]
Anton Vinogradov commented on IGNITE-17496:
---
Merged to the master.
[~mmuzaf] , thanks for the review!
> LWM may be after HWM (reserved) on primary after the node restart
> -
>
> Key: IGNITE-17496
> URL: https://issues.apache.org/jira/browse/IGNITE-17496
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.14
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:java}
> java.lang.AssertionError: LWM after HWM: lwm=10010, hwm=10003, cntr=Counter
> [lwm=10010, missed=[10011 - 10012, 10021, 10031 - 10032, 10043 - 10044],
> maxApplied=10047, hwm=10004]
> at
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl.reserve(PartitionUpdateCounterTrackingImpl.java:265)
> at
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterErrorWrapper.reserve(PartitionUpdateCounterErrorWrapper.java:58)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.getAndIncrementUpdateCounter(IgniteCacheOffheapManagerImpl.java:1620)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.getAndIncrementUpdateCounter(GridCacheOffheapManager.java:2538)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.getAndIncrementUpdateCounter(GridDhtLocalPartition.java:942)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.calculatePartitionUpdateCounters(IgniteTxLocalAdapter.java:510)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1360)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:730)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1136)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:400)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:581)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:378)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:201)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:175)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:135)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:223)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:221)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1151)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:592)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:393)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:110)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:309)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1907)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:243)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
> at
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:637)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at java.lang.Thread.run(Thread.java:750) {code}
> It looks like we have incorrect initialization problem here.
>
[jira] [Assigned] (IGNITE-17466) Remove TableStorage and PartitionStorage implementations
[ https://issues.apache.org/jira/browse/IGNITE-17466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko reassigned IGNITE-17466: Assignee: Kirill Tkalenko > Remove TableStorage and PartitionStorage implementations > > > Key: IGNITE-17466 > URL: https://issues.apache.org/jira/browse/IGNITE-17466 > Project: Ignite > Issue Type: Task >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > > All implementations of *TableStorage* and *PartitionStorage* should be > removed, as well as the code associated with them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17532) RocksDB partition destruction
[ https://issues.apache.org/jira/browse/IGNITE-17532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-17532: --- Description: Current implementation has WAL disabled. This means that deleted partition can resurrect bu itself after restart and no one will delete it. Partition should be treated as deleted only when it's deleted on disc. For this reason "destroyPartition" method should return a future. EDIT: current implementation does return a future, but with explicit flush, which is technically unnecessary. was: Current implementation has WAL disabled. This means that deleted partition can resurrect bu itself after restart and no one will delete it. Partition should be treated as deleted only when it's deleted on disc. For this reason "destroyPartition" method should return a future. > RocksDB partition destruction > - > > Key: IGNITE-17532 > URL: https://issues.apache.org/jira/browse/IGNITE-17532 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 3.0.0-alpha6 > > > Current implementation has WAL disabled. This means that deleted partition > can resurrect bu itself after restart and no one will delete it. > Partition should be treated as deleted only when it's deleted on disc. For > this reason "destroyPartition" method should return a future. > EDIT: current implementation does return a future, but with explicit flush, > which is technically unnecessary. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17536) Implement BinaryTuple inlining in a hash index B+Tree
Kirill Tkalenko created IGNITE-17536: Summary: Implement BinaryTuple inlining in a hash index B+Tree Key: IGNITE-17536 URL: https://issues.apache.org/jira/browse/IGNITE-17536 Project: Ignite Issue Type: Task Reporter: Kirill Tkalenko Fix For: 3.0.0-alpha6 In a simple implementation, instead of a *BinaryTuple*, we store its link from the *FreeList* in the key, this is not optimal and we need to inline the *BinaryTuple* in the key, for starters, you can see how to do this in 2.0. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-14914) Support in() clause in IndexQuery.
[
https://issues.apache.org/jira/browse/IGNITE-14914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Timonin updated IGNITE-14914:
Description:
IndexQuery should support IN criterion:
{{IndexQuery.setCriteria(in("A", Arrays.asList(1, 2 ,3)));}}
# IN criterion accepts collection of values to find. This collections is
transformed to {{SortedSet(1, 2, 3)}} because IndexQuery provides to user
sorted result.
# When IN applies on first indexed field - IN(A0, A1) for index (A, B) - it
converts to multiple {{eq}} operations are joint with OR operation: {{{}EQ(A0)
or EQ(A1){}}}.
# Other range criteria for other fields are applied to every such separate
operation:
{{IN(A0, A1) and GT(B)}} converts to {{{}(EQ(A0) and GT(B)) or (EQ(A1) and
GT(B)){}}}.
# When IN applies to non-leading indexed field - IN(B0, B1) for index (A, B) -
it works like a filter for prepared range:
{{GTE(A) and IN(B0, B1)}} converts to range {{[[A, B0]; [A, B1]]}} and every
cache entry within this range is checked for being included to SortedSet(B0,
B1).
was:
IndexQuery should support IN criterion:
1. For first indexed field it should split query on multiple ranges
> Support in() clause in IndexQuery.
> --
>
> Key: IGNITE-14914
> URL: https://issues.apache.org/jira/browse/IGNITE-14914
> Project: Ignite
> Issue Type: New Feature
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Labels: IEP-71, ise
> Fix For: 2.14
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> IndexQuery should support IN criterion:
> {{IndexQuery.setCriteria(in("A", Arrays.asList(1, 2 ,3)));}}
> # IN criterion accepts collection of values to find. This collections is
> transformed to {{SortedSet(1, 2, 3)}} because IndexQuery provides to user
> sorted result.
> # When IN applies on first indexed field - IN(A0, A1) for index (A, B) - it
> converts to multiple {{eq}} operations are joint with OR operation:
> {{{}EQ(A0) or EQ(A1){}}}.
> # Other range criteria for other fields are applied to every such separate
> operation:
> {{IN(A0, A1) and GT(B)}} converts to {{{}(EQ(A0) and GT(B)) or (EQ(A1) and
> GT(B)){}}}.
> # When IN applies to non-leading indexed field - IN(B0, B1) for index (A, B)
> - it works like a filter for prepared range:
> {{GTE(A) and IN(B0, B1)}} converts to range {{[[A, B0]; [A, B1]]}} and every
> cache entry within this range is checked for being included to SortedSet(B0,
> B1).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-14914) Support in() clause in IndexQuery.
[ https://issues.apache.org/jira/browse/IGNITE-14914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-14914: Description: IndexQuery should support IN criterion: 1. For first indexed field it should split query on multiple ranges > Support in() clause in IndexQuery. > -- > > Key: IGNITE-14914 > URL: https://issues.apache.org/jira/browse/IGNITE-14914 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-71, ise > Fix For: 2.14 > > Time Spent: 0.5h > Remaining Estimate: 0h > > IndexQuery should support IN criterion: > 1. For first indexed field it should split query on multiple ranges -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-14914) Support in() clause in IndexQuery.
[
https://issues.apache.org/jira/browse/IGNITE-14914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580165#comment-17580165
]
Ignite TC Bot commented on IGNITE-14914:
{panel:title=Branch: [pull/10195/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10195/head] Base: [master] : New Tests
(58)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Index Query API{color} [[tests
58|https://ci.ignite.apache.org/viewLog.html?buildId=6731885]]
* {color:#013220}IndexQueryTestSuite:
IndexQueryInCriterionDescTest.testSingleValueInCriterion - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInCriterionDescTest.testSingleInCriterionOnSecondField - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInCriterionDescTest.testMultipleInWithRangeCrossCriterionOnSecondField
- PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInCriterionDescTest.testSingleInWithSingleRangeCriterion -
PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInCriterionDescTest.testTwoValuesInCriterion - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInCriterionDescTest.testSingleInWithMultipleRangeCriterion -
PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInCriterionDescTest.testMultipleInWithSingleRangeCriterionCrossing -
PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInCriterionDescTest.testMultipleInCriteriaAndRangeCriteriaNoCross -
PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInCriterionTest.testExplcitiInCriterionWithNullVal - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInCriterionTest.testDuplicatedInCriterionFailure - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInCriterionDescTest.testMultipleInCriterion - PASSED{color}
... and 47 new tests
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6731947buildTypeId=IgniteTests24Java8_RunAll]
> Support in() clause in IndexQuery.
> --
>
> Key: IGNITE-14914
> URL: https://issues.apache.org/jira/browse/IGNITE-14914
> Project: Ignite
> Issue Type: New Feature
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Labels: IEP-71, ise
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-14914) Support in() clause in IndexQuery.
[ https://issues.apache.org/jira/browse/IGNITE-14914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-14914: Fix Version/s: 2.14 > Support in() clause in IndexQuery. > -- > > Key: IGNITE-14914 > URL: https://issues.apache.org/jira/browse/IGNITE-14914 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-71, ise > Fix For: 2.14 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17534) Introduce an interface for Hash Indices
[
https://issues.apache.org/jira/browse/IGNITE-17534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-17534:
-
Description:
We need to create an interface for the Hash Index with the following methods:
{code:java}
public interface HashIndexStorage {
/**
* Returns the Index Descriptor of this storage.
*/
HashIndexDescriptor indexDescriptor();
/**
* Returns a collection of {@code RowId}s that correspond to the given
index key.
*/
Collection get(BinaryTuple key);
/**
* Adds the given index row to the index.
*/
void put(IndexRow row);
/**
* Removes the given row from the index.
*
* Removing a non-existent row is a no-op.
*/
void remove(IndexRow row);
}
{code}
It is also required to provide a test-only reference implementation and create
tests
was:
We need to create an interface for the Hash Index with the following methods:
{code:java}
public interface HashIndexStorage {
/**
* Returns the Index Descriptor of this storage.
*/
HashIndexDescriptor indexDescriptor();
/**
* Returns a collection of {@code RowId}s that correspond to the given
index key.
*/
Collection get(IndexRow row);
/**
* Adds the given index row to the index.
*/
void put(IndexRow row);
/**
* Removes the given row from the index.
*
* Removing a non-existent row is a no-op.
*/
void remove(IndexRow row);
}
{code}
It is also required to provide a test-only reference implementation and create
tests
> Introduce an interface for Hash Indices
> ---
>
> Key: IGNITE-17534
> URL: https://issues.apache.org/jira/browse/IGNITE-17534
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> We need to create an interface for the Hash Index with the following methods:
> {code:java}
> public interface HashIndexStorage {
> /**
> * Returns the Index Descriptor of this storage.
> */
> HashIndexDescriptor indexDescriptor();
>
> /**
> * Returns a collection of {@code RowId}s that correspond to the given
> index key.
> */
> Collection get(BinaryTuple key);
> /**
> * Adds the given index row to the index.
> */
> void put(IndexRow row);
> /**
> * Removes the given row from the index.
> *
> * Removing a non-existent row is a no-op.
> */
> void remove(IndexRow row);
> }
> {code}
> It is also required to provide a test-only reference implementation and
> create tests
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17534) Introduce an interface for Hash Indices
[
https://issues.apache.org/jira/browse/IGNITE-17534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-17534:
-
Description:
We need to create an interface for the Hash Index with the following methods:
{code:java}
public interface HashIndexStorage {
/**
* Returns the Index Descriptor of this storage.
*/
HashIndexDescriptor indexDescriptor();
/**
* Returns a collection of {@code RowId}s that correspond to the given
index key.
*/
Collection get(IndexRow row);
/**
* Adds the given index row to the index.
*/
void put(IndexRow row);
/**
* Removes the given row from the index.
*
* Removing a non-existent row is a no-op.
*/
void remove(IndexRow row);
}
{code}
It is also required to provide a test-only reference implementation and create
tests
was:We need to create an interface for the Hash Index with the following
methods
> Introduce an interface for Hash Indices
> ---
>
> Key: IGNITE-17534
> URL: https://issues.apache.org/jira/browse/IGNITE-17534
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> We need to create an interface for the Hash Index with the following methods:
> {code:java}
> public interface HashIndexStorage {
> /**
> * Returns the Index Descriptor of this storage.
> */
> HashIndexDescriptor indexDescriptor();
>
> /**
> * Returns a collection of {@code RowId}s that correspond to the given
> index key.
> */
> Collection get(IndexRow row);
> /**
> * Adds the given index row to the index.
> */
> void put(IndexRow row);
> /**
> * Removes the given row from the index.
> *
> * Removing a non-existent row is a no-op.
> */
> void remove(IndexRow row);
> }
> {code}
> It is also required to provide a test-only reference implementation and
> create tests
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17469) cli profile commands unification
[
https://issues.apache.org/jira/browse/IGNITE-17469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vadim Pakhnushev updated IGNITE-17469:
--
Component/s: (was: ignite-3)
Epic Link: IGNITE-16970
> cli profile commands unification
>
>
> Key: IGNITE-17469
> URL: https://issues.apache.org/jira/browse/IGNITE-17469
> Project: Ignite
> Issue Type: Improvement
> Components: cli
>Reporter: Yury Yudin
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Time Spent: 40m
> Remaining Estimate: 0h
>
> cli config profile now has two commands show and create, while setting a
> profile is done through a parameter, which is confusing.
> There should be a separate command to set the profile.
> In general I would suggest the commands there to look like:
> cli config show
> cli config set
> cli config get
> All repl cli commands should not accept --profile or -p parameters, all
> setting and getting of the params in a profile should go through its
> activation instead. I.e. cli config profile create newprofile ; cli config
> profile activate newprofile; cli config set
> ignite.cluster-url=[http://localhost:10300|http://localhost:10300/]
> We should retain --profile in non-repl mode.
> Profile manipulation should go like below:
> cli config profile show []
> cli config profile list
> cli config profile create --copy-from
> cli config profile activate
>
> Let’s please update IEP with the corresponding changes as well.
>
> Let's also make sure non-repl commands do have --profile option and
> auto-completion scripts are updated accordingly. Currently I don't see any
> suggestions on --profile there:
> {noformat}
> tests@ubuntu:~/Work/apache-ignite-3.0.0-SNAPSHOT$ ./ignite cluster config
> show --profile te
> st
> Unknown options: '--profile', 'test'
> Usage: ignite cluster config show [-h] [--cluster-url=]
> [--selector=]
> Shows cluster configuration.
> --cluster-url=
> Url to ignite node.
> -h, --help Show this help message and exit.
> --selector=
> Configuration path selector.
> tests@ubuntu:~/Work/apache-ignite-3.0.0-SNAPSHOT$
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17517) Clean up todo's with closed tickets in CLI
[ https://issues.apache.org/jira/browse/IGNITE-17517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-17517: --- Labels: ignite, (was: ) > Clean up todo's with closed tickets in CLI > -- > > Key: IGNITE-17517 > URL: https://issues.apache.org/jira/browse/IGNITE-17517 > Project: Ignite > Issue Type: Task > Components: cli >Reporter: Aleksandr >Priority: Minor > Labels: ignite, > > There are a couple of todo's that are forgotten, clean them up or create new > tickets that are not in CLOSED state. > https://issues.apache.org/jira/browse/IGNITE-17091 > https://issues.apache.org/jira/browse/IGNITE-17092 > https://issues.apache.org/jira/browse/IGNITE-17162 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17510) NPE in cluster configuration REST calls
[
https://issues.apache.org/jira/browse/IGNITE-17510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr updated IGNITE-17510:
---
Component/s: (was: ignite-3)
> NPE in cluster configuration REST calls
> ---
>
> Key: IGNITE-17510
> URL: https://issues.apache.org/jira/browse/IGNITE-17510
> Project: Ignite
> Issue Type: Task
> Components: cli, rest
>Reporter: Aleksandr
>Priority: Major
>
> When calling {{/management/v1/configuration/cluster}} on the cluster that is
> not initialized, then we got the NPE and as a result, a 500 error code is
> returned.
> {{ItNotInitializedClusterRestTest#clusterConfiguration}} and
> {{ItNotInitializedClusterRestTest#clusterConfigurationUpdate}} reproduce the
> issue and have TODO for that.
> I would suggest to return 404 in that case as
> {{/management/v1/cluster/topology/logical}} does. So, there is no such
> resource on the cluster that is not initialized.
> The {{cluster config show/update}} error handling should be updated as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17517) Clean up todo's with closed tickets in CLI
[ https://issues.apache.org/jira/browse/IGNITE-17517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-17517: --- Component/s: (was: ignite-3) > Clean up todo's with closed tickets in CLI > -- > > Key: IGNITE-17517 > URL: https://issues.apache.org/jira/browse/IGNITE-17517 > Project: Ignite > Issue Type: Task > Components: cli >Reporter: Aleksandr >Priority: Minor > > There are a couple of todo's that are forgotten, clean them up or create new > tickets that are not in CLOSED state. > https://issues.apache.org/jira/browse/IGNITE-17091 > https://issues.apache.org/jira/browse/IGNITE-17092 > https://issues.apache.org/jira/browse/IGNITE-17162 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17510) NPE in cluster configuration REST calls
[
https://issues.apache.org/jira/browse/IGNITE-17510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr updated IGNITE-17510:
---
Labels: ignite-3 (was: )
> NPE in cluster configuration REST calls
> ---
>
> Key: IGNITE-17510
> URL: https://issues.apache.org/jira/browse/IGNITE-17510
> Project: Ignite
> Issue Type: Task
> Components: cli, rest
>Reporter: Aleksandr
>Priority: Major
> Labels: ignite-3
>
> When calling {{/management/v1/configuration/cluster}} on the cluster that is
> not initialized, then we got the NPE and as a result, a 500 error code is
> returned.
> {{ItNotInitializedClusterRestTest#clusterConfiguration}} and
> {{ItNotInitializedClusterRestTest#clusterConfigurationUpdate}} reproduce the
> issue and have TODO for that.
> I would suggest to return 404 in that case as
> {{/management/v1/cluster/topology/logical}} does. So, there is no such
> resource on the cluster that is not initialized.
> The {{cluster config show/update}} error handling should be updated as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17518) Actualize cli module
[ https://issues.apache.org/jira/browse/IGNITE-17518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-17518: --- Component/s: (was: ignite-3) > Actualize cli module > > > Key: IGNITE-17518 > URL: https://issues.apache.org/jira/browse/IGNITE-17518 > Project: Ignite > Issue Type: Task > Components: cli >Reporter: Aleksandr >Priority: Minor > > 1) move all classes in CLI module under 'internal' package > 2) remove cli-common module that is not needed any more. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17519) Fix error handlers in Flow
[ https://issues.apache.org/jira/browse/IGNITE-17519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-17519: --- Component/s: (was: ignite-3) > Fix error handlers in Flow > -- > > Key: IGNITE-17519 > URL: https://issues.apache.org/jira/browse/IGNITE-17519 > Project: Ignite > Issue Type: Task > Components: cli >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > In FlowTest there is a couple of tests that reproduce the issue. In case the > custom exception hander is set to Flow, it is not used. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17518) Actualize cli module
[ https://issues.apache.org/jira/browse/IGNITE-17518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-17518: --- Labels: ignite-3 (was: ) > Actualize cli module > > > Key: IGNITE-17518 > URL: https://issues.apache.org/jira/browse/IGNITE-17518 > Project: Ignite > Issue Type: Task > Components: cli >Reporter: Aleksandr >Priority: Minor > Labels: ignite-3 > > 1) move all classes in CLI module under 'internal' package > 2) remove cli-common module that is not needed any more. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17519) Fix error handlers in Flow
[ https://issues.apache.org/jira/browse/IGNITE-17519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-17519: --- Labels: ignite-3 (was: ) > Fix error handlers in Flow > -- > > Key: IGNITE-17519 > URL: https://issues.apache.org/jira/browse/IGNITE-17519 > Project: Ignite > Issue Type: Task > Components: cli, ignite-3 >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > In FlowTest there is a couple of tests that reproduce the issue. In case the > custom exception hander is set to Flow, it is not used. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17534) Introduce an interface for Hash Indices
Aleksandr Polovtcev created IGNITE-17534: Summary: Introduce an interface for Hash Indices Key: IGNITE-17534 URL: https://issues.apache.org/jira/browse/IGNITE-17534 Project: Ignite Issue Type: Task Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev We need to create an interface for the Hash Index with the following methods -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17535) Implementing a hash index B+Tree
Kirill Tkalenko created IGNITE-17535: Summary: Implementing a hash index B+Tree Key: IGNITE-17535 URL: https://issues.apache.org/jira/browse/IGNITE-17535 Project: Ignite Issue Type: Task Reporter: Kirill Tkalenko Fix For: 3.0.0-alpha6 It is necessary to implement a hash index B+Tree, for simplicity, without inlining a *BinaryTuple*, but simply storing a link to it. The key will be: hash and link of the *BinaryTuple*. The value will be: *RowId*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17529) Override CLI config file path via environment variable
[
https://issues.apache.org/jira/browse/IGNITE-17529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vadim Pakhnushev updated IGNITE-17529:
--
Summary: Override CLI config file path via environment variable (was:
Allow changing CLI config file path via environment variable)
> Override CLI config file path via environment variable
> --
>
> Key: IGNITE-17529
> URL: https://issues.apache.org/jira/browse/IGNITE-17529
> Project: Ignite
> Issue Type: Task
> Components: cli
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
>
> Use {{IGNITE_CLI_CONFIG_FILE}} to define path to the CLI config file which is
> currently defined as {{XDG_CONFIG_HOME/ignitecli/defaults}} where
> {{XDG_CONFIG_HOME}} defaults to {{~/.config}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17286) Race between completing table creation and stopping TableManager
[
https://issues.apache.org/jira/browse/IGNITE-17286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580148#comment-17580148
]
Mirza Aliev commented on IGNITE-17286:
--
And actually, nothing was reverted on the main branch
> Race between completing table creation and stopping TableManager
>
>
> Key: IGNITE-17286
> URL: https://issues.apache.org/jira/browse/IGNITE-17286
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> As IGNITE-17048 demonstrates, our tests sometimes fail with message like the
> following:
> java.lang.AssertionError: Raft groups are still running
> The leftover Raft groups always relate to table partitions (and NOT
> metastorage/cmg).
> It looks like this can happen due to TableManager.stop() being called before
> some table creation is completed (on some Ignite node). As a result,
> TableManager.stop() does not see this table, so the table does not get
> stopped, and its Raft groups are left forever.
> Adding a delay to table creation completion
> public void onSqlSchemaReady(long causalityToken) {
> if (Math.random() < 0.33) {
> try
> { Thread.sleep(1000); }
> catch (InterruptedException e)
> { // ignore }
> }
> LOG.info("SCHEMA READY FOR " + causalityToken);
> tablesByIdVv.complete(causalityToken);
> }
> makes the failure manifest itself easily.
> The reproducer is in
> [https://github.com/gridgain/apache-ignite-3/tree/ignite-17286-repr]
> To run the reproducer, just run
> ItComputeTest.executesColocatedByClassNameWithTupleKey()
> It usually takes less than 10 iterations to bump into the assertion.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-17501) Integration between index and partition storages
[ https://issues.apache.org/jira/browse/IGNITE-17501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev resolved IGNITE-17501. -- Resolution: Invalid Closing this issue as it has been resolved as part of the transactions implementation > Integration between index and partition storages > > > Key: IGNITE-17501 > URL: https://issues.apache.org/jira/browse/IGNITE-17501 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17533) Implement a meta B+Tree of indexes
Kirill Tkalenko created IGNITE-17533: Summary: Implement a meta B+Tree of indexes Key: IGNITE-17533 URL: https://issues.apache.org/jira/browse/IGNITE-17533 Project: Ignite Issue Type: Task Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko Fix For: 3.0.0-alpha6 In order for us to work with many index B+Tree, we need to store their roots somewhere, a separate B+Tree is suitable for this, as done in 2.0, but instead of a key in the form of an index name, we need to use something more unique, for example, UUID. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17286) Race between completing table creation and stopping TableManager
[
https://issues.apache.org/jira/browse/IGNITE-17286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580141#comment-17580141
]
Mirza Aliev commented on IGNITE-17286:
--
[~rpuch] I think, that we shouldn't, seems like that was infrastructural
problems on TC
> Race between completing table creation and stopping TableManager
>
>
> Key: IGNITE-17286
> URL: https://issues.apache.org/jira/browse/IGNITE-17286
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> As IGNITE-17048 demonstrates, our tests sometimes fail with message like the
> following:
> java.lang.AssertionError: Raft groups are still running
> The leftover Raft groups always relate to table partitions (and NOT
> metastorage/cmg).
> It looks like this can happen due to TableManager.stop() being called before
> some table creation is completed (on some Ignite node). As a result,
> TableManager.stop() does not see this table, so the table does not get
> stopped, and its Raft groups are left forever.
> Adding a delay to table creation completion
> public void onSqlSchemaReady(long causalityToken) {
> if (Math.random() < 0.33) {
> try
> { Thread.sleep(1000); }
> catch (InterruptedException e)
> { // ignore }
> }
> LOG.info("SCHEMA READY FOR " + causalityToken);
> tablesByIdVv.complete(causalityToken);
> }
> makes the failure manifest itself easily.
> The reproducer is in
> [https://github.com/gridgain/apache-ignite-3/tree/ignite-17286-repr]
> To run the reproducer, just run
> ItComputeTest.executesColocatedByClassNameWithTupleKey()
> It usually takes less than 10 iterations to bump into the assertion.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17532) RocksDB partition destruction
Ivan Bessonov created IGNITE-17532: -- Summary: RocksDB partition destruction Key: IGNITE-17532 URL: https://issues.apache.org/jira/browse/IGNITE-17532 Project: Ignite Issue Type: Improvement Reporter: Ivan Bessonov Assignee: Ivan Bessonov Fix For: 3.0.0-alpha6 Current implementation has WAL disabled. This means that deleted partition can resurrect bu itself after restart and no one will delete it. Partition should be treated as deleted only when it's deleted on disc. For this reason "destroyPartition" method should return a future. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17286) Race between completing table creation and stopping TableManager
[
https://issues.apache.org/jira/browse/IGNITE-17286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580131#comment-17580131
]
Roman Puchkovskiy commented on IGNITE-17286:
[~v.pyatkov] should we reopen the issue then?
> Race between completing table creation and stopping TableManager
>
>
> Key: IGNITE-17286
> URL: https://issues.apache.org/jira/browse/IGNITE-17286
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> As IGNITE-17048 demonstrates, our tests sometimes fail with message like the
> following:
> java.lang.AssertionError: Raft groups are still running
> The leftover Raft groups always relate to table partitions (and NOT
> metastorage/cmg).
> It looks like this can happen due to TableManager.stop() being called before
> some table creation is completed (on some Ignite node). As a result,
> TableManager.stop() does not see this table, so the table does not get
> stopped, and its Raft groups are left forever.
> Adding a delay to table creation completion
> public void onSqlSchemaReady(long causalityToken) {
> if (Math.random() < 0.33) {
> try
> { Thread.sleep(1000); }
> catch (InterruptedException e)
> { // ignore }
> }
> LOG.info("SCHEMA READY FOR " + causalityToken);
> tablesByIdVv.complete(causalityToken);
> }
> makes the failure manifest itself easily.
> The reproducer is in
> [https://github.com/gridgain/apache-ignite-3/tree/ignite-17286-repr]
> To run the reproducer, just run
> ItComputeTest.executesColocatedByClassNameWithTupleKey()
> It usually takes less than 10 iterations to bump into the assertion.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17521) Need to retry enlisting new partition in a transaction if first ReplicaService#invoke() return PrimaryReplicaMissException
[ https://issues.apache.org/jira/browse/IGNITE-17521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel reassigned IGNITE-17521: -- Assignee: Sergey Uttsel > Need to retry enlisting new partition in a transaction if first > ReplicaService#invoke() return PrimaryReplicaMissException > -- > > Key: IGNITE-17521 > URL: https://issues.apache.org/jira/browse/IGNITE-17521 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3, transaction3_rw > > If a transaction enlist new partition and ReplicaService#invoke() return > PrimaryReplicaMissException then it's need to retry enlisting several times. -- This message was sent by Atlassian Jira (v8.20.10#820010)
