[jira] [Created] (IGNITE-13710) Calcite integration. Fix or to union rule logic
Igor Seliverstov created IGNITE-13710: - Summary: Calcite integration. Fix or to union rule logic Key: IGNITE-13710 URL: https://issues.apache.org/jira/browse/IGNITE-13710 Project: Ignite Issue Type: Bug Components: sql Reporter: Igor Seliverstov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13515) Performance drop when there are many thin clients per server
Igor Seliverstov created IGNITE-13515:
-
Summary: Performance drop when there are many thin clients per
server
Key: IGNITE-13515
URL: https://issues.apache.org/jira/browse/IGNITE-13515
Project: Ignite
Issue Type: Task
Components: clients
Reporter: Igor Seliverstov
Assignee: Igor Seliverstov
There is a performance drop when running many thin clients per node:
{noformat}
4 nodes - 1 thin client java - ~5500 pps (put per second)
4 nodes - 2 thin clients java - ~5000 pps
4 nodes - 4 thin clients java - ~4000 pps
4 nodes - 10 thin clients java - ~1500 pps
4 nodes - ~100 thin clients java - ~100 pps
{noformat}
May be related to sync request processing in connection thread pool on server
side. Need to investigate and fix if possible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13461) Calcite integration. Wrong behavior on thick client side planning.
Igor Seliverstov created IGNITE-13461: - Summary: Calcite integration. Wrong behavior on thick client side planning. Key: IGNITE-13461 URL: https://issues.apache.org/jira/browse/IGNITE-13461 Project: Ignite Issue Type: Bug Components: sql Reporter: Igor Seliverstov Assignee: Igor Seliverstov Query planner tries to use index physical structures at a client side, also it tries to access affinity manager, that isn't started on the client. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13247) Calcite integration. Move QueryCursorEx.isQuery() flag to a proper place.
Igor Seliverstov created IGNITE-13247: - Summary: Calcite integration. Move QueryCursorEx.isQuery() flag to a proper place. Key: IGNITE-13247 URL: https://issues.apache.org/jira/browse/IGNITE-13247 Project: Ignite Issue Type: Improvement Reporter: Igor Seliverstov Since QueryCursorEx is used in continuous queries, we should move SQL query related flag to another place. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13117) Calcite integration. Update Calcite version to 1.23.0
Igor Seliverstov created IGNITE-13117: - Summary: Calcite integration. Update Calcite version to 1.23.0 Key: IGNITE-13117 URL: https://issues.apache.org/jira/browse/IGNITE-13117 Project: Ignite Issue Type: Improvement Reporter: Igor Seliverstov Assignee: Igor Seliverstov There are two important features in the new Calcite release what we need to solve current planner issues: top-down traits propagation and bottom-up traits derivation -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12991) Calcite integration. Pass cancel flag to VolcanoPlanner
Igor Seliverstov created IGNITE-12991:
-
Summary: Calcite integration. Pass cancel flag to VolcanoPlanner
Key: IGNITE-12991
URL: https://issues.apache.org/jira/browse/IGNITE-12991
Project: Ignite
Issue Type: Improvement
Reporter: Igor Seliverstov
see {{AbstractRelOptPlanner.java:91}}, here {{CancelFlag}} is used to cancel
planning loop. We need to pass it into a newly created context and bind its
state with {{PlanningContext#queryCancel}} to break possible infinite planning
loop. See also {{PlanningContext#unwrap}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12972) Calcite integration. Serialization refactoring
Igor Seliverstov created IGNITE-12972: - Summary: Calcite integration. Serialization refactoring Key: IGNITE-12972 URL: https://issues.apache.org/jira/browse/IGNITE-12972 Project: Ignite Issue Type: Improvement Reporter: Igor Seliverstov Assignee: Igor Seliverstov Currently we need quite a lot of classes to serialize, send and deserialize a prepared plan (in scope of node-to-node communications). It's better to do that by analogy with Calcite's RelJsonReader/RelJsonWriter. This way we may omit necessity to maintain lots of classes preserving functionality. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12909) Calcite integration. Explain command support
Igor Seliverstov created IGNITE-12909: - Summary: Calcite integration. Explain command support Key: IGNITE-12909 URL: https://issues.apache.org/jira/browse/IGNITE-12909 Project: Ignite Issue Type: Task Reporter: Igor Seliverstov Support EXPLAIN command -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12900) Calcite integration. Use RowHandler to access fields.
Igor Seliverstov created IGNITE-12900: - Summary: Calcite integration. Use RowHandler to access fields. Key: IGNITE-12900 URL: https://issues.apache.org/jira/browse/IGNITE-12900 Project: Ignite Issue Type: Task Reporter: Igor Seliverstov Currently only Object[] can be used as a row because most of execution nodes require Object[] as a row type. Let's use generic row types with appropriate RowHandler in execution nodes and compiled expressions to get more flexibility. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12899) Calcite integration. Distribution multitrait
Igor Seliverstov created IGNITE-12899: - Summary: Calcite integration. Distribution multitrait Key: IGNITE-12899 URL: https://issues.apache.org/jira/browse/IGNITE-12899 Project: Ignite Issue Type: Task Reporter: Igor Seliverstov Currently Ignite nodes have single distribution value which isn't true in several cases like: # a partitioned table with a key alias should have 2 distribution traits: by _key and by key alias (id for example) - without distribution by _key column almost impossible to implement IGNITE-12692 # After inner / cross join the result should have several hash distributions (by left and by right keys) - it may be important on join transpose optimization -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12871) Calcite integration. Broadcast to hash conversion without exchange.
Igor Seliverstov created IGNITE-12871: - Summary: Calcite integration. Broadcast to hash conversion without exchange. Key: IGNITE-12871 URL: https://issues.apache.org/jira/browse/IGNITE-12871 Project: Ignite Issue Type: Improvement Reporter: Igor Seliverstov Use a partition filter instead of network communications -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12868) Calcite integration. LEFT, RIGHT join support.
Igor Seliverstov created IGNITE-12868: - Summary: Calcite integration. LEFT, RIGHT join support. Key: IGNITE-12868 URL: https://issues.apache.org/jira/browse/IGNITE-12868 Project: Ignite Issue Type: New Feature Reporter: Igor Seliverstov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12864) Calcite integration. UNION support.
Igor Seliverstov created IGNITE-12864: - Summary: Calcite integration. UNION support. Key: IGNITE-12864 URL: https://issues.apache.org/jira/browse/IGNITE-12864 Project: Ignite Issue Type: New Feature Reporter: Igor Seliverstov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12820) Calcite integration. Do not use AbstarctConverter while planning.
Igor Seliverstov created IGNITE-12820: - Summary: Calcite integration. Do not use AbstarctConverter while planning. Key: IGNITE-12820 URL: https://issues.apache.org/jira/browse/IGNITE-12820 Project: Ignite Issue Type: Improvement Reporter: Igor Seliverstov We need to change traits explicitly without AbstractConverter's and appropriate rules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12819) Calcite integration. Cost system.
Igor Seliverstov created IGNITE-12819: - Summary: Calcite integration. Cost system. Key: IGNITE-12819 URL: https://issues.apache.org/jira/browse/IGNITE-12819 Project: Ignite Issue Type: Task Reporter: Igor Seliverstov Current implementation doesn't suit our needs for particular reasons. We need to introduce our own one taking into account such parameters as IO operations, memory usage, CPU usage, disk usage etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12792) Calcite integration. Update Calcite version to 1.22.0
Igor Seliverstov created IGNITE-12792: - Summary: Calcite integration. Update Calcite version to 1.22.0 Key: IGNITE-12792 URL: https://issues.apache.org/jira/browse/IGNITE-12792 Project: Ignite Issue Type: Improvement Reporter: Igor Seliverstov Assignee: Igor Seliverstov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12776) Calcite integration. An exception occurred when a replicated cache is used in a query.
Igor Seliverstov created IGNITE-12776: - Summary: Calcite integration. An exception occurred when a replicated cache is used in a query. Key: IGNITE-12776 URL: https://issues.apache.org/jira/browse/IGNITE-12776 Project: Ignite Issue Type: Bug Reporter: Igor Seliverstov Assignee: Igor Seliverstov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12747) Calcite integration. Correlated queries support.
Igor Seliverstov created IGNITE-12747: - Summary: Calcite integration. Correlated queries support. Key: IGNITE-12747 URL: https://issues.apache.org/jira/browse/IGNITE-12747 Project: Ignite Issue Type: New Feature Reporter: Igor Seliverstov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12708) Calcite integration. Expressions factory base implementation.
Igor Seliverstov created IGNITE-12708: - Summary: Calcite integration. Expressions factory base implementation. Key: IGNITE-12708 URL: https://issues.apache.org/jira/browse/IGNITE-12708 Project: Ignite Issue Type: New Feature Components: sql Reporter: Igor Seliverstov Assignee: Igor Seliverstov We need to implement basic environment for expressions evaluation. Expressions should exist in two types - compiled and interpreted. Expressions should be compiled in dedicated thread pull and eventually replace interpreted ones. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12700) Calcite integration. Aggregates support.
Igor Seliverstov created IGNITE-12700: - Summary: Calcite integration. Aggregates support. Key: IGNITE-12700 URL: https://issues.apache.org/jira/browse/IGNITE-12700 Project: Ignite Issue Type: New Feature Components: sql Reporter: Igor Seliverstov Assignee: Igor Seliverstov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12695) Calcite integration. DML support. MERGE support
Igor Seliverstov created IGNITE-12695: - Summary: Calcite integration. DML support. MERGE support Key: IGNITE-12695 URL: https://issues.apache.org/jira/browse/IGNITE-12695 Project: Ignite Issue Type: New Feature Reporter: Igor Seliverstov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12692) Calcite integration. DML. Skip reducer optimization.
Igor Seliverstov created IGNITE-12692: - Summary: Calcite integration. DML. Skip reducer optimization. Key: IGNITE-12692 URL: https://issues.apache.org/jira/browse/IGNITE-12692 Project: Ignite Issue Type: Improvement Reporter: Igor Seliverstov Having plan tree we easily can check whether a final modification may be executed on data nodes directly or not. We should implement such kind of optimization. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12639) Calcite integration. DML support.
Igor Seliverstov created IGNITE-12639: - Summary: Calcite integration. DML support. Key: IGNITE-12639 URL: https://issues.apache.org/jira/browse/IGNITE-12639 Project: Ignite Issue Type: New Feature Reporter: Igor Seliverstov Assignee: Igor Seliverstov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12633) Calcite integration. Query cancel purpose.
Igor Seliverstov created IGNITE-12633: - Summary: Calcite integration. Query cancel purpose. Key: IGNITE-12633 URL: https://issues.apache.org/jira/browse/IGNITE-12633 Project: Ignite Issue Type: Improvement Components: sql Reporter: Igor Seliverstov Currently on a query participant node left whole query is cancelled, but the end user doesn't know the purpose. We should pass causing cancel exception to end user. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12620) Calcite integration. Index Nested Loop Join/Hash Join
Igor Seliverstov created IGNITE-12620: - Summary: Calcite integration. Index Nested Loop Join/Hash Join Key: IGNITE-12620 URL: https://issues.apache.org/jira/browse/IGNITE-12620 Project: Ignite Issue Type: New Feature Reporter: Igor Seliverstov We may implement the feature the next way: # For each row from left node consume whole dataset from right node # Pass join condition as an argument of request() method of the right node # In case a data source at right is an index scan ## If there is no cursor opened - create a new cursor using bounds from request ## If there is an existing cursor - just check the cursor was opened using the same condition as passed one. ## After the right node signals EOD consume a next row from left and repeat from p 2. # In case a data source at right is a table scan with huge amount of rows ## If there is no cursor opened - create a new cursor ignoring passed condition ## If there is an existing cursor - just check the cursor was opened using the same condition as passed one. ## After the right node signals EOD consume a next row from left and repeat from p 2. # In case a data source at right is remote / is a table scan with small number of rows/ is a filter node with good enough selectivity ## Create a hash index for a data source ## If there is no cursor opened - create a new cursor using bounds from request ## If there is an existing cursor - just check the cursor was opened using the same condition as passed one. ## After the right node signals EOD consume a next row from left and repeat from p 2. Consider implementation specifics at optimization time, choose the cheapest variant -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12602) Calcite integration. JDBC Thin driver support.
Igor Seliverstov created IGNITE-12602: - Summary: Calcite integration. JDBC Thin driver support. Key: IGNITE-12602 URL: https://issues.apache.org/jira/browse/IGNITE-12602 Project: Ignite Issue Type: Task Reporter: Igor Seliverstov Provide a way to use experimental engine via JDBC thin driver. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12592) Calcite integration. Query load balancing.
Igor Seliverstov created IGNITE-12592:
-
Summary: Calcite integration. Query load balancing.
Key: IGNITE-12592
URL: https://issues.apache.org/jira/browse/IGNITE-12592
Project: Ignite
Issue Type: Task
Reporter: Igor Seliverstov
Currently all query tasks execute in a query pool. The pool contains a limited
number of threads, so, in case of long running scan operation other query tasks
will starve.
We need to limit time a thread spends inside {{ScanNode#requestInternal
method}}.
See appropriate TODO
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12586) Calcite integration. NodesMapping simplification.
Igor Seliverstov created IGNITE-12586:
-
Summary: Calcite integration. NodesMapping simplification.
Key: IGNITE-12586
URL: https://issues.apache.org/jira/browse/IGNITE-12586
Project: Ignite
Issue Type: Improvement
Reporter: Igor Seliverstov
Seems turning {{List assignments}} to {{Map
assignments}} may significantly reduce occupied memory.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12585) Calcite integration. Splitter improvements.
Igor Seliverstov created IGNITE-12585: - Summary: Calcite integration. Splitter improvements. Key: IGNITE-12585 URL: https://issues.apache.org/jira/browse/IGNITE-12585 Project: Ignite Issue Type: Improvement Reporter: Igor Seliverstov Currently in case a head fragment of a query plan have broadcast distribution it causes OptimisticPlanningException and additional fragment split each time it's mapped on topology on a client node. Seems it's quite usual case, so, we should cover it properly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12566) Calcite integration. Expressions evaluation.
Igor Seliverstov created IGNITE-12566: - Summary: Calcite integration. Expressions evaluation. Key: IGNITE-12566 URL: https://issues.apache.org/jira/browse/IGNITE-12566 Project: Ignite Issue Type: Task Reporter: Igor Seliverstov Currently we use a part of Calcite "Bindables" to evaluate expressions at the execution time. Using it we * lose a control on how expressions are evaluated * cannot implement several important optimizations, like "keepBinary" * can use only Object[] as a row, which causes a lot of array copy operations and unnecessary allocations at the execution time * suffer from delays, which go from expressions compilation process when it's more efficient to start from interpretation and compile an expression on repeatable execution only We need to implement expressions interpreter and our own expression compiler taking Ignite specifics in consideration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12564) Calcite integration. Exceptions handling.
Igor Seliverstov created IGNITE-12564: - Summary: Calcite integration. Exceptions handling. Key: IGNITE-12564 URL: https://issues.apache.org/jira/browse/IGNITE-12564 Project: Ignite Issue Type: Task Reporter: Igor Seliverstov There are several exceptions types that may be thrown at * parsing and validation time * planning time * mapping time * execution time All of them should be handled properly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12563) Calcite integration. Reset and remap queries on topology change.
Igor Seliverstov created IGNITE-12563: - Summary: Calcite integration. Reset and remap queries on topology change. Key: IGNITE-12563 URL: https://issues.apache.org/jira/browse/IGNITE-12563 Project: Ignite Issue Type: Task Components: sql Reporter: Igor Seliverstov A query should: * be silently remapped in case an actual topology version at query plan materialization time differs from a topology version at the time locations was calculated * be cancelled with appropriate exception in case one of responsible nodes left a cluster after execution is started. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12455) Calcite integration. Partition pruning.
Igor Seliverstov created IGNITE-12455: - Summary: Calcite integration. Partition pruning. Key: IGNITE-12455 URL: https://issues.apache.org/jira/browse/IGNITE-12455 Project: Ignite Issue Type: Improvement Reporter: Igor Seliverstov In scope of fragment info calculation we're able to prune partitions on the basis of filter condition, query parameters, affinity and tables distribution. This optimization may dramatically reduce query execution time/needed resources. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12449) Calcite integration. Execution flow.
Igor Seliverstov created IGNITE-12449: - Summary: Calcite integration. Execution flow. Key: IGNITE-12449 URL: https://issues.apache.org/jira/browse/IGNITE-12449 Project: Ignite Issue Type: Task Reporter: Igor Seliverstov We need to introduce query execution environment. Execution should: * use streaming approach * have suspend/resume ability * work in event loop threads -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12448) Calcite integration. Communication protocol.
Igor Seliverstov created IGNITE-12448: - Summary: Calcite integration. Communication protocol. Key: IGNITE-12448 URL: https://issues.apache.org/jira/browse/IGNITE-12448 Project: Ignite Issue Type: Task Components: sql Reporter: Igor Seliverstov We need to introduce a communication protocol between query fragments in scope of query execution. * Protocol should have Push semantics with back pressure ability * Protocol have to provide ordering guaranties - the data batches processed in same order they sent to remote node. * Protocol have to provide delivery guaranties. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12446) Calcite integration. Fix javadocs and code style.
Igor Seliverstov created IGNITE-12446: - Summary: Calcite integration. Fix javadocs and code style. Key: IGNITE-12446 URL: https://issues.apache.org/jira/browse/IGNITE-12446 Project: Ignite Issue Type: Task Components: sql Reporter: Igor Seliverstov Assignee: Igor Seliverstov Fix javadocs and code style -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12251) Calcite exchange rules
Igor Seliverstov created IGNITE-12251: - Summary: Calcite exchange rules Key: IGNITE-12251 URL: https://issues.apache.org/jira/browse/IGNITE-12251 Project: Ignite Issue Type: Task Components: sql Reporter: Igor Seliverstov Assignee: Igor Seliverstov Need to implement IgniteDistributionTraitDef and utility methods (to calculate distribution trait for each node type based on its position, type and children nodes) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12248) Apache Calcite based query execution engine
Igor Seliverstov created IGNITE-12248: - Summary: Apache Calcite based query execution engine Key: IGNITE-12248 URL: https://issues.apache.org/jira/browse/IGNITE-12248 Project: Ignite Issue Type: Task Components: sql Reporter: Igor Seliverstov Assignee: Igor Seliverstov Currently used H2 based query execution engine has a number of critical limitations Which do not allow to execute an arbitrary query. The ticket aims to show potential of a new, Calcite based, execution engine which may act not worse than current one on co-located queries, provide a boost for queries, using distributed joins, and provide an ability to execute arbitrary queries, requiring more than one map-reduce step in execution flow. [IEP link|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=130028084] [Dev list thread|http://apache-ignite-developers.2346864.n4.nabble.com/New-SQL-execution-engine-td43724.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-11433) MVCC: Link entry versions at the Data Store layer.
Igor Seliverstov created IGNITE-11433: - Summary: MVCC: Link entry versions at the Data Store layer. Key: IGNITE-11433 URL: https://issues.apache.org/jira/browse/IGNITE-11433 Project: Ignite Issue Type: Improvement Components: mvcc, sql Reporter: Igor Seliverstov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11238) Possible hang on exchange
Igor Seliverstov created IGNITE-11238:
-
Summary: Possible hang on exchange
Key: IGNITE-11238
URL: https://issues.apache.org/jira/browse/IGNITE-11238
Project: Ignite
Issue Type: Bug
Components: general
Reporter: Igor Seliverstov
Currently we may hang on exchange for a while (two network timeouts) waiting
for release a latch (see {{GridDhtPartitionsExchangeFuture#waitPartitionRelease
releaseLatch}}) in case a processing topology version has not been added to
discovery history yet but client acknowledge already received by coordinator:
{code:java}
[2019-02-06
17:43:17,009][ERROR][sys-#43%mvcc.CacheMvccPartitionedSqlCoordinatorFailoverTest0%][ExchangeLatchManager]
Topology AffinityTopologyVersion [topVer=24, minorTopVer=0] not found in
discovery history ; consider increasing IGNITE_DISCOVERY_HISTORY_SIZE property.
Current value is -1
class org.apache.ignite.IgniteException: Topology AffinityTopologyVersion
[topVer=24, minorTopVer=0] not found in discovery history ; consider increasing
IGNITE_DISCOVERY_HISTORY_SIZE property. Current value is -1
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.ExchangeLatchManager.aliveNodesForTopologyVer(ExchangeLatchManager.java:260)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.ExchangeLatchManager.getLatchCoordinator(ExchangeLatchManager.java:302)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.ExchangeLatchManager.processAck(ExchangeLatchManager.java:351)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.ExchangeLatchManager.lambda$new$0(ExchangeLatchManager.java:121)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1561)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1189)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
at
org.apache.ignite.internal.managers.communication.GridIoManager$8.run(GridIoManager.java:1086)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
This way the received ack won't be processed, so, we will be waiting for retry:
{code:java}
// Try to resend ack.
releaseLatch.countDown();
{code}
To solve the issue we need to test whether the version is present in discovery
history and put it into a pending map if i isn't so (see
{{ExchangeLatchManager#pendingAcks}})
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11173) MVCC TX: Acquire write version if coordinator changed in the middle of tx.
Igor Seliverstov created IGNITE-11173: - Summary: MVCC TX: Acquire write version if coordinator changed in the middle of tx. Key: IGNITE-11173 URL: https://issues.apache.org/jira/browse/IGNITE-11173 Project: Ignite Issue Type: New Feature Components: mvcc Reporter: Igor Seliverstov Current implementation suppose all transactions on previous coordinator were finished before new coordinator has been initialized, but there is a case when it isn't true. A tx which hasn't obtained a topology lock (hasn't done any updates) doesn't prevent a topology change, this way nothing prevent new transactions start. All newly created txs suppose all updates on previous coordinator are finished - this mean a possible update of mapped on previous coordinator txs is considered as stale regardless the tx is still active. We make such txs readonly to not break the visibility checking logic (see IGNITE-8841). There are two possible ways to allow writes after coordinator is changed: * collect active txs and their dependencies and populate the active txs list with them during a new coordinator initialization - this approach is quite complex and have obvious issues like necessity of using full tx versions in a snapshot * acquire a new version right after topology locked for writes using previously acquired "read" version for possible write conflicts detecting and visibility checking. I would prefer the second option as fully understandable and relatively easy to implement. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11121) MVCC TX: AssertionError in discovery manager on BLT change.
Igor Seliverstov created IGNITE-11121:
-
Summary: MVCC TX: AssertionError in discovery manager on BLT
change.
Key: IGNITE-11121
URL: https://issues.apache.org/jira/browse/IGNITE-11121
Project: Ignite
Issue Type: Bug
Reporter: Igor Seliverstov
Fix For: 2.8
The next exception occurred in logs on BLT change.
{noformat}
[12:11:36,912][SEVERE][sys-#87][GridClosureProcessor] Closure execution failed
with error.
java.lang.AssertionError
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.node(GridDiscoveryManager.java:1794)
at
org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1693)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$NodeFailureTimeoutObject.lambda$onTimeout0$16553d7$1(IgniteTxManager.java:2592)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:354)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$NodeFailureTimeoutObject.onTimeout0(IgniteTxManager.java:2588)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$NodeFailureTimeoutObject.access$3300(IgniteTxManager.java:2505)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$NodeFailureTimeoutObject$1.run(IgniteTxManager.java:2623)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6874)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
>From the stack trace I see there is a node failure which causes transactions
>recovery and uninitialized Mvcc coordinator (it means there are no server
>nodes, or there is a coordinatorAssignClosure which returns no result, or a
>recovering node was not activated)
the scenario, where the exception may be observed:
* Start a cluster
* Load some data (from client node, the client node is shut down after that)
* Calculate hash
* Add new server node
* Change BLT
* Wait for rebalance
* Calculate new hash and check it is the same as previously calculated
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11068) MVCC TX: Do not create TxLog and do not start vacuum workers in case there are no MVCC caches on the node.
Igor Seliverstov created IGNITE-11068: - Summary: MVCC TX: Do not create TxLog and do not start vacuum workers in case there are no MVCC caches on the node. Key: IGNITE-11068 URL: https://issues.apache.org/jira/browse/IGNITE-11068 Project: Ignite Issue Type: Improvement Reporter: Igor Seliverstov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10956) MVCC TX: Move queryEnlisted flag from IgniteTxLocalAdapter to IgniteTxState
Igor Seliverstov created IGNITE-10956: - Summary: MVCC TX: Move queryEnlisted flag from IgniteTxLocalAdapter to IgniteTxState Key: IGNITE-10956 URL: https://issues.apache.org/jira/browse/IGNITE-10956 Project: Ignite Issue Type: Improvement Components: mvcc Reporter: Igor Seliverstov queryEnlisted flag represents a transaction state (like txState.empty(), in other words shows whether there were some updates on MVCC caches or not). It makes sense to move such flag to IgniteTxState. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10829) MVCC TX: Lazy query execution for query enlists.
Igor Seliverstov created IGNITE-10829: - Summary: MVCC TX: Lazy query execution for query enlists. Key: IGNITE-10829 URL: https://issues.apache.org/jira/browse/IGNITE-10829 Project: Ignite Issue Type: Improvement Components: mvcc Affects Versions: 2.7 Reporter: Igor Seliverstov Fix For: 2.8 Implement lazy query execution using semantic goes from IGNITE-9171. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10730) MVCC TX: Batch WAL datarecords
Igor Seliverstov created IGNITE-10730: - Summary: MVCC TX: Batch WAL datarecords Key: IGNITE-10730 URL: https://issues.apache.org/jira/browse/IGNITE-10730 Project: Ignite Issue Type: Improvement Components: mvcc Reporter: Igor Seliverstov on MVCC updates we make changes one by one and WAL records are written straight after successful update under the same checkpoint lock. This produces contention on wal flush operations and harm overall performance. But we need only one guarantee - all the records have to be written into the log before prepare start. That means we free to batch such writes (for example 10 rows in one data record) it shouldn't cause memory issues but will resolve contention. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10729) MVCC TX: Improvements.
Igor Seliverstov created IGNITE-10729: - Summary: MVCC TX: Improvements. Key: IGNITE-10729 URL: https://issues.apache.org/jira/browse/IGNITE-10729 Project: Ignite Issue Type: Improvement Components: mvcc Reporter: Igor Seliverstov Currently there are several problems: 1) vacuum doesn't have change set, this means it travers all data to find invisible entries; hanse it breaks read statistics and make all data set "hot" - we should travers data entries instead, and only those entries, which was updated (linked to newer versions), moreover, vacuum should travers only those data pages, which were updated after last successful vacuum (at least one entry on the data page was linked to a never one) 2) vacuum travers over partitions instead of data entries, so, there possible some races like: reader checks an entry; updater removes this entry from partition; vacuum doesn't see the entry and clean TxLog -> reader cannot check the entry state with TxLog and gets an exception. This race prevents an optimization when all entries, older than last successful vacuum version, are considered as COMMITTED (see previous suggestion) 3) all entry versions are placed in BTrees, so, we cannot do updates like PG - just adding a new version and linking the old one to it. Having only one unversioned item per row in all indexes making possible fast invoke operations on such indexes in MVCC mode. Also it let us not to update all indexes on each update operation (partition index isn't updated at all, only SQL indexes, built over changed fields need to be updated) - this dramatically reduces write operations, hence it reduces amount of pages to be "checkpointed" and reduces checkpoint mark phase. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10714) MVCC TX: JTA transaction manager.
Igor Seliverstov created IGNITE-10714: - Summary: MVCC TX: JTA transaction manager. Key: IGNITE-10714 URL: https://issues.apache.org/jira/browse/IGNITE-10714 Project: Ignite Issue Type: Bug Reporter: Igor Seliverstov Add JTA transactions support for MVCC transactions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10693) MVCC TX: Random server restart tests became failed
Igor Seliverstov created IGNITE-10693: - Summary: MVCC TX: Random server restart tests became failed Key: IGNITE-10693 URL: https://issues.apache.org/jira/browse/IGNITE-10693 Project: Ignite Issue Type: Bug Components: mvcc, sql Reporter: Igor Seliverstov Fix For: 2.8 [one|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=254244004184327163=%3Cdefault%3E=testDetails], [two|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=8412476034648229784=%3Cdefault%3E=testDetails], [three|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=254244004184327163=%3Cdefault%3E=testDetails], all these tests became failed after IGNITE-9630 has been merged to master. Seems there is an issue in partition calculating mechanism on unstable topology. I suppose the algorithm uses partitions on nodes just become primary while the partitions are in moving state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10597) MVCC TX: Organize used thread pools
Igor Seliverstov created IGNITE-10597: - Summary: MVCC TX: Organize used thread pools Key: IGNITE-10597 URL: https://issues.apache.org/jira/browse/IGNITE-10597 Project: Ignite Issue Type: Bug Components: mvcc Reporter: Igor Seliverstov Fix For: 2.8 All mvcc operations use cache pool, this means striped pool is used under hood that may lead performance issues in case of long operations (like query update). we need: 1) use query pool for query updates 2) use random stripe for batched updates 3) use appropriate stripe for single updates. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10576) MVCC TX: Rework UpdateSourceIterator to mix operation types
Igor Seliverstov created IGNITE-10576: - Summary: MVCC TX: Rework UpdateSourceIterator to mix operation types Key: IGNITE-10576 URL: https://issues.apache.org/jira/browse/IGNITE-10576 Project: Ignite Issue Type: Bug Components: mvcc Reporter: Igor Seliverstov Assignee: Andrew Mashenkov Current the UpdateSourceIterator implementation doesn't suit Cache API needs. It should be able to mix operation types per key. For example we may execute putAll operation with a half of keys are having values and a half aren't, this way we should mix DELETE operation for null-value keys and PUT operation for others. Another use case is a transform operation which should turn into a number of PUT/UPDATE/DELETE operations on a backup node. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10572) MVCC TX: Possible race on invokeAll operations
Igor Seliverstov created IGNITE-10572:
-
Summary: MVCC TX: Possible race on invokeAll operations
Key: IGNITE-10572
URL: https://issues.apache.org/jira/browse/IGNITE-10572
Project: Ignite
Issue Type: Bug
Components: mvcc
Reporter: Igor Seliverstov
Assignee: Andrew Mashenkov
see {{GridNearTxEnlistFuture#checkResponse}} method.
1) race on result creation - two threads may see {{this.res == null}} and just
set their values, result is partially lost
2) race on success flag set - just set false flag may be overwritten by
concurrent successful response checking operation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10559) MVCC TX: Use extracted partitions to reduce target nodes for Query Update
Igor Seliverstov created IGNITE-10559: - Summary: MVCC TX: Use extracted partitions to reduce target nodes for Query Update Key: IGNITE-10559 URL: https://issues.apache.org/jira/browse/IGNITE-10559 Project: Ignite Issue Type: Task Components: mvcc Reporter: Igor Seliverstov We may avoid "query reduce" step on update queries without sorting/grouping by simply sending them to all data nodes and executing update operation locally. Using extracted from SQL partitions will reduce target nodes count and save resources. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10468) MVCC TX: Failover
Igor Seliverstov created IGNITE-10468: - Summary: MVCC TX: Failover Key: IGNITE-10468 URL: https://issues.apache.org/jira/browse/IGNITE-10468 Project: Ignite Issue Type: Task Reporter: Igor Seliverstov There is several problems in mvcc failover scenarios. The task is an umbrella ticket for currently known issues. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10457) MVCC TX: GridIndexRebuildWithMvccEnabledSelfTest fails
Igor Seliverstov created IGNITE-10457:
-
Summary: MVCC TX: GridIndexRebuildWithMvccEnabledSelfTest fails
Key: IGNITE-10457
URL: https://issues.apache.org/jira/browse/IGNITE-10457
Project: Ignite
Issue Type: Bug
Components: mvcc, sql
Reporter: Igor Seliverstov
Fix For: 2.8
See the log below:
{noformat}
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Runtime failure on bounds: [lower=MvccMaxSearchRow [], upper=MvccMinSearchRow
[]]
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1756)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1108)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:820)
at
org.apache.ignite.internal.processors.query.h2.GridIndexRebuildSelfTest.putData(GridIndexRebuildSelfTest.java:191)
at
org.apache.ignite.internal.processors.query.h2.GridIndexRebuildWithMvccEnabledSelfTest.testIndexRebuild(GridIndexRebuildWithMvccEnabledSelfTest.java:76)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$001(GridAbstractTest.java:150)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.evaluate(GridAbstractTest.java:2104)
at
org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2119)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.IgniteCheckedException: Runtime failure on
bounds: [lower=MvccMaxSearchRow [], upper=MvccMinSearchRow []]
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.visit(BPlusTree.java:1061)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:1968)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.mvccUpdate(GridCacheOffheapManager.java:2032)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:543)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.mvccSet(GridCacheMapEntry.java:1142)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.continueLoop(GridDhtTxAbstractEnlistFuture.java:463)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.init(GridDhtTxAbstractEnlistFuture.java:363)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistFuture.enlistLocal(GridNearTxEnlistFuture.java:525)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistFuture.sendBatch(GridNearTxEnlistFuture.java:420)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistFuture.sendNextBatches(GridNearTxEnlistFuture.java:167)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistFuture.map(GridNearTxEnlistFuture.java:143)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxAbstractEnlistFuture.mapOnTopology(GridNearTxAbstractEnlistFuture.java:331)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxAbstractEnlistFuture.init(GridNearTxAbstractEnlistFuture.java:246)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.updateAsync(GridNearTxLocal.java:2076)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.mvccPutAllAsync0(GridNearTxLocal.java:785)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAsync0(GridNearTxLocal.java:580)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAsync(GridNearTxLocal.java:446)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter$22.op(GridCacheAdapter.java:2522)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter$22.op(GridCacheAdapter.java:2520)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4284)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put0(GridCacheAdapter.java:2520)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2501)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2478)
at
[jira] [Created] (IGNITE-10378) MVCC TX: Possible race on MVCC coordinator reassignment
Igor Seliverstov created IGNITE-10378: - Summary: MVCC TX: Possible race on MVCC coordinator reassignment Key: IGNITE-10378 URL: https://issues.apache.org/jira/browse/IGNITE-10378 Project: Ignite Issue Type: Bug Components: mvcc Environment: We need to add an additional check to finish MVCC coordinator init future on particular exchange done only. Reporter: Igor Seliverstov Fix For: 2.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10322) MVCC TX: Clean out messages.
Igor Seliverstov created IGNITE-10322: - Summary: MVCC TX: Clean out messages. Key: IGNITE-10322 URL: https://issues.apache.org/jira/browse/IGNITE-10322 Project: Ignite Issue Type: Improvement Components: mvcc Reporter: Igor Seliverstov Fix For: 2.8 Currently MvccSnapshot is a part of many message types and some of usages look unnecessary. Since MvccSnapshot potentially can be really long (in bytes) we need to review and possibly optimize all places where MvccSnapshot is a message part. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10276) MVCC TX: Optimize logger creations
Igor Seliverstov created IGNITE-10276: - Summary: MVCC TX: Optimize logger creations Key: IGNITE-10276 URL: https://issues.apache.org/jira/browse/IGNITE-10276 Project: Ignite Issue Type: Improvement Components: mvcc Reporter: Igor Seliverstov Fix For: 2.8 We need to initialize loggers in all new classes like it was done in *GridDhtAtomicAbstractUpdateFuture* for example. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10248) MVCC TX: remove redundant partition checking from GridDhtTxAbstractEnlistFuture
Igor Seliverstov created IGNITE-10248:
-
Summary: MVCC TX: remove redundant partition checking from
GridDhtTxAbstractEnlistFuture
Key: IGNITE-10248
URL: https://issues.apache.org/jira/browse/IGNITE-10248
Project: Ignite
Issue Type: Improvement
Components: mvcc
Reporter: Igor Seliverstov
Fix For: 2.8
We need to ensure that on unstable topology all queries (even those that
doesn't require reducer) should execute with reducer (which support execution
on unstable topology)
All verifications should be done inside
{{*IgniteH2Indexing#prepareDistributedUpdate*}} method
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10241) MVCC TX: orphaned remote transactions
Igor Seliverstov created IGNITE-10241:
-
Summary: MVCC TX: orphaned remote transactions
Key: IGNITE-10241
URL: https://issues.apache.org/jira/browse/IGNITE-10241
Project: Ignite
Issue Type: Bug
Components: mvcc
Reporter: Igor Seliverstov
Fix For: 2.8
test occasionally fails with following error:
{code:java}
[2018-11-13
15:03:44,240][ERROR][sys-#19392%mvcc.CacheMvccPartitionedSqlCoordinatorFailoverTest0%][GridDhtPartitionsExchangeFuture]
Failed to notify listener:
o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2@22ae2fbd
java.lang.ClassCastException:
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxRemote
cannot be cast to
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.rollbackMvccTxOnCoordinatorChange(IgniteTxManager.java:327)
at
org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onExchangeDone(MvccProcessorImpl.java:394)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:2095)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:3391)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:3157)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2773)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:139)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2578)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2566)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:395)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:355)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:2566)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1747)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1200(GridCachePartitionExchangeManager.java:144)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:377)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:335)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:3194)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:3173)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:100)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:294)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1568)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1196)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1092)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
Seems there is an issue with committing/rolling back transactions on topology
changes because we expect all transactions
[jira] [Created] (IGNITE-10131) Wrong processing of loaded from store keys on backup nodes.
Igor Seliverstov created IGNITE-10131:
-
Summary: Wrong processing of loaded from store keys on backup
nodes.
Key: IGNITE-10131
URL: https://issues.apache.org/jira/browse/IGNITE-10131
Project: Ignite
Issue Type: Bug
Components: cache
Reporter: Igor Seliverstov
In scope of IGNITE-7086 was added a closure, which puts a key value pair in
case the node is a local backup and readThrough is enabled and the key is
absent on the node (in other words the key was read from store on a primary
node).
Currently this closure post-processes each call even in case 3rd party
persistence store is disabled for the cache because readThrough flag is
obtained by inversion of skipStore flag of operation context (which is false by
default).
see {{CU.createBackupPostProcessingClosure(..)}} for details
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10129) MVCC TX: do not log Vacuum warnings if mvcc is not enabled
Igor Seliverstov created IGNITE-10129:
-
Summary: MVCC TX: do not log Vacuum warnings if mvcc is not enabled
Key: IGNITE-10129
URL: https://issues.apache.org/jira/browse/IGNITE-10129
Project: Ignite
Issue Type: Bug
Components: mvcc
Reporter: Igor Seliverstov
Fix For: 2.7
currently we can see warnings like :
{{[10:18:48,741][INFO][exchange-worker-#64][MvccProcessorImpl] Attempting to
stop inactive vacuum.}} on node stop.
Such warnings should not appear in case MVCC is disabled (there is no MVCC
caches).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10109) MVCC TX: data become inconsistent after several updates
Igor Seliverstov created IGNITE-10109: - Summary: MVCC TX: data become inconsistent after several updates Key: IGNITE-10109 URL: https://issues.apache.org/jira/browse/IGNITE-10109 Project: Ignite Issue Type: Bug Components: mvcc Reporter: Igor Seliverstov Assignee: Igor Seliverstov Fix For: 2.7 see [TC test history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4365543959682167276=testDetails] Here we do concurrent updates on several accounts (update their balances incrementing one and decrementing another), we expect consistent sum of all accounts at any time. The sum become inconsistent after while. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10104) MVCC TX: client SFU doesn't work on replicated caches
Igor Seliverstov created IGNITE-10104:
-
Summary: MVCC TX: client SFU doesn't work on replicated caches
Key: IGNITE-10104
URL: https://issues.apache.org/jira/browse/IGNITE-10104
Project: Ignite
Issue Type: Bug
Components: mvcc, sql
Reporter: Igor Seliverstov
Fix For: 2.8
When select for update executes from client node the execution is sent to
random owning node. On that node dht enlist operation is started what causes an
assertion error because dht enlist operation implies that the node is primary
for all processed keys.
see {{CacheMvccReplicatedBackupsTest.testBackupsCoherenceWithLargeOperations}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10082) MVCC TX: Partition sizes become inconsistent after rebalance.
Igor Seliverstov created IGNITE-10082: - Summary: MVCC TX: Partition sizes become inconsistent after rebalance. Key: IGNITE-10082 URL: https://issues.apache.org/jira/browse/IGNITE-10082 Project: Ignite Issue Type: Bug Components: cache, mvcc Reporter: Igor Seliverstov Fix For: 2.8 While rebalance partition size increments on each put operation; since several versions of one key may be rebalanced, partition sizes become inconsistent after rebalance finished. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9985) MVCC TX: fix backup mappings
Igor Seliverstov created IGNITE-9985: Summary: MVCC TX: fix backup mappings Key: IGNITE-9985 URL: https://issues.apache.org/jira/browse/IGNITE-9985 Project: Ignite Issue Type: Task Components: mvcc Reporter: Igor Seliverstov Assignee: Igor Seliverstov Fix mappings to update going to be evicted partitions as well to maintain consistency during rebalance -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9911) CacheMvccSelectForUpdateQueryAbstractTest#testSelectForUpdateAfterAbortedTx periodically hangs
Igor Seliverstov created IGNITE-9911: Summary: CacheMvccSelectForUpdateQueryAbstractTest#testSelectForUpdateAfterAbortedTx periodically hangs Key: IGNITE-9911 URL: https://issues.apache.org/jira/browse/IGNITE-9911 Project: Ignite Issue Type: Task Components: mvcc Reporter: Igor Seliverstov Assignee: Igor Seliverstov Fix For: 2.7 See [TC history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=7394250566319069846=testDetails] for details -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9538) MVCC TX: Send partition update counters to backup nodes on prepare state.
Igor Seliverstov created IGNITE-9538: Summary: MVCC TX: Send partition update counters to backup nodes on prepare state. Key: IGNITE-9538 URL: https://issues.apache.org/jira/browse/IGNITE-9538 Project: Ignite Issue Type: Task Components: cache, mvcc Reporter: Igor Seliverstov Assignee: Igor Seliverstov Fix For: 2.7 There are several issues with partition update counters consistency in transactional caches. The next approach solves most of them: # Count per-partition updates # on prepare state on primary node update current partition counter incrementing it by per-partition updates count and send initial value with updates count to backup nodes # on backup nodes hold all pending updates and update partition update counter applying the lowest gapless update (on tx finish). # on historical rebalance use partition update counter as start point. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9489) CorruptedTreeException on index create.
Igor Seliverstov created IGNITE-9489:
Summary: CorruptedTreeException on index create.
Key: IGNITE-9489
URL: https://issues.apache.org/jira/browse/IGNITE-9489
Project: Ignite
Issue Type: Bug
Components: cache, sql
Affects Versions: 2.6, 2.5, 2.4
Reporter: Igor Seliverstov
Attachments: Test.java
Currently on dynamic index drop with enabled persistence H2TreeIndex instances
aren't destroyed. That means that their root pages aren't removed from meta
tree (see
{{org.apache.ignite.internal.processors.cache.persistence.IndexStorageImpl#getOrAllocateForTree}})
and reused on subsequent dynamic index create that leads
CorruptedTreeException on initial index rebuild because there are some items
with broken links on the root page.
Reproducer attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9483) JDBC/ODBC thin drivers protocol versions compatibility
Igor Seliverstov created IGNITE-9483:
Summary: JDBC/ODBC thin drivers protocol versions compatibility
Key: IGNITE-9483
URL: https://issues.apache.org/jira/browse/IGNITE-9483
Project: Ignite
Issue Type: Bug
Components: mvcc
Affects Versions: 2.7
Reporter: Igor Seliverstov
Fix For: 2.7
Initially MVCC feature was aimed to 2.5 version but cannot be released earlier
than in scope of 2.7
There are several protocol versions checks that do their stuff for 2.5.0
version instead of 2.7.0 (for example:
{{JdbcConnectionContext#initializeFromHandshake}})
Need to identify such places and fix them.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9314) MVCC TX: Datastreamer operations
Igor Seliverstov created IGNITE-9314: Summary: MVCC TX: Datastreamer operations Key: IGNITE-9314 URL: https://issues.apache.org/jira/browse/IGNITE-9314 Project: Ignite Issue Type: Task Reporter: Igor Seliverstov Need to change DataStreamer semantics (make it transactional) Currently clients can see DataStreamer partial writes and two subsequent selects, which are run in scope of one transaction at load time, may return different results. Related thread: http://apache-ignite-developers.2346864.n4.nabble.com/MVCC-and-IgniteDataStreamer-td32340.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9265) MVCC TX: Two rows with the same key in one MERGE statement produce an exception
Igor Seliverstov created IGNITE-9265:
Summary: MVCC TX: Two rows with the same key in one MERGE
statement produce an exception
Key: IGNITE-9265
URL: https://issues.apache.org/jira/browse/IGNITE-9265
Project: Ignite
Issue Type: Bug
Reporter: Igor Seliverstov
In case the operation like {{MERGE INTO INTEGER (_key, _val) KEY(_key) VALUES
(1,1),(1,2)}} is called an exception is occurred.
Correct behavior: each next update on the same key overwrites pervious one
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8865) SQL Transactions: Set sequential false if update query has no order
Igor Seliverstov created IGNITE-8865: Summary: SQL Transactions: Set sequential false if update query has no order Key: IGNITE-8865 URL: https://issues.apache.org/jira/browse/IGNITE-8865 Project: Ignite Issue Type: Task Reporter: Igor Seliverstov See appropriate TODO in DmlStatementsProcessor -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8692) MVCC TX: Always persistent TxLog
Igor Seliverstov created IGNITE-8692: Summary: MVCC TX: Always persistent TxLog Key: IGNITE-8692 URL: https://issues.apache.org/jira/browse/IGNITE-8692 Project: Ignite Issue Type: Task Components: cache, sql Reporter: Igor Seliverstov Currently TxLog may be overflowed in case a long running Tx prevents "vacuuming". It can be solved by enabling persistence for TxLog data region by default. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8239) SQL TX: Do not use skipReducer flag for MVCC DML requests
Igor Seliverstov created IGNITE-8239: Summary: SQL TX: Do not use skipReducer flag for MVCC DML requests Key: IGNITE-8239 URL: https://issues.apache.org/jira/browse/IGNITE-8239 Project: Ignite Issue Type: Task Reporter: Igor Seliverstov Currently we explicitly set skipReducer flag to true to get UpdatePlan with DmlDistributedPlanInfo. We should check if mvcc is enabled instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8208) SQL TX: Do not check with TxLog rows having the same insert and update versions
Igor Seliverstov created IGNITE-8208: Summary: SQL TX: Do not check with TxLog rows having the same insert and update versions Key: IGNITE-8208 URL: https://issues.apache.org/jira/browse/IGNITE-8208 Project: Ignite Issue Type: Task Reporter: Igor Seliverstov Such rows are invisible for all readers (double-changed in scope of one tx). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8207) SQL TX: Cleanup own previous changes on update
Igor Seliverstov created IGNITE-8207: Summary: SQL TX: Cleanup own previous changes on update Key: IGNITE-8207 URL: https://issues.apache.org/jira/browse/IGNITE-8207 Project: Ignite Issue Type: Task Reporter: Igor Seliverstov During update process we're cleaning up rows, which became invisible for all readers. Updating a row more than once we are free to cleanup previous own changes except last one. This means we shouldn't leave more than two rows per key with version equal to current tx for updates and one for delete operations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8206) SQL TX: Rewrite MvccCursor
Igor Seliverstov created IGNITE-8206: Summary: SQL TX: Rewrite MvccCursor Key: IGNITE-8206 URL: https://issues.apache.org/jira/browse/IGNITE-8206 Project: Ignite Issue Type: Task Reporter: Igor Seliverstov Currently we materialize rows before passing Mvcc filter. It means we deserialize all rows, including invisible for snapshot. We need to pass the filter to BPlusTree.find() method instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8149) MVCC TX Size method should use tx snapshot
Igor Seliverstov created IGNITE-8149: Summary: MVCC TX Size method should use tx snapshot Key: IGNITE-8149 URL: https://issues.apache.org/jira/browse/IGNITE-8149 Project: Ignite Issue Type: Task Components: cache Reporter: Igor Seliverstov Currently cache.size() returns number of entries in cache trees while there can be several versions of one key-value pairs. We should use tx snapshot and count all passed mvcc filter entries instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7991) MVCC TX Crash recovery
Igor Seliverstov created IGNITE-7991: Summary: MVCC TX Crash recovery Key: IGNITE-7991 URL: https://issues.apache.org/jira/browse/IGNITE-7991 Project: Ignite Issue Type: Task Components: cache Reporter: Igor Seliverstov Implement crash recovery for MVCC enabled caches -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7966) MVCC TX Review cache/Ignite configuration for MVCC needs
Igor Seliverstov created IGNITE-7966: Summary: MVCC TX Review cache/Ignite configuration for MVCC needs Key: IGNITE-7966 URL: https://issues.apache.org/jira/browse/IGNITE-7966 Project: Ignite Issue Type: Task Components: cache, sql Reporter: Igor Seliverstov We need to rethink Ignite and Cache configuration to have a control on such parameters as VACUUM frequency, TxLog data-region parameters, whether MVCC enabled or not for particular cache etc. Most of such parameters are hardcoded now. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7792) IgniteDatabaseSharedManager refactoring
Igor Seliverstov created IGNITE-7792:
Summary: IgniteDatabaseSharedManager refactoring
Key: IGNITE-7792
URL: https://issues.apache.org/jira/browse/IGNITE-7792
Project: Ignite
Issue Type: Task
Components: cache
Reporter: Igor Seliverstov
Currently there is no mapping of cacheId to page memory which prevents adding
custom persistent structures
({{GridCacheDatabaseSharedManager.WriteCheckpointPages#run}}).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-7748) MVCC TX Implement TxLog related stuctures
Igor Seliverstov created IGNITE-7748: Summary: MVCC TX Implement TxLog related stuctures Key: IGNITE-7748 URL: https://issues.apache.org/jira/browse/IGNITE-7748 Project: Ignite Issue Type: Task Components: cache Reporter: Igor Seliverstov Assignee: Igor Seliverstov Create TxLog on the basis of BPlusTree. The key is a pair of two long (which correspond to crd version and mvcc cntr of MvccVersion) The value is TxState - an enum. TxState has next possible values : PREPARED, COMMITTED, ABORTED, NA. NA is a special value, which is returned when there is no info about requested TX. TxLog is managed by MvccProcessor and initiated along with MvccProcessor. At the first step there is no special WAL records corresponding to TxLog operation (will be implemented in future. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7604) SQL TX: Allow DML operations with reducer
Igor Seliverstov created IGNITE-7604: Summary: SQL TX: Allow DML operations with reducer Key: IGNITE-7604 URL: https://issues.apache.org/jira/browse/IGNITE-7604 Project: Ignite Issue Type: Task Components: sql Reporter: Igor Seliverstov Allow DML operations with reducer -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7583) SQL TX: Change secondary indexes structure
Igor Seliverstov created IGNITE-7583: Summary: SQL TX: Change secondary indexes structure Key: IGNITE-7583 URL: https://issues.apache.org/jira/browse/IGNITE-7583 Project: Ignite Issue Type: Task Components: sql Reporter: Igor Seliverstov We need to change: * rows with the same key and different versions should be placed in a tree ordered by version decending * move next version from BTree leafs to data rows * filters according to next logic: the row is visible if leaf version is less than assigned and not active and max_version of referenced row is NA or heigher than assigned or active -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7388) MVCC TX Support async tx rollback (e.g. on timeout)
Igor Seliverstov created IGNITE-7388: Summary: MVCC TX Support async tx rollback (e.g. on timeout) Key: IGNITE-7388 URL: https://issues.apache.org/jira/browse/IGNITE-7388 Project: Ignite Issue Type: Bug Reporter: Igor Seliverstov Currently TX timeout isn't taken into consideration while MVCC version is requesting. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7384) MVCC Mvcc versions may be lost in case of rebalanse with persistence enabled
Igor Seliverstov created IGNITE-7384:
Summary: MVCC Mvcc versions may be lost in case of rebalanse with
persistence enabled
Key: IGNITE-7384
URL: https://issues.apache.org/jira/browse/IGNITE-7384
Project: Ignite
Issue Type: Bug
Reporter: Igor Seliverstov
In case a node returns to topology it equests a delta instead of full
partition, WAL-based iterator is used there
({{o.a.i.i.processors.cache.persistence.GridCacheOffheapManager#rebalanceIterator}})
WAL-based iterator doesn't contain MVCC versions which causes issues.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-7371) MVCC TX Repeatable read semantic
Igor Seliverstov created IGNITE-7371: Summary: MVCC TX Repeatable read semantic Key: IGNITE-7371 URL: https://issues.apache.org/jira/browse/IGNITE-7371 Project: Ignite Issue Type: New Feature Components: cache Reporter: Igor Seliverstov Fix For: 2.5 Repeatable read isolation implies that each GET operation whithin tx gets a last commited version of entry *at the time the tx was started*. Curentrly we get a last commited version of entry *at the time the first read operation invokes on a particular key whithin tx.* We need to fix this unconsistence. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7342) SQL TX: Fix checking whether currently updating row is updated after it pass query filter
Igor Seliverstov created IGNITE-7342: Summary: SQL TX: Fix checking whether currently updating row is updated after it pass query filter Key: IGNITE-7342 URL: https://issues.apache.org/jira/browse/IGNITE-7342 Project: Ignite Issue Type: Bug Components: sql Reporter: Igor Seliverstov Assignee: Igor Seliverstov Fix For: 2.5 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7267) Fix transactional inserts.
Igor Seliverstov created IGNITE-7267: Summary: Fix transactional inserts. Key: IGNITE-7267 URL: https://issues.apache.org/jira/browse/IGNITE-7267 Project: Ignite Issue Type: Bug Components: sql Reporter: Igor Seliverstov Assignee: Igor Seliverstov Fix For: 2.5 Inserts optimisation (IGNITE-4490) breaks transactional inserts. Need to rework the feature. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7249) SQL TX: Commit/rollback active TX before processing DDL statement
Igor Seliverstov created IGNITE-7249: Summary: SQL TX: Commit/rollback active TX before processing DDL statement Key: IGNITE-7249 URL: https://issues.apache.org/jira/browse/IGNITE-7249 Project: Ignite Issue Type: Test Components: sql Reporter: Igor Seliverstov Assignee: Igor Seliverstov -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7187) SQL TX: Near caches support
Igor Seliverstov created IGNITE-7187: Summary: SQL TX: Near caches support Key: IGNITE-7187 URL: https://issues.apache.org/jira/browse/IGNITE-7187 Project: Ignite Issue Type: Task Components: sql Reporter: Igor Seliverstov Currently near readers don't participate in SQL transactions, we need to notify near readers on updates. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7188) SQL TX: Retry strategy on lock conflicts
Igor Seliverstov created IGNITE-7188: Summary: SQL TX: Retry strategy on lock conflicts Key: IGNITE-7188 URL: https://issues.apache.org/jira/browse/IGNITE-7188 Project: Ignite Issue Type: Task Components: sql Reporter: Igor Seliverstov We need to provide some strategy to avoid lock conflicts (deadlocks), detect and hanle them. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7186) SQL TX: Updates on backup nodes/Replicated caches support
Igor Seliverstov created IGNITE-7186: Summary: SQL TX: Updates on backup nodes/Replicated caches support Key: IGNITE-7186 URL: https://issues.apache.org/jira/browse/IGNITE-7186 Project: Ignite Issue Type: Task Components: sql Reporter: Igor Seliverstov Current TX implementation implies update backup partitions at the tx prepare state sending set of keys and update values from primary nodes. This approach works fine for Key-Value store but produces issues when we run SQL update without WHERE clause on a table of billions rows. We need to process somehow primary and backups partitions at the same time using mainly local query results. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7184) SQL TX: Support optimistic transactions
Igor Seliverstov created IGNITE-7184: Summary: SQL TX: Support optimistic transactions Key: IGNITE-7184 URL: https://issues.apache.org/jira/browse/IGNITE-7184 Project: Ignite Issue Type: Task Components: sql Reporter: Igor Seliverstov Support optimistic transactions -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7185) SQL TX: Updates during rebalancing.
Igor Seliverstov created IGNITE-7185: Summary: SQL TX: Updates during rebalancing. Key: IGNITE-7185 URL: https://issues.apache.org/jira/browse/IGNITE-7185 Project: Ignite Issue Type: Task Components: sql Reporter: Igor Seliverstov Crrently we map an update operation to data nodes and perform it on all the nodes simultaneously. It works fine on stable topology but produces many issues if the operation happens at the rebalance time because we cannot query data properly if some partitions are in moving state. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7183) SQL TX: Implicit transactions
Igor Seliverstov created IGNITE-7183: Summary: SQL TX: Implicit transactions Key: IGNITE-7183 URL: https://issues.apache.org/jira/browse/IGNITE-7183 Project: Ignite Issue Type: Task Reporter: Igor Seliverstov Implicit transaction has to be started on any SQL update in a transactional cache. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7164) SQL TX: Locking protocol for complex cases
Igor Seliverstov created IGNITE-7164: Summary: SQL TX: Locking protocol for complex cases Key: IGNITE-7164 URL: https://issues.apache.org/jira/browse/IGNITE-7164 Project: Ignite Issue Type: Task Components: sql Reporter: Igor Seliverstov Currently several features are still unimplemented: # Implicit transactions # Optimistic transactions # Transactional SQL updates during rebalancing # Updates on backup nodes/Replicated caches support # Near caches support # TX restore # Remap on topology changes -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6931) Avoid extra deserialization on index rebuild
Igor Seliverstov created IGNITE-6931: Summary: Avoid extra deserialization on index rebuild Key: IGNITE-6931 URL: https://issues.apache.org/jira/browse/IGNITE-6931 Project: Ignite Issue Type: Improvement Security Level: Public (Viewable by anyone) Components: cache, sql Affects Versions: 2.3 Reporter: Igor Seliverstov Assignee: Igor Seliverstov Fix For: 2.4 Currently on index rebuild we open a cursor over cache keys and for each key get a full row instead of using already extracted one. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6929) Preserve mvcc versions on index rebuild
Igor Seliverstov created IGNITE-6929:
Summary: Preserve mvcc versions on index rebuild
Key: IGNITE-6929
URL: https://issues.apache.org/jira/browse/IGNITE-6929
Project: Ignite
Issue Type: Bug
Security Level: Public (Viewable by anyone)
Components: sql
Reporter: Igor Seliverstov
Assignee: Igor Seliverstov
Currently we may loose next available version for an index row on index rebuild
({{org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.CacheDataStoreImpl#updateIndexes}})
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
