[jira] [Updated] (IGNITE-13871) MVCC removal
[ https://issues.apache.org/jira/browse/IGNITE-13871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-13871: -- Labels: ise (was: ) > MVCC removal > > > Key: IGNITE-13871 > URL: https://issues.apache.org/jira/browse/IGNITE-13871 > Project: Ignite > Issue Type: Task >Reporter: Vyacheslav Koptilin >Assignee: Anton Vinogradov >Priority: Blocker > Labels: ise > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > > The community has agreed that MVCC public API should be removed. > Vote thread > http://apache-ignite-developers.2346864.n4.nabble.com/Removing-MVCC-public-API-tp50550.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20246) Sql. Decouple distribution trait and function.
[ https://issues.apache.org/jira/browse/IGNITE-20246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-20246: -- Description: *Motivation* As for now, we have IgniteDistribution trait with DistributionFunction inside. In fact, this "function" is a factory for factory for functions, but should be just a logical node. `IgniteDistribution.destination()` method accepts hash-function factory regardless if the function hash-based or not. LogicalRelImplementor could convert this logical node into a physcal node, which can calculates destinations, and make hash function part of this physcal node. *Suggestion* 1. Move `gniteDistribution.destination()` method to some another class, which will be a "destination factory" and e.g. put it into a table instead of `distribution`. 2. Replace HashFunctionFactory with RowHandler in `destination()` method signature. was: Motivation. As for now, we have IgniteDistribution trait with DistributionFunction inside. In fact, this "function" is a factory for factory for functions, but should be just a logical node. `IgniteDistribution.destination()` method accepts hash-function factory regardless if the function hash-based or not. LogicalRelImplementor could convert this logical node into a physcal node, which can calculates destinations, and make hash function part of this physcal node. Let's 1. Move `gniteDistribution.destination()` method to some another class, which will be a "destination factory" and e.g. put it into a table instead of `distribution`. 2. Replace HashFunctionFactory with RowHandler in `destination()` method signature. > Sql. Decouple distribution trait and function. > -- > > Key: IGNITE-20246 > URL: https://issues.apache.org/jira/browse/IGNITE-20246 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3, tech-debt > Fix For: 3.0.0-beta2 > > > *Motivation* > As for now, we have IgniteDistribution trait with DistributionFunction inside. > In fact, this "function" is a factory for factory for functions, but should > be just a logical node. > `IgniteDistribution.destination()` method accepts hash-function factory > regardless if the function hash-based or not. LogicalRelImplementor could > convert this logical node into a physcal node, which can calculates > destinations, and make hash function part of this physcal node. > *Suggestion* > 1. Move `gniteDistribution.destination()` method to some another class, > which will be a "destination factory" and e.g. put it into a table instead of > `distribution`. > 2. Replace HashFunctionFactory with RowHandler in `destination()` method > signature. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20246) Sql. Decouple distribution trait and function.
[ https://issues.apache.org/jira/browse/IGNITE-20246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-20246: -- Fix Version/s: 3.0.0-beta2 > Sql. Decouple distribution trait and function. > -- > > Key: IGNITE-20246 > URL: https://issues.apache.org/jira/browse/IGNITE-20246 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Motivation. > As for now, we have IgniteDistribution trait with DistributionFunction inside. > In fact, this "function" is a factory for factory for functions, but should > be just a logical node. > `IgniteDistribution.destination()` method accepts hash-function factory > regardless if the function hash-based or not. LogicalRelImplementor could > convert this logical node into a physcal node, which can calculates > destinations, and make hash function part of this physcal node. > Let's > 1. Move `gniteDistribution.destination()` method to some another class, > which will be a "destination factory" and e.g. put it into a table instead of > `distribution`. > 2. Replace HashFunctionFactory with RowHandler in `destination()` method > signature. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20246) Sql. Decouple distribution trait and function.
[ https://issues.apache.org/jira/browse/IGNITE-20246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-20246: -- Labels: ignite-3 tech-debt (was: ignite-3) > Sql. Decouple distribution trait and function. > -- > > Key: IGNITE-20246 > URL: https://issues.apache.org/jira/browse/IGNITE-20246 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3, tech-debt > Fix For: 3.0.0-beta2 > > > Motivation. > As for now, we have IgniteDistribution trait with DistributionFunction inside. > In fact, this "function" is a factory for factory for functions, but should > be just a logical node. > `IgniteDistribution.destination()` method accepts hash-function factory > regardless if the function hash-based or not. LogicalRelImplementor could > convert this logical node into a physcal node, which can calculates > destinations, and make hash function part of this physcal node. > Let's > 1. Move `gniteDistribution.destination()` method to some another class, > which will be a "destination factory" and e.g. put it into a table instead of > `distribution`. > 2. Replace HashFunctionFactory with RowHandler in `destination()` method > signature. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20246) Sql. Decouple distribution trait and function.
Andrey Mashenkov created IGNITE-20246: - Summary: Sql. Decouple distribution trait and function. Key: IGNITE-20246 URL: https://issues.apache.org/jira/browse/IGNITE-20246 Project: Ignite Issue Type: Improvement Components: sql Reporter: Andrey Mashenkov Motivation. As for now, we have IgniteDistribution trait with DistributionFunction inside. In fact, this "function" is a factory for factory for functions, but should be just a logical node. `IgniteDistribution.destination()` method accepts hash-function factory regardless if the function hash-based or not. LogicalRelImplementor could convert this logical node into a physcal node, which can calculates destinations, and make hash function part of this physcal node. Let's 1. Move `gniteDistribution.destination()` method to some another class, which will be a "destination factory" and e.g. put it into a table instead of `distribution`. 2. Replace HashFunctionFactory with RowHandler in `destination()` method signature. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-15190) Ignite 3 CLI: if a node start takes longer than the timeout, it does not appear in the list
[
https://issues.apache.org/jira/browse/IGNITE-15190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin resolved IGNITE-15190.
--
Resolution: Won't Fix
Not actual anymore
https://cwiki.apache.org/confluence/display/IGNITE/IEP-88%3A+CLI+Tool
> Ignite 3 CLI: if a node start takes longer than the timeout, it does not
> appear in the list
> ---
>
> Key: IGNITE-15190
> URL: https://issues.apache.org/jira/browse/IGNITE-15190
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha2
>Reporter: Valentin Kulichenko
>Priority: Major
> Labels: ignite-3
>
> The {{node start}} command has a timeout, after which it treats the startup
> process as failed, and exits, without including the node in the list shown by
> the {{node list}} command.
> It is possible that the node actually manages to start after the timeout, in
> which case the CLI tool and the user are not aware of the running node.
> We need to revisit the node management approach in the CLI, so that we can
> avoid issues like this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-15097) Impelement integration tests for ignite-3 cli
[ https://issues.apache.org/jira/browse/IGNITE-15097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin resolved IGNITE-15097. -- Resolution: Won't Fix Not actual anymore https://cwiki.apache.org/confluence/display/IGNITE/IEP-88%3A+CLI+Tool > Impelement integration tests for ignite-3 cli > - > > Key: IGNITE-15097 > URL: https://issues.apache.org/jira/browse/IGNITE-15097 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > > We must extend ignite-cli test suite by full integration tests with the real > ignite node. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-16601) The CLI uses a direct java call to run the node ignoring the JAVA_HOME variable.
[ https://issues.apache.org/jira/browse/IGNITE-16601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin resolved IGNITE-16601. -- Resolution: Invalid Not actual anymore https://cwiki.apache.org/confluence/display/IGNITE/IEP-88%3A+CLI+Tool > The CLI uses a direct java call to run the node ignoring the JAVA_HOME > variable. > > > Key: IGNITE-16601 > URL: https://issues.apache.org/jira/browse/IGNITE-16601 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-alpha4 >Reporter: Fedor Malchikov >Priority: Blocker > Labels: ignite-3, ignite-3-cli-tool > > As a result, working on environments where java is not directly installed or > several versions of java are used is significantly complicated. As far as I > know, in version 2, overriding java_home was the main method of switching > between java versions in the system. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-16412) Default cli config contains portRange = 0 as result you can't start 2+ nodes.
[
https://issues.apache.org/jira/browse/IGNITE-16412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin resolved IGNITE-16412.
--
Resolution: Won't Fix
Not actual anymore
https://cwiki.apache.org/confluence/display/IGNITE/IEP-88%3A+CLI+Tool
> Default cli config contains portRange = 0 as result you can't start 2+ nodes.
> --
>
> Key: IGNITE-16412
> URL: https://issues.apache.org/jira/browse/IGNITE-16412
> Project: Ignite
> Issue Type: Bug
>Reporter: Fedor Malchikov
>Priority: Major
> Labels: ignite-3, ignite-3-cli-tool
>
> Default config:
> ./ignite config get --type=node
> "\{\"clientConnector\":{\"connectTimeout\":5000,\"port\":10800,\"portRange\":100},\"network\":\{\"inbound\":{\"soBacklog\":128,\"soKeepAlive\":true,\"soLinger\":0,\"soReuseAddr\":true,\"tcpNoDelay\":true},\"membership\":\{\"failurePingInterval\":500,\"membershipSyncInterval\":1000,\"scaleCube\":{\"failurePingRequestMembers\":1,\"gossipInterval\":10,\"membershipSuspicionMultiplier\":1}},\"nodeFinder\":\{\"netClusterNodes\":[],\"type\":\"STATIC\"},\"outbound\":\{\"soKeepAlive\":true,\"soLinger\":0,\"tcpNoDelay\":true},\"port\":47500,\"portRange\":0,\"shutdownQuietPeriod\":0,\"shutdownTimeout\":15000},\"node\":\{\"metastorageNodes\":[]},\"rest\":\{\"port\":10300,\"portRange\":100}}"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20245) MVCC test/suites removal
Anton Vinogradov created IGNITE-20245: - Summary: MVCC test/suites removal Key: IGNITE-20245 URL: https://issues.apache.org/jira/browse/IGNITE-20245 Project: Ignite Issue Type: Sub-task Reporter: Anton Vinogradov Assignee: Anton Vinogradov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20244) Replace the use of constants from the DistributionZoneManager with constants from CatalogUtils and CatalogService
Kirill Tkalenko created IGNITE-20244: Summary: Replace the use of constants from the DistributionZoneManager with constants from CatalogUtils and CatalogService Key: IGNITE-20244 URL: https://issues.apache.org/jira/browse/IGNITE-20244 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko Fix For: 3.0.0-beta2 To reduce the amount of changes in task IGNITE-20114, I propose to get rid of the constants in the *org.apache.ignite.internal.distributionzones.DistributionZoneManager* and use the constants from *org.apache.ignite.internal.catalog.commands.CatalogUtils* and *org.apache.ignite.internal.catalog.CatalogService* instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-13871) MVCC removal
[ https://issues.apache.org/jira/browse/IGNITE-13871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-13871: -- Fix Version/s: 2.16 > MVCC removal > > > Key: IGNITE-13871 > URL: https://issues.apache.org/jira/browse/IGNITE-13871 > Project: Ignite > Issue Type: Task >Reporter: Vyacheslav Koptilin >Assignee: Anton Vinogradov >Priority: Blocker > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > > The community has agreed that MVCC public API should be removed. > Vote thread > http://apache-ignite-developers.2346864.n4.nabble.com/Removing-MVCC-public-API-tp50550.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-13871) MVCC removal
[ https://issues.apache.org/jira/browse/IGNITE-13871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-13871: -- Summary: MVCC removal (was: Removing MVCC public API) > MVCC removal > > > Key: IGNITE-13871 > URL: https://issues.apache.org/jira/browse/IGNITE-13871 > Project: Ignite > Issue Type: Task >Reporter: Vyacheslav Koptilin >Assignee: Anton Vinogradov >Priority: Blocker > Time Spent: 20m > Remaining Estimate: 0h > > The community has agreed that MVCC public API should be removed. > Vote thread > http://apache-ignite-developers.2346864.n4.nabble.com/Removing-MVCC-public-API-tp50550.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19844) TX code cleanup
[ https://issues.apache.org/jira/browse/IGNITE-19844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-19844: -- Description: It's an umbrella issue to keep all cleanup issues. Scope: #1 !scope.png|width=800! #2 !scope2.png|width=800! #3 !scope3.png|width=800! #4 !scope4.png|width=800! TODO #5 - Grid*Requests and Grid*Responses (like GridNearLockRequest) was: It's an umbrella issue to keep all cleanup issues. Scope: #1 !scope.png|width=800! #2 !scope2.png|width=800! #3 !scope3.png|width=800! #4 !scope4.png|width=800! TODO #5 - Grid*Requests (like GridNearLockRequest) > TX code cleanup > --- > > Key: IGNITE-19844 > URL: https://issues.apache.org/jira/browse/IGNITE-19844 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Attachments: scope.png, scope2.png, scope3.png, scope4.png > > > It's an umbrella issue to keep all cleanup issues. > Scope: > #1 > !scope.png|width=800! > #2 > !scope2.png|width=800! > #3 > !scope3.png|width=800! > #4 > !scope4.png|width=800! > TODO #5 - Grid*Requests and Grid*Responses (like GridNearLockRequest) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20183) Java thin 3.0: testNonNullTxDisablesPartitionAwareness is flaky
[
https://issues.apache.org/jira/browse/IGNITE-20183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17755516#comment-17755516
]
Pavel Tupitsyn commented on IGNITE-20183:
-
Merged to main: bb382455eaafeac3eb022e649ebff3f41985a4ac
> Java thin 3.0: testNonNullTxDisablesPartitionAwareness is flaky
> ---
>
> Key: IGNITE-20183
> URL: https://issues.apache.org/jira/browse/IGNITE-20183
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> https://ci.ignite.apache.org/test/-5961865609456060252?currentProjectId=ApacheIgnite3xGradle_Test=true
> {code}
> org.opentest4j.AssertionFailedError: Operation get was not executed on
> expected node ==> expected: but was:
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at
> app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
> at
> app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
> at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1153)
> at
> app//org.apache.ignite.client.PartitionAwarenessTest.assertOpOnNode(PartitionAwarenessTest.java:591)
> at
> app//org.apache.ignite.client.PartitionAwarenessTest.testNonNullTxDisablesPartitionAwareness(PartitionAwarenessTest.java:157)
> {code}
> Seems to be caused by IGNITE-20152 fix - random port causes random node
> ordering.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-19992) Sql. Rework execution of 2-phase set operators
[
https://issues.apache.org/jira/browse/IGNITE-19992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17755510#comment-17755510
]
Maksim Zhuravkov commented on IGNITE-19992:
---
[~korlov] [~xtern] Could you please review my patch?
> Sql. Rework execution of 2-phase set operators
> --
>
> Key: IGNITE-19992
> URL: https://issues.apache.org/jira/browse/IGNITE-19992
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As of now, both {{IntersectNode}} and {{MinusNode}} use complex structures as
> result of MAP phase (see
> {{org.apache.ignite.internal.sql.engine.exec.rel.AbstractSetOpNode.Grouping#getOnMapper}};
> it emits rows cardinality of 2, where first column is entire group key, and
> second column is an array of counters). This prevents us from migrating sql
> runtime to BinaryTuple-based rows, because currently BinaryTuple does not
> support nested structures.
> Let's rework those node to inline group key and counters into plain row.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19844) TX code cleanup
[ https://issues.apache.org/jira/browse/IGNITE-19844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-19844: -- Description: It's an umbrella issue to keep all cleanup issues. Scope: #1 !scope.png|width=800! #2 !scope2.png|width=800! #3 !scope3.png|width=800! #4 !scope4.png|width=800! TODO #5 - Grid*Requests (like GridNearLockRequest) was: It's an umbrella issue to keep all cleanup issues. Scope: #1 !scope.png|width=800! #2 !scope2.png|width=800! #3 !scope3.png|width=800! #4 !scope4.png|width=800! > TX code cleanup > --- > > Key: IGNITE-19844 > URL: https://issues.apache.org/jira/browse/IGNITE-19844 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Attachments: scope.png, scope2.png, scope3.png, scope4.png > > > It's an umbrella issue to keep all cleanup issues. > Scope: > #1 > !scope.png|width=800! > #2 > !scope2.png|width=800! > #3 > !scope3.png|width=800! > #4 > !scope4.png|width=800! > TODO #5 - Grid*Requests (like GridNearLockRequest) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-15742) Description of IgniteCluster.baselineAutoAdjustTimeout does not provide any information about measure units for the timeout.
[
https://issues.apache.org/jira/browse/IGNITE-15742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17755507#comment-17755507
]
Vyacheslav Koptilin commented on IGNITE-15742:
--
Hello [~venkatesh2090],
I merged your patch. Thank you for your efforts!
> Description of IgniteCluster.baselineAutoAdjustTimeout does not provide any
> information about measure units for the timeout.
>
>
> Key: IGNITE-15742
> URL: https://issues.apache.org/jira/browse/IGNITE-15742
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Vyacheslav Koptilin
>Assignee: Venkatesh Prasad Kannan
>Priority: Major
> Labels: newbie
> Fix For: 2.16
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Both methods related to baseline auto adjustment does not specify measure
> units of the timeout:
> {code:java}
> /**
> * @return Value of time which we would wait before the actual topology
> change since last server topology change
> * (node join/left/fail).
> * @throws IgniteException If operation failed.
> */
> public long baselineAutoAdjustTimeout();
> /**
> * @param baselineAutoAdjustTimeout Value of time which we would wait
> before the actual topology change since last
> * server topology change (node join/left/fail).
> * @throws IgniteException If failed.
> */
> public void baselineAutoAdjustTimeout(long baselineAutoAdjustTimeout)
> throws IgniteException;
> {code}
> Need to clearly specify that {{baselineAutoAdjustTimeout}} should be defined
> in milliseconds.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15742) Description of IgniteCluster.baselineAutoAdjustTimeout does not provide any information about measure units for the timeout.
[
https://issues.apache.org/jira/browse/IGNITE-15742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-15742:
-
Fix Version/s: 2.16
> Description of IgniteCluster.baselineAutoAdjustTimeout does not provide any
> information about measure units for the timeout.
>
>
> Key: IGNITE-15742
> URL: https://issues.apache.org/jira/browse/IGNITE-15742
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Vyacheslav Koptilin
>Assignee: Venkatesh Prasad Kannan
>Priority: Major
> Labels: newbie
> Fix For: 2.16
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Both methods related to baseline auto adjustment does not specify measure
> units of the timeout:
> {code:java}
> /**
> * @return Value of time which we would wait before the actual topology
> change since last server topology change
> * (node join/left/fail).
> * @throws IgniteException If operation failed.
> */
> public long baselineAutoAdjustTimeout();
> /**
> * @param baselineAutoAdjustTimeout Value of time which we would wait
> before the actual topology change since last
> * server topology change (node join/left/fail).
> * @throws IgniteException If failed.
> */
> public void baselineAutoAdjustTimeout(long baselineAutoAdjustTimeout)
> throws IgniteException;
> {code}
> Need to clearly specify that {{baselineAutoAdjustTimeout}} should be defined
> in milliseconds.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20033) Implement local txnStateMap
[
https://issues.apache.org/jira/browse/IGNITE-20033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-20033:
--
Description:
h3. Motivation
For some purposes, in addition to persistent txnState in commit partition, it's
required to have a txn meta on every transactional actor: txn coordinator,
commit partition (both primary and all backups) and all enlisted partitions
(both primary and backups).
[IEP-91|https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol#IEP91:Transactionprotocol-Txnstatemap]
names such meta holder as txn state map and specifies following structure
{code:java}
txId -> (txState, txCoordAddr, commitTs){code}
Such map is originally designed to provide required information for
writeIntentResolution: txState for local write intent resolution and
txCoordAddr for coordinator-path one, but that's not all it's good for, so it
definitely worth to implement it as soon as possible in order to unblock
further activities.
-Why we have this ticket in "commit partition recovery" pack?
-Because in order to implement proper handling of a commit partition primary
replica change (which is definitely a part of the "commit partition pack") it's
required to:
# Support local txnStateMap, in order to
# Implement writeIntentResolution coordinator path, in order to
# Calculate commitTimestamp on txn coordtinator istead of commit partition,
where we do it now.
h3. Definition of Done
Every transactional actor
* Txn Coordinator.
* CommitPartition, both primary and all backups.
* All enlisted partitions, both primary and all backups.
should have volatile txnStateMap with following suggested structure 'txId ->
(txState, txCoordAddr, commitTs)'.
Given map should be adjusted before any further transactional actions within
node in a following way:
* Transaction coordinator.
** On transaction start with state PENDING.
** On transaction commit, right after commitTimestamp calucalttion with state
FINISHING.
** On txFinishReplicaResponse with either COMMITED or ABORTED.
* Commit partition.
** On replica touch with state PENDING.
** After succefull finishTxCommand application on majoirty with either
COMMITED or ABORTED.
** Seems that we don't need FINISHING state here, so let's skip it for now.
* Enlisted replica.
** Primary
*** On replica touch with state PENDING.
*** On TxCleanupCommand COMMITED or ABORTED.
** Backup
*** On touch replication PENDING.
*** On TxCleanupCommand COMMITED or ABORTED, same as for primary.
h3. Implementation Notes
There are some open questions:
* Where to put this txnStateMap? TxManager?
* Properly handle same map multiple updates, based on the fact that Commit
Partition is also an enlisted partition. To be honest I believe it's not that
important. We may extent possible state change application rules to assume that
null > PENDING, PENDING > FINISHING, PENDING > COMMITED, PENDING > ABORTED,
PENDING > PENDING, COMMITED > COMMITED and ABORTED > ABORTED are all possible.
* Eliminate excessive map updates in case of "one-phase commit".
https://issues.apache.org/jira/browse/IGNITE-15927
* Substitute org.apache.ignite.internal.tx.impl.TxManagerImpl#states with
txnStateMap.
* Definte "touch".
* It's reasonbale to use non-consistent node id as txCoordAddr because
currently there's no sense in sending TxStateReq to the node that lost it's
local txnStateMap because of node restart.
was:
h3. Motivation
For some purposes, in addition to persistent txnState in commit partition, it's
required to have a txn meta on every transactional actor: txn coordinator,
commit partition (both primary and all backups) and all enlisted partitions
(both primary and backups).
[IEP-91|https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol#IEP91:Transactionprotocol-Txnstatemap]
names such meta holder as txn state map and specifies following structure
{code:java}
txId -> (txState, txCoordAddr, commitTs){code}
Such map is originally designed to provide required information for
writeIntentResolution: txState for local write intent resolution and
txCoordAddr for coordinator-path one, but that's not all it's good for, so it
definitely worth to implement it as soon as possible in order to unblock
further activities.
-Why we have this ticket in "commit partition recovery" pack?
-Because in order to implement proper handling of a commit partition primary
replica change (which is definitely a part of the "commit partition pack") it's
required to:
# Support local txnStateMap, in order to
# Implement writeIntentResolution coordinator path, in order to
# Calculate commitTimestamp on txn coordtinator istead of commit partition,
where we do it now.
h3. Definition of Done
Every transactional actor
* Txn Coordinator.
* CommitPartition, both primary and all backups.
* All enlisted partitions, both primary and
[jira] [Commented] (IGNITE-20196) Sql. Review list of reserved keywords
[ https://issues.apache.org/jira/browse/IGNITE-20196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17755497#comment-17755497 ] Yury Gerzhedovich commented on IGNITE-20196: [~korlov] LGTM. > Sql. Review list of reserved keywords > - > > Key: IGNITE-20196 > URL: https://issues.apache.org/jira/browse/IGNITE-20196 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > IGNITE-19759 introduces some refactoring to the parser configuration: > reserved keywords are revised and parser is configured with defaults defined > in default_configuration, which makes config.fmpp a bit cleaner. > Let's port all these changes to Ignite-3. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20233) jdbc: Propagate observable timestamp to sql-engine.
[ https://issues.apache.org/jira/browse/IGNITE-20233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-20233: --- Component/s: sql > jdbc: Propagate observable timestamp to sql-engine. > --- > > Key: IGNITE-20233 > URL: https://issues.apache.org/jira/browse/IGNITE-20233 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > We need to pass the observable timestamp from jdbc client to the sql engine. > This must be done after the completion of IGNITE-19898. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-13871) Removing MVCC public API
[ https://issues.apache.org/jira/browse/IGNITE-13871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov reassigned IGNITE-13871: - Assignee: Anton Vinogradov (was: Nikolay Izhikov) > Removing MVCC public API > > > Key: IGNITE-13871 > URL: https://issues.apache.org/jira/browse/IGNITE-13871 > Project: Ignite > Issue Type: Task >Reporter: Vyacheslav Koptilin >Assignee: Anton Vinogradov >Priority: Blocker > Time Spent: 20m > Remaining Estimate: 0h > > The community has agreed that MVCC public API should be removed. > Vote thread > http://apache-ignite-developers.2346864.n4.nabble.com/Removing-MVCC-public-API-tp50550.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-20211) GridNearTxAbstractEnlistFuture and descendants code deduplication
[ https://issues.apache.org/jira/browse/IGNITE-20211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17755464#comment-17755464 ] Anton Vinogradov edited comment on IGNITE-20211 at 8/17/23 10:12 AM: - Can not be fixed properly before MVCC removal (IGNITE-13871) was (Author: av): Can not be fix properly before MVCC removal (IGNITE-13871) > GridNearTxAbstractEnlistFuture and descendants code deduplication > - > > Key: IGNITE-20211 > URL: https://issues.apache.org/jira/browse/IGNITE-20211 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Fix For: 2.16 > > Time Spent: 1h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-20211) GridNearTxAbstractEnlistFuture and descendants code deduplication
[ https://issues.apache.org/jira/browse/IGNITE-20211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov resolved IGNITE-20211. --- Resolution: Won't Fix Can not be fix properly before MVCC removal (IGNITE-13871) > GridNearTxAbstractEnlistFuture and descendants code deduplication > - > > Key: IGNITE-20211 > URL: https://issues.apache.org/jira/browse/IGNITE-20211 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Fix For: 2.16 > > Time Spent: 1h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20217) GridCacheFutureAdapter and descendants initial cleanup
[
https://issues.apache.org/jira/browse/IGNITE-20217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17755463#comment-17755463
]
Ignite TC Bot commented on IGNITE-20217:
{panel:title=Branch: [pull/10896/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10896/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7302409buildTypeId=IgniteTests24Java8_RunAll]
> GridCacheFutureAdapter and descendants initial cleanup
> --
>
> Key: IGNITE-20217
> URL: https://issues.apache.org/jira/browse/IGNITE-20217
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Fix For: 2.16
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Deleted] (IGNITE-20218) CacheDistributedGetFutureAdapter and descendants initial deduplication
[ https://issues.apache.org/jira/browse/IGNITE-20218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov deleted IGNITE-20218: -- > CacheDistributedGetFutureAdapter and descendants initial deduplication > -- > > Key: IGNITE-20218 > URL: https://issues.apache.org/jira/browse/IGNITE-20218 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20082) Fix ODBC package
[
https://issues.apache.org/jira/browse/IGNITE-20082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17755450#comment-17755450
]
Aleksandr commented on IGNITE-20082:
Thank you for the contribution, merged into main:
2c22342bb131a610af4c622c99127bf52aa102ea
> Fix ODBC package
> -
>
> Key: IGNITE-20082
> URL: https://issues.apache.org/jira/browse/IGNITE-20082
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Pochatkin
>Assignee: Mikhail Pochatkin
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 1. Missing {{/usr/lib/libignite3-odbc.so.3}} inside DEB\RPM packages
> 2. Incorrect {{unixodbc}} package name in DEB package requirement
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20183) Java thin 3.0: testNonNullTxDisablesPartitionAwareness is flaky
[
https://issues.apache.org/jira/browse/IGNITE-20183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17755449#comment-17755449
]
Igor Sapego commented on IGNITE-20183:
--
Looks good to me.
> Java thin 3.0: testNonNullTxDisablesPartitionAwareness is flaky
> ---
>
> Key: IGNITE-20183
> URL: https://issues.apache.org/jira/browse/IGNITE-20183
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://ci.ignite.apache.org/test/-5961865609456060252?currentProjectId=ApacheIgnite3xGradle_Test=true
> {code}
> org.opentest4j.AssertionFailedError: Operation get was not executed on
> expected node ==> expected: but was:
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at
> app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
> at
> app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
> at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1153)
> at
> app//org.apache.ignite.client.PartitionAwarenessTest.assertOpOnNode(PartitionAwarenessTest.java:591)
> at
> app//org.apache.ignite.client.PartitionAwarenessTest.testNonNullTxDisablesPartitionAwareness(PartitionAwarenessTest.java:157)
> {code}
> Seems to be caused by IGNITE-20152 fix - random port causes random node
> ordering.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20164) Sql. Incorrect propagation of RelCollation trait for Sort-based map/reduce aggregates.
[
https://issues.apache.org/jira/browse/IGNITE-20164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov reassigned IGNITE-20164:
-
Assignee: Maksim Zhuravkov
> Sql. Incorrect propagation of RelCollation trait for Sort-based map/reduce
> aggregates.
> --
>
> Key: IGNITE-20164
> URL: https://issues.apache.org/jira/browse/IGNITE-20164
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> RelCollation propagation does not take into account remapping of group keys
> between MAP/REDUCE phases, hence causes errors in queries that are expected
> to use sort-based MAP/REDUCE - RelCollation uses the same keys on both
> phases. Example:
> {code:java}
> String[] rules = {
> "MapReduceHashAggregateConverterRule",
> "ColocatedHashAggregateConverterRule",
> "ColocatedSortAggregateConverterRule"
> };
> sql("CREATE TABLE testMe40 (a INTEGER, b INTEGER);");
> sql("INSERT INTO testMe40 VALUES (11, 2), (12, 2), (12, 3)");
> assertQuery("SELECT COUNT(a), COUNT(DISTINCT(b)) FROM testMe40")
> .disableRules(rules)
> .returns(3L, 2L)
> .check();
> {code}
> Plan:
> {code:java}
> IgniteProject(EXPR$0=[CAST($0):BIGINT NOT NULL], EXPR$1=[$1]),
> IgniteReduceSortAggregate(group=[{}], EXPR$0=[$SUM0($1)],
> EXPR$1=[COUNT($0)], collation=[[]]),
> IgniteMapSortAggregate(group=[{}], EXPR$0=[$SUM0($1)],
> EXPR$1=[COUNT($0)], collation=[[]]),
> IgniteReduceSortAggregate(group=[{1}], EXPR$0=[COUNT($0)],
> collation=[[1]]), < HERE
> IgniteExchange(distribution=[single]),
> IgniteMapSortAggregate(group=[{1}], EXPR$0=[COUNT($0)],
> collation=[[1]]),
> IgniteSort(sort0=[$1], dir0=[ASC]),
> IgniteTableScan(table=[[PUBLIC, TESTME40]],
> requiredColumns=[{1, 2}]),
> {code}
> Error:
> {code:java}
> Caused by: java.lang.ClassCastException: class java.util.ArrayList cannot be
> cast to class java.lang.Comparable (java.util.ArrayList and
> java.lang.Comparable are in module java.base of loader 'bootstrap')
> at
> org.apache.ignite.internal.sql.engine.exec.exp.ExpressionFactoryImpl.compare(ExpressionFactoryImpl.java:247)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.ExpressionFactoryImpl.lambda$comparator$0(ExpressionFactoryImpl.java:178)
> at
> java.base/java.util.Map$Entry.lambda$comparingByKey$6d558cbf$1(Map.java:539)
> at
> java.base/java.util.PriorityQueue.siftUpUsingComparator(PriorityQueue.java:675)
> at java.base/java.util.PriorityQueue.siftUp(PriorityQueue.java:652)
> at java.base/java.util.PriorityQueue.offer(PriorityQueue.java:345)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.Inbox.pushOrdered(Inbox.java:235)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.Inbox.push(Inbox.java:188)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.Inbox.onBatchReceived(Inbox.java:168)
> at
> org.apache.ignite.internal.sql.engine.exec.ExchangeServiceImpl.onMessage(ExchangeServiceImpl.java:184)
> ... 7 more
> {code}
> The query below works because position of column b does not change after MAP
> phase.
> {code:java}
> String[] rules = {
> "MapReduceHashAggregateConverterRule",
> "ColocatedHashAggregateConverterRule",
> "ColocatedSortAggregateConverterRule"
> };
> sql("CREATE TABLE testMe40 (a INTEGER, b INTEGER);");
> sql("INSERT INTO testMe40 VALUES (11, 2), (12, 2), (12, 3)");
> assertQuery("SELECT COUNT(a), COUNT(DISTINCT(b)) FROM testMe40")
> .disableRules(rules)
> .returns(3L, 2L)
> .check();
> {code}
> Plan:
> {code:java}
> IgniteProject(EXPR$0=[$0], EXPR$1=[CAST($1):BIGINT NOT NULL]),
> IgniteReduceSortAggregate(group=[{}], EXPR$0=[COUNT($0)],
> EXPR$1=[$SUM0($1)], collation=[[]]),
> IgniteMapSortAggregate(group=[{}], EXPR$0=[COUNT($0)],
> EXPR$1=[$SUM0($1)], collation=[[]]),
> IgniteReduceSortAggregate(group=[{0}], EXPR$1=[COUNT($1)],
> collation=[[0]]),
> IgniteExchange(distribution=[single]),
> IgniteMapSortAggregate(group=[{0}], EXPR$1=[COUNT($1)],
> collation=[[0]]),
> IgniteSort(sort0=[$0], dir0=[ASC]),
> IgniteTableScan(table=[[PUBLIC, TESTME40]], projects=[[$t1,
> $t0]], requiredColumns=[{1, 2}]),
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20243) Introduce a Matcher for BinaryRows
[
https://issues.apache.org/jira/browse/IGNITE-20243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-20243:
-
Fix Version/s: 3.0.0-beta2
> Introduce a Matcher for BinaryRows
> --
>
> Key: IGNITE-20243
> URL: https://issues.apache.org/jira/browse/IGNITE-20243
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In tests we often need to compare two given BinaryRows. Unfortunately, we
> cannot use {{equals}} and, as a consequence, {{assertEquals}}, because
> {{BinaryRow}} has two implemenations: {{Row}} and {{BinaryRowImpl}} which are
> used interchangeably.
> To solve this problem, it is proposed to add a Hamcrest Matcher, that will
> allow to compare two {{BinaryRows}} regardless of their implementation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20201) Node failure when incorrect names are used for hitrate and histogram metrics configuration
[
https://issues.apache.org/jira/browse/IGNITE-20201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov reassigned IGNITE-20201:
---
Assignee: Mikhail Petrov
> Node failure when incorrect names are used for hitrate and histogram metrics
> configuration
> --
>
> Key: IGNITE-20201
> URL: https://issues.apache.org/jira/browse/IGNITE-20201
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.15
>Reporter: Ilya Shishkov
>Assignee: Mikhail Petrov
>Priority: Critical
> Labels: ise
>
> There are no metric name validation when we perform hitrate and historgam
> metrics configuration by means of control script. It can lead to
> impossibility to restart persistent cluster.
> *How to reproduce:*
> # Start persistent cluster.
> # Enter commands from instructions [1].
> {noformat}
> control.sh —metric —configure-histogram histogram-metric-name 1,2,3
> control.sh —metric —configure-hitrate hitrate-metric-name 1000
> {noformat}
> # Deactivate and restart cluster.
> # Start and activate cluster and nodes will fail with following error:
> {noformat}
> [19:47:26,981][SEVERE][main][IgniteKernal] Got exception while starting (will
> rollback startup routine).
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> at java.lang.String.substring(String.java:1967)
> at
> org.apache.ignite.internal.processors.metric.impl.MetricUtils.fromFullName(MetricUtils.java:72)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager.find(GridMetricManager.java:502)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager.onHistogramConfigChanged(GridMetricManager.java:480)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager.access$300(GridMetricManager.java:73)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager$1.lambda$onReadyForRead$1(GridMetricManager.java:272)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.InMemoryCachedDistributedMetaStorageBridge.iterate(InMemoryCachedDistributedMetaStorageBridge.java:87)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.iterate(DistributedMetaStorageImpl.java:542)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager$1.onReadyForRead(GridMetricManager.java:272)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.notifyReadyForRead(DistributedMetaStorageImpl.java:355)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onMetaStorageReadyForRead(DistributedMetaStorageImpl.java:434)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.access$200(DistributedMetaStorageImpl.java:116)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl$2.onReadyForRead(DistributedMetaStorageImpl.java:259)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:430)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:877)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:3094)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1120)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1725)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1089)
> at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:983)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:889)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:808)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:678)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:647)
> at org.apache.ignite.Ignition.start(Ignition.java:325)
> at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:365)
> {noformat}
> Failure occurs when {{GridMetricManager}} tries to parse entries with
> incorrect metric names from metastorage:
> {noformat}
> metrics.histogram.histogram-metric-name [1, 2, 3]
>
>
[jira] [Resolved] (IGNITE-20228) Fix flaky test KillCommandsControlShTest
[ https://issues.apache.org/jira/browse/IGNITE-20228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin resolved IGNITE-20228. - Fix Version/s: 2.16 Reviewer: Nikolay Izhikov Resolution: Fixed [~nizhikov] thanks for the review. Merged to master > Fix flaky test KillCommandsControlShTest > > > Key: IGNITE-20228 > URL: https://issues.apache.org/jira/browse/IGNITE-20228 > Project: Ignite > Issue Type: Bug >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20228) Fix flaky test KillCommandsControlShTest
[
https://issues.apache.org/jira/browse/IGNITE-20228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17755415#comment-17755415
]
Ignite TC Bot commented on IGNITE-20228:
{panel:title=Branch: [pull/10898/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10898/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7303599buildTypeId=IgniteTests24Java8_RunAll]
> Fix flaky test KillCommandsControlShTest
>
>
> Key: IGNITE-20228
> URL: https://issues.apache.org/jira/browse/IGNITE-20228
> Project: Ignite
> Issue Type: Bug
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Labels: ise
> Time Spent: 20m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20015) Sql. Introduce new distribution function
[
https://issues.apache.org/jira/browse/IGNITE-20015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov reassigned IGNITE-20015:
-
Assignee: Andrey Mashenkov
> Sql. Introduce new distribution function
>
>
> Key: IGNITE-20015
> URL: https://issues.apache.org/jira/browse/IGNITE-20015
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> To realize the full potential of sql engine in queries over node specific
> views, we need to support new type of distribution function
> ({{org.apache.ignite.internal.sql.engine.trait.DistributionFunction}}). The
> semantic of this new function should be pretty strait forward: the column
> this function refers to is actually an identity of the node containing the
> data.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20033) Implement local txnStateMap
[
https://issues.apache.org/jira/browse/IGNITE-20033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov reassigned IGNITE-20033:
-
Assignee: Denis Chudov
> Implement local txnStateMap
> ---
>
> Key: IGNITE-20033
> URL: https://issues.apache.org/jira/browse/IGNITE-20033
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3, transaction3_recovery, transactions
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h3. Motivation
> For some purposes, in addition to persistent txnState in commit partition,
> it's required to have a txn meta on every transactional actor: txn
> coordinator, commit partition (both primary and all backups) and all enlisted
> partitions (both primary and backups).
> [IEP-91|https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol#IEP91:Transactionprotocol-Txnstatemap]
> names such meta holder as txn state map and specifies following structure
> {code:java}
> txId -> (txState, txCoordAddr, commitTs){code}
> Such map is originally designed to provide required information for
> writeIntentResolution: txState for local write intent resolution and
> txCoordAddr for coordinator-path one, but that's not all it's good for, so it
> definitely worth to implement it as soon as possible in order to unblock
> further activities.
> -Why we have this ticket in "commit partition recovery" pack?
> -Because in order to implement proper handling of a commit partition primary
> replica change (which is definitely a part of the "commit partition pack")
> it's required to:
> # Support local txnStateMap, in order to
> # Implement writeIntentResolution coordinator path, in order to
> # Calculate commitTimestamp on txn coordtinator istead of commit partition,
> where we do it now.
> h3. Definition of Done
> Every transactional actor
> * Txn Coordinator.
> * CommitPartition, both primary and all backups.
> * All enlisted partitions, both primary and all backups.
> should have volatile txnStateMap with following suggested structure 'txId ->
> (txState, txCoordAddr, commitTs)'.
>
> Given map should be adjusted before any further transactional actions within
> node in a following way:
> * Transaction coordinator.
> ** On transaction start with state PENDING.
> ** On transaction commit, right after commitTimestamp calucalttion with
> state FINISHING.
> ** On txFinishReplicaResponse with either COMMITED or ABORTED.
> * Commit partition.
> ** On replica touch with state PENDING.
> ** After succefull finishTxCommand application on majoirty with either
> COMMITED or ABORTED.
> ** Seems that we don't need FINISHING state here, so let's skip it for now.
> * Enlisted replica.
> ** Primary
> *** On replica touch with state PENDING.
> *** On TxCleanupCommand COMMITED or ABORTED.
> ** Backup
> *** On touch replication PENDING.
> *** On TxCleanupCommand COMMITED or ABORTED, same as for primary.
> h3. Implementation Notes
> There are some open questions:
> * Where to put this txnStateMap? TxManager?
> * Properly handle same map multiple updates, based on the fact that Commit
> Partition is also an enlisted partition. To be honest I believe it's not that
> important. We may extent possible state change application rules to assume
> that null > PENDING, PENDING > FINISHING, PENDING > COMMITED, PENDING >
> ABORTED, PENIGN > PENDING, COMMITED > COMMITED and ABORTED > ABORTED are all
> possible.
> * Eliminate excessive map updates in case of "one-phase commit".
> https://issues.apache.org/jira/browse/IGNITE-15927
> * Substitute org.apache.ignite.internal.tx.impl.TxManagerImpl#states with
> txnStateMap.
> * Definte "touch".
> * It's reasonbale to use non-consistent node id as txCoordAddr because
> currently there's no sense in sending TxStateReq to the node that lost it's
> local txnStateMap because of node restart.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20195) Long fsync of Raft log storage
[ https://issues.apache.org/jira/browse/IGNITE-20195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-20195: -- Description: Under intensive transactional load (see test [1]) the duration of fsync of Raft log storage [2] can exceed 1 second on local test runs. To reproduce it, you should turn on fsync on raft configuration mock. [1] ItTxDistributedTestThreeNodesThreeReplicas#testBalance [2] RocksDbSharedLogStorage#commitWriteBatch was: Under intensive transactional load (see test [1]) the duration of fsync of Raft log storage [2] can exceed 1 second on local test runs. [1] ItTxDistributedTestThreeNodesThreeReplicas#testBalance [2] RocksDbSharedLogStorage#commitWriteBatch > Long fsync of Raft log storage > -- > > Key: IGNITE-20195 > URL: https://issues.apache.org/jira/browse/IGNITE-20195 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > Under intensive transactional load (see test [1]) the duration of fsync of > Raft log storage [2] can exceed 1 second on local test runs. To reproduce it, > you should turn on fsync on raft configuration mock. > [1] ItTxDistributedTestThreeNodesThreeReplicas#testBalance > [2] RocksDbSharedLogStorage#commitWriteBatch -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-19430) PartitionReplicaListenerTest.testReadOnlyGetAfterRowRewrite() misses an assertion
[
https://issues.apache.org/jira/browse/IGNITE-19430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev resolved IGNITE-19430.
--
Resolution: Fixed
> PartitionReplicaListenerTest.testReadOnlyGetAfterRowRewrite() misses an
> assertion
> -
>
> Key: IGNITE-19430
> URL: https://issues.apache.org/jira/browse/IGNITE-19430
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
>
> There is a fragment that looks like this:
> for (BinaryRow e : expected) {
> res.contains(e);
> }
> The result of contains() call is ignored. Maybe it should be asserted that
> contains() returns true, but if this assertion is added the test begins to
> fail.
> This has to be investigated.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20243) Introduce a Matcher for BinaryRows
[
https://issues.apache.org/jira/browse/IGNITE-20243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-20243:
-
Description:
In tests we often need to compare two given BinaryRows. Unfortunately, we
cannot use {{equals}} and, as a consequence, {{assertEquals}}, because
{{BinaryRow}} has two implemenations: {{Row}} and {{BinaryRowImpl}} which are
used interchangeably.
To solve this problem, it is proposed to add a Hamcrest Matcher, that will
allow to compare two {{BinaryRows}} regardless of their implementation.
was:
In tests we often need to compare two given {{BinaryRow}}s. Unfortunately, we
cannot use {{equals}} and, as a consequence, {{assertEquals}}, because
{{BinaryRow}} has two implemenations: {{Row}} and {{BinaryRowImpl}} which are
used interchangeably.
To solve this problem, it is proposed to add a Hamcrest Matcher, that will
allow to compare two {{BinaryRows}} regardless of their implementation.
> Introduce a Matcher for BinaryRows
> --
>
> Key: IGNITE-20243
> URL: https://issues.apache.org/jira/browse/IGNITE-20243
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Minor
> Labels: ignite-3
>
> In tests we often need to compare two given BinaryRows. Unfortunately, we
> cannot use {{equals}} and, as a consequence, {{assertEquals}}, because
> {{BinaryRow}} has two implemenations: {{Row}} and {{BinaryRowImpl}} which are
> used interchangeably.
> To solve this problem, it is proposed to add a Hamcrest Matcher, that will
> allow to compare two {{BinaryRows}} regardless of their implementation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20243) Introduce a Matcher for BinaryRows
[
https://issues.apache.org/jira/browse/IGNITE-20243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-20243:
-
Description:
In tests we often need to compare two given {{BinaryRow}}s. Unfortunately, we
cannot use {{equals}} and, as a consequence, {{assertEquals}}, because
{{BinaryRow}} has two implemenations: {{Row}} and {{BinaryRowImpl}} which are
used interchangeably.
To solve this problem, it is proposed to add a Hamcrest Matcher, that will
allow to compare two {{BinaryRows}} regardless of their implementation.
was:
In tests we often need to compare two given BinaryRows. Unfortunately, we
cannot use {{equals}} and, as a consequence, {{assertEquals}}, because
{{BinaryRow}} has two implemenations: {{Row}} and {{BinaryRowImpl}} which are
used interchangeably.
To solve this problem, it is proposed to add a Hamcrest Matcher, that will
allow to compare two {{BinaryRows}} regardless of their implementation.
> Introduce a Matcher for BinaryRows
> --
>
> Key: IGNITE-20243
> URL: https://issues.apache.org/jira/browse/IGNITE-20243
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Minor
> Labels: ignite-3
>
> In tests we often need to compare two given {{BinaryRow}}s. Unfortunately, we
> cannot use {{equals}} and, as a consequence, {{assertEquals}}, because
> {{BinaryRow}} has two implemenations: {{Row}} and {{BinaryRowImpl}} which are
> used interchangeably.
> To solve this problem, it is proposed to add a Hamcrest Matcher, that will
> allow to compare two {{BinaryRows}} regardless of their implementation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20243) Introduce a Matcher for BinaryRows
[
https://issues.apache.org/jira/browse/IGNITE-20243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-20243:
-
Description:
In tests we often need to compare two given BinaryRows. Unfortunately, we
cannot use {{equals}} and, as a consequence, {{assertEquals}}, because
{{BinaryRow}} has two implemenations: {{Row}} and {{BinaryRowImpl}} which are
used interchangeably.
To solve this problem, it is proposed to add a Hamcrest Matcher, that will
allow to compare two {{BinaryRows}} regardless of their implementation.
was:
In tests we often need to compare two given {{BinaryRow}}s. Unfortunately, we
cannot use {{equals}} and, as a consequence, {{assertEquals}}, because
{{BinaryRow}} has two implemenations: {{Row}} and {{BinaryRowImpl}} which are
used interchangeably.
To solve this problem, it is proposed to add a Hamcrest Matcher, that will
allow to compare two {{BinaryRows}} regardless of their implementation.
> Introduce a Matcher for BinaryRows
> --
>
> Key: IGNITE-20243
> URL: https://issues.apache.org/jira/browse/IGNITE-20243
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Minor
> Labels: ignite-3
>
> In tests we often need to compare two given BinaryRows. Unfortunately, we
> cannot use {{equals}} and, as a consequence, {{assertEquals}}, because
> {{BinaryRow}} has two implemenations: {{Row}} and {{BinaryRowImpl}} which are
> used interchangeably.
> To solve this problem, it is proposed to add a Hamcrest Matcher, that will
> allow to compare two {{BinaryRows}} regardless of their implementation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20243) Introduce a Matcher for BinaryRows
Aleksandr Polovtcev created IGNITE-20243:
Summary: Introduce a Matcher for BinaryRows
Key: IGNITE-20243
URL: https://issues.apache.org/jira/browse/IGNITE-20243
Project: Ignite
Issue Type: Task
Reporter: Aleksandr Polovtcev
Assignee: Aleksandr Polovtcev
In tests we often need to compare two given {{BinaryRow}}s. Unfortunately, we
cannot use {{equals}} and, as a consequence, {{assertEquals}}, because
{{BinaryRow}} has two implemenations: {{Row}} and {{BinaryRowImpl}} which are
used interchangeably.
To solve this problem, it is proposed to add a Hamcrest Matcher, that will
allow to compare two {{BinaryRows}} regardless of their implementation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20242) C++ 3.0: Retry outdated schema error
Pavel Tupitsyn created IGNITE-20242: --- Summary: C++ 3.0: Retry outdated schema error Key: IGNITE-20242 URL: https://issues.apache.org/jira/browse/IGNITE-20242 Project: Ignite Issue Type: Improvement Components: thin client Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 IGNITE-19397 introduces a special error code for outdated client schema. Detect this error, reload the latest schema and retry. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20241) C++ 3.0: Reload schema when unmapped Tuple field is detected
[ https://issues.apache.org/jira/browse/IGNITE-20241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-20241: --- Assignee: Igor Sapego (was: Pavel Tupitsyn) > C++ 3.0: Reload schema when unmapped Tuple field is detected > > > Key: IGNITE-20241 > URL: https://issues.apache.org/jira/browse/IGNITE-20241 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > See parent epic. Unmapped columns are not allowed; however, we must ensure > that the validation is performed against the latest schema, not the cached > one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20242) C++ 3.0: Retry outdated schema error
[ https://issues.apache.org/jira/browse/IGNITE-20242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-20242: --- Assignee: Igor Sapego (was: Pavel Tupitsyn) > C++ 3.0: Retry outdated schema error > > > Key: IGNITE-20242 > URL: https://issues.apache.org/jira/browse/IGNITE-20242 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > IGNITE-19397 introduces a special error code for outdated client schema. > Detect this error, reload the latest schema and retry. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20240) C++ 3.0: Reject Tuples with unmapped fields
[ https://issues.apache.org/jira/browse/IGNITE-20240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20240: Language: (was: C++) > C++ 3.0: Reject Tuples with unmapped fields > --- > > Key: IGNITE-20240 > URL: https://issues.apache.org/jira/browse/IGNITE-20240 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Tuples with unmapped fields should not be allowed in table APIs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20242) C++ 3.0: Retry outdated schema error
[ https://issues.apache.org/jira/browse/IGNITE-20242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20242: Component/s: platforms > C++ 3.0: Retry outdated schema error > > > Key: IGNITE-20242 > URL: https://issues.apache.org/jira/browse/IGNITE-20242 > Project: Ignite > Issue Type: Improvement > Components: platforms, 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 > > > IGNITE-19397 introduces a special error code for outdated client schema. > Detect this error, reload the latest schema and retry. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20242) C++ 3.0: Retry outdated schema error
[ https://issues.apache.org/jira/browse/IGNITE-20242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20242: Labels: ignite-3 (was: .NET ignite-3) > C++ 3.0: Retry outdated schema error > > > Key: IGNITE-20242 > URL: https://issues.apache.org/jira/browse/IGNITE-20242 > 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 > > > IGNITE-19397 introduces a special error code for outdated client schema. > Detect this error, reload the latest schema and retry. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20240) C++ 3.0: Reject Tuples with unmapped fields
[ https://issues.apache.org/jira/browse/IGNITE-20240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-20240: --- Assignee: Igor Sapego (was: Pavel Tupitsyn) > C++ 3.0: Reject Tuples with unmapped fields > --- > > Key: IGNITE-20240 > URL: https://issues.apache.org/jira/browse/IGNITE-20240 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Tuples and POCOs with unmapped fields should not be allowed in table APIs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20240) C++ 3.0: Reject Tuples with unmapped fields
[ https://issues.apache.org/jira/browse/IGNITE-20240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20240: Description: Tuples with unmapped fields should not be allowed in table APIs. (was: Tuples and POCOs with unmapped fields should not be allowed in table APIs.) > C++ 3.0: Reject Tuples with unmapped fields > --- > > Key: IGNITE-20240 > URL: https://issues.apache.org/jira/browse/IGNITE-20240 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Tuples with unmapped fields should not be allowed in table APIs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20241) C++ 3.0: Reload schema when unmapped Tuple field is detected
[ https://issues.apache.org/jira/browse/IGNITE-20241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20241: Labels: ignite-3 (was: .NET ignite-3) > C++ 3.0: Reload schema when unmapped Tuple field is detected > > > Key: IGNITE-20241 > URL: https://issues.apache.org/jira/browse/IGNITE-20241 > Project: Ignite > Issue Type: Improvement > Components: platforms, 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 > > > See parent epic. Unmapped columns are not allowed; however, we must ensure > that the validation is performed against the latest schema, not the cached > one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20241) C++ 3.0: Reload schema when unmapped Tuple field is detected
Pavel Tupitsyn created IGNITE-20241: --- Summary: C++ 3.0: Reload schema when unmapped Tuple field is detected Key: IGNITE-20241 URL: https://issues.apache.org/jira/browse/IGNITE-20241 Project: Ignite Issue Type: Improvement Components: platforms, thin client Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 See parent epic. Unmapped columns are not allowed; however, we must ensure that the validation is performed against the latest schema, not the cached one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20240) C++ 3.0: Reject Tuples with unmapped fields
[ https://issues.apache.org/jira/browse/IGNITE-20240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20240: Labels: ignite-3 (was: .NET ignite-3) > C++ 3.0: Reject Tuples with unmapped fields > --- > > Key: IGNITE-20240 > URL: https://issues.apache.org/jira/browse/IGNITE-20240 > Project: Ignite > Issue Type: Improvement > Components: platforms, 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 > > > Tuples and POCOs with unmapped fields should not be allowed in table APIs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20240) C++ 3.0: Reject Tuples with unmapped fields
Pavel Tupitsyn created IGNITE-20240: --- Summary: C++ 3.0: Reject Tuples with unmapped fields Key: IGNITE-20240 URL: https://issues.apache.org/jira/browse/IGNITE-20240 Project: Ignite Issue Type: Improvement Components: platforms, thin client Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 Tuples and POCOs with unmapped fields should not be allowed in table APIs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20240) C++ 3.0: Reject Tuples with unmapped fields
[ https://issues.apache.org/jira/browse/IGNITE-20240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20240: Language: C++ (was: C#) > C++ 3.0: Reject Tuples with unmapped fields > --- > > Key: IGNITE-20240 > URL: https://issues.apache.org/jira/browse/IGNITE-20240 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > Tuples and POCOs with unmapped fields should not be allowed in table APIs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (IGNITE-19834) Thin 3.0: Schema validation
[ https://issues.apache.org/jira/browse/IGNITE-19834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reopened IGNITE-19834: - > Thin 3.0: Schema validation > --- > > Key: IGNITE-19834 > URL: https://issues.apache.org/jira/browse/IGNITE-19834 > Project: Ignite > Issue Type: Epic > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > h2. Motivation > Current Ignite 3 behavior is inconsistent when user data has unmapped columns: > * POJO: unmapped columns (not in schema) are ignored; > * Tuple: unmapped columns are ignored on client, but cause exception on > server (when using server-side API from a Compute task). > We should ensure consistent and reliable behavior across all APIs and clients. > h2. Non-goals > * Validate column types (already handled by serializers) > * Deal with any other schema aspects (indexes, constraints) which are not > present on the client side > h2. Requirements > Incompatible rows must be rejected by all APIs (Record, KeyValue, > RecordBinary, KeyValueBinary): > * Unmapped columns are present; > * Columns without default value are missing. > * Validation should be performed by the server when possible. > * Unmapped columns should be validated by the client, because rows are > serialized according to the schema (server does not see unmapped columns). > h2. Design > h3. Case 1: Missing Columns > Already handled by the client and the server: > * Client sends noValueSet to indicate which columns were not provided by the > user; > * Server rejects rows when the column is not set by the user and does not > have a default value. > h3. Case 2: Unmapped Columns > *Server-side API* > * Fix Marshaller to reject POJOs with unmapped fields; > * Reject tuples from client connector when schema is outdated (see > explanation below). > *Client-side API* > Client serializes user rows according to the latest known schema. Unmapped > columns will not reach the server side. Therefore, the client must reject > unmapped columns in user rows (Tuples, POJOs). > However, there is no guarantee that the client always has the latest schema: > * Column might be removed on the server, but the client uses old schema and > validation passes when it should fail; > ** Solution: server rejects rows with outdated schema from the client. > * Column might be added on the server, but the client uses old schema and > validation fails when it should pass. > ** Solution: when an unmapped column is detected by the client, it should > request the latest schema and retry the validation to avoid false-positive > exceptions. > The fact that the server rejects rows with outdated schema from the client > also simplifies client schema synchronization logic - we won't have to deal > with things like IGNITE-19241 Java thin 3.0: propagate table schema updates > to client on write-only operations anymore. Client will simply reload the > schema when given a certain error code. > *Schemas and Transactions* > IEP-98 Schema Synchronization proposes a more complex logic of handling > schema updates within transactions. This may alter the way we validate > schemas on the server, but should not affect the client: if a given schema > version is observed by the client, any server node should be able to handle > this version potentially waiting for it to be installed before proceeding). > h2. Implementation Notes > Client and server APIs implement the same interfaces. Therefore, the same > tests should run against both APIs and ensure identical behavior (see > ItSqlSynchronousApiTest as an example of this approach). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20236) Get rid of DistributionZonesConfigurationSchema#defaultDataStorage
[ https://issues.apache.org/jira/browse/IGNITE-20236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17755387#comment-17755387 ] Roman Puchkovskiy commented on IGNITE-20236: The patch looks good to me > Get rid of DistributionZonesConfigurationSchema#defaultDataStorage > -- > > Key: IGNITE-20236 > URL: https://issues.apache.org/jira/browse/IGNITE-20236 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 40m > Remaining Estimate: 0h > > Since > *org.apache.ignite.internal.distributionzones.configuration.DistributionZonesConfigurationSchema* > will be deleted in IGNITE-20114, we need to do something with configuration > *DistributionZonesConfigurationSchema#defaultDataStorage*. > It is suggested to temporarily hardcode the current default value in the > *org.apache.ignite.internal.storage.DataStorageManager*. > A new solution is proposed to be implemented in NEW_TICKET. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20236) Get rid of DistributionZonesConfigurationSchema#defaultDataStorage
[ https://issues.apache.org/jira/browse/IGNITE-20236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-20236: - Reviewer: Roman Puchkovskiy > Get rid of DistributionZonesConfigurationSchema#defaultDataStorage > -- > > Key: IGNITE-20236 > URL: https://issues.apache.org/jira/browse/IGNITE-20236 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Since > *org.apache.ignite.internal.distributionzones.configuration.DistributionZonesConfigurationSchema* > will be deleted in IGNITE-20114, we need to do something with configuration > *DistributionZonesConfigurationSchema#defaultDataStorage*. > It is suggested to temporarily hardcode the current default value in the > *org.apache.ignite.internal.storage.DataStorageManager*. > A new solution is proposed to be implemented in NEW_TICKET. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20239) Sql. Remove row type transformations from SetOpConverterRule.
[ https://issues.apache.org/jira/browse/IGNITE-20239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20239: -- Description: `SetOpConverterRule` creates a rowType produced by set operation by means of `TypeFactory::leastRestrictive`. This should not be necessary because types of rows returned by inputs to set operation should be coerced at the validation stage by `SqlValidator`/ SetopOperandTypeChecker`. Remove calls to `TypeFactory::leastRestrictive` from `SetOpConverterRule` for both colocated and map/reduce versions of operators and use `rowType` returned by a set operator node. was: `SetOpConverterRule` creates a rowType produced by set operation by means of `TypeFactory::leastRestrictiveType`. This should not be necessary because types of rows returned by inputs to set operation should be coerced at the validation stage by `SqlValidator`/ SetopOperandTypeChecker`. Remove calls to `TypeFactory::leastRestrictiveType` from `SetOpConverterRule` for both colocated and map/reduce versions of operators and use `rowType` returned by a set operator node. > Sql. Remove row type transformations from SetOpConverterRule. > -- > > Key: IGNITE-20239 > URL: https://issues.apache.org/jira/browse/IGNITE-20239 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > `SetOpConverterRule` creates a rowType produced by set operation by means of > `TypeFactory::leastRestrictive`. This should not be necessary because types > of rows returned by inputs to set operation should be coerced at the > validation stage by `SqlValidator`/ SetopOperandTypeChecker`. > Remove calls to `TypeFactory::leastRestrictive` from `SetOpConverterRule` for > both colocated and map/reduce versions of operators and use `rowType` > returned by a set operator node. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20239) Sql. Remove row type transformations from SetOpConverterRule.
[ https://issues.apache.org/jira/browse/IGNITE-20239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20239: -- Description: `SetOpConverterRule` creates a rowType produced by set operation by means of `TypeFactory::leastRestrictiveType`. This should not be necessary because types of rows returned by inputs to set operation should be coerced at the validation stage by `SqlValidator`/ SetopOperandTypeChecker`. Remove calls to `TypeFactory::leastRestrictiveType` from `SetOpConverterRule` for both colocated and map/reduce versions of operators and use `rowType` returned by a set operator node. was: `SetOpConverterRule` creates a rowType produced by set operation by means of `TypeFactory::leastRestrictiveType`. This should not be necessary because the types of rows returned by inputs to set operation should have been already been coerced at the validation stage by `SqlValidator`/ SetopOperandTypeChecker`. Remove calls to `TypeFactory::leastRestrictiveType` from `SetOpConverterRule` for both colocated and map/reduce versions of operators and use `rowType` returned by a set operator node. > Sql. Remove row type transformations from SetOpConverterRule. > -- > > Key: IGNITE-20239 > URL: https://issues.apache.org/jira/browse/IGNITE-20239 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > `SetOpConverterRule` creates a rowType produced by set operation by means of > `TypeFactory::leastRestrictiveType`. This should not be necessary because > types of rows returned by inputs to set operation should be coerced at the > validation stage by `SqlValidator`/ SetopOperandTypeChecker`. > Remove calls to `TypeFactory::leastRestrictiveType` from `SetOpConverterRule` > for both colocated and map/reduce versions of operators and use `rowType` > returned by a set operator node. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20239) Sql. Remove row type transformations from SetOpConverterRule.
[ https://issues.apache.org/jira/browse/IGNITE-20239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20239: -- Summary: Sql. Remove row type transformations from SetOpConverterRule. (was: Sql. SetOpConverterRule. Remove row type transformations.) > Sql. Remove row type transformations from SetOpConverterRule. > -- > > Key: IGNITE-20239 > URL: https://issues.apache.org/jira/browse/IGNITE-20239 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > `SetOpConverterRule` creates a rowType produced by set operation by means of > `TypeFactory::leastRestrictiveType`. This should not be necessary because the > types of rows returned by inputs to set operation should have been already > been coerced at the validation stage by `SqlValidator`/ > SetopOperandTypeChecker`. > Remove calls to `TypeFactory::leastRestrictiveType` from `SetOpConverterRule` > for both colocated and map/reduce versions of operators and use `rowType` > returned by a set operator node. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20239) Sql. SetOpConverterRule. Remove row type transformations.
[ https://issues.apache.org/jira/browse/IGNITE-20239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20239: -- Summary: Sql. SetOpConverterRule. Remove row type transformations. (was: Sql. SetOpConverterRule. ) > Sql. SetOpConverterRule. Remove row type transformations. > -- > > Key: IGNITE-20239 > URL: https://issues.apache.org/jira/browse/IGNITE-20239 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > `SetOpConverterRule` creates a rowType produced by set operation by means of > `TypeFactory::leastRestrictiveType`. This should not be necessary because the > types of rows returned by inputs to set operation should have been already > been coerced at the validation stage by `SqlValidator`/ > SetopOperandTypeChecker`. > Remove calls to `TypeFactory::leastRestrictiveType` from `SetOpConverterRule` > for both colocated and map/reduce versions of operators and use `rowType` > returned by a set operator node. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20239) Sql. SetOpConverterRule.
Maksim Zhuravkov created IGNITE-20239: - Summary: Sql. SetOpConverterRule. Key: IGNITE-20239 URL: https://issues.apache.org/jira/browse/IGNITE-20239 Project: Ignite Issue Type: Improvement Components: sql Reporter: Maksim Zhuravkov Fix For: 3.0.0-beta2 `SetOpConverterRule` creates a rowType produced by set operation by means of `TypeFactory::leastRestrictiveType`. This should not be necessary because the types of rows returned by inputs to set operation should have been already been coerced at the validation stage by `SqlValidator`/ SetopOperandTypeChecker`. Remove calls to `TypeFactory::leastRestrictiveType` from `SetOpConverterRule` for both colocated and map/reduce versions of operators and use `rowType` returned by a set operator node. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17842) .NET: LINQ GroupBy with anonymous type produces invalid SQL
[
https://issues.apache.org/jira/browse/IGNITE-17842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-17842:
Affects Version/s: 2.15
> .NET: LINQ GroupBy with anonymous type produces invalid SQL
> ---
>
> Key: IGNITE-17842
> URL: https://issues.apache.org/jira/browse/IGNITE-17842
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.15
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
>
> To reproduce, change *TestGroupBy* like this:
> {code}
> CollectionAssert.AreEquivalent(new[] { 1000, 1001 },
> persons.GroupBy(x => new { I0 = x.Value.OrganizationId
> }).Select(x => x.Key.I0).ToArray());
> {code}
> Result:
> {code}
> Apache.Ignite.Core.Common.IgniteException : Failed to parse query. Column
> "_T0.I0" not found; SQL statement:
> select _T0.I0 from PERSON_ORG_SCHEMA.Person as _T0 group by
> (_T0.ORGANIZATIONID)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
