[jira] [Updated] (IGNITE-19313) Update IgniteReleasedVersion for compatibility tests to 2.15.0
[ https://issues.apache.org/jira/browse/IGNITE-19313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-19313: --- Parent: IGNITE-19314 Issue Type: Sub-task (was: Task) > Update IgniteReleasedVersion for compatibility tests to 2.15.0 > -- > > Key: IGNITE-19313 > URL: https://issues.apache.org/jira/browse/IGNITE-19313 > Project: Ignite > Issue Type: Sub-task >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > > Update IgniteReleasedVersion for compatibility tests to 2.15.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19311) Update ignite-2.15 branch version to 2.15.0
[ https://issues.apache.org/jira/browse/IGNITE-19311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-19311: --- Parent: IGNITE-19314 Issue Type: Sub-task (was: Task) > Update ignite-2.15 branch version to 2.15.0 > --- > > Key: IGNITE-19311 > URL: https://issues.apache.org/jira/browse/IGNITE-19311 > Project: Ignite > Issue Type: Sub-task >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > > Update ignite-2.15 branch version to 2.15.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19312) Update Apache Ignite 2.15 release notes
[ https://issues.apache.org/jira/browse/IGNITE-19312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-19312: --- Parent: IGNITE-19314 Issue Type: Sub-task (was: Task) > Update Apache Ignite 2.15 release notes > --- > > Key: IGNITE-19312 > URL: https://issues.apache.org/jira/browse/IGNITE-19312 > Project: Ignite > Issue Type: Sub-task >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > > Update Apache Ignite 2.15 release notes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19310) Update Ignite version to 2.16.0-SNAPSHOT
[ https://issues.apache.org/jira/browse/IGNITE-19310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-19310: --- Parent: IGNITE-19314 Issue Type: Sub-task (was: Task) > Update Ignite version to 2.16.0-SNAPSHOT > > > Key: IGNITE-19310 > URL: https://issues.apache.org/jira/browse/IGNITE-19310 > Project: Ignite > Issue Type: Sub-task >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > > Update Ignite version to 2.16.0-SNAPSHOT -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19309) Update Linux packages version to 2.15
[ https://issues.apache.org/jira/browse/IGNITE-19309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-19309: --- Parent: IGNITE-19314 Issue Type: Sub-task (was: Task) > Update Linux packages version to 2.15 > - > > Key: IGNITE-19309 > URL: https://issues.apache.org/jira/browse/IGNITE-19309 > Project: Ignite > Issue Type: Sub-task >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > > Update Linux packages version to 2.15 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19308) Change copyright to 2023
[ https://issues.apache.org/jira/browse/IGNITE-19308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-19308: --- Parent: IGNITE-19314 Issue Type: Sub-task (was: Task) > Change copyright to 2023 > > > Key: IGNITE-19308 > URL: https://issues.apache.org/jira/browse/IGNITE-19308 > Project: Ignite > Issue Type: Sub-task >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > > Change copyright to 2023 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19314) Release 2.15
Aleksey Plekhanov created IGNITE-19314: -- Summary: Release 2.15 Key: IGNITE-19314 URL: https://issues.apache.org/jira/browse/IGNITE-19314 Project: Ignite Issue Type: Task Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov This is umbrella ticket for 2.15 release process. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16985) Design table management flow (part 1)
[ https://issues.apache.org/jira/browse/IGNITE-16985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16985: - Ignite Flags: (was: Docs Required,Release Notes Required) > Design table management flow (part 1) > - > > Key: IGNITE-16985 > URL: https://issues.apache.org/jira/browse/IGNITE-16985 > Project: Ignite > Issue Type: Task >Reporter: Alexander Lapin >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > Attachments: VersionedValuesUpdates.svg, VersionedValuesUpdates.yuml, > flow.png, flow.puml, onTableCreate.svg, onTableCreate.yuml, onTableDrop.svg, > onTableDrop.yuml, table.svg, table.yuml > > > As a part of the issue planed: > # Draw a time diagram of all operations: createTable(), dropTable(), > table(), tables(). > # Emphases of correctness work of causality tokens: tablesByIdVv. > # Reflect cross components interactions. Components: Schema manager, SQL > manager (SqlQueryProcessor), Affinity manager (it is not dedicated for now). > > The task for this ticket is to make a detailed diagram of the current flow, > to ease the design itself. > Definition of done: > We have detailed and clear description of table manager flows and the ticket > IGNITE-18989 is enriched with details about the flaws we want to fix. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18916) .NET: Thin 3.0 Add SQL tests with UUID columns
[ https://issues.apache.org/jira/browse/IGNITE-18916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713890#comment-17713890 ] Pavel Tupitsyn commented on IGNITE-18916: - [~isapego] please review. > .NET: Thin 3.0 Add SQL tests with UUID columns > -- > > Key: IGNITE-18916 > URL: https://issues.apache.org/jira/browse/IGNITE-18916 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Now when UUID support is implemented for SQL core > (https://issues.apache.org/jira/browse/IGNITE-16376), we need to add tests > with UUID columns to clients to ensure that everything works well in clients. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18958) Implement handling of lease grant responses on placement driver side
[
https://issues.apache.org/jira/browse/IGNITE-18958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713737#comment-17713737
]
Vladislav Pyatkov commented on IGNITE-18958:
Merged 4fd5c8e55e04f374d35ce686028176bbbfd67da4
> Implement handling of lease grant responses on placement driver side
>
>
> Key: IGNITE-18958
> URL: https://issues.apache.org/jira/browse/IGNITE-18958
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The active actor of placement driver should handle lease grant responses from
> replicas, other nodes of placement driver should discard such messages.
> Lease grant response should either contain "ok" acceptance flag, meaning that
> the replica (leaseholder candidate) accepted the assigned role of primary
> replica, or redirect proposal, meaning that the replica proposes another
> node, which is a member of replication group, for this role. In the first
> case, the placement driver should make the invoke to meta storage in order to
> promote the leaseholder candidate to actual leaseholder, with the same lease
> expiration timestamp as it was initiated for candidate. In the second case,
> the placement driver should consider the redirect proposal using leaseholder
> balancer (see IGNITE-18879 ) and make decision to assign the candidate to the
> proposed node (and send a new LeaseGrantMessage to it) or force assign the
> leaseholder role to the same candidate.
> Pseudocode:
>
> {code:java}
> onLeaseGrantResponse(leaseGrantResponse) {
> leaseExpirationTime = leaseGrantResponse.leaseExpirationTime
> if (leaseGrantResponse.redirectProposal) {
> leaseCandidateNew =
> leaseBalancer.considerRedirectProposal(leaseGrantResponse.sender,
> leaseGrantResponse.redirectProposal);
> if (invokeMetaStorage(grantLease(leaseCandidateNew,
> leaseExpirationTime))) {
> sendLeaseGrantMessage(leaseCandidateNew, leaseExpirationTime,
> force) // force lease grant message
> }
> } else {
> assert(leaseGrantResponse.accepted)
> leaseholder = leaseGrantResponse.sender
> invokeMetaStorage(leaseConfirmed(leaseholder, leaseExpirationTime))
> }
> }{code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19313) Update IgniteReleasedVersion for compatibility tests to 2.15.0
Aleksey Plekhanov created IGNITE-19313: -- Summary: Update IgniteReleasedVersion for compatibility tests to 2.15.0 Key: IGNITE-19313 URL: https://issues.apache.org/jira/browse/IGNITE-19313 Project: Ignite Issue Type: Task Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Update IgniteReleasedVersion for compatibility tests to 2.15.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19312) Update Apache Ignite 2.15 release notes
Aleksey Plekhanov created IGNITE-19312: -- Summary: Update Apache Ignite 2.15 release notes Key: IGNITE-19312 URL: https://issues.apache.org/jira/browse/IGNITE-19312 Project: Ignite Issue Type: Task Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Update Apache Ignite 2.15 release notes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19311) Update ignite-2.15 branch version to 2.15.0
Aleksey Plekhanov created IGNITE-19311: -- Summary: Update ignite-2.15 branch version to 2.15.0 Key: IGNITE-19311 URL: https://issues.apache.org/jira/browse/IGNITE-19311 Project: Ignite Issue Type: Task Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Update ignite-2.15 branch version to 2.15.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19310) Update Ignite version to 2.16.0-SNAPSHOT
Aleksey Plekhanov created IGNITE-19310: -- Summary: Update Ignite version to 2.16.0-SNAPSHOT Key: IGNITE-19310 URL: https://issues.apache.org/jira/browse/IGNITE-19310 Project: Ignite Issue Type: Task Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Update Ignite version to 2.16.0-SNAPSHOT -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19309) Update Linux packages version to 2.15
Aleksey Plekhanov created IGNITE-19309: -- Summary: Update Linux packages version to 2.15 Key: IGNITE-19309 URL: https://issues.apache.org/jira/browse/IGNITE-19309 Project: Ignite Issue Type: Task Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Update Linux packages version to 2.15 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19308) Change copyright to 2023
Aleksey Plekhanov created IGNITE-19308: -- Summary: Change copyright to 2023 Key: IGNITE-19308 URL: https://issues.apache.org/jira/browse/IGNITE-19308 Project: Ignite Issue Type: Task Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Change copyright to 2023 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19297) Cleanup assembly files
[
https://issues.apache.org/jira/browse/IGNITE-19297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713684#comment-17713684
]
Ignite TC Bot commented on IGNITE-19297:
{panel:title=Branch: [pull/10652/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10652/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: Basic Tests*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7142869&buildTypeId=IgniteTests24Java8_RunBasicTests]
> Cleanup assembly files
> --
>
> Key: IGNITE-19297
> URL: https://issues.apache.org/jira/browse/IGNITE-19297
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.15
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> # Hadoop module was discontinued, but we still have file
> release-apache-ignite-hadoop.xml with references to some non-existent files
> (and related files LICENSE_HADOOP, NOTICE_HADOOP).
> # There are some dependencies to hadoop-common from examples (perhaps still
> required) and parent.pom (parhaps not required anymore).
> # dependencies-apache-ignite-slim.xml contains ignite-hadoop as exclusion.
> # LICENSE, parent.pom and snaptree-bsd-license.txt contain a mention of
> snaptree, which is not in ignite codebase anymore
> # LICENSE contains a mention of "
> org.apache.ignite.internal.processors.hadoop.books" package, which is not
> exists now (but corresponding license still relevant to examples, since file
> alice-in-wonderland.txt now can be found there)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19048) Extract Subscribers and Accumulators to core module
[
https://issues.apache.org/jira/browse/IGNITE-19048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Pochatkin updated IGNITE-19048:
---
Summary: Extract Subscribers and Accumulators to core module (was: Extract
Subscribers and Accumulators to metastorage-api module)
> Extract Subscribers and Accumulators to core module
> ---
>
> Key: IGNITE-19048
> URL: https://issues.apache.org/jira/browse/IGNITE-19048
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Pochatkin
>Assignee: Mikhail Pochatkin
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In IGNITE-18870 was introduced abstractions
> *org.apache.ignite.internal.deployunit.metastore.Accumulator* and
> {*}org.apache.ignite.internal.deployunit.metastore.EntrySubscriber{*}. These
> abstractions may help to avoid boilerplate code in context of Subscriber
> implementation for prefix method of metastore and another Subscribers.
> So, need to extract it and replace existed Subscribers by new one.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19048) Extract Subscribers and Accumulators to metastorage-api module
[
https://issues.apache.org/jira/browse/IGNITE-19048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Pochatkin updated IGNITE-19048:
---
Description:
In IGNITE-18870 was introduced abstractions
*org.apache.ignite.internal.deployunit.metastore.Accumulator* and
{*}org.apache.ignite.internal.deployunit.metastore.EntrySubscriber{*}. These
abstractions may help to avoid boilerplate code in context of Subscriber
implementation for prefix method of metastore and another Subscribers.
So, need to extract it and replace existed Subscribers by new one.
was:In IGNITE-18870 was introduced abstractions
org.apache.ignite.internal.deployunit.metastore.Accumulator and
org.apache.ignite.internal.deployunit.metastore.EntrySubscriber. These
abstractions may help to avoid boilerplate code in context of Subscriber
implementation for prefix method of metastore. So, need to extract it and
replace existed Subscribers by new one.
> Extract Subscribers and Accumulators to metastorage-api module
> --
>
> Key: IGNITE-19048
> URL: https://issues.apache.org/jira/browse/IGNITE-19048
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Pochatkin
>Assignee: Mikhail Pochatkin
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In IGNITE-18870 was introduced abstractions
> *org.apache.ignite.internal.deployunit.metastore.Accumulator* and
> {*}org.apache.ignite.internal.deployunit.metastore.EntrySubscriber{*}. These
> abstractions may help to avoid boilerplate code in context of Subscriber
> implementation for prefix method of metastore and another Subscribers.
> So, need to extract it and replace existed Subscribers by new one.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18958) Implement handling of lease grant responses on placement driver side
[
https://issues.apache.org/jira/browse/IGNITE-18958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713658#comment-17713658
]
Kirill Gusakov commented on IGNITE-18958:
-
LGTM
> Implement handling of lease grant responses on placement driver side
>
>
> Key: IGNITE-18958
> URL: https://issues.apache.org/jira/browse/IGNITE-18958
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The active actor of placement driver should handle lease grant responses from
> replicas, other nodes of placement driver should discard such messages.
> Lease grant response should either contain "ok" acceptance flag, meaning that
> the replica (leaseholder candidate) accepted the assigned role of primary
> replica, or redirect proposal, meaning that the replica proposes another
> node, which is a member of replication group, for this role. In the first
> case, the placement driver should make the invoke to meta storage in order to
> promote the leaseholder candidate to actual leaseholder, with the same lease
> expiration timestamp as it was initiated for candidate. In the second case,
> the placement driver should consider the redirect proposal using leaseholder
> balancer (see IGNITE-18879 ) and make decision to assign the candidate to the
> proposed node (and send a new LeaseGrantMessage to it) or force assign the
> leaseholder role to the same candidate.
> Pseudocode:
>
> {code:java}
> onLeaseGrantResponse(leaseGrantResponse) {
> leaseExpirationTime = leaseGrantResponse.leaseExpirationTime
> if (leaseGrantResponse.redirectProposal) {
> leaseCandidateNew =
> leaseBalancer.considerRedirectProposal(leaseGrantResponse.sender,
> leaseGrantResponse.redirectProposal);
> if (invokeMetaStorage(grantLease(leaseCandidateNew,
> leaseExpirationTime))) {
> sendLeaseGrantMessage(leaseCandidateNew, leaseExpirationTime,
> force) // force lease grant message
> }
> } else {
> assert(leaseGrantResponse.accepted)
> leaseholder = leaseGrantResponse.sender
> invokeMetaStorage(leaseConfirmed(leaseholder, leaseExpirationTime))
> }
> }{code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19307) Sql. Set operations: Conversion to relational algebra failed to preserve datatypes.
[
https://issues.apache.org/jira/browse/IGNITE-19307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-19307:
--
Summary: Sql. Set operations: Conversion to relational algebra failed to
preserve datatypes. (was: Sql. Set operation: Conversion to relational algebra
failed to preserve datatypes.)
> Sql. Set operations: Conversion to relational algebra failed to preserve
> datatypes.
> ---
>
> Key: IGNITE-19307
> URL: https://issues.apache.org/jira/browse/IGNITE-19307
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The following query fails with "Conversion to relational algebra failed to
> preserve datatypes"
> {code:java}
> @Test
> public void test() {
>sql("CREATE TABLE tt (id integer primary key, test_key integer)");
>sql("INSERT INTO tt VALUES(1, 100)");
>assertQuery("SELECT test_key FROM tt UNION ALL SELECT '1000'").check();
> }
> {code}
> Although the same expression with literal works as expected:
> {code:java}
> @Test
> public void test2() {
>assertQuery("SELECT 100 UNION ALL SELECT '1000'").check();
> }
> {code}
> Error:
> {code:java}
> java.lang.AssertionError: Conversion to relational algebra failed to preserve
> datatypes:
> validated type:
> RecordType(VARCHAR CHARACTER SET "UTF-8" NOT NULL TEST_KEY) NOT NULL
> converted type:
> RecordType(VARCHAR CHARACTER SET "UTF-8" EXPR$0) NOT NULL
> rel:
> LogicalUnion(all=[true])
> LogicalProject(EXPR$0=[CAST($1):VARCHAR CHARACTER SET "UTF-8"])
> IgniteLogicalTableScan(table=[[PUBLIC, TT]])
> LogicalValues(tuples=[[{ _UTF-8'1000' }]])
> {code}
> When both side of set operation are columns query also works:
> {code:java}
> @Test
> public void test3() {
> sql("CREATE TABLE tt (id integer primary key, test_key integer)");
> sql("CREATE TABLE ttt (id integer primary key, test_key varchar)");
> sql("INSERT INTO tt VALUES(1, 100)");
> sql("INSERT INTO ttt VALUES(1, '200')");
> assertQuery("SELECT test_key FROM tt UNION ALL SELECT test_key FROM
> ttt").check();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19307) Sql. Set operation: Conversion to relational algebra failed to preserve datatypes.
[
https://issues.apache.org/jira/browse/IGNITE-19307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-19307:
--
Description:
The following query fails with "Conversion to relational algebra failed to
preserve datatypes"
{code:java}
@Test
public void test() {
sql("CREATE TABLE tt (id integer primary key, test_key integer)");
sql("INSERT INTO tt VALUES(1, 100)");
assertQuery("SELECT test_key FROM tt UNION ALL SELECT '1000'").check();
}
{code}
Although the same expression with literal works as expected:
{code:java}
@Test
public void test2() {
assertQuery("SELECT 100 UNION ALL SELECT '1000'").check();
}
{code}
Error:
{code:java}
java.lang.AssertionError: Conversion to relational algebra failed to preserve
datatypes:
validated type:
RecordType(VARCHAR CHARACTER SET "UTF-8" NOT NULL TEST_KEY) NOT NULL
converted type:
RecordType(VARCHAR CHARACTER SET "UTF-8" EXPR$0) NOT NULL
rel:
LogicalUnion(all=[true])
LogicalProject(EXPR$0=[CAST($1):VARCHAR CHARACTER SET "UTF-8"])
IgniteLogicalTableScan(table=[[PUBLIC, TT]])
LogicalValues(tuples=[[{ _UTF-8'1000' }]])
{code}
When both side of set operation are columns query also works:
{code:java}
@Test
public void test3() {
sql("CREATE TABLE tt (id integer primary key, test_key integer)");
sql("CREATE TABLE ttt (id integer primary key, test_key varchar)");
sql("INSERT INTO tt VALUES(1, 100)");
sql("INSERT INTO ttt VALUES(1, '200')");
assertQuery("SELECT test_key FROM tt UNION ALL SELECT test_key FROM
ttt").check();
}
{code}
was:
The following query fails with "Conversion to relational algebra failed to
preserve datatypes"
{code:java}
@Test
public void test() {
sql("CREATE TABLE tt (id integer primary key, test_key integer)");
sql("INSERT INTO tt VALUES(1, 100)");
assertQuery("SELECT test_key FROM tt UNION ALL SELECT '1000'").check();
}
{code}
Although the same expression with literal works as expected:
{code:java}
@Test
public void test2() {
assertQuery("SELECT 100 UNION ALL SELECT '1000'").check();
}
{code}
Error:
{code:java}
java.lang.AssertionError: Conversion to relational algebra failed to preserve
datatypes:
validated type:
RecordType(VARCHAR CHARACTER SET "UTF-8" NOT NULL TEST_KEY) NOT NULL
converted type:
RecordType(VARCHAR CHARACTER SET "UTF-8" EXPR$0) NOT NULL
rel:
LogicalUnion(all=[true])
LogicalProject(EXPR$0=[CAST($1):VARCHAR CHARACTER SET "UTF-8"])
IgniteLogicalTableScan(table=[[PUBLIC, TT]])
LogicalValues(tuples=[[{ _UTF-8'1000' }]])
{code}
When both side of set operation are columns query also works:
{code:java}
@Test
public void test3() {
sql("CREATE TABLE tt (id integer primary key, test_key integer)");
sql("CREATE TABLE ttt (id integer primary key, test_key varchar)");
sql("INSERT INTO tt VALUES(1, 100)");
sql("INSERT INTO ttt VALUES(1, '200')");
assertQuery("SELECT test_key FROM tt UNION ALL SELECT test_key FROM
ttt").check();
}
{code}
> Sql. Set operation: Conversion to relational algebra failed to preserve
> datatypes.
> --
>
> Key: IGNITE-19307
> URL: https://issues.apache.org/jira/browse/IGNITE-19307
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The following query fails with "Conversion to relational algebra failed to
> preserve datatypes"
> {code:java}
> @Test
> public void test() {
>sql("CREATE TABLE tt (id integer primary key, test_key integer)");
>sql("INSERT INTO tt VALUES(1, 100)");
>assertQuery("SELECT test_key FROM tt UNION ALL SELECT '1000'").check();
> }
> {code}
> Although the same expression with literal works as expected:
> {code:java}
> @Test
> public void test2() {
>assertQuery("SELECT 100 UNION ALL SELECT '1000'").check();
> }
> {code}
> Error:
> {code:java}
> java.lang.AssertionError: Conversion to relational algebra failed to preserve
> datatypes:
> validated type:
> RecordType(VARCHAR CHARACTER SET "UTF-8" NOT NULL TEST_KEY) NOT NULL
> converted type:
> RecordType(VARCHAR CHARACTER SET "UTF-8" EXPR$0) NOT NULL
> rel:
> LogicalUnion(all=[true])
> LogicalProject(EXPR$0=[CAST($1):VARCHAR CHARACTER SET "UTF-8"])
> IgniteLogicalTableScan(table=[[PUBLIC, TT]])
> LogicalValues(tuples=[[{ _UTF-8'1000' }]])
> {code}
> When both side of set operation are columns query also works:
> {code:java}
> @Test
> public void test3() {
> sql("CREATE TABLE tt (id integer primary key, test_key integer)");
> sql("CREATE TABLE ttt (id integer primary key, test_key varchar)");
> sql("INSERT INTO tt VALUES(1, 100)");
> sql("INSERT INTO ttt VALUES(1, '200')");
> assertQuery("SELECT test_k
[jira] [Updated] (IGNITE-19307) Sql. Set operation: Conversion to relational algebra failed to preserve datatypes.
[
https://issues.apache.org/jira/browse/IGNITE-19307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-19307:
--
Description:
The following query fails with "Conversion to relational algebra failed to
preserve datatypes"
{code:java}
@Test
public void test() {
sql("CREATE TABLE tt (id integer primary key, test_key integer)");
sql("INSERT INTO tt VALUES(1, 100)");
assertQuery("SELECT test_key FROM tt UNION ALL SELECT '1000'").check();
}
{code}
Although the same expression with literal works as expected:
{code:java}
@Test
public void test2() {
assertQuery("SELECT 100 UNION ALL SELECT '1000'").check();
}
{code}
Error:
{code:java}
java.lang.AssertionError: Conversion to relational algebra failed to preserve
datatypes:
validated type:
RecordType(VARCHAR CHARACTER SET "UTF-8" NOT NULL TEST_KEY) NOT NULL
converted type:
RecordType(VARCHAR CHARACTER SET "UTF-8" EXPR$0) NOT NULL
rel:
LogicalUnion(all=[true])
LogicalProject(EXPR$0=[CAST($1):VARCHAR CHARACTER SET "UTF-8"])
IgniteLogicalTableScan(table=[[PUBLIC, TT]])
LogicalValues(tuples=[[{ _UTF-8'1000' }]])
{code}
When both side of set operation are columns query also works:
{code:java}
@Test
public void test3() {
sql("CREATE TABLE tt (id integer primary key, test_key integer)");
sql("CREATE TABLE ttt (id integer primary key, test_key varchar)");
sql("INSERT INTO tt VALUES(1, 100)");
sql("INSERT INTO ttt VALUES(1, '200')");
assertQuery("SELECT test_key FROM tt UNION ALL SELECT test_key FROM
ttt").check();
}
{code}
was:
The following query fails with "Conversion to relational algebra failed to
preserve datatypes"
{code:java}
@Test
public void test() {
sql("CREATE TABLE tt (id integer primary key, test_key integer)");
sql("INSERT INTO tt VALUES(1, 100)");
assertQuery("SELECT test_key FROM tt UNION ALL SELECT '1000'").check();
}
{code}
Although the same expression with literal works as expected:
{code:java}
@Test
public void test2() {
assertQuery("SELECT 100 UNION ALL SELECT '1000'").check();
}
{code}
Error:
{code:java}
java.lang.AssertionError: Conversion to relational algebra failed to preserve
datatypes:
validated type:
RecordType(VARCHAR CHARACTER SET "UTF-8" NOT NULL TEST_KEY) NOT NULL
converted type:
RecordType(VARCHAR CHARACTER SET "UTF-8" EXPR$0) NOT NULL
rel:
LogicalUnion(all=[true])
LogicalProject(EXPR$0=[CAST($1):VARCHAR CHARACTER SET "UTF-8"])
IgniteLogicalTableScan(table=[[PUBLIC, TT]])
LogicalValues(tuples=[[{ _UTF-8'1000' }]])
{code}
> Sql. Set operation: Conversion to relational algebra failed to preserve
> datatypes.
> --
>
> Key: IGNITE-19307
> URL: https://issues.apache.org/jira/browse/IGNITE-19307
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The following query fails with "Conversion to relational algebra failed to
> preserve datatypes"
> {code:java}
> @Test
> public void test() {
>sql("CREATE TABLE tt (id integer primary key, test_key integer)");
>sql("INSERT INTO tt VALUES(1, 100)");
>assertQuery("SELECT test_key FROM tt UNION ALL SELECT '1000'").check();
> }
> {code}
> Although the same expression with literal works as expected:
> {code:java}
> @Test
> public void test2() {
>assertQuery("SELECT 100 UNION ALL SELECT '1000'").check();
> }
> {code}
> Error:
> {code:java}
> java.lang.AssertionError: Conversion to relational algebra failed to preserve
> datatypes:
> validated type:
> RecordType(VARCHAR CHARACTER SET "UTF-8" NOT NULL TEST_KEY) NOT NULL
> converted type:
> RecordType(VARCHAR CHARACTER SET "UTF-8" EXPR$0) NOT NULL
> rel:
> LogicalUnion(all=[true])
> LogicalProject(EXPR$0=[CAST($1):VARCHAR CHARACTER SET "UTF-8"])
> IgniteLogicalTableScan(table=[[PUBLIC, TT]])
> LogicalValues(tuples=[[{ _UTF-8'1000' }]])
> {code}
> When both side of set operation are columns query also works:
> {code:java}
> @Test
> public void test3() {
> sql("CREATE TABLE tt (id integer primary key, test_key integer)");
> sql("CREATE TABLE ttt (id integer primary key, test_key varchar)");
> sql("INSERT INTO tt VALUES(1, 100)");
> sql("INSERT INTO ttt VALUES(1, '200')");
> assertQuery("SELECT test_key FROM tt UNION ALL SELECT test_key FROM
> ttt").check();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19307) Sql. Set operation: Conversion to relational algebra failed to preserve datatypes.
[
https://issues.apache.org/jira/browse/IGNITE-19307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-19307:
--
Labels: ignite-3 (was: )
> Sql. Set operation: Conversion to relational algebra failed to preserve
> datatypes.
> --
>
> Key: IGNITE-19307
> URL: https://issues.apache.org/jira/browse/IGNITE-19307
> Project: Ignite
> Issue Type: Bug
> Components: sql
> Environment: The following query fails with "Conversion to relational
> algebra failed to preserve datatypes"
> {code:java}
> @Test
> public void test() {
>sql("CREATE TABLE tt (id integer primary key, test_key integer)");
>sql("INSERT INTO tt VALUES(1, 100)");
>assertQuery("SELECT test_key FROM tt UNION ALL SELECT '1000'").check();
> }
> {code}
> Although the same expression with literal works as expected:
> {code:java}
> @Test
> public void test2() {
>assertQuery("SELECT 100 UNION ALL SELECT '1000'").check();
> }
> {code}
> Error:
> {code:java}
> java.lang.AssertionError: Conversion to relational algebra failed to preserve
> datatypes:
> validated type:
> RecordType(VARCHAR CHARACTER SET "UTF-8" NOT NULL TEST_KEY) NOT NULL
> converted type:
> RecordType(VARCHAR CHARACTER SET "UTF-8" EXPR$0) NOT NULL
> rel:
> LogicalUnion(all=[true])
> LogicalProject(EXPR$0=[CAST($1):VARCHAR CHARACTER SET "UTF-8"])
> IgniteLogicalTableScan(table=[[PUBLIC, TT]])
> LogicalValues(tuples=[[{ _UTF-8'1000' }]])
> {code}
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19307) Sql. Set operation: Conversion to relational algebra failed to preserve datatypes.
[
https://issues.apache.org/jira/browse/IGNITE-19307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-19307:
--
Description:
The following query fails with "Conversion to relational algebra failed to
preserve datatypes"
{code:java}
@Test
public void test() {
sql("CREATE TABLE tt (id integer primary key, test_key integer)");
sql("INSERT INTO tt VALUES(1, 100)");
assertQuery("SELECT test_key FROM tt UNION ALL SELECT '1000'").check();
}
{code}
Although the same expression with literal works as expected:
{code:java}
@Test
public void test2() {
assertQuery("SELECT 100 UNION ALL SELECT '1000'").check();
}
{code}
Error:
{code:java}
java.lang.AssertionError: Conversion to relational algebra failed to preserve
datatypes:
validated type:
RecordType(VARCHAR CHARACTER SET "UTF-8" NOT NULL TEST_KEY) NOT NULL
converted type:
RecordType(VARCHAR CHARACTER SET "UTF-8" EXPR$0) NOT NULL
rel:
LogicalUnion(all=[true])
LogicalProject(EXPR$0=[CAST($1):VARCHAR CHARACTER SET "UTF-8"])
IgniteLogicalTableScan(table=[[PUBLIC, TT]])
LogicalValues(tuples=[[{ _UTF-8'1000' }]])
{code}
> Sql. Set operation: Conversion to relational algebra failed to preserve
> datatypes.
> --
>
> Key: IGNITE-19307
> URL: https://issues.apache.org/jira/browse/IGNITE-19307
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The following query fails with "Conversion to relational algebra failed to
> preserve datatypes"
> {code:java}
> @Test
> public void test() {
>sql("CREATE TABLE tt (id integer primary key, test_key integer)");
>sql("INSERT INTO tt VALUES(1, 100)");
>assertQuery("SELECT test_key FROM tt UNION ALL SELECT '1000'").check();
> }
> {code}
> Although the same expression with literal works as expected:
> {code:java}
> @Test
> public void test2() {
>assertQuery("SELECT 100 UNION ALL SELECT '1000'").check();
> }
> {code}
> Error:
> {code:java}
> java.lang.AssertionError: Conversion to relational algebra failed to preserve
> datatypes:
> validated type:
> RecordType(VARCHAR CHARACTER SET "UTF-8" NOT NULL TEST_KEY) NOT NULL
> converted type:
> RecordType(VARCHAR CHARACTER SET "UTF-8" EXPR$0) NOT NULL
> rel:
> LogicalUnion(all=[true])
> LogicalProject(EXPR$0=[CAST($1):VARCHAR CHARACTER SET "UTF-8"])
> IgniteLogicalTableScan(table=[[PUBLIC, TT]])
> LogicalValues(tuples=[[{ _UTF-8'1000' }]])
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19307) Sql. Set operation: Conversion to relational algebra failed to preserve datatypes.
[
https://issues.apache.org/jira/browse/IGNITE-19307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-19307:
--
Environment: (was: The following query fails with "Conversion to
relational algebra failed to preserve datatypes"
{code:java}
@Test
public void test() {
sql("CREATE TABLE tt (id integer primary key, test_key integer)");
sql("INSERT INTO tt VALUES(1, 100)");
assertQuery("SELECT test_key FROM tt UNION ALL SELECT '1000'").check();
}
{code}
Although the same expression with literal works as expected:
{code:java}
@Test
public void test2() {
assertQuery("SELECT 100 UNION ALL SELECT '1000'").check();
}
{code}
Error:
{code:java}
java.lang.AssertionError: Conversion to relational algebra failed to preserve
datatypes:
validated type:
RecordType(VARCHAR CHARACTER SET "UTF-8" NOT NULL TEST_KEY) NOT NULL
converted type:
RecordType(VARCHAR CHARACTER SET "UTF-8" EXPR$0) NOT NULL
rel:
LogicalUnion(all=[true])
LogicalProject(EXPR$0=[CAST($1):VARCHAR CHARACTER SET "UTF-8"])
IgniteLogicalTableScan(table=[[PUBLIC, TT]])
LogicalValues(tuples=[[{ _UTF-8'1000' }]])
{code}
)
> Sql. Set operation: Conversion to relational algebra failed to preserve
> datatypes.
> --
>
> Key: IGNITE-19307
> URL: https://issues.apache.org/jira/browse/IGNITE-19307
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19307) Sql. Set operation: Conversion to relational algebra failed to preserve datatypes.
Maksim Zhuravkov created IGNITE-19307:
-
Summary: Sql. Set operation: Conversion to relational algebra
failed to preserve datatypes.
Key: IGNITE-19307
URL: https://issues.apache.org/jira/browse/IGNITE-19307
Project: Ignite
Issue Type: Bug
Components: sql
Environment: The following query fails with "Conversion to relational
algebra failed to preserve datatypes"
{code:java}
@Test
public void test() {
sql("CREATE TABLE tt (id integer primary key, test_key integer)");
sql("INSERT INTO tt VALUES(1, 100)");
assertQuery("SELECT test_key FROM tt UNION ALL SELECT '1000'").check();
}
{code}
Although the same expression with literal works as expected:
{code:java}
@Test
public void test2() {
assertQuery("SELECT 100 UNION ALL SELECT '1000'").check();
}
{code}
Error:
{code:java}
java.lang.AssertionError: Conversion to relational algebra failed to preserve
datatypes:
validated type:
RecordType(VARCHAR CHARACTER SET "UTF-8" NOT NULL TEST_KEY) NOT NULL
converted type:
RecordType(VARCHAR CHARACTER SET "UTF-8" EXPR$0) NOT NULL
rel:
LogicalUnion(all=[true])
LogicalProject(EXPR$0=[CAST($1):VARCHAR CHARACTER SET "UTF-8"])
IgniteLogicalTableScan(table=[[PUBLIC, TT]])
LogicalValues(tuples=[[{ _UTF-8'1000' }]])
{code}
Reporter: Maksim Zhuravkov
Fix For: 3.0.0-beta2
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19209) Implement installing table schema updates
[ https://issues.apache.org/jira/browse/IGNITE-19209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semyon Danilov updated IGNITE-19209: Description: At the moment there is a CatalogService that manages SchemaDescriptors (database schemas, not table schemas) and TableDescriptors. CREATE TABLE is being handled by the CatalogService, however it seems like it doesn't actually write the schema to the metastorage. I believe that two things must be done in the scope of this ticket: 1. Actually write new schema to the metastorage. 2. Use metastorage's cluster time as the new schema's activation time. We must also make use of Delay Duration which is described in the https://cwiki.apache.org/confluence/display/IGNITE/IEP-98%3A+Schema+Synchronization was:TBD > Implement installing table schema updates > - > > Key: IGNITE-19209 > URL: https://issues.apache.org/jira/browse/IGNITE-19209 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > At the moment there is a CatalogService that manages SchemaDescriptors > (database schemas, not table schemas) and TableDescriptors. CREATE TABLE is > being handled by the CatalogService, however it seems like it doesn't > actually write the schema to the metastorage. > I believe that two things must be done in the scope of this ticket: > 1. Actually write new schema to the metastorage. > 2. Use metastorage's cluster time as the new schema's activation time. We > must also make use of Delay Duration which is described in the > https://cwiki.apache.org/confluence/display/IGNITE/IEP-98%3A+Schema+Synchronization -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19305) Index alive after drop indexed column
[
https://issues.apache.org/jira/browse/IGNITE-19305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Belyak updated IGNITE-19305:
--
Description:
In
[documentation|https://ignite.apache.org/docs/3.0.0-beta/sql-reference/ddl#alter-table-if-exists-table-drop-column-if-exists-column1-column2-int]
I see: "If the column was indexed, the index has to be dropped manually in
advance by using the 'DROP INDEX' command." But it seems like an alpha version
limitation.
Unable to create index with the same name after dropping indexed column:
{noformat}
create table tindex(
id int primary key,
v1 int,
v2 int);
create index titest on tindex(v1, v2)
alter table tindex drop column v1;
create index titest on tindex(v2);{noformat}
error:
{noformat}
[Code: 0, SQL State: 5] Exception while executing query [query=create
index titest on tindex(v2)]. Error message:IGN-SQL-17
TraceId:5f61df67-cc61-4eb1-98be-3bbaa25a7c44 IGN-SQL-17
TraceId:5f61df67-cc61-4eb1-98be-3bbaa25a7c44 Index already exists
[name="PUBLIC"."TITEST"]{noformat}
Expected behaviour:
1) index titest drop while dropping v1 columnd
2) index titest successfully created on the last DDL operation.
was:
Unable to create index with the same name after dropping indexed column:
{noformat}
create table tindex(
id int primary key,
v1 int,
v2 int);
create index titest on tindex(v1, v2)
alter table tindex drop column v1;
create index titest on tindex(v2);{noformat}
error:
{noformat}
[Code: 0, SQL State: 5] Exception while executing query [query=create
index titest on tindex(v2)]. Error message:IGN-SQL-17
TraceId:5f61df67-cc61-4eb1-98be-3bbaa25a7c44 IGN-SQL-17
TraceId:5f61df67-cc61-4eb1-98be-3bbaa25a7c44 Index already exists
[name="PUBLIC"."TITEST"]{noformat}
Expected behaviour:
1) index titest drop while dropping v1 columnd
2) index titest successfully created on the last DDL operation.
> Index alive after drop indexed column
> -
>
> Key: IGNITE-19305
> URL: https://issues.apache.org/jira/browse/IGNITE-19305
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0
>Reporter: Alexander Belyak
>Priority: Major
>
> In
> [documentation|https://ignite.apache.org/docs/3.0.0-beta/sql-reference/ddl#alter-table-if-exists-table-drop-column-if-exists-column1-column2-int]
> I see: "If the column was indexed, the index has to be dropped manually in
> advance by using the 'DROP INDEX' command." But it seems like an alpha
> version limitation.
> Unable to create index with the same name after dropping indexed column:
> {noformat}
> create table tindex(
> id int primary key,
> v1 int,
> v2 int);
> create index titest on tindex(v1, v2)
> alter table tindex drop column v1;
> create index titest on tindex(v2);{noformat}
> error:
> {noformat}
> [Code: 0, SQL State: 5] Exception while executing query [query=create
> index titest on tindex(v2)]. Error message:IGN-SQL-17
> TraceId:5f61df67-cc61-4eb1-98be-3bbaa25a7c44 IGN-SQL-17
> TraceId:5f61df67-cc61-4eb1-98be-3bbaa25a7c44 Index already exists
> [name="PUBLIC"."TITEST"]{noformat}
> Expected behaviour:
> 1) index titest drop while dropping v1 columnd
> 2) index titest successfully created on the last DDL operation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19306) Drop multiple column if exists without brace
Alexander Belyak created IGNITE-19306:
-
Summary: Drop multiple column if exists without brace
Key: IGNITE-19306
URL: https://issues.apache.org/jira/browse/IGNITE-19306
Project: Ignite
Issue Type: Bug
Components: documentation
Affects Versions: 3.0
Reporter: Alexander Belyak
Wrong parameter name {{IF NOT EXISTS}}
[https://ignite.apache.org/docs/3.0.0-beta/sql-reference/ddl#alter-table-if-exists-table-drop-column-if-exists-column1-column2-int]
Correct one: IF EXISTS
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-19297) Cleanup assembly files
[
https://issues.apache.org/jira/browse/IGNITE-19297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713622#comment-17713622
]
Aleksey Plekhanov commented on IGNITE-19297:
Looks like {{hadoop-common}} also used in {{{}spark-model-parser{}}}, so it's
better to leave it as is until ML module move to extensions.
> Cleanup assembly files
> --
>
> Key: IGNITE-19297
> URL: https://issues.apache.org/jira/browse/IGNITE-19297
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.15
>
>
> # Hadoop module was discontinued, but we still have file
> release-apache-ignite-hadoop.xml with references to some non-existent files
> (and related files LICENSE_HADOOP, NOTICE_HADOOP).
> # There are some dependencies to hadoop-common from examples (perhaps still
> required) and parent.pom (parhaps not required anymore).
> # dependencies-apache-ignite-slim.xml contains ignite-hadoop as exclusion.
> # LICENSE, parent.pom and snaptree-bsd-license.txt contain a mention of
> snaptree, which is not in ignite codebase anymore
> # LICENSE contains a mention of "
> org.apache.ignite.internal.processors.hadoop.books" package, which is not
> exists now (but corresponding license still relevant to examples, since file
> alice-in-wonderland.txt now can be found there)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-19048) Extract Subscribers and Accumulators to metastorage-api module
[ https://issues.apache.org/jira/browse/IGNITE-19048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin reassigned IGNITE-19048: -- Assignee: Mikhail Pochatkin > Extract Subscribers and Accumulators to metastorage-api module > -- > > Key: IGNITE-19048 > URL: https://issues.apache.org/jira/browse/IGNITE-19048 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > > In IGNITE-18870 was introduced abstractions > org.apache.ignite.internal.deployunit.metastore.Accumulator and > org.apache.ignite.internal.deployunit.metastore.EntrySubscriber. These > abstractions may help to avoid boilerplate code in context of Subscriber > implementation for prefix method of metastore. So, need to extract it and > replace existed Subscribers by new one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19304) Create index with the same column twice
[
https://issues.apache.org/jira/browse/IGNITE-19304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Belyak updated IGNITE-19304:
--
Summary: Create index with the same column twice (was: Create index with
same column twice)
> Create index with the same column twice
> ---
>
> Key: IGNITE-19304
> URL: https://issues.apache.org/jira/browse/IGNITE-19304
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0
>Reporter: Alexander Belyak
>Priority: Minor
>
> Unable to create index with same column twice:
> {noformat}
> create table tindex(
> id int primary key,
> v1 int,
> v2 int);
> create index titest on tindex(v1,v1){noformat}
> error:
> {noformat}
> [Code: 0, SQL State: 5] Exception while executing query [query=create
> index titest on tindex(v1,v1)]. Error message:IGN-CMN-65535
> TraceId:203a2c0c-fbf1-4143-aa47-50c97223ad84 Named List element with key "V1"
> already exists{noformat}
> But documentation
> [https://ignite.apache.org/docs/3.0.0-beta/sql-reference/ddl#create-index] do
> not block it. Postgres allow to execute such DDL too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19305) Index alive after drop indexed column
Alexander Belyak created IGNITE-19305:
-
Summary: Index alive after drop indexed column
Key: IGNITE-19305
URL: https://issues.apache.org/jira/browse/IGNITE-19305
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0
Reporter: Alexander Belyak
Unable to create index with the same name after dropping indexed column:
{noformat}
create table tindex(
id int primary key,
v1 int,
v2 int);
create index titest on tindex(v1, v2)
alter table tindex drop column v1;
create index titest on tindex(v2);{noformat}
error:
{noformat}
[Code: 0, SQL State: 5] Exception while executing query [query=create
index titest on tindex(v2)]. Error message:IGN-SQL-17
TraceId:5f61df67-cc61-4eb1-98be-3bbaa25a7c44 IGN-SQL-17
TraceId:5f61df67-cc61-4eb1-98be-3bbaa25a7c44 Index already exists
[name="PUBLIC"."TITEST"]{noformat}
Expected behaviour:
1) index titest drop while dropping v1 columnd
2) index titest successfully created on the last DDL operation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19304) Create index with same column twice
Alexander Belyak created IGNITE-19304:
-
Summary: Create index with same column twice
Key: IGNITE-19304
URL: https://issues.apache.org/jira/browse/IGNITE-19304
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0
Reporter: Alexander Belyak
Unable to create index with same column twice:
{noformat}
create table tindex(
id int primary key,
v1 int,
v2 int);
create index titest on tindex(v1,v1){noformat}
error:
{noformat}
[Code: 0, SQL State: 5] Exception while executing query [query=create
index titest on tindex(v1,v1)]. Error message:IGN-CMN-65535
TraceId:203a2c0c-fbf1-4143-aa47-50c97223ad84 Named List element with key "V1"
already exists{noformat}
But documentation
[https://ignite.apache.org/docs/3.0.0-beta/sql-reference/ddl#create-index] do
not block it. Postgres allow to execute such DDL too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19087) Cancel rebalance mechanism
[ https://issues.apache.org/jira/browse/IGNITE-19087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-19087: - Epic Link: (was: IGNITE-18290) > Cancel rebalance mechanism > -- > > Key: IGNITE-19087 > URL: https://issues.apache.org/jira/browse/IGNITE-19087 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Priority: Major > Labels: ignite-3 > > TODO: Add description, which must be based on cancellation design from > [https://github.com/apache/ignite-3/blob/c276a334c4c3742520494bccdc957f4530c8ed7a/modules/distribution-zones/tech-notes/rebalance.md] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19303) Make NamedLists confiuguration rendering more user-friendly
[
https://issues.apache.org/jira/browse/IGNITE-19303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr updated IGNITE-19303:
---
Description:
Fix the rendering syntax for named lists. Now they are saved in a strange
format:
{code:java}
namedList : [{
name = foo
attribute = a
}]
{code}
Also, I would expect (in the future) the following (when there's only a single
property to the list entry):
{code:java}
namedList {
foo.attribute = a
bar.attribute = b
}
instead of
namedList {
foo {
attribute = a
}
...
}
{code}
Maybe we would require a custom rendering code. Syntax matters, it's a
user-facing part of Ignite.
Do not forget about todo in LocalFileConfigurationStorageTest.
was:Do not forget about todo in LocalFileConfigurationStorageTest.
> Make NamedLists confiuguration rendering more user-friendly
> ---
>
> Key: IGNITE-19303
> URL: https://issues.apache.org/jira/browse/IGNITE-19303
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Aleksandr
>Priority: Major
> Labels: ignite-3
>
> Fix the rendering syntax for named lists. Now they are saved in a strange
> format:
> {code:java}
> namedList : [{
> name = foo
> attribute = a
> }]
> {code}
> Also, I would expect (in the future) the following (when there's only a
> single property to the list entry):
> {code:java}
> namedList {
> foo.attribute = a
> bar.attribute = b
> }
> instead of
> namedList {
> foo {
> attribute = a
> }
> ...
> }
> {code}
> Maybe we would require a custom rendering code. Syntax matters, it's a
> user-facing part of Ignite.
> Do not forget about todo in LocalFileConfigurationStorageTest.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19303) Make NamedLists confiuguration rendering more user-friendly
[ https://issues.apache.org/jira/browse/IGNITE-19303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-19303: --- Description: Do not forget about todo in LocalFileConfigurationStorageTest. > Make NamedLists confiuguration rendering more user-friendly > --- > > Key: IGNITE-19303 > URL: https://issues.apache.org/jira/browse/IGNITE-19303 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > Do not forget about todo in LocalFileConfigurationStorageTest. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19303) Make NamedLists confiuguration rendering more user-friendly
Aleksandr created IGNITE-19303: -- Summary: Make NamedLists confiuguration rendering more user-friendly Key: IGNITE-19303 URL: https://issues.apache.org/jira/browse/IGNITE-19303 Project: Ignite Issue Type: Improvement Components: general Reporter: Aleksandr -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19255) Fix broken unit tests in distribution-zones module
[
https://issues.apache.org/jira/browse/IGNITE-19255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-19255:
-
Description:
In IGNITE-19105 I've changed some internal shenanigans of the
MetaStorageManager (without affecting its API in any way). After that, nearly
all unit tests in the {{distribution-zones}} module started to fail. Turns out
it happened because of extensive mock usages that emulate behavior of the Meta
Storage. So I decided to replace it with the {{StandaloneMetaStorageManager}}
implementation and all hell broke loose: many tests emulate Meta Storage
incorrectly, a lot of races appeared, because many methods became truly
asynchronous.
This situation is very frustrating: a different component internals were
changed with no API changes and a completely unrelated module is not longer
able to pass its tests. Though I fixed most of the failures, some tests are
still failing and I'm going to try to describe, what's wrong with them:
*{{DistributionZoneManagerScaleUpTest#testDataNodesPropagationAfterScaleUpTriggeredOnNewCluster}}*
- this test tests a scenario when we start a node after logical topology was
updated. I don't know how realistic is this scenario, but the problem is that
"data nodes" don't get populated with the logical topology nodes on
{{distributionZoneManager}} start, because {{scheduleTimers}} method, that
get's invoked from the Meta Storage Watch, doesn't go inside the {{if
(!addedNodes.isEmpty() && autoAdjustScaleUp != INFINITE_TIMER_VALUE)}} branch.
*{{DistributionZoneManagerScaleUpTest#testDataNodesPropagationForDefaultZoneAfterScaleUpTriggered}}*
- same issue as above.
*{{DistributionZoneManagerScaleUpTest#testDataNodesPropagationForDefaultZoneAfterScaleDownTriggered}}*
- same issue as above.
*{{DistributionZoneManagerScaleUpTest#testUpdateZoneScaleUpTriggersDataNodePropagation}}*
- this test fails with the following assertion error: {_}Expected revision
that is greater or equal to already seen meta storage events.{_}. This is
because TestConfigurationStorage does not use the same revision as the Meta
Storage, therefore their revisions can't be compared directly. This should
either be converted to an integration test or it should use
`DistributedConfigurationStrorage` instead.
*{{DistributionZoneManagerScaleUpTest#testUpdateZoneScaleDownTriggersDataNodePropagation}}*
- same issue as above.
*{{DistributionZoneManagerWatchListenerTest#testDataNodesOfDefaultZoneUpdatedOnWatchListenerEvent}}*
- this test is flaky, probably due to some races between Watch and
Configuration Listener execution (sometimes a retry on {{invoke}} happens and
{{Mockito#verify}} fails).
*New tests* from [https://github.com/gridgain/apache-ignite-3/tree/ignite-18756]
*DistributionZoneAwaitDataNodesTest#testRemoveZoneWhileAwaitingDataNodes* -
this test must remove the zone after MetastorageTopologyListener updates the
topVerTracker and before
MetastorageDataNodesListener updates
scaleUpRevisionTracker/scaleDownRevisionTracker. Now it's impossible to do it
with StandaloneMetaStorageManager.
*DistributionZoneAwaitDataNodesTest#testScaleUpScaleDownAreChangedWhileAwaitingDataNodes*
- same issue as above but here we need to update scaleUp and scaleDown instead
of removing the zone.
was:
In IGNITE-19105 I've changed some internal shenanigans of the
MetaStorageManager (without affecting its API in any way). After that, nearly
all unit tests in the {{distribution-zones}} module started to fail. Turns out
it happened because of extensive mock usages that emulate behavior of the Meta
Storage. So I decided to replace it with the {{StandaloneMetaStorageManager}}
implementation and all hell broke loose: many tests emulate Meta Storage
incorrectly, a lot of races appeared, because many methods became truly
asynchronous.
This situation is very frustrating: a different component internals were
changed with no API changes and a completely unrelated module is not longer
able to pass its tests. Though I fixed most of the failures, some tests are
still failing and I'm going to try to describe, what's wrong with them:
*{{DistributionZoneManagerScaleUpTest#testDataNodesPropagationAfterScaleUpTriggeredOnNewCluster}}*
- this test tests a scenario when we start a node after logical topology was
updated. I don't know how realistic is this scenario, but the problem is that
"data nodes" don't get populated with the logical topology nodes on
{{distributionZoneManager}} start, because {{scheduleTimers}} method, that
get's invoked from the Meta Storage Watch, doesn't go inside the {{if
(!addedNodes.isEmpty() && autoAdjustScaleUp != INFINITE_TIMER_VALUE)}} branch.
*{{DistributionZoneManagerScaleUpTest#testDataNodesPropagationForDefaultZoneAfterScaleUpTriggered}}*
- same issue as above.
*{{DistributionZoneManagerScaleUpTest#testDataNodesPropagationForDefaultZoneAf
[jira] [Updated] (IGNITE-18526) Sql. Provide command and handler to change the zone of the table.
[ https://issues.apache.org/jira/browse/IGNITE-18526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-18526: - Epic Link: IGNITE-19170 (was: IGNITE-18528) > Sql. Provide command and handler to change the zone of the table. > - > > Key: IGNITE-18526 > URL: https://issues.apache.org/jira/browse/IGNITE-18526 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Sergey Uttsel >Priority: Major > Labels: ignite-3 > > Need to provide DDL command and its handler to altering table with new zone. > As a result, we need to create command (AlterTableChangeZoneCommand, like > AlterTableAddCommand) and execute this command in order to apply changes to > configuration (see DdlCommandHandler). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19302) Phantom reads protection is broken
Ivan Bessonov created IGNITE-19302:
--
Summary: Phantom reads protection is broken
Key: IGNITE-19302
URL: https://issues.apache.org/jira/browse/IGNITE-19302
Project: Ignite
Issue Type: Bug
Reporter: Ivan Bessonov
{{SortedIndexLocker#acquireLockNextKey}} is poorly implemented and not tested
properly. It ignores the documented contract of {{hasNext}} and {{peek}} from
{{{}PeekCursor{}}}.
"Has next" checks must essentially be replaced with {{{}peek() != null{}}}.
Unit tests, that would simulate concurrent operations, or maybe even do
concurrent operations, must be implemented.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-19267) Implement local Low Watermark propagation
[
https://issues.apache.org/jira/browse/IGNITE-19267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713572#comment-17713572
]
Roman Puchkovskiy commented on IGNITE-19267:
The patch looks good to me
> Implement local Low Watermark propagation
> -
>
> Key: IGNITE-19267
> URL: https://issues.apache.org/jira/browse/IGNITE-19267
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 6h 40m
> Remaining Estimate: 0h
>
> According to the IEP-91, we can delete old data, once it becomes older than
> the certain threshold. At the moment, we can consider this threshold to be
> shared between different tables, but be unique on individual nodes. It's
> called a Low Watermark (LW).
> The way the value is chosen is the following:
> * There's the {_}data availability time{_}, that can be configured by the
> user. This is a cluster configuration. It has a value of, for example, 45
> minutes. Valid values - {{{}[0, +INF){}}}.
> * There's a {_}GC frequency{_}, that's also a cluster configuration. For
> example, 5 minuter. Range of valid values should be more strict.
> * Last LW value is persisted in Vault.
> * Every 5 minutes, we assign a new "lwCandidate{{{} = now() - 45min -
> maxClockSkew"{}}}.
> ** If there are no running transactions with timestamp below
> {{{}lwCandidate{}}}, we promote the candidate into a real LW value.
> ** Otherwise, we trigger GC with timestamp of the transaction with the
> oldest timestamp (and promoting LW to that timestamp), and raising the bar
> every time* that transaction is completed. Eventually, we will reach the
> point where there are no running transactions with timestamp below
> {{{}lwCandidate{}}}.
> * it's not necessary to do it every time. But, once the timestamp of the
> oldest RO transaction is above or equal to {{{}lwCandidate{}}}, we must
> guarantee its promotion. Everything else is optimization.
> * If there's a new RO transaction with timestamp below {{{}lwCandidate{}}},
> we fail it.
> * When it comes to running GC - you never delete anything if LW < safeTime.
> This does not prevent us from propagating new LW value locally, we just don't
> drop the data until we have the rights to do so.
> Promoted LW value cannot become smaller no matter what. All data below LW is
> considered to be invalid, maybe broken and completely invisible to user.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-19100) .NET: Thin 3.0: Support basic authentication
[ https://issues.apache.org/jira/browse/IGNITE-19100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713567#comment-17713567 ] Pavel Tupitsyn commented on IGNITE-19100: - Merged to main: https://github.com/apache/ignite-3/commit/af3fdd9485e2caa135eca251d3007f9ca93ad992 > .NET: Thin 3.0: Support basic authentication > > > Key: IGNITE-19100 > URL: https://issues.apache.org/jira/browse/IGNITE-19100 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Mikhail Pochatkin >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19002) Move dataStorage configuration from table to distribution zone config
[ https://issues.apache.org/jira/browse/IGNITE-19002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713565#comment-17713565 ] Vladislav Pyatkov commented on IGNITE-19002: LGTM > Move dataStorage configuration from table to distribution zone config > - > > Key: IGNITE-19002 > URL: https://issues.apache.org/jira/browse/IGNITE-19002 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > Time Spent: 2h 40m > Remaining Estimate: 0h > > To implement the distribution zone based architecture we need to move the > dataStorage config from TableConfiguration to DistributionZoneConfiguration -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19184) Add proper javadocs for the node's attributes feature
[ https://issues.apache.org/jira/browse/IGNITE-19184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-19184: - Epic Link: (was: IGNITE-18528) > Add proper javadocs for the node's attributes feature > -- > > Key: IGNITE-19184 > URL: https://issues.apache.org/jira/browse/IGNITE-19184 > Project: Ignite > Issue Type: Improvement >Reporter: Mirza Aliev >Priority: Major > Labels: ignite-3 > > We have several places where nodes attributes must be explained properly in > the Public API, > so we should add more details in that places, explaining zone filters, > providing examples, etc. > Seems like it is better to do this task closer to the end of the feature, > when filtering will be implemented. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18564) Extend test coverage for WatchListener in DistributionZoneManager
[ https://issues.apache.org/jira/browse/IGNITE-18564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-18564: - Epic Link: (was: IGNITE-18528) > Extend test coverage for WatchListener in DistributionZoneManager > - > > Key: IGNITE-18564 > URL: https://issues.apache.org/jira/browse/IGNITE-18564 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Uttsel >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3 > > h3. Motivation > DistributionZoneManagerWatchListenerTest checks only default zone. Now when > individual zone change trigger were created it is possible to test custom > zones too. So need to add a custom zone to all tests in > DistributionZoneManagerWatchListenerTest. > DistributionZoneManager has a watch listener which is triggered on update > "distributionZones.logicalTopology" key and updates zone dataNodes in the > metastorage. Also DistributionZoneManager has a method > initDataNodesFromVaultManager() which save zone dataNodes on > DistributionZoneManager#start(). DistributionZoneManagerWatchListenerTest > checks this logic. But it checks only for default zone. Now when individual > zone change trigger keys were created it is possible to test custom zones > too. So need to add a custom zone to all tests in > DistributionZoneManagerWatchListenerTest. > # testDataNodesOfDefaultZoneUpdatedOnWatchListenerEvent - the test checks > that dataNodes is updated on watch event. Need to add custom zone and check > it. > # testStaleWatchEvent - the test checks that dataNodes is not updated on > stale watch event. Need to add custom zone and check it. > # testStaleVaultRevisionOnZoneManagerStart - the test checks that dataNodes > is not updated from the vault on DistributionZoneManager#start() if the vault > applied revision is stale. Need to add custom zone and check it. > # testDataNodesUpdatedOnZoneManagerStart - the test checks that dataNodes is > updated from the vault on DistributionZoneManager#start(). Need to add custom > zone and check it. > # testLogicalTopologyIsNullOnZoneManagerStart - the test checks that > dataNodes is not updated from the vault on DistributionZoneManager#start() if > "distributionZones.logicalTopology" is null in the vault. Need to add custom > zone and check it. > *Definition of Done* > Tests in the DistributionZoneManagerWatchListenerTest check not only default > zone, but also a custom zone. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18416) Tests for DistributionZoneManager
[ https://issues.apache.org/jira/browse/IGNITE-18416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-18416: - Epic Link: (was: IGNITE-18528) > Tests for DistributionZoneManager > - > > Key: IGNITE-18416 > URL: https://issues.apache.org/jira/browse/IGNITE-18416 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3 > > Tests for DistributionZoneManager. > h3. Node start/restart tests: > *Test1:* > Parameters: > # zone config: [scaleUp = 0, scaleDown = 0, commonAutoAdjust = > INTEGER.MAX_VALUE], [scaleUp = INTEGER.MAX_VALUE, scaleDown = > INTEGER.MAX_VALUE, commonAutoAdjust = 0], [scaleUp = 10, scaleDown = 0, > commonAutoAdjust = INTEGER.MAX_VALUE], [scaleUp = 0, scaleDown = 10, > commonAutoAdjust = INTEGER.MAX_VALUE], [scaleUp = INTEGER.MAX_VALUE, > scaleDown = INTEGER.MAX_VALUE, commonAutoAdjust = 10] > Prerequisite: > # node1 is started. > # Default zone with . > Test steps: > # Start node2. > # *Assert* that data nodes of default zone is [node1, node2] after > timeout. > # Stop node2. > # *Assert* that data nodes of default zone is [node1] after > timeout. > *Test2:* > Parameters: > # zone config: [scaleUp = 1000, commonAutoAdjust = INTEGER.MAX_VALUE], > [scaleUp = INTEGER.MAX_VALUE, commonAutoAdjust = 1000] > Prerequisite: > # node1 is started. > # Default zone with . > Test steps: > # Start node2. _(Zone timer is started at node1 and node2)._ > # Restart node1. > # *Assert* that data nodes of default zone is [node1, node2] after node1 is > restarted. _(Before timer expiration)_ > *Test3:* > Parameters: > # zone config: [scaleDown = 1000, commonAutoAdjust = INTEGER.MAX_VALUE], > [scaleDown = INTEGER.MAX_VALUE, commonAutoAdjust = 1000] > Prerequisite: > # node1, node2 are started. > # Default zone with . > # Data nodes of default zone is [node1, node2] > Test steps: > # Stop node2. _(Zone timer is started at node1)._ > # Restart node1. > # *Assert* that data nodes of default zone is [node1] after node1 is > restarted. _(Before timer expiration)_ > *Test4:* > Prerequisite: > # node1 and node2 are started. > # Default zone with scaleUp = 10 and scaleDown = Integer.MAX_VALUE. > # Data nodes of default zone: [node1, node2]. > Test steps: > # Start node3 at the time 0. > # Stop node2 at time 5. > # *Assert* that at time 10 data nodes of default zone will be changed to > [node1, node2, node3]. > # Start node4 at time 30. > # *Assert* that at time 40 data nodes of default zone will be changed to > [node1, node2, node3, node4]. > # Start node2 at time 50. _(So node2 tries to do metaStorage.invoke with a > stale dataNodes [node1, node2, node3])_ > # *Assert* that data nodes of default zone is [node1, node2, node3, node4] > after node2 is restarted. > *Test5:* > Prerequisite: > # node1, node2 and node3 are started. > # Default zone with scaleUp = 10 and scaleDown = 15. > Test steps: > # Start node4 and stop node2 at the time 0. > # Stop node3 and start node5 at the time 5. > # *Assert* that at time 15 data nodes of default zone will be changed to > [node1, node2, node3, node4, node5]. > # *Assert* that at time 20 data nodes of default zone will be changed to > [node1, node4, node5]. > *Test6:* > Prerequisite: > # node1 and node2 are started. > # Default zone with commonAutoAdjust = 10. > Test steps: > # Stop node2 at the time 0. > # Start node3 at the time 5. > # *Assert* that at time 10 data nodes of default zone is [node1, node2]. > # *Assert* that at time 15 data nodes of default zone will be changed to > [node1, node3]. > > h3. Zone configuration changes > *Test1:* > Prerequisite: > # node1, node2 are started. > Test steps: > # Create new zone. > # *Assert* that data nodes of new zone is [node1, node2] > *Test2:* > Prerequisite: > # node1 are started. > # Data nodes of default zone: [node1]. > Test steps: > # Alter default zone with <[scaleUp = 1000, scaleDown = 0, commonAutoAdjust = > INTEGER.MAX_VALUE], [scaleUp = INTEGER.MAX_VALUE, scaleDown = > INTEGER.MAX_VALUE, commonAutoAdjust = 1000]> > # Start node2 at time 0. > # Change <[scaleUp], [commonAutoAdjust]> to 10 at time 5. > # *Assert* that data nodes of default zone is changed to [node1, node2] at > time 15. > # Alter default zone with <[scaleUp = 0, scaleDown = 1000, commonAutoAdjust = > INTEGER.MAX_VALUE], [scaleUp = INTEGER.MAX_VALUE, scaleDown = > INTEGER.MAX_VALUE, commonAutoAdjust = 1000]> > # Stop node2 at time 15. > # Change <[scaleDown], [commonAutoAdjust]> to 10 at time 20. > # *Assert* that data nodes of default zone is changed to [node1] at time 30. > *Test3:* > Prerequisite: > # node1 and node2 are started. > Test steps: > # Alter zone1 with [scaleUp = 10, scaleDown = 10, commonAutoAdjust = > INTEG
[jira] [Updated] (IGNITE-18624) Need to use data nodes from DistributionZoneManager used instead of BaselineManager#nodes on table creation.
[ https://issues.apache.org/jira/browse/IGNITE-18624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-18624: - Epic Link: IGNITE-18528 > Need to use data nodes from DistributionZoneManager used instead of > BaselineManager#nodes on table creation. > > > Key: IGNITE-18624 > URL: https://issues.apache.org/jira/browse/IGNITE-18624 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3 > Time Spent: 1.5h > Remaining Estimate: 0h > > h3. Motivation > In TableManager#createTableAsyncInternal need to use data nodes from > DistributionZoneManager with awaiting that data nodes for the zone is updated > in meta storage instead of BaselineManager#nodes. > h3. Definition of Done > # Data nodes from DistributionZoneManager used instead of > BaselineManager#nodes on table creation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18756) Awaiting for nodes are appeared in distribution zone data nodes
[ https://issues.apache.org/jira/browse/IGNITE-18756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-18756: - Epic Link: IGNITE-18528 > Awaiting for nodes are appeared in distribution zone data nodes > --- > > Key: IGNITE-18756 > URL: https://issues.apache.org/jira/browse/IGNITE-18756 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3 > Time Spent: 12h > Remaining Estimate: 0h > > h3. Motivation > Awaiting for nodes are appeared in distribution zone data nodes. > Now when nodes were started and joined to physical topology it's enough to > create table with assignments on these nodes. When we get rid of > BaselineManager#nodes then the data nodes of the distribution zone will be > used to create assignments for partitions. > In order for the nodes from the physical topology are in the assignments when > table is creating, it's need to wait until these nodes are added to the data > nodes of the distribution zone. > h3. Definition of Done > At the time of table creating data nodes from the physical topology must also > be in the data nodes of the distribution zone. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19297) Cleanup assembly files
[ https://issues.apache.org/jira/browse/IGNITE-19297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-19297: --- Description: # Hadoop module was discontinued, but we still have file release-apache-ignite-hadoop.xml with references to some non-existent files (and related files LICENSE_HADOOP, NOTICE_HADOOP). # There are some dependencies to hadoop-common from examples (perhaps still required) and parent.pom (parhaps not required anymore). # dependencies-apache-ignite-slim.xml contains ignite-hadoop as exclusion. # LICENSE, parent.pom and snaptree-bsd-license.txt contain a mention of snaptree, which is not in ignite codebase anymore # LICENSE contains a mention of " org.apache.ignite.internal.processors.hadoop.books" package, which is not exists now (but corresponding license still relevant to examples, since file alice-in-wonderland.txt now can be found there) was: # Hadoop module was discontinued, but we still have file release-apache-ignite-hadoop.xml with references to some non-existent files (and related files LICENSE_HADOOP, NOTICE_HADOOP). # There are some dependencies to hadoop-common from examples (perhaps still required) and parent.pom (parhaps not required anymore). # dependencies-apache-ignite-slim.xml contains ignite-hadoop as exclusion. # LICENSE, parent.pom and snaptree-bsd-license.txt contain a mention of snaptree, which is not in ignite codebase anymore # LICENSE contain a mention of " org.apache.ignite.internal.processors.hadoop.books" package, which is not exists now (but corresponding license still relevant to examples, since file alice-in-wonderland.txt now can be found there) > Cleanup assembly files > -- > > Key: IGNITE-19297 > URL: https://issues.apache.org/jira/browse/IGNITE-19297 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Fix For: 2.15 > > > # Hadoop module was discontinued, but we still have file > release-apache-ignite-hadoop.xml with references to some non-existent files > (and related files LICENSE_HADOOP, NOTICE_HADOOP). > # There are some dependencies to hadoop-common from examples (perhaps still > required) and parent.pom (parhaps not required anymore). > # dependencies-apache-ignite-slim.xml contains ignite-hadoop as exclusion. > # LICENSE, parent.pom and snaptree-bsd-license.txt contain a mention of > snaptree, which is not in ignite codebase anymore > # LICENSE contains a mention of " > org.apache.ignite.internal.processors.hadoop.books" package, which is not > exists now (but corresponding license still relevant to examples, since file > alice-in-wonderland.txt now can be found there) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19301) Add --all flag to undeploy command
Mikhail Pochatkin created IGNITE-19301: -- Summary: Add --all flag to undeploy command Key: IGNITE-19301 URL: https://issues.apache.org/jira/browse/IGNITE-19301 Project: Ignite Issue Type: New Feature Components: cli Reporter: Mikhail Pochatkin Intorduce --all flag to undeploy command which mutually exclusive to --version. This flag should undeploy all version of provided unit. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19300) Disabled table Examples
[ https://issues.apache.org/jira/browse/IGNITE-19300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-19300: --- Component/s: sql > Disabled table Examples > --- > > Key: IGNITE-19300 > URL: https://issues.apache.org/jira/browse/IGNITE-19300 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > There are 9 disabled tests: > org.apache.ignite.internal.table.Example.useCase1 > org.apache.ignite.internal.table.Example.useCase1 > org.apache.ignite.internal.table.Example.useCase1 > org.apache.ignite.internal.table.Example.useCase2 > org.apache.ignite.internal.table.Example.useCase1 > org.apache.ignite.internal.table.Example.useCase3 > org.apache.ignite.internal.table.Example.useCase3 > org.apache.ignite.internal.table.Example.useCase4 > org.apache.ignite.internal.table.Example.useCase1 > org.apache.ignite.internal.table.Example.useCase5 > org.apache.ignite.internal.table.Example.useCase5 > org.apache.ignite.internal.table.Example.useCase6 > org.apache.ignite.internal.table.Example.useCase1 > org.apache.ignite.internal.table.Example.useCase7 > org.apache.ignite.internal.table.Example.useCase7 > org.apache.ignite.internal.table.Example.useCase8 > org.apache.ignite.internal.table.Example.useCase1 > org.apache.ignite.internal.table.Example.useCase9 > Need to check the reason for the mute and fix it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19300) Disabled table Examples
[ https://issues.apache.org/jira/browse/IGNITE-19300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-19300: --- Description: There are 9 disabled tests: org.apache.ignite.internal.table.Example.useCase1 org.apache.ignite.internal.table.Example.useCase1 org.apache.ignite.internal.table.Example.useCase1 org.apache.ignite.internal.table.Example.useCase2 org.apache.ignite.internal.table.Example.useCase1 org.apache.ignite.internal.table.Example.useCase3 org.apache.ignite.internal.table.Example.useCase3 org.apache.ignite.internal.table.Example.useCase4 org.apache.ignite.internal.table.Example.useCase1 org.apache.ignite.internal.table.Example.useCase5 org.apache.ignite.internal.table.Example.useCase5 org.apache.ignite.internal.table.Example.useCase6 org.apache.ignite.internal.table.Example.useCase1 org.apache.ignite.internal.table.Example.useCase7 org.apache.ignite.internal.table.Example.useCase7 org.apache.ignite.internal.table.Example.useCase8 org.apache.ignite.internal.table.Example.useCase1 org.apache.ignite.internal.table.Example.useCase9 Need to check the reason for the mute and fix it. was: There are 8 disabled tests: org.apache.ignite.internal.table.Example.useCase1 org.apache.ignite.internal.table.Example.useCase2 org.apache.ignite.internal.table.Example.useCase3 org.apache.ignite.internal.table.Example.useCase4 org.apache.ignite.internal.table.Example.useCase5 org.apache.ignite.internal.table.Example.useCase6 org.apache.ignite.internal.table.Example.useCase7 org.apache.ignite.internal.table.Example.useCase8 Need to check the reason of mute and fix it. > Disabled table Examples > --- > > Key: IGNITE-19300 > URL: https://issues.apache.org/jira/browse/IGNITE-19300 > Project: Ignite > Issue Type: Improvement >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > There are 9 disabled tests: > org.apache.ignite.internal.table.Example.useCase1 > org.apache.ignite.internal.table.Example.useCase1 > org.apache.ignite.internal.table.Example.useCase1 > org.apache.ignite.internal.table.Example.useCase2 > org.apache.ignite.internal.table.Example.useCase1 > org.apache.ignite.internal.table.Example.useCase3 > org.apache.ignite.internal.table.Example.useCase3 > org.apache.ignite.internal.table.Example.useCase4 > org.apache.ignite.internal.table.Example.useCase1 > org.apache.ignite.internal.table.Example.useCase5 > org.apache.ignite.internal.table.Example.useCase5 > org.apache.ignite.internal.table.Example.useCase6 > org.apache.ignite.internal.table.Example.useCase1 > org.apache.ignite.internal.table.Example.useCase7 > org.apache.ignite.internal.table.Example.useCase7 > org.apache.ignite.internal.table.Example.useCase8 > org.apache.ignite.internal.table.Example.useCase1 > org.apache.ignite.internal.table.Example.useCase9 > Need to check the reason for the mute and fix it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19300) Disabled table Examples
Yury Gerzhedovich created IGNITE-19300: -- Summary: Disabled table Examples Key: IGNITE-19300 URL: https://issues.apache.org/jira/browse/IGNITE-19300 Project: Ignite Issue Type: Improvement Reporter: Yury Gerzhedovich There are 8 disabled tests: org.apache.ignite.internal.table.Example.useCase1 org.apache.ignite.internal.table.Example.useCase2 org.apache.ignite.internal.table.Example.useCase3 org.apache.ignite.internal.table.Example.useCase4 org.apache.ignite.internal.table.Example.useCase5 org.apache.ignite.internal.table.Example.useCase6 org.apache.ignite.internal.table.Example.useCase7 org.apache.ignite.internal.table.Example.useCase8 Need to check the reason of mute and fix it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19297) Cleanup assembly files
[ https://issues.apache.org/jira/browse/IGNITE-19297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-19297: --- Description: # Hadoop module was discontinued, but we still have file release-apache-ignite-hadoop.xml with references to some non-existent files (and related files LICENSE_HADOOP, NOTICE_HADOOP). # There are some dependencies to hadoop-common from examples (perhaps still required) and parent.pom (parhaps not required anymore). # dependencies-apache-ignite-slim.xml contains ignite-hadoop as exclusion. # LICENSE, parent.pom and snaptree-bsd-license.txt contain a mention of snaptree, which is not in ignite codebase anymore # LICENSE contain a mention of " org.apache.ignite.internal.processors.hadoop.books" package, which is not exists now (but corresponding license still relevant to examples, since file alice-in-wonderland.txt now can be found there) was: # Hadoop module was discontinued, but we still have file release-apache-ignite-hadoop.xml with references to some non-existent files (and related files LICENSE_HADOOP, NOTICE_HADOOP). # There are some dependencies to hadoop-common from examples (perhaps still required) and parent.pom (parhaps not required anymore). # dependencies-apache-ignite-slim.xml contains ignite-hadoop as exclusion (and some other deleted modules, but also perhaps ignite-extdata-pluggable should be added) # LICENSE, parent.pom and snaptree-bsd-license.txt contain a mention of snaptree, which is not in ignite codebase anymore # LICENSE contain a mention of " org.apache.ignite.internal.processors.hadoop.books" package, which is not exists now (but corresponding license still relevant to examples, since file alice-in-wonderland.txt now can be found there) > Cleanup assembly files > -- > > Key: IGNITE-19297 > URL: https://issues.apache.org/jira/browse/IGNITE-19297 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Fix For: 2.15 > > > # Hadoop module was discontinued, but we still have file > release-apache-ignite-hadoop.xml with references to some non-existent files > (and related files LICENSE_HADOOP, NOTICE_HADOOP). > # There are some dependencies to hadoop-common from examples (perhaps still > required) and parent.pom (parhaps not required anymore). > # dependencies-apache-ignite-slim.xml contains ignite-hadoop as exclusion. > # LICENSE, parent.pom and snaptree-bsd-license.txt contain a mention of > snaptree, which is not in ignite codebase anymore > # LICENSE contain a mention of " > org.apache.ignite.internal.processors.hadoop.books" package, which is not > exists now (but corresponding license still relevant to examples, since file > alice-in-wonderland.txt now can be found there) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19299) Unmute IgniteSqlApiTest#testMetadata
Yury Gerzhedovich created IGNITE-19299: -- Summary: Unmute IgniteSqlApiTest#testMetadata Key: IGNITE-19299 URL: https://issues.apache.org/jira/browse/IGNITE-19299 Project: Ignite Issue Type: Improvement Components: sql Reporter: Yury Gerzhedovich We have disabled test org.apache.ignite.internal.sql.engine.IgniteSqlApiTest#testMetadata. Currently, it uses just mocks to check something which is not clear to me, Need to think should we have such tests at all. In case it is useful rewrite it, or remove it all. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19100) .NET: Thin 3.0: Support basic authentication
[ https://issues.apache.org/jira/browse/IGNITE-19100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713541#comment-17713541 ] Igor Sapego commented on IGNITE-19100: -- Looks good to me. > .NET: Thin 3.0: Support basic authentication > > > Key: IGNITE-19100 > URL: https://issues.apache.org/jira/browse/IGNITE-19100 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Mikhail Pochatkin >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19298) .NET: Thin 3.0: MetricsTests.TestRequestsActive is flaky
[
https://issues.apache.org/jira/browse/IGNITE-19298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-19298:
Description:
{code}
Expected: 0
But was: -1
at Apache.Ignite.Tests.MetricsTests.TestRequestsActive() in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/MetricsTests.cs:line
164
at
NUnit.Framework.Internal.TaskAwaitAdapter.GenericAdapter`1.BlockUntilCompleted()
at
NUnit.Framework.Internal.MessagePumpStrategy.NoMessagePumpStrategy.WaitForCompletion(AwaitAdapter
awaiter)
at NUnit.Framework.Internal.AsyncToSyncAdapter.Await(Func`1 invoke)
at
NUnit.Framework.Internal.Commands.TestMethodCommand.RunTestMethod(TestExecutionContext
context)
at
NUnit.Framework.Internal.Commands.TestMethodCommand.Execute(TestExecutionContext
context)
at
NUnit.Framework.Internal.Commands.BeforeAndAfterTestCommand.<>c__DisplayClass1_0.b__0()
at
NUnit.Framework.Internal.Commands.DelegatingTestCommand.RunTestMethodInThreadAbortSafeZone(TestExecutionContext
context, Action action)
1)at Apache.Ignite.Tests.MetricsTests.TestRequestsActive() in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/MetricsTests.cs:line
164
at
System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.AsyncStateMachineBox`1.ExecutionContextCallback(Object
s)
{code}
https://ci.ignite.apache.org/test/4249445999771063462?currentProjectId=ApacheIgnite3xGradle_Test
> .NET: Thin 3.0: MetricsTests.TestRequestsActive is flaky
>
>
> Key: IGNITE-19298
> URL: https://issues.apache.org/jira/browse/IGNITE-19298
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Fix For: 3.0.0-beta2
>
>
> {code}
> Expected: 0
> But was: -1
>at Apache.Ignite.Tests.MetricsTests.TestRequestsActive() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/MetricsTests.cs:line
> 164
>at
> NUnit.Framework.Internal.TaskAwaitAdapter.GenericAdapter`1.BlockUntilCompleted()
>at
> NUnit.Framework.Internal.MessagePumpStrategy.NoMessagePumpStrategy.WaitForCompletion(AwaitAdapter
> awaiter)
>at NUnit.Framework.Internal.AsyncToSyncAdapter.Await(Func`1 invoke)
>at
> NUnit.Framework.Internal.Commands.TestMethodCommand.RunTestMethod(TestExecutionContext
> context)
>at
> NUnit.Framework.Internal.Commands.TestMethodCommand.Execute(TestExecutionContext
> context)
>at
> NUnit.Framework.Internal.Commands.BeforeAndAfterTestCommand.<>c__DisplayClass1_0.b__0()
>at
> NUnit.Framework.Internal.Commands.DelegatingTestCommand.RunTestMethodInThreadAbortSafeZone(TestExecutionContext
> context, Action action)
> 1)at Apache.Ignite.Tests.MetricsTests.TestRequestsActive() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/MetricsTests.cs:line
> 164
>at
> System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.AsyncStateMachineBox`1.ExecutionContextCallback(Object
> s)
> {code}
> https://ci.ignite.apache.org/test/4249445999771063462?currentProjectId=ApacheIgnite3xGradle_Test
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19298) .NET: Thin 3.0: MetricsTests.TestRequestsActive is flaky
[
https://issues.apache.org/jira/browse/IGNITE-19298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-19298:
Labels: ignite-3 (was: )
> .NET: Thin 3.0: MetricsTests.TestRequestsActive is flaky
>
>
> Key: IGNITE-19298
> URL: https://issues.apache.org/jira/browse/IGNITE-19298
> Project: Ignite
> Issue Type: Bug
> 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
>
>
> {code}
> Expected: 0
> But was: -1
>at Apache.Ignite.Tests.MetricsTests.TestRequestsActive() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/MetricsTests.cs:line
> 164
>at
> NUnit.Framework.Internal.TaskAwaitAdapter.GenericAdapter`1.BlockUntilCompleted()
>at
> NUnit.Framework.Internal.MessagePumpStrategy.NoMessagePumpStrategy.WaitForCompletion(AwaitAdapter
> awaiter)
>at NUnit.Framework.Internal.AsyncToSyncAdapter.Await(Func`1 invoke)
>at
> NUnit.Framework.Internal.Commands.TestMethodCommand.RunTestMethod(TestExecutionContext
> context)
>at
> NUnit.Framework.Internal.Commands.TestMethodCommand.Execute(TestExecutionContext
> context)
>at
> NUnit.Framework.Internal.Commands.BeforeAndAfterTestCommand.<>c__DisplayClass1_0.b__0()
>at
> NUnit.Framework.Internal.Commands.DelegatingTestCommand.RunTestMethodInThreadAbortSafeZone(TestExecutionContext
> context, Action action)
> 1)at Apache.Ignite.Tests.MetricsTests.TestRequestsActive() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/MetricsTests.cs:line
> 164
>at
> System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.AsyncStateMachineBox`1.ExecutionContextCallback(Object
> s)
> {code}
> https://ci.ignite.apache.org/test/4249445999771063462?currentProjectId=ApacheIgnite3xGradle_Test
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19298) .NET: Thin 3.0: MetricsTests.TestRequestsActive is flaky
Pavel Tupitsyn created IGNITE-19298: --- Summary: .NET: Thin 3.0: MetricsTests.TestRequestsActive is flaky Key: IGNITE-19298 URL: https://issues.apache.org/jira/browse/IGNITE-19298 Project: Ignite Issue Type: Bug Components: platforms, thin client Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19297) Cleanup assembly files
[ https://issues.apache.org/jira/browse/IGNITE-19297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-19297: --- Fix Version/s: 2.15 > Cleanup assembly files > -- > > Key: IGNITE-19297 > URL: https://issues.apache.org/jira/browse/IGNITE-19297 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Fix For: 2.15 > > > # Hadoop module was discontinued, but we still have file > release-apache-ignite-hadoop.xml with references to some non-existent files > (and related files LICENSE_HADOOP, NOTICE_HADOOP). > # There are some dependencies to hadoop-common from examples (perhaps still > required) and parent.pom (parhaps not required anymore). > # dependencies-apache-ignite-slim.xml contains ignite-hadoop as exclusion > (and some other deleted modules, but also perhaps ignite-extdata-pluggable > should be added) > # LICENSE, parent.pom and snaptree-bsd-license.txt contain a mention of > snaptree, which is not in ignite codebase anymore > # LICENSE contain a mention of " > org.apache.ignite.internal.processors.hadoop.books" package, which is not > exists now (but corresponding license still relevant to examples, since file > alice-in-wonderland.txt now can be found there) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19297) Cleanup assembly files
Aleksey Plekhanov created IGNITE-19297: -- Summary: Cleanup assembly files Key: IGNITE-19297 URL: https://issues.apache.org/jira/browse/IGNITE-19297 Project: Ignite Issue Type: Improvement Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov # Hadoop module was discontinued, but we still have file release-apache-ignite-hadoop.xml with references to some non-existent files (and related files LICENSE_HADOOP, NOTICE_HADOOP). # There are some dependencies to hadoop-common from examples (perhaps still required) and parent.pom (parhaps not required anymore). # dependencies-apache-ignite-slim.xml contains ignite-hadoop as exclusion (and some other deleted modules, but also perhaps ignite-extdata-pluggable should be added) # LICENSE, parent.pom and snaptree-bsd-license.txt contain a mention of snaptree, which is not in ignite codebase anymore # LICENSE contain a mention of " org.apache.ignite.internal.processors.hadoop.books" package, which is not exists now (but corresponding license still relevant to examples, since file alice-in-wonderland.txt now can be found there) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19100) .NET: Thin 3.0: Support basic authentication
[ https://issues.apache.org/jira/browse/IGNITE-19100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713530#comment-17713530 ] Igor Sapego commented on IGNITE-19100: -- Left few comments. > .NET: Thin 3.0: Support basic authentication > > > Key: IGNITE-19100 > URL: https://issues.apache.org/jira/browse/IGNITE-19100 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Mikhail Pochatkin >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19077) Apply cutom cluster config on cluster init
[ https://issues.apache.org/jira/browse/IGNITE-19077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin reassigned IGNITE-19077: -- Assignee: Ivan Gagarkin > Apply cutom cluster config on cluster init > -- > > Key: IGNITE-19077 > URL: https://issues.apache.org/jira/browse/IGNITE-19077 > Project: Ignite > Issue Type: Task > Components: rest >Reporter: Aleksandr >Assignee: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > > After IGNITE-18576 its possible to provide Authentication cluster > configuration on cluster init. > Looking at ClusterManagementGroupManager#onElectedAsLeader we can see that > REST authentication configuration is applied to the distributed configuration > on leader election. This happens because there is no any other way to put any > values to the cluster configuration on init. > -This leads to the following situation:- > - -cluster init in progress, some REST endpoints are blocked > (cluster/configuration for example)- > - -cluster initialized, REST is available without auth *anybody can use the > REST*- > - -authentication configuration is applied to the distributed configuration > and REST is secured- > After IGNITE-18943 this is not possible because configuration REST endpoints > are disabled until cluter initialization will successfuly finished. > It is proposed to extend this approach to whole cluster configration. Instead > of cluster authentication configuration init endpoint should accept whole > cluster configuration in HOCON format and apply it as it currently. > CLI should have option to provide HOCON file. This file should be readed and > provided tgo init REST endpoint. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19277) Add authorization of Ignite Cluster Node stop/restart operations.
[ https://issues.apache.org/jira/browse/IGNITE-19277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-19277: Labels: security (was: ) > Add authorization of Ignite Cluster Node stop/restart operations. > - > > Key: IGNITE-19277 > URL: https://issues.apache.org/jira/browse/IGNITE-19277 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Critical > Labels: security > Fix For: 2.15 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Before https://issues.apache.org/jira/browse/IGNITE-15322 > IgniteCluster#restartNodes()/stopNodes() operations were authorized by the > name of the internal tasks that is used during their execution - > org.apache.ignite.internal.cluster.IgniteKillTask. > After https://issues.apache.org/jira/browse/IGNITE-15322 has been resolved, > authorization of internal tasks is no longer performed. So > IgniteCluster#restartNodes()/stopNodes() operations are not authorized at > all. > We must to fix it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-19277) Add authorization of Ignite Cluster Node stop/restart operations.
[ https://issues.apache.org/jira/browse/IGNITE-19277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov resolved IGNITE-19277. - Resolution: Fixed > Add authorization of Ignite Cluster Node stop/restart operations. > - > > Key: IGNITE-19277 > URL: https://issues.apache.org/jira/browse/IGNITE-19277 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Critical > Fix For: 2.15 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Before https://issues.apache.org/jira/browse/IGNITE-15322 > IgniteCluster#restartNodes()/stopNodes() operations were authorized by the > name of the internal tasks that is used during their execution - > org.apache.ignite.internal.cluster.IgniteKillTask. > After https://issues.apache.org/jira/browse/IGNITE-15322 has been resolved, > authorization of internal tasks is no longer performed. So > IgniteCluster#restartNodes()/stopNodes() operations are not authorized at > all. > We must to fix it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19277) Add authorization of Ignite Cluster Node stop/restart operations.
[ https://issues.apache.org/jira/browse/IGNITE-19277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713488#comment-17713488 ] Mikhail Petrov commented on IGNITE-19277: - [~alexpl], Thank you for the review. > Add authorization of Ignite Cluster Node stop/restart operations. > - > > Key: IGNITE-19277 > URL: https://issues.apache.org/jira/browse/IGNITE-19277 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Critical > Fix For: 2.15 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Before https://issues.apache.org/jira/browse/IGNITE-15322 > IgniteCluster#restartNodes()/stopNodes() operations were authorized by the > name of the internal tasks that is used during their execution - > org.apache.ignite.internal.cluster.IgniteKillTask. > After https://issues.apache.org/jira/browse/IGNITE-15322 has been resolved, > authorization of internal tasks is no longer performed. So > IgniteCluster#restartNodes()/stopNodes() operations are not authorized at > all. > We must to fix it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19277) Add authorization of Ignite Cluster Node stop/restart operations.
[
https://issues.apache.org/jira/browse/IGNITE-19277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713485#comment-17713485
]
Ignite TC Bot commented on IGNITE-19277:
{panel:title=Branch: [pull/10644/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10644/head] Base: [master] : New Tests
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Security{color} [[tests
2|https://ci2.ignite.apache.org/viewLog.html?buildId=7142379]]
* {color:#013220}SecurityTestSuite:
ClusterNodeOperationPermissionTest.testStopNodeAuthorization - PASSED{color}
* {color:#013220}SecurityTestSuite:
ClusterNodeOperationPermissionTest.testStartNodeAuthorization - PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7142402&buildTypeId=IgniteTests24Java8_RunAll]
> Add authorization of Ignite Cluster Node stop/restart operations.
> -
>
> Key: IGNITE-19277
> URL: https://issues.apache.org/jira/browse/IGNITE-19277
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Critical
> Fix For: 2.15
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Before https://issues.apache.org/jira/browse/IGNITE-15322
> IgniteCluster#restartNodes()/stopNodes() operations were authorized by the
> name of the internal tasks that is used during their execution -
> org.apache.ignite.internal.cluster.IgniteKillTask.
> After https://issues.apache.org/jira/browse/IGNITE-15322 has been resolved,
> authorization of internal tasks is no longer performed. So
> IgniteCluster#restartNodes()/stopNodes() operations are not authorized at
> all.
> We must to fix it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-18255) C++ 3.0: Add KeyValueView
[ https://issues.apache.org/jira/browse/IGNITE-18255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713466#comment-17713466 ] Igor Sapego edited comment on IGNITE-18255 at 4/18/23 8:08 AM: --- Merged to main. was (Author: isapego): Merged to main > C++ 3.0: Add KeyValueView > - > > Key: IGNITE-18255 > URL: https://issues.apache.org/jira/browse/IGNITE-18255 > Project: Ignite > Issue Type: New Feature > Components: platforms >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > Implement KeyValueView in C++ client. Implement column mapping for user > objects. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-16778) Support timestamp through jdbc
[ https://issues.apache.org/jira/browse/IGNITE-16778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky reassigned IGNITE-16778: --- Assignee: Evgeny Stanilovsky > Support timestamp through jdbc > -- > > Key: IGNITE-16778 > URL: https://issues.apache.org/jira/browse/IGNITE-16778 > Project: Ignite > Issue Type: Bug > Components: jdbc, sql >Reporter: Alexander Belyak >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > Attachments: RunnerForTestNode.java > > > Able to use timestamp data type through KV view by LocalDateTime, but no > through jdbc setTimestamp method. Example in attachment -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19296) Unmute PicocliBugTest
Yury Gerzhedovich created IGNITE-19296: -- Summary: Unmute PicocliBugTest Key: IGNITE-19296 URL: https://issues.apache.org/jira/browse/IGNITE-19296 Project: Ignite Issue Type: Improvement Components: cli Reporter: Yury Gerzhedovich The product has muted org.apache.ignite.internal.cli.commands.PicocliBugTest due to a bug which already been fixed. Let's consider updating the version of Picocli and unmuting the test. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17853) Fix release build on TC (.NET documentation)
[
https://issues.apache.org/jira/browse/IGNITE-17853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-17853:
---
Priority: Blocker (was: Critical)
> Fix release build on TC (.NET documentation)
>
>
> Key: IGNITE-17853
> URL: https://issues.apache.org/jira/browse/IGNITE-17853
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Taras Ledkov
>Assignee: Pavel Tupitsyn
>Priority: Blocker
> Fix For: 2.15
>
>
> There is not .NET documentation in the release build.
> [ignite-2.14|https://ci.ignite.apache.org/viewLog.html?buildId=6794645&buildTypeId=Releases_ApacheIg[…]&branch_Releases_ApacheIgniteMain=ignite-1377&_focus=70896]
> release build.
> Build log:
> {code}
> [08:50:17]Step 11/15: Copy .NET docs (Command Line)
> [08:50:17][Step 11/15] Disabled build step Copy .NET docs (Command Line) is
> skipped
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17345) [IEP-35] Metric to track PA enabled request on ThinClient
[ https://issues.apache.org/jira/browse/IGNITE-17345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-17345: --- Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > [IEP-35] Metric to track PA enabled request on ThinClient > - > > Key: IGNITE-17345 > URL: https://issues.apache.org/jira/browse/IGNITE-17345 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: IEP-35, ise > Fix For: 2.15 > > Time Spent: 5.5h > Remaining Estimate: 0h > > The crucial point to understand ThinClient performance is to know - Partition > Awareness enabled or not. > For now, it's impossible to understand how many request goes to node that is > primary for key. > It seems useful metrics to analyze PA behavior - two counters to track amount > of requests for each server node > - one counter for keys current node is primary. > - another counter for keys which require extra network hop between server > nodes to serve the request. > For environment with optimal performance second counter should be close to > zero. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-17345) [IEP-35] Metric to track PA enabled request on ThinClient
[ https://issues.apache.org/jira/browse/IGNITE-17345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov resolved IGNITE-17345. Release Note: Thin client: Added affinity hits/misses metric (for partition awareness requests) Resolution: Fixed [~nizhikov], thanks for the review! Merged to master, cherry-picked to 2.15. > [IEP-35] Metric to track PA enabled request on ThinClient > - > > Key: IGNITE-17345 > URL: https://issues.apache.org/jira/browse/IGNITE-17345 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: IEP-35, ise > Fix For: 2.15 > > Time Spent: 5.5h > Remaining Estimate: 0h > > The crucial point to understand ThinClient performance is to know - Partition > Awareness enabled or not. > For now, it's impossible to understand how many request goes to node that is > primary for key. > It seems useful metrics to analyze PA behavior - two counters to track amount > of requests for each server node > - one counter for keys current node is primary. > - another counter for keys which require extra network hop between server > nodes to serve the request. > For environment with optimal performance second counter should be close to > zero. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17345) [IEP-35] Metric to track PA enabled request on ThinClient
[
https://issues.apache.org/jira/browse/IGNITE-17345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713434#comment-17713434
]
Ignite TC Bot commented on IGNITE-17345:
{panel:title=Branch: [pull/10649/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10649/head] Base: [master] : New Tests
(5)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Thin Client: Java{color} [[tests
5|https://ci2.ignite.apache.org/viewLog.html?buildId=7142822]]
* {color:#013220}ClientTestSuite:
AffinityMetricsTest.testCacheKeyAffinityMetricsReplicated - PASSED{color}
* {color:#013220}ClientTestSuite:
AffinityMetricsTest.testCacheKeyAffinityMetricsTx - PASSED{color}
* {color:#013220}ClientTestSuite:
AffinityMetricsTest.testCacheKeyAffinityMetricsPartitioned - PASSED{color}
* {color:#013220}ClientTestSuite:
AffinityMetricsTest.testQueryAffinityMetricsReplicated - PASSED{color}
* {color:#013220}ClientTestSuite:
AffinityMetricsTest.testQueryAffinityMetricsPartitioned - PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7137296&buildTypeId=IgniteTests24Java8_RunAll]
> [IEP-35] Metric to track PA enabled request on ThinClient
> -
>
> Key: IGNITE-17345
> URL: https://issues.apache.org/jira/browse/IGNITE-17345
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: IEP-35, ise
> Fix For: 2.15
>
> Time Spent: 5h 20m
> Remaining Estimate: 0h
>
> The crucial point to understand ThinClient performance is to know - Partition
> Awareness enabled or not.
> For now, it's impossible to understand how many request goes to node that is
> primary for key.
> It seems useful metrics to analyze PA behavior - two counters to track amount
> of requests for each server node
> - one counter for keys current node is primary.
> - another counter for keys which require extra network hop between server
> nodes to serve the request.
> For environment with optimal performance second counter should be close to
> zero.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
