[jira] [Commented] (IGNITE-20573) Java thin 3.0: Introduce configurable operation timeout
[ https://issues.apache.org/jira/browse/IGNITE-20573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17811362#comment-17811362 ] Igor Sapego commented on IGNITE-20573: -- Looks good to me. > Java thin 3.0: Introduce configurable operation timeout > --- > > Key: IGNITE-20573 > URL: https://issues.apache.org/jira/browse/IGNITE-20573 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we have *IgniteClientConfiguration.connectTimeout* which is only > used for handshake and heartbeats, which means we use it to check if the > server and network are responsive. > However, other operations (put, get, compute, etc) can take any amount of > time. > Investigate if a general operation timeout can be useful. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-8801) Change default behaviour of atomic operations inside transactions
[
https://issues.apache.org/jira/browse/IGNITE-8801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17811353#comment-17811353
]
Scott Feldstein commented on IGNITE-8801:
-
thanks for the response [~timonin.maksim]
We noticed this issue when upgrading to 2.16.0 in the Ignite Hibernate L2 cache
implementation. There are two caches the {{default-update-timestamps-region}}
and {{{}default-query-results-region{}}}, both of these are updated by
hibernate in their transactional boundary and we have no control of the precise
ordering afaict.
For the time being I updated our implementation (which is a mirror of the
ignite hibernate impl) to create these caches using TRANSACTIONAL mode. Not
sure if that will have any implications for atomic caches since the timestamps
and query caches are used for transactional / non-transactional updates.
The overall problem that I see is - in frameworks such as hibernate developers
may have no control over the precise ordering of updates. This will cause
issues where Ignite will not accommodate the desired behavior due to this
restriction.
That being said, perhaps the switch to TRANSACTIONAL mode for these hibernate
internal caches is benign and I'm overreacting :) But I imagine you'll run into
issues at some point where developers simply can't control the ordering of
updates on caches that can't as easily be switched to TRANSACTIONAL.
Question - what is the implication of making a cache TRANSACTIONAL as opposed
to ATOMIC? IOW, why can't all caches be TRANSACTIONAL?
> Change default behaviour of atomic operations inside transactions
> -
>
> Key: IGNITE-8801
> URL: https://issues.apache.org/jira/browse/IGNITE-8801
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ryabov Dmitrii
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 5h
> Remaining Estimate: 0h
>
> Need to change default behaviour of atomic operations to fail inside
> transactions.
> 1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
> 2) Set default value to restrict atomic operations in
> {{CacheOperationContext}} constructor without arguments and arguments for
> calls of another constructor.
> 3) Fix javadocs.
> As per the latest round of discussion on Ignite Dev List as of 28/10/2022 we
> agreed on the following:
> 1) Revert deprecation IGNITE-17916 - reverted
> 2) Change default value in 2.15.
> 3) Notify users in release notes, an exception message - how to change the
> behavior back.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21366) AssertionError during the execution of the request
Aleksandr Nikolaev created IGNITE-21366:
---
Summary: AssertionError during the execution of the request
Key: IGNITE-21366
URL: https://issues.apache.org/jira/browse/IGNITE-21366
Project: Ignite
Issue Type: Bug
Reporter: Aleksandr Nikolaev
Assignee: Aleksandr Nikolaev
Fix For: 2.17
If GridH2Table#cache size is greater than int, then we get an AssertionError:
{code}
-26T19:32:35,247][ERROR][main][] Test failed
[test=RowCountTableStatisticsUsageTest#compareJoinsWithConditionsOnBothTables[cacheMode=REPLICATED],
duration=10]
java.lang.AssertionError: totalRowCnt=-4294967096, localRowCount=-2147483548
at
org.apache.ignite.internal.processors.query.h2.opt.TableStatistics.(TableStatistics.java:34)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.refreshStatsIfNeeded(GridH2Table.java:1055)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.getRowCountApproximation(GridH2Table.java:1013)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2IndexBase.getRowCountApproximation(GridH2IndexBase.java:226)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.h2.opt.H2ScanIndex.getRowCountApproximation(H2ScanIndex.java:158)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.h2.opt.H2ScanIndex.getCost(H2ScanIndex.java:289)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.h2.opt.H2TableScanIndex.getCost(H2TableScanIndex.java:74)
~[classes/:?]
at org.h2.table.Table.getBestPlanItem(Table.java:714)
~[h2-1.4.197.jar:1.4.197]
at org.h2.table.TableFilter.getBestPlanItem(TableFilter.java:224)
~[h2-1.4.197.jar:1.4.197]
at org.h2.table.Plan.calculateCost(Plan.java:121)
~[h2-1.4.197.jar:1.4.197]
at org.h2.command.dml.Optimizer.testPlan(Optimizer.java:180)
~[h2-1.4.197.jar:1.4.197]
at org.h2.command.dml.Optimizer.calculateBestPlan(Optimizer.java:81)
~[h2-1.4.197.jar:1.4.197]
at org.h2.command.dml.Optimizer.optimize(Optimizer.java:239)
~[h2-1.4.197.jar:1.4.197]
at org.h2.command.dml.Select.preparePlan(Select.java:1018)
~[h2-1.4.197.jar:1.4.197]
at org.h2.command.dml.Select.prepare(Select.java:884)
~[h2-1.4.197.jar:1.4.197]
at org.h2.command.dml.Explain.prepare(Explain.java:49)
~[h2-1.4.197.jar:1.4.197]
at org.h2.command.Parser.prepareCommand(Parser.java:283)
~[h2-1.4.197.jar:1.4.197]
at org.h2.engine.Session.prepareLocal(Session.java:611)
~[h2-1.4.197.jar:1.4.197]
at org.h2.engine.Session.prepareCommand(Session.java:549)
~[h2-1.4.197.jar:1.4.197]
at org.h2.jdbc.JdbcConnection.prepareCommand(JdbcConnection.java:1247)
~[h2-1.4.197.jar:1.4.197]
at
org.h2.jdbc.JdbcPreparedStatement.(JdbcPreparedStatement.java:76)
~[h2-1.4.197.jar:1.4.197]
at org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:694)
~[h2-1.4.197.jar:1.4.197]
at
org.apache.ignite.internal.processors.query.h2.H2Connection.prepareStatementNoCache(H2Connection.java:191)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.h2.H2PooledConnection.prepareStatementNoCache(H2PooledConnection.java:109)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.h2.QueryParser.parseH2(QueryParser.java:341)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.h2.QueryParser.parse0(QueryParser.java:225)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.h2.QueryParser.parse(QueryParser.java:138)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1011)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:3115)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:3086)
~[classes/:?]
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:3821)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$3(GridQueryProcessor.java:3132)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:3260)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:3082)
~[classes/:?]
[19:32:35] >>> Stopping test:
RowCountTableStatisticsUsageTest#compareJoinsWithConditionsOnBothTables[cacheMode=REPLICATED]
in 19 ms <<<
at
org.apache.ignite.internal.processors.query.Grid
[jira] [Updated] (IGNITE-21366) AssertionError during the execution of the request
[
https://issues.apache.org/jira/browse/IGNITE-21366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Nikolaev updated IGNITE-21366:
Labels: ise (was: )
> AssertionError during the execution of the request
> ---
>
> Key: IGNITE-21366
> URL: https://issues.apache.org/jira/browse/IGNITE-21366
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Nikolaev
>Assignee: Aleksandr Nikolaev
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
>
> If GridH2Table#cache size is greater than int, then we get an AssertionError:
> {code}
> -26T19:32:35,247][ERROR][main][] Test failed
> [test=RowCountTableStatisticsUsageTest#compareJoinsWithConditionsOnBothTables[cacheMode=REPLICATED],
> duration=10]
> java.lang.AssertionError: totalRowCnt=-4294967096, localRowCount=-2147483548
> at
> org.apache.ignite.internal.processors.query.h2.opt.TableStatistics.(TableStatistics.java:34)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.refreshStatsIfNeeded(GridH2Table.java:1055)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.getRowCountApproximation(GridH2Table.java:1013)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2IndexBase.getRowCountApproximation(GridH2IndexBase.java:226)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.opt.H2ScanIndex.getRowCountApproximation(H2ScanIndex.java:158)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.opt.H2ScanIndex.getCost(H2ScanIndex.java:289)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.opt.H2TableScanIndex.getCost(H2TableScanIndex.java:74)
> ~[classes/:?]
> at org.h2.table.Table.getBestPlanItem(Table.java:714)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.table.TableFilter.getBestPlanItem(TableFilter.java:224)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.table.Plan.calculateCost(Plan.java:121)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.command.dml.Optimizer.testPlan(Optimizer.java:180)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.command.dml.Optimizer.calculateBestPlan(Optimizer.java:81)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.command.dml.Optimizer.optimize(Optimizer.java:239)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.command.dml.Select.preparePlan(Select.java:1018)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.command.dml.Select.prepare(Select.java:884)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.command.dml.Explain.prepare(Explain.java:49)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.command.Parser.prepareCommand(Parser.java:283)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.engine.Session.prepareLocal(Session.java:611)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.engine.Session.prepareCommand(Session.java:549)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.jdbc.JdbcConnection.prepareCommand(JdbcConnection.java:1247)
> ~[h2-1.4.197.jar:1.4.197]
> at
> org.h2.jdbc.JdbcPreparedStatement.(JdbcPreparedStatement.java:76)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:694)
> ~[h2-1.4.197.jar:1.4.197]
> at
> org.apache.ignite.internal.processors.query.h2.H2Connection.prepareStatementNoCache(H2Connection.java:191)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.H2PooledConnection.prepareStatementNoCache(H2PooledConnection.java:109)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.QueryParser.parseH2(QueryParser.java:341)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.QueryParser.parse0(QueryParser.java:225)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.QueryParser.parse(QueryParser.java:138)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1011)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:3115)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:3086)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:3821)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$3(GridQueryProcessor.java:3132)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQue
[jira] [Updated] (IGNITE-21130) TxLog removal
[
https://issues.apache.org/jira/browse/IGNITE-21130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-21130:
--
Fix Version/s: 2.17
> TxLog removal
> -
>
> Key: IGNITE-21130
> URL: https://issues.apache.org/jira/browse/IGNITE-21130
> Project: Ignite
> Issue Type: Sub-task
> Components: mvcc
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Remove TxLog region [1, TxLog] and all corresponding data structures and
> code, such as classes from {{o.a.i.internal.processors.cache.mvcc.txlog.*}}
> package (except for {{TxState}}, see IGNITE-21345).
> #
> https://cwiki.apache.org/confluence/display/IGNITE/Distributed+MVCC+And+Transactional+SQL+Design
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21365) Improve documentation on MessagingService
[ https://issues.apache.org/jira/browse/IGNITE-21365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-21365: --- Description: # It must be clearly stated that for normal messages (if message's needsAck() returns true), send/invoke will provide ordering guarantees # For normal messages, the only possible outcomes are: ## Successful delivery (and future completion) ## (Only for invokes): timeout ## Exception signalling that the recipient has left the physical topology ## NodeStoppingException if current node stops # For normal messages, the above guarantees are provided even in cases when a physical connection is closed: another one would be open and proceed servicing the logical conneciton # For non-normal (non-ackable) messages, those guarantees are not guaranteed > Improve documentation on MessagingService > - > > Key: IGNITE-21365 > URL: https://issues.apache.org/jira/browse/IGNITE-21365 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > # It must be clearly stated that for normal messages (if message's needsAck() > returns true), send/invoke will provide ordering guarantees > # For normal messages, the only possible outcomes are: > ## Successful delivery (and future completion) > ## (Only for invokes): timeout > ## Exception signalling that the recipient has left the physical topology > ## NodeStoppingException if current node stops > # For normal messages, the above guarantees are provided even in cases when > a physical connection is closed: another one would be open and proceed > servicing the logical conneciton > # For non-normal (non-ackable) messages, those guarantees are not guaranteed -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21365) Improve documentation on MessagingService
Roman Puchkovskiy created IGNITE-21365: -- Summary: Improve documentation on MessagingService Key: IGNITE-21365 URL: https://issues.apache.org/jira/browse/IGNITE-21365 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21364) Do not throw HandshakeException from MessagingService methods
Roman Puchkovskiy created IGNITE-21364: -- Summary: Do not throw HandshakeException from MessagingService methods Key: IGNITE-21364 URL: https://issues.apache.org/jira/browse/IGNITE-21364 Project: Ignite Issue Type: Improvement Components: networking Reporter: Roman Puchkovskiy Fix For: 3.0.0-beta2 We must guarantee that a future from send/invoke either completes successfully (meaning that the message was delivered to the recipient node/a response was received), fail with an exception that signals that the recipient node has left the physical topology, or fail with NodeStoppingException (if the sending node is stopping). Other outcomes seem illegal. Hence, sends/invokes cannot end up with HandshakeExceptions. Those must be either swallowed internally, or replaced with exceptions that signal that the recipient has left the physical topology. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21336) Handle ClosedChannelException gracefully
[ https://issues.apache.org/jira/browse/IGNITE-21336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-21336: --- Description: We have a connection recovery mechanism that transparently re-establishes a connection whose Channel was closed. This means that a sender should never see ClosedChannelException as a result of a send. There is a race now that allows a sender to get such an exception. The same race might also cause a message to not be added to the unacknowledged messages queue, which might offset acknowledgement and put connection restoration logic at risk (some messages might not be resent). Also, message ordering might be compromised due to the same race on the boundary between the old and new channels in the same logical connection. was: We have a connection recovery mechanism that transparently re-establishes a connection whose Channel was closed. This means that a sender should never see ClosedChannelException as a result of a send. There is a race now that allows a sender to get such an exception. A retry logic should be added (in DefaultMessagingService) to make sure this exception just caused a retry (leading to reestablishing the connection or failing to reestablish it). > Handle ClosedChannelException gracefully > > > Key: IGNITE-21336 > URL: https://issues.apache.org/jira/browse/IGNITE-21336 > Project: Ignite > Issue Type: Improvement > Components: networking >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > We have a connection recovery mechanism that transparently re-establishes a > connection whose Channel was closed. This means that a sender should never > see ClosedChannelException as a result of a send. There is a race now that > allows a sender to get such an exception. > The same race might also cause a message to not be added to the > unacknowledged messages queue, which might offset acknowledgement and put > connection restoration logic at risk (some messages might not be resent). > Also, message ordering might be compromised due to the same race on the > boundary between the old and new channels in the same logical connection. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21336) Handle ClosedChannelException gracefully
[ https://issues.apache.org/jira/browse/IGNITE-21336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-21336: --- Epic Link: IGNITE-21188 > Handle ClosedChannelException gracefully > > > Key: IGNITE-21336 > URL: https://issues.apache.org/jira/browse/IGNITE-21336 > Project: Ignite > Issue Type: Improvement > Components: networking >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > We have a connection recovery mechanism that transparently re-establishes a > connection whose Channel was closed. This means that a sender should never > see ClosedChannelException as a result of a send. There is a race now that > allows a sender to get such an exception. > A retry logic should be added (in DefaultMessagingService) to make sure this > exception just caused a retry (leading to reestablishing the connection or > failing to reestablish it). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21336) Handle ClosedChannelException gracefully
[ https://issues.apache.org/jira/browse/IGNITE-21336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-21336: --- Summary: Handle ClosedChannelException gracefully (was: Retry a network send failed due to ClosedChannelException) > Handle ClosedChannelException gracefully > > > Key: IGNITE-21336 > URL: https://issues.apache.org/jira/browse/IGNITE-21336 > Project: Ignite > Issue Type: Improvement > Components: networking >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > We have a connection recovery mechanism that transparently re-establishes a > connection whose Channel was closed. This means that a sender should never > see ClosedChannelException as a result of a send. There is a race now that > allows a sender to get such an exception. > A retry logic should be added (in DefaultMessagingService) to make sure this > exception just caused a retry (leading to reestablishing the connection or > failing to reestablish it). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21359) There are 2 RebalanceUtil classes
[ https://issues.apache.org/jira/browse/IGNITE-21359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17811291#comment-17811291 ] Kirill Gusakov commented on IGNITE-21359: - LGTM > There are 2 RebalanceUtil classes > - > > Key: IGNITE-21359 > URL: https://issues.apache.org/jira/browse/IGNITE-21359 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > and they duplicate constants and methods. The least that we could do is > remove code duplication and maybe rename one of these classes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20894) Add tests for ensuring transactional guarantees
[ https://issues.apache.org/jira/browse/IGNITE-20894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-20894: -- Description: h3. Motivation The first purpose of the transaction flow tests is to preserve consistency in storage. The reason for this might be partial commits due to executing commits and rollbacks on one transaction. The second is avoiding redundant or permanent locks that can originate from an asynchronous operation happening in parallel with commit/rollback. h3. Definition of done Here is a list of tests that should be present: # Multiple commits of the transaction from different threads. There should be also some multithreaded enlists (via get/put operations) which should fail if the finishing process of the transaction has already started (transition to FINISHING state is done). After the completion of all asynchronous operations there should be no locks left on server side (we should check that the failed enlisting operations haven't left any locks as well). # Same as 1, but there should be concurrent rollbacks instead of commits. # Same as 1, but there should be random finish operations for transaction, there can be commits after rollback and rollbacks after commit. was: h3. Motivation The first purpose of the transaction flow tests is to preserve consistency in storage. The reason for this might be partial commits due to executing commits and rollbacks on one transaction. The second is avoiding redundant or permanent locks that can originate from an asynchronous operation happening in parallel with commit/rollback. h3. Definition of done Here is a list of tests that should be present: # Multiple commits of the transaction from different threads. There should be also some multithreaded enlists (via get/put operations) which should fail if the finishing process of the transaction has already started (transition to FINISHING state is done). After the completion of all asynchronous operations there should be no locks left on server side. # Same as 1, but there should be concurrent rollbacks instead of commits. # Same as 1, but there should be random finish operations for transaction, there can be commits after rollback and rollbacks after commit. > Add tests for ensuring transactional guarantees > --- > > Key: IGNITE-20894 > URL: https://issues.apache.org/jira/browse/IGNITE-20894 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Alexey Scherbakov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > Time Spent: 10m > Remaining Estimate: 0h > > h3. Motivation > The first purpose of the transaction flow tests is to preserve consistency in > storage. The reason for this might be partial commits due to executing > commits and rollbacks on one transaction. The second is avoiding redundant or > permanent locks that can originate from an asynchronous operation happening > in parallel with commit/rollback. > h3. Definition of done > Here is a list of tests that should be present: > # Multiple commits of the transaction from different threads. There should > be also some multithreaded enlists (via get/put operations) which should fail > if the finishing process of the transaction has already started (transition > to FINISHING state is done). After the completion of all asynchronous > operations there should be no locks left on server side (we should check that > the failed enlisting operations haven't left any locks as well). > # Same as 1, but there should be concurrent rollbacks instead of commits. > # Same as 1, but there should be random finish operations for transaction, > there can be commits after rollback and rollbacks after commit. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20894) Add tests for ensuring transactional guarantees
[ https://issues.apache.org/jira/browse/IGNITE-20894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-20894: -- Description: h3. Motivation The first purpose of the transaction flow tests is to preserve consistency in storage. The reason for this might be partial commits due to executing commits and rollbacks on one transaction. The second is avoiding redundant or permanent locks that can originate from an asynchronous operation happening in parallel with commit/rollback. h3. Definition of done Here is a list of tests that should be present: # Multiple commits of the transaction from different threads. There should be also some multithreaded enlists (via get/put operations) which should fail if the finishing process of the transaction has already started (transition to FINISHING state is done). Such enlists should fail. After the completion of all asynchronous operations there should be no locks left on server side. # Same as 1, but there should be concurrent rollbacks instead of commits. # Same as 1, but there should be random finish operations for transaction, there can be commits after rollback and rollbacks after commit. was: h3. Motivation The first purpose of the transaction flow tests is to preserve consistency in storage. The reason for this might be partial commits due to executing commits and rollbacks on one transaction. The second is avoiding redundant or permanent locks that can originate from an asynchronous operation happening in parallel with commit/rollback. h3. Definition of done Here is a list of tests that should be present: # Multiple commits of the transaction from different threads. There should be also some multithreaded enlists (via get/put operations) which should fail when the finishing process of the transaction has started (transition to FINISHING state is done). Such enlists should fail. After the completion of all asynchronous operations there should be no locks left on server side. # Same as 1, but there should be concurrent rollbacks instead of commits. # Same as 1, but there should be random finish operations for transaction, there can be commits after rollback and rollbacks after commit. > Add tests for ensuring transactional guarantees > --- > > Key: IGNITE-20894 > URL: https://issues.apache.org/jira/browse/IGNITE-20894 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Alexey Scherbakov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > Time Spent: 10m > Remaining Estimate: 0h > > h3. Motivation > The first purpose of the transaction flow tests is to preserve consistency in > storage. The reason for this might be partial commits due to executing > commits and rollbacks on one transaction. The second is avoiding redundant or > permanent locks that can originate from an asynchronous operation happening > in parallel with commit/rollback. > h3. Definition of done > Here is a list of tests that should be present: > # Multiple commits of the transaction from different threads. There should > be also some multithreaded enlists (via get/put operations) which should fail > if the finishing process of the transaction has already started (transition > to FINISHING state is done). Such enlists should fail. After the completion > of all asynchronous operations there should be no locks left on server side. > # Same as 1, but there should be concurrent rollbacks instead of commits. > # Same as 1, but there should be random finish operations for transaction, > there can be commits after rollback and rollbacks after commit. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20894) Add tests for ensuring transactional guarantees
[ https://issues.apache.org/jira/browse/IGNITE-20894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-20894: -- Description: h3. Motivation The first purpose of the transaction flow tests is to preserve consistency in storage. The reason for this might be partial commits due to executing commits and rollbacks on one transaction. The second is avoiding redundant or permanent locks that can originate from an asynchronous operation happening in parallel with commit/rollback. h3. Definition of done Here is a list of tests that should be present: # Multiple commits of the transaction from different threads. There should be also some multithreaded enlists (via get/put operations) which should fail if the finishing process of the transaction has already started (transition to FINISHING state is done). After the completion of all asynchronous operations there should be no locks left on server side. # Same as 1, but there should be concurrent rollbacks instead of commits. # Same as 1, but there should be random finish operations for transaction, there can be commits after rollback and rollbacks after commit. was: h3. Motivation The first purpose of the transaction flow tests is to preserve consistency in storage. The reason for this might be partial commits due to executing commits and rollbacks on one transaction. The second is avoiding redundant or permanent locks that can originate from an asynchronous operation happening in parallel with commit/rollback. h3. Definition of done Here is a list of tests that should be present: # Multiple commits of the transaction from different threads. There should be also some multithreaded enlists (via get/put operations) which should fail if the finishing process of the transaction has already started (transition to FINISHING state is done). Such enlists should fail. After the completion of all asynchronous operations there should be no locks left on server side. # Same as 1, but there should be concurrent rollbacks instead of commits. # Same as 1, but there should be random finish operations for transaction, there can be commits after rollback and rollbacks after commit. > Add tests for ensuring transactional guarantees > --- > > Key: IGNITE-20894 > URL: https://issues.apache.org/jira/browse/IGNITE-20894 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Alexey Scherbakov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > Time Spent: 10m > Remaining Estimate: 0h > > h3. Motivation > The first purpose of the transaction flow tests is to preserve consistency in > storage. The reason for this might be partial commits due to executing > commits and rollbacks on one transaction. The second is avoiding redundant or > permanent locks that can originate from an asynchronous operation happening > in parallel with commit/rollback. > h3. Definition of done > Here is a list of tests that should be present: > # Multiple commits of the transaction from different threads. There should > be also some multithreaded enlists (via get/put operations) which should fail > if the finishing process of the transaction has already started (transition > to FINISHING state is done). After the completion of all asynchronous > operations there should be no locks left on server side. > # Same as 1, but there should be concurrent rollbacks instead of commits. > # Same as 1, but there should be random finish operations for transaction, > there can be commits after rollback and rollbacks after commit. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20894) Add tests for ensuring transactional guarantees
[ https://issues.apache.org/jira/browse/IGNITE-20894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-20894: -- Description: h3. Motivation The first purpose of the transaction flow tests is to preserve consistency in storage. The reason for this might be partial commits due to executing commits and rollbacks on one transaction. The second is avoiding redundant or permanent locks that can originate from an asynchronous operation happening in parallel with commit/rollback. h3. Definition of done Here is a list of tests that should be present: # Multiple commits of the transaction from different threads. There should be also some multithreaded enlists (via get/put operations) which should fail when the finishing process of the transaction has started (transition to FINISHING state is done). Such enlists should fail. After the completion of all asynchronous operations there should be no locks left on server side. # Same as 1, but there should be concurrent rollbacks instead of commits. # Same as 1, but there should be random finish operations for transaction, there can be commits after rollback and rollbacks after commit. was: h3. Motivation The first purpose of the transaction flow tests is to preserve consistency in storage. The reason for this might be partial commits due to executing commits and rollbacks on one transaction. The second is avoiding redundant or permanent locks that can originate from an asynchronous operation during a commit. h3. Definition of done Here is a list of tests that should be present: # Ensure the correctness of the exception and all the transaction's locks are freed when adding operations to a committed transaction. (Multithreading) # Ensure the correctness of the exception and all the transaction's locks are freed when adding operations to a rolled-back transaction. (Multithreading) # Test consistency after commit when the transaction is acting asynchronously. (1 and 2 about throwing an exception, 3 and 4 checks same invariants but for not throwing an exception case.) # Test consistency after rollback when the transaction is acting asynchronously. > Add tests for ensuring transactional guarantees > --- > > Key: IGNITE-20894 > URL: https://issues.apache.org/jira/browse/IGNITE-20894 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Alexey Scherbakov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > Time Spent: 10m > Remaining Estimate: 0h > > h3. Motivation > The first purpose of the transaction flow tests is to preserve consistency in > storage. The reason for this might be partial commits due to executing > commits and rollbacks on one transaction. The second is avoiding redundant or > permanent locks that can originate from an asynchronous operation happening > in parallel with commit/rollback. > h3. Definition of done > Here is a list of tests that should be present: > # Multiple commits of the transaction from different threads. There should > be also some multithreaded enlists (via get/put operations) which should fail > when the finishing process of the transaction has started (transition to > FINISHING state is done). Such enlists should fail. After the completion of > all asynchronous operations there should be no locks left on server side. > # Same as 1, but there should be concurrent rollbacks instead of commits. > # Same as 1, but there should be random finish operations for transaction, > there can be commits after rollback and rollbacks after commit. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21358) ItRebalanceDistributedTest#testRaftClientsUpdatesAfterRebalance is flaky with No such partition 0 in table TBL1
[
https://issues.apache.org/jira/browse/IGNITE-21358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin resolved IGNITE-21358.
--
Resolution: Duplicate
> ItRebalanceDistributedTest#testRaftClientsUpdatesAfterRebalance is flaky with
> No such partition 0 in table TBL1
> ---
>
> Key: IGNITE-21358
> URL: https://issues.apache.org/jira/browse/IGNITE-21358
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Major
> Labels: MakeTeamcityGreenAgain, ignite-3
>
> {code:java}
> org.apache.ignite.internal.lang.IgniteInternalException: IGN-CMN-65535
> TraceId:b98e1ecc-d098-4f18-9ba4-b0b6d7bddf80 No such partition 0 in table
> TBL1 at
> app//org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.partitionRaftGroupService(InternalTableImpl.java:1518)
> at
> app//org.apache.ignite.internal.rebalance.ItRebalanceDistributedTest.lambda$testRaftClientsUpdatesAfterRebalance$25(ItRebalanceDistributedTest.java:653)
> at
> java.base@11.0.17/java.util.stream.MatchOps$1MatchSink.accept(MatchOps.java:90)
> at
> java.base@11.0.17/java.util.ArrayList$ArrayListSpliterator.tryAdvance(ArrayList.java:1632)
> {code}
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7801385?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildProblemsSection=true&expandBuildTestsSection=true
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21363) Catalog compaction when starting index building
Kirill Tkalenko created IGNITE-21363: Summary: Catalog compaction when starting index building Key: IGNITE-21363 URL: https://issues.apache.org/jira/browse/IGNITE-21363 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko We need to deal with compaction of catalog when starting to build an index, for example, in IGNITE-21115 we need to wait for the RW transaction to finish until the vcatalog in which the index created, if we delete these catalog versions (provided that they are not the latest), what will end up is unknown. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21353) Sql. Support for choosing the primary key index type.
[
https://issues.apache.org/jira/browse/IGNITE-21353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-21353:
---
Description:
As of now we support choosing type just for secondary indexes, like a
_CREATE INDEX idx_name ON table *USING TREE* (column_name)_
But for PK we always create under the hood HASH index.
Let's introduce ability to choose type for PK by the analogy with a secondary
indexes;
it should be add an optional parameter *USING type* for PRIMARY KEY definition
and add ability set collation for columns including into PK)
CREATE TABLE . (..., PRIMARY KEY *[ USING SORTED | HASH ]* (column1,
column2, ... column_n)) ...)
as example full command: CREATE TABLE my (c1 INT, c2 INT, c3 INT, PRIMARY KEY
*USING* {*}SORTED{*}{*}{{*}} (c2 ASC, c1 DESC NULL FIRST))
Also let's set BTREE as default for PK without set concrete type.
was:
As of now we support choosing type just for secondary indexes, like a
_CREATE INDEX idx_name ON table *USING TREE* (column_name)_
But for PK we always create under the hood HASH index.
Let's introduce ability to choose type for PK by the analogy with a secondary
indexes;
it should be add an optional parameter *USING type* for PRIMARY KEY definition
and add ability set collation for columns including into PK)
CREATE TABLE . (..., PRIMARY KEY *[ USING SORTED | HASH ]* (column1,
column2, ... column_n)) ...)
as example full command: CREATE TABLE my (c1 INT, c2 INT, c3 INT, PRIMARY *KEY
USING* {*}SORTED{*}{*}{*} (c2 ASC, c1 DESC NULL FIRST))
Also let's set BTREE as default for PK without set concrete type.
> Sql. Support for choosing the primary key index type.
> -
>
> Key: IGNITE-21353
> URL: https://issues.apache.org/jira/browse/IGNITE-21353
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> As of now we support choosing type just for secondary indexes, like a
> _CREATE INDEX idx_name ON table *USING TREE* (column_name)_
> But for PK we always create under the hood HASH index.
> Let's introduce ability to choose type for PK by the analogy with a secondary
> indexes;
> it should be add an optional parameter *USING type* for PRIMARY KEY
> definition and add ability set collation for columns including into PK)
> CREATE TABLE . (..., PRIMARY KEY *[ USING SORTED | HASH ]* (column1,
> column2, ... column_n)) ...)
> as example full command: CREATE TABLE my (c1 INT, c2 INT, c3 INT, PRIMARY KEY
> *USING* {*}SORTED{*}{*}{{*}} (c2 ASC, c1 DESC NULL FIRST))
> Also let's set BTREE as default for PK without set concrete type.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21353) Sql. Support for choosing the primary key index type.
[
https://issues.apache.org/jira/browse/IGNITE-21353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-21353:
---
Description:
As of now we support choosing type just for secondary indexes, like a
_CREATE INDEX idx_name ON table *USING TREE* (column_name)_
But for PK we always create under the hood HASH index.
Let's introduce ability to choose type for PK by the analogy with a secondary
indexes;
it should be add an optional parameter *USING type* for PRIMARY KEY definition
and add ability set collation for columns including into PK)
CREATE TABLE . (..., PRIMARY KEY *[ USING SORTED | HASH ]* (column1,
column2, ... column_n)) ...)
as example full command: CREATE TABLE my (c1 INT, c2 INT, c3 INT, PRIMARY *KEY
USING* {*}SORTED{*}{*}{*} (c2 ASC, c1 DESC NULL FIRST))
Also let's set BTREE as default for PK without set concrete type.
was:
As of now we support choosing type just for secondary indexes, like a
_CREATE INDEX idx_name ON table *USING TREE* (column_name)_
But for PK we always create under the hood HASH index.
Let's introduce ability to choose type for PK by the analogy with a secondary
indexes;
it should be add an optional parameter *USING type* for PRIMARY KEY definition
and add ability set collation for columns including into PK)
CREATE TABLE . (..., PRIMARY KEY *[ USING BTREE | HASH ]* (column1,
column2, ... column_n)) ...)
as example full command: CREATE TABLE my (c1 INT, c2 INT, c3 INT, PRIMARY *KEY
USING TREE* (c2 ASC, c1 DESC NULL FIRST))
Also let's set BTREE as default for PK without set concrete type.
> Sql. Support for choosing the primary key index type.
> -
>
> Key: IGNITE-21353
> URL: https://issues.apache.org/jira/browse/IGNITE-21353
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> As of now we support choosing type just for secondary indexes, like a
> _CREATE INDEX idx_name ON table *USING TREE* (column_name)_
> But for PK we always create under the hood HASH index.
> Let's introduce ability to choose type for PK by the analogy with a secondary
> indexes;
> it should be add an optional parameter *USING type* for PRIMARY KEY
> definition and add ability set collation for columns including into PK)
> CREATE TABLE . (..., PRIMARY KEY *[ USING SORTED | HASH ]* (column1,
> column2, ... column_n)) ...)
> as example full command: CREATE TABLE my (c1 INT, c2 INT, c3 INT, PRIMARY
> *KEY USING* {*}SORTED{*}{*}{*} (c2 ASC, c1 DESC NULL FIRST))
> Also let's set BTREE as default for PK without set concrete type.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21353) Sql. Support for choosing the primary key index type.
[ https://issues.apache.org/jira/browse/IGNITE-21353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-21353: --- Description: As of now we support choosing type just for secondary indexes, like a _CREATE INDEX idx_name ON table *USING TREE* (column_name)_ But for PK we always create under the hood HASH index. Let's introduce ability to choose type for PK by the analogy with a secondary indexes; it should be add an optional parameter *USING type* for PRIMARY KEY definition and add ability set collation for columns including into PK) CREATE TABLE . (..., PRIMARY KEY *[ USING BTREE | HASH ]* (column1, column2, ... column_n)) ...) as example full command: CREATE TABLE my (c1 INT, c2 INT, c3 INT, PRIMARY *KEY USING TREE* (c2 ASC, c1 DESC NULL FIRST)) Also let's set BTREE as default for PK without set concrete type. was: As of now we support choosing type just for secondary indexes, like a _CREATE INDEX idx_name ON table *USING TREE* (column_name)_ But for PK we always create under the hood HASH index. Let's introduce ability to choose type for PK by the analogy with a secondary indexes; it should be add an optional parameter *USING type* for PRIMARY KEY definition and add ability set collation for columns including into PK) CREATE TABLE . PRIMARY KEY *[ USING BTREE | HASH ]* (column1, column2, ... column_n)) as example full command: CREATE TABLE my (c1 INT, c2 INT, c3 INT, PRIMARY *KEY USING TREE* (c2 ASC, c1 DESC NULL FIRST)) Also let's set BTREE as default for PK without set concrete type. > Sql. Support for choosing the primary key index type. > - > > Key: IGNITE-21353 > URL: https://issues.apache.org/jira/browse/IGNITE-21353 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > As of now we support choosing type just for secondary indexes, like a > _CREATE INDEX idx_name ON table *USING TREE* (column_name)_ > But for PK we always create under the hood HASH index. > Let's introduce ability to choose type for PK by the analogy with a secondary > indexes; > it should be add an optional parameter *USING type* for PRIMARY KEY > definition and add ability set collation for columns including into PK) > CREATE TABLE . (..., PRIMARY KEY *[ USING BTREE | HASH ]* (column1, > column2, ... column_n)) ...) > as example full command: CREATE TABLE my (c1 INT, c2 INT, c3 INT, PRIMARY > *KEY USING TREE* (c2 ASC, c1 DESC NULL FIRST)) > Also let's set BTREE as default for PK without set concrete type. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21353) Sql. Support for choosing the primary key index type.
[ https://issues.apache.org/jira/browse/IGNITE-21353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-21353: --- Description: As of now we support choosing type just for secondary indexes, like a _CREATE INDEX idx_name ON table *USING TREE* (column_name)_ But for PK we always create under the hood HASH index. Let's introduce ability to choose type for PK by the analogy with a secondary indexes; it should be add an optional parameter *USING type* for PRIMARY KEY definition and add ability set collation for columns including into PK) CREATE TABLE . PRIMARY KEY *[ USING BTREE | HASH ]* (column1, column2, ... column_n)) as example full command: CREATE TABLE my (c1 INT, c2 INT, c3 INT, PRIMARY *KEY USING TREE* (c2 ASC, c1 DESC NULL FIRST)) Also let's set BTREE as default for PK without set concrete type. was: As of now we support choosing type just for secondary indexes, like a _CREATE INDEX idx_name ON table *USING TREE* (column_name)_ But for PK we always create under the hood HASH index. Let's introduce ability to choose type for PK by the analogy with a secondary indexes; it should be add an optional parameter *USING type* for PRIMARY KEY definition CREATE TABLE . PRIMARY KEY *[ USING BTREE | HASH ]* (column1, column2, ... column_n)... Also let's set BTREE as default for PK without set concrete type. > Sql. Support for choosing the primary key index type. > - > > Key: IGNITE-21353 > URL: https://issues.apache.org/jira/browse/IGNITE-21353 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > As of now we support choosing type just for secondary indexes, like a > _CREATE INDEX idx_name ON table *USING TREE* (column_name)_ > But for PK we always create under the hood HASH index. > Let's introduce ability to choose type for PK by the analogy with a secondary > indexes; > it should be add an optional parameter *USING type* for PRIMARY KEY > definition and add ability set collation for columns including into PK) > CREATE TABLE . PRIMARY KEY *[ USING BTREE | HASH ]* (column1, column2, > ... column_n)) > as example full command: CREATE TABLE my (c1 INT, c2 INT, c3 INT, PRIMARY > *KEY USING TREE* (c2 ASC, c1 DESC NULL FIRST)) > Also let's set BTREE as default for PK without set concrete type. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21360) Fix ClientComputeTest
[
https://issues.apache.org/jira/browse/IGNITE-21360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17811169#comment-17811169
]
Pavel Tupitsyn commented on IGNITE-21360:
-
Merged to main: 7a1225662ce4cd780d32f4db6204847d6c0044d1
> Fix ClientComputeTest
> -
>
> Key: IGNITE-21360
> URL: https://issues.apache.org/jira/browse/IGNITE-21360
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{ClientComputeTest.testClientSendsComputeJobToTargetNodeWhenDirectConnectionExists}}
> is flaky due to the concurrent usage of the static field.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21360) Fix ClientComputeTest
[
https://issues.apache.org/jira/browse/IGNITE-21360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-21360:
Component/s: thin client
> Fix ClientComputeTest
> -
>
> Key: IGNITE-21360
> URL: https://issues.apache.org/jira/browse/IGNITE-21360
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{ClientComputeTest.testClientSendsComputeJobToTargetNodeWhenDirectConnectionExists}}
> is flaky due to the concurrent usage of the static field.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21360) Fix ClientComputeTest
[
https://issues.apache.org/jira/browse/IGNITE-21360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-21360:
Fix Version/s: 3.0.0-beta2
> Fix ClientComputeTest
> -
>
> Key: IGNITE-21360
> URL: https://issues.apache.org/jira/browse/IGNITE-21360
> Project: Ignite
> Issue Type: Bug
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{ClientComputeTest.testClientSendsComputeJobToTargetNodeWhenDirectConnectionExists}}
> is flaky due to the concurrent usage of the static field.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21360) Fix ClientComputeTest
[
https://issues.apache.org/jira/browse/IGNITE-21360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-21360:
Affects Version/s: 3.0.0-beta1
> Fix ClientComputeTest
> -
>
> Key: IGNITE-21360
> URL: https://issues.apache.org/jira/browse/IGNITE-21360
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{ClientComputeTest.testClientSendsComputeJobToTargetNodeWhenDirectConnectionExists}}
> is flaky due to the concurrent usage of the static field.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-21360) Fix ClientComputeTest
[
https://issues.apache.org/jira/browse/IGNITE-21360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn resolved IGNITE-21360.
-
Resolution: Fixed
> Fix ClientComputeTest
> -
>
> Key: IGNITE-21360
> URL: https://issues.apache.org/jira/browse/IGNITE-21360
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{ClientComputeTest.testClientSendsComputeJobToTargetNodeWhenDirectConnectionExists}}
> is flaky due to the concurrent usage of the static field.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20680) Postpone destroying table data while table is reachable for RO transactions via Catalog
[ https://issues.apache.org/jira/browse/IGNITE-20680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-20680: -- Summary: Postpone destroying table data while table is reachable for RO transactions via Catalog (was: Move table to RO state when executing DROP TABLE) > Postpone destroying table data while table is reachable for RO transactions > via Catalog > --- > > Key: IGNITE-20680 > URL: https://issues.apache.org/jira/browse/IGNITE-20680 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Currently, when a DROP TABLE command is executed, the table is immediately > stopped and its data destroyed. > Instead, we should drop the table in next Catalog version only, so it's only > accessible for RO transactions which readTimestamp is before the drop > timestamp; accordingly, partition RAFT groups should not be stopped and > storages destroyed yet. > TableManager should listen for LWM changes and destroy dropped tables, which > drop timestamp is below LWM. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20680) Move table to RO state when executing DROP TABLE
[ https://issues.apache.org/jira/browse/IGNITE-20680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-20680: - Assignee: Andrey Mashenkov > Move table to RO state when executing DROP TABLE > > > Key: IGNITE-20680 > URL: https://issues.apache.org/jira/browse/IGNITE-20680 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Currently, when a DROP TABLE command is executed, the table is immediately > stopped and its data destroyed. > Instead, we should drop the table in next Catalog version only, so it's only > accessible for RO transactions which readTimestamp is before the drop > timestamp; accordingly, partition RAFT groups should not be stopped and > storages destroyed yet. > TableManager should listen for LWM changes and destroy dropped tables, which > drop timestamp is below LWM. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21291) Scan cursors do not close when an RO transaction is finalized
[ https://issues.apache.org/jira/browse/IGNITE-21291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-21291: --- Description: h3. Motivation The cursors are opened on the server side and take up extra memory. When an RW transaction is committed, we send the transaction cleanup messages to all transaction participants. But the state of the RO transaction is strung locally, so do not send any messages to the transaction participants (where the cursors were opened). h3. Definition of done Cursors that were created by an RO transaction should be closed when the transaction is no longer in use. was: h3. Motivation The cursors are opened on the server side and take up extra memory. When an RW transaction is committed, we send the transaction cleanup messages to all transaction participants. But the state of the RO transaction is strung locally, so do not send any messages to the transaction participants (where the cursors were opened). h3. Definition of done Cursors for RO transactions are closed somehow. > Scan cursors do not close when an RO transaction is finalized > - > > Key: IGNITE-21291 > URL: https://issues.apache.org/jira/browse/IGNITE-21291 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > h3. Motivation > The cursors are opened on the server side and take up extra memory. When an > RW transaction is committed, we send the transaction cleanup messages to all > transaction participants. But the state of the RO transaction is strung > locally, so do not send any messages to the transaction participants (where > the cursors were opened). > h3. Definition of done > Cursors that were created by an RO transaction should be closed when the > transaction is no longer in use. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20680) Move table to RO state when executing DROP TABLE
[ https://issues.apache.org/jira/browse/IGNITE-20680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-20680: -- Description: Currently, when a DROP TABLE command is executed, the table is immediately stopped and its data destroyed. Instead, we should drop the table in next Catalog version only, so it's only accessible for RO transactions which readTimestamp is before the drop timestamp; accordingly, partition RAFT groups should not be stopped and storages destroyed yet. TableManager should listen for LWM changes and destroy dropped tables, which drop timestamp is below LWM. was: Currently, when a DROP TABLE command is executed, the table is immediately stopped and its data destroyed. Instead, we should move the table to a 'read-only' state where it's only accessible for RO transactions which readTimestamp is before the drop timestamp; accordingly, partition RAFT groups should not be stopped and storages destroyed yet. >From the point of view of the Catalog, the table should either be removed from >it when executing a DROP TABLE command, or it should be marked as a >'read-only', this should be decided. > Move table to RO state when executing DROP TABLE > > > Key: IGNITE-20680 > URL: https://issues.apache.org/jira/browse/IGNITE-20680 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Currently, when a DROP TABLE command is executed, the table is immediately > stopped and its data destroyed. > Instead, we should drop the table in next Catalog version only, so it's only > accessible for RO transactions which readTimestamp is before the drop > timestamp; accordingly, partition RAFT groups should not be stopped and > storages destroyed yet. > TableManager should listen for LWM changes and destroy dropped tables, which > drop timestamp is below LWM. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21362) Just inserted row not found when using KV api
Konstantin Orlov created IGNITE-21362:
-
Summary: Just inserted row not found when using KV api
Key: IGNITE-21362
URL: https://issues.apache.org/jira/browse/IGNITE-21362
Project: Ignite
Issue Type: Bug
Reporter: Konstantin Orlov
Consider the following scenario:
{code:java}
sql("CREATE TABLE my (c1 INT, c2 INT, c3 INT, PRIMARY KEY (c2, c1))");
// mind the order of columns in PK definition
Tuple key = Tuple.create()
.set("c1", 1)
.set("c2", 2);
Tuple val = Tuple.create()
.set("c3", 3);
KeyValueView kv = igniteNode
.tables()
.table("my")
.keyValueView();
kv.put(null, key, val);
Tuple result = kv.get(null, key); // <-- returns null here
{code}
Expected behaviour is to get result equals to {{val}} that we've just put to
the table, but {{kv.get()}} returns {{null}} in this case. If we change the
order of columns in PK definition to (c1, c2), then the test will pass.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21361) Fix java.lang.IllegalStateException: Port 47500 is not available.
Vladimir Pligin created IGNITE-21361: Summary: Fix java.lang.IllegalStateException: Port 47500 is not available. Key: IGNITE-21361 URL: https://issues.apache.org/jira/browse/IGNITE-21361 Project: Ignite Issue Type: Improvement Reporter: Vladimir Pligin There are failures leading to NPEs in the test infrastructure. [https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7798120?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildProblemsSection=true&expandBuildChangesSection=true&expandBuildTestsSection=true] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21360) Fix ClientComputeTest
Vadim Pakhnushev created IGNITE-21360:
-
Summary: Fix ClientComputeTest
Key: IGNITE-21360
URL: https://issues.apache.org/jira/browse/IGNITE-21360
Project: Ignite
Issue Type: Bug
Reporter: Vadim Pakhnushev
Assignee: Vadim Pakhnushev
{{ClientComputeTest.testClientSendsComputeJobToTargetNodeWhenDirectConnectionExists}}
is flaky due to the concurrent usage of the static field.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21280) Add DATA_PAGE_FRAGMENTED_UPDATE_RECORD WAL record type placeholder
[ https://issues.apache.org/jira/browse/IGNITE-21280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17811155#comment-17811155 ] Nikolay Izhikov commented on IGNITE-21280: -- Hello [~slava.koptilin], [~ktkale...@gridgain.com] Can you, please, clarify the intention of reservation? Do we have some related ticket to use new WAL record type? > Add DATA_PAGE_FRAGMENTED_UPDATE_RECORD WAL record type placeholder > -- > > Key: IGNITE-21280 > URL: https://issues.apache.org/jira/browse/IGNITE-21280 > Project: Ignite > Issue Type: Improvement >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > Reserve new WAL type for encrypted DATA_PAGE_FRAGMENTED_UPDATE_RECORD record. -- This message was sent by Atlassian Jira (v8.20.10#820010)
