[jira] [Commented] (IGNITE-20665) DataStreamer: keep order for entries with equal keys / update such entries locally
[
https://issues.apache.org/jira/browse/IGNITE-20665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17776033#comment-17776033
]
Vladislav Pyatkov commented on IGNITE-20665:
[~gdomo] When you invoke the method (addData()), the streamer processes an
operation asynchronously.
If you want strict operation ordering, just wait for the future result or call
flush.
> DataStreamer: keep order for entries with equal keys / update such entries
> locally
> --
>
> Key: IGNITE-20665
> URL: https://issues.apache.org/jira/browse/IGNITE-20665
> Project: Ignite
> Issue Type: Improvement
> Components: streaming
>Affects Versions: 2.15
>Reporter: Grigory Domozhirov
>Priority: Minor
>
> Code below returns "old value":
> {code:java}
> try (
> Ignite ignite = Ignition.start();
> IgniteCache cache = ignite.createCache("test");
> IgniteDataStreamer dataStreamer =
> ignite.dataStreamer(cache.getName())) {
> dataStreamer.allowOverwrite(true);
> for (int i = 0; i < 1000; i++) {
> dataStreamer.addData(0, "old value");
> }
> dataStreamer.addData(0, "new value");
> dataStreamer.flush();
> System.out.println(cache.get(0));
> }
> {code}
> Despite streaming order is not guaranteed by DataStreamer such behaviour
> might be surprising and effectively voids allowOverwrite option.
> Also, it ends up with a lot of outdated entries streamed, decreasing overall
> loading process.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20636) Add to the MakeIndexAvailableCommand the ability to use only the indexId
[ https://issues.apache.org/jira/browse/IGNITE-20636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17776031#comment-17776031 ] Roman Puchkovskiy commented on IGNITE-20636: The patch looks good to me > Add to the MakeIndexAvailableCommand the ability to use only the indexId > > > Key: IGNITE-20636 > URL: https://issues.apache.org/jira/browse/IGNITE-20636 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 50m > Remaining Estimate: 0h > > It is necessary to add to > *org.apache.ignite.internal.catalog.commands.MakeIndexAvailableCommand* the > use of only the indexId and maybe the name of the index and schema, but so > that these parameters do not mix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20659) Placement driver do not create a lease
[
https://issues.apache.org/jira/browse/IGNITE-20659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov reassigned IGNITE-20659:
--
Assignee: Vladislav Pyatkov
> Placement driver do not create a lease
> --
>
> Key: IGNITE-20659
> URL: https://issues.apache.org/jira/browse/IGNITE-20659
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Blocker
> Labels: ignite-3
>
> This behavior has recently appeared in some environments. TC also has the
> same
> [issue|https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7559849?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildProblemsSection=true&expandBuildChangesSection=true&expandBuildTestsSection=true].
> The placement driver correctly started, and the active actor was also ready,
> but for some reason, no lease was created. The result is the timeout
> exception for waiting for a primary replica through the API.
> {noformat}
> 2023-10-15T23:37:32,477][INFO
> ][%iinrt_nwdt_0%JRaft-ReadOnlyService-Disruptor-_stripe_8-0][AssignmentsTracker]
> Assignment cache initialized for placement driver [groupAssignments={}]
> [2023-10-15T23:37:32,478][INFO
> ][%iinrt_nwdt_0%JRaft-ReadOnlyService-Disruptor-_stripe_8-0][TopologyTracker]
> Logical topology initialized for placement driver
> [topologySnap=LogicalTopologySnapshot [version=0, nodes=SetN []]]
> [2023-10-15T23:37:32,483][INFO
> ][%iinrt_nwdt_0%Raft-Group-Client-1][PlacementDriverManager] Placement driver
> active actor is starting.
> ...
> Caused by:
> org.apache.ignite.internal.placementdriver.PrimaryReplicaAwaitTimeoutException:
> IGN-PLACEMENTDRIVER-1 TraceId:c085cfe8-570c-4947-a4b6-ed7c3fea041d The
> primary replica await timed out [replicationGroupId=4_part_0,
> referenceTimestamp=HybridTimestamp [time=111240718117240832,
> physical=1697398652912, logical=0], currentLease=null]
> at
> org.apache.ignite.internal.placementdriver.leases.LeaseTracker.lambda$awaitPrimaryReplica$2(LeaseTracker.java:229)
> at
> java.base/java.util.concurrent.CompletableFuture.uniExceptionally(CompletableFuture.java:986)
> at
> java.base/java.util.concurrent.CompletableFuture$UniExceptionally.tryFire(CompletableFuture.java:970)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> java.base/java.util.concurrent.CompletableFuture$Timeout.run(CompletableFuture.java:2792)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> ... 3 more
> Caused by: java.util.concurrent.TimeoutException
> ... 7 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20444) Sql. Add restrictions for execution tx related statements with single statement mode.
[
https://issues.apache.org/jira/browse/IGNITE-20444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17776025#comment-17776025
]
Evgeny Stanilovsky commented on IGNITE-20444:
-
[~mzhuravkov] thanks for your effort.
> Sql. Add restrictions for execution tx related statements with single
> statement mode.
> -
>
> Key: IGNITE-20444
> URL: https://issues.apache.org/jira/browse/IGNITE-20444
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Append single statement restrictions for using with new tx related sql syntax
> [1] implementation.
> {code:java}
> try (Session ses = client.sql().createSession()) {
> ses.execute(
> null, "_new transactional statement from
> ignite-20442_" <-- such calls need to be rejected
> ).close();
> ses.execute(
> null,
> "some other sql statement"
> ).close();
> }
> {code}
> [1] https://issues.apache.org/jira/browse/IGNITE-20442
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-19219) ODBC 3.0: Implement primary keys query
[ https://issues.apache.org/jira/browse/IGNITE-19219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17776012#comment-17776012 ] Pavel Tupitsyn commented on IGNITE-19219: - [~isapego] looks good to me. > ODBC 3.0: Implement primary keys query > -- > > Key: IGNITE-19219 > URL: https://issues.apache.org/jira/browse/IGNITE-19219 > Project: Ignite > Issue Type: Improvement > Components: odbc >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > This functionality was not implemented properly in Ignite 2, so we probably > will need to re-implement it. > Also port and add tests as needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20436) Thin 3.0: Utilize exception handler in client code
[ https://issues.apache.org/jira/browse/IGNITE-20436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego reassigned IGNITE-20436: Assignee: Igor Sapego (was: Pavel Tupitsyn) > Thin 3.0: Utilize exception handler in client code > -- > > Key: IGNITE-20436 > URL: https://issues.apache.org/jira/browse/IGNITE-20436 > Project: Ignite > Issue Type: Improvement >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Utilize exception handler introduced by IGNITE-19539 in client code. Search > this tickets tag in code for specific places. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20658) Update Ignite dependency: PostgreSQL JDBC to 42.6.0
[
https://issues.apache.org/jira/browse/IGNITE-20658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17775940#comment-17775940
]
Ignite TC Bot commented on IGNITE-20658:
{panel:title=Branch: [pull/10999/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10999/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7564595&buildTypeId=IgniteTests24Java8_RunAll]
> Update Ignite dependency: PostgreSQL JDBC to 42.6.0
> ---
>
> Key: IGNITE-20658
> URL: https://issues.apache.org/jira/browse/IGNITE-20658
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Nikolaev
>Assignee: Aleksandr Nikolaev
>Priority: Major
> Labels: ise
> Fix For: 2.16
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Update Ignite dependency: PostgreSQL JDBC to 42.6.0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20667) .NET: Thin 3.0: Use builders where possible instead of configurations
[ https://issues.apache.org/jira/browse/IGNITE-20667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego reassigned IGNITE-20667: Assignee: (was: Igor Sapego) > .NET: Thin 3.0: Use builders where possible instead of configurations > - > > Key: IGNITE-20667 > URL: https://issues.apache.org/jira/browse/IGNITE-20667 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Consider to use builders instead of configuration + fabric method for cases > like creation of an instance of client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20667) .NET: Thin 3.0: Use builders where possible instead of configurations
Igor Sapego created IGNITE-20667: Summary: .NET: Thin 3.0: Use builders where possible instead of configurations Key: IGNITE-20667 URL: https://issues.apache.org/jira/browse/IGNITE-20667 Project: Ignite Issue Type: Improvement Components: platforms, thin client Affects Versions: 3.0.0-beta1 Reporter: Igor Sapego Assignee: Igor Sapego Fix For: 3.0.0-beta2 Consider to use builders instead of configuration + fabric method for cases like creation of an instance of client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20666) C++ 3.0: Use builders where possible instead of configurations
Igor Sapego created IGNITE-20666: Summary: C++ 3.0: Use builders where possible instead of configurations Key: IGNITE-20666 URL: https://issues.apache.org/jira/browse/IGNITE-20666 Project: Ignite Issue Type: Improvement Components: platforms, thin client Affects Versions: 3.0.0-beta1 Reporter: Igor Sapego Assignee: Igor Sapego Fix For: 3.0.0-beta2 Consider to use builders instead of configuration + fabric method for cases like creation of an instance of client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20366) testBatchReadPutConcurrently failed
[
https://issues.apache.org/jira/browse/IGNITE-20366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-20366:
-
Reviewer: Alexander Lapin
> testBatchReadPutConcurrently failed
> ---
>
> Key: IGNITE-20366
> URL: https://issues.apache.org/jira/browse/IGNITE-20366
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Kirill Sizov
>Priority: Blocker
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:java}
> org.opentest4j.AssertionFailedError: expected: but was: at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36) at
> app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31) at
> app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180) at
> app//org.apache.ignite.internal.table.TxAbstractTest.testBatchReadPutConcurrently(TxAbstractTest.java:467)
> at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base@11.0.17/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566) {code}
> Need to find a root cause of the issue.
> Only
> {{ItTxDistributedTestThreeNodesThreeReplicas.testBatchReadPutConcurrently}}
> is failing out of all subclasses of {{TxAbstractTest}}
> h3. Cause
> *This is a test issue, not a product issue*
> The test checks whether the locks are in the expected state. And this check
> fails because the lock manager is chosen incorrectly and does not have those
> locks.
> The locks are expected to be on the primary and tests select the primary
> using the raft leader, however the product has already switch to placement
> driver.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20665) DataStreamer: keep order for entries with equal keys / update such entries locally
[
https://issues.apache.org/jira/browse/IGNITE-20665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grigory Domozhirov updated IGNITE-20665:
Summary: DataStreamer: keep order for entries with equal keys / update such
entries locally (was: DataStreamer: keep order for entries with equal keys /
replace values before streaming)
> DataStreamer: keep order for entries with equal keys / update such entries
> locally
> --
>
> Key: IGNITE-20665
> URL: https://issues.apache.org/jira/browse/IGNITE-20665
> Project: Ignite
> Issue Type: Improvement
> Components: streaming
>Affects Versions: 2.15
>Reporter: Grigory Domozhirov
>Priority: Minor
>
> Code below returns "old value":
> {code:java}
> try (
> Ignite ignite = Ignition.start();
> IgniteCache cache = ignite.createCache("test");
> IgniteDataStreamer dataStreamer =
> ignite.dataStreamer(cache.getName())) {
> dataStreamer.allowOverwrite(true);
> for (int i = 0; i < 1000; i++) {
> dataStreamer.addData(0, "old value");
> }
> dataStreamer.addData(0, "new value");
> dataStreamer.flush();
> System.out.println(cache.get(0));
> }
> {code}
> Despite streaming order is not guaranteed by DataStreamer such behaviour
> might be surprising and effectively voids allowOverwrite option.
> Also, it ends up with a lot of outdated entries streamed, decreasing overall
> loading process.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20665) DataStreamer: keep order for entries with equal keys / replace values before streaming
Grigory Domozhirov created IGNITE-20665:
---
Summary: DataStreamer: keep order for entries with equal keys /
replace values before streaming
Key: IGNITE-20665
URL: https://issues.apache.org/jira/browse/IGNITE-20665
Project: Ignite
Issue Type: Improvement
Components: streaming
Affects Versions: 2.15
Reporter: Grigory Domozhirov
Code below returns "old value":
{code:java}
try (
Ignite ignite = Ignition.start();
IgniteCache cache = ignite.createCache("test");
IgniteDataStreamer dataStreamer =
ignite.dataStreamer(cache.getName())) {
dataStreamer.allowOverwrite(true);
for (int i = 0; i < 1000; i++) {
dataStreamer.addData(0, "old value");
}
dataStreamer.addData(0, "new value");
dataStreamer.flush();
System.out.println(cache.get(0));
}
{code}
Despite streaming order is not guaranteed by DataStreamer such behaviour might
be surprising and effectively voids allowOverwrite option.
Also, it ends up with a lot of outdated entries streamed, decreasing overall
loading process.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20522) There should be a default user
[ https://issues.apache.org/jira/browse/IGNITE-20522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-20522: --- Summary: There should be a default user (was: There should be a default user, if authentication is enabled) > There should be a default user > -- > > Key: IGNITE-20522 > URL: https://issues.apache.org/jira/browse/IGNITE-20522 > Project: Ignite > Issue Type: Improvement > Components: security >Reporter: Ivan Gagarkin >Assignee: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > Time Spent: 50m > Remaining Estimate: 0h > > We need to add a default user with the credentials "ignite/ignite" for > authentication purposes. > Additionally, the enabled flag should be moved to the top level of the > security configuration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20116) Linearize storage updates with safeTime adjustment rules
[
https://issues.apache.org/jira/browse/IGNITE-20116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17775837#comment-17775837
]
Roman Puchkovskiy commented on IGNITE-20116:
The patch looks good to me
> Linearize storage updates with safeTime adjustment rules
>
>
> Key: IGNITE-20116
> URL: https://issues.apache.org/jira/browse/IGNITE-20116
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Blocker
> Labels: ignite-3, transactions
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> h3. Motivation
> The logic of setting safeTime explicitly prohibits setting a larger time
> ahead of a smaller one. In other words, all data updates within storages
> should be strictly ordered by the safeTime associated with such updates.
> Currently it's not true:
> * We associate update and safe time during update command creation (see
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener)
> {code:java}
> UpdateCommandBuilder bldr = MSG_FACTORY.updateCommand()
> ...
> .safeTimeLong(hybridClock.nowLong()); {code}
> * However, neither applying a given command locally nor sending it to the
> raft isn't linearized with associated safeTime value. In other words, it's
> possible that we will assign t0 to the cmd0 and t1 to the cmd1 but will apply
> cmd1 prior to cmd0 locally.
> Simply speaking, we lack some sort of synchronization here.
> h3. Definition of Done
> * It's required to linearize updates application to preserve guarantees of
> the monotonicity of a safeTime's adjustment.
> h3. Implementation Notes
> Different options are possible:
> # We may reject a command that is associated with safeTime < already applied
> one. Such approach requires
> ## To resend the command with new safeTime in case of 1pc.
> ## Adjust local safeTime, and resend command with new safe time in case of
> 2pc.
> # Add proper synchronization both on client and server side.
> # Send pending safeTime instances with each command. More details below:
> Let’s assume that there were two updateCommands cmd1(safeTime: t1) and
> cmd2(safeTime: t2). Let’s also assume that cmd2 was send prior to cmd2
> (meaning that it was reordered). In that case, assuming that cmd2 has both t1
> and t2 within its data bag, it will wait for cmd1 to bring it data in a queue
> or formally it will wait previous commands to apply themselves.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20654) Forbid init scripts in H2 connections
[
https://issues.apache.org/jira/browse/IGNITE-20654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17775819#comment-17775819
]
Ignite TC Bot commented on IGNITE-20654:
{panel:title=Branch: [pull/10997/head] Base: [master] : Possible Blockers
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Snapshots 2{color} [[tests 0 Exit Code
|https://ci2.ignite.apache.org/viewLog.html?buildId=7564833]]
{color:#d04437}Snapshots 3{color} [[tests 0 Exit Code , Failure on metric
|https://ci2.ignite.apache.org/viewLog.html?buildId=7564835]]
{panel}
{panel:title=Branch: [pull/10997/head] Base: [master] : New Tests
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Queries 3{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7560666]]
* {color:#013220}IgniteBinaryCacheQueryTestSuite3:
H2ConnectionSettingsTest.testForbidInitSetting - PASSED{color}
{color:#8b}Queries 3 (lazy=true){color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7560667]]
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite3:
H2ConnectionSettingsTest.testForbidInitSetting - PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7560695&buildTypeId=IgniteTests24Java8_RunAll]
> Forbid init scripts in H2 connections
> -
>
> Key: IGNITE-20654
> URL: https://issues.apache.org/jira/browse/IGNITE-20654
> Project: Ignite
> Issue Type: Task
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20385) Incorrect code INTERNAL_ERROR on node left
[
https://issues.apache.org/jira/browse/IGNITE-20385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-20385:
--
Description:
During execute SQL query we could got Exception with INTERNAL_ERR in case
remote node left. Node left sholdn't be interpret as INTERNAL ERROR, due to
it's normal situation and user can be informed about it.
Let's map the situation to SqlException with code NODE_LEFT_ERR.
Also need to check wich similar situation we could cover here.
As start point need to find all places where used
ExceptionUtils.withCauseAndCode method
{code:java}
org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:6a9a41f8-a6f4-44f1-87b0-4516c514d1df Unable to send fragment
[targetNode=idt_n_1, fragmentId=1, cause=Node left the cluster. Node: idt_n_1]
at
org.apache.ignite.lang.IgniteExceptionMapperUtil.mapToPublicException(IgniteExceptionMapperUtil.java:106)
at
org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.wrapIfNecessary(AsyncSqlCursorImpl.java:100)
at
org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$0(AsyncSqlCursorImpl.java:76)
at
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at
java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$execute$15(ExecutionServiceImpl.java:747)
at
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at
java.base/java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:946)
at
java.base/java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2266)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$execute$17(ExecutionServiceImpl.java:726)
at
java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
at
java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
at
java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
at
org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:81)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Suppressed: java.lang.RuntimeException: This is a trimmed root
...
Caused by: org.apache.ignite.lang.IgniteInternalException: IGN-CMN-65535
TraceId:6a9a41f8-a6f4-44f1-87b0-4516c514d1df Unable to send fragment
[targetNode=idt_n_1, fragmentId=1, cause=Node left the cluster. Node: idt_n_1]
at
org.apache.ignite.internal.util.ExceptionUtils.lambda$withCauseAndCode$3(ExceptionUtils.java:440)
at
org.apache.ignite.internal.util.ExceptionUtils.withCauseInternal(ExceptionUtils.java:467)
at
org.apache.ignite.internal.util.ExceptionUtils.withCauseAndCode(ExceptionUtils.java:440)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$execute$12(ExecutionServiceImpl.java:714)
at
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at
java.base/java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:946)
at
java.base/java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2266)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$execute$17(ExecutionServiceImpl.java:698)
... 7 more
Caused by: org.apache.ignite.internal.sql.engine.NodeLeftException: IGN-CMN-5
TraceId:bf122f9c-e697-4dfa-b59f-0692595fa94c Node left the cluster. Node:
idt_n_1
at
org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.send(MessageServiceImpl.java:92)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.sendFragment(ExecutionServiceImpl.java:505)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$execute$17(ExecutionServiceImpl.java:695)
... 7 more
{code}
was:
During execute SQL query we could got Exception with INTERNAL_ERR in case
remote node left. Node left sholdn't be interpret as INTERNAL ERROR, due to
it's normal situation and user can be infor
[jira] [Assigned] (IGNITE-20600) Sql. Updating primary key column produces an incorrect error message.
[
https://issues.apache.org/jira/browse/IGNITE-20600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov reassigned IGNITE-20600:
-
Assignee: Maksim Zhuravkov
> Sql. Updating primary key column produces an incorrect error message.
> -
>
> Key: IGNITE-20600
> URL: https://issues.apache.org/jira/browse/IGNITE-20600
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Primary key column update produces an error that contains incorrect error
> description:
> {code:java}
> sql("CREATE TABLE my (id INT PRIMARY KEY, val INT)");
> sql("UPDATE my SET id = 1");
> // Err: Cannot update field "ID". You cannot update key, key fields or val
> field in case the val is a complex type
> {code}
> Update error message so it indicates that primary key columns are not
> modifiable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20387) Remap most exceptions to SqlExceptions for SQL API
[ https://issues.apache.org/jira/browse/IGNITE-20387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-20387: -- Fix Version/s: 3.0.0-beta2 > Remap most exceptions to SqlExceptions for SQL API > -- > > Key: IGNITE-20387 > URL: https://issues.apache.org/jira/browse/IGNITE-20387 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 5h 20m > Remaining Estimate: 0h > > As of now SQL API could throw different type of Exceptions like a > TableAlreadyExistsException, TableNotFoundException, > ColumnAlreadyExistsException and so one. It looks incorrect due to SQL API > should operate just SqlExceptions. > Let's do right mapping in SqlExceptionMapperProvider. > To have more simple test also let's try to generify synchoonus and > asynchronous test (see ItSqlSynchronousApiTest and ItSqlAsynchronousApiTest). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20569) .NET: Thin 3.0: Revise logging
[ https://issues.apache.org/jira/browse/IGNITE-20569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20569: Description: .NET client in Ignite 3.x uses custom *IIgniteLogger* interface. This approach is copied from 2.x client; it is outdated and inefficient. Revise it: * Should we add a dependency on [Microsoft.Extensions.Logging.Abstractions|https://www.nuget.org/packages/Microsoft.Extensions.Logging.Abstractions/6.0.4#dependencies-body-tab], and use standard *ILogger* instead (accept *ILoggerFactory* in config)? * Without that, how do we support structured logging, templates, code-generated loggers? * How do we integrate with popular loggers? With *ILogger* it comes out of the box. was: .NET client in Ignite 3.x uses custom *IIgniteLogger* interface. This approach is copied from 2.x client; it is outdated and inefficient. Revise it: * Should we add a dependency on [Microsoft.Extensions.Logging.Abstractions|https://www.nuget.org/packages/Microsoft.Extensions.Logging.Abstractions/6.0.4#dependencies-body-tab], and use standard *ILogger* instead? * Without that, how do we support structured logging, templates, code-generated loggers? * How do we integrate with popular loggers? With *ILogger* it comes out of the box. > .NET: Thin 3.0: Revise logging > -- > > Key: IGNITE-20569 > URL: https://issues.apache.org/jira/browse/IGNITE-20569 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Blocker > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > .NET client in Ignite 3.x uses custom *IIgniteLogger* interface. This > approach is copied from 2.x client; it is outdated and inefficient. > Revise it: > * Should we add a dependency on > [Microsoft.Extensions.Logging.Abstractions|https://www.nuget.org/packages/Microsoft.Extensions.Logging.Abstractions/6.0.4#dependencies-body-tab], > and use standard *ILogger* instead (accept *ILoggerFactory* in config)? > * Without that, how do we support structured logging, templates, > code-generated loggers? > * How do we integrate with popular loggers? With *ILogger* it comes out of > the box. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20664) Resolve compatibility issue with SnakeYAML versions in Micronaut tests
Ivan Gagarkin created IGNITE-20664:
--
Summary: Resolve compatibility issue with SnakeYAML versions in
Micronaut tests
Key: IGNITE-20664
URL: https://issues.apache.org/jira/browse/IGNITE-20664
Project: Ignite
Issue Type: Bug
Components: cli
Reporter: Ivan Gagarkin
We are encountering an issue with Micronaut tests involving the 'jarhell'
component. Specifically, we are using two different versions of the SnakeYAML
library - version 1.33 and version 2.0. When running the tests from IntelliJ
IDEA, we observe the following error in the
'org.apache.ignite.internal.rest.ItGeneratedRestClientTest' class
{code:java}
java.lang.NoSuchMethodError: org.yaml.snakeyaml.constructor.SafeConstructor:
method 'void ()' not found
at
io.micronaut.context.env.yaml.CustomSafeConstructor.(CustomSafeConstructor.java:36)
at
io.micronaut.context.env.yaml.YamlPropertySourceLoader.processInput(YamlPropertySourceLoader.java:56)
at
io.micronaut.context.env.AbstractPropertySourceLoader.read(AbstractPropertySourceLoader.java:117)
at
io.micronaut.context.env.AbstractPropertySourceLoader.loadProperties(AbstractPropertySourceLoader.java:102)
at
io.micronaut.context.env.AbstractPropertySourceLoader.load(AbstractPropertySourceLoader.java:68)
at
io.micronaut.context.env.AbstractPropertySourceLoader.load(AbstractPropertySourceLoader.java:55)
at
io.micronaut.context.env.DefaultEnvironment.loadPropertySourceFromLoader(DefaultEnvironment.java:607)
at
io.micronaut.context.env.DefaultEnvironment.readPropertySourceList(DefaultEnvironment.java:541)
at
io.micronaut.context.env.DefaultEnvironment.readPropertySourceList(DefaultEnvironment.java:527)
at
io.micronaut.context.DefaultApplicationContext$RuntimeConfiguredEnvironment.readPropertySourceList(DefaultApplicationContext.java:794)
at
io.micronaut.context.env.DefaultEnvironment.readPropertySources(DefaultEnvironment.java:412)
at
io.micronaut.context.env.DefaultEnvironment.start(DefaultEnvironment.java:270)
at
io.micronaut.context.DefaultApplicationContext$RuntimeConfiguredEnvironment.start(DefaultApplicationContext.java:769)
at
io.micronaut.context.DefaultApplicationContext$RuntimeConfiguredEnvironment.start(DefaultApplicationContext.java:738)
at
io.micronaut.context.DefaultApplicationContext.startEnvironment(DefaultApplicationContext.java:242)
at
io.micronaut.context.DefaultApplicationContext.start(DefaultApplicationContext.java:193)
at
io.micronaut.test.extensions.AbstractMicronautExtension.startApplicationContext(AbstractMicronautExtension.java:433)
at
io.micronaut.test.extensions.AbstractMicronautExtension.beforeClass(AbstractMicronautExtension.java:314)
at
io.micronaut.test.extensions.junit5.MicronautJunit5Extension.beforeAll(MicronautJunit5Extension.java:84)
at
org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.lambda$invokeBeforeAllCallbacks$12(ClassBasedTestDescriptor.java:395)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.invokeBeforeAllCallbacks(ClassBasedTestDescriptor.java:395)
at
org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.before(ClassBasedTestDescriptor.java:211)
at
org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.before(ClassBasedTestDescriptor.java:84)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:148)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at
org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1541) at
org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:41)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:155)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestT
[jira] [Updated] (IGNITE-20657) At the checkpoint ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/IGNITE-20657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-20657:
-
Description:
We need to investigate and fix the error:
{noformat}
2023-10-13 08:18:30:080 +0300
[WARNING][%poc-tester-SERVER-192.168.1.55-id-0%checkpoint-thread-2][Checkpointer]
Runtime error caught during ignite runnable execution [worker=IgniteWorker
[name=checkpoint-thread,
igniteInstanceName=poc-tester-SERVER-192.168.1.55-id-0, listener=null,
finished=false, heartbeatTimestamp=1697174310076, hashCode=413706408,
interrupted=false,
runner=%poc-tester-SERVER-192.168.1.55-id-0%checkpoint-thread-2]]
org.apache.ignite.internal.lang.IgniteInternalException: IGN-CMN-65535
TraceId:24a9602a-f323-48a7-8055-d3e72ed19af6
java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0
at
org.apache.ignite.internal.pagememory.persistence.checkpoint.Checkpointer.body(Checkpointer.java:225)
at
org.apache.ignite.internal.util.worker.IgniteWorker.run(IgniteWorker.java:108)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.util.concurrent.CompletionException:
java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
at
java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
at
java.base/java.util.concurrent.CompletableFuture$BiRelay.tryFire(CompletableFuture.java:1423)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
at
org.apache.ignite.internal.pagememory.persistence.checkpoint.CheckpointPagesWriter.run(CheckpointPagesWriter.java:158)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
... 1 more
Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for
length 0
at
java.base/java.util.concurrent.CopyOnWriteArrayList.elementAt(CopyOnWriteArrayList.java:385)
at
java.base/java.util.concurrent.CopyOnWriteArrayList.get(CopyOnWriteArrayList.java:398)
at
org.apache.ignite.internal.pagememory.persistence.store.FilePageStore.getOrCreateNewDeltaFile(FilePageStore.java:288)
at
org.apache.ignite.internal.pagememory.persistence.checkpoint.CheckpointManager.writePageToDeltaFilePageStore(CheckpointManager.java:295)
at
org.apache.ignite.internal.pagememory.persistence.checkpoint.CheckpointManager.lambda$new$0(CheckpointManager.java:126)
at
org.apache.ignite.internal.pagememory.persistence.checkpoint.CheckpointPagesWriter.writePartitionMeta(CheckpointPagesWriter.java:301)
at
org.apache.ignite.internal.pagememory.persistence.checkpoint.CheckpointPagesWriter.writePages(CheckpointPagesWriter.java:219)
at
org.apache.ignite.internal.pagememory.persistence.checkpoint.CheckpointPagesWriter.run(CheckpointPagesWriter.java:147)
... 3 more
{noformat}
h2. Update:
The problem is the usual data race between adding a new delta file at a
checkpoint and compacting the previous (last) delta file.
was:
We need to investigate and fix the error:
{noformat}
2023-10-13 08:18:30:080 +0300
[WARNING][%poc-tester-SERVER-192.168.1.55-id-0%checkpoint-thread-2][Checkpointer]
Runtime error caught during ignite runnable execution [worker=IgniteWorker
[name=checkpoint-thread,
igniteInstanceName=poc-tester-SERVER-192.168.1.55-id-0, listener=null,
finished=false, heartbeatTimestamp=1697174310076, hashCode=413706408,
interrupted=false,
runner=%poc-tester-SERVER-192.168.1.55-id-0%checkpoint-thread-2]]
org.apache.ignite.internal.lang.IgniteInternalException: IGN-CMN-65535
TraceId:24a9602a-f323-48a7-8055-d3e72ed19af6
java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0
at
org.apache.ignite.internal.pagememory.persistence.checkpoint.Checkpointer.body(Checkpointer.java:225)
at
org.apache.ignite.internal.util.worker.IgniteWorker.run(IgniteWorker.java:108)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.util.concurrent.CompletionException:
java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
at
java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
at
java.base/java.util.concurrent.CompletableFuture$BiRelay.tryFire(CompletableFuture.java:1423)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
[jira] [Created] (IGNITE-20663) Thin 3.0: ItThinClientSchemaSynchronizationTest.testClientUsesLatestSchemaOnWrite is flaky
Igor Sapego created IGNITE-20663: Summary: Thin 3.0: ItThinClientSchemaSynchronizationTest.testClientUsesLatestSchemaOnWrite is flaky Key: IGNITE-20663 URL: https://issues.apache.org/jira/browse/IGNITE-20663 Project: Ignite Issue Type: Bug Components: thin client Reporter: Igor Sapego The following test is flaky: https://ci.ignite.apache.org/test/-4306071594745342563?currentProjectId=ApacheIgnite3xGradle_Test_IntegrationTests&expandTestHistoryChartSection=true Need to investigate and fix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20574) Sql. Do not permit to create tables in SYSTEM schema.
[ https://issues.apache.org/jira/browse/IGNITE-20574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-20574: - Assignee: Maksim Zhuravkov > Sql. Do not permit to create tables in SYSTEM schema. > - > > Key: IGNITE-20574 > URL: https://issues.apache.org/jira/browse/IGNITE-20574 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently, The SYSTEM schema should only contain only system view objects; > adding other objects to this schema should not be allowed. > But it is possible to create a table in the SYSTEM schema. We need to > disallow that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19217) ODBC 3.0: Implement foreign keys query
[ https://issues.apache.org/jira/browse/IGNITE-19217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17775731#comment-17775731 ] Pavel Tupitsyn commented on IGNITE-19217: - [~isapego] looks good to me. > ODBC 3.0: Implement foreign keys query > -- > > Key: IGNITE-19217 > URL: https://issues.apache.org/jira/browse/IGNITE-19217 > Project: Ignite > Issue Type: Improvement > Components: odbc >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > As we do not support them natively, probably should just port dummy > functionality and tests from Ignite 2. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20311) Sql. Fix behaviour of ROUND function.
[
https://issues.apache.org/jira/browse/IGNITE-20311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov reassigned IGNITE-20311:
-
Assignee: Maksim Zhuravkov
> Sql. Fix behaviour of ROUND function.
> -
>
> Key: IGNITE-20311
> URL: https://issues.apache.org/jira/browse/IGNITE-20311
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
> causes issues when reading data from a `BinaryTuple` because this way
> ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
> {code}
> SELECT ROUND(1.7)
> # Although the implementation of the round function produces 2, RowSchema
> has NativeType (precision=2, scale=1).
> # Because of that this query returns 2.0
> {code}
> Implementation we agreed upon:
> - For `ROUND(N)` return DECIMAL(p, 0) where p is precision of N's type.
> - For `ROUND(N, s)` return DECIMAL(p, derived_s) where where p is precision
> of N's type, and derived_s is scale of N's type.
> Examples:
> {code}
> # ROUND(N):
> SELECT ROUND(1.1)
> # Returns 1. Type: DECIMAL(p, 0)
> # ROUND(N, s):
> SELECT ROUND(1.123, s) FROM (VALUES (0), (1), (2), (3), (4) ) t(s)
> # Returns
> # 1
> # 1.1
> # 1.12
> # 1.123
> # 1.1230
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20311) Sql. Fix behaviour of ROUND function.
[
https://issues.apache.org/jira/browse/IGNITE-20311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20311:
--
Description:
The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
causes issues when reading data from a `BinaryTuple` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2, RowSchema has
NativeType (precision=2, scale=1).
# Because of that this query returns 2.0
{code}
Implementation we agreed upon:
- For `ROUND(N)` return DECIMAL(p, 0) where p is precision of N's type.
- For `ROUND(N, s)` return DECIMAL(p, derived_s) where where p is precision of
N's type, and derived_s is scale of N's type.
Examples:
{code}
# ROUND(N):
SELECT ROUND(1.1)
# Returns 1, Type: DECIMAL(p, 0)
# ROUND(N, s):
SELECT ROUND(1.123, s) FROM (VALUES (0), (1), (2), (3), (4) ) t(s)
# Returns
# 1
# 1.1
# 1.12
# 1.123
# 1.1230
{code}
was:
The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
causes issues when reading data from a `BinaryTuple` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2, RowSchema has
NativeType (precision=2, scale=1).
# Because of that this query returns 2.0
{code}
Implementation we agreed upon:
- For `ROUND(N)` return DECIMAL(p, 0) where p is precision of N's type.
- For `ROUND(N, s)` return DECIMAL(p, derived_s) where where p is precision of
N's type, and derived_s is scale of N's type.
Examples:
{code}
# ROUND(N):
SELECT ROUND(1.1)
# Returns 1. Type: DECIMAL(p, 0)
# ROUND(N, s):
SELECT ROUND(1.123, s) FROM (VALUES (0), (1), (2), (3), (4) ) t(s)
# Returns
# 1
# 1.1
# 1.12
# 1.123
# 1.1230
{code}
> Sql. Fix behaviour of ROUND function.
> -
>
> Key: IGNITE-20311
> URL: https://issues.apache.org/jira/browse/IGNITE-20311
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
> causes issues when reading data from a `BinaryTuple` because this way
> ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
> {code}
> SELECT ROUND(1.7)
> # Although the implementation of the round function produces 2, RowSchema
> has NativeType (precision=2, scale=1).
> # Because of that this query returns 2.0
> {code}
> Implementation we agreed upon:
> - For `ROUND(N)` return DECIMAL(p, 0) where p is precision of N's type.
> - For `ROUND(N, s)` return DECIMAL(p, derived_s) where where p is precision
> of N's type, and derived_s is scale of N's type.
> Examples:
> {code}
> # ROUND(N):
> SELECT ROUND(1.1)
> # Returns 1, Type: DECIMAL(p, 0)
> # ROUND(N, s):
> SELECT ROUND(1.123, s) FROM (VALUES (0), (1), (2), (3), (4) ) t(s)
> # Returns
> # 1
> # 1.1
> # 1.12
> # 1.123
> # 1.1230
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20366) testBatchReadPutConcurrently failed
[
https://issues.apache.org/jira/browse/IGNITE-20366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Sizov updated IGNITE-20366:
---
Description:
{code:java}
org.opentest4j.AssertionFailedError: expected: but was: at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63) at
app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36) at
app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31) at
app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180) at
app//org.apache.ignite.internal.table.TxAbstractTest.testBatchReadPutConcurrently(TxAbstractTest.java:467)
at
java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base@11.0.17/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566) {code}
Need to find a root cause of the issue.
Only
{{ItTxDistributedTestThreeNodesThreeReplicas.testBatchReadPutConcurrently}} is
failing out of all subclasses of {{TxAbstractTest}}
h4. Cause
*This is a test issue, not a product issue*
The test checks whether the locks are in the expected state. And this check
fails because the lock manager is chosen incorrectly and does not have those
locks.
The locks are expected to be on the primary and tests select the primary using
the raft leader, however the product has already switch to placement driver.
was:
{code:java}
org.opentest4j.AssertionFailedError: expected: but was: at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63) at
app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36) at
app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31) at
app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180) at
app//org.apache.ignite.internal.table.TxAbstractTest.testBatchReadPutConcurrently(TxAbstractTest.java:467)
at
java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base@11.0.17/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566) {code}
Need to find a root cause of the issue.
Only
{{ItTxDistributedTestThreeNodesThreeReplicas.testBatchReadPutConcurrently}} is
failing out of all subclasses of {{TxAbstractTest}}
> testBatchReadPutConcurrently failed
> ---
>
> Key: IGNITE-20366
> URL: https://issues.apache.org/jira/browse/IGNITE-20366
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Kirill Sizov
>Priority: Blocker
> Labels: ignite-3
>
> {code:java}
> org.opentest4j.AssertionFailedError: expected: but was: at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36) at
> app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31) at
> app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180) at
> app//org.apache.ignite.internal.table.TxAbstractTest.testBatchReadPutConcurrently(TxAbstractTest.java:467)
> at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base@11.0.17/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566) {code}
> Need to find a root cause of the issue.
> Only
> {{ItTxDistributedTestThreeNodesThreeReplicas.testBatchReadPutConcurrently}}
> is failing out of all subclasses of {{TxAbstractTest}}
> h4. Cause
> *This is a test issue, not a product issue*
> The test checks whether the locks are in the expected state. And this check
> fails because the lock manager is chosen i
[jira] [Updated] (IGNITE-20366) testBatchReadPutConcurrently failed
[
https://issues.apache.org/jira/browse/IGNITE-20366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Sizov updated IGNITE-20366:
---
Description:
{code:java}
org.opentest4j.AssertionFailedError: expected: but was: at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63) at
app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36) at
app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31) at
app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180) at
app//org.apache.ignite.internal.table.TxAbstractTest.testBatchReadPutConcurrently(TxAbstractTest.java:467)
at
java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base@11.0.17/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566) {code}
Need to find a root cause of the issue.
Only
{{ItTxDistributedTestThreeNodesThreeReplicas.testBatchReadPutConcurrently}} is
failing out of all subclasses of {{TxAbstractTest}}
h3. Cause
*This is a test issue, not a product issue*
The test checks whether the locks are in the expected state. And this check
fails because the lock manager is chosen incorrectly and does not have those
locks.
The locks are expected to be on the primary and tests select the primary using
the raft leader, however the product has already switch to placement driver.
was:
{code:java}
org.opentest4j.AssertionFailedError: expected: but was: at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63) at
app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36) at
app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31) at
app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180) at
app//org.apache.ignite.internal.table.TxAbstractTest.testBatchReadPutConcurrently(TxAbstractTest.java:467)
at
java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base@11.0.17/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566) {code}
Need to find a root cause of the issue.
Only
{{ItTxDistributedTestThreeNodesThreeReplicas.testBatchReadPutConcurrently}} is
failing out of all subclasses of {{TxAbstractTest}}
h4. Cause
*This is a test issue, not a product issue*
The test checks whether the locks are in the expected state. And this check
fails because the lock manager is chosen incorrectly and does not have those
locks.
The locks are expected to be on the primary and tests select the primary using
the raft leader, however the product has already switch to placement driver.
> testBatchReadPutConcurrently failed
> ---
>
> Key: IGNITE-20366
> URL: https://issues.apache.org/jira/browse/IGNITE-20366
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Kirill Sizov
>Priority: Blocker
> Labels: ignite-3
>
> {code:java}
> org.opentest4j.AssertionFailedError: expected: but was: at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36) at
> app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31) at
> app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180) at
> app//org.apache.ignite.internal.table.TxAbstractTest.testBatchReadPutConcurrently(TxAbstractTest.java:467)
> at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base@11.0.17/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566)
[jira] [Updated] (IGNITE-20662) Sql. Test performance of multi statement queries
[ https://issues.apache.org/jira/browse/IGNITE-20662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-20662: -- Description: Let's add some benchmarks to measure performance of multi statement queries. At least two types of tests should be added: * overhead of script processor: run the same single statement query as single statement and as script * performance gain after implementation of sophisticated rules of parallelisation (related ticket will be added later): run sequence of queries as chain of single statements and as script was: Let's add some benchmarks to measure performance of multi statement queries. At least two type of test should be added: * overhead of script processor: run the same single statement query as single statement and as script * performance gain after implementation of sophisticated rules of parallelisation (related ticket will be added later): run sequence of queries as chain of single statements and as script > Sql. Test performance of multi statement queries > > > Key: IGNITE-20662 > URL: https://issues.apache.org/jira/browse/IGNITE-20662 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > Let's add some benchmarks to measure performance of multi statement queries. > At least two types of tests should be added: > * overhead of script processor: run the same single statement query as single > statement and as script > * performance gain after implementation of sophisticated rules of > parallelisation (related ticket will be added later): run sequence of queries > as chain of single statements and as script -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20662) Sql. Test performance of multi statement queries
Konstantin Orlov created IGNITE-20662: - Summary: Sql. Test performance of multi statement queries Key: IGNITE-20662 URL: https://issues.apache.org/jira/browse/IGNITE-20662 Project: Ignite Issue Type: Improvement Components: sql Reporter: Konstantin Orlov Let's add some benchmarks to measure performance of multi statement queries. At least two type of test should be added: * overhead of script processor: run the same single statement query as single statement and as script * performance gain after implementation of sophisticated rules of parallelisation (related ticket will be added later): run sequence of queries as chain of single statements and as script -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20659) Placement driver do not create a lease
[
https://issues.apache.org/jira/browse/IGNITE-20659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-20659:
-
Priority: Blocker (was: Major)
> Placement driver do not create a lease
> --
>
> Key: IGNITE-20659
> URL: https://issues.apache.org/jira/browse/IGNITE-20659
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Blocker
> Labels: ignite-3
>
> This behavior has recently appeared in some environments. TC also has the
> same
> [issue|https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7559849?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildProblemsSection=true&expandBuildChangesSection=true&expandBuildTestsSection=true].
> The placement driver correctly started, and the active actor was also ready,
> but for some reason, no lease was created. The result is the timeout
> exception for waiting for a primary replica through the API.
> {noformat}
> 2023-10-15T23:37:32,477][INFO
> ][%iinrt_nwdt_0%JRaft-ReadOnlyService-Disruptor-_stripe_8-0][AssignmentsTracker]
> Assignment cache initialized for placement driver [groupAssignments={}]
> [2023-10-15T23:37:32,478][INFO
> ][%iinrt_nwdt_0%JRaft-ReadOnlyService-Disruptor-_stripe_8-0][TopologyTracker]
> Logical topology initialized for placement driver
> [topologySnap=LogicalTopologySnapshot [version=0, nodes=SetN []]]
> [2023-10-15T23:37:32,483][INFO
> ][%iinrt_nwdt_0%Raft-Group-Client-1][PlacementDriverManager] Placement driver
> active actor is starting.
> ...
> Caused by:
> org.apache.ignite.internal.placementdriver.PrimaryReplicaAwaitTimeoutException:
> IGN-PLACEMENTDRIVER-1 TraceId:c085cfe8-570c-4947-a4b6-ed7c3fea041d The
> primary replica await timed out [replicationGroupId=4_part_0,
> referenceTimestamp=HybridTimestamp [time=111240718117240832,
> physical=1697398652912, logical=0], currentLease=null]
> at
> org.apache.ignite.internal.placementdriver.leases.LeaseTracker.lambda$awaitPrimaryReplica$2(LeaseTracker.java:229)
> at
> java.base/java.util.concurrent.CompletableFuture.uniExceptionally(CompletableFuture.java:986)
> at
> java.base/java.util.concurrent.CompletableFuture$UniExceptionally.tryFire(CompletableFuture.java:970)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> java.base/java.util.concurrent.CompletableFuture$Timeout.run(CompletableFuture.java:2792)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> ... 3 more
> Caused by: java.util.concurrent.TimeoutException
> ... 7 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20659) Placement driver do not create a lease
[
https://issues.apache.org/jira/browse/IGNITE-20659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-20659:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Placement driver do not create a lease
> --
>
> Key: IGNITE-20659
> URL: https://issues.apache.org/jira/browse/IGNITE-20659
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Blocker
> Labels: ignite-3
>
> This behavior has recently appeared in some environments. TC also has the
> same
> [issue|https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7559849?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildProblemsSection=true&expandBuildChangesSection=true&expandBuildTestsSection=true].
> The placement driver correctly started, and the active actor was also ready,
> but for some reason, no lease was created. The result is the timeout
> exception for waiting for a primary replica through the API.
> {noformat}
> 2023-10-15T23:37:32,477][INFO
> ][%iinrt_nwdt_0%JRaft-ReadOnlyService-Disruptor-_stripe_8-0][AssignmentsTracker]
> Assignment cache initialized for placement driver [groupAssignments={}]
> [2023-10-15T23:37:32,478][INFO
> ][%iinrt_nwdt_0%JRaft-ReadOnlyService-Disruptor-_stripe_8-0][TopologyTracker]
> Logical topology initialized for placement driver
> [topologySnap=LogicalTopologySnapshot [version=0, nodes=SetN []]]
> [2023-10-15T23:37:32,483][INFO
> ][%iinrt_nwdt_0%Raft-Group-Client-1][PlacementDriverManager] Placement driver
> active actor is starting.
> ...
> Caused by:
> org.apache.ignite.internal.placementdriver.PrimaryReplicaAwaitTimeoutException:
> IGN-PLACEMENTDRIVER-1 TraceId:c085cfe8-570c-4947-a4b6-ed7c3fea041d The
> primary replica await timed out [replicationGroupId=4_part_0,
> referenceTimestamp=HybridTimestamp [time=111240718117240832,
> physical=1697398652912, logical=0], currentLease=null]
> at
> org.apache.ignite.internal.placementdriver.leases.LeaseTracker.lambda$awaitPrimaryReplica$2(LeaseTracker.java:229)
> at
> java.base/java.util.concurrent.CompletableFuture.uniExceptionally(CompletableFuture.java:986)
> at
> java.base/java.util.concurrent.CompletableFuture$UniExceptionally.tryFire(CompletableFuture.java:970)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> java.base/java.util.concurrent.CompletableFuture$Timeout.run(CompletableFuture.java:2792)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> ... 3 more
> Caused by: java.util.concurrent.TimeoutException
> ... 7 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20653) C++ client: support SQL script execution
[ https://issues.apache.org/jira/browse/IGNITE-20653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego reassigned IGNITE-20653: Assignee: Igor Sapego > C++ client: support SQL script execution > > > Key: IGNITE-20653 > URL: https://issues.apache.org/jira/browse/IGNITE-20653 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Pavel Pereslegin >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > > support SQL script execution in C++ client -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20661) JDBC. Support multi statement queries by JDBC
Konstantin Orlov created IGNITE-20661:
-
Summary: JDBC. Support multi statement queries by JDBC
Key: IGNITE-20661
URL: https://issues.apache.org/jira/browse/IGNITE-20661
Project: Ignite
Issue Type: Improvement
Components: jdbc
Reporter: Konstantin Orlov
Currently, both {{JdbcStatement#execute}} and
{{JdbcPreparedStatement#execute()}} passes the call to
{{SqlQueryProcessor#querySingleAsync}}. After IGNITE-20443 script processes
will be able to process multi statement queries, thus both call should be
retargeted to introduced {{SqlQueryProcessor#queryScriptAsync}} method.
h3. Definition Of Done
* It's possible to supply entire script to all variations of mentioned methods
of Statement and PreparedStatement
* result of execution of a script meets JDBC contract (see javadocs of
appropriate methods and JDBC v4.3 spec for details)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20660) SQL: broken behavior of OCTET_LENGTH function
Andrey Khitrin created IGNITE-20660:
---
Summary: SQL: broken behavior of OCTET_LENGTH function
Key: IGNITE-20660
URL: https://issues.apache.org/jira/browse/IGNITE-20660
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-beta2
Reporter: Andrey Khitrin
Recently, `OCTET_LENGTH` function acted like a synonym for `LENGTH` function.
But in the latest AI3 versions, it started to decline usual strings:
{code:sql}
sql-cli> select OCTET_LENGTH('Some Text');
SQL query execution error
Failed to validate query. From line 0, column 0 to line 1, column 31: Cast
function cannot convert value of type CHAR(9) to type VARBINARY
{code}
Looks like it only accepts a very specific type of strings:
{code:sql}
sql-cli> select OCTET_LENGTH(x'0123');
╔═══╗
║ OCTET_LENGTH(X'0123') ║
╠═══╣
║ 2 ║
╚═══╝
{code}
But as it said in ANSI99 specification, this function must be able to work with
any correct string.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20659) Placement driver do not create a lease
[
https://issues.apache.org/jira/browse/IGNITE-20659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-20659:
---
Labels: ignite-3 (was: )
> Placement driver do not create a lease
> --
>
> Key: IGNITE-20659
> URL: https://issues.apache.org/jira/browse/IGNITE-20659
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> This behavior has recently appeared in some environments. TC also has the
> same
> [issue|https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7559849?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildProblemsSection=true&expandBuildChangesSection=true&expandBuildTestsSection=true].
> The placement driver correctly started, and the active actor was also ready,
> but for some reason, no lease was created. The result is the timeout
> exception for waiting for a primary replica through the API.
> {noformat}
> 2023-10-15T23:37:32,477][INFO
> ][%iinrt_nwdt_0%JRaft-ReadOnlyService-Disruptor-_stripe_8-0][AssignmentsTracker]
> Assignment cache initialized for placement driver [groupAssignments={}]
> [2023-10-15T23:37:32,478][INFO
> ][%iinrt_nwdt_0%JRaft-ReadOnlyService-Disruptor-_stripe_8-0][TopologyTracker]
> Logical topology initialized for placement driver
> [topologySnap=LogicalTopologySnapshot [version=0, nodes=SetN []]]
> [2023-10-15T23:37:32,483][INFO
> ][%iinrt_nwdt_0%Raft-Group-Client-1][PlacementDriverManager] Placement driver
> active actor is starting.
> ...
> Caused by:
> org.apache.ignite.internal.placementdriver.PrimaryReplicaAwaitTimeoutException:
> IGN-PLACEMENTDRIVER-1 TraceId:c085cfe8-570c-4947-a4b6-ed7c3fea041d The
> primary replica await timed out [replicationGroupId=4_part_0,
> referenceTimestamp=HybridTimestamp [time=111240718117240832,
> physical=1697398652912, logical=0], currentLease=null]
> at
> org.apache.ignite.internal.placementdriver.leases.LeaseTracker.lambda$awaitPrimaryReplica$2(LeaseTracker.java:229)
> at
> java.base/java.util.concurrent.CompletableFuture.uniExceptionally(CompletableFuture.java:986)
> at
> java.base/java.util.concurrent.CompletableFuture$UniExceptionally.tryFire(CompletableFuture.java:970)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> java.base/java.util.concurrent.CompletableFuture$Timeout.run(CompletableFuture.java:2792)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> ... 3 more
> Caused by: java.util.concurrent.TimeoutException
> ... 7 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20659) Placement driver do not create a lease
Vladislav Pyatkov created IGNITE-20659:
--
Summary: Placement driver do not create a lease
Key: IGNITE-20659
URL: https://issues.apache.org/jira/browse/IGNITE-20659
Project: Ignite
Issue Type: Bug
Reporter: Vladislav Pyatkov
This behavior has recently appeared in some environments. TC also has the same
[issue|https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7559849?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildProblemsSection=true&expandBuildChangesSection=true&expandBuildTestsSection=true].
The placement driver correctly started, and the active actor was also ready,
but for some reason, no lease was created. The result is the timeout exception
for waiting for a primary replica through the API.
{noformat}
2023-10-15T23:37:32,477][INFO
][%iinrt_nwdt_0%JRaft-ReadOnlyService-Disruptor-_stripe_8-0][AssignmentsTracker]
Assignment cache initialized for placement driver [groupAssignments={}]
[2023-10-15T23:37:32,478][INFO
][%iinrt_nwdt_0%JRaft-ReadOnlyService-Disruptor-_stripe_8-0][TopologyTracker]
Logical topology initialized for placement driver
[topologySnap=LogicalTopologySnapshot [version=0, nodes=SetN []]]
[2023-10-15T23:37:32,483][INFO
][%iinrt_nwdt_0%Raft-Group-Client-1][PlacementDriverManager] Placement driver
active actor is starting.
...
Caused by:
org.apache.ignite.internal.placementdriver.PrimaryReplicaAwaitTimeoutException:
IGN-PLACEMENTDRIVER-1 TraceId:c085cfe8-570c-4947-a4b6-ed7c3fea041d The primary
replica await timed out [replicationGroupId=4_part_0,
referenceTimestamp=HybridTimestamp [time=111240718117240832,
physical=1697398652912, logical=0], currentLease=null]
at
org.apache.ignite.internal.placementdriver.leases.LeaseTracker.lambda$awaitPrimaryReplica$2(LeaseTracker.java:229)
at
java.base/java.util.concurrent.CompletableFuture.uniExceptionally(CompletableFuture.java:986)
at
java.base/java.util.concurrent.CompletableFuture$UniExceptionally.tryFire(CompletableFuture.java:970)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
java.base/java.util.concurrent.CompletableFuture$Timeout.run(CompletableFuture.java:2792)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
... 3 more
Caused by: java.util.concurrent.TimeoutException
... 7 more
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20640) RAFT client does not change peers after rebalance
[
https://issues.apache.org/jira/browse/IGNITE-20640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Gusakov reassigned IGNITE-20640:
---
Assignee: Kirill Gusakov
> RAFT client does not change peers after rebalance
> -
>
> Key: IGNITE-20640
> URL: https://issues.apache.org/jira/browse/IGNITE-20640
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Kirill Gusakov
>Priority: Blocker
>
> *Motivation*
> Due to nodes starting simultaneously, tests may have several rebalances at
> the start. After the rebalance is finished, the list of peers for the raft
> replication group can be different. The changed list of peers should apply to
> RAFT clients, but it does not happen.
> The method (InternalTableImpl#updateInternalTableRaftGroupService) updates
> clients only on table start and does not consider a further rebalance.
> Currently, we try to send a raft command but receive a timeout exception
> because the leader is absent from the list of peers:
> {noformat}
> [2023-10-13T15:16:18,120][INFO ][%node1%tableManager-io-13][Loza] Start new
> raft node=RaftNodeId [groupId=3_part_12, peer=Peer [consistentId=node1,
> idx=0]] with initial configuration=PeersAndLearners [peers=Set12 [Peer
> [consistentId=node1, idx=0]], learners=SetN []]
> [2023-10-13T15:16:18,472][INFO ][%node2%tableManager-io-14][Loza] Start new
> raft node=RaftNodeId [groupId=3_part_12, peer=Peer [consistentId=node2,
> idx=0]] with initial configuration=PeersAndLearners [peers=Set12 [Peer
> [consistentId=node1, idx=0]], learners=SetN []]
> ...
> [2023-10-13T15:16:18,661][ERROR][%node1%JRaft-Request-Processor-21][RpcRequestProcessor]
> handleRequest ChangePeersAsyncRequestImpl [groupId=3_part_12,
> leaderId=node1, newLearnersList=ArrayList [], newPeersList=ArrayList [node2],
> term=2] failed
> java.lang.IllegalStateException: Not leader
> at
> org.apache.ignite.raft.jraft.core.NodeImpl.listPeers(NodeImpl.java:3293)
> ~[main/:?]
> at
> org.apache.ignite.raft.jraft.rpc.impl.cli.ChangePeersAsyncRequestProcessor.processRequest0(ChangePeersAsyncRequestProcessor.java:55)
> ~[main/:?]
> at
> org.apache.ignite.raft.jraft.rpc.impl.cli.ChangePeersAsyncRequestProcessor.processRequest0(ChangePeersAsyncRequestProcessor.java:36)
> ~[main/:?]
> at
> org.apache.ignite.raft.jraft.rpc.impl.cli.BaseCliRequestProcessor.processRequest(BaseCliRequestProcessor.java:112)
> ~[main/:?]
> at
> org.apache.ignite.raft.jraft.rpc.RpcRequestProcessor.handleRequest(RpcRequestProcessor.java:49)
> ~[main/:?]
> at
> org.apache.ignite.raft.jraft.rpc.RpcRequestProcessor.handleRequest(RpcRequestProcessor.java:29)
> ~[main/:?]
> at
> org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcServer$RpcMessageHandler.lambda$onReceived$0(IgniteRpcServer.java:194)
> ~[main/:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> {noformat}
> *Difinition of done*
> After rebalancing the non-interaction peer list, the list should be updated
> and RAFT commands applied.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20640) RAFT client does not change peers after rebalance
[
https://issues.apache.org/jira/browse/IGNITE-20640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-20640:
-
Priority: Blocker (was: Major)
> RAFT client does not change peers after rebalance
> -
>
> Key: IGNITE-20640
> URL: https://issues.apache.org/jira/browse/IGNITE-20640
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Blocker
>
> *Motivation*
> Due to nodes starting simultaneously, tests may have several rebalances at
> the start. After the rebalance is finished, the list of peers for the raft
> replication group can be different. The changed list of peers should apply to
> RAFT clients, but it does not happen.
> The method (InternalTableImpl#updateInternalTableRaftGroupService) updates
> clients only on table start and does not consider a further rebalance.
> Currently, we try to send a raft command but receive a timeout exception
> because the leader is absent from the list of peers:
> {noformat}
> [2023-10-13T15:16:18,120][INFO ][%node1%tableManager-io-13][Loza] Start new
> raft node=RaftNodeId [groupId=3_part_12, peer=Peer [consistentId=node1,
> idx=0]] with initial configuration=PeersAndLearners [peers=Set12 [Peer
> [consistentId=node1, idx=0]], learners=SetN []]
> [2023-10-13T15:16:18,472][INFO ][%node2%tableManager-io-14][Loza] Start new
> raft node=RaftNodeId [groupId=3_part_12, peer=Peer [consistentId=node2,
> idx=0]] with initial configuration=PeersAndLearners [peers=Set12 [Peer
> [consistentId=node1, idx=0]], learners=SetN []]
> ...
> [2023-10-13T15:16:18,661][ERROR][%node1%JRaft-Request-Processor-21][RpcRequestProcessor]
> handleRequest ChangePeersAsyncRequestImpl [groupId=3_part_12,
> leaderId=node1, newLearnersList=ArrayList [], newPeersList=ArrayList [node2],
> term=2] failed
> java.lang.IllegalStateException: Not leader
> at
> org.apache.ignite.raft.jraft.core.NodeImpl.listPeers(NodeImpl.java:3293)
> ~[main/:?]
> at
> org.apache.ignite.raft.jraft.rpc.impl.cli.ChangePeersAsyncRequestProcessor.processRequest0(ChangePeersAsyncRequestProcessor.java:55)
> ~[main/:?]
> at
> org.apache.ignite.raft.jraft.rpc.impl.cli.ChangePeersAsyncRequestProcessor.processRequest0(ChangePeersAsyncRequestProcessor.java:36)
> ~[main/:?]
> at
> org.apache.ignite.raft.jraft.rpc.impl.cli.BaseCliRequestProcessor.processRequest(BaseCliRequestProcessor.java:112)
> ~[main/:?]
> at
> org.apache.ignite.raft.jraft.rpc.RpcRequestProcessor.handleRequest(RpcRequestProcessor.java:49)
> ~[main/:?]
> at
> org.apache.ignite.raft.jraft.rpc.RpcRequestProcessor.handleRequest(RpcRequestProcessor.java:29)
> ~[main/:?]
> at
> org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcServer$RpcMessageHandler.lambda$onReceived$0(IgniteRpcServer.java:194)
> ~[main/:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> {noformat}
> *Difinition of done*
> After rebalancing the non-interaction peer list, the list should be updated
> and RAFT commands applied.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20636) Add to the MakeIndexAvailableCommand the ability to use only the indexId
[ https://issues.apache.org/jira/browse/IGNITE-20636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-20636: - Description: It is necessary to add to *org.apache.ignite.internal.catalog.commands.MakeIndexAvailableCommand* the use of only the indexId and maybe the name of the index and schema, but so that these parameters do not mix. (was: It is necessary to add to *org.apache.ignite.internal.catalog.commands.MakeIndexAvailableCommand* the use of only the indexId and the name of the index and schema, but so that these parameters do not mix.) > Add to the MakeIndexAvailableCommand the ability to use only the indexId > > > Key: IGNITE-20636 > URL: https://issues.apache.org/jira/browse/IGNITE-20636 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > It is necessary to add to > *org.apache.ignite.internal.catalog.commands.MakeIndexAvailableCommand* the > use of only the indexId and maybe the name of the index and schema, but so > that these parameters do not mix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20622) OOMe during TPC-C scale10
[ https://issues.apache.org/jira/browse/IGNITE-20622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-20622: -- Description: Got OOMe during loading TPC-C database with scale 10 (benchbase). Just starting benchbase with TPC-C benchmark with scale factor is enough to get stable OOMe exception in 10 min. (was: Got OOMe during loading TPC-C database with scale 10 (benchbase). TBD) > OOMe during TPC-C scale10 > - > > Key: IGNITE-20622 > URL: https://issues.apache.org/jira/browse/IGNITE-20622 > Project: Ignite > Issue Type: Bug > Components: networking >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > Got OOMe during loading TPC-C database with scale 10 (benchbase). Just > starting benchbase with TPC-C benchmark with scale factor is enough to get > stable OOMe exception in 10 min. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20579) Finally restrict atomic operations inside the transaction (remove the system property)
[
https://issues.apache.org/jira/browse/IGNITE-20579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17775639#comment-17775639
]
Ignite TC Bot commented on IGNITE-20579:
{panel:title=Branch: [pull/10979/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10979/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7558990&buildTypeId=IgniteTests24Java8_RunAll]
> Finally restrict atomic operations inside the transaction (remove the system
> property)
> --
>
> Key: IGNITE-20579
> URL: https://issues.apache.org/jira/browse/IGNITE-20579
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: ise
> Fix For: 2.16
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20658) Update Ignite dependency: PostgreSQL JDBC to 42.6.0
[ https://issues.apache.org/jira/browse/IGNITE-20658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Nikolaev updated IGNITE-20658: Labels: ise (was: ) > Update Ignite dependency: PostgreSQL JDBC to 42.6.0 > --- > > Key: IGNITE-20658 > URL: https://issues.apache.org/jira/browse/IGNITE-20658 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Aleksandr Nikolaev >Priority: Major > Labels: ise > Fix For: 2.16 > > > Update Ignite dependency: PostgreSQL JDBC to 42.6.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20658) Update Ignite dependency: PostgreSQL JDBC to 42.6.0
Aleksandr Nikolaev created IGNITE-20658: --- Summary: Update Ignite dependency: PostgreSQL JDBC to 42.6.0 Key: IGNITE-20658 URL: https://issues.apache.org/jira/browse/IGNITE-20658 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Nikolaev Assignee: Aleksandr Nikolaev Fix For: 2.16 Update Ignite dependency: PostgreSQL JDBC to 42.6.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20116) Linearize storage updates with safeTime adjustment rules
[
https://issues.apache.org/jira/browse/IGNITE-20116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-20116:
-
Reviewer: Roman Puchkovskiy
> Linearize storage updates with safeTime adjustment rules
>
>
> Key: IGNITE-20116
> URL: https://issues.apache.org/jira/browse/IGNITE-20116
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Blocker
> Labels: ignite-3, transactions
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> h3. Motivation
> The logic of setting safeTime explicitly prohibits setting a larger time
> ahead of a smaller one. In other words, all data updates within storages
> should be strictly ordered by the safeTime associated with such updates.
> Currently it's not true:
> * We associate update and safe time during update command creation (see
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener)
> {code:java}
> UpdateCommandBuilder bldr = MSG_FACTORY.updateCommand()
> ...
> .safeTimeLong(hybridClock.nowLong()); {code}
> * However, neither applying a given command locally nor sending it to the
> raft isn't linearized with associated safeTime value. In other words, it's
> possible that we will assign t0 to the cmd0 and t1 to the cmd1 but will apply
> cmd1 prior to cmd0 locally.
> Simply speaking, we lack some sort of synchronization here.
> h3. Definition of Done
> * It's required to linearize updates application to preserve guarantees of
> the monotonicity of a safeTime's adjustment.
> h3. Implementation Notes
> Different options are possible:
> # We may reject a command that is associated with safeTime < already applied
> one. Such approach requires
> ## To resend the command with new safeTime in case of 1pc.
> ## Adjust local safeTime, and resend command with new safe time in case of
> 2pc.
> # Add proper synchronization both on client and server side.
> # Send pending safeTime instances with each command. More details below:
> Let’s assume that there were two updateCommands cmd1(safeTime: t1) and
> cmd2(safeTime: t2). Let’s also assume that cmd2 was send prior to cmd2
> (meaning that it was reordered). In that case, assuming that cmd2 has both t1
> and t2 within its data bag, it will wait for cmd1 to bring it data in a queue
> or formally it will wait previous commands to apply themselves.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20574) Sql. Do not permit to create tables in SYSTEM schema.
[ https://issues.apache.org/jira/browse/IGNITE-20574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-20574: --- Epic Link: IGNITE-20014 > Sql. Do not permit to create tables in SYSTEM schema. > - > > Key: IGNITE-20574 > URL: https://issues.apache.org/jira/browse/IGNITE-20574 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Currently, The SYSTEM schema should only contain only system view objects; > adding other objects to this schema should not be allowed. > But it is possible to create a table in the SYSTEM schema. We need to > disallow that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20574) Sql. Do not permit to create tables in SYSTEM schema.
[ https://issues.apache.org/jira/browse/IGNITE-20574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-20574: --- Description: Currently, The SYSTEM schema should only contain only system view objects; adding other objects to this schema should not be allowed. But it is possible to create a table in the SYSTEM schema. We need to disallow that. was: Currently, The SYSTEM schema should only contain only system view objects; adding other objects to this schema should not be allowed. But it is possible to create a table in the SYSTEM schema. We need to disallow that. > Sql. Do not permit to create tables in SYSTEM schema. > - > > Key: IGNITE-20574 > URL: https://issues.apache.org/jira/browse/IGNITE-20574 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Currently, The SYSTEM schema should only contain only system view objects; > adding other objects to this schema should not be allowed. > But it is possible to create a table in the SYSTEM schema. We need to > disallow that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18426) Sql. Fix distribution function to use the distribution zone ID instead of the table ID.
[
https://issues.apache.org/jira/browse/IGNITE-18426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-18426:
--
Epic Link: IGNITE-20473
> Sql. Fix distribution function to use the distribution zone ID instead of the
> table ID.
> ---
>
> Key: IGNITE-18426
> URL: https://issues.apache.org/jira/browse/IGNITE-18426
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The affinity function must be adjusted in IGNITE-18211, but it currently uses
> the table ID instead of the distribution zone ID because distribution zones
> do not have table integration.
> We need to fix this after IGNITE-18089.
> Not forget:
> * Enable ItSetOpTest#testSetOpColocated
> * Change the {{zoneId}} type from {{Object}} to actual type.
> * Fix other {{TODO}} related to IGNITE-18426.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-19276) Implement a mechanism to build indices distributively
[
https://issues.apache.org/jira/browse/IGNITE-19276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17775603#comment-17775603
]
Roman Puchkovskiy commented on IGNITE-19276:
The patch looks good to me
> Implement a mechanism to build indices distributively
> -
>
> Key: IGNITE-19276
> URL: https://issues.apache.org/jira/browse/IGNITE-19276
> 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 10m
> Remaining Estimate: 0h
>
> IGNITE-19692 defines a mechanism for executing operations on each partition
> of a table in a resilient way. It should be implemented so that we can build
> an index and switch it to an active state when it's built on all partitions.
> This will allow implement what IGNITE-18539 states:
> {code:java}
> when index is created, we also create a table somewhere that looks similar to
> this:
> indexCompletion..0 = false
> ...
> indexCompletion..N = false {code}
> This part has not been implemented, and it's separated into another issue.
> h3. Things to consider
> * RAFT replica listener node may die after sending last "build index"
> command, thus not updating, so new replica listener must compare states of
> indexes in schema with states of indexes in storage.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20311) Sql. Fix behaviour of ROUND function.
[
https://issues.apache.org/jira/browse/IGNITE-20311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20311:
--
Description:
The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
causes issues when reading data from a `BinaryTuple` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2, RowSchema has
NativeType (precision=2, scale=1).
# Because of that this query returns 2.0
{code}
Implementation we agreed upon:
- For `ROUND(N)` return DECIMAL(p, 0) where p is precision of N's type.
- For `ROUND(N, s)` return DECIMAL(p, derived_s) where where p is precision of
N's type, and derived_s is scale of N's type.
Examples:
{code}
# ROUND(N):
SELECT ROUND(1.1)
# Returns 1. Type: DECIMAL(p, 0)
# ROUND(N, s):
SELECT ROUND(1.123, s) FROM (VALUES (0), (1), (2), (3), (4) ) t(s)
# Returns
# 1
# 1.1
# 1.12
# 1.123
# 1.1230
{code}
was:
The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
causes issues when reading data from a `BinaryTuple` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2, RowSchema has
NativeType (precision=2, scale=1).
# Because of that this query returns 2.0
{code}
Implementation we agreed upon:
- For `ROUND(N)` return DECIMAL(p, 0) where p is precision of N's type.
- For `ROUND(N, s)` return DECIMAL(p, derived_s) where where p is precision of
N's type, and derived_s is scale of N's type.
Examples:
{code}
# ROUND(N):
SELECT ROUND(1.1)
# Returns 1. Type: DECIMAL(p, 0)
# ROUND(N, s):
SELECT ROUND(1.123, s) FROM (VALUES (0), (1), (2), (3), (4) ) t(s)
# Returns
# 1.000
# 1.100
# 1.120
# 1.123
# 1.1230
{code}
> Sql. Fix behaviour of ROUND function.
> -
>
> Key: IGNITE-20311
> URL: https://issues.apache.org/jira/browse/IGNITE-20311
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
> causes issues when reading data from a `BinaryTuple` because this way
> ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
> {code}
> SELECT ROUND(1.7)
> # Although the implementation of the round function produces 2, RowSchema
> has NativeType (precision=2, scale=1).
> # Because of that this query returns 2.0
> {code}
> Implementation we agreed upon:
> - For `ROUND(N)` return DECIMAL(p, 0) where p is precision of N's type.
> - For `ROUND(N, s)` return DECIMAL(p, derived_s) where where p is precision
> of N's type, and derived_s is scale of N's type.
> Examples:
> {code}
> # ROUND(N):
> SELECT ROUND(1.1)
> # Returns 1. Type: DECIMAL(p, 0)
> # ROUND(N, s):
> SELECT ROUND(1.123, s) FROM (VALUES (0), (1), (2), (3), (4) ) t(s)
> # Returns
> # 1
> # 1.1
> # 1.12
> # 1.123
> # 1.1230
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20646) Consider using CLOCK_SKEW unaware await/getPrimaryReplica()
[
https://issues.apache.org/jira/browse/IGNITE-20646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-20646:
---
Description:
h3. Motivation
[Vladislav
Pyatkov|https://issues.apache.org/jira/secure/ViewProfile.jspa?name=vpyatkov]
has strong point that current CLOCK_SKEW aware implementation of
await/getPrimaryReplica should be removed, meaning that we should compare
expirationTimestamp with propagated one without error(CLOCK_SKEW). Same as for
waiting. Current CLOC_SKEW aware approach is specified in
org.apache.ignite.internal.placementdriver.PlacementDriver javadocs and
guarantees that if primary replica is visible from await on node A it'll be
visible thought get on any other node.
h3. Definition of Done
We should prepare full set of pros and cons for each option. Whether they are
correct? Which one is better from the performance point of view? Which one is
simpler?
h3. UPD
The issue is deeper than we described it here. The root cause of the issue is
the placement driver API, which is inappropriate to use for someone who has
never seen the implementation. I mean the two methods, awaitPrimaryReplica and
getPrimaryReplica, because both methods get a timestamp from parameters but
have the internal proposal that the timestamp is the current timestamp for this
node. Nevertheless, functionality is required.
My advise:
{code}
public CompletableFuture awaitPrimaryReplica(
ReplicationGroupId groupId,
long timeout,
TimeUnit unit
) {
return inBusyLockAsync(busyLock, () -> {
CompletableFuture fut = new CompletableFuture<>();
EventListener lnsr = (parameters,
exception) -> {
if (parameters.groupId().equals(groupId)) {
fut.complete(leases.leaseByGroupId().get(groupId));
return completedFuture(true);
}
return completedFuture(false);
};
listen(PRIMARY_REPLICA_ELECTED, lnsr);
// It is a pseudocode, basically. You should get the lease from the
event parameter in the project code.
Lease lease = leases.leaseByGroupId().getOrDefault(groupId,
EMPTY_LEASE);
if (lease.isAccepted()) {
removeListener(PRIMARY_REPLICA_ELECTED, lnsr);
fut.complete(lease);
}
return fut;
});
}
public CompletableFuture getPrimaryReplica(ReplicationGroupId
replicationGroupId, HybridTimestamp timestamp) {
return inBusyLockAsync(busyLock, () -> {
Lease lease =
leases.leaseByGroupId().getOrDefault(replicationGroupId, EMPTY_LEASE);
if (lease.isAccepted() &&
lease.getExpirationTime().compareTo(timestamp) > 0 &&
lease.getStartTime().compareTo(timestamp) < 0
) {
return completedFuture(lease);
}
// TODO: Here we have to compare with the last update placement
driver timestamp. Unfortunately, we do not save the
// timestamp in the lease updater
(Updater#updateLeaseBatchInternal) thread. It must be done in the future.
// Based on Meta storage, safe time is the wrong solution because
the lease timestamp does not depend on the safe time.
return msManager
.clusterTime()
.waitFor(timestamp.addPhysicalTime(CLOCK_SKEW))
.thenApply(ignored -> inBusyLock(busyLock, () -> {
Lease lease0 =
leases.leaseByGroupId().getOrDefault(replicationGroupId, EMPTY_LEASE);
if (lease.isAccepted() &&
lease.getExpirationTime().compareTo(timestamp)
> 0 &&
lease.getStartTime().compareTo(timestamp) < 0
) {
return lease0;
} else {
return null;
}
}));
});
}
{code}
was:
h3. Motivation
[Vladislav
Pyatkov|https://issues.apache.org/jira/secure/ViewProfile.jspa?name=vpyatkov]
has strong point that current CLOCK_SKEW aware implementation of
await/getPrimaryReplica should be removed, meaning that we should compare
expirationTimestamp with propagated one without error(CLOCK_SKEW). Same as for
waiting. Current CLOC_SKEW aware approach is specified in
org.apache.ignite.internal.placementdriver.PlacementDriver javadocs and
guarantees that if primary replica is visible from await on node A it'll be
visible thought get on any other node.
h3. Definition of Done
We should prepare full set of pros and cons for each option. Whether they are
correct? Which one is better from the performance point of view? Which one is
simpler?
> Consider using CLOCK_SKEW unaware await/getPrimaryRepli
[jira] [Assigned] (IGNITE-20560) It's possible to execute commands on a finished transaction under certain circumstances
[
https://issues.apache.org/jira/browse/IGNITE-20560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Sizov reassigned IGNITE-20560:
--
Assignee: Kirill Sizov
> It's possible to execute commands on a finished transaction under certain
> circumstances
> ---
>
> Key: IGNITE-20560
> URL: https://issues.apache.org/jira/browse/IGNITE-20560
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Sizov
>Assignee: Kirill Sizov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If a cleanup operation crashes, it does not affect the transaction it was for
> called since the transaction has been finished already.
> However under certain circumstances we may *get the validation that prevents
> commands from being executed on a finished transaction broken.*
> The issue is that we have
> {{PartitionReplicaListener.TxCleanupReadyFutureList.state}} that duplicates
> local txState, and is updated in the cleanup command handler.
> *Details*
> {{PartitionReplicaListener.TxCleanupReadyFutureList.state}} is
> * +updated+ in {{PartitionReplicaListener.processTxCleanupAction}} and
> * +read+ in {{{}PartitionReplicaListener.appendTxCommand{}}}.
> If the update has not been called because of a crash, the code in
> {{{}appendTxCommand{}}}:
> {code:java}
>txCleanupReadyFutures.compute(txId, (id, txOps) -> {
> if (txOps == null) {
> txOps = new TxCleanupReadyFutureList();
> }
> if (isFinalState(txOps.state)) {
> fut.completeExceptionally(
> new
> TransactionException(TX_FAILED_READ_WRITE_OPERATION_ERR, "Transaction is
> already finished."));
> } else {
> txOps.futures.computeIfAbsent(cmdType, type -> new
> ArrayList<>()).add(fut);
> }
> return txOps;
> });{code}
> will still read {{txOps.state}} as {{PENDING}} and will allow to execute this
> command instead of throwing a {{{}TransactionException{}}}.
> *Motivation*
> The identified issue is that we save a transaction state in two places in a
> primary replica:
> * in txCleanupReadyFutures with cleanup futures,
> * in TxManager#txStateMap where we cached it in the tx state local map.
> *Definition of done*
> # We should remove the transaction state from TxCleanupReadyFutureList and
> use the state that is stored in TxManager and available through
> TxManagerImpl#stateMeta(txId)
> # To resolve tests where we are suppressing TxCleanupReplicaReques
> (ItTxDistributedTestSingleNodeNoCleanupMessage#testTransactionAlreadyRolledback,
> #testTransactionAlreadyCommitted) we have to check the transaction state map
> on the transaction coordinator before trying to enlist a new operation in the
> transaction. Despite the fact that the tests are not completely honest, we
> will avoid executing an operation after a commit timestamp is already chosen.
> # The tests from point 2 should be rewritten because we do not assume to just
> drop TxCleanupReplicaRequest (the handling of TxCleanupReplicaRequest is
> customized so as to skip it) and complete the commit invocation.
> *_Please note there are tests muted with this task._*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20578) Implement scan over system view
[
https://issues.apache.org/jira/browse/IGNITE-20578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17775568#comment-17775568
]
Yury Gerzhedovich commented on IGNITE-20578:
[~korlov] LGTM
> Implement scan over system view
> ---
>
> Key: IGNITE-20578
> URL: https://issues.apache.org/jira/browse/IGNITE-20578
> Project: Ignite
> Issue Type: Improvement
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Although system view definition incudes data provider, it's not very suitable
> for integration with sql engine. First, it exposes objects that should not be
> exposed (for example, data provided for view of Tables exposes the entire
> Table object). Second, it lacks the column that should be injected for node
> views (name of the local node).
> Under this issue, let's close this gap. Suggested api was introduced in
> IGNITE-20437 (see {{SystemViewManager#scanView}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20439) Sql. Support multiple schemas in CatalogSqlSchemaManager.
[ https://issues.apache.org/jira/browse/IGNITE-20439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-20439: -- Priority: Major (was: Minor) > Sql. Support multiple schemas in CatalogSqlSchemaManager. > - > > Key: IGNITE-20439 > URL: https://issues.apache.org/jira/browse/IGNITE-20439 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > CatalogSqlSchemaManager::schema(name) returns a SchemaPlus that only includes > a schema with the specified name, > this makes accessing objects from other schemas not possible. Update > CatalogSqlSchemaManager::schema to include other schemas as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20317) Meta storage invokes are not completed when events are handled in DZM
[ https://issues.apache.org/jira/browse/IGNITE-20317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-20317: - Fix Version/s: 3.0.0-beta2 > Meta storage invokes are not completed when events are handled in DZM > -- > > Key: IGNITE-20317 > URL: https://issues.apache.org/jira/browse/IGNITE-20317 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Uttsel >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > h3. *Motivation* > There are meta storage invokes in DistributionZoneManager in zone's > lifecycle. The futures of these invokes are ignored, so after the lifecycle > method is completed actually not all its actions are completed. Therefore > several invokes for example on createZone and alterZone can be reordered. > Currently it does the meta storage invokes in: > # ZonesConfigurationListener#onCreate to init a zone. > # ZonesConfigurationListener#onDelete to clean up the zone data. > # DistributionZoneManager#onUpdateFilter to save data nodes in the meta > storage. > # DistributionZoneManager#onUpdateScaleUp > # DistributionZoneManager#onUpdateScaleDown > -DistributionZoneRebalanceEngine#onUpdateReplicas to apdate assignment on > replicas update.- > -LogicalTopologyEventListener to update logical topology.- > -DistributionZoneRebalanceEngine#createDistributionZonesDataNodesListener > watch listener to update pending assignments.- > h3. *Definition of Done* > Need to ensure event handling linearization. All immediate data nodes > recalculation must be returned to the event handler. > h3. *Implementation Notes* > * ZonesConfigurationListener#onCreate, ZonesConfigurationListener#onDelete, > DistributionZoneManager#onUpdateFilter and > DistributionZoneRebalanceEngine#onUpdateReplicas are invoked in configuration > listeners. So we can just return the ms invoke future from these methods > and it ensure, that this invoke will be completed within the current event > handling. > * We cannnot return future from LogicalTopologyEventListener's methods. We > can ignore these futures. It has drawback: we can skip the topology update > # topology=[A,B], dataNodes=[A,B], scaleUp=0, scaleDown=100 > # Node C was joined to the topology and left quickly and ms invokes to update > topology entry was reordered. > # data nodes was not updated immediately to [A,B,C]. > We think that we can ignore this bug because eventually it doesn't break the > consistency of the date node. For this purpose we need to change the invoke > condition: > `value(zonesLogicalTopologyVersionKey()).lt(longToBytes(newTopology.version()))` > instead of > `value(zonesLogicalTopologyVersionKey()).eq(longToBytes(newTopology.version() > - 1))` > * Need to return ms invoke futures from WatchListener#onUpdate method of the > data nodes listener. -- This message was sent by Atlassian Jira (v8.20.10#820010)
