[jira] [Created] (IGNITE-19774) .NET: IgniteClientTests.TestToString is flaky
Pavel Tupitsyn created IGNITE-19774:
---
Summary: .NET: IgniteClientTests.TestToString is flaky
Key: IGNITE-19774
URL: https://issues.apache.org/jira/browse/IGNITE-19774
Project: Ignite
Issue Type: Bug
Components: platforms, thin client
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 3.0.0-beta2
{code}
Expected: String containing "Name =
org.apache.ignite.internal.runner.app.PlatformTestNodeRunner, Address =
127.0.0.1:109"
But was: "IgniteClientInternal { Connections = [ ClusterNode { Id =
18f19c31-ccc3-4f4f-8096-f263f2e93a59, Name =
org.apache.ignite.internal.runner.app.PlatformTestNodeRunner_2, Address =
127.0.0.1:10943 } ] }"
at Apache.Ignite.Tests.IgniteClientTests.TestToString() in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/IgniteClientTests.cs:line
59
at
NUnit.Framework.Internal.TaskAwaitAdapter.GenericAdapter`1.BlockUntilCompleted()
at
NUnit.Framework.Internal.MessagePumpStrategy.NoMessagePumpStrategy.WaitForCompletion(AwaitAdapter
awaiter)
at NUnit.Framework.Internal.AsyncToSyncAdapter.Await(Func`1 invoke)
at
NUnit.Framework.Internal.Commands.TestMethodCommand.RunTestMethod(TestExecutionContext
context)
at
NUnit.Framework.Internal.Commands.TestMethodCommand.Execute(TestExecutionContext
context)
at
NUnit.Framework.Internal.Commands.BeforeAndAfterTestCommand.<>c__DisplayClass1_0.b__0()
at
NUnit.Framework.Internal.Commands.DelegatingTestCommand.RunTestMethodInThreadAbortSafeZone(TestExecutionContext
context, Action action)
1)at Apache.Ignite.Tests.IgniteClientTests.TestToString() in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/IgniteClientTests.cs:line
59
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18663) Sql. DATE Literals are not validated correctly.
[
https://issues.apache.org/jira/browse/IGNITE-18663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov reassigned IGNITE-18663:
-
Assignee: (was: Maksim Zhuravkov)
> Sql. DATE Literals are not validated correctly.
> ---
>
> Key: IGNITE-18663
> URL: https://issues.apache.org/jira/browse/IGNITE-18663
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Date literal with incorrect are not rejected. Some examples:
> {code:java}
> # month out of range
> INSERT INTO dates VALUES ('1993-20-14')
> # day out of range
> INSERT INTO dates VALUES ('1993-08-99')
> # day out of range because not a leapyear
> INSERT INTO dates VALUES ('1993-02-29')
> # day out of range because not a leapyear
> INSERT INTO dates VALUES ('1900-02-29')
> {code}
> See more examples in test_incorrect_dates.test
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-19353) Sql. Incorrect type conversion for dynamic parameters - CAST operation ignores type precision.
[
https://issues.apache.org/jira/browse/IGNITE-19353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov reassigned IGNITE-19353:
-
Assignee: Maksim Zhuravkov
> Sql. Incorrect type conversion for dynamic parameters - CAST operation
> ignores type precision.
> --
>
> Key: IGNITE-19353
> URL: https://issues.apache.org/jira/browse/IGNITE-19353
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Current implementation of expression execution runtime incorrectly translates
> types of dynamic parameters because (a) it losses type informations of
> dynamic parameters (see https://issues.apache.org/jira/browse/IGNITE-18831),
> (b) it goes against the rules of calcite's enumerables/link4j (on which the
> code is based), which expect dynamic parameters to be converted into their
> java values according to their inferred types.
> The following code illustrates the problem with character types:
> {code:java}
> @Test
> public void test() {
> assertQuery("SELECT CAST(? AS
> VARCHAR(2))").withParams("abcd").returns("ab").check();
> }
> {code}
> The code returns `abcd` when `ab` is expected.
> Problem with numeric types:
> {code:java}
> @Test
> public void test() {
> assertQuery("SELECT CAST(? AS DECIMAL(2))").withParams(new
> BigDecimal("123")).check();
> }
> {code}
> The code returns original value where Postgres/Oracle/SQL Server return
> conversion error.
> *Solution*: convert values of dynamic parameters to java values according to
> type information inferred at the validation stage and pass converted values
> to expression execution runtime.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19745) Add ability to retrieve/scan over meta storage revisions for a specific key
[
https://issues.apache.org/jira/browse/IGNITE-19745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-19745:
-
Description:
h3. *Motivation*
Occurred that it's not possible to subscribe to old meta storage revision.
Alternative solution will be a combination of subscription for new ones along
with scanning/retrieving old revisions in a following way:
# Register watch with a listener that blocks new entries processing with latch
or similar before all already exisiting entries will be retrieved.
# Retrieve existing entries.
# Unblock watch processing.
Currently there's no method in meta storage API that will provide an ability to
scan over revisions {*}locally{*}, so that we may add such mehod, e.g.
{code:java}
private List doGet(byte[] key, long revLowerBound, long revUpperBound)
{code}
Aforementioned method is a method in RocksDbKeyValueStorage that should be both
properly exposed to ms API and also implemented in KeyValueStorage.
h3. Definition of Done.
It's possible to retrieve/scan over meta storage revisions for a specific key.
was:
h3. *Motivation*
Occurred that it's not possible to subscribe to old meta storage revision.
Alternative solution will be a combination of subscription for new ones along
with scanning/retrieveing old revisions in a following way:
# Register watch with a listener that blocks new entries processing with latch
or similar before all already exisiting entries will be retrieved.
# Retireve exisiting entries.
# Unblock watch processing.
Currently there's no method in meta storage API that will provide an ability to
scan over revisions {*}locally{*}, so that we may add such mehod, e.g.
{code:java}
private List doGet(byte[] key, long revLowerBound, long revUpperBound)
{code}
Aforementioned method is a method in RocksDbKeyValueStorage that should be both
properly exposed to ms API and aslo implemented in KeyValueStorage.
h3. Definition of Done.
It's possible to read specif
> Add ability to retrieve/scan over meta storage revisions for a specific key
> ---
>
> Key: IGNITE-19745
> URL: https://issues.apache.org/jira/browse/IGNITE-19745
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Uttsel
>Assignee: Sergey Uttsel
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. *Motivation*
> Occurred that it's not possible to subscribe to old meta storage revision.
> Alternative solution will be a combination of subscription for new ones along
> with scanning/retrieving old revisions in a following way:
> # Register watch with a listener that blocks new entries processing with
> latch or similar before all already exisiting entries will be retrieved.
> # Retrieve existing entries.
> # Unblock watch processing.
> Currently there's no method in meta storage API that will provide an ability
> to scan over revisions {*}locally{*}, so that we may add such mehod, e.g.
>
> {code:java}
> private List doGet(byte[] key, long revLowerBound, long revUpperBound)
> {code}
> Aforementioned method is a method in RocksDbKeyValueStorage that should be
> both properly exposed to ms API and also implemented in KeyValueStorage.
> h3. Definition of Done.
> It's possible to retrieve/scan over meta storage revisions for a specific key.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19745) Add ability to retrieve/scan over meta storage revisions for a specific key
[
https://issues.apache.org/jira/browse/IGNITE-19745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-19745:
-
Description:
h3. *Motivation*
Occurred that it's not possible to subscribe to old meta storage revision.
Alternative solution will be a combination of subscription for new ones along
with scanning/retrieving old revisions in a following way:
# Register watch with a listener that blocks new entries processing with latch
or similar before all already exisiting entries will be retrieved.
# Retrieve existing entries.
# Unblock watch processing.
Currently there's no method in meta storage API that will provide an ability to
scan over revisions {*}locally{*}, so that we may add such mehod, e.g.
{code:java}
private List doGet(byte[] key, long revLowerBound, long revUpperBound)
{code}
Aforementioned method is a method in RocksDbKeyValueStorage that should be both
properly exposed to ms API and also implemented in KeyValueStorage.
h3. Definition of Done.
It's possible to retrieve/scan over meta storage revisions for a specific key.
was:
h3. *Motivation*
Occurred that it's not possible to subscribe to old meta storage revision.
Alternative solution will be a combination of subscription for new ones along
with scanning/retrieving old revisions in a following way:
# Register watch with a listener that blocks new entries processing with latch
or similar before all already exisiting entries will be retrieved.
# Retrieve existing entries.
# Unblock watch processing.
Currently there's no method in meta storage API that will provide an ability to
scan over revisions {*}locally{*}, so that we may add such mehod, e.g.
{code:java}
private List doGet(byte[] key, long revLowerBound, long revUpperBound)
{code}
Aforementioned method is a method in RocksDbKeyValueStorage that should be both
properly exposed to ms API and also implemented in KeyValueStorage.
h3. Definition of Done.
It's possible to retrieve/scan over meta storage revisions for a specific key.
> Add ability to retrieve/scan over meta storage revisions for a specific key
> ---
>
> Key: IGNITE-19745
> URL: https://issues.apache.org/jira/browse/IGNITE-19745
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Uttsel
>Assignee: Sergey Uttsel
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. *Motivation*
> Occurred that it's not possible to subscribe to old meta storage revision.
> Alternative solution will be a combination of subscription for new ones along
> with scanning/retrieving old revisions in a following way:
> # Register watch with a listener that blocks new entries processing with
> latch or similar before all already exisiting entries will be retrieved.
> # Retrieve existing entries.
> # Unblock watch processing.
> Currently there's no method in meta storage API that will provide an ability
> to scan over revisions {*}locally{*}, so that we may add such mehod, e.g.
> {code:java}
> private List doGet(byte[] key, long revLowerBound, long revUpperBound)
> {code}
> Aforementioned method is a method in RocksDbKeyValueStorage that should be
> both properly exposed to ms API and also implemented in KeyValueStorage.
> h3. Definition of Done.
> It's possible to retrieve/scan over meta storage revisions for a specific key.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19745) Add ability to retrieve/scan over meta storage revisions for a specific key
[
https://issues.apache.org/jira/browse/IGNITE-19745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-19745:
-
Description:
h3. *Motivation*
Occurred that it's not possible to subscribe to old meta storage revision.
Alternative solution will be a combination of subscription for new ones along
with scanning/retrieveing old revisions in a following way:
# Register watch with a listener that blocks new entries processing with latch
or similar before all already exisiting entries will be retrieved.
# Retireve exisiting entries.
# Unblock watch processing.
Currently there's no method in meta storage API that will provide an ability to
scan over revisions {*}locally{*}, so that we may add such mehod, e.g.
{code:java}
private List doGet(byte[] key, long revLowerBound, long revUpperBound)
{code}
Aforementioned method is a method in RocksDbKeyValueStorage that should be both
properly exposed to ms API and aslo implemented in KeyValueStorage.
h3. Definition of Done.
It's possible to read specif
was:
h3. *Motivation*
In https://issues.apache.org/jira/browse/IGNITE-19735 I have tried to extends
MetaStorageManager api with
{code:java}
void registerPrefixWatch(ByteArray key, long startRevision, WatchListener
lsnr){code}
method for the watch listeners receive the events with revision lower than the
applied revision. The KeyValueStorage#watchRange method already has a start
revision number so the issue seems easy. But I have written a test and see that
the watch listener receives events with revisions which are grater than the
applied revision only. See
https://github.com/gridgain/apache-ignite-3/tree/ignite-19735_1 and test
ItMetaStorageWatchTest#testWatchWithOldStartRevision.
h3. *Definition of Done*
Watch listeners which were registered with a start revision lower that the
applied revision must receive all events from a start revision.
> Add ability to retrieve/scan over meta storage revisions for a specific key
> ---
>
> Key: IGNITE-19745
> URL: https://issues.apache.org/jira/browse/IGNITE-19745
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Uttsel
>Assignee: Sergey Uttsel
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. *Motivation*
> Occurred that it's not possible to subscribe to old meta storage revision.
> Alternative solution will be a combination of subscription for new ones along
> with scanning/retrieveing old revisions in a following way:
> # Register watch with a listener that blocks new entries processing with
> latch or similar before all already exisiting entries will be retrieved.
> # Retireve exisiting entries.
> # Unblock watch processing.
> Currently there's no method in meta storage API that will provide an ability
> to scan over revisions {*}locally{*}, so that we may add such mehod, e.g.
>
> {code:java}
> private List doGet(byte[] key, long revLowerBound, long revUpperBound)
> {code}
> Aforementioned method is a method in RocksDbKeyValueStorage that should be
> both properly exposed to ms API and aslo implemented in KeyValueStorage.
> h3. Definition of Done.
> It's possible to read specif
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19745) Add ability to retrieve/scan over meta storage revisions for a specific key
[
https://issues.apache.org/jira/browse/IGNITE-19745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-19745:
-
Summary: Add ability to retrieve/scan over meta storage revisions for a
specific key (was: Watch listeners don't receive events with revision lower
than the applied revision)
> Add ability to retrieve/scan over meta storage revisions for a specific key
> ---
>
> Key: IGNITE-19745
> URL: https://issues.apache.org/jira/browse/IGNITE-19745
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Uttsel
>Assignee: Sergey Uttsel
>Priority: Major
> Labels: ignite-3
>
> h3. *Motivation*
> In https://issues.apache.org/jira/browse/IGNITE-19735 I have tried to extends
> MetaStorageManager api with
> {code:java}
> void registerPrefixWatch(ByteArray key, long startRevision, WatchListener
> lsnr){code}
> method for the watch listeners receive the events with revision lower than
> the applied revision. The KeyValueStorage#watchRange method already has a
> start revision number so the issue seems easy. But I have written a test and
> see that the watch listener receives events with revisions which are grater
> than the applied revision only. See
> https://github.com/gridgain/apache-ignite-3/tree/ignite-19735_1 and test
> ItMetaStorageWatchTest#testWatchWithOldStartRevision.
> h3. *Definition of Done*
> Watch listeners which were registered with a start revision lower that the
> applied revision must receive all events from a start revision.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19419) Internal queue overload under intensive SQL load
[
https://issues.apache.org/jira/browse/IGNITE-19419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Khitrin updated IGNITE-19419:
Summary: Internal queue overload under intensive SQL load (was: Corrupted
LogStorage under intensive SQL load)
> Internal queue overload under intensive SQL load
>
>
> Key: IGNITE-19419
> URL: https://issues.apache.org/jira/browse/IGNITE-19419
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: ignite-3, storage-engine
> Attachments: ai3.jstack, logs.zip
>
>
> I tried to run a SQL benchmark (slightly modified [Benchbase TPC-C
> scenario|https://github.com/cmu-db/benchbase/wiki/TPC-C]) against Ignite3
> (commit hash b48ddcba7cd2bd3b9a053ae131c25b44a0400e27).
> Ignite3 was running in a single-node mode with -Xmx8G -Xms8G memory limit
> (increased memory size comparing to IGNITE-19412). After some time it has
> become unavailable to the client. Log is filled with error messages like the
> following:
>
> {code:java}
> 2023-05-03 17:51:57:705 +0300
> [WARNING][%node0%JRaft-FSMCaller-Disruptor-_stripe_10-0][NodeImpl] Node
> got error: Error
> [type=ERROR_TYPE_LOG, status=Status[EBUSY<1009>: LogManager is busy, disk
> queue overload.]].
> 2023-05-03 17:51:57:705 +0300
> [WARNING][CompletableFutureDelayScheduler][RaftGroupServiceImpl] Recoverable
> error during the request type=ActionRequestImpl occurred (will be retried on
> the randomly selected node):
> java.util.concurrent.CompletionException:
> java.util.concurrent.TimeoutException
> at
> java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:367)
> at
> java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:376)
> at
> java.base/java.util.concurrent.CompletableFuture$UniRelay.tryFire(CompletableFuture.java:1019)
> 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)
> 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:829)
> Caused by: java.util.concurrent.TimeoutException
> ... 7 more
> 2023-05-03 17:51:57:705 +0300
> [ERROR][%node0%JRaft-LogManager-Disruptor-_stripe_10-0][NodeImpl] Node
> append [2268, 2268]
> failed, status=Status[EIO<1014>: Corrupted LogStorage].
> 2023-05-03 17:51:57:705 +0300
> [WARNING][%node0%JRaft-FSMCaller-Disruptor-_stripe_10-0][FSMCallerImpl]
> FSMCaller already in error status, ignore new error
> Error [type=ERROR_TYPE_LOG, status=Status[EBUSY<1009>: LogManager is busy,
> disk queue overload.]]
> at
> org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.reportError(LogManagerImpl.java:587)
> at
> org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.appendEntries(LogManagerImpl.java:337)
> at
> org.apache.ignite.raft.jraft.core.NodeImpl.executeApplyingTasks(NodeImpl.java:1621)
> at
> org.apache.ignite.raft.jraft.core.NodeImpl$LogEntryAndClosureHandler.onEvent(NodeImpl.java:305)
> at
> org.apache.ignite.raft.jraft.core.NodeImpl$LogEntryAndClosureHandler.onEvent(NodeImpl.java:288)
> at
> org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:217)
> at
> org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:181)
> at
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:137)
> at java.base/java.lang.Thread.run(Thread.java:829)
> 2023-05-03 17:51:57:706 +0300
> [INFO][%node0%JRaft-FSMCaller-Disruptor-_stripe_10-0][ReplicatorGroupImpl]
> Fail to find the next candidate.
> 2023-05-03 17:51:57:706 +0300
> [ERROR][%node0%JRaft-LogManager-Disruptor-_stripe_10-0][NodeImpl] Node
> append [2271, 2271]
> failed, status=Status[EIO<1014>: Corrupted LogStorage].
> 2023-05-03 17:51:57:706 +0300
> [INFO][%node0%JRaft-FSMCaller-Disruptor-_stripe_10-0][StateMachineAdapter]
> onLeaderStop: status=Status[EBADNODE<10009>: Raft
[jira] [Assigned] (IGNITE-19730) Sql. Different tests failed in scope of ExecutionServiceImplTest
[
https://issues.apache.org/jira/browse/IGNITE-19730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky reassigned IGNITE-19730:
---
Assignee: Evgeny Stanilovsky
> Sql. Different tests failed in scope of ExecutionServiceImplTest
>
>
> Key: IGNITE-19730
> URL: https://issues.apache.org/jira/browse/IGNITE-19730
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> different tests failed under ExecutionServiceImplTest, with :
> {code:java}
> Expected :true
> Actual :false
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImplTest.tearDown(ExecutionServiceImplTest.java:159)
> {code}
> reproduced in main (79a841d95247c338b80ab91a9)
> Step to reproduce : run ExecutionServiceImplTest *until failure* and after 5+
> run unstable tests become visible.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19730) Sql. Different tests failed in scope of ExecutionServiceImplTest
[
https://issues.apache.org/jira/browse/IGNITE-19730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-19730:
Description:
different tests failed under ExecutionServiceImplTest, with :
{code:java}
Expected :true
Actual :false
at
org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImplTest.tearDown(ExecutionServiceImplTest.java:159)
{code}
reproduced in main (79a841d95247c338b80ab91a9)
Step to reproduce : run ExecutionServiceImplTest *until failure* and after 5+
run unstable tests become visible.
was:
different tests failed under ExecutionServiceImplTest, with :
{code:java}
Expected :true
Actual :false
at
org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImplTest.tearDown(ExecutionServiceImplTest.java:159)
{code}
reproduced in main (79a841d95247c338b80ab91a9)
Spet to reproduce : run ExecutionServiceImplTest *until failure* and after 5+
run unstable tests become visible.
> Sql. Different tests failed in scope of ExecutionServiceImplTest
>
>
> Key: IGNITE-19730
> URL: https://issues.apache.org/jira/browse/IGNITE-19730
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> different tests failed under ExecutionServiceImplTest, with :
> {code:java}
> Expected :true
> Actual :false
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImplTest.tearDown(ExecutionServiceImplTest.java:159)
> {code}
> reproduced in main (79a841d95247c338b80ab91a9)
> Step to reproduce : run ExecutionServiceImplTest *until failure* and after 5+
> run unstable tests become visible.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19766) Add topology snapshot to the services system view
[ https://issues.apache.org/jira/browse/IGNITE-19766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Amelchev updated IGNITE-19766: - Fix Version/s: 2.16 > Add topology snapshot to the services system view > - > > Key: IGNITE-19766 > URL: https://issues.apache.org/jira/browse/IGNITE-19766 > Project: Ignite > Issue Type: Task >Reporter: Nikita Amelchev >Assignee: Nikita Amelchev >Priority: Major > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > > Add topology snapshot info to the services system view -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19626) C# Client should provide a list of deployment units on compute
[ https://issues.apache.org/jira/browse/IGNITE-19626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19626: Ignite Flags: (was: Docs Required,Release Notes Required) > C# Client should provide a list of deployment units on compute > -- > > Key: IGNITE-19626 > URL: https://issues.apache.org/jira/browse/IGNITE-19626 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Ivan Gagarkin >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > > During work on IGNITE-19565 all org.apache.ignite.compute.IgniteCompute's > methods were extended with a list of units used to execute a job. > We need to support those changes in C# Client and update tests as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19626) C# Client should provide a list of deployment units on compute
[ https://issues.apache.org/jira/browse/IGNITE-19626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19626: Labels: .NET ignite-3 (was: ignite-3) > C# Client should provide a list of deployment units on compute > -- > > Key: IGNITE-19626 > URL: https://issues.apache.org/jira/browse/IGNITE-19626 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Ivan Gagarkin >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > > During work on IGNITE-19565 all org.apache.ignite.compute.IgniteCompute's > methods were extended with a list of units used to execute a job. > We need to support those changes in C# Client and update tests as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19626) .NET: Client should provide a list of deployment units on compute
[ https://issues.apache.org/jira/browse/IGNITE-19626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19626: Summary: .NET: Client should provide a list of deployment units on compute (was: C# Client should provide a list of deployment units on compute) > .NET: Client should provide a list of deployment units on compute > - > > Key: IGNITE-19626 > URL: https://issues.apache.org/jira/browse/IGNITE-19626 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Ivan Gagarkin >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > > During work on IGNITE-19565 all org.apache.ignite.compute.IgniteCompute's > methods were extended with a list of units used to execute a job. > We need to support those changes in C# Client and update tests as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19756) Thin 3.0: Colocation column order is not preserved
[ https://issues.apache.org/jira/browse/IGNITE-19756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-19756: - Priority: Critical (was: Blocker) > Thin 3.0: Colocation column order is not preserved > -- > > Key: IGNITE-19756 > URL: https://issues.apache.org/jira/browse/IGNITE-19756 > Project: Ignite > Issue Type: Bug > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > [ClientTableCommon#writeSchema|https://github.com/apache/ignite-3/blob/317aca963ed9c87e14dd6eebd3284408fb550c8c/modules/client-handler/src/main/java/org/apache/ignite/client/handler/requests/table/ClientTableCommon.java#L75] > does not preserve the order of colocation columns. It assumes that key > column order is the same as colocation column order, which is not always true. > * Fix *writeSchema* somehow to specify the order of colocation columns (maybe > send their indices as a separate array) > * Fix clients (.NET, Java, C++) accordingly -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19205) ODBC 3.0: Implemnet data buffers from Ignite 2 using Ignite 3 protocol
[ https://issues.apache.org/jira/browse/IGNITE-19205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego reassigned IGNITE-19205: Assignee: Igor Sapego > ODBC 3.0: Implemnet data buffers from Ignite 2 using Ignite 3 protocol > -- > > Key: IGNITE-19205 > URL: https://issues.apache.org/jira/browse/IGNITE-19205 > Project: Ignite > Issue Type: Improvement > Components: odbc >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > To be done: > - Return functionality to all classes from ignite/odbc/app, re-write them > using our new protocol; > - Port related tests from Ignite 2; -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19624) Java Client should provide a list of deployment units on compute
[ https://issues.apache.org/jira/browse/IGNITE-19624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego reassigned IGNITE-19624: Assignee: Pavel Tupitsyn > Java Client should provide a list of deployment units on compute > > > Key: IGNITE-19624 > URL: https://issues.apache.org/jira/browse/IGNITE-19624 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Ivan Gagarkin >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > > During work on IGNITE-19565 all org.apache.ignite.compute.IgniteCompute's > methods were extended with a list of units used to execute a job. > We need to support those changes in Java Client and update tests as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19625) C++ Client should provide a list of deployment units on compute
[ https://issues.apache.org/jira/browse/IGNITE-19625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego reassigned IGNITE-19625: Assignee: Igor Sapego > C++ Client should provide a list of deployment units on compute > --- > > Key: IGNITE-19625 > URL: https://issues.apache.org/jira/browse/IGNITE-19625 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Ivan Gagarkin >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > > During work on IGNITE-19565 all org.apache.ignite.compute.IgniteCompute's > methods were extended with a list of units used to execute a job. > We need to support those changes in C++ Client and update tests as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19626) C# Client should provide a list of deployment units on compute
[ https://issues.apache.org/jira/browse/IGNITE-19626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego reassigned IGNITE-19626: Assignee: Pavel Tupitsyn > C# Client should provide a list of deployment units on compute > -- > > Key: IGNITE-19626 > URL: https://issues.apache.org/jira/browse/IGNITE-19626 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Ivan Gagarkin >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > > During work on IGNITE-19565 all org.apache.ignite.compute.IgniteCompute's > methods were extended with a list of units used to execute a job. > We need to support those changes in C# Client and update tests as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19617) Embedded Basic Data Streamer
[ https://issues.apache.org/jira/browse/IGNITE-19617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19617: Summary: Embedded Basic Data Streamer (was: Server-side Basic Data Streamer) > Embedded Basic Data Streamer > > > Key: IGNITE-19617 > URL: https://issues.apache.org/jira/browse/IGNITE-19617 > Project: Ignite > Issue Type: Task > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-102, ignite-3 > Fix For: 3.0.0-beta2 > > > Implement basic data streamer in Java server API (*RecordViewImpl*, > *KeyValueViewImpl*, *RecordBinaryViewImpl*, *KeyValueBinaryViewImpl*) without > receiver - see Use Case 1 in the > [IEP-102|https://cwiki.apache.org/confluence/display/IGNITE/IEP-102%3A+Data+Streamer]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19617) Embedded Basic Data Streamer
[ https://issues.apache.org/jira/browse/IGNITE-19617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19617: Description: Implement basic data streamer in Java embedded API (*RecordViewImpl*, *KeyValueViewImpl*, *RecordBinaryViewImpl*, *KeyValueBinaryViewImpl*) without receiver - see Use Case 1 in the [IEP-102|https://cwiki.apache.org/confluence/display/IGNITE/IEP-102%3A+Data+Streamer]. (was: Implement basic data streamer in Java server API (*RecordViewImpl*, *KeyValueViewImpl*, *RecordBinaryViewImpl*, *KeyValueBinaryViewImpl*) without receiver - see Use Case 1 in the [IEP-102|https://cwiki.apache.org/confluence/display/IGNITE/IEP-102%3A+Data+Streamer].) > Embedded Basic Data Streamer > > > Key: IGNITE-19617 > URL: https://issues.apache.org/jira/browse/IGNITE-19617 > Project: Ignite > Issue Type: Task > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-102, ignite-3 > Fix For: 3.0.0-beta2 > > > Implement basic data streamer in Java embedded API (*RecordViewImpl*, > *KeyValueViewImpl*, *RecordBinaryViewImpl*, *KeyValueBinaryViewImpl*) without > receiver - see Use Case 1 in the > [IEP-102|https://cwiki.apache.org/confluence/display/IGNITE/IEP-102%3A+Data+Streamer]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-19749) AccessDeniedException on Windows
[
https://issues.apache.org/jira/browse/IGNITE-19749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko resolved IGNITE-19749.
--
Reviewer: Ivan Bessonov
Resolution: Fixed
> AccessDeniedException on Windows
>
>
> Key: IGNITE-19749
> URL: https://issues.apache.org/jira/browse/IGNITE-19749
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {noformat}
> org.apache.ignite.lang.IgniteInternalException: IGN-CMN-65535
> TraceId:ac3ebe36-c426-4388-ba3f-02294db2cc19
> org.apache.ignite.lang.IgniteInternalCheckedException: IGN-CMN-65535
> TraceId:b9bc45c5-0f89-42cd-b530-b7f356ca268f Error when renaming delta file:
> D:\work\ignite-3\modules\ignite3-ycsb-work\1686841339026\db\db\table-1\part-0-delta-0.bin.tmp
> at
> org.apache.ignite.internal.pagememory.persistence.checkpoint.Checkpointer.body(Checkpointer.java:224)
> at
> org.apache.ignite.internal.util.worker.IgniteWorker.run(IgniteWorker.java:108)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.util.concurrent.CompletionException:
> org.apache.ignite.lang.IgniteInternalCheckedException: IGN-CMN-65535
> TraceId:b9bc45c5-0f89-42cd-b530-b7f356ca268f Error when renaming delta file:
> D:\work\ignite-3\modules\ignite3-ycsb-work\1686841339026\db\db\table-1\part-0-delta-0.bin.tmp
> 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.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.pagememory.persistence.checkpoint.Checkpointer.lambda$syncUpdatedPageStores$0(Checkpointer.java:490)
> 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: org.apache.ignite.lang.IgniteInternalCheckedException:
> IGN-CMN-65535 TraceId:b9bc45c5-0f89-42cd-b530-b7f356ca268f Error when
> renaming delta file:
> D:\work\ignite-3\modules\ignite3-ycsb-work\1686841339026\db\db\table-1\part-0-delta-0.bin.tmp
> at
> org.apache.ignite.internal.pagememory.persistence.checkpoint.Checkpointer.renameDeltaFileOnCheckpointThread(Checkpointer.java:782)
> at
> org.apache.ignite.internal.pagememory.persistence.checkpoint.Checkpointer.fsyncDeltaFile(Checkpointer.java:521)
> at
> org.apache.ignite.internal.pagememory.persistence.checkpoint.Checkpointer.lambda$syncUpdatedPageStores$0(Checkpointer.java:483)
> ... 3 more
> Caused by: java.nio.file.FileAlreadyExistsException:
> D:\work\ignite-3\modules\ignite3-ycsb-work\1686841339026\db\db\table-1\part-0-delta-0.bin.tmp
> ->
> D:\work\ignite-3\modules\ignite3-ycsb-work\1686841339026\db\db\table-1\part-0-delta-0.bin
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:87)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:395)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:292)
> at java.base/java.nio.file.Files.move(Files.java:1421)
> at
> org.apache.ignite.internal.util.IgniteUtils.atomicMoveFile(IgniteUtils.java:771)
> at
> org.apache.ignite.internal.pagememory.persistence.store.AbstractFilePageStoreIo.renameFilePath(AbstractFilePageStoreIo.java:598)
> at
> org.apache.ignite.internal.pagememory.persistence.checkpoint.Checkpointer.renameDeltaFileOnCheckpointThread(Checkpointer.java:780)
> ... 5 more
> Suppressed: java.nio.file.AccessDeniedException:
> D:\work\ignite-3\modules\ignite3-ycsb-work\1686841339026\db\db\table-1\part-0-delta-0.bin.tmp
> ->
> D:\work\ignite-3\modules\ignite3-ycsb-work\1686841339026\db\db\table-1\part-0-delta-0.bin
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at
> java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:309)
> at
>
[jira] [Updated] (IGNITE-19773) Move Wal, Diagnostic, Encryption, Kill, Snapshot, Meta, Property, Consistency task classes to "org.apache.ignite.internal.management" package
[ https://issues.apache.org/jira/browse/IGNITE-19773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valery Shorin updated IGNITE-19773: --- Description: Move Wal, Diagnostic, Encryption, Kill, Snapshot, Meta, Property, Consistency task classes to "org.apache.ignite.internal.management" package (was: Move Baseline, Tx, ChangeTag, ShutdownPolicy, TracingConfiguration, Metric, Persistence, Defragmentation, PerformanceStatistics, Cdc task classes to "org.apache.ignite.internal.management" package) > Move Wal, Diagnostic, Encryption, Kill, Snapshot, Meta, Property, Consistency > task classes to "org.apache.ignite.internal.management" package > - > > Key: IGNITE-19773 > URL: https://issues.apache.org/jira/browse/IGNITE-19773 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.16 >Reporter: Valery Shorin >Assignee: Valery Shorin >Priority: Major > Labels: IEP-81 > Fix For: 2.16 > > > Move Wal, Diagnostic, Encryption, Kill, Snapshot, Meta, Property, Consistency > task classes to "org.apache.ignite.internal.management" package -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19773) Move Wal, Diagnostic, Encryption, Kill, Snapshot, Meta, Property, Consistency task classes to "org.apache.ignite.internal.management" package
Valery Shorin created IGNITE-19773: -- Summary: Move Wal, Diagnostic, Encryption, Kill, Snapshot, Meta, Property, Consistency task classes to "org.apache.ignite.internal.management" package Key: IGNITE-19773 URL: https://issues.apache.org/jira/browse/IGNITE-19773 Project: Ignite Issue Type: Sub-task Affects Versions: 2.16 Reporter: Valery Shorin Assignee: Valery Shorin Fix For: 2.16 Move Baseline, Tx, ChangeTag, ShutdownPolicy, TracingConfiguration, Metric, Persistence, Defragmentation, PerformanceStatistics, Cdc task classes to "org.apache.ignite.internal.management" package -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-19771) Move Baseline, Tx, ChangeTag, ShutdownPolicy, TracingConfiguration, Metric, Persistence, Defragmentation, PerformanceStatistics, Cdc task classes to "org.apache.ignite
[ https://issues.apache.org/jira/browse/IGNITE-19771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valery Shorin resolved IGNITE-19771. Resolution: Resolved > Move Baseline, Tx, ChangeTag, ShutdownPolicy, TracingConfiguration, Metric, > Persistence, Defragmentation, PerformanceStatistics, Cdc task classes to > "org.apache.ignite.internal.management" package > > > Key: IGNITE-19771 > URL: https://issues.apache.org/jira/browse/IGNITE-19771 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.16 >Reporter: Valery Shorin >Assignee: Valery Shorin >Priority: Major > Labels: IEP-81 > Fix For: 2.16 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Move Baseline, Tx, ChangeTag, ShutdownPolicy, TracingConfiguration, Metric, > Persistence, Defragmentation, PerformanceStatistics, Cdc task classes to > "org.apache.ignite.internal.management" package -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19500) IndexManager should listen CatalogService events instead of configuration
[ https://issues.apache.org/jira/browse/IGNITE-19500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-19500: - Ignite Flags: (was: Docs Required,Release Notes Required) > IndexManager should listen CatalogService events instead of configuration > - > > Key: IGNITE-19500 > URL: https://issues.apache.org/jira/browse/IGNITE-19500 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > As of now, IndexManager listens configuration events to create internal > structures. > Let's make IndexManager listens CatalogService events instead. > Note: Some tests may fails due to changed guarantees and related ticked > incompletion. So, let's do this in a separate feature branch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19500) IndexManager should listen CatalogService events instead of configuration
[ https://issues.apache.org/jira/browse/IGNITE-19500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-19500: - Fix Version/s: 3.0.0-beta2 > IndexManager should listen CatalogService events instead of configuration > - > > Key: IGNITE-19500 > URL: https://issues.apache.org/jira/browse/IGNITE-19500 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > As of now, IndexManager listens configuration events to create internal > structures. > Let's make IndexManager listens CatalogService events instead. > Note: Some tests may fails due to changed guarantees and related ticked > incompletion. So, let's do this in a separate feature branch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19450) Add * char to latest version of unit in list command
[ https://issues.apache.org/jira/browse/IGNITE-19450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin reassigned IGNITE-19450: -- Assignee: Mikhail Pochatkin > Add * char to latest version of unit in list command > > > Key: IGNITE-19450 > URL: https://issues.apache.org/jira/browse/IGNITE-19450 > Project: Ignite > Issue Type: New Feature >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: iep-103, ignite-3 > > *$ ignite3 cluster unit list [] [--version > ]] [--status [UPLOADING[, DEPLOYED [, …* > > Output example: > > |Unit |Version|Status | > |foo.example.job |1.0.0 |DEPLOYED | > |foo.example.job |*1.0.1 |DEPLOYED | > |foo.example.job |1.0.2 |UPLOADING| > |foo.example.task|*1.0.0 |DEPLOYED | > > The asterisk symbol * in the Version column highlights the latest *deployed* > version of a deployment unit on the cluster. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18663) Sql. DATE Literals are not validated correctly.
[
https://issues.apache.org/jira/browse/IGNITE-18663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov reassigned IGNITE-18663:
-
Assignee: Maksim Zhuravkov
> Sql. DATE Literals are not validated correctly.
> ---
>
> Key: IGNITE-18663
> URL: https://issues.apache.org/jira/browse/IGNITE-18663
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Date literal with incorrect are not rejected. Some examples:
> {code:java}
> # month out of range
> INSERT INTO dates VALUES ('1993-20-14')
> # day out of range
> INSERT INTO dates VALUES ('1993-08-99')
> # day out of range because not a leapyear
> INSERT INTO dates VALUES ('1993-02-29')
> # day out of range because not a leapyear
> INSERT INTO dates VALUES ('1900-02-29')
> {code}
> See more examples in test_incorrect_dates.test
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19771) Move Baseline, Tx, ChangeTag, ShutdownPolicy, TracingConfiguration, Metric, Persistence, Defragmentation, PerformanceStatistics, Cdc task classes to "org.apache.ignite.
[ https://issues.apache.org/jira/browse/IGNITE-19771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valery Shorin updated IGNITE-19771: --- Description: Move Baseline, Tx, ChangeTag, ShutdownPolicy, TracingConfiguration, Metric, Persistence, Defragmentation, PerformanceStatistics, Cdc task classes to "org.apache.ignite.internal.management" package (was: Move Baseline, Tx, ChangeTag, ShutdownPolicy, TracingConfiguration, Metric, Persistence, Defragmentation, PerformanceStatistics, Cdctask classes to "org.apache.ignite.internal.management" package) > Move Baseline, Tx, ChangeTag, ShutdownPolicy, TracingConfiguration, Metric, > Persistence, Defragmentation, PerformanceStatistics, Cdc task classes to > "org.apache.ignite.internal.management" package > > > Key: IGNITE-19771 > URL: https://issues.apache.org/jira/browse/IGNITE-19771 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.16 >Reporter: Valery Shorin >Assignee: Valery Shorin >Priority: Major > Labels: IEP-81 > Fix For: 2.16 > > > Move Baseline, Tx, ChangeTag, ShutdownPolicy, TracingConfiguration, Metric, > Persistence, Defragmentation, PerformanceStatistics, Cdc task classes to > "org.apache.ignite.internal.management" package -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19771) Move Baseline, Tx, ChangeTag, ShutdownPolicy, TracingConfiguration, Metric, Persistence, Defragmentation, PerformanceStatistics, Cdc task classes to "org.apache.ignite.
[ https://issues.apache.org/jira/browse/IGNITE-19771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valery Shorin updated IGNITE-19771: --- Summary: Move Baseline, Tx, ChangeTag, ShutdownPolicy, TracingConfiguration, Metric, Persistence, Defragmentation, PerformanceStatistics, Cdc task classes to "org.apache.ignite.internal.management" package (was: Move Baseline, Tx, ChangeTag, ShutdownPolicy, TracingConfiguration, Metric, Persistence, Defragmentation, PerformanceStatistics, Cdctask classes to "org.apache.ignite.internal.management" package) > Move Baseline, Tx, ChangeTag, ShutdownPolicy, TracingConfiguration, Metric, > Persistence, Defragmentation, PerformanceStatistics, Cdc task classes to > "org.apache.ignite.internal.management" package > > > Key: IGNITE-19771 > URL: https://issues.apache.org/jira/browse/IGNITE-19771 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.16 >Reporter: Valery Shorin >Assignee: Valery Shorin >Priority: Major > Labels: IEP-81 > Fix For: 2.16 > > > Move Baseline, Tx, ChangeTag, ShutdownPolicy, TracingConfiguration, Metric, > Persistence, Defragmentation, PerformanceStatistics, Cdctask classes to > "org.apache.ignite.internal.management" package -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19745) Watch listeners don't receive events with revision lower than the applied revision
[
https://issues.apache.org/jira/browse/IGNITE-19745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Uttsel reassigned IGNITE-19745:
--
Assignee: Sergey Uttsel
> Watch listeners don't receive events with revision lower than the applied
> revision
> --
>
> Key: IGNITE-19745
> URL: https://issues.apache.org/jira/browse/IGNITE-19745
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Uttsel
>Assignee: Sergey Uttsel
>Priority: Major
> Labels: ignite-3
>
> h3. *Motivation*
> In https://issues.apache.org/jira/browse/IGNITE-19735 I have tried to extends
> MetaStorageManager api with
> {code:java}
> void registerPrefixWatch(ByteArray key, long startRevision, WatchListener
> lsnr){code}
> method for the watch listeners receive the events with revision lower than
> the applied revision. The KeyValueStorage#watchRange method already has a
> start revision number so the issue seems easy. But I have written a test and
> see that the watch listener receives events with revisions which are grater
> than the applied revision only. See
> https://github.com/gridgain/apache-ignite-3/tree/ignite-19735_1 and test
> ItMetaStorageWatchTest#testWatchWithOldStartRevision.
> h3. *Definition of Done*
> Watch listeners which were registered with a start revision lower that the
> applied revision must receive all events from a start revision.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-19772) Compilation error in main branch
[ https://issues.apache.org/jira/browse/IGNITE-19772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-19772: Assignee: Vyacheslav Koptilin > Compilation error in main branch > > > Key: IGNITE-19772 > URL: https://issues.apache.org/jira/browse/IGNITE-19772 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Uttsel >Assignee: Vyacheslav Koptilin >Priority: Blocker > Labels: ignite-3 > > /opt/buildagent/work/b8d4df1365f1f1e5/modules/distribution-zones/src/test/java/org/apache/ignite/internal/distributionzones/DistributionZoneCausalityDataNodesTest.java:51: > error: cannot find symbol > import > org.apache.ignite.internal.distributionzones.exception.DistributionZoneNotFoundException; -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19772) Compilation error in main branch
[ https://issues.apache.org/jira/browse/IGNITE-19772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-19772: Assignee: Sergey Uttsel (was: Vyacheslav Koptilin) > Compilation error in main branch > > > Key: IGNITE-19772 > URL: https://issues.apache.org/jira/browse/IGNITE-19772 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Uttsel >Assignee: Sergey Uttsel >Priority: Blocker > Labels: ignite-3 > > /opt/buildagent/work/b8d4df1365f1f1e5/modules/distribution-zones/src/test/java/org/apache/ignite/internal/distributionzones/DistributionZoneCausalityDataNodesTest.java:51: > error: cannot find symbol > import > org.apache.ignite.internal.distributionzones.exception.DistributionZoneNotFoundException; -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19772) Compilation error in main branch
[ https://issues.apache.org/jira/browse/IGNITE-19772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-19772: - Priority: Blocker (was: Critical) > Compilation error in main branch > > > Key: IGNITE-19772 > URL: https://issues.apache.org/jira/browse/IGNITE-19772 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Uttsel >Priority: Blocker > Labels: ignite-3 > > /opt/buildagent/work/b8d4df1365f1f1e5/modules/distribution-zones/src/test/java/org/apache/ignite/internal/distributionzones/DistributionZoneCausalityDataNodesTest.java:51: > error: cannot find symbol > import > org.apache.ignite.internal.distributionzones.exception.DistributionZoneNotFoundException; -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19772) Compilation error in main branch
[ https://issues.apache.org/jira/browse/IGNITE-19772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel updated IGNITE-19772: --- Ignite Flags: (was: Docs Required,Release Notes Required) > Compilation error in main branch > > > Key: IGNITE-19772 > URL: https://issues.apache.org/jira/browse/IGNITE-19772 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Uttsel >Priority: Critical > Labels: ignite-3 > > /opt/buildagent/work/b8d4df1365f1f1e5/modules/distribution-zones/src/test/java/org/apache/ignite/internal/distributionzones/DistributionZoneCausalityDataNodesTest.java:51: > error: cannot find symbol > import > org.apache.ignite.internal.distributionzones.exception.DistributionZoneNotFoundException; -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19772) Compilation error in main branch
[ https://issues.apache.org/jira/browse/IGNITE-19772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel updated IGNITE-19772: --- Priority: Critical (was: Major) > Compilation error in main branch > > > Key: IGNITE-19772 > URL: https://issues.apache.org/jira/browse/IGNITE-19772 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Uttsel >Priority: Critical > Labels: ignite-3 > > /opt/buildagent/work/b8d4df1365f1f1e5/modules/distribution-zones/src/test/java/org/apache/ignite/internal/distributionzones/DistributionZoneCausalityDataNodesTest.java:51: > error: cannot find symbol > import > org.apache.ignite.internal.distributionzones.exception.DistributionZoneNotFoundException; -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19772) Compilation error in main branch
Sergey Uttsel created IGNITE-19772: -- Summary: Compilation error in main branch Key: IGNITE-19772 URL: https://issues.apache.org/jira/browse/IGNITE-19772 Project: Ignite Issue Type: Bug Reporter: Sergey Uttsel /opt/buildagent/work/b8d4df1365f1f1e5/modules/distribution-zones/src/test/java/org/apache/ignite/internal/distributionzones/DistributionZoneCausalityDataNodesTest.java:51: error: cannot find symbol import org.apache.ignite.internal.distributionzones.exception.DistributionZoneNotFoundException; -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19767) Update Ignite dependency: Jetty
[ https://issues.apache.org/jira/browse/IGNITE-19767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-19767: --- Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Update Ignite dependency: Jetty > --- > > Key: IGNITE-19767 > URL: https://issues.apache.org/jira/browse/IGNITE-19767 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Aleksandr Nikolaev >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Update Jetty dependency 9.4.43.v20210629 to 9.4.51.v20230217 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19771) Move Baseline, Tx, ChangeTag, ShutdownPolicy, TracingConfiguration, Metric, Persistence, Defragmentation, PerformanceStatistics, Cdctask classes to "org.apache.ignite.i
Valery Shorin created IGNITE-19771: -- Summary: Move Baseline, Tx, ChangeTag, ShutdownPolicy, TracingConfiguration, Metric, Persistence, Defragmentation, PerformanceStatistics, Cdctask classes to "org.apache.ignite.internal.management" package Key: IGNITE-19771 URL: https://issues.apache.org/jira/browse/IGNITE-19771 Project: Ignite Issue Type: Sub-task Affects Versions: 2.16 Reporter: Valery Shorin Assignee: Valery Shorin Fix For: 2.16 Move Cache-related task classes to "org.apache.ignite.internal.management.cache" package -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19771) Move Baseline, Tx, ChangeTag, ShutdownPolicy, TracingConfiguration, Metric, Persistence, Defragmentation, PerformanceStatistics, Cdctask classes to "org.apache.ignite.i
[ https://issues.apache.org/jira/browse/IGNITE-19771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valery Shorin updated IGNITE-19771: --- Description: Move Baseline, Tx, ChangeTag, ShutdownPolicy, TracingConfiguration, Metric, Persistence, Defragmentation, PerformanceStatistics, Cdctask classes to "org.apache.ignite.internal.management" package (was: Move Baseline, Tx, ChangeTag, ShutdownPolicy, TracingConfiguration, Metric, Persistence, Defragmentation, PerformanceStatistics, Cdctask classes to "org.apache.ignite.internal.management package) > Move Baseline, Tx, ChangeTag, ShutdownPolicy, TracingConfiguration, Metric, > Persistence, Defragmentation, PerformanceStatistics, Cdctask classes to > "org.apache.ignite.internal.management" package > --- > > Key: IGNITE-19771 > URL: https://issues.apache.org/jira/browse/IGNITE-19771 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.16 >Reporter: Valery Shorin >Assignee: Valery Shorin >Priority: Major > Labels: IEP-81 > Fix For: 2.16 > > > Move Baseline, Tx, ChangeTag, ShutdownPolicy, TracingConfiguration, Metric, > Persistence, Defragmentation, PerformanceStatistics, Cdctask classes to > "org.apache.ignite.internal.management" package -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19771) Move Baseline, Tx, ChangeTag, ShutdownPolicy, TracingConfiguration, Metric, Persistence, Defragmentation, PerformanceStatistics, Cdctask classes to "org.apache.ignite.i
[ https://issues.apache.org/jira/browse/IGNITE-19771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valery Shorin updated IGNITE-19771: --- Description: Move Baseline, Tx, ChangeTag, ShutdownPolicy, TracingConfiguration, Metric, Persistence, Defragmentation, PerformanceStatistics, Cdctask classes to "org.apache.ignite.internal.management package (was: Move Cache-related task classes to "org.apache.ignite.internal.management.cache" package) > Move Baseline, Tx, ChangeTag, ShutdownPolicy, TracingConfiguration, Metric, > Persistence, Defragmentation, PerformanceStatistics, Cdctask classes to > "org.apache.ignite.internal.management" package > --- > > Key: IGNITE-19771 > URL: https://issues.apache.org/jira/browse/IGNITE-19771 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.16 >Reporter: Valery Shorin >Assignee: Valery Shorin >Priority: Major > Labels: IEP-81 > Fix For: 2.16 > > > Move Baseline, Tx, ChangeTag, ShutdownPolicy, TracingConfiguration, Metric, > Persistence, Defragmentation, PerformanceStatistics, Cdctask classes to > "org.apache.ignite.internal.management package -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19584) Calcite engine. SQL metrics
[
https://issues.apache.org/jira/browse/IGNITE-19584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17734045#comment-17734045
]
Ignite TC Bot commented on IGNITE-19584:
{panel:title=Branch: [pull/10777/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10777/head] Base: [master] : New Tests
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Calcite SQL{color} [[tests
3|https://ci2.ignite.apache.org/viewLog.html?buildId=7217288]]
* {color:#013220}IgniteCalciteTestSuite:
SqlDiagnosticIntegrationTest.testBatchParserMetrics - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
SqlDiagnosticIntegrationTest.testParserMetrics - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
SqlDiagnosticIntegrationTest.testUserQueriesMetrics - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7217369buildTypeId=IgniteTests24Java8_RunAll]
> Calcite engine. SQL metrics
> ---
>
> Key: IGNITE-19584
> URL: https://issues.apache.org/jira/browse/IGNITE-19584
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.16
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, we have two groups (registries) of metrics for SQL:
> * "sql.parser.cache" - shows count of hits/misses during SQL queries parsing
> * "sql.queries.user" - shows count of succesfully executed and failed metrics
> Parser metrics are not affected by Calcite-based engine and execution metrics
> count all metrics as succesfully executed.
> We need to implement parser metrics and fix execution metrics.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19506) Use data nodes from DistributionZoneManager with a causality token instead of BaselineManager#nodes
[ https://issues.apache.org/jira/browse/IGNITE-19506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel updated IGNITE-19506: --- Attachment: Causality data nodes.docx > Use data nodes from DistributionZoneManager with a causality token instead of > BaselineManager#nodes > --- > > Key: IGNITE-19506 > URL: https://issues.apache.org/jira/browse/IGNITE-19506 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Uttsel >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3 > Attachments: Causality data nodes.docx > > Time Spent: 1h > Remaining Estimate: 0h > > h3. *Motivation* > Need to use data nodes from DistributionZoneManager instead of > BaselineManager#nodes in: > # DistributionZoneRebalanceEngine#onUpdateReplicas > # TableManager#createAssignmentsSwitchRebalanceListener > We need to get data nodes consistently so we need to use revision of > configuration events and a meta storage events as causality token. Also need > to use VersionedValue to save data nodes with causality token. > Description of causality data nodes algorithm is attached. > h3. *Definition of Done* > DistributionZoneRebalanceEngine#onUpdateReplicas and > TableManager#createAssignmentsSwitchRebalanceListener use data nodes from > DistributionZoneManager -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19506) Use data nodes from DistributionZoneManager with a causality token instead of BaselineManager#nodes
[ https://issues.apache.org/jira/browse/IGNITE-19506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel updated IGNITE-19506: --- Description: h3. *Motivation* Need to use data nodes from DistributionZoneManager instead of BaselineManager#nodes in: # DistributionZoneRebalanceEngine#onUpdateReplicas # TableManager#createAssignmentsSwitchRebalanceListener We need to get data nodes consistently so we need to use revision of configuration events and a meta storage events as causality token. Also need to use VersionedValue to save data nodes with causality token. Description of causality data nodes algorithm is attached. h3. *Definition of Done* DistributionZoneRebalanceEngine#onUpdateReplicas and TableManager#createAssignmentsSwitchRebalanceListener use data nodes from DistributionZoneManager was: h3. *Motivation* Need to use data nodes from DistributionZoneManager instead of BaselineManager#nodes in: # DistributionZoneRebalanceEngine#onUpdateReplicas # TableManager#createAssignmentsSwitchRebalanceListener We need to get data nodes consistently so we need to use revision of configuration events and a meta storage events as causality token. Also need to use VersionedValue to save data nodes with causality token. Description of causality data nodes algorithm: https://docs.google.com/document/d/1fq7HpHNF-hFEv8w8oIQCLAZObj3s5klrbQxuhsF7Dy0 h3. *Definition of Done* DistributionZoneRebalanceEngine#onUpdateReplicas and TableManager#createAssignmentsSwitchRebalanceListener use data nodes from DistributionZoneManager > Use data nodes from DistributionZoneManager with a causality token instead of > BaselineManager#nodes > --- > > Key: IGNITE-19506 > URL: https://issues.apache.org/jira/browse/IGNITE-19506 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Uttsel >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3 > Attachments: Causality data nodes.docx > > Time Spent: 1h > Remaining Estimate: 0h > > h3. *Motivation* > Need to use data nodes from DistributionZoneManager instead of > BaselineManager#nodes in: > # DistributionZoneRebalanceEngine#onUpdateReplicas > # TableManager#createAssignmentsSwitchRebalanceListener > We need to get data nodes consistently so we need to use revision of > configuration events and a meta storage events as causality token. Also need > to use VersionedValue to save data nodes with causality token. > Description of causality data nodes algorithm is attached. > h3. *Definition of Done* > DistributionZoneRebalanceEngine#onUpdateReplicas and > TableManager#createAssignmentsSwitchRebalanceListener use data nodes from > DistributionZoneManager -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19769) Ignite Docs: change ignite-spring-data-2.2-ext to ignite-spring-data-ext
[ https://issues.apache.org/jira/browse/IGNITE-19769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YuJue Li updated IGNITE-19769: -- Ignite Flags: (was: Docs Required,Release Notes Required) Language: Java > Ignite Docs: change ignite-spring-data-2.2-ext to ignite-spring-data-ext > > > Key: IGNITE-19769 > URL: https://issues.apache.org/jira/browse/IGNITE-19769 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.15 >Reporter: YuJue Li >Assignee: YuJue Li >Priority: Minor > Fix For: 2.16 > > > [https://ignite.apache.org/docs/latest/extensions-and-integrations/spring/spring-data] > Change artifactId from ignite-spring-data-2.2-ext to ignite-spring-data-ext -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19770) Add a mechanism to wait till a schema is available via Schema Sync at a ts
Roman Puchkovskiy created IGNITE-19770:
--
Summary: Add a mechanism to wait till a schema is available via
Schema Sync at a ts
Key: IGNITE-19770
URL: https://issues.apache.org/jira/browse/IGNITE-19770
Project: Ignite
Issue Type: Improvement
Reporter: Roman Puchkovskiy
Fix For: 3.0.0-beta2
According to IEP-98, when obtaining a schema at a timestamp T, we need to wait
till Meta-Storage SafeTime becomes >= T-DD. A mechanism for such waits needs to
be implemented.
Also, we will probably need to wait for a specific version of a table/index/etc
(or a version of a Catalog as a whole), so a way to need for it (and not for a
ts) is also needed.
Both can be implemented either as methods like
{{CompletableFuture table(String tableName, HybridTimestamp
ts)}} (for each getting method) or a single method like
{{CompletableFuture waitForTs(HybridTimestamp)}} (then usual sync methods
to be used to get the definitions).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19769) Ignite Docs: change ignite-spring-data-2.2-ext to ignite-spring-data-ext
YuJue Li created IGNITE-19769: - Summary: Ignite Docs: change ignite-spring-data-2.2-ext to ignite-spring-data-ext Key: IGNITE-19769 URL: https://issues.apache.org/jira/browse/IGNITE-19769 Project: Ignite Issue Type: Improvement Components: documentation Affects Versions: 2.15 Reporter: YuJue Li Assignee: YuJue Li Fix For: 2.16 [https://ignite.apache.org/docs/latest/extensions-and-integrations/spring/spring-data] Change artifactId from ignite-spring-data-2.2-ext to ignite-spring-data-ext -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19768) Port configured tables workaround from configuration to Catalog
[
https://issues.apache.org/jira/browse/IGNITE-19768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-19768:
---
Epic Link: IGNITE-19502
> Port configured tables workaround from configuration to Catalog
> ---
>
> Key: IGNITE-19768
> URL: https://issues.apache.org/jira/browse/IGNITE-19768
> Project: Ignite
> Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Currently, TableManager contains a workaround (for a problem of getting of
> the most recent schemas without a proper Schema Sync mechanism), it works
> like this: on each attempt to resolve a table by ID, we look into the
> configuration to make sure that the table with this ID is created and not
> dropped yet. Also, we look into the configuration on each attempt to get a
> list of all tables.
> A switch from Configuration to the Catalog is under way, so we need to switch
> this workaround from Configuration to the Catalog as well.
> {{ConfiguredTablesCache}} needs to be modified to achieve this.
> An alternative would to be implement both the switch from Configuration to
> Catalog AND introduction of the proper Schema Sync at once, but this will
> greatly complicate the matters, it seems to be better to do these changes one
> after another (first Catalog, then Schema Sync).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19768) Port configured tables workaround from configuration to Catalog
Roman Puchkovskiy created IGNITE-19768:
--
Summary: Port configured tables workaround from configuration to
Catalog
Key: IGNITE-19768
URL: https://issues.apache.org/jira/browse/IGNITE-19768
Project: Ignite
Issue Type: Improvement
Reporter: Roman Puchkovskiy
Fix For: 3.0.0-beta2
Currently, TableManager contains a workaround (for a problem of getting of the
most recent schemas without a proper Schema Sync mechanism), it works like
this: on each attempt to resolve a table by ID, we look into the configuration
to make sure that the table with this ID is created and not dropped yet. Also,
we look into the configuration on each attempt to get a list of all tables.
A switch from Configuration to the Catalog is under way, so we need to switch
this workaround from Configuration to the Catalog as well.
{{ConfiguredTablesCache}} needs to be modified to achieve this.
An alternative would to be implement both the switch from Configuration to
Catalog AND introduction of the proper Schema Sync at once, but this will
greatly complicate the matters, it seems to be better to do these changes one
after another (first Catalog, then Schema Sync).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-19654) Sql. Rework planner Timeout and tests.
[ https://issues.apache.org/jira/browse/IGNITE-19654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich reassigned IGNITE-19654: -- Assignee: Yury Gerzhedovich > Sql. Rework planner Timeout and tests. > -- > > Key: IGNITE-19654 > URL: https://issues.apache.org/jira/browse/IGNITE-19654 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Evgeny Stanilovsky >Assignee: Yury Gerzhedovich >Priority: Major > Labels: calcite3-required, ignite-3 > > BaseQueryContext#plannerTimeout is not used for now, probably rejecting for > long query planning is broken too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19209) Implement installing table schema updates
[ https://issues.apache.org/jira/browse/IGNITE-19209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy reassigned IGNITE-19209: -- Assignee: Roman Puchkovskiy > Implement installing table schema updates > - > > Key: IGNITE-19209 > URL: https://issues.apache.org/jira/browse/IGNITE-19209 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > At the moment there is a CatalogService that manages SchemaDescriptors > (database schemas, not table schemas) and TableDescriptors. CREATE TABLE is > being handled by the CatalogService, however it seems like it doesn't > actually write the schema to the metastorage. > I believe that two things must be done in the scope of this ticket: > 1. Actually write new schema to the metastorage. > 2. Use node's HLC + DD (Delay Duration) which is described in the > https://cwiki.apache.org/confluence/display/IGNITE/IEP-98%3A+Schema+Synchronization > as the new schema's activation time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
