[jira] [Updated] (IGNITE-17786) Add --verbose option to all commands
[
https://issues.apache.org/jira/browse/IGNITE-17786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semyon Danilov updated IGNITE-17786:
Reviewer: Semyon Danilov
> Add --verbose option to all commands
>
>
> Key: IGNITE-17786
> URL: https://issues.apache.org/jira/browse/IGNITE-17786
> Project: Ignite
> Issue Type: Improvement
> Components: cli
>Reporter: Aleksandr
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta1
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Users of CLI should have the ability to go deeper if they face issues with
> CLI.
> The goal of this ticket is to add {{--verbose}} option to all commands and
> print additional debug information to the terminal if this flag is set to
> true.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17786) Add --verbose option to all commands
[
https://issues.apache.org/jira/browse/IGNITE-17786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semyon Danilov updated IGNITE-17786:
Fix Version/s: 3.0.0-beta1
> Add --verbose option to all commands
>
>
> Key: IGNITE-17786
> URL: https://issues.apache.org/jira/browse/IGNITE-17786
> Project: Ignite
> Issue Type: Improvement
> Components: cli
>Reporter: Aleksandr
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta1
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Users of CLI should have the ability to go deeper if they face issues with
> CLI.
> The goal of this ticket is to add {{--verbose}} option to all commands and
> print additional debug information to the terminal if this flag is set to
> true.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18058) .NET: Thin 3.0: Socket read never times out
[ https://issues.apache.org/jira/browse/IGNITE-18058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18058: Ignite Flags: (was: Docs Required,Release Notes Required) > .NET: Thin 3.0: Socket read never times out > --- > > Key: IGNITE-18058 > URL: https://issues.apache.org/jira/browse/IGNITE-18058 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > If the server does not respond, we hang forever in > *ClientSocket.ReceiveBytesAsync*. > We have *IgniteClientConfiguration.SocketTimeout*, but it is not actually > used anywhere. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18058) .NET: Thin 3.0: Socket read never times out
[ https://issues.apache.org/jira/browse/IGNITE-18058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18058: Description: If the server does not respond, we hang forever in *ClientSocket.ReceiveBytesAsync*. We have *IgniteClientConfiguration.SocketTimeout*, but it is not actually used anywhere. > .NET: Thin 3.0: Socket read never times out > --- > > Key: IGNITE-18058 > URL: https://issues.apache.org/jira/browse/IGNITE-18058 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > If the server does not respond, we hang forever in > *ClientSocket.ReceiveBytesAsync*. > We have *IgniteClientConfiguration.SocketTimeout*, but it is not actually > used anywhere. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18058) .NET: Thin 3.0: Socket read never times out
Pavel Tupitsyn created IGNITE-18058: --- Summary: .NET: Thin 3.0: Socket read never times out Key: IGNITE-18058 URL: https://issues.apache.org/jira/browse/IGNITE-18058 Project: Ignite Issue Type: Bug Components: platforms, thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18057) Sql. Fix index scan transactional consistency.
Andrey Mashenkov created IGNITE-18057: - Summary: Sql. Fix index scan transactional consistency. Key: IGNITE-18057 URL: https://issues.apache.org/jira/browse/IGNITE-18057 Project: Ignite Issue Type: Improvement Components: sql Reporter: Andrey Mashenkov TBD. Long story short. For now, searching for lower bound looks broken in storage. Storage cursor returns either lower bound (if found) or next item that large lower bound. In second case, * TX1 starts scan and searching for a lower bound, then lock a row next to the desired lower bound. * A concurrent transaction TX2 may add a new row between the lower bound and row which TX1 is about to lock. * TX1 must release lock and retry search, but it can't detect the issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18056) Sql. Make RangeConditions accordant to index row type
Andrey Mashenkov created IGNITE-18056: - Summary: Sql. Make RangeConditions accordant to index row type Key: IGNITE-18056 URL: https://issues.apache.org/jira/browse/IGNITE-18056 Project: Ignite Issue Type: Improvement Components: sql Reporter: Andrey Mashenkov As of now, RangeIndexCondition bounds is accordant to table row type, however, bound conditions are filled only on indexed column positions. Later, before passing bounds to storage, we convert the bounds respectively to index row type either way. Let's build bounds according to index row type, as valid index row prefixes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18055) Sql. Support index scans with NULL conditions.
[
https://issues.apache.org/jira/browse/IGNITE-18055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-18055:
--
Description:
Query {{SELECT * FROM T1 WHERE val IS NULL}} look fine, but next cases has to
be fixed.
* {{SELECT * FROM T1 WHERE val IS NOT NULL}} - returns nothing.
* {{SELECT * FROM T1 WHERE (val <= 5) or (val IS NULL)}} - returns duplicate
rows.
Startpoint is ItSecondaryIndexTest.
was:
Query {{SELECT * FROM T1 WHERE val is null}} look fine, but next cases has to
be fixed.
* {{SELECT * FROM T1 WHERE val is not null}} - returns nothing.
* {{SELECT * FROM T1 WHERE (val <= 5) or (val is null)}} - returns duplicate
rows.
Startpoint is ItSecondaryIndexTest.
> Sql. Support index scans with NULL conditions.
> --
>
> Key: IGNITE-18055
> URL: https://issues.apache.org/jira/browse/IGNITE-18055
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
>
> Query {{SELECT * FROM T1 WHERE val IS NULL}} look fine, but next cases has to
> be fixed.
> * {{SELECT * FROM T1 WHERE val IS NOT NULL}} - returns nothing.
> * {{SELECT * FROM T1 WHERE (val <= 5) or (val IS NULL)}} - returns duplicate
> rows.
> Startpoint is ItSecondaryIndexTest.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18055) Sql. Support index scans with NULL conditions.
Andrey Mashenkov created IGNITE-18055:
-
Summary: Sql. Support index scans with NULL conditions.
Key: IGNITE-18055
URL: https://issues.apache.org/jira/browse/IGNITE-18055
Project: Ignite
Issue Type: Improvement
Components: sql
Environment: Query {{SELECT * FROM T1 WHERE val is null}} look fine,
but next cases has to be fixed.
* {{SELECT * FROM T1 WHERE val is not null}} - returns nothing.
* {{SELECT * FROM T1 WHERE (val <= 5) or (val is null)}} - returns duplicate
rows.
Startpoint is ItSecondaryIndexTest.
Reporter: Andrey Mashenkov
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18055) Sql. Support index scans with NULL conditions.
[
https://issues.apache.org/jira/browse/IGNITE-18055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-18055:
--
Description:
Query {{SELECT * FROM T1 WHERE val is null}} look fine, but next cases has to
be fixed.
* {{SELECT * FROM T1 WHERE val is not null}} - returns nothing.
* {{SELECT * FROM T1 WHERE (val <= 5) or (val is null)}} - returns duplicate
rows.
Startpoint is ItSecondaryIndexTest.
> Sql. Support index scans with NULL conditions.
> --
>
> Key: IGNITE-18055
> URL: https://issues.apache.org/jira/browse/IGNITE-18055
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
>
> Query {{SELECT * FROM T1 WHERE val is null}} look fine, but next cases has to
> be fixed.
> * {{SELECT * FROM T1 WHERE val is not null}} - returns nothing.
> * {{SELECT * FROM T1 WHERE (val <= 5) or (val is null)}} - returns duplicate
> rows.
> Startpoint is ItSecondaryIndexTest.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18055) Sql. Support index scans with NULL conditions.
[
https://issues.apache.org/jira/browse/IGNITE-18055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-18055:
--
Environment: (was: Query {{SELECT * FROM T1 WHERE val is null}} look
fine, but next cases has to be fixed.
* {{SELECT * FROM T1 WHERE val is not null}} - returns nothing.
* {{SELECT * FROM T1 WHERE (val <= 5) or (val is null)}} - returns duplicate
rows.
Startpoint is ItSecondaryIndexTest.)
> Sql. Support index scans with NULL conditions.
> --
>
> Key: IGNITE-18055
> URL: https://issues.apache.org/jira/browse/IGNITE-18055
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18054) Implement sql query free memory metric in percents
[ https://issues.apache.org/jira/browse/IGNITE-18054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nusrat Shakarov updated IGNITE-18054: - Description: There is a need to have sql query free memory in percent. In some cases the absolute value of freeMem metric does not give a clear understanding of potential problems. The proposal is to implement a new metric - freeMemPercentage - based on freeMem and maxMem metrics. was: There is a need to have sql query free memory in percent. In some cases the absolute value of freeMem metric does not give a clear understanding of potential problems. The proposal is to create a new metric - freeMemPercentage - based on freeMem and maxMem metrics. > Implement sql query free memory metric in percents > -- > > Key: IGNITE-18054 > URL: https://issues.apache.org/jira/browse/IGNITE-18054 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Nusrat Shakarov >Priority: Major > > There is a need to have sql query free memory in percent. > In some cases the absolute value of freeMem metric does not give a clear > understanding of potential problems. > The proposal is to implement a new metric - freeMemPercentage - based on > freeMem and maxMem metrics. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18054) Implement sql query free memory metric in percents
[ https://issues.apache.org/jira/browse/IGNITE-18054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nusrat Shakarov updated IGNITE-18054: - Description: There is a need to have sql query free memory in percent. In some cases the absolute value of freeMem metric does not give a clear understanding of potential problems. The proposal is to create a new metric - freeMemPercentage - based on freeMem and maxMem metrics. was:There is a need to have sql query free memory in percent. > Implement sql query free memory metric in percents > -- > > Key: IGNITE-18054 > URL: https://issues.apache.org/jira/browse/IGNITE-18054 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Nusrat Shakarov >Priority: Major > > There is a need to have sql query free memory in percent. > In some cases the absolute value of freeMem metric does not give a clear > understanding of potential problems. > The proposal is to create a new metric - freeMemPercentage - based on freeMem > and maxMem metrics. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18054) Implement sql query free memory metric in percents
[ https://issues.apache.org/jira/browse/IGNITE-18054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nusrat Shakarov updated IGNITE-18054: - Description: There is a need to have sql query free memory in percent. > Implement sql query free memory metric in percents > -- > > Key: IGNITE-18054 > URL: https://issues.apache.org/jira/browse/IGNITE-18054 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Nusrat Shakarov >Priority: Major > > There is a need to have sql query free memory in percent. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18054) Implement sql query free memory metric in percents
Nusrat Shakarov created IGNITE-18054: Summary: Implement sql query free memory metric in percents Key: IGNITE-18054 URL: https://issues.apache.org/jira/browse/IGNITE-18054 Project: Ignite Issue Type: Improvement Components: sql Reporter: Nusrat Shakarov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18043) Replaceable deadlock prevention mechanism
[ https://issues.apache.org/jira/browse/IGNITE-18043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-18043: --- Description: *Motivation:* We have an embedded deadlock prevention strategy (presently, it is _Wait-Die_). Although, [the original paper|https://people.eecs.berkeley.edu/~brewer/cs262/concurrency-distributed-databases.pdf] about deadlock prevention contains another two strategies: _priorities_ and _Wound-Wait_. Also, the mechanism should give a possibility to not use any strategy to prevent deadlock. All told, above shows we need to separate the prevention strategy in dedicate interface (which even has one implementation _Wait-Die_). Another implementation will be released by necessary. *Definition of Done:* A deadlock resolution strategy (_ResolutionStrategy_) has to be extracted to interface, which parametrizes _LockManager_. Wait-Die strategy (_WaitDieLockResolutionStrategy_) will be the only one implementation of _ResolutionStrategy_. _HeapLockManager_ should be parametrized by _WaitDieLockResolutionStrategy_. was: We have an embedded deadlock prevention strategy (presently, it is _Wait-Die_). Although, [the original paper|https://people.eecs.berkeley.edu/~brewer/cs262/concurrency-distributed-databases.pdf] about deadlock prevention contains another two strategies: _priorities_ and _Wound-Wait_. Also, the mechanism should give a possibility to not use any strategy to prevent deadlock. All told, above shows we need to separate the prevention strategy in dedicate interface (which even has one implementation _Wait-Die_). Another implementation will be released by necessary. > Replaceable deadlock prevention mechanism > - > > Key: IGNITE-18043 > URL: https://issues.apache.org/jira/browse/IGNITE-18043 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > *Motivation:* > We have an embedded deadlock prevention strategy (presently, it is > _Wait-Die_). Although, [the original > paper|https://people.eecs.berkeley.edu/~brewer/cs262/concurrency-distributed-databases.pdf] > about deadlock prevention contains another two strategies: _priorities_ and > _Wound-Wait_. Also, the mechanism should give a possibility to not use any > strategy to prevent deadlock. > All told, above shows we need to separate the prevention strategy in dedicate > interface (which even has one implementation _Wait-Die_). Another > implementation will be released by necessary. > *Definition of Done:* > A deadlock resolution strategy (_ResolutionStrategy_) has to be extracted to > interface, which parametrizes _LockManager_. Wait-Die strategy > (_WaitDieLockResolutionStrategy_) will be the only one implementation of > _ResolutionStrategy_. > _HeapLockManager_ should be parametrized by _WaitDieLockResolutionStrategy_. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17733) Chnage lock manager implementation
[ https://issues.apache.org/jira/browse/IGNITE-17733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-17733: --- Description: *Motivation:* Lock manager should be based on _Wait-Die_ deadlock resolution strategy by default. The conception is implemented in [POC|https://github.com/ascherbakoff/ai3-txn-mvp]. Since current implementation has another resolution strategy, some tests will become failing. All those test should to be fixed as a part of the ticket. *Definition of Done:* Required to replace implementation of _HeapLockManager_ to [_Lock_ |https://github.com/ascherbakoff/ai3-txn-mvp/blob/main/src/main/java/com/ascherbakoff/ai3/lock/Lock.java] and adjusted API. Hence, the lock resolution strategy is changed, it leads to failing of tests from _AbstractLockManagerTest_ and _TxAbstractTest_. These failings have to be fixed. Property IGNITE_ALL_LOCK_TYPES_ARE_USED should be removed. *Workaround:* Until, this issue does not be fixed, we use lock only on primary keys. This behavior is turned by property IGNITE_ALL_LOCK_TYPES_ARE_USED. was: Lock manager should be based on _Wait-Die_ deadlock resolution strategy by default. The conception is implemented in [POC|https://github.com/ascherbakoff/ai3-txn-mvp]. Since current implementation has another resolution strategy, some tests will become failing. All those test should to be fixed as a part of the ticket. > Chnage lock manager implementation > -- > > Key: IGNITE-17733 > URL: https://issues.apache.org/jira/browse/IGNITE-17733 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > *Motivation:* > Lock manager should be based on _Wait-Die_ deadlock resolution strategy by > default. The conception is implemented in > [POC|https://github.com/ascherbakoff/ai3-txn-mvp]. > Since current implementation has another resolution strategy, some tests will > become failing. All those test should to be fixed as a part of the ticket. > *Definition of Done:* > Required to replace implementation of _HeapLockManager_ to [_Lock_ > |https://github.com/ascherbakoff/ai3-txn-mvp/blob/main/src/main/java/com/ascherbakoff/ai3/lock/Lock.java] > and adjusted API. > Hence, the lock resolution strategy is changed, it leads to failing of tests > from _AbstractLockManagerTest_ and _TxAbstractTest_. These failings have to > be fixed. > Property IGNITE_ALL_LOCK_TYPES_ARE_USED should be removed. > *Workaround:* > Until, this issue does not be fixed, we use lock only on primary keys. This > behavior is turned by property IGNITE_ALL_LOCK_TYPES_ARE_USED. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17690) Thin 3.0: Get and verify cluster id on connection
[ https://issues.apache.org/jira/browse/IGNITE-17690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627315#comment-17627315 ] Pavel Tupitsyn commented on IGNITE-17690: - Merged to main: 17804b5b741f037842fb5a9dc71e927ef2fbf02a > Thin 3.0: Get and verify cluster id on connection > - > > Key: IGNITE-17690 > URL: https://issues.apache.org/jira/browse/IGNITE-17690 > Project: Ignite > Issue Type: Improvement >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-90, ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Client need to get and verify cluster ID on handshake as described in > [IEP-90|https://cwiki.apache.org/confluence/display/IGNITE/IEP-90+Client+Lifecycle] > to make sure all servers it connects to are from the same cluster. This is > especially important during connection restoration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17690) Thin 3.0: Get and verify cluster id on connection
[ https://issues.apache.org/jira/browse/IGNITE-17690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627305#comment-17627305 ] Igor Sapego commented on IGNITE-17690: -- [~ptupitsyn] looks good to me. > Thin 3.0: Get and verify cluster id on connection > - > > Key: IGNITE-17690 > URL: https://issues.apache.org/jira/browse/IGNITE-17690 > Project: Ignite > Issue Type: Improvement >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-90, ignite-3 > > Client need to get and verify cluster ID on handshake as described in > [IEP-90|https://cwiki.apache.org/confluence/display/IGNITE/IEP-90+Client+Lifecycle] > to make sure all servers it connects to are from the same cluster. This is > especially important during connection restoration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18053) С++ Thin 3.0: Get and verify cluster id on connection
Igor Sapego created IGNITE-18053: Summary: С++ Thin 3.0: Get and verify cluster id on connection Key: IGNITE-18053 URL: https://issues.apache.org/jira/browse/IGNITE-18053 Project: Ignite Issue Type: Improvement Components: platforms, thin client Reporter: Igor Sapego Assignee: Igor Sapego Fix For: 3.0.0-beta2 Client needs to get and verify cluster ID on handshake as described in [IEP-90|https://cwiki.apache.org/confluence/display/IGNITE/IEP-90+Client+Lifecycle] to make sure all servers it connects to are from the same cluster. This is especially important during connection restoration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17733) Chnage lock manager implementation
[
https://issues.apache.org/jira/browse/IGNITE-17733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-17733:
---
Description:
Lock manager should be based on _Wait-Die_ deadlock resolution strategy by
default. The conception is implemented in
[POC|https://github.com/ascherbakoff/ai3-txn-mvp].
Since current implementation has another resolution strategy, some tests will
become failing. All those test should to be fixed as a part of the ticket.
was:
Due to an issue in protocol of lock manager, locks on indexes are avoided. Need
to find a way where we can use honest lock modes on indexes, but not convert
the type to {_}NL{_}.
> Chnage lock manager implementation
> --
>
> Key: IGNITE-17733
> URL: https://issues.apache.org/jira/browse/IGNITE-17733
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> Lock manager should be based on _Wait-Die_ deadlock resolution strategy by
> default. The conception is implemented in
> [POC|https://github.com/ascherbakoff/ai3-txn-mvp].
> Since current implementation has another resolution strategy, some tests will
> become failing. All those test should to be fixed as a part of the ticket.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17733) Chnage lock manager implementation
[
https://issues.apache.org/jira/browse/IGNITE-17733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-17733:
---
Summary: Chnage lock manager implementation (was: Resume honest index lock)
> Chnage lock manager implementation
> --
>
> Key: IGNITE-17733
> URL: https://issues.apache.org/jira/browse/IGNITE-17733
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> Due to an issue in protocol of lock manager, locks on indexes are avoided.
> Need to find a way where we can use honest lock modes on indexes, but not
> convert the type to {_}NL{_}.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18052) Introduce short term locks for sorted indexes operations
[
https://issues.apache.org/jira/browse/IGNITE-18052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-18052:
--
Description:
*Motivation:*
According to the transaction protocol IEP [1] insert operation in RW
transactions for sortex index looks as follows:
_Unique index:_
// insert
IX_short(nextKey) // released after the insertion
X_commit(currentKey) // acquired before releasing IX_short
_Non-unique index:_
// insert
IX_short(nextKey)
X_commit(currentKey) if nextKey previously locked in S, X or SIX mode
IX_commit(currentKey) otherwise
This is necessary to avoid races between insert and scan operations. However,
it's not yet implemented.
*Definition of done:*
Short term locks are acquired and released as described above.
*Implementation notes:*
For the code related to locks for indexes, see
{{org.apache.ignite.internal.table.distributed.IndexLocker}}. We are interested
in {{SortedIndexLocker}} implementation, method {{locksForInsert}}. Actually,
there is some draft, but it is commented.
[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol
was:
*Motivation:*
According to the transaction protocol IEP [1] insert operation in RW
transactions for sortex index looks as follows:
_Unique index:_
// insert
IX_short(nextKey) // released after the insertion
X_commit(currentKey) // acquired before releasing IX_short
_Non-unique index:_
// insert
IX_short(nextKey)
X_commit(currentKey) if nextKey previously locked in S, X or SIX mode
IX_commit(currentKey) otherwise
This is necessary to avoid races between insert and scan operations. However,
it's not yet implemented.
*Definition of done:*
Short term locks are acquired and released as described above.
*Implementation notes:*
For the code related to locks for indexes, see
{{org.apache.ignite.internal.table.distributed.IndexLocker}}. We are interested
in {{SortedIndexLocker }}implementation, method {{locksForInsert}}. Actually,
there is some draft, but it is commented.
[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol
> Introduce short term locks for sorted indexes operations
>
>
> Key: IGNITE-18052
> URL: https://issues.apache.org/jira/browse/IGNITE-18052
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> *Motivation:*
> According to the transaction protocol IEP [1] insert operation in RW
> transactions for sortex index looks as follows:
> _Unique index:_
> // insert
> IX_short(nextKey) // released after the insertion
> X_commit(currentKey) // acquired before releasing IX_short
> _Non-unique index:_
> // insert
> IX_short(nextKey)
> X_commit(currentKey) if nextKey previously locked in S, X or SIX mode
> IX_commit(currentKey) otherwise
> This is necessary to avoid races between insert and scan operations. However,
> it's not yet implemented.
> *Definition of done:*
> Short term locks are acquired and released as described above.
> *Implementation notes:*
> For the code related to locks for indexes, see
> {{org.apache.ignite.internal.table.distributed.IndexLocker}}. We are
> interested in {{SortedIndexLocker}} implementation, method
> {{locksForInsert}}. Actually, there is some draft, but it is commented.
> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18052) Introduce short term locks for sorted indexes operations
[
https://issues.apache.org/jira/browse/IGNITE-18052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-18052:
--
Description:
*Motivation*
According to the transaction protocol IEP [1] insert operation in RW
transactions for sortex index looks as follows:
_Unique index:_
// insert
IX_short(nextKey) // released after the insertion
X_commit(currentKey) // acquired before releasing IX_short
_Non-unique index:_
// insert
IX_short(nextKey)
X_commit(currentKey) if nextKey previously locked in S, X or SIX mode
IX_commit(currentKey) otherwise
This is necessary to avoid races between insert and scan operations. However,
it's not yet implemented.
*Definition of done:*
Short term locks are acquired and released as described above.
*Implementation notes:*
For the code related to locks for indexes, see
{{org.apache.ignite.internal.table.distributed.IndexLocker}}. We are interested
in {{SortedIndexLocker }}implementation, method {{locksForInsert}}. Actually,
there is some draft, but it is commented.
[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol
was:
Motivation
According to the transaction protocol IEP [1] insert operation in RW
transactions for sortex index looks as follows:
Unique index:
// insert
IX_short(nextKey) // released after the insertion
X_commit(currentKey) // acquired before releasing IX_short
Non-unique index:
// insert
IX_short(nextKey)
X_commit(currentKey) if nextKey previously locked in S, X or SIX mode
IX_commit(currentKey) otherwise
This is necessary to avoid races between insert and scan operations. However,
it's not yet implemented.
Definition of done:
Short term locks are acquired and released as described above.
Implementation notes:
For the code related to locks for indexes, see
{{org.apache.ignite.internal.table.distributed.IndexLocker}}. We are interested
in {{SortedIndexLocker }}implementation, method {{locksForInsert}}. Actually,
there is some draft, but it is commented.
[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol
> Introduce short term locks for sorted indexes operations
>
>
> Key: IGNITE-18052
> URL: https://issues.apache.org/jira/browse/IGNITE-18052
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> According to the transaction protocol IEP [1] insert operation in RW
> transactions for sortex index looks as follows:
> _Unique index:_
> // insert
> IX_short(nextKey) // released after the insertion
> X_commit(currentKey) // acquired before releasing IX_short
> _Non-unique index:_
> // insert
> IX_short(nextKey)
> X_commit(currentKey) if nextKey previously locked in S, X or SIX mode
> IX_commit(currentKey) otherwise
> This is necessary to avoid races between insert and scan operations. However,
> it's not yet implemented.
> *Definition of done:*
> Short term locks are acquired and released as described above.
> *Implementation notes:*
> For the code related to locks for indexes, see
> {{org.apache.ignite.internal.table.distributed.IndexLocker}}. We are
> interested in {{SortedIndexLocker }}implementation, method
> {{locksForInsert}}. Actually, there is some draft, but it is commented.
> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18052) Introduce short term locks for sorted indexes operations
[
https://issues.apache.org/jira/browse/IGNITE-18052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-18052:
--
Epic Link: IGNITE-18042
> Introduce short term locks for sorted indexes operations
>
>
> Key: IGNITE-18052
> URL: https://issues.apache.org/jira/browse/IGNITE-18052
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> Motivation
> According to the transaction protocol IEP [1] insert operation in RW
> transactions for sortex index looks as follows:
> Unique index:
> // insert
> IX_short(nextKey) // released after the insertion
> X_commit(currentKey) // acquired before releasing IX_short
> Non-unique index:
> // insert
> IX_short(nextKey)
> X_commit(currentKey) if nextKey previously locked in S, X or SIX mode
> IX_commit(currentKey) otherwise
> This is necessary to avoid races between insert and scan operations. However,
> it's not yet implemented.
> Definition of done:
> Short term locks are acquired and released as described above.
> Implementation notes:
> For the code related to locks for indexes, see
> {{org.apache.ignite.internal.table.distributed.IndexLocker}}. We are
> interested in {{SortedIndexLocker }}implementation, method
> {{locksForInsert}}. Actually, there is some draft, but it is commented.
> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18052) Introduce short term locks for sorted indexes operations
[
https://issues.apache.org/jira/browse/IGNITE-18052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-18052:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Introduce short term locks for sorted indexes operations
>
>
> Key: IGNITE-18052
> URL: https://issues.apache.org/jira/browse/IGNITE-18052
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> Motivation
> According to the transaction protocol IEP [1] insert operation in RW
> transactions for sortex index looks as follows:
> Unique index:
> // insert
> IX_short(nextKey) // released after the insertion
> X_commit(currentKey) // acquired before releasing IX_short
> Non-unique index:
> // insert
> IX_short(nextKey)
> X_commit(currentKey) if nextKey previously locked in S, X or SIX mode
> IX_commit(currentKey) otherwise
> This is necessary to avoid races between insert and scan operations. However,
> it's not yet implemented.
> Definition of done:
> Short term locks are acquired and released as described above.
> Implementation notes:
> For the code related to locks for indexes, see
> {{org.apache.ignite.internal.table.distributed.IndexLocker}}. We are
> interested in {{SortedIndexLocker }}implementation, method
> {{locksForInsert}}. Actually, there is some draft, but it is commented.
> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18052) Introduce short term locks for sorted indexes operations
Denis Chudov created IGNITE-18052:
-
Summary: Introduce short term locks for sorted indexes operations
Key: IGNITE-18052
URL: https://issues.apache.org/jira/browse/IGNITE-18052
Project: Ignite
Issue Type: Improvement
Reporter: Denis Chudov
Motivation
According to the transaction protocol IEP [1] insert operation in RW
transactions for sortex index looks as follows:
Unique index:
// insert
IX_short(nextKey) // released after the insertion
X_commit(currentKey) // acquired before releasing IX_short
Non-unique index:
// insert
IX_short(nextKey)
X_commit(currentKey) if nextKey previously locked in S, X or SIX mode
IX_commit(currentKey) otherwise
This is necessary to avoid races between insert and scan operations. However,
it's not yet implemented.
Definition of done:
Short term locks are acquired and released as described above.
Implementation notes:
For the code related to locks for indexes, see
{{org.apache.ignite.internal.table.distributed.IndexLocker}}. We are interested
in {{SortedIndexLocker }}implementation, method {{locksForInsert}}. Actually,
there is some draft, but it is commented.
[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18052) Introduce short term locks for sorted indexes operations
[
https://issues.apache.org/jira/browse/IGNITE-18052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-18052:
--
Description:
*Motivation:*
According to the transaction protocol IEP [1] insert operation in RW
transactions for sortex index looks as follows:
_Unique index:_
// insert
IX_short(nextKey) // released after the insertion
X_commit(currentKey) // acquired before releasing IX_short
_Non-unique index:_
// insert
IX_short(nextKey)
X_commit(currentKey) if nextKey previously locked in S, X or SIX mode
IX_commit(currentKey) otherwise
This is necessary to avoid races between insert and scan operations. However,
it's not yet implemented.
*Definition of done:*
Short term locks are acquired and released as described above.
*Implementation notes:*
For the code related to locks for indexes, see
{{org.apache.ignite.internal.table.distributed.IndexLocker}}. We are interested
in {{SortedIndexLocker }}implementation, method {{locksForInsert}}. Actually,
there is some draft, but it is commented.
[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol
was:
*Motivation*
According to the transaction protocol IEP [1] insert operation in RW
transactions for sortex index looks as follows:
_Unique index:_
// insert
IX_short(nextKey) // released after the insertion
X_commit(currentKey) // acquired before releasing IX_short
_Non-unique index:_
// insert
IX_short(nextKey)
X_commit(currentKey) if nextKey previously locked in S, X or SIX mode
IX_commit(currentKey) otherwise
This is necessary to avoid races between insert and scan operations. However,
it's not yet implemented.
*Definition of done:*
Short term locks are acquired and released as described above.
*Implementation notes:*
For the code related to locks for indexes, see
{{org.apache.ignite.internal.table.distributed.IndexLocker}}. We are interested
in {{SortedIndexLocker }}implementation, method {{locksForInsert}}. Actually,
there is some draft, but it is commented.
[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol
> Introduce short term locks for sorted indexes operations
>
>
> Key: IGNITE-18052
> URL: https://issues.apache.org/jira/browse/IGNITE-18052
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> *Motivation:*
> According to the transaction protocol IEP [1] insert operation in RW
> transactions for sortex index looks as follows:
> _Unique index:_
> // insert
> IX_short(nextKey) // released after the insertion
> X_commit(currentKey) // acquired before releasing IX_short
> _Non-unique index:_
> // insert
> IX_short(nextKey)
> X_commit(currentKey) if nextKey previously locked in S, X or SIX mode
> IX_commit(currentKey) otherwise
> This is necessary to avoid races between insert and scan operations. However,
> it's not yet implemented.
> *Definition of done:*
> Short term locks are acquired and released as described above.
> *Implementation notes:*
> For the code related to locks for indexes, see
> {{org.apache.ignite.internal.table.distributed.IndexLocker}}. We are
> interested in {{SortedIndexLocker }}implementation, method
> {{locksForInsert}}. Actually, there is some draft, but it is commented.
> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18052) Introduce short term locks for sorted indexes operations
[
https://issues.apache.org/jira/browse/IGNITE-18052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-18052:
--
Labels: ignite-3 (was: )
> Introduce short term locks for sorted indexes operations
>
>
> Key: IGNITE-18052
> URL: https://issues.apache.org/jira/browse/IGNITE-18052
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> Motivation
> According to the transaction protocol IEP [1] insert operation in RW
> transactions for sortex index looks as follows:
> Unique index:
> // insert
> IX_short(nextKey) // released after the insertion
> X_commit(currentKey) // acquired before releasing IX_short
> Non-unique index:
> // insert
> IX_short(nextKey)
> X_commit(currentKey) if nextKey previously locked in S, X or SIX mode
> IX_commit(currentKey) otherwise
> This is necessary to avoid races between insert and scan operations. However,
> it's not yet implemented.
> Definition of done:
> Short term locks are acquired and released as described above.
> Implementation notes:
> For the code related to locks for indexes, see
> {{org.apache.ignite.internal.table.distributed.IndexLocker}}. We are
> interested in {{SortedIndexLocker }}implementation, method
> {{locksForInsert}}. Actually, there is some draft, but it is commented.
> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17741) idle_verify must provide explicit data and version hashes
[
https://issues.apache.org/jira/browse/IGNITE-17741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627275#comment-17627275
]
Ignite TC Bot commented on IGNITE-17741:
{panel:title=Branch: [pull/10357/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10357/head] Base: [master] : New Tests
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Queries 3 (lazy=true){color} [[tests
2|https://ci2.ignite.apache.org/viewLog.html?buildId=6883069]]
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite3:
StatisticsConfigurationTest.testOrphanDataCleanup[persist=false] - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite3:
StatisticsConfigurationTest.testOrphanDataCleanup[persist=true] - PASSED{color}
{color:#8b}Queries 3{color} [[tests
2|https://ci2.ignite.apache.org/viewLog.html?buildId=6883068]]
* {color:#013220}IgniteBinaryCacheQueryTestSuite3:
StatisticsConfigurationTest.testOrphanDataCleanup[persist=false] - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite3:
StatisticsConfigurationTest.testOrphanDataCleanup[persist=true] - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6883095buildTypeId=IgniteTests24Java8_RunAll]
> idle_verify must provide explicit data and version hashes
> -
>
> Key: IGNITE-17741
> URL: https://issues.apache.org/jira/browse/IGNITE-17741
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: iep-31, ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently we have a single hash.
> Separated hashes will provide more information.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18051) Extend test coverage for lock model
[
https://issues.apache.org/jira/browse/IGNITE-18051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-18051:
--
Issue Type: Improvement (was: Bug)
> Extend test coverage for lock model
> ---
>
> Key: IGNITE-18051
> URL: https://issues.apache.org/jira/browse/IGNITE-18051
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> There is a transaction MVP [1] that contains decent implementation of
> transaction and lock model. There are multiple tests that deserve to be moved
> in Ignite 3 to improve test coverage of the lock model.
> *Implementation notes*
> Some of the test scenarios may be already implemented in
> {{org.apache.ignite.internal.table.TxAbstractTest}} in Ignite. Also, some of
> them can be implemented as lock manager tests (see
> {{org.apache.ignite.internal.tx.AbstractLockManagerTest}} ) or tests for the
> deadlock prevention strategies (are going to be created under IGNITE-18043 ).
> [1] https://github.com/ascherbakoff/ai3-txn-mvp
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18051) Extend test coverage for lock model
[
https://issues.apache.org/jira/browse/IGNITE-18051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-18051:
--
Description:
*Motivation*
There is a transaction MVP [1] that contains decent implementation of
transaction and lock model. There are multiple tests that deserve to be moved
in Ignite 3 to improve test coverage of the lock model.
*Implementation notes*
Some of the test scenarios may be already implemented in
{{org.apache.ignite.internal.table.TxAbstractTest}} in Ignite. Also, some of
them can be implemented as lock manager tests (see
{{org.apache.ignite.internal.tx.AbstractLockManagerTest}} ) or tests for the
deadlock prevention strategies (are going to be created under IGNITE-18043 ).
[1] https://github.com/ascherbakoff/ai3-txn-mvp
was:
*Motivation*
There is a transaction MVP [1] that contains decent implementation of
transaction and lock model. There are multiple test that deserve to be moved in
Ignite 3 to improve test coverage of the lock model.
*Implementation notes*
Some of the test scenarios may be already implemented in
{{org.apache.ignite.internal.table.TxAbstractTest}} in Ignite. Also, some of
them can be implemented as lock manager tests (see
{{org.apache.ignite.internal.tx.AbstractLockManagerTest}} ) or tests for the
deadlock prevention strategies (are going to be created under IGNITE-18043 ).
[1] https://github.com/ascherbakoff/ai3-txn-mvp
> Extend test coverage for lock model
> ---
>
> Key: IGNITE-18051
> URL: https://issues.apache.org/jira/browse/IGNITE-18051
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> There is a transaction MVP [1] that contains decent implementation of
> transaction and lock model. There are multiple tests that deserve to be moved
> in Ignite 3 to improve test coverage of the lock model.
> *Implementation notes*
> Some of the test scenarios may be already implemented in
> {{org.apache.ignite.internal.table.TxAbstractTest}} in Ignite. Also, some of
> them can be implemented as lock manager tests (see
> {{org.apache.ignite.internal.tx.AbstractLockManagerTest}} ) or tests for the
> deadlock prevention strategies (are going to be created under IGNITE-18043 ).
> [1] https://github.com/ascherbakoff/ai3-txn-mvp
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18051) Extend test coverage for lock model
[
https://issues.apache.org/jira/browse/IGNITE-18051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-18051:
--
Description:
*Motivation*
There is a transaction MVP [1] that contains decent implementation of
transaction and lock model. There are multiple test that deserve to be moved in
Ignite 3 to improve test coverage of the lock model.
*Implementation notes*
Some of the test scenarios may be already implemented in
{{org.apache.ignite.internal.table.TxAbstractTest}} in Ignite. Also, some of
them may be implemented as lock manager tests (see
{{org.apache.ignite.internal.tx.AbstractLockManagerTest}} ) or tests for the
deadlock prevention strategies (are going to be implemented under IGNITE-18043
).
[1] https://github.com/ascherbakoff/ai3-txn-mvp
was:
Motivation
There is a transaction MVP [1] that contains decent implementation of
transaction and lock model. There are multiple test that deserve to be moved in
Ignite 3 to improve test coverage of the lock model.
Implementation notes
Some of the test scenarios may be already implemented in
{{org.apache.ignite.internal.table.TxAbstractTest}} in Ignite. Also, some of
them may be implemented as lock manager tests (see
{{org.apache.ignite.internal.tx.AbstractLockManagerTest}} ) or tests for the
deadlock prevention strategies (are going to be implemented under IGNITE-18043
).
[1] https://github.com/ascherbakoff/ai3-txn-mvp
> Extend test coverage for lock model
> ---
>
> Key: IGNITE-18051
> URL: https://issues.apache.org/jira/browse/IGNITE-18051
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> There is a transaction MVP [1] that contains decent implementation of
> transaction and lock model. There are multiple test that deserve to be moved
> in Ignite 3 to improve test coverage of the lock model.
> *Implementation notes*
> Some of the test scenarios may be already implemented in
> {{org.apache.ignite.internal.table.TxAbstractTest}} in Ignite. Also, some of
> them may be implemented as lock manager tests (see
> {{org.apache.ignite.internal.tx.AbstractLockManagerTest}} ) or tests for the
> deadlock prevention strategies (are going to be implemented under
> IGNITE-18043 ).
> [1] https://github.com/ascherbakoff/ai3-txn-mvp
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18051) Extend test coverage for lock model
[
https://issues.apache.org/jira/browse/IGNITE-18051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-18051:
--
Description:
*Motivation*
There is a transaction MVP [1] that contains decent implementation of
transaction and lock model. There are multiple test that deserve to be moved in
Ignite 3 to improve test coverage of the lock model.
*Implementation notes*
Some of the test scenarios may be already implemented in
{{org.apache.ignite.internal.table.TxAbstractTest}} in Ignite. Also, some of
them can be implemented as lock manager tests (see
{{org.apache.ignite.internal.tx.AbstractLockManagerTest}} ) or tests for the
deadlock prevention strategies (are going to be created under IGNITE-18043 ).
[1] https://github.com/ascherbakoff/ai3-txn-mvp
was:
*Motivation*
There is a transaction MVP [1] that contains decent implementation of
transaction and lock model. There are multiple test that deserve to be moved in
Ignite 3 to improve test coverage of the lock model.
*Implementation notes*
Some of the test scenarios may be already implemented in
{{org.apache.ignite.internal.table.TxAbstractTest}} in Ignite. Also, some of
them can be implemented as lock manager tests (see
{{org.apache.ignite.internal.tx.AbstractLockManagerTest}} ) or tests for the
deadlock prevention strategies (are going to be implemented under IGNITE-18043
).
[1] https://github.com/ascherbakoff/ai3-txn-mvp
> Extend test coverage for lock model
> ---
>
> Key: IGNITE-18051
> URL: https://issues.apache.org/jira/browse/IGNITE-18051
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> There is a transaction MVP [1] that contains decent implementation of
> transaction and lock model. There are multiple test that deserve to be moved
> in Ignite 3 to improve test coverage of the lock model.
> *Implementation notes*
> Some of the test scenarios may be already implemented in
> {{org.apache.ignite.internal.table.TxAbstractTest}} in Ignite. Also, some of
> them can be implemented as lock manager tests (see
> {{org.apache.ignite.internal.tx.AbstractLockManagerTest}} ) or tests for the
> deadlock prevention strategies (are going to be created under IGNITE-18043 ).
> [1] https://github.com/ascherbakoff/ai3-txn-mvp
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18051) Extend test coverage for lock model
[
https://issues.apache.org/jira/browse/IGNITE-18051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-18051:
--
Description:
*Motivation*
There is a transaction MVP [1] that contains decent implementation of
transaction and lock model. There are multiple test that deserve to be moved in
Ignite 3 to improve test coverage of the lock model.
*Implementation notes*
Some of the test scenarios may be already implemented in
{{org.apache.ignite.internal.table.TxAbstractTest}} in Ignite. Also, some of
them can be implemented as lock manager tests (see
{{org.apache.ignite.internal.tx.AbstractLockManagerTest}} ) or tests for the
deadlock prevention strategies (are going to be implemented under IGNITE-18043
).
[1] https://github.com/ascherbakoff/ai3-txn-mvp
was:
*Motivation*
There is a transaction MVP [1] that contains decent implementation of
transaction and lock model. There are multiple test that deserve to be moved in
Ignite 3 to improve test coverage of the lock model.
*Implementation notes*
Some of the test scenarios may be already implemented in
{{org.apache.ignite.internal.table.TxAbstractTest}} in Ignite. Also, some of
them may be implemented as lock manager tests (see
{{org.apache.ignite.internal.tx.AbstractLockManagerTest}} ) or tests for the
deadlock prevention strategies (are going to be implemented under IGNITE-18043
).
[1] https://github.com/ascherbakoff/ai3-txn-mvp
> Extend test coverage for lock model
> ---
>
> Key: IGNITE-18051
> URL: https://issues.apache.org/jira/browse/IGNITE-18051
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> There is a transaction MVP [1] that contains decent implementation of
> transaction and lock model. There are multiple test that deserve to be moved
> in Ignite 3 to improve test coverage of the lock model.
> *Implementation notes*
> Some of the test scenarios may be already implemented in
> {{org.apache.ignite.internal.table.TxAbstractTest}} in Ignite. Also, some of
> them can be implemented as lock manager tests (see
> {{org.apache.ignite.internal.tx.AbstractLockManagerTest}} ) or tests for the
> deadlock prevention strategies (are going to be implemented under
> IGNITE-18043 ).
> [1] https://github.com/ascherbakoff/ai3-txn-mvp
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18051) Extend test coverage for lock model
Denis Chudov created IGNITE-18051:
-
Summary: Extend test coverage for lock model
Key: IGNITE-18051
URL: https://issues.apache.org/jira/browse/IGNITE-18051
Project: Ignite
Issue Type: Bug
Reporter: Denis Chudov
Motivation
There is a transaction MVP [1] that contains decent implementation of
transaction and lock model. There are multiple test that deserve to be moved in
Ignite 3 to improve test coverage of the lock model.
Implementation notes
Some of the test scenarios may be already implemented in
{{org.apache.ignite.internal.table.TxAbstractTest}} in Ignite. Also, some of
them may be implemented as lock manager tests (see
{{org.apache.ignite.internal.tx.AbstractLockManagerTest}} ) or tests for the
deadlock prevention strategies (are going to be implemented under IGNITE-18043
).
[1] https://github.com/ascherbakoff/ai3-txn-mvp
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18050) Possible phantom reads during sorted index scan
[
https://issues.apache.org/jira/browse/IGNITE-18050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-18050:
--
Description:
According to transaction protocol IEP [1], locking protocol for scan operation
over sorted index looks as follows (we assume the forward scans):
// scan
If the currentKey is bigger than the upper bound, return NOT_FOUND but take a
lock anyway.
If currentKey matches the upper bound no need to take a lock on the next key.
If the upper bound is null, take a lock on +INF.
If currentKey is not found, take a lock on +INF.
S_commit(currentKey)
// insert
IX_short(nextKey) // released after the insertion
X_commit(currentKey) // acquired before releasing IX_short
For example, scan(2, false, 4, false) must take S locks on keys 3 and 5. Note
that this will falsely lock the insertion of key 4, but we can’t do anything
here due to the chosen conservative approach.
Also we are going to prevent phantom reads by peeking next key before taking
the lock.
Consider table *t* with field *a* and sorted index:
3 -> rowId(3)
6 -> rowId(6)
Three concurrent transactions are running, below each line is a moment in time
(assuming select actually performs scan operation):
{code:java}
tx1 | tx2 | tx3
performs select * from t where a >= 3 and a <= 6| performs insert(5) |
performs insert(4)
next(): currentKey = 3 | |
S_commit(3) | |
peek(): nextKey = 6 | |
// hangs for a while| |
| IX_short(6) |
| X_commit(5) |
| commit() |
| |
IX_short(5)
| |
X_commit(4)
| |
commit()
S_commit(6) | |
next(): currentKey = 5 | |
... | |
select returns following: | |
3 | |
5 | |
6 | |
| |
the same select is repeated.| |
now it returns: | |
3 | |
4 | |
5 | |
6 | |
{code}
We see a phantom read for second select within tx1, which violates
serializability.
So we should either repeat peeking next key in a loop until next() operation
returns the key that was actually S_locked, or take IX_short lock on previous
key during insert. The former doesn't seem to be efficient.
[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol
was:
According to transaction protocol IEP [1], locking protocol for scan operation
over sorted index looks as follows (we assume the forward scans):
// scan
If the currentKey is bigger than the upper bound, return NOT_FOUND but take a
lock anyway.
If currentKey matches the upper bound no need to take a lock on the next key.
If the upper bound is null, take a lock on +INF.
If currentKey is not found, take a lock on +INF.
S_commit(currentKey)
// insert
IX_short(nextKey) // released after the insertion
X_commit(currentKey) // acquired before releasing IX_short
For example, scan(2, false, 4, false) must take S locks on keys 3 and 5. Note
that this will falsely lock the insertion of key 4, but we can’t do anything
here due to the chosen conservative approach.
Also we are going to prevent phantom reads by peeking next key before taking
the lock.
Consider table *t* with field *a* and sorted index:
3 -> rowId(3)
6 -> rowId(6)
Three concurrent transactions are running, below each line is a moment in time
(assuming select actually performs scan operation):
{code:java}
tx1 | tx2 | tx3
performs select * from t where a >= 3 and a <= 6| performs insert(5) |
performs insert(4)
next(): currentKey = 3 | |
[jira] [Updated] (IGNITE-18007) macOS support for Ignite 3 C++ client
[ https://issues.apache.org/jira/browse/IGNITE-18007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semyon Danilov updated IGNITE-18007: Reviewer: Igor Sapego > macOS support for Ignite 3 C++ client > - > > Key: IGNITE-18007 > URL: https://issues.apache.org/jira/browse/IGNITE-18007 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > Currently there's support for Windows and Linux. MacOS (and other BSD > relatives) doesn't have epoll for async IO operations. It is possible, > however, to add support with relatively easy approach: using epoll-shim > library, that lets user epoll api over kqueue -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18050) Possible phantom reads during sorted index scan
[
https://issues.apache.org/jira/browse/IGNITE-18050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-18050:
--
Description:
According to transaction protocol IEP [1], locking protocol for scan operation
over sorted index looks as follows (we assume the forward scans):
// scan
If the currentKey is bigger than the upper bound, return NOT_FOUND but take a
lock anyway.
If currentKey matches the upper bound no need to take a lock on the next key.
If the upper bound is null, take a lock on +INF.
If currentKey is not found, take a lock on +INF.
S_commit(currentKey)
// insert
IX_short(nextKey) // released after the insertion
X_commit(currentKey) // acquired before releasing IX_short
For example, scan(2, false, 4, false) must take S locks on keys 3 and 5. Note
that this will falsely lock the insertion of key 4, but we can’t do anything
here due to the chosen conservative approach.
Also we are going to prevent phantom reads by peeking next key before taking
the lock.
Consider table *t* with field *a* and sorted index:
3 -> rowId(3)
6 -> rowId(6)
Three concurrent transactions are running, below each line is a moment in time
(assuming select actually performs scan operation):
{code:java}
tx1 | tx2 | tx3
performs select * from t where a >= 3 and a <= 6| performs insert(5) |
performs insert(4)
next(): currentKey = 3 | |
peek(): nextKey = 6 | |
// hangs for a while| |
| IX_short(6) |
| X_commit(5) |
| commit() |
| |
IX_short(5)
| |
X_commit(4)
| |
commit()
S_commit(6) | |
next(): currentKey = 5 | |
... | |
select returns following: | |
3 | |
5 | |
6 | |
| |
the same select is repeated.| |
now it returns: | |
3 | |
4 | |
5 | |
6 | |
{code}
We see a phantom read for second select within tx1, which violates
serializability.
So we should either repeat peeking next key in a loop until next() operation
returns the key that was actually S_locked, or choose another approach because
loop doesn't seem to be efficient.
[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol
was:
According to transaction protocol IEP [1], locking protocol for scan operation
over sorted index looks as follows (we assume the forward scans):
// scan
If the currentKey is bigger than the upper bound, return NOT_FOUND but take a
lock anyway.
If currentKey matches the upper bound no need to take a lock on the next key.
If the upper bound is null, take a lock on +INF.
If currentKey is not found, take a lock on +INF.
S_commit(currentKey)
// insert
IX_short(nextKey) // released after the insertion
X_commit(currentKey) // acquired before releasing IX_short
For example, scan(2, false, 4, false) must take S locks on keys 3 and 5. Note
that this will falsely lock the insertion of key 4, but we can’t do anything
here due to the chosen conservative approach.
Also we are going to prevent phantom reads by peeking next key before taking
the lock.
Consider table t with field a and sorted index:
3 -> rowId(3)
6 -> rowId(6)
Three concurrent transactions are running, below each line is a moment in time
(assuming select actually performs scan operation):
{code:java}
tx1 | tx2 | tx3
performs select * from t where a >= 3 and a <= 6| performs insert(5) |
performs insert(4)
next(): currentKey = 3 | |
peek(): nextKey = 6 | |
// hangs for a while
[jira] [Updated] (IGNITE-18050) Possible phantom reads during sorted index scan
[
https://issues.apache.org/jira/browse/IGNITE-18050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-18050:
--
Description:
According to transaction protocol IEP [1], locking protocol for scan operation
over sorted index looks as follows (we assume the forward scans):
// scan
If the currentKey is bigger than the upper bound, return NOT_FOUND but take a
lock anyway.
If currentKey matches the upper bound no need to take a lock on the next key.
If the upper bound is null, take a lock on +INF.
If currentKey is not found, take a lock on +INF.
S_commit(currentKey)
// insert
IX_short(nextKey) // released after the insertion
X_commit(currentKey) // acquired before releasing IX_short
For example, scan(2, false, 4, false) must take S locks on keys 3 and 5. Note
that this will falsely lock the insertion of key 4, but we can’t do anything
here due to the chosen conservative approach.
Also we are going to prevent phantom reads by peeking next key before taking
the lock.
Consider table t with field a and sorted index:
3 -> rowId(3)
6 -> rowId(6)
Three concurrent transactions are running, below each line is a moment in time
(assuming select actually performs scan operation):
{code:java}
tx1 | tx2 | tx3
performs select * from t where a >= 3 and a <= 6| performs insert(5) |
performs insert(4)
next(): currentKey = 3 | |
peek(): nextKey = 6 | |
// hangs for a while| |
| IX_short(6) |
| X_commit(5) |
| commit() |
| |
IX_short(5)
| |
X_commit(4)
| |
commit()
S_commit(6) | |
next(): currentKey = 5 | |
... | |
select returns following: | |
3 | |
5 | |
6 | |
| |
the same select is repeated.| |
now it returns: | |
3 | |
4 | |
5 | |
6 | |
{code}
We see a phantom read for second select within tx1, which violates
serializability.
So we should either repeat peeking next key in a loop until next() operation
returns the key that was actually S_locked, or choose another approach because
loop doesn't seem to be efficient.
[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol
was:
According to transaction protocol IEP [1], locking protocol for scan operation
over sorted index looks as follows (we assume the forward scans):
// scan
If the currentKey is bigger than the upper bound, return NOT_FOUND but take a
lock anyway.
If currentKey matches the upper bound no need to take a lock on the next key.
If the upper bound is null, take a lock on +INF.
If currentKey is not found, take a lock on +INF.
S_commit(currentKey)
// insert
IX_short(nextKey) // released after the insertion
X_commit(currentKey) // acquired before releasing IX_short
For example, scan(2, false, 4, false) must take S locks on keys 3 and 5. Note
that this will falsely lock the insertion of key 4, but we can’t do anything
here due to the chosen conservative approach.
Also we are going to prevent phantom reads by peeking next key before taking
the lock.
Consider table t with field a and sorted index:
3 -> rowId(3)
6 -> rowId(6)
Three concurrent transactions are running, below each line is a moment in time
(assuming select actually performs scan operation):
{code:java}
tx1 | tx2
| tx3
performs select * from t where a >= 3 and a <= 6| performs insert(5)
| performs insert(4)
next(): currentKey = 3 |
|
peek(): nextKey = 6
[jira] [Created] (IGNITE-18050) Possible phantom reads during sorted index scan
Denis Chudov created IGNITE-18050:
-
Summary: Possible phantom reads during sorted index scan
Key: IGNITE-18050
URL: https://issues.apache.org/jira/browse/IGNITE-18050
Project: Ignite
Issue Type: Bug
Reporter: Denis Chudov
According to transaction protocol IEP [1], locking protocol for scan operation
over sorted index looks as follows (we assume the forward scans):
// scan
If the currentKey is bigger than the upper bound, return NOT_FOUND but take a
lock anyway.
If currentKey matches the upper bound no need to take a lock on the next key.
If the upper bound is null, take a lock on +INF.
If currentKey is not found, take a lock on +INF.
S_commit(currentKey)
// insert
IX_short(nextKey) // released after the insertion
X_commit(currentKey) // acquired before releasing IX_short
For example, scan(2, false, 4, false) must take S locks on keys 3 and 5. Note
that this will falsely lock the insertion of key 4, but we can’t do anything
here due to the chosen conservative approach.
Also we are going to prevent phantom reads by peeking next key before taking
the lock.
Consider table t with field a and sorted index:
3 -> rowId(3)
6 -> rowId(6)
Three concurrent transactions are running, below each line is a moment in time
(assuming select actually performs scan operation):
{code:java}
tx1 | tx2
| tx3
performs select * from t where a >= 3 and a <= 6| performs insert(5)
| performs insert(4)
next(): currentKey = 3 |
|
peek(): nextKey = 6 |
|
// hangs for a while|
|
| IX_short(6)
|
| X_commit(5)
|
| commit()
|
|
| IX_short(5)
|
| X_commit(4)
|
| commit()
S_commit(6) |
|
next(): currentKey = 5 |
|
... |
|
select returns following: |
|
3 |
|
5 |
|
6 |
|
|
|
the same select is repeated.|
|
now it returns: |
|
3 |
|
4 |
|
5 |
|
6 |
|
{code}
We see a phantom read for second select within tx1, which violates
serializability.
So we should either repeat peeking next key in a loop until next() operation
returns the key that was actually S_locked, or choose another approach because
loop doesn't seem to be efficient.
[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17989) JVM memory usage metric source
[ https://issues.apache.org/jira/browse/IGNITE-17989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627247#comment-17627247 ] Vyacheslav Koptilin commented on IGNITE-17989: -- LGTM > JVM memory usage metric source > -- > > Key: IGNITE-17989 > URL: https://issues.apache.org/jira/browse/IGNITE-17989 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > h3. Motivation > It will be useful to have builtin metric source with jvm memory usage stats. > h3. Definition of Done > It must expose the following metrics as a separate gauge metric each: > * heap memory usage (init/used/commited/max) > * non-heap memory usage (init/used/commited/max) > * name of metrics should have the general prefix "jvm." to group all future > jvm metrics together > Also, it needs to check, if calculation of these stats is heavy and we need > to cache it for some time windows. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18021) Creating an API for full rebalance without losing user data in MvPartitionStorage on receiver
[ https://issues.apache.org/jira/browse/IGNITE-18021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-18021: - Reviewer: Aleksandr Polovtcev (was: Roman Puchkovskiy) > Creating an API for full rebalance without losing user data in > MvPartitionStorage on receiver > - > > Key: IGNITE-18021 > URL: https://issues.apache.org/jira/browse/IGNITE-18021 > Project: Ignite > Issue Type: Task >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > We need to create an API for a complete rebalance without losing user data in > class *MvPartitionStorage* and *MvTableStorage* on receiver. > And also to make a test implementation and basic tests. > The main idea is described in IGNITE-17990. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18048) Issues breakdown for lock management
[ https://issues.apache.org/jira/browse/IGNITE-18048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-18048: -- Summary: Issues breakdown for lock management (was: Issues breakdown for lock managment) > Issues breakdown for lock management > > > Key: IGNITE-18048 > URL: https://issues.apache.org/jira/browse/IGNITE-18048 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > Estimate and add a description in detail for all tickets from the epic. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18048) Issues breakdown for lock managment
[ https://issues.apache.org/jira/browse/IGNITE-18048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-18048: -- Summary: Issues breakdown for lock managment (was: Breack down issues for lock managment) > Issues breakdown for lock managment > --- > > Key: IGNITE-18048 > URL: https://issues.apache.org/jira/browse/IGNITE-18048 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > Estimate and add a description in detail for all tickets from the epic. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17435) Fix Datastreamer documentation.
[ https://issues.apache.org/jira/browse/IGNITE-17435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Amelchev updated IGNITE-17435: - Fix Version/s: 2.15 > Fix Datastreamer documentation. > --- > > Key: IGNITE-17435 > URL: https://issues.apache.org/jira/browse/IGNITE-17435 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Labels: ise > Fix For: 2.15 > > > The doc should mention something like: > Setting the `allowOverwrite` property to false is best used for initial data > load on a cluster with stable topology. When cluster works under load, some > actions may cause issues with data consistency. To avoid them: > * Avoid having the same keys repeating in the data being streamed; > * Avoid concurrent updates of the cache that is being streamed into; > * Avoid streamer fauilure. > * Avoid snapshotting. > Also, the docs should note streamer's limitations and traits. > Additionally, we may warn into log that datastreamer should successfully > finish. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-17384) IdleVerify: print partition conflicts into control-utility.log
[
https://issues.apache.org/jira/browse/IGNITE-17384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627198#comment-17627198
]
Ilya Shishkov edited comment on IGNITE-17384 at 11/1/22 2:59 PM:
-
[~nizhikov], there are some updates:
It seems, that results are printed into {{idle_verify*.txt}} files *_only in
case of exceptions_* during check, eg. when some nodes leaves a cluster or
cluster is not idle. So, even if partition conflicts present on the cluster,
they will not be printed to logs or {{idle_verify*.txt}} files in case of
exceptions absence.
I think, that it is a bug and partition conflicts should be always printed into
logs or such text files.
was (Author: shishkovilja):
[~nizhikov], there are some updates:
It seems, that results are printed into {{idle_verify*.txt}} files *_only in
case of exceptions_* during check, eg. when some nodes leaves a cluster or
cluster is not idle. So, even if partition conflicts present on the cluster,
they will not be printed to logs or {{idle_verify*.txt}} files.
I think, that it is a bug and partition conflicts should be always printed into
logs or such text files.
> IdleVerify: print partition conflicts into control-utility.log
> --
>
> Key: IGNITE-17384
> URL: https://issues.apache.org/jira/browse/IGNITE-17384
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
>
> Currently, when you call {{control.sh --cache idle_verify}}, partition
> conflicts will be printed into standard output, but they are missing in the
> control-utility.log. So, if you have many conflicts, you should additionally
> redirect output to a file in order to send information for a further analysis.
> It would be more convenient to print partition conflicts in the
> control-utility.log file too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-17384) IdleVerify: print partition conflicts into control-utility.log
[
https://issues.apache.org/jira/browse/IGNITE-17384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627198#comment-17627198
]
Ilya Shishkov edited comment on IGNITE-17384 at 11/1/22 2:58 PM:
-
[~nizhikov], there are some updates:
It seems, that results are printed into {{idle_verify*.txt}} files *_only in
case of exceptions_* during check, eg. when some nodes leaves a cluster or
cluster is not idle. So, even if partition conflicts present on the cluster,
they will not be printed to logs or {{idle_verify*.txt}} files.
I think, that it is a bug and partition conflicts should be always printed into
logs or such text files.
was (Author: shishkovilja):
[~nizhikov], there are some updates:
It seems, that results are printed into {{idle_verify*.txt}} files only in case
of exceptions during check, eg. when some nodes leaves a cluster or cluster is
not idle. So, even if partition conflicts present on the cluster, they will not
be printed to logs or {{idle_verify*.txt}} files.
I think, that it is a bug and partition conflicts should be always printed into
logs or such text files.
> IdleVerify: print partition conflicts into control-utility.log
> --
>
> Key: IGNITE-17384
> URL: https://issues.apache.org/jira/browse/IGNITE-17384
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
>
> Currently, when you call {{control.sh --cache idle_verify}}, partition
> conflicts will be printed into standard output, but they are missing in the
> control-utility.log. So, if you have many conflicts, you should additionally
> redirect output to a file in order to send information for a further analysis.
> It would be more convenient to print partition conflicts in the
> control-utility.log file too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-17384) IdleVerify: print partition conflicts into control-utility.log
[
https://issues.apache.org/jira/browse/IGNITE-17384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627198#comment-17627198
]
Ilya Shishkov edited comment on IGNITE-17384 at 11/1/22 2:57 PM:
-
[~nizhikov], there are some updates:
It seems, that results are printed into {{idle_verify*.txt}} files only in case
of exceptions during check, eg. when some nodes leaves a cluster or cluster is
not idle. So, even if partition conflicts present on the cluster, they will not
be printed to logs or {{idle_verify*.txt}} files.
I think, that it is a bug and partition conflicts should be always printed into
logs or such text files.
was (Author: shishkovilja):
[~nizhikov], there are some updates:
It seems, that results are printed into {{idle_verify*.txt}} files only in case
of exceptions during check, eg. when some nodes leaves a cluster or cluster is
not idle. So, even if partition conflicts present on the cluster, they will not
be printed to logs or {{idle_verify*.txt}} files.
> IdleVerify: print partition conflicts into control-utility.log
> --
>
> Key: IGNITE-17384
> URL: https://issues.apache.org/jira/browse/IGNITE-17384
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
>
> Currently, when you call {{control.sh --cache idle_verify}}, partition
> conflicts will be printed into standard output, but they are missing in the
> control-utility.log. So, if you have many conflicts, you should additionally
> redirect output to a file in order to send information for a further analysis.
> It would be more convenient to print partition conflicts in the
> control-utility.log file too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (IGNITE-17384) IdleVerify: print partition conflicts into control-utility.log
[
https://issues.apache.org/jira/browse/IGNITE-17384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov reopened IGNITE-17384:
[~nizhikov], there are some updates:
It seems, that results are printed into {{idle_verify*.txt}} files only in case
of exceptions during check, eg. when some nodes leaves a cluster or cluster is
not idle. So, even if partition conflicts present on the cluster, they will not
be printed to logs or {{idle_verify*.txt}} files.
> IdleVerify: print partition conflicts into control-utility.log
> --
>
> Key: IGNITE-17384
> URL: https://issues.apache.org/jira/browse/IGNITE-17384
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
>
> Currently, when you call {{control.sh --cache idle_verify}}, partition
> conflicts will be printed into standard output, but they are missing in the
> control-utility.log. So, if you have many conflicts, you should additionally
> redirect output to a file in order to send information for a further analysis.
> It would be more convenient to print partition conflicts in the
> control-utility.log file too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18049) Cursor#close() should not declare any exceptions in throws clause
Roman Puchkovskiy created IGNITE-18049:
--
Summary: Cursor#close() should not declare any exceptions in
throws clause
Key: IGNITE-18049
URL: https://issues.apache.org/jira/browse/IGNITE-18049
Project: Ignite
Issue Type: Improvement
Reporter: Roman Puchkovskiy
Assignee: Roman Puchkovskiy
Fix For: 3.0.0-beta2
When an {{AutoCloseable}} subinterface/implementation declares {{throws
Exception}} in its {{close()}} method, it makes it very inconvenient to work
with such a type using try-with-resources because the using code must use
something like {{catch (Exception e)}} which makes it difficult to process
exceptions that might arise in the {{try}} block.
The suggestion is to make {{Cursor#close()}} not declare any checked
exceptions. Most of the current implementations of {{Cursor}} already obey to
this restriction, and a few that don't can be easily reworked to obey.
The only problem is adapters (when we adapt an {{Iterator}} producing a
{{{}Cursor{}}}). Here, we must be prepared to get an {{Iterator}} that is a
resource itself (is an {{{}AutoCloseable{}}}) and hence needs to be closed when
the cursor is closed. But {{AutoCloseable#close()}} might throw a checked
exception. It is unacceptable to swallow it, and it is not too good to just
automatically wrap it in an unchecked exception.
# The best thing is that developers (who know their resources) write their own
custom {{Cursor}} implementations handling the closure.
# We also need a way to adapt 'safe close' iterators (obtained from in-memory
collections, for example). We should add a method like
{{Cursor#fromPurIterator(Iterator)}} that will check (at the moment of
invocation that the provided iterator is NOT an AutoCloseable and will throw if
it is)
# We can also provide a generic way to adapt a closeable iterator with a
method like {{ & AutoCloseable>
Cursor#fromCloseableIterator(IT iterator)}} adding a Javadoc urging the user to
use this method only when absolutely necessary
# We probably should not add an omnivorous method that could adapt both pure
and closeable iterators for now to prevent abuses.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18027) Implementation of a full rebalance without loss of user data for RocksDbMvPartitionStorageon on receiver
[ https://issues.apache.org/jira/browse/IGNITE-18027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko reassigned IGNITE-18027: Assignee: Kirill Tkalenko > Implementation of a full rebalance without loss of user data for > RocksDbMvPartitionStorageon on receiver > > > Key: IGNITE-18027 > URL: https://issues.apache.org/jira/browse/IGNITE-18027 > Project: Ignite > Issue Type: Task >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > We need to implement a full rebalance without losing user data for > *RocksDbMvPartitionStorage* and *RocksDbTableStorage* on the recipient, do > not forget about the tests. > The main idea is described in IGNITE-17990. > API should be in ticket IGNITE-18021. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-13350) Migrate ZookeeperDiscoveryStatistics to new metrics framework
[ https://issues.apache.org/jira/browse/IGNITE-13350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov resolved IGNITE-13350. -- Resolution: Fixed > Migrate ZookeeperDiscoveryStatistics to new metrics framework > - > > Key: IGNITE-13350 > URL: https://issues.apache.org/jira/browse/IGNITE-13350 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > > ZookeeperDiscoveryStatistics should be migrated to the new metrics framework. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17775) Invalid data in network buffers causes message deserialization errors and messages loss
[
https://issues.apache.org/jira/browse/IGNITE-17775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy reassigned IGNITE-17775:
--
Assignee: Roman Puchkovskiy
> Invalid data in network buffers causes message deserialization errors and
> messages loss
> ---
>
> Key: IGNITE-17775
> URL: https://issues.apache.org/jira/browse/IGNITE-17775
> Project: Ignite
> Issue Type: Bug
> Components: networking
>Reporter: Denis Chudov
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
>
> h3. TL;DR
> Message serialization registry behavior is inconsistent, it either throws an
> AssertionError or NetworkConfigurationException if factory is not found.
> There should be only one. This will simplify debugging situations where one
> forgot to register a factory in the registry, as it's the case in the problem
> below. There's no actual bug in messaging and mentioned exception is
> impossible to get in normal circumstances.
> h3. Original description
> In some tests I observe network messages' deserialization errors and timeout
> exceptions while waiting for response. In some cases there is negative group
> type of the message, and this causes error:
> {code:java}
> java.lang.AssertionError: message type must not be negative, messageType=-5376
> at
> org.apache.ignite.network.MessageSerializationRegistryImpl.getFactory(MessageSerializationRegistryImpl.java:77)
> at
> org.apache.ignite.network.MessageSerializationRegistryImpl.createDeserializer(MessageSerializationRegistryImpl.java:102)
> at
> org.apache.ignite.internal.network.serialization.SerializationService.createDeserializer(SerializationService.java:68)
> at
> org.apache.ignite.internal.network.serialization.PerSessionSerializationService.createMessageDeserializer(PerSessionSerializationService.java:109)
> at
> org.apache.ignite.internal.network.netty.InboundDecoder.decode(InboundDecoder.java:89)
> at
> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:507)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:446)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:833)
> {code}
> When the group or message type is positive but not existing, there should be
> a NetworkConfigurationException but it's not displayed in logs, however, it
> causes TimeoutExceptions because of messages loss.
> This reproduces in
> [https://github.com/gridgain/apache-ignite-3/tree/ignite-17523-2] in
> ItTablesApiTest#testGetTableFromLaggedNode
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18048) Breack down issues for lock managment
[ https://issues.apache.org/jira/browse/IGNITE-18048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-18048: --- Description: Estimate and add a description in detail for all tickets from the epic. (was: Estimate and add a description in detail for all ticket for the epic.) > Breack down issues for lock managment > - > > Key: IGNITE-18048 > URL: https://issues.apache.org/jira/browse/IGNITE-18048 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > Estimate and add a description in detail for all tickets from the epic. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (IGNITE-18010) Migrate control.sh to IgniteLogger
[ https://issues.apache.org/jira/browse/IGNITE-18010 ] Nikolay Izhikov deleted comment on IGNITE-18010: -- was (Author: nizhikov): Failures unrelated. > Migrate control.sh to IgniteLogger > -- > > Key: IGNITE-18010 > URL: https://issues.apache.org/jira/browse/IGNITE-18010 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-81 > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > > Right now control.sh utility uses own logging mechanism built on > java.util.logging while other parts of Ignite uses IgniteLogger facade. > It will be more convenient and consistent to use IgniteLogger in control.sh > code too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18048) Breack down issues for lock managment
[ https://issues.apache.org/jira/browse/IGNITE-18048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-18048: --- Description: Estimate and add a description in detail for all ticket for the epic. > Breack down issues for lock managment > - > > Key: IGNITE-18048 > URL: https://issues.apache.org/jira/browse/IGNITE-18048 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > Estimate and add a description in detail for all ticket for the epic. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (IGNITE-18010) Migrate control.sh to IgniteLogger
[ https://issues.apache.org/jira/browse/IGNITE-18010 ]
Nikolay Izhikov deleted comment on IGNITE-18010:
--
was (Author: ignitetcbot):
{panel:title=Branch: [pull/10354/head] Base: [master] : Possible Blockers
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 2{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6882854]]
* IgniteCacheTestSuite2: IgniteCachePartitionMapUpdateTest.testRandom - Test
has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}PDS 4{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6882910]]
* IgnitePdsTestSuite4:
ResetLostPartitionTest.testReactivateGridBeforeResetLostPartitions - Test has
low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache 6{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6882858]]
* IgniteCacheTestSuite6: CacheExchangeMergeTest.testMergeAndHistoryCleanup -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Queries 1{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6882923]]
* IgniteBinaryCacheQueryTestSuite:
DynamicIndexServerCoordinatorBasicSelfTest.testCreateReplicatedAtomic - Test
has low fail rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/10354/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=6879191buildTypeId=IgniteTests24Java8_RunAll]
> Migrate control.sh to IgniteLogger
> --
>
> Key: IGNITE-18010
> URL: https://issues.apache.org/jira/browse/IGNITE-18010
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-81
> Fix For: 2.15
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Right now control.sh utility uses own logging mechanism built on
> java.util.logging while other parts of Ignite uses IgniteLogger facade.
> It will be more convenient and consistent to use IgniteLogger in control.sh
> code too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18010) Migrate control.sh to IgniteLogger
[
https://issues.apache.org/jira/browse/IGNITE-18010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627185#comment-17627185
]
Ignite TC Bot commented on IGNITE-18010:
{panel:title=Branch: [pull/10354/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10354/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=6879191buildTypeId=IgniteTests24Java8_RunAll]
> Migrate control.sh to IgniteLogger
> --
>
> Key: IGNITE-18010
> URL: https://issues.apache.org/jira/browse/IGNITE-18010
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-81
> Fix For: 2.15
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Right now control.sh utility uses own logging mechanism built on
> java.util.logging while other parts of Ignite uses IgniteLogger facade.
> It will be more convenient and consistent to use IgniteLogger in control.sh
> code too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17741) idle_verify must provide explicit data and version hashes
[ https://issues.apache.org/jira/browse/IGNITE-17741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov reassigned IGNITE-17741: Assignee: Nikolay Izhikov > idle_verify must provide explicit data and version hashes > - > > Key: IGNITE-17741 > URL: https://issues.apache.org/jira/browse/IGNITE-17741 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Nikolay Izhikov >Priority: Major > Labels: iep-31, ise > > Currently we have a single hash. > Separated hashes will provide more information. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18048) Breack down issues for lock managment
Vladislav Pyatkov created IGNITE-18048: -- Summary: Breack down issues for lock managment Key: IGNITE-18048 URL: https://issues.apache.org/jira/browse/IGNITE-18048 Project: Ignite Issue Type: Improvement Reporter: Vladislav Pyatkov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18042) Rework lock management mechanism
[ https://issues.apache.org/jira/browse/IGNITE-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-18042: -- Epic Name: Lock model adjustments (was: Lock management) > Rework lock management mechanism > > > Key: IGNITE-18042 > URL: https://issues.apache.org/jira/browse/IGNITE-18042 > Project: Ignite > Issue Type: Epic >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > Today lock management is represented by interface LockManager (implementation > into HeapLockManager). This approach has known issue (lock is not being taken > on row id, not possible to replace a mechanism of deadlock prevention and > some particular scenarios). > This epic covers some activity which is connected with work that makes the > management correctness. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17384) IdleVerify: print partition conflicts into control-utility.log
[
https://issues.apache.org/jira/browse/IGNITE-17384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627175#comment-17627175
]
Nikolay Izhikov commented on IGNITE-17384:
--
Right not idle_verify logs written to
{{$IGNITE_WORK/idle_verify-${current-time}.txt}} file.
IGNITE-18010 changes this a bit and logs will land into {{$IGNITE_WORK/log}}
directory.
> IdleVerify: print partition conflicts into control-utility.log
> --
>
> Key: IGNITE-17384
> URL: https://issues.apache.org/jira/browse/IGNITE-17384
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: ise
>
> Currently, when you call {{control.sh --cache idle_verify}}, partition
> conflicts will be printed into standard output, but they are missing in the
> control-utility.log. So, if you have many conflicts, you should additionally
> redirect output to a file in order to send information for a further analysis.
> It would be more convenient to print partition conflicts in the
> control-utility.log file too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17384) IdleVerify: print partition conflicts into control-utility.log
[
https://issues.apache.org/jira/browse/IGNITE-17384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-17384:
-
Fix Version/s: 2.15
> IdleVerify: print partition conflicts into control-utility.log
> --
>
> Key: IGNITE-17384
> URL: https://issues.apache.org/jira/browse/IGNITE-17384
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
>
> Currently, when you call {{control.sh --cache idle_verify}}, partition
> conflicts will be printed into standard output, but they are missing in the
> control-utility.log. So, if you have many conflicts, you should additionally
> redirect output to a file in order to send information for a further analysis.
> It would be more convenient to print partition conflicts in the
> control-utility.log file too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18010) Migrate control.sh to IgniteLogger
[ https://issues.apache.org/jira/browse/IGNITE-18010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627171#comment-17627171 ] Nikolay Izhikov commented on IGNITE-18010: -- Failures unrelated. > Migrate control.sh to IgniteLogger > -- > > Key: IGNITE-18010 > URL: https://issues.apache.org/jira/browse/IGNITE-18010 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-81 > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > > Right now control.sh utility uses own logging mechanism built on > java.util.logging while other parts of Ignite uses IgniteLogger facade. > It will be more convenient and consistent to use IgniteLogger in control.sh > code too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-17384) IdleVerify: print partition conflicts into control-utility.log
[
https://issues.apache.org/jira/browse/IGNITE-17384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov resolved IGNITE-17384.
--
Resolution: Fixed
> IdleVerify: print partition conflicts into control-utility.log
> --
>
> Key: IGNITE-17384
> URL: https://issues.apache.org/jira/browse/IGNITE-17384
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: ise
>
> Currently, when you call {{control.sh --cache idle_verify}}, partition
> conflicts will be printed into standard output, but they are missing in the
> control-utility.log. So, if you have many conflicts, you should additionally
> redirect output to a file in order to send information for a further analysis.
> It would be more convenient to print partition conflicts in the
> control-utility.log file too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18010) Migrate control.sh to IgniteLogger
[
https://issues.apache.org/jira/browse/IGNITE-18010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627170#comment-17627170
]
Ignite TC Bot commented on IGNITE-18010:
{panel:title=Branch: [pull/10354/head] Base: [master] : Possible Blockers
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 2{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6882854]]
* IgniteCacheTestSuite2: IgniteCachePartitionMapUpdateTest.testRandom - Test
has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}PDS 4{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6882910]]
* IgnitePdsTestSuite4:
ResetLostPartitionTest.testReactivateGridBeforeResetLostPartitions - Test has
low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache 6{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6882858]]
* IgniteCacheTestSuite6: CacheExchangeMergeTest.testMergeAndHistoryCleanup -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Queries 1{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6882923]]
* IgniteBinaryCacheQueryTestSuite:
DynamicIndexServerCoordinatorBasicSelfTest.testCreateReplicatedAtomic - Test
has low fail rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/10354/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=6879191buildTypeId=IgniteTests24Java8_RunAll]
> Migrate control.sh to IgniteLogger
> --
>
> Key: IGNITE-18010
> URL: https://issues.apache.org/jira/browse/IGNITE-18010
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-81
> Fix For: 2.15
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Right now control.sh utility uses own logging mechanism built on
> java.util.logging while other parts of Ignite uses IgniteLogger facade.
> It will be more convenient and consistent to use IgniteLogger in control.sh
> code too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18010) Migrate control.sh to IgniteLogger
[ https://issues.apache.org/jira/browse/IGNITE-18010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-18010: - Fix Version/s: 2.15 > Migrate control.sh to IgniteLogger > -- > > Key: IGNITE-18010 > URL: https://issues.apache.org/jira/browse/IGNITE-18010 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-81 > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > > Right now control.sh utility uses own logging mechanism built on > java.util.logging while other parts of Ignite uses IgniteLogger facade. > It will be more convenient and consistent to use IgniteLogger in control.sh > code too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17976) Throw correct exception on KeyValueView#get in case of lost majority
[
https://issues.apache.org/jira/browse/IGNITE-17976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev reassigned IGNITE-17976:
Assignee: (was: Mirza Aliev)
> Throw correct exception on KeyValueView#get in case of lost majority
>
>
> Key: IGNITE-17976
> URL: https://issues.apache.org/jira/browse/IGNITE-17976
> Project: Ignite
> Issue Type: Task
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> *Scenario*:
> Start two nodes, populate data, stop node, try to
> {{table.keyValueView().get}} value, that is not presented in the table.
> *Expected behaviour*:
> Exception is thrown (we need to agree on the right exception)
> *Actual behaviour*:
> We can caught {{ReplicationTimeoutException}}, {{TransactionException}},
> {{IgniteException}}. Sometimes we fail with {{NullPointerException}}, the
> reason is because we can stop leader of some partition, and for two nodes it
> is impossible to elect new leader, so we get null in
> {{InternalTableImpl#enlist}} when we try to get
> {{{svc.refreshAndGetLeaderWithTerm();}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17989) JVM memory usage metric source
[ https://issues.apache.org/jira/browse/IGNITE-17989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17989: - Reviewer: Vyacheslav Koptilin > JVM memory usage metric source > -- > > Key: IGNITE-17989 > URL: https://issues.apache.org/jira/browse/IGNITE-17989 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > > h3. Motivation > It will be useful to have builtin metric source with jvm memory usage stats. > h3. Definition of Done > It must expose the following metrics as a separate gauge metric each: > * heap memory usage (init/used/commited/max) > * non-heap memory usage (init/used/commited/max) > * name of metrics should have the general prefix "jvm." to group all future > jvm metrics together > Also, it needs to check, if calculation of these stats is heavy and we need > to cache it for some time windows. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17989) JVM memory usage metric source
[ https://issues.apache.org/jira/browse/IGNITE-17989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17989: - Fix Version/s: 3.0.0-beta2 > JVM memory usage metric source > -- > > Key: IGNITE-17989 > URL: https://issues.apache.org/jira/browse/IGNITE-17989 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > h3. Motivation > It will be useful to have builtin metric source with jvm memory usage stats. > h3. Definition of Done > It must expose the following metrics as a separate gauge metric each: > * heap memory usage (init/used/commited/max) > * non-heap memory usage (init/used/commited/max) > * name of metrics should have the general prefix "jvm." to group all future > jvm metrics together > Also, it needs to check, if calculation of these stats is heavy and we need > to cache it for some time windows. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18047) High failure rate of test suite 'Cache 2' suite on TC1
[ https://issues.apache.org/jira/browse/IGNITE-18047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov updated IGNITE-18047: --- Labels: ise teamcity (was: ise) > High failure rate of test suite 'Cache 2' suite on TC1 > -- > > Key: IGNITE-18047 > URL: https://issues.apache.org/jira/browse/IGNITE-18047 > Project: Ignite > Issue Type: Task >Reporter: Ilya Shishkov >Priority: Major > Labels: ise, teamcity > > Failure rate is abot 30% on master branch. Most of time test suite fails by > timeout [1], sometimes with an error: "Out of memory: GC overhead limit > exceeded" [2]. But, on TC2 there are only a few failures [3] of the suite. > # > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache2?branch=%3Cdefault%3E=builds > # > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache2/6821056 > # > https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache2?branch=%3Cdefault%3E=builds -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18047) High failure rate of test suite 'Cache 2' suite on TC1
[ https://issues.apache.org/jira/browse/IGNITE-18047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov updated IGNITE-18047: --- Summary: High failure rate of test suite 'Cache 2' suite on TC1 (was: High failure rate of test suite 'Cache2' suite on TC1) > High failure rate of test suite 'Cache 2' suite on TC1 > -- > > Key: IGNITE-18047 > URL: https://issues.apache.org/jira/browse/IGNITE-18047 > Project: Ignite > Issue Type: Task >Reporter: Ilya Shishkov >Priority: Major > Labels: ise > > Failure rate is abot 30% on master branch. Most of time test suite fails by > timeout [1], sometimes with an error: "Out of memory: GC overhead limit > exceeded" [2]. But, on TC2 there are only a few failures [3] of the suite. > # > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache2?branch=%3Cdefault%3E=builds > # > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache2/6821056 > # > https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache2?branch=%3Cdefault%3E=builds -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18047) High failure rate of test suite 'Cache2' suite on TC1
[ https://issues.apache.org/jira/browse/IGNITE-18047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov updated IGNITE-18047: --- Description: Failure rate is abot 30% on master branch. Most of time test suite fails by timeout [1], sometimes with an error: "Out of memory: GC overhead limit exceeded" [2]. But, on TC2 there are only a few failures [3] of the suite. # https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache2?branch=%3Cdefault%3E=builds # https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache2/6821056 # https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache2?branch=%3Cdefault%3E=builds was: Failure rate is abot 30% on master branch. Most of time test suite fails by timeout [1], sometimes by error: "Out of memory: GC overhead limit exceeded" [2]. But, on TC2 there are only a few failures [3] of the suite. # https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache2?branch=%3Cdefault%3E=builds # https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache2/6821056 # https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache2?branch=%3Cdefault%3E=builds > High failure rate of test suite 'Cache2' suite on TC1 > - > > Key: IGNITE-18047 > URL: https://issues.apache.org/jira/browse/IGNITE-18047 > Project: Ignite > Issue Type: Task >Reporter: Ilya Shishkov >Priority: Major > Labels: ise > > Failure rate is abot 30% on master branch. Most of time test suite fails by > timeout [1], sometimes with an error: "Out of memory: GC overhead limit > exceeded" [2]. But, on TC2 there are only a few failures [3] of the suite. > # > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache2?branch=%3Cdefault%3E=builds > # > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache2/6821056 > # > https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache2?branch=%3Cdefault%3E=builds -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18047) High failure rate of test suite 'Cache2' suite on TC1
Ilya Shishkov created IGNITE-18047: -- Summary: High failure rate of test suite 'Cache2' suite on TC1 Key: IGNITE-18047 URL: https://issues.apache.org/jira/browse/IGNITE-18047 Project: Ignite Issue Type: Task Reporter: Ilya Shishkov Failure rate is abot 30% on master branch. Most of time test suite fails by timeout [1], sometimes by error: "Out of memory: GC overhead limit exceeded" [2]. But, on TC2 there are only a few failures [3] of the suite. # https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache2?branch=%3Cdefault%3E=builds # https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache2/6821056 # https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache2?branch=%3Cdefault%3E=builds -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18045) Short term locks support
[ https://issues.apache.org/jira/browse/IGNITE-18045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-18045: --- Description: [Transaction IEP|https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol#IEP91:Transactionprotocol-Uniqueindex] contains an operation that need a short term locks (look at insert operation for sorted index), but this type of lock lies on present implementation badly. Today, if a transaction releases a lock that has been got to twice (maybe different types, but in one key) the lock is released at all. Adding counters by lock types is solved the issue, but possible it is not required to solve the problem, because we can change operation in order of the short term locks will be not needed. was: [Transaction IEP|https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol#IEP91:Transactionprotocol-Uniqueindex] contains an operation that need a short term locks, but this type of lock lies on present implementation badly. Today, if a transaction releases a lock that has been got to twice (maybe different types, but in one key) the lock is released at all. Adding counters by lock types is solved the issue, but possible it is not required to solve the problem, because we can change operation in order of the short term locks will be not needed. > Short term locks support > > > Key: IGNITE-18045 > URL: https://issues.apache.org/jira/browse/IGNITE-18045 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > [Transaction > IEP|https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol#IEP91:Transactionprotocol-Uniqueindex] > contains an operation that need a short term locks (look at insert operation > for sorted index), but this type of lock lies on present implementation > badly. Today, if a transaction releases a lock that has been got to twice > (maybe different types, but in one key) the lock is released at all. > Adding counters by lock types is solved the issue, but possible it is not > required to solve the problem, because we can change operation in order of > the short term locks will be not needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18046) .NET: Thin 3.0: Get and verify cluster id on connection
[ https://issues.apache.org/jira/browse/IGNITE-18046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18046: Description: Client needs to get and verify cluster ID on handshake as described in [IEP-90|https://cwiki.apache.org/confluence/display/IGNITE/IEP-90+Client+Lifecycle] to make sure all servers it connects to are from the same cluster. This is especially important during connection restoration. > .NET: Thin 3.0: Get and verify cluster id on connection > --- > > Key: IGNITE-18046 > URL: https://issues.apache.org/jira/browse/IGNITE-18046 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-90, ignite-3 > Fix For: 3.0.0-beta2 > > > Client needs to get and verify cluster ID on handshake as described in > [IEP-90|https://cwiki.apache.org/confluence/display/IGNITE/IEP-90+Client+Lifecycle] > to make sure all servers it connects to are from the same cluster. This is > especially important during connection restoration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18046) .NET: Thin 3.0: Get and verify cluster id on connection
Pavel Tupitsyn created IGNITE-18046: --- Summary: .NET: Thin 3.0: Get and verify cluster id on connection Key: IGNITE-18046 URL: https://issues.apache.org/jira/browse/IGNITE-18046 Project: Ignite Issue Type: Improvement Components: platforms, thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18045) Short term locks support
[ https://issues.apache.org/jira/browse/IGNITE-18045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-18045: --- Description: [Transaction IEP|https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol#IEP91:Transactionprotocol-Uniqueindex] contains an operation that need a short term locks, but this type of lock lies on present implementation badly. Today, if a transaction releases a lock that has been got to twice (maybe different types, but in one key) the lock is released at all. Adding counters by lock types is solved the issue, but possible it is not required to solve the problem, because we can change operation in order of the short term locks will be not needed. was: Transaction IEP contains an operation that need a short term locks, but this type of lock lies on present implementation badly. Today, if a transaction releases a lock that has been got to twice (maybe different types, but in one key) the lock is released at all. Adding counters by lock types is solved the issue, but possible it is not required to solve the problem, because we can change operation in order of the short term locks will be not needed. > Short term locks support > > > Key: IGNITE-18045 > URL: https://issues.apache.org/jira/browse/IGNITE-18045 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > [Transaction > IEP|https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol#IEP91:Transactionprotocol-Uniqueindex] > contains an operation that need a short term locks, but this type of lock > lies on present implementation badly. Today, if a transaction releases a lock > that has been got to twice (maybe different types, but in one key) the lock > is released at all. > Adding counters by lock types is solved the issue, but possible it is not > required to solve the problem, because we can change operation in order of > the short term locks will be not needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18045) Short term locks support
Vladislav Pyatkov created IGNITE-18045: -- Summary: Short term locks support Key: IGNITE-18045 URL: https://issues.apache.org/jira/browse/IGNITE-18045 Project: Ignite Issue Type: Improvement Reporter: Vladislav Pyatkov Transaction IEP contains an operation that need a short term locks, but this type of lock lies on present implementation badly. Today, if a transaction releases a lock that has been got to twice (maybe different types, but in one key) the lock is released at all. Adding counters by lock types is solved the issue, but possible it is not required to solve the problem, because we can change operation in order of the short term locks will be not needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18044) ItIgniteNodeRestartTest#testTwoNodesRestartDirect is failed after schema recovery fix.
Evgeny Stanilovsky created IGNITE-18044:
---
Summary: ItIgniteNodeRestartTest#testTwoNodesRestartDirect is
failed after schema recovery fix.
Key: IGNITE-18044
URL: https://issues.apache.org/jira/browse/IGNITE-18044
Project: Ignite
Issue Type: Bug
Reporter: Evgeny Stanilovsky
In [1] was introduced schema recovery fix, after the fix test [2] is failing
with :
{noformat}
Caused by: java.lang.AssertionError: Mismatched transaction id,
expectedTxId={000d780b-10c0--face-5ad039564953},
actualTxId={000d780a-a0fd--face-5ad039564953}
{noformat}
[1] https://issues.apache.org/jira/browse/IGNITE-17986
[2] ItIgniteNodeRestartTest#testTwoNodesRestartDirect
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18043) Replaceable deadlock prevention mechanism
[ https://issues.apache.org/jira/browse/IGNITE-18043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-18043: --- Description: We have an embedded deadlock prevention strategy (presently, it is _Wait-Die_). Although, [the original paper|https://people.eecs.berkeley.edu/~brewer/cs262/concurrency-distributed-databases.pdf] about deadlock prevention contains another two strategies: _priorities_ and _Wound-Wait_. Also, the mechanism should give a possibility to not use any strategy to prevent deadlock. All told, above shows we need to separate the prevention strategy in dedicate interface (which even has one implementation _Wait-Die_). Another implementation will be released by necessary. was: We have an embedded deadlock prevention strategy (presently, it is _Wait-Die_). Although, [the original paper|https://people.eecs.berkeley.edu/~brewer/cs262/concurrency-distributed-databases.pdf] about deadlock prevention contains another two strategies: _priorities_ and _Wound-Wait_. Also, the mechanism should give a possibility to not use any strategy to prevent deadlock. All told, above shows we need to separate the prevention strategy in dedicate interface (which even has one implementation _Wait-Die_). Another implementation will be released by necessary. > Replaceable deadlock prevention mechanism > - > > Key: IGNITE-18043 > URL: https://issues.apache.org/jira/browse/IGNITE-18043 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > We have an embedded deadlock prevention strategy (presently, it is > _Wait-Die_). Although, [the original > paper|https://people.eecs.berkeley.edu/~brewer/cs262/concurrency-distributed-databases.pdf] > about deadlock prevention contains another two strategies: _priorities_ and > _Wound-Wait_. Also, the mechanism should give a possibility to not use any > strategy to prevent deadlock. > All told, above shows we need to separate the prevention strategy in dedicate > interface (which even has one implementation _Wait-Die_). Another > implementation will be released by necessary. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18043) Replaceable deadlock prevention mechanism
Vladislav Pyatkov created IGNITE-18043: -- Summary: Replaceable deadlock prevention mechanism Key: IGNITE-18043 URL: https://issues.apache.org/jira/browse/IGNITE-18043 Project: Ignite Issue Type: Improvement Reporter: Vladislav Pyatkov We have an embedded deadlock prevention strategy (presently, it is _Wait-Die_). Although, [the original paper|https://people.eecs.berkeley.edu/~brewer/cs262/concurrency-distributed-databases.pdf] about deadlock prevention contains another two strategies: _priorities_ and _Wound-Wait_. Also, the mechanism should give a possibility to not use any strategy to prevent deadlock. All told, above shows we need to separate the prevention strategy in dedicate interface (which even has one implementation _Wait-Die_). Another implementation will be released by necessary. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
https://issues.apache.org/jira/browse/IGNITE-15322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-15322:
--
Description:
For example, this code needs TASK_EXECUTE permissions.
{code:java}
Affinity affinity = ignite.affinity("TEST");
affinity.mapKeysToNodes(Arrays.asList(1L,100L, 1000L));{code}
This is unexpected behavior, because:
- the task started implicitly (under the hood), customer should not to know
about it.
- this is a system task (not defined by a customer), the tasks needs for a
normal grid workflow.
Also, I suppose there are any other implicitly tasks, which could lead to
unexpected behavior (need permissions).
Possible way to solve this issue:
1. Add mechanism to destinguish whether task class is SYSTEM (part of the
Ignite codebase) or USER. Here we can reuse SecurityUtils#isSystemType.
2. Add mechanism to detect if task execution was initiated by the user (PUBLIC
CALL) or by the Ignite system itself (INTERNAL CALL).
3. Add ability to explicitly specify for SYSTEM task/callable/runnable/closure
what permission should be checked before its execution.
4. Skip permission check for the tasks that are SYSTEM and initiated by the
Ignite internal code unless permissions are specified explicitly.
5. Restrict execution of SYSTEM tasks initiated by the user directly and for
which no explicit permissions are specified.
Possible troubles:
1. We have control.sh tasks that are executed via the thin client. Task
execution through the thin client compute is considered as PUBLIC CALL so we
should assign some permission to each control.sh task.
To skip creation of a separate permissions for each control.sh task it is
proposed to group tasks that belongs to the same control.sh command e.g.
control.sh --cache ... tasks will require ADMIN_CACHE permission
control.sh --tx ... tasks will require ADMIN_TX permission
2. Mentioned SecurityUtils#isSystemType works only for the ignite-core module.
If some tasks are defined inside other Ignite modules - they will not be
considered SYSTEM. Currently there are no such task.
was:
For example, this code needs TASK_EXECUTE permissions.
{code:java}
Affinity affinity = ignite.affinity("TEST");
affinity.mapKeysToNodes(Arrays.asList(1L,100L, 1000L));{code}
This is unexpected behavior, because:
- the task started implicitly (under the hood), customer should not to know
about it.
- this is a system task (not defined by a customer), the tasks needs for a
normal grid workflow.
Also, I suppose there are any other implicitly tasks, which could lead to
unexpected behavior (need permissions).
Possible lan to solve this issue:
1. Add mechanism to destinguish whether task class is SYSTEM (part of the
Ignite codebase) or USER. Here we can reuse SecurityUtils#isSystemType.
2. Add mechanism to detect if task execution was initiated by the user (PUBLIC
CALL) or by the Ignite system itself (INTERNAL CALL).
3. Add ability to explicitly specify for SYSTEM task/callable/runnable/closure
what permission should be checked before its execution.
4. Skip permission check for the tasks that are SYSTEM and initiated by the
Ignite internal code unless permissions are specified explicitly.
5. Restrict execution of SYSTEM tasks initiated by the user directly and for
which no explicit permissions are specified.
Possible troubles:
1. We have control.sh tasks that are executed via the thin client. Task
execution through the thin client compute is considered as PUBLIC CALL so we
should assign some permission to each control.sh task.
To skip creation of a separate permissions for each control.sh task it is
proposed to group tasks that belongs to the same control.sh command e.g.
control.sh --cache ... tasks will require ADMIN_CACHE permission
control.sh --tx ... tasks will require ADMIN_TX permission
2. Mentioned SecurityUtils#isSystemType works only for the ignite-core module.
If some tasks are defined inside other Ignite modules - they will not be
considered SYSTEM. Currently there are no such task.
> System tasks should run without any explicitly granted permissions
> --
>
> Key: IGNITE-15322
> URL: https://issues.apache.org/jira/browse/IGNITE-15322
> Project: Ignite
> Issue Type: Bug
> Components: compute, security
>Reporter: Ilya Kazakov
>Assignee: Mikhail Petrov
>Priority: Minor
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For example, this code needs TASK_EXECUTE permissions.
> {code:java}
> Affinity affinity = ignite.affinity("TEST");
> affinity.mapKeysToNodes(Arrays.asList(1L,100L, 1000L));{code}
> This is unexpected behavior, because:
> - the task started implicitly (under the hood), customer should not to know
> about it.
> - this is a system task (not
[jira] [Updated] (IGNITE-18039) Switch our build system to gradle
[ https://issues.apache.org/jira/browse/IGNITE-18039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-18039: - Labels: ignite-3 (was: ) > Switch our build system to gradle > - > > Key: IGNITE-18039 > URL: https://issues.apache.org/jira/browse/IGNITE-18039 > Project: Ignite > Issue Type: Epic > Components: build >Reporter: Yury Yudin >Priority: Major > Labels: ignite-3 > > As proposed and agreed as part of IEP-93 ignite3 build system is being > switched to gradle. > This epic is a collection of all tickets that need to be completed to make > the switch to gradle as smooth as possible both in terms of building the > artefacts as well as day-to-day development.The last item in this epic would > be the removal of the original maven build. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18034) Address CVE-2022-39135 by upgrading calcite-core to 1.32.0
[ https://issues.apache.org/jira/browse/IGNITE-18034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-18034: - Component/s: (was: ignite-3) > Address CVE-2022-39135 by upgrading calcite-core to 1.32.0 > -- > > Key: IGNITE-18034 > URL: https://issues.apache.org/jira/browse/IGNITE-18034 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.14 >Reporter: Sander >Priority: Major > > Hello, > We have recently upgraded to ignite version 2.14.0 to take advantage of the > new calcite SQL engine. However there is a critical vulnerability with the > current version of calcite-core 1.30.0. > Calcite-core version 1.30.0 has a critical vulnerability > [https://nvd.nist.gov/vuln/detail/CVE-2022-39135] > This vulnerability is resolved in calcite-core version 1.32.0. However if we > force this package in our build. There are issues running sql queries against > ignite with the error: > ``` > java.lang.AbstractMethodError: > org.apache.calcite.sql.parser.SqlAbstractParserImpl.setTimeUnitCodes(Ljava/util/Map;)V > at org.apache.calcite.sql.parser.SqlParser.(SqlParser.java:73) > ~[calcite-core-1.32.0.jar:1.32.0] > at org.apache.calcite.sql.parser.SqlParser.create(SqlParser.java:126) > ~[calcite-core-1.32.0.jar:1.32.0] > at > org.apache.ignite.internal.processors.query.calcite.util.Commons.parse(Commons.java:220) > ~[ignite-calcite-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.query.calcite.util.Commons.parse(Commons.java:204) > ~[ignite-calcite-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:345) > ~[ignite-calcite-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:3092) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:3074) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:3751) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$3(GridQueryProcessor.java:3118) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:3190) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:3070) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:3024) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.querySqlFields(JdbcRequestHandler.java:773) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:641) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.doHandle(JdbcRequestHandler.java:311) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:251) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:204) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:55) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70) > [ignite-core-2.14.0.jar:2.14.0] > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) > [na:1.8.0_301] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) >
[jira] [Updated] (IGNITE-18034) Address CVE-2022-39135 by upgrading calcite-core to 1.32.0
[ https://issues.apache.org/jira/browse/IGNITE-18034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-18034: - Labels: (was: ignite-3) > Address CVE-2022-39135 by upgrading calcite-core to 1.32.0 > -- > > Key: IGNITE-18034 > URL: https://issues.apache.org/jira/browse/IGNITE-18034 > Project: Ignite > Issue Type: Bug > Components: ignite-3 >Affects Versions: 2.14 >Reporter: Sander >Priority: Major > > Hello, > We have recently upgraded to ignite version 2.14.0 to take advantage of the > new calcite SQL engine. However there is a critical vulnerability with the > current version of calcite-core 1.30.0. > Calcite-core version 1.30.0 has a critical vulnerability > [https://nvd.nist.gov/vuln/detail/CVE-2022-39135] > This vulnerability is resolved in calcite-core version 1.32.0. However if we > force this package in our build. There are issues running sql queries against > ignite with the error: > ``` > java.lang.AbstractMethodError: > org.apache.calcite.sql.parser.SqlAbstractParserImpl.setTimeUnitCodes(Ljava/util/Map;)V > at org.apache.calcite.sql.parser.SqlParser.(SqlParser.java:73) > ~[calcite-core-1.32.0.jar:1.32.0] > at org.apache.calcite.sql.parser.SqlParser.create(SqlParser.java:126) > ~[calcite-core-1.32.0.jar:1.32.0] > at > org.apache.ignite.internal.processors.query.calcite.util.Commons.parse(Commons.java:220) > ~[ignite-calcite-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.query.calcite.util.Commons.parse(Commons.java:204) > ~[ignite-calcite-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:345) > ~[ignite-calcite-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:3092) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:3074) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:3751) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$3(GridQueryProcessor.java:3118) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:3190) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:3070) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:3024) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.querySqlFields(JdbcRequestHandler.java:773) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:641) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.doHandle(JdbcRequestHandler.java:311) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:251) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:204) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:55) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70) > [ignite-core-2.14.0.jar:2.14.0] > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) > [na:1.8.0_301] > at
[jira] [Updated] (IGNITE-18016) Fix javadocs for public IgniteTables
[ https://issues.apache.org/jira/browse/IGNITE-18016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-18016: - Labels: ignite-3 (was: ) > Fix javadocs for public IgniteTables > - > > Key: IGNITE-18016 > URL: https://issues.apache.org/jira/browse/IGNITE-18016 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta1 > > Time Spent: 10m > Remaining Estimate: 0h > > We mention using SQL schemas in javadocs at > org.apache.ignite.table.manager.IgniteTables. Due to schemas are not > supported now need to rewrite these javadocs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18034) Address CVE-2022-39135 by upgrading calcite-core to 1.32.0
[ https://issues.apache.org/jira/browse/IGNITE-18034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-18034: - Labels: ignite-3 (was: ) > Address CVE-2022-39135 by upgrading calcite-core to 1.32.0 > -- > > Key: IGNITE-18034 > URL: https://issues.apache.org/jira/browse/IGNITE-18034 > Project: Ignite > Issue Type: Bug > Components: ignite-3 >Affects Versions: 2.14 >Reporter: Sander >Priority: Major > Labels: ignite-3 > > Hello, > We have recently upgraded to ignite version 2.14.0 to take advantage of the > new calcite SQL engine. However there is a critical vulnerability with the > current version of calcite-core 1.30.0. > Calcite-core version 1.30.0 has a critical vulnerability > [https://nvd.nist.gov/vuln/detail/CVE-2022-39135] > This vulnerability is resolved in calcite-core version 1.32.0. However if we > force this package in our build. There are issues running sql queries against > ignite with the error: > ``` > java.lang.AbstractMethodError: > org.apache.calcite.sql.parser.SqlAbstractParserImpl.setTimeUnitCodes(Ljava/util/Map;)V > at org.apache.calcite.sql.parser.SqlParser.(SqlParser.java:73) > ~[calcite-core-1.32.0.jar:1.32.0] > at org.apache.calcite.sql.parser.SqlParser.create(SqlParser.java:126) > ~[calcite-core-1.32.0.jar:1.32.0] > at > org.apache.ignite.internal.processors.query.calcite.util.Commons.parse(Commons.java:220) > ~[ignite-calcite-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.query.calcite.util.Commons.parse(Commons.java:204) > ~[ignite-calcite-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:345) > ~[ignite-calcite-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:3092) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:3074) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:3751) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$3(GridQueryProcessor.java:3118) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:3190) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:3070) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:3024) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.querySqlFields(JdbcRequestHandler.java:773) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:641) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.doHandle(JdbcRequestHandler.java:311) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:251) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:204) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:55) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125) > ~[ignite-core-2.14.0.jar:2.14.0] > at > org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70) > [ignite-core-2.14.0.jar:2.14.0] > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) > [na:1.8.0_301] > at
[jira] [Updated] (IGNITE-18005) ItDataTypesTest#testUnicodeStrings fails with IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/IGNITE-18005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-18005:
-
Labels: ignite-3 (was: )
> ItDataTypesTest#testUnicodeStrings fails with IndexOutOfBoundsException
> ---
>
> Key: IGNITE-18005
> URL: https://issues.apache.org/jira/browse/IGNITE-18005
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:java}
> Caused by: java.lang.IndexOutOfBoundsException: 4
> at java.base/java.nio.HeapByteBuffer.get(HeapByteBuffer.java:166)
> at org.apache.ignite.internal.schema.row.Row.findColumn(Row.java:516)
> at org.apache.ignite.internal.schema.row.Row.stringValue(Row.java:288)
> at
> org.apache.ignite.internal.schema.NativeTypeSpec$9.objectValue(NativeTypeSpec.java:134)
> at org.apache.ignite.internal.schema.row.Row.value(Row.java:122)
> at
> org.apache.ignite.internal.sql.engine.schema.IgniteTableImpl.toRow(IgniteTableImpl.java:284)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.TableScanNode.convert(TableScanNode.java:279)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.TableScanNode$SubscriberImpl.onNext(TableScanNode.java:246)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.TableScanNode$SubscriberImpl.onNext(TableScanNode.java:233)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> at
> org.apache.ignite.internal.table.distributed.storage.InternalTableImpl$PartitionScanPublisher$PartitionScanSubscription.lambda$scanBatch$2(InternalTableImpl.java:1182)
> at
> java.base/java.util.concurrent.CompletableFuture$UniAccept.tryFire(CompletableFuture.java:714)
> ... 11 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18001) Ignite node may become unavailable after some play with SQL
[
https://issues.apache.org/jira/browse/IGNITE-18001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-18001:
-
Labels: ignite-3 (was: )
> Ignite node may become unavailable after some play with SQL
> ---
>
> Key: IGNITE-18001
> URL: https://issues.apache.org/jira/browse/IGNITE-18001
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: ignite-3
> Attachments: ignite3db-0.log, ignite3db-1.log
>
>
> Steps to reproduce:
> # Start AI3 node, init cluster
> # Connect to node via Ignite3 CLI
> # Open SQL console in Ignite3 CLI
> # Play with SQL queries: create tables, invoke select queries, drop tables,
> so on. Probably, this step is not needed. Probably, it may be important to
> perform some queries with errors.
> # Wait for some time (30-60 mins) having SQL console open.
> # Try to execute new query after the pause. It {*}hangs{*}.
> In DB log, a lot of the following errors occur (some of them could occur even
> before step 6 above):
> {code}
> 2022-10-27 18:15:57:391 +0400
> [WARNING][%defaultNode%Raft-Group-Client-11][RaftGroupServiceImpl]
> Recoverable error duri
> ng the request type=ActionRequestImpl occurred (will be retried on the
> randomly selected node):
> java.util.concurrent.TimeoutException
> at
> java.base/java.util.concurrent.CompletableFuture$Timeout.run(CompletableFuture.java:2792)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecut
> or.java:304)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> 2022-10-27 18:17:21:376 +0400
> [INFO][%defaultNode%checkpoint-thread-1][Checkpoint] Skipping checkpoint (no
> pages were m
> odified) [checkpointBeforeWriteLockTime=0ms, checkpointWriteLockWait=0ms,
> checkpointListenersExecuteTime=0ms, checkpoin
> tWriteLockHoldTime=0ms, reason='timeout']
> {code}
> After attempt to restart node (`./bin/ignite3db.sh stop && ./bin/ignite3db.sh
> start`) another stacktrace occurs in log:
> {code}2022-10-27 18:24:06:489 +0400
> [INFO][ForkJoinPool.commonPool-worker-9][ClientHandlerModule] Thin client
> protocol started successfully[port=10800]
> 2022-10-27 18:24:06:490 +0400
> [INFO][ForkJoinPool.commonPool-worker-9][IgniteImpl] Components started,
> performing recovery
> 2022-10-27 18:24:06:868 +0400
> [INFO][ForkJoinPool.commonPool-worker-9][ConfigurationRegistry] Failed to
> notify configuration listener
> java.util.NoSuchElementException:
> table.tables.ee9c42e0-9b96-4164-b13b-8bec99d3171a.assignments
> at
> org.apache.ignite.internal.configuration.util.ConfigurationUtil.findEx(ConfigurationUtil.java:852)
> at
> org.apache.ignite.internal.configuration.ConfigurationChanger.getLatest(ConfigurationChanger.java:439)
> at
> org.apache.ignite.internal.configuration.direct.DirectPropertyProxy.value(DirectPropertyProxy.java:65)
> at
> org.apache.ignite.internal.table.distributed.TableManager.updateAssignmentInternal(TableManager.java:652)
> at
> org.apache.ignite.internal.table.distributed.TableManager.onUpdateAssignments(TableManager.java:616)
> at
> org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier.notifyPublicListeners(ConfigurationNotifier.java:492)
> at
> org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier$2.visitLeafNode(ConfigurationNotifier.java:374)
> at
> org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier$2.visitLeafNode(ConfigurationNotifier.java:370)
> at
> org.apache.ignite.internal.schema.configuration.TableNode.traverseChildren(Unknown
> Source)
> at
> org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier.notifyListeners(ConfigurationNotifier.java:370)
> at
> org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier$2.visitNamedListNode(ConfigurationNotifier.java:460)
> at
> org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier$2.visitNamedListNode(ConfigurationNotifier.java:370)
> at
> org.apache.ignite.internal.schema.configuration.TablesNode.traverseChildren(Unknown
> Source)
> at
>
[jira] [Updated] (IGNITE-18004) Fix compilation after merging safe time propagation
[
https://issues.apache.org/jira/browse/IGNITE-18004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-18004:
-
Labels: ignite-3 (was: )
> Fix compilation after merging safe time propagation
> ---
>
> Key: IGNITE-18004
> URL: https://issues.apache.org/jira/browse/IGNITE-18004
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:java}
> [ERROR]
> /home/alapin/workspace/ignite-3/modules/sql-engine/src/main/java/org/apache/ignite/internal/sql/engine/SqlQueryProcessor.java:[393,110]
> org.apache.ignite.internal.hlc.HybridClock is abstract; cannot be
> instantiated
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17997) Whitespaces at the end are ignored during string comparison
[
https://issues.apache.org/jira/browse/IGNITE-17997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-17997:
-
Labels: ignite-3 (was: )
> Whitespaces at the end are ignored during string comparison
> ---
>
> Key: IGNITE-17997
> URL: https://issues.apache.org/jira/browse/IGNITE-17997
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: ignite-3
>
> In 3.0.0-Beta-1:
> {code:java}
> sql-cli> select 'a' = 'a' as t1, 'a' = 'b' as t2, 'a' = 'a ' as t3, 'a' = '
> a' as t4;
> ╔══╤═══╤══╤═══╗
> ║ T1 │ T2 │ T3 │ T4 ║
> ╠══╪═══╪══╪═══╣
> ║ true │ false │ true │ false ║
> ╚══╧═══╧══╧═══╝
> {code}
> Tests T1, T2, and T4 show correct behavior. But in test T2 we see that string
> 'a' is considered being equal to string 'a ' (same string but with
> arbitrary amount of whitespaces at the end). This is incorrect behavior.
> This issue may have the same nature as IGNITE-17996, but it's just a
> hypothesis.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17996) Strange behavior of SQL CASE expression
[
https://issues.apache.org/jira/browse/IGNITE-17996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-17996:
-
Labels: ignite-3 (was: )
> Strange behavior of SQL CASE expression
> ---
>
> Key: IGNITE-17996
> URL: https://issues.apache.org/jira/browse/IGNITE-17996
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: ignite-3
>
> I observe strange behavior in the next scenario:
>
> {code:java}
> sql-cli> create table xx (f1 int primary key);
> Updated 0 rows.
> sql-cli> insert into xx values (1);
> Updated 1 rows.
> sql-cli> insert into xx values (2);
> Updated 1 rows.
> sql-cli> select f1, case when f1 < 2 then 'foo' else 'barbar' end as s,
> length(case when f1 < 2 then 'foo' else 'barbar' end) as ls from xx;
> ╔╤╤╗
> ║ F1 │ S │ LS ║
> ╠╪╪╣
> ║ 2 │ barbar │ 6 ║
> ╟┼┼╢
> ║ 1 │ foo │ 6 ║
> ╚╧╧╝
> {code}
> I expect `CASE` to return 'foo' value, but de-facto it returns 'foo '
> ('foo' with 3 whitespaces at the end). Seems like this should be fixed.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17987) Temporarily exclude timestamp comparison in case of ABORTED to ABORTED txn state cas
[ https://issues.apache.org/jira/browse/IGNITE-17987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17987: - Labels: ignite-3 (was: ) > Temporarily exclude timestamp comparison in case of ABORTED to ABORTED txn > state cas > > > Key: IGNITE-17987 > URL: https://issues.apache.org/jira/browse/IGNITE-17987 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17981) Fix tests compilation errors on ignite-3.0.0-beta1 branch
[
https://issues.apache.org/jira/browse/IGNITE-17981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-17981:
-
Labels: ignite-3 (was: )
> Fix tests compilation errors on ignite-3.0.0-beta1 branch
> -
>
> Key: IGNITE-17981
> URL: https://issues.apache.org/jira/browse/IGNITE-17981
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are several merge-based bugs in test code in beta branch
> {code:java}
> > Task :ignite-storage-page-memory:compileTestJava FAILED
> /home/ivan/Projects/ignite-3/modules/storage-page-memory/src/test/java/org/apache/ignite/internal/storage/pagememory/index/AbstractPageMemorySortedIndexStorageTest.java:29:
> error: package org.apache.ignite.internal.schema.testutils.builder does not
> exist
> import org.apache.ignite.internal.schema.testutils.builder.SchemaBuilders;
> ^
> /home/ivan/Projects/ignite-3/modules/storage-page-memory/src/test/java/org/apache/ignite/internal/storage/pagememory/index/AbstractPageMemorySortedIndexStorageTest.java:31:
> error: package org.apache.ignite.internal.schema.testutils.definition.index
> does not exist
> import
> org.apache.ignite.internal.schema.testutils.definition.index.SortedIndexDefinition;
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17967) RO writeIntent resolution tests hang up in case of multi node cluster
[
https://issues.apache.org/jira/browse/IGNITE-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-17967:
-
Labels: ignite-3 transaction3_ro (was: transaction3_ro)
> RO writeIntent resolution tests hang up in case of multi node cluster
> -
>
> Key: IGNITE-17967
> URL: https://issues.apache.org/jira/browse/IGNITE-17967
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3, transaction3_ro
> Fix For: 3.0.0-beta1
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {code:java}
> TxAbstractTest#testReadOnlyGetWriteIntentResolutionUpdate{code}
> works in case of single node cluster but hangs up in case of multi node one.
> It also worth to mention that simple get tests without writeIntent resolution
> e.g.
> {code:java}
> TxAbstractTest#testReadOnlyGet{code}
> works both on sinle and multi node cluster.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17968) Seems that mvDataStorage.scan doesn't return pending removed value as writeIntent
[
https://issues.apache.org/jira/browse/IGNITE-17968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-17968:
-
Labels: ignite-3 transaction3_ro (was: transaction3_ro)
> Seems that mvDataStorage.scan doesn't return pending removed value as
> writeIntent
> -
>
> Key: IGNITE-17968
> URL: https://issues.apache.org/jira/browse/IGNITE-17968
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Semyon Danilov
>Priority: Major
> Labels: ignite-3, transaction3_ro
> Fix For: 3.0.0-beta1
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Following test will work
> {code:java}
> @Test
> public void testReadOnlyGetWriteIntentResolutionUpdate() {
> accounts.recordView().upsert(null, makeValue(1, 100.));
> // Pending tx
> Transaction tx = igniteTransactions.begin();
> accounts.recordView().upsert(tx, makeValue(1, 300.));
> // Update
> Transaction readOnlyTx = igniteTransactions.readOnly().begin();
> assertEquals(100., accounts.recordView().get(readOnlyTx,
> makeKey(1)).doubleValue("balance"));
> }{code}
> And following won't
> {code:java}
> @Test
> public void testReadOnlyGetWriteIntentResolutionRemove() {
> accounts.recordView().upsert(null, makeValue(1, 100.));
> // Pending tx
> Transaction tx = igniteTransactions.begin();
> accounts.recordView().delete(tx, makeKey(1));
> // Remove.
> Transaction readOnlyTx = igniteTransactions.readOnly().begin();
> assertEquals(100., accounts.recordView().get(readOnlyTx,
> makeKey(1)).doubleValue("balance"));
> } {code}
> Internally mvDataStorage.scan(readTimestamp) in
> PartitionReplicaListener#processReadOnlyMultiEntryAction will skip such
> pending removed entries.
> Please pay attention that writeIntetns that contain data (update pending
> modification instead of remove one) works propertly. See
> ItTxDistributedTestSingleNode#testReadOnlyGetWriteIntentResolutionUpdate and
> ItTxDistributedTestSingleNode#testReadOnlyPendingWriteIntentSkipped for more
> details.
> *Reproducers:*
> ItTxDistributedTestSingleNode#testReadOnlyGetWriteIntentResolutionRemove
> ItTxDistributedTestSingleNode#testReadOnlyPendingWriteIntentSkippedCombined
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17963) Use smarter logic for read-only recipient node evaluation
[ https://issues.apache.org/jira/browse/IGNITE-17963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17963: - Labels: ignite-3 (was: ) > Use smarter logic for read-only recipient node evaluation > - > > Key: IGNITE-17963 > URL: https://issues.apache.org/jira/browse/IGNITE-17963 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > h3. Motivation > It's possible for an end user to run read-only reads using KeyValueView and > RecordView endpoints with the help of get(), getAll() and similar methods > propagating read-only transaction as a first parameter. Internally such > requests will be routed to some recipient node that will process given > reads. Despite read-write actions that are processed on primary replica only, > it's possible to handle read-only actions on any replica of a corresponding > replication group. Thus some internal processor should define a node that > will process read-only action. Currently primary replica is always selected, > so that it's required to upgrade read-only recipient node evaluator with some > smarter logic. As a starting point we may consider local read-result > processing as preferable. > h3. Definition of Done > KeyValueView and RecordView read-only reads processed locally if there's a > local replica of a corresponding group. > h3. Implementation Notes > Generally speaking we should try to reuse sql engine logic here. Probably > it'll lead to exacting some sort of common planner for all table access > endpoints. However it might be rather tough improvement to implement, so > within the scope of given ticket let's do some initial research of how sql > engine targets requests to the nodes and add locality based recipient node > evaluation. > Currently it's all about InternalTableImpl#evaluateReadOnlyRecipientNode -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17953) NPE and closed connection on some malformed SQL requests using third-party SQL clients
[
https://issues.apache.org/jira/browse/IGNITE-17953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-17953:
-
Labels: ignite-3 (was: )
> NPE and closed connection on some malformed SQL requests using third-party
> SQL clients
> --
>
> Key: IGNITE-17953
> URL: https://issues.apache.org/jira/browse/IGNITE-17953
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: ignite-3
>
> I try to run different SQL queries in AI3 using
> [SqlLine|https://github.com/julianhyde/sqlline] tool and fresh ignite-client
> JAR downloaded from CI. I tried both correct and some incorrect SQL queries.
> And it looks like some incorrect SQL queries lead to irrecoverable error on
> the client side. The stack trace is the following:
> {code:java}
> Oct 21, 2022 4:57:02 PM io.netty.channel.DefaultChannelPipeline
> onUnhandledInboundException
> WARNING: An exceptionCaught() event was fired, and it reached at the tail of
> the pipeline. It usually means the last handler in the pipeline did not
> handle the exception.
> java.lang.NullPointerException
> at org.apache.ignite.lang.ErrorGroup.errorMessage(ErrorGroup.java:193)
> at
> org.apache.ignite.lang.IgniteException.(IgniteException.java:190)
> at
> org.apache.ignite.internal.client.TcpClientChannel.readError(TcpClientChannel.java:336)
> at
> org.apache.ignite.internal.client.TcpClientChannel.processNextMessage(TcpClientChannel.java:301)
> at
> org.apache.ignite.internal.client.TcpClientChannel.onMessage(TcpClientChannel.java:160)
> at
> org.apache.ignite.internal.client.io.netty.NettyClientConnection.onMessage(NettyClientConnection.java:94)
> at
> org.apache.ignite.internal.client.io.netty.NettyClientMessageHandler.channelRead(NettyClientMessageHandler.java:34)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:327)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:299)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:722)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:658)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:584)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:995)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Oct 21, 2022 4:58:07 PM io.netty.channel.DefaultChannelPipeline
> onUnhandledInboundException
> WARNING: An exceptionCaught() event was fired, and it reached at the tail of
> the pipeline. It usually means the last handler in the pipeline did not
> handle the exception.
> java.io.IOException: Connection reset by peer
> at java.base/sun.nio.ch.FileDispatcherImpl.read0(Native Method)
> at
> java.base/sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> at java.base/sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:276)
> at
