[jira] [Commented] (IGNITE-21982) Extend test coverage for SQL T021(BINARY and VARBINARY data types)
[ https://issues.apache.org/jira/browse/IGNITE-21982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849159#comment-17849159 ] Evgeny Stanilovsky commented on IGNITE-21982: - [~amashenkov] can you make a review plz ? > Extend test coverage for SQL T021(BINARY and VARBINARY data types) > -- > > Key: IGNITE-21982 > URL: https://issues.apache.org/jira/browse/IGNITE-21982 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Iurii Gerzhedovich >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Test coverage for SQL T021(BINARY and VARBINARY data types) is poor. > Let's increase the test coverage. > > ref - test/sql/types/blob/test_blob_cast.test > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22320) Sql. LITERAL_AGG erroneously assembled after deserialization
Evgeny Stanilovsky created IGNITE-22320: --- Summary: Sql. LITERAL_AGG erroneously assembled after deserialization Key: IGNITE-22320 URL: https://issues.apache.org/jira/browse/IGNITE-22320 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 3.0.0-beta1 Reporter: Evgeny Stanilovsky This is just a projection of corresponding calcite issue[1], this causes some hacks in code mentioned under this issue. [1] https://issues.apache.org/jira/browse/CALCITE-5969 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21225) Redundant lambda object allocation in ClockPageReplacementFlags#setFlag
[
https://issues.apache.org/jira/browse/IGNITE-21225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov resolved IGNITE-21225.
Fix Version/s: 2.17
Release Note: Fixed redundant lambda object allocation in
ClockPageReplacementFlags#
Resolution: Fixed
[~timonin.maksim], thanks for the review! Merged to master.
> Redundant lambda object allocation in ClockPageReplacementFlags#setFlag
> ---
>
> Key: IGNITE-21225
> URL: https://issues.apache.org/jira/browse/IGNITE-21225
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Every time we call {{ClockPageReplacementFlags#setFlag/clearFlag}} methods
> the new lambda object is created, since lambda is accessing the variable in
> enclosing scope. \{{ClockPageReplacementFlags#setFlag}} method called every
> time when page is modified, so, it's a relatevily hot method and we should
> avoid new object allocation here.
> Here is the test to show redundant allocations:
>
> {code:java}
> /** */
> @Test
> public void testAllocation() {
> clockFlags = new ClockPageReplacementFlags(MAX_PAGES_CNT,
> region.address());
> int cnt = 1_000_000;
> ThreadMXBean bean = (ThreadMXBean)ManagementFactory.getThreadMXBean();
> // Warmup.
> clockFlags.setFlag(0);
> long allocated0 =
> bean.getThreadAllocatedBytes(Thread.currentThread().getId());
> for (int i = 0; i < cnt; i++)
> clockFlags.setFlag(i % MAX_PAGES_CNT);
> long allocated1 =
> bean.getThreadAllocatedBytes(Thread.currentThread().getId());
> assertTrue("Too many bytes allocated: " + (allocated1 - allocated0),
> allocated1 - allocated0 < cnt);
> } {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21823) fix log message pageSize
[ https://issues.apache.org/jira/browse/IGNITE-21823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-21823: --- Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > fix log message pageSize > > > Key: IGNITE-21823 > URL: https://issues.apache.org/jira/browse/IGNITE-21823 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Andrei Nadyktov >Priority: Minor > Labels: ise, newbie > Fix For: 2.17 > > Time Spent: 40m > Remaining Estimate: 0h > > If you do not indicate in the configuration, the size of pageSize, then in > the log we see the message that pageSize = 0 that is not true -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22319) Node crashes if a snapshot restore cancelled due to network issues
[
https://issues.apache.org/jira/browse/IGNITE-22319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Amelchev updated IGNITE-22319:
-
Affects Version/s: 2.16
2.15
> Node crashes if a snapshot restore cancelled due to network issues
> ---
>
> Key: IGNITE-22319
> URL: https://issues.apache.org/jira/browse/IGNITE-22319
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.15, 2.16
>Reporter: Nikita Amelchev
>Assignee: Nikita Amelchev
>Priority: Major
> Fix For: 2.17
>
>
> Node crashes if a snapshot restore (not same topology) cancelled due to
> network issues.
> There are several possible reasons:
> 1. Assertion error (node left or socket timeout):
> {noformat}
> [2024-05-21T18:39:22,212][ERROR][disco-event-worker-#1479%snapshot.IgniteSnapshotRestoreFromRemoteTest2%][GridEventStorageManager]
> Unexpected exception in listener notification for event: DiscoveryEvent
> [evtNode=TcpDiscoveryNode [id=1b573ddc-b0eb-4909-978b-9d418c10,
> consistentId=snapshot.IgniteSnapshotRestoreFromRemoteTest0, addrs=ArrayList
> [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1,
> intOrder=1, loc=false, ver=2.17.0#20240512-sha1:27cef45b, isClient=false],
> topVer=4, msgTemplate=null,
> span=o.a.i.i.processors.tracing.NoopSpan@48b53ef5, nodeId8=9992b67a, msg=Node
> left, type=NODE_LEFT, tstamp=1716305962203]
> java.lang.AssertionError: null
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SequentialRemoteSnapshotManager.onException(IgniteSnapshotManager.java:4022)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.interruptReceiver(GridIoManager.java:2799)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$6.onEvent(GridIoManager.java:972)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager$LocalListenerWrapper.onEvent(GridEventStorageManager.java:1403)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:898)
> [classes/:?]
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:883)
> [classes/:?]
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record0(GridEventStorageManager.java:354)
> [classes/:?]
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record(GridEventStorageManager.java:317)
> [classes/:?]
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.recordEvent(GridDiscoveryManager.java:3036)
> [classes/:?]
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body0(GridDiscoveryManager.java:3223)
> [classes/:?]
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body(GridDiscoveryManager.java:3056)
> [classes/:?]
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> [classes/:?]
> at java.base/java.lang.Thread.run(Thread.java:829) [?:?]
> {noformat}
> 2. Deadlock of system threads.
> {noformat}
> # DEADLOCKED Thread
> [name="pub-#956%snapshot.IgniteSnapshotRestoreFromRemoteTest2%", id=1056,
> state=BLOCKED, blockCnt=10, waitCnt=0]
> Lock
> [object=o.a.i.i.processors.cache.persistence.snapshot.IgniteSnapshotManager$RemoteSnapshotFilesRecevier@4a114695,
>
> ownerName=disco-event-worker-#853%snapshot.IgniteSnapshotRestoreFromRemoteTest2%,
> ownerId=952]
> at
> app//o.a.i.i.processors.cache.persistence.snapshot.IgniteSnapshotManager$RemoteSnapshotFilesRecevier.init(IgniteSnapshotManager.java:3698)
> at
> app//o.a.i.i.processors.cache.persistence.snapshot.IgniteSnapshotManager$SequentialRemoteSnapshotManager.submit(IgniteSnapshotManager.java:3836)
> - locked
> o.a.i.i.processors.cache.persistence.snapshot.IgniteSnapshotManager$SequentialRemoteSnapshotManager@1da11e24
> at
> app//o.a.i.i.processors.cache.persistence.snapshot.IgniteSnapshotManager$SequentialRemoteSnapshotManager.scheduleNext(IgniteSnapshotManager.java:3849)
> - locked
> o.a.i.i.processors.cache.persistence.snapshot.IgniteSnapshotManager$SequentialRemoteSnapshotManager@1da11e24
> at
> app//o.a.i.i.processors.cache.persistence.snapshot.IgniteSnapshotManager$SequentialRemoteSnapshotManager$$Lambda$1787/0x0008009c1c40.run(Unknown
> Source)
> at
> app//o.a.i.i.util.future.GridFutureAdapter.lambda$listen$8a14a590$1(GridFutureAdapter.java:363)
> at
> app//o.a.i.i.util.future.GridFutureAdapter$$Lambda$1215/0x0008007ba040.apply(Unknown
>
[jira] [Updated] (IGNITE-22319) Node crashes if a snapshot restore cancelled due to network issues
[
https://issues.apache.org/jira/browse/IGNITE-22319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Amelchev updated IGNITE-22319:
-
Fix Version/s: 2.17
> Node crashes if a snapshot restore cancelled due to network issues
> ---
>
> Key: IGNITE-22319
> URL: https://issues.apache.org/jira/browse/IGNITE-22319
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikita Amelchev
>Assignee: Nikita Amelchev
>Priority: Major
> Fix For: 2.17
>
>
> Node crashes if a snapshot restore (not same topology) cancelled due to
> network issues.
> There are several possible reasons:
> 1. Assertion error (node left or socket timeout):
> {noformat}
> [2024-05-21T18:39:22,212][ERROR][disco-event-worker-#1479%snapshot.IgniteSnapshotRestoreFromRemoteTest2%][GridEventStorageManager]
> Unexpected exception in listener notification for event: DiscoveryEvent
> [evtNode=TcpDiscoveryNode [id=1b573ddc-b0eb-4909-978b-9d418c10,
> consistentId=snapshot.IgniteSnapshotRestoreFromRemoteTest0, addrs=ArrayList
> [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1,
> intOrder=1, loc=false, ver=2.17.0#20240512-sha1:27cef45b, isClient=false],
> topVer=4, msgTemplate=null,
> span=o.a.i.i.processors.tracing.NoopSpan@48b53ef5, nodeId8=9992b67a, msg=Node
> left, type=NODE_LEFT, tstamp=1716305962203]
> java.lang.AssertionError: null
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SequentialRemoteSnapshotManager.onException(IgniteSnapshotManager.java:4022)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.interruptReceiver(GridIoManager.java:2799)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$6.onEvent(GridIoManager.java:972)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager$LocalListenerWrapper.onEvent(GridEventStorageManager.java:1403)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:898)
> [classes/:?]
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:883)
> [classes/:?]
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record0(GridEventStorageManager.java:354)
> [classes/:?]
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record(GridEventStorageManager.java:317)
> [classes/:?]
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.recordEvent(GridDiscoveryManager.java:3036)
> [classes/:?]
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body0(GridDiscoveryManager.java:3223)
> [classes/:?]
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body(GridDiscoveryManager.java:3056)
> [classes/:?]
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> [classes/:?]
> at java.base/java.lang.Thread.run(Thread.java:829) [?:?]
> {noformat}
> 2. Deadlock of system threads.
> {noformat}
> # DEADLOCKED Thread
> [name="pub-#956%snapshot.IgniteSnapshotRestoreFromRemoteTest2%", id=1056,
> state=BLOCKED, blockCnt=10, waitCnt=0]
> Lock
> [object=o.a.i.i.processors.cache.persistence.snapshot.IgniteSnapshotManager$RemoteSnapshotFilesRecevier@4a114695,
>
> ownerName=disco-event-worker-#853%snapshot.IgniteSnapshotRestoreFromRemoteTest2%,
> ownerId=952]
> at
> app//o.a.i.i.processors.cache.persistence.snapshot.IgniteSnapshotManager$RemoteSnapshotFilesRecevier.init(IgniteSnapshotManager.java:3698)
> at
> app//o.a.i.i.processors.cache.persistence.snapshot.IgniteSnapshotManager$SequentialRemoteSnapshotManager.submit(IgniteSnapshotManager.java:3836)
> - locked
> o.a.i.i.processors.cache.persistence.snapshot.IgniteSnapshotManager$SequentialRemoteSnapshotManager@1da11e24
> at
> app//o.a.i.i.processors.cache.persistence.snapshot.IgniteSnapshotManager$SequentialRemoteSnapshotManager.scheduleNext(IgniteSnapshotManager.java:3849)
> - locked
> o.a.i.i.processors.cache.persistence.snapshot.IgniteSnapshotManager$SequentialRemoteSnapshotManager@1da11e24
> at
> app//o.a.i.i.processors.cache.persistence.snapshot.IgniteSnapshotManager$SequentialRemoteSnapshotManager$$Lambda$1787/0x0008009c1c40.run(Unknown
> Source)
> at
> app//o.a.i.i.util.future.GridFutureAdapter.lambda$listen$8a14a590$1(GridFutureAdapter.java:363)
> at
> app//o.a.i.i.util.future.GridFutureAdapter$$Lambda$1215/0x0008007ba040.apply(Unknown
> Source)
> at
>
[jira] [Created] (IGNITE-22319) Node crashes if a snapshot restore cancelled due to network issues
Nikita Amelchev created IGNITE-22319:
Summary: Node crashes if a snapshot restore cancelled due to
network issues
Key: IGNITE-22319
URL: https://issues.apache.org/jira/browse/IGNITE-22319
Project: Ignite
Issue Type: Bug
Reporter: Nikita Amelchev
Assignee: Nikita Amelchev
Node crashes if a snapshot restore (not same topology) cancelled due to network
issues.
There are several possible reasons:
1. Assertion error (node left or socket timeout):
{noformat}
[2024-05-21T18:39:22,212][ERROR][disco-event-worker-#1479%snapshot.IgniteSnapshotRestoreFromRemoteTest2%][GridEventStorageManager]
Unexpected exception in listener notification for event: DiscoveryEvent
[evtNode=TcpDiscoveryNode [id=1b573ddc-b0eb-4909-978b-9d418c10,
consistentId=snapshot.IgniteSnapshotRestoreFromRemoteTest0, addrs=ArrayList
[127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1,
intOrder=1, loc=false, ver=2.17.0#20240512-sha1:27cef45b, isClient=false],
topVer=4, msgTemplate=null, span=o.a.i.i.processors.tracing.NoopSpan@48b53ef5,
nodeId8=9992b67a, msg=Node left, type=NODE_LEFT, tstamp=1716305962203]
java.lang.AssertionError: null
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SequentialRemoteSnapshotManager.onException(IgniteSnapshotManager.java:4022)
~[classes/:?]
at
org.apache.ignite.internal.managers.communication.GridIoManager.interruptReceiver(GridIoManager.java:2799)
~[classes/:?]
at
org.apache.ignite.internal.managers.communication.GridIoManager$6.onEvent(GridIoManager.java:972)
~[classes/:?]
at
org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager$LocalListenerWrapper.onEvent(GridEventStorageManager.java:1403)
~[classes/:?]
at
org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:898)
[classes/:?]
at
org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:883)
[classes/:?]
at
org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record0(GridEventStorageManager.java:354)
[classes/:?]
at
org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record(GridEventStorageManager.java:317)
[classes/:?]
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.recordEvent(GridDiscoveryManager.java:3036)
[classes/:?]
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body0(GridDiscoveryManager.java:3223)
[classes/:?]
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body(GridDiscoveryManager.java:3056)
[classes/:?]
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
[classes/:?]
at java.base/java.lang.Thread.run(Thread.java:829) [?:?]
{noformat}
2. Deadlock of system threads.
{noformat}
# DEADLOCKED Thread
[name="pub-#956%snapshot.IgniteSnapshotRestoreFromRemoteTest2%", id=1056,
state=BLOCKED, blockCnt=10, waitCnt=0]
Lock
[object=o.a.i.i.processors.cache.persistence.snapshot.IgniteSnapshotManager$RemoteSnapshotFilesRecevier@4a114695,
ownerName=disco-event-worker-#853%snapshot.IgniteSnapshotRestoreFromRemoteTest2%,
ownerId=952]
at
app//o.a.i.i.processors.cache.persistence.snapshot.IgniteSnapshotManager$RemoteSnapshotFilesRecevier.init(IgniteSnapshotManager.java:3698)
at
app//o.a.i.i.processors.cache.persistence.snapshot.IgniteSnapshotManager$SequentialRemoteSnapshotManager.submit(IgniteSnapshotManager.java:3836)
- locked
o.a.i.i.processors.cache.persistence.snapshot.IgniteSnapshotManager$SequentialRemoteSnapshotManager@1da11e24
at
app//o.a.i.i.processors.cache.persistence.snapshot.IgniteSnapshotManager$SequentialRemoteSnapshotManager.scheduleNext(IgniteSnapshotManager.java:3849)
- locked
o.a.i.i.processors.cache.persistence.snapshot.IgniteSnapshotManager$SequentialRemoteSnapshotManager@1da11e24
at
app//o.a.i.i.processors.cache.persistence.snapshot.IgniteSnapshotManager$SequentialRemoteSnapshotManager$$Lambda$1787/0x0008009c1c40.run(Unknown
Source)
at
app//o.a.i.i.util.future.GridFutureAdapter.lambda$listen$8a14a590$1(GridFutureAdapter.java:363)
at
app//o.a.i.i.util.future.GridFutureAdapter$$Lambda$1215/0x0008007ba040.apply(Unknown
Source)
at
app//o.a.i.i.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:474)
at
app//o.a.i.i.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:350)
at
app//o.a.i.i.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:338)
at
app//o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:586)
at
[jira] [Commented] (IGNITE-20059) SpringBoot/Data extensions all use super-old, unsupported versions
[ https://issues.apache.org/jira/browse/IGNITE-20059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849040#comment-17849040 ] Stephen Darlington commented on IGNITE-20059: - [~anovikov] I don't think that's true. IGNITE-22077 updates the Spring dependencies, whereas this PR updates the SpringBoot and SpringData dependencies. > SpringBoot/Data extensions all use super-old, unsupported versions > -- > > Key: IGNITE-20059 > URL: https://issues.apache.org/jira/browse/IGNITE-20059 > Project: Ignite > Issue Type: Improvement > Components: extensions, spring, springdata >Reporter: Stephen Darlington >Assignee: Stephen Darlington >Priority: Major > > All our Spring dependencies are very out of date. It's currently pointing to > version 2.2.13, which hasn't been supported since late 2020. This is an > obstacle to Ignite being added to the [Spring > Initializr|https://github.com/spring-io/start.spring.io/issues/960]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22292) Moving LogSyncer from Loza and RaftServer and pass it to usages as IgniteComponent
[
https://issues.apache.org/jira/browse/IGNITE-22292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-22292:
-
Description:
*Description*
The main goal is to remove {{LogSyncer}} from {{Loza}} and especially method
{{{}Loza#getLogSyncer{}}}.
*Motivation*
# There is an intention to hide all raft-specific entities behind replication
layer and log syncer is an entity that sticking out. Besides it's only needs
for engines and may be passed though {{IgniteImpl}} as an ignite component.
# All current implementations except {{DefaultLogStorageFactory}} are not
implements properly sync method at all that looks like the reason for interface
segregation between {{LogSyncer}} and {{LogStorageFactory.}}
*Definition of done*
# There no more {{Loza#getLogSyncer}} method and its' calls.
# {{LogSyncer}} and {{LogStorageFactory}} interfaces are separated.
# {{LogSyncer}} creates and injects into engines as {{IgniteComponent}} in
{{{}IgniteImpl{}}}.
was:
*Description*
The main goal is to remove {{LogSyncer}} from {{Loza}} and especially method
{{{}Loza#getLogSyncer{}}}.
*Motivation*
# There is an intention to hide all raft-specific entities behind replication
layer and log syncer is an entity that sticking out. Besides it's only needs
for engines and may be passed though {{IgniteImpl}} as an ignite component.
# All current implementations except {{DefaultLogStorageFactory}} are not
implements properly sync method at all that looks like the reason for interface
segregation between {{LogSyncer}} and {{LogStorageFactory.}}
*Definition of done*
# There no more {{Loza#getLogSyncer}} method and its' calls.
# {{LogSyncer}} and {{LogStorageFactory}} interfaces are separated.{{{}
{}}}
# {{LogSyncer}} creates and injects into engines as {{IgniteComponent}} in
{{{}IgniteIml{}}}.
> Moving LogSyncer from Loza and RaftServer and pass it to usages as
> IgniteComponent
> --
>
> Key: IGNITE-22292
> URL: https://issues.apache.org/jira/browse/IGNITE-22292
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Efremov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
>
> *Description*
> The main goal is to remove {{LogSyncer}} from {{Loza}} and especially method
> {{{}Loza#getLogSyncer{}}}.
> *Motivation*
> # There is an intention to hide all raft-specific entities behind
> replication layer and log syncer is an entity that sticking out. Besides it's
> only needs for engines and may be passed though {{IgniteImpl}} as an ignite
> component.
> # All current implementations except {{DefaultLogStorageFactory}} are not
> implements properly sync method at all that looks like the reason for
> interface segregation between {{LogSyncer}} and {{LogStorageFactory.}}
> *Definition of done*
> # There no more {{Loza#getLogSyncer}} method and its' calls.
> # {{LogSyncer}} and {{LogStorageFactory}} interfaces are separated.
> # {{LogSyncer}} creates and injects into engines as {{IgniteComponent}} in
> {{{}IgniteImpl{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22315) Make raft-client starting only once and only with raft-client and replica together
[
https://issues.apache.org/jira/browse/IGNITE-22315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-22315:
-
Description:
*Description*
The goal is to make sure that when partition starting on an ignite-node, if the
node in assignments, then there should be only ones raft-node, raft-client and
replica and no any started entities otherwise.
*Motivation*
Now on the one hand in {{TableManager}} there is a path when raft-node and
replica didn't start, but raft-client is:
In {{TableManager#startPartitionAndStartClient}} there is a place where
{{startGroupFut}} returns {{{}false{}}}:\{{ localMemberAssignment}} is {{null}}
or {{PartitionReplicatorNodeRecovery#shouldStartGroup}} returns {{{}false{}}}.
Then, raft-node and replica will not be started, but regardless of
{{startGroupFut}} result raft client will be started:
{code:java}
startGroupFut
.thenComposeAsync(v -> inBusyLock(busyLock, () -> {
TableRaftService tableRaftService =
table.internalTable().tableRaftService();
try {
// Return existing service if it's already started.
return completedFuture(
(TopologyAwareRaftGroupService)
tableRaftService.partitionRaftGroupService(replicaGrpId.partitionId())
);
} catch (IgniteInternalException e) {
// We use "IgniteInternalException" in accordance with the
javadoc of "partitionRaftGroupService" method.
try {
// TODO IGNITE-19614 This procedure takes 10 seconds if
there's no majority online.
return raftMgr
.startRaftGroupService(replicaGrpId,
newConfiguration, raftGroupServiceFactory, raftCommandsMarshaller);
} catch (NodeStoppingException ex) {
return failedFuture(ex);
}
}
}), ioExecutor)
.thenAcceptAsync(updatedRaftGroupService -> inBusyLock(busyLock, () -> {
((InternalTableImpl) internalTbl).tableRaftService()
.updateInternalTableRaftGroupService(partId,
updatedRaftGroupService);
boolean startedRaftNode = startGroupFut.join();
if (localMemberAssignment == null || !startedRaftNode ||
replicaMgr.isReplicaStarted(replicaGrpId)) {
return;
} {code}
the code shows that {{v}} argument ({{{}startGroupFut{}}}'s result) in the
lambda doesn't affect on raft-client's starting, and also the client is put
into {{TableRaftService}} then regardless of replica's starting.
On the other hand, there is a place that rely on raft-client creation on every
node with table's ID in {{TableManager#tables}} map: inside
{{TableManager#handleChangePendingAssignmentEvent}} there are two calls:
# the same name method
{{{}TableManager#handleChangePendingAssignmentEvent{}}}}}{}}}
# {{TableManager#changePeersOnRebalance}}
Both are asking for internal table's
{{{}tableRaftService().partitionRaftGroupService(partId){}}}, but there no any
checks about is the local node is suitable for raft-entities and replica
starting or they are already started.
Then, when we would try to fix instant raft-client starting it will lead to
instant {{IgniteInternalException}} with _"No such partition P in table T"_
from {{{}TableRaftService#{}}}{{{}partitionRaftGroupService{}}}. This is a
problem that should be solved.
{color:#383838}*Definition of done*{color}
# {color:#383838}Raft-client must be started only together with raft-node and
replica or shouldn't be started otherwise.{color}
# {color:#383838}{{TableRaftService}} shouldn't be requested for raft-client
if the local node isn't in a raft group.{color}
# {color:#383838}Some tests may rely on described behavior, then failed tests
should be investigated and, probably fixed.{color}
# {color:#383838}New tests that check single starting of raft-node,
raft-client and replica together are required{color}
{color:#0f54d6} {color}
{color:#383838} {color}
{color:#00855f} {color}
was:
*Description*
The goal is to make sure that when partition starting on an ignite-node, if the
node in assignments, then there should be only ones raft-node, raft-client and
replica and no any started entities otherwise.
*Motivation*
Now on the one hand in {{TableManager}} there is a path when raft-node and
replica didn't start, but raft-client is:
In {{TableManager#startPartitionAndStartClient}} there is a place where
{{startGroupFut}} returns {{{}false{}}}:\{{ localMemberAssignment}} is {{null}}
or {{PartitionReplicatorNodeRecovery#shouldStartGroup}} returns {{{}false{}}}.
Then, raft-node and replica will not be started, but regardless of
{{startGroupFut}} result raft client will be started:
{code:java}
startGroupFut
.thenComposeAsync(v -> inBusyLock(busyLock, () -> {
TableRaftService
[jira] [Updated] (IGNITE-22315) Make raft-client starting only once and only with raft-client and replica together
[
https://issues.apache.org/jira/browse/IGNITE-22315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-22315:
-
Description:
*Description*
The goal is to make sure that when partition starting on an ignite-node, if the
node in assignments, then there should be only ones raft-node, raft-client and
replica and no any started entities otherwise.
*Motivation*
Now on the one hand in {{TableManager}} there is a path when raft-node and
replica didn't start, but raft-client is:
In {{TableManager#startPartitionAndStartClient}} there is a place where
{{startGroupFut}} returns {{{}false{}}}:\{{ localMemberAssignment}} is {{null}}
or {{PartitionReplicatorNodeRecovery#shouldStartGroup}} returns {{{}false{}}}.
Then, raft-node and replica will not be started, but regardless of
{{startGroupFut}} result raft client will be started:
{code:java}
startGroupFut
.thenComposeAsync(v -> inBusyLock(busyLock, () -> {
TableRaftService tableRaftService =
table.internalTable().tableRaftService();
try {
// Return existing service if it's already started.
return completedFuture(
(TopologyAwareRaftGroupService)
tableRaftService.partitionRaftGroupService(replicaGrpId.partitionId())
);
} catch (IgniteInternalException e) {
// We use "IgniteInternalException" in accordance with the
javadoc of "partitionRaftGroupService" method.
try {
// TODO IGNITE-19614 This procedure takes 10 seconds if
there's no majority online.
return raftMgr
.startRaftGroupService(replicaGrpId,
newConfiguration, raftGroupServiceFactory, raftCommandsMarshaller);
} catch (NodeStoppingException ex) {
return failedFuture(ex);
}
}
}), ioExecutor)
.thenAcceptAsync(updatedRaftGroupService -> inBusyLock(busyLock, () -> {
((InternalTableImpl) internalTbl).tableRaftService()
.updateInternalTableRaftGroupService(partId,
updatedRaftGroupService);
boolean startedRaftNode = startGroupFut.join();
if (localMemberAssignment == null || !startedRaftNode ||
replicaMgr.isReplicaStarted(replicaGrpId)) {
return;
} {code}
the code shows that {{v}} argument ({{{}startGroupFut{}}}'s result) in the
lambda doesn't affect on raft-client's starting, and also the client is put
into {{TableRaftService}} then regardless of replica's starting.
On the other hand, there is a place that rely on raft-client creation on every
node with table's ID in {{TableManager#tables}} map: inside
{{TableManager#handleChangePendingAssignmentEvent}} there are two calls:
# the same name method
{{{}TableManager#handleChangePendingAssignmentEvent{}}}}}{}}}
# {{TableManager#changePeersOnRebalance}}
Both are asking for internal table's
{{{}tableRaftService().partitionRaftGroupService(partId){}}}, but there no any
checks about is the local node is suitable for raft-entities and replica
starting or they are already started.
Then, when we would try to fix instant raft-client starting it will lead to
instant {{IgniteInternalException}} with _"No such partition P in table T"_
from {{{}TableRaftService#{}}}{{{}partitionRaftGroupService{}}}. This is a
problem that should be solved.
{color:#383838}*Definition of done*{color}
{color:#383838}1. Raft-client must be started only together with raft-node and
replica or shouldn't be started otherwise.{color}
{color:#383838}2. {{TableRaftService}} shouldn't be requested for raft-client
if the local node isn't in a raft group.{color}
{color:#383838}3. Some tests may rely on described behavior, then failed tests
should be investigated and, probably fixed.{color}
{color:#383838}4. New tests that check single starting of raft-node,
raft-client and replica together are required{color}
{color:#0f54d6} {color}
{color:#383838} {color}
{color:#00855f} {color}
was:
*Description*
The goal is to make sure that when partition starting on an ignite-node, if the
node in assignments, then there should be only ones raft-node, raft-client and
replica and no any started entities otherwise.
*Motivation*
Now on the one hand in {{TableManager}} there is a path when raft-node and
replica didn't start, but raft-client is:
In {{TableManager#startPartitionAndStartClient}} there is a place where
{{startGroupFut}} returns {{{}false{}}}:{{ localMemberAssignment}} is {{null}}
or {{PartitionReplicatorNodeRecovery#shouldStartGroup}} returns {{{}false{}}}.
Then, raft-node and replica will not be started, but regardless of
{{startGroupFut}} result raft client will be started:
{code:java}
startGroupFut
.thenComposeAsync(v -> inBusyLock(busyLock, () -> {
TableRaftService
[jira] [Commented] (IGNITE-19613) Add log4j-slf4j-impl dependency into ignite-cdc-ext
[ https://issues.apache.org/jira/browse/IGNITE-19613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848965#comment-17848965 ] Andrei Nadyktov commented on IGNITE-19613: -- [~brat_kuzma], can I assign this ticket to me? > Add log4j-slf4j-impl dependency into ignite-cdc-ext > --- > > Key: IGNITE-19613 > URL: https://issues.apache.org/jira/browse/IGNITE-19613 > Project: Ignite > Issue Type: Task > Components: extensions >Reporter: Ilya Shishkov >Assignee: Denis Kuznetsov >Priority: Minor > Labels: IEP-59, ise > > log4j-slf4j-impl dependency is necessary in order to log messages of Kafka > clients, currently such messages are absent in log. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22318) Data Streamer: Optimize receiver task invocation
[ https://issues.apache.org/jira/browse/IGNITE-22318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22318: Description: *ClientStreamerWithReceiverBatchSendRequest.java* uses a Compute task to execute the receiver. This task is instantiated every time, which might be expensive. See if we can cache it somehow. > Data Streamer: Optimize receiver task invocation > > > Key: IGNITE-22318 > URL: https://issues.apache.org/jira/browse/IGNITE-22318 > Project: Ignite > Issue Type: Improvement > Components: streaming >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > > *ClientStreamerWithReceiverBatchSendRequest.java* uses a Compute task to > execute the receiver. This task is instantiated every time, which might be > expensive. See if we can cache it somehow. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22318) Data Streamer: Optimize receiver task invocation
[ https://issues.apache.org/jira/browse/IGNITE-22318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22318: Description: *ClientStreamerWithReceiverBatchSendRequest* uses a Compute task to execute the receiver. This task is instantiated every time, which might be expensive. See if we can cache it somehow. (was: *ClientStreamerWithReceiverBatchSendRequest.java* uses a Compute task to execute the receiver. This task is instantiated every time, which might be expensive. See if we can cache it somehow.) > Data Streamer: Optimize receiver task invocation > > > Key: IGNITE-22318 > URL: https://issues.apache.org/jira/browse/IGNITE-22318 > Project: Ignite > Issue Type: Improvement > Components: streaming >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > > *ClientStreamerWithReceiverBatchSendRequest* uses a Compute task to execute > the receiver. This task is instantiated every time, which might be expensive. > See if we can cache it somehow. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22318) Data Streamer: Optimize receiver task invocation
Pavel Tupitsyn created IGNITE-22318: --- Summary: Data Streamer: Optimize receiver task invocation Key: IGNITE-22318 URL: https://issues.apache.org/jira/browse/IGNITE-22318 Project: Ignite Issue Type: Improvement Components: streaming Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22312) Sql. Type parameters such precision / scale / length are not properly checked.
[
https://issues.apache.org/jira/browse/IGNITE-22312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22312:
--
Description:
1. SqlValidator accepts values for precision / scale that lay beyond max
precision / scale values defined by IgniteTypeSystem:
{noformat}
SELECT '12:34:54'::TIME(1000)
SELECT '111'::DECIMAL(2147483647)
{noformat}
2. Error messages produced by Catalog and SqlValidator are inconsistent:
{noformat}
ALTER TABLE t ADD COLUMN valint3 varchar(0)
Error: Length for column 'VALINT3' of type 'STRING' must be at least 1
SELECT 1::VARCHAR(0)
Error: Length for type 'VARCHAR' must be at least 1
CREATE TABLE tdd(id VARCHAR DEFAULT RAND_UUID, VAL INT, PRIMARY KEY (ID) )
Error: Functional default type mismatch: [col=ID, functionName=RAND_UUID,
expectedType=UUID, actualType=STRING]
{noformat}
was:
1. SqlValidator accepts values for precision / scale that lay beyond max
precision / scale values defined by IgniteTypeSystem:
{noformat}
SELECT '12:34:54'::TIME(1000)
SELECT '111'::DECIMAL(2147483647)
{noformat}
2. Error messages produced by Catalog and SqlValidator are inconsistent:
{noformat}
ALTER TABLE t ADD COLUMN valint3 varchar(0)
Error: Length for column 'VALINT3' of type 'STRING' must be at least 1
SELECT 1::VARCHAR(0)
Error: Length for type 'VARCHAR' must be at least 1
{noformat}
> Sql. Type parameters such precision / scale / length are not properly checked.
> --
>
> Key: IGNITE-22312
> URL: https://issues.apache.org/jira/browse/IGNITE-22312
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
>
> 1. SqlValidator accepts values for precision / scale that lay beyond max
> precision / scale values defined by IgniteTypeSystem:
> {noformat}
> SELECT '12:34:54'::TIME(1000)
> SELECT '111'::DECIMAL(2147483647)
> {noformat}
> 2. Error messages produced by Catalog and SqlValidator are inconsistent:
> {noformat}
> ALTER TABLE t ADD COLUMN valint3 varchar(0)
> Error: Length for column 'VALINT3' of type 'STRING' must be at least 1
> SELECT 1::VARCHAR(0)
> Error: Length for type 'VARCHAR' must be at least 1
> CREATE TABLE tdd(id VARCHAR DEFAULT RAND_UUID, VAL INT, PRIMARY KEY (ID) )
> Error: Functional default type mismatch: [col=ID, functionName=RAND_UUID,
> expectedType=UUID, actualType=STRING]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-19544) Thin 3.0: Data Streamer with Receiver
[ https://issues.apache.org/jira/browse/IGNITE-19544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848949#comment-17848949 ] Igor Sapego commented on IGNITE-19544: -- Left a comment. Overall looks good. > Thin 3.0: Data Streamer with Receiver > - > > Key: IGNITE-19544 > URL: https://issues.apache.org/jira/browse/IGNITE-19544 > Project: Ignite > Issue Type: Task > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-102, iep-121, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 40m > Remaining Estimate: 0h > > Implement data streamer with receiver in Java client - see > [IEP-121|https://cwiki.apache.org/confluence/display/IGNITE/IEP-121%3A+Data+Streamer+with+Receiver] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22314) Sql. Incorrect result while using ALL operator.
[
https://issues.apache.org/jira/browse/IGNITE-22314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848938#comment-17848938
]
Evgeny Stanilovsky commented on IGNITE-22314:
-
also fill https://issues.apache.org/jira/browse/CALCITE-6418
> Sql. Incorrect result while using ALL operator.
> ---
>
> Key: IGNITE-22314
> URL: https://issues.apache.org/jira/browse/IGNITE-22314
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> Query:
> {noformat}
> CREATE TABLE integers(i INTEGER);
> INSERT INTO integers VALUES (1), (2), (3), (NULL);
> SELECT i=ALL(SELECT i FROM (values(null), (1)) integers(i) WHERE i=i1.i OR i
> IS NULL) FROM integers i1 ORDER BY i;
> the same for:
> SELECT i=ALL(SELECT i FROM integers WHERE i=i1.i OR i IS NULL) FROM integers
> i1 ORDER BY i;{noformat}
> returns incorrect result, need to be four NULL`s but four 'true' will return.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22164) Sql. Merge throws exception if columns defined in different from table definition order.
[
https://issues.apache.org/jira/browse/IGNITE-22164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22164:
--
Fix Version/s: 3.0.0-beta2
> Sql. Merge throws exception if columns defined in different from table
> definition order.
>
>
> Key: IGNITE-22164
> URL: https://issues.apache.org/jira/browse/IGNITE-22164
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Reproducer:
> {noformat}
> sql("create table limitedChar (pk int primary key, f1 CHAR(2), f2
> CHAR(2))");
> sql("create table test1 (pk int primary key, f1 CHAR(2), f2
> CHAR(2))");
> String mergeSql2 = "MERGE INTO limitedChar dst USING test1 src ON
> dst.pk = src.pk "
> + "WHEN MATCHED THEN UPDATE SET f1 = '12' "
> + "WHEN NOT MATCHED THEN INSERT (pk, f2, f1) VALUES (src.pk,
> src.f2, src.f1)";
> sql(mergeSql2);
> {noformat}
> Caused by: java.lang.ClassCastException: class
> org.apache.ignite.internal.sql.engine.rel.logical.IgniteLogicalTableScan
> cannot be cast to class org.apache.calcite.rel.logical.LogicalProject
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22317) [Extensions] Release Ignite Spring Extensions
[ https://issues.apache.org/jira/browse/IGNITE-22317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov reassigned IGNITE-22317: --- Assignee: Andrey Novikov > [Extensions] Release Ignite Spring Extensions > - > > Key: IGNITE-22317 > URL: https://issues.apache.org/jira/browse/IGNITE-22317 > Project: Ignite > Issue Type: Task > Components: extensions >Reporter: Andrey Novikov >Assignee: Andrey Novikov >Priority: Major > Fix For: 2.16 > > > The following extenstions must be released: > - ignite-spring-data-ext > - ignite-spring-session-ext > - ignite-spring-cache-ext > - ignite-spring-tx-ext -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22317) [Extensions] Release Ignite Spring Extensions
[ https://issues.apache.org/jira/browse/IGNITE-22317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov updated IGNITE-22317: Epic Link: IGNITE-22096 > [Extensions] Release Ignite Spring Extensions > - > > Key: IGNITE-22317 > URL: https://issues.apache.org/jira/browse/IGNITE-22317 > Project: Ignite > Issue Type: Task > Components: extensions >Reporter: Andrey Novikov >Assignee: Andrey Novikov >Priority: Major > Fix For: 2.16 > > > The following extenstions must be released: > - ignite-spring-data-ext > - ignite-spring-session-ext > - ignite-spring-cache-ext > - ignite-spring-tx-ext -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22317) [Extensions] Release Ignite Spring Extensions
Andrey Novikov created IGNITE-22317: --- Summary: [Extensions] Release Ignite Spring Extensions Key: IGNITE-22317 URL: https://issues.apache.org/jira/browse/IGNITE-22317 Project: Ignite Issue Type: Task Components: extensions Reporter: Andrey Novikov Fix For: 2.16 The following extenstions must be released: - ignite-spring-data-ext - ignite-spring-session-ext - ignite-spring-cache-ext - ignite-spring-tx-ext -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-20059) SpringBoot/Data extensions all use super-old, unsupported versions
[ https://issues.apache.org/jira/browse/IGNITE-20059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848907#comment-17848907 ] Andrey Novikov edited comment on IGNITE-20059 at 5/23/24 11:17 AM: --- [~sdarlington] It seems that these changes are no longer relevant as we updated to Spring 6 in IGNITE-22077 was (Author: anovikov): [~sdarlington] It seems that these changes are no longer required, as we updated to Spring 6 in IGNITE-22077 > SpringBoot/Data extensions all use super-old, unsupported versions > -- > > Key: IGNITE-20059 > URL: https://issues.apache.org/jira/browse/IGNITE-20059 > Project: Ignite > Issue Type: Improvement > Components: extensions, spring, springdata >Reporter: Stephen Darlington >Assignee: Stephen Darlington >Priority: Major > > All our Spring dependencies are very out of date. It's currently pointing to > version 2.2.13, which hasn't been supported since late 2020. This is an > obstacle to Ignite being added to the [Spring > Initializr|https://github.com/spring-io/start.spring.io/issues/960]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20059) SpringBoot/Data extensions all use super-old, unsupported versions
[ https://issues.apache.org/jira/browse/IGNITE-20059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848907#comment-17848907 ] Andrey Novikov commented on IGNITE-20059: - [~sdarlington] It seems that these changes are no longer required, as we updated to Spring 6 in IGNITE-22077 > SpringBoot/Data extensions all use super-old, unsupported versions > -- > > Key: IGNITE-20059 > URL: https://issues.apache.org/jira/browse/IGNITE-20059 > Project: Ignite > Issue Type: Improvement > Components: extensions, spring, springdata >Reporter: Stephen Darlington >Assignee: Stephen Darlington >Priority: Major > > All our Spring dependencies are very out of date. It's currently pointing to > version 2.2.13, which hasn't been supported since late 2020. This is an > obstacle to Ignite being added to the [Spring > Initializr|https://github.com/spring-io/start.spring.io/issues/960]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22316) Sql. Support concatenation for binary types.
[
https://issues.apache.org/jira/browse/IGNITE-22316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-22316:
Description:
According to sql standard: 6.31
{noformat}
::=
|
{noformat}
thus constructions like:
{noformat}
SELECT x'12' || '10';{noformat}
need to be supported.
was:
According to sql standard: 6.31
::=
|
thus constructions like:
{noformat}
SELECT x'12' || '10';{noformat}
need to be supported.
> Sql. Support concatenation for binary types.
>
>
> Key: IGNITE-22316
> URL: https://issues.apache.org/jira/browse/IGNITE-22316
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> According to sql standard: 6.31
> {noformat}
> ::=
>
> |
> {noformat}
> thus constructions like:
> {noformat}
> SELECT x'12' || '10';{noformat}
>
> need to be supported.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22316) Sql. Support concatenation for binary types.
Evgeny Stanilovsky created IGNITE-22316:
---
Summary: Sql. Support concatenation for binary types.
Key: IGNITE-22316
URL: https://issues.apache.org/jira/browse/IGNITE-22316
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Evgeny Stanilovsky
According to sql standard: 6.31
::=
|
thus constructions like:
{noformat}
SELECT x'12' || '10';{noformat}
need to be supported.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22315) Make raft-client starting only once and only with raft-client and replica together
[
https://issues.apache.org/jira/browse/IGNITE-22315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-22315:
-
Description:
*Description*
The goal is to make sure that when partition starting on an ignite-node, if the
node in assignments, then there should be only ones raft-node, raft-client and
replica and no any started entities otherwise.
*Motivation*
Now on the one hand in {{TableManager}} there is a path when raft-node and
replica didn't start, but raft-client is:
In {{TableManager#startPartitionAndStartClient}} there is a place where
{{startGroupFut}} returns {{{}false{}}}:{{ localMemberAssignment}} is {{null}}
or {{PartitionReplicatorNodeRecovery#shouldStartGroup}} returns {{{}false{}}}.
Then, raft-node and replica will not be started, but regardless of
{{startGroupFut}} result raft client will be started:
{code:java}
startGroupFut
.thenComposeAsync(v -> inBusyLock(busyLock, () -> {
TableRaftService tableRaftService =
table.internalTable().tableRaftService();
try {
// Return existing service if it's already started.
return completedFuture(
(TopologyAwareRaftGroupService)
tableRaftService.partitionRaftGroupService(replicaGrpId.partitionId())
);
} catch (IgniteInternalException e) {
// We use "IgniteInternalException" in accordance with the
javadoc of "partitionRaftGroupService" method.
try {
// TODO IGNITE-19614 This procedure takes 10 seconds if
there's no majority online.
return raftMgr
.startRaftGroupService(replicaGrpId,
newConfiguration, raftGroupServiceFactory, raftCommandsMarshaller);
} catch (NodeStoppingException ex) {
return failedFuture(ex);
}
}
}), ioExecutor)
.thenAcceptAsync(updatedRaftGroupService -> inBusyLock(busyLock, () -> {
((InternalTableImpl) internalTbl).tableRaftService()
.updateInternalTableRaftGroupService(partId,
updatedRaftGroupService);
boolean startedRaftNode = startGroupFut.join();
if (localMemberAssignment == null || !startedRaftNode ||
replicaMgr.isReplicaStarted(replicaGrpId)) {
return;
} {code}
{color:#00855f}the code shows that {{v}} argument ({{{}startGroupFut{}}}'s
result) in the lambda doesn't affect on raft-client's starting, and also the
client is put into {{TableRaftService}} then regardless of replica's
starting.{color}
On the other hand, there is a place that rely on raft-client creation on every
node with table's ID in {{TableManager#tables}} map: inside
{{TableManager#handleChangePendingAssignmentEvent}} there are two calls:
# the same name method
{{TableManager#handleChangePendingAssignmentEvent}}{{{}{}}}
# {{TableManager#changePeersOnRebalance}}
Both are asking for internal table's
{{{}tableRaftService().partitionRaftGroupService(partId){}}}, but there no any
checks about is the local node is suitable for raft-entities and replica
starting or they are already started.
Then, when we would try to fix instant raft-client starting it will lead to
instant {{IgniteInternalException}} with _"No such partition P in table T"_
from {{{}TableRaftService#{}}}{{{}partitionRaftGroupService{}}}. This is a
problem that should be solved.
{color:#383838}*Definition of done*{color}
{color:#383838}1. Raft-client must be started only together with raft-node and
replica or shouldn't be started otherwise.{color}
{color:#383838}2. {{TableRaftService}} shouldn't be requested for raft-client
if the local node isn't in a raft group.{color}
{color:#383838}3. Some tests may rely on described behavior, then failed tests
should be investigated and, probably fixed.{color}
{color:#383838}4. New tests that check single starting of raft-node,
raft-client and replica together are required{color}
{color:#0f54d6} {color}
{color:#383838} {color}
{color:#00855f} {color}
was:
*Description*
The goal is to make sure that when partition starting on an ignite-node, if the
node in assignments, then there should be only ones raft-node, raft-client and
replica and no any started entities otherwise.
*Motivation*
Now on the one hand in {{TableManager}} there is a path when raft-node and
replica didn't start, but raft-client is:
In {{TableManager#startPartitionAndStartClient}} there is a place where
startGroupFut returns false: {{localMemberAssignment}} is {{null}} or
{{PartitionReplicatorNodeRecovery#shouldStartGroup}} returns {{{}false{}}}.
Then, raft-node and replica will not be started, but regardless of
{{startGroupFut}} result raft client will be started:
{code:java}
startGroupFut
.thenComposeAsync(v -> inBusyLock(busyLock, () -> {
[jira] [Updated] (IGNITE-22292) Moving LogSyncer from Loza and RaftServer and pass it to usages as IgniteComponent
[
https://issues.apache.org/jira/browse/IGNITE-22292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-22292:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Moving LogSyncer from Loza and RaftServer and pass it to usages as
> IgniteComponent
> --
>
> Key: IGNITE-22292
> URL: https://issues.apache.org/jira/browse/IGNITE-22292
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Efremov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
>
> *Description*
> The main goal is to remove {{LogSyncer}} from {{Loza}} and especially method
> {{{}Loza#getLogSyncer{}}}.
> *Motivation*
> # There is an intention to hide all raft-specific entities behind
> replication layer and log syncer is an entity that sticking out. Besides it's
> only needs for engines and may be passed though {{IgniteImpl}} as an ignite
> component.
> # All current implementations except {{DefaultLogStorageFactory}} are not
> implements properly sync method at all that looks like the reason for
> interface segregation between {{LogSyncer}} and {{LogStorageFactory.}}
> *Definition of done*
> # There no more {{Loza#getLogSyncer}} method and its' calls.
> # {{LogSyncer}} and {{LogStorageFactory}} interfaces are separated.{{{}
> {}}}
> # {{LogSyncer}} creates and injects into engines as {{IgniteComponent}} in
> {{{}IgniteIml{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22218) Remove TableRaftService in favor of using RaftGroupService from Replica instances
[
https://issues.apache.org/jira/browse/IGNITE-22218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-22218:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Remove TableRaftService in favor of using RaftGroupService from Replica
> instances
> -
>
> Key: IGNITE-22218
> URL: https://issues.apache.org/jira/browse/IGNITE-22218
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Efremov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
>
> *Description*
> All {{RaftGroupService}} instances should be gotten from
> {{Replica#raftClient}} instead of using
> {{TableRaftService#partitionRaftGroupService}}.
> *Motivation*
> Main goal is to follow IGNITE-21805 track and localize raft-clients'
> instances management inside {{ReplicaManager}} and
> {{Replica}}. That requires to remove {{TableRaftService}} as entity that
> collects raft-clients inside.
> *Definition of done*
> 1. {{TableRaftService}} is removed.
> 2. All usings of TableRaftService#partitionRaftGroupService}} should be
> replaced on
>{{ReplicaManager#getReplica#raftClient}} calls chain.
> 3. {{TableViewInternal#leaderAssignment}} should be removed from the
> interface.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21805) Refactor TableManager and move all RAFT related pieces to Replica
[ https://issues.apache.org/jira/browse/IGNITE-21805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Efremov updated IGNITE-21805: - Ignite Flags: (was: Docs Required,Release Notes Required) > Refactor TableManager and move all RAFT related pieces to Replica > - > > Key: IGNITE-21805 > URL: https://issues.apache.org/jira/browse/IGNITE-21805 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Mikhail Efremov >Priority: Major > Labels: ignite-3 > Time Spent: 2h 40m > Remaining Estimate: 0h > > *Motivation* > At the moment we have some places inside the TableManager, which: > * Use RaftManager to start/stop RAFT nodes > (handleChangePendingAssignmentEvent/handleChangeStableAssignmentEvent) > * Use RaftGroupService through > table.internalTable().tableRaftService().partitionRaftGroupService calls > This fact prevents us on the track of zone-based collocation. The further > collocation steps will be easier, if we will move the whole RAFT connected > operation to the Replica class. Moreover, it should be there semantically > *Definition of done* > * All code inside the handleChangePendingAssignmentEvent connected with the > start of raft groups (PartitionListener/RebalanceRaftGroupEventsListener) and > raft clients must be moved to the start of the Replica itself > * The same about handleChangeStableAssignmentEvent - the stop of Replica > must stop appropriate raft node > * All calls for > table.internalTable().tableRaftService().partitionRaftGroupService must be > replaced by the replicaMgr.replica(replicaGrpdId).raftClient() > *Implementation notes* > * The new temporary methods must be implemented and remove after IGNITE-22036 > ** ReplicaManager.replica(ReplicationGroupId replicaGrpId) - which returns > the appropriate Replica by group id > ** Replica.raftClient() - which return replica's RaftGroupService (raft > client) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22315) Make raft-client starting only once and only with raft-client and replica together
[
https://issues.apache.org/jira/browse/IGNITE-22315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-22315:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Make raft-client starting only once and only with raft-client and replica
> together
> --
>
> Key: IGNITE-22315
> URL: https://issues.apache.org/jira/browse/IGNITE-22315
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Efremov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
>
> *Description*
> The goal is to make sure that when partition starting on an ignite-node, if
> the node in assignments, then there should be only ones raft-node,
> raft-client and replica and no any started entities otherwise.
> *Motivation*
> Now on the one hand in {{TableManager}} there is a path when raft-node and
> replica didn't start, but raft-client is:
> In {{TableManager#startPartitionAndStartClient}} there is a place where
> startGroupFut returns false: {{localMemberAssignment}} is {{null}} or
> {{PartitionReplicatorNodeRecovery#shouldStartGroup}} returns {{{}false{}}}.
> Then, raft-node and replica will not be started, but regardless of
> {{startGroupFut}} result raft client will be started:
> {code:java}
> startGroupFut
> .thenComposeAsync(v -> inBusyLock(busyLock, () -> {
> TableRaftService tableRaftService =
> table.internalTable().tableRaftService();
> try {
> // Return existing service if it's already started.
> return completedFuture(
> (TopologyAwareRaftGroupService)
> tableRaftService.partitionRaftGroupService(replicaGrpId.partitionId())
> );
> } catch (IgniteInternalException e) {
> // We use "IgniteInternalException" in accordance with the
> javadoc of "partitionRaftGroupService" method.
> try {
> // TODO IGNITE-19614 This procedure takes 10 seconds if
> there's no majority online.
> return raftMgr
> .startRaftGroupService(replicaGrpId,
> newConfiguration, raftGroupServiceFactory, raftCommandsMarshaller);
> } catch (NodeStoppingException ex) {
> return failedFuture(ex);
> }
> }
> }), ioExecutor)
> .thenAcceptAsync(updatedRaftGroupService -> inBusyLock(busyLock, ()
> -> {
> ((InternalTableImpl) internalTbl).tableRaftService()
> .updateInternalTableRaftGroupService(partId,
> updatedRaftGroupService);
> boolean startedRaftNode = startGroupFut.join();
> if (localMemberAssignment == null || !startedRaftNode ||
> replicaMgr.isReplicaStarted(replicaGrpId)) {
> return;
> } {code}
> {color:#00855f}{color:#383838}the code shows that {{v}} argument
> ({{{}startGroupFut{}}}'s result) in the lambda doesn't affect on
> raft-client's starting, and also the client is put into {{TableRaftService}}
> then regardless of replica's starting.{color}{color}
> On the other hand, there is a place that rely on raft-client creation on
> every node with table's ID in {{TableManager#tables}} map: inside
> {{TableManager#handleChangePendingAssignmentEvent}} there are two calls: #
> the same name method {{TableManager#handleChangePendingAssignmentEvent}}
> # {{TableManager#changePeersOnRebalance}}
> Both are asking for internal table's
> {{{}tableRaftService().partitionRaftGroupService(partId){}}}, but there no
> any checks about is the local node is suitable for raft-entities and replica
> starting or they are already started.
>
> Then, when we would try to fix instant raft-client starting it will lead to
> instant {{IgniteInternalException}} with _"No such partition P in table T"_
> from {{TableRaftService#}}
> {{{}partitionRaftGroupService{}}}. This is a problem that should be
> solved.{color:#00855f}
> {color}{color:#383838}
> {color}
> {color:#383838}*Definition of done*{color}
> {color:#383838}1. Raft-client must be started only together with raft-node
> and replica or shouldn't be started otherwise.
> {color}
> {color:#383838}2. {{TableRaftService}} shouldn't be requested for raft-client
> if the local node isn't in a raft group.{color}
> {color:#383838}3. Some tests may rely on described behavior, then failed
> tests should be investigated and, probably fixed.{color}
> {color:#383838}4. New tests that check single starting of raft-node,
> raft-client and replica together are required{color}
> {color:#0f54d6} {color}
> {color:#383838} {color}
> {color:#00855f} {color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22036) Replace TableManager.changePeersOnRebalance by the broadcast ReplicaRequest
[ https://issues.apache.org/jira/browse/IGNITE-22036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Efremov updated IGNITE-22036: - Epic Link: IGNITE-22313 (was: IGNITE-19170) > Replace TableManager.changePeersOnRebalance by the broadcast ReplicaRequest > --- > > Key: IGNITE-22036 > URL: https://issues.apache.org/jira/browse/IGNITE-22036 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Mikhail Efremov >Priority: Major > Labels: ignite-3 > > *Motivation* > To simplify the process of moving to the zone-based collocation we need to > remove all raft-connected code from TableManager. After IGNITE-21805 we will > still have: > * TableManager.changePeersOnRebalance > This method must be replaced by appropriate request to Replica. > *Definition of done* > * TableManager send the broadcast ChangePeersReplicaRequest to all nodes from > table partition assignments instead of direct call to raft changePeersAsync > *Implementation details* > We need to: > * Introduce ChangePeersReplicaRequest(PeersAndLearners peersAndLearners) - > the new replica request type > * Move the code from TableManager.changePeersOnRebalance to the Replica > itself, as a reaction to ChangePeersReplicaRequest > * TableManager must send the ChangePeersReplicaRequest to all nodes from > table partition assignments instead of direct > TableManager.changePeersOnRebalance call -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22218) Remove TableRaftService in favor of using RaftGroupService from Replica instances
[
https://issues.apache.org/jira/browse/IGNITE-22218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-22218:
-
Epic Link: IGNITE-22313 (was: IGNITE-22115)
> Remove TableRaftService in favor of using RaftGroupService from Replica
> instances
> -
>
> Key: IGNITE-22218
> URL: https://issues.apache.org/jira/browse/IGNITE-22218
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Efremov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
>
> *Description*
> All {{RaftGroupService}} instances should be gotten from
> {{Replica#raftClient}} instead of using
> {{TableRaftService#partitionRaftGroupService}}.
> *Motivation*
> Main goal is to follow IGNITE-21805 track and localize raft-clients'
> instances management inside {{ReplicaManager}} and
> {{Replica}}. That requires to remove {{TableRaftService}} as entity that
> collects raft-clients inside.
> *Definition of done*
> 1. {{TableRaftService}} is removed.
> 2. All usings of TableRaftService#partitionRaftGroupService}} should be
> replaced on
>{{ReplicaManager#getReplica#raftClient}} calls chain.
> 3. {{TableViewInternal#leaderAssignment}} should be removed from the
> interface.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22222) Move ThreadLocalPartitionCommandsMarshaller to ReplicaManager module with cycle dependency fix
[
https://issues.apache.org/jira/browse/IGNITE-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-2:
-
Epic Link: IGNITE-22313
> Move ThreadLocalPartitionCommandsMarshaller to ReplicaManager module with
> cycle dependency fix
> --
>
> Key: IGNITE-2
> URL: https://issues.apache.org/jira/browse/IGNITE-2
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Efremov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
>
> *Description*
> Now the marshaller starts in {{IgniteImpl}} and using only for
> {{ReplicaManager}} creation, there is a reason to move it in
> {{{}ReplicaManager{}}}'s constructor, but there is cyclic dependency arises.
> Also in some places in tests classes like
> {{org.apache.ignite.internal.replicator.ItPlacementDriverReplicaSideTest#beforeTest}}
> we can't pass or mock this specific marshaller's class.
> *Definition of done*
> {{ThreadLocalPartitionCommandsMarshaller}} instantiation is moved into
> {{ReplicaManager}} and there no any another places of it's instance creation.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21805) Refactor TableManager and move all RAFT related pieces to Replica
[ https://issues.apache.org/jira/browse/IGNITE-21805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Efremov updated IGNITE-21805: - Epic Link: IGNITE-22313 (was: IGNITE-19170) > Refactor TableManager and move all RAFT related pieces to Replica > - > > Key: IGNITE-21805 > URL: https://issues.apache.org/jira/browse/IGNITE-21805 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Mikhail Efremov >Priority: Major > Labels: ignite-3 > Time Spent: 2h 40m > Remaining Estimate: 0h > > *Motivation* > At the moment we have some places inside the TableManager, which: > * Use RaftManager to start/stop RAFT nodes > (handleChangePendingAssignmentEvent/handleChangeStableAssignmentEvent) > * Use RaftGroupService through > table.internalTable().tableRaftService().partitionRaftGroupService calls > This fact prevents us on the track of zone-based collocation. The further > collocation steps will be easier, if we will move the whole RAFT connected > operation to the Replica class. Moreover, it should be there semantically > *Definition of done* > * All code inside the handleChangePendingAssignmentEvent connected with the > start of raft groups (PartitionListener/RebalanceRaftGroupEventsListener) and > raft clients must be moved to the start of the Replica itself > * The same about handleChangeStableAssignmentEvent - the stop of Replica > must stop appropriate raft node > * All calls for > table.internalTable().tableRaftService().partitionRaftGroupService must be > replaced by the replicaMgr.replica(replicaGrpdId).raftClient() > *Implementation notes* > * The new temporary methods must be implemented and remove after IGNITE-22036 > ** ReplicaManager.replica(ReplicationGroupId replicaGrpId) - which returns > the appropriate Replica by group id > ** Replica.raftClient() - which return replica's RaftGroupService (raft > client) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22315) Make raft-client starting only once and only with raft-client and replica together
Mikhail Efremov created IGNITE-22315:
Summary: Make raft-client starting only once and only with
raft-client and replica together
Key: IGNITE-22315
URL: https://issues.apache.org/jira/browse/IGNITE-22315
Project: Ignite
Issue Type: Improvement
Reporter: Mikhail Efremov
Assignee: Mikhail Efremov
*Description*
The goal is to make sure that when partition starting on an ignite-node, if the
node in assignments, then there should be only ones raft-node, raft-client and
replica and no any started entities otherwise.
*Motivation*
Now on the one hand in {{TableManager}} there is a path when raft-node and
replica didn't start, but raft-client is:
In {{TableManager#startPartitionAndStartClient}} there is a place where
startGroupFut returns false: {{localMemberAssignment}} is {{null}} or
{{PartitionReplicatorNodeRecovery#shouldStartGroup}} returns {{{}false{}}}.
Then, raft-node and replica will not be started, but regardless of
{{startGroupFut}} result raft client will be started:
{code:java}
startGroupFut
.thenComposeAsync(v -> inBusyLock(busyLock, () -> {
TableRaftService tableRaftService =
table.internalTable().tableRaftService();
try {
// Return existing service if it's already started.
return completedFuture(
(TopologyAwareRaftGroupService)
tableRaftService.partitionRaftGroupService(replicaGrpId.partitionId())
);
} catch (IgniteInternalException e) {
// We use "IgniteInternalException" in accordance with the
javadoc of "partitionRaftGroupService" method.
try {
// TODO IGNITE-19614 This procedure takes 10 seconds if
there's no majority online.
return raftMgr
.startRaftGroupService(replicaGrpId,
newConfiguration, raftGroupServiceFactory, raftCommandsMarshaller);
} catch (NodeStoppingException ex) {
return failedFuture(ex);
}
}
}), ioExecutor)
.thenAcceptAsync(updatedRaftGroupService -> inBusyLock(busyLock, () -> {
((InternalTableImpl) internalTbl).tableRaftService()
.updateInternalTableRaftGroupService(partId,
updatedRaftGroupService);
boolean startedRaftNode = startGroupFut.join();
if (localMemberAssignment == null || !startedRaftNode ||
replicaMgr.isReplicaStarted(replicaGrpId)) {
return;
} {code}
{color:#00855f}{color:#383838}the code shows that {{v}} argument
({{{}startGroupFut{}}}'s result) in the lambda doesn't affect on raft-client's
starting, and also the client is put into {{TableRaftService}} then regardless
of replica's starting.{color}{color}
On the other hand, there is a place that rely on raft-client creation on every
node with table's ID in {{TableManager#tables}} map: inside
{{TableManager#handleChangePendingAssignmentEvent}} there are two calls: # the
same name method {{TableManager#handleChangePendingAssignmentEvent}}
# {{TableManager#changePeersOnRebalance}}
Both are asking for internal table's
{{{}tableRaftService().partitionRaftGroupService(partId){}}}, but there no any
checks about is the local node is suitable for raft-entities and replica
starting or they are already started.
Then, when we would try to fix instant raft-client starting it will lead to
instant {{IgniteInternalException}} with _"No such partition P in table T"_
from {{TableRaftService#}}
{{{}partitionRaftGroupService{}}}. This is a problem that should be
solved.{color:#00855f}
{color}{color:#383838}
{color}
{color:#383838}*Definition of done*{color}
{color:#383838}1. Raft-client must be started only together with raft-node and
replica or shouldn't be started otherwise.
{color}
{color:#383838}2. {{TableRaftService}} shouldn't be requested for raft-client
if the local node isn't in a raft group.{color}
{color:#383838}3. Some tests may rely on described behavior, then failed tests
should be investigated and, probably fixed.{color}
{color:#383838}4. New tests that check single starting of raft-node,
raft-client and replica together are required{color}
{color:#0f54d6} {color}
{color:#383838} {color}
{color:#00855f} {color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22314) Sql. Incorrect result while using ALL operator.
[
https://issues.apache.org/jira/browse/IGNITE-22314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-22314:
Description:
Query:
{noformat}
CREATE TABLE integers(i INTEGER);
INSERT INTO integers VALUES (1), (2), (3), (NULL);
SELECT i=ALL(SELECT i FROM (values(null), (1)) integers(i) WHERE i=i1.i OR i IS
NULL) FROM integers i1 ORDER BY i;
the same for:
SELECT i=ALL(SELECT i FROM integers WHERE i=i1.i OR i IS NULL) FROM integers i1
ORDER BY i;{noformat}
returns incorrect result, need to be four NULL`s but four 'true' will return.
was:
Query:
{noformat}
CREATE TABLE integers(i INTEGER);
INSERT INTO integers VALUES (1), (2), (3), (NULL);
SELECT i=ALL(SELECT i FROM (values(null), (1)) integers(i) WHERE i=i1.i OR i IS
NULL) FROM integers i1 ORDER BY i;
{noformat}
returns incorrect result, need to be four NULL`s but four 'true' will return.
> Sql. Incorrect result while using ALL operator.
> ---
>
> Key: IGNITE-22314
> URL: https://issues.apache.org/jira/browse/IGNITE-22314
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> Query:
> {noformat}
> CREATE TABLE integers(i INTEGER);
> INSERT INTO integers VALUES (1), (2), (3), (NULL);
> SELECT i=ALL(SELECT i FROM (values(null), (1)) integers(i) WHERE i=i1.i OR i
> IS NULL) FROM integers i1 ORDER BY i;
> the same for:
> SELECT i=ALL(SELECT i FROM integers WHERE i=i1.i OR i IS NULL) FROM integers
> i1 ORDER BY i;{noformat}
> returns incorrect result, need to be four NULL`s but four 'true' will return.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22314) Sql. Incorrect result while using ALL operator.
[
https://issues.apache.org/jira/browse/IGNITE-22314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-22314:
Ignite Flags: (was: Docs Required,Release Notes Required)
> Sql. Incorrect result while using ALL operator.
> ---
>
> Key: IGNITE-22314
> URL: https://issues.apache.org/jira/browse/IGNITE-22314
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
>
> Query:
> {noformat}
> CREATE TABLE integers(i INTEGER);
> INSERT INTO integers VALUES (1), (2), (3), (NULL);
> SELECT i=ALL(SELECT i FROM (values(null), (1)) integers(i) WHERE i=i1.i OR i
> IS NULL) FROM integers i1 ORDER BY i;
> {noformat}
> returns incorrect result, need to be four NULL`s but four 'true' will return.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22314) Sql. Incorrect result while using ALL operator.
[
https://issues.apache.org/jira/browse/IGNITE-22314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-22314:
Labels: ignite-3 (was: )
> Sql. Incorrect result while using ALL operator.
> ---
>
> Key: IGNITE-22314
> URL: https://issues.apache.org/jira/browse/IGNITE-22314
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> Query:
> {noformat}
> CREATE TABLE integers(i INTEGER);
> INSERT INTO integers VALUES (1), (2), (3), (NULL);
> SELECT i=ALL(SELECT i FROM (values(null), (1)) integers(i) WHERE i=i1.i OR i
> IS NULL) FROM integers i1 ORDER BY i;
> {noformat}
> returns incorrect result, need to be four NULL`s but four 'true' will return.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22314) Sql. Incorrect result while using ALL operator.
Evgeny Stanilovsky created IGNITE-22314:
---
Summary: Sql. Incorrect result while using ALL operator.
Key: IGNITE-22314
URL: https://issues.apache.org/jira/browse/IGNITE-22314
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Evgeny Stanilovsky
Query:
{noformat}
CREATE TABLE integers(i INTEGER);
INSERT INTO integers VALUES (1), (2), (3), (NULL);
SELECT i=ALL(SELECT i FROM (values(null), (1)) integers(i) WHERE i=i1.i OR i IS
NULL) FROM integers i1 ORDER BY i;
{noformat}
returns incorrect result, need to be four NULL`s but four 'true' will return.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22292) Moving LogSyncer from Loza and RaftServer and pass it to usages as IgniteComponent
[
https://issues.apache.org/jira/browse/IGNITE-22292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-22292:
-
Epic Link: IGNITE-22313 (was: IGNITE-22115)
> Moving LogSyncer from Loza and RaftServer and pass it to usages as
> IgniteComponent
> --
>
> Key: IGNITE-22292
> URL: https://issues.apache.org/jira/browse/IGNITE-22292
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Efremov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
>
> *Description*
> The main goal is to remove {{LogSyncer}} from {{Loza}} and especially method
> {{{}Loza#getLogSyncer{}}}.
> *Motivation*
> # There is an intention to hide all raft-specific entities behind
> replication layer and log syncer is an entity that sticking out. Besides it's
> only needs for engines and may be passed though {{IgniteImpl}} as an ignite
> component.
> # All current implementations except {{DefaultLogStorageFactory}} are not
> implements properly sync method at all that looks like the reason for
> interface segregation between {{LogSyncer}} and {{LogStorageFactory.}}
> *Definition of done*
> # There no more {{Loza#getLogSyncer}} method and its' calls.
> # {{LogSyncer}} and {{LogStorageFactory}} interfaces are separated.{{{}
> {}}}
> # {{LogSyncer}} creates and injects into engines as {{IgniteComponent}} in
> {{{}IgniteIml{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22313) Moving RAFT-specific code to replication layer
Mikhail Efremov created IGNITE-22313: Summary: Moving RAFT-specific code to replication layer Key: IGNITE-22313 URL: https://issues.apache.org/jira/browse/IGNITE-22313 Project: Ignite Issue Type: Epic Reporter: Mikhail Efremov Assignee: Mikhail Efremov An epic for tickets to move RAFT-related entities and it's calls under replication layer -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22312) Sql. Type parameters such precision / scale / length are not properly checked.
[
https://issues.apache.org/jira/browse/IGNITE-22312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22312:
--
Description:
1. SqlValidator accepts values for precision / scale that lay beyond max
precision / scale values defined by IgniteTypeSystem:
{noformat}
SELECT '12:34:54'::TIME(1000)
SELECT '111'::DECIMAL(2147483647)
{noformat}
2. Error messages produced by Catalog and SqlValidator are inconsistent:
{noformat}
ALTER TABLE t ADD COLUMN valint3 varchar(0)
Error: Length for column 'VALINT3' of type 'STRING' must be at least 1
SELECT 1::VARCHAR(0)
Error: Length for type 'VARCHAR' must be at least 1
{noformat}
was:
1. SqlValidator accepts values for precision / scale that lay beyond max
precision / scale values defined by IgniteTypeSystem:
{noformat}
SELECT '12:34:54'::TIME(1000)
SELECT '111' :: DECIMAL(2147483647)
{noformat}
2. Error messages produced by Catalog and SqlValidator are inconsistent:
{noformat}
ALTER TABLE t ADD COLUMN valint3 varchar(0)
Error: Length for column 'VALINT3' of type 'STRING' must be at least 1
SELECT 1::VARCHAR(0)
Error: Length for type 'VARCHAR' must be at least 1
{noformat}
> Sql. Type parameters such precision / scale / length are not properly checked.
> --
>
> Key: IGNITE-22312
> URL: https://issues.apache.org/jira/browse/IGNITE-22312
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
>
> 1. SqlValidator accepts values for precision / scale that lay beyond max
> precision / scale values defined by IgniteTypeSystem:
> {noformat}
> SELECT '12:34:54'::TIME(1000)
> SELECT '111'::DECIMAL(2147483647)
> {noformat}
> 2. Error messages produced by Catalog and SqlValidator are inconsistent:
> {noformat}
> ALTER TABLE t ADD COLUMN valint3 varchar(0)
> Error: Length for column 'VALINT3' of type 'STRING' must be at least 1
> SELECT 1::VARCHAR(0)
> Error: Length for type 'VARCHAR' must be at least 1
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22312) Sql. Type parameters such precision / scale / length are not properly checked.
[
https://issues.apache.org/jira/browse/IGNITE-22312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22312:
--
Description:
1. SqlValidator accepts values for precision / scale that lay beyond max
precision / scale values defined by IgniteTypeSystem:
{noformat}
SELECT '12:34:54'::TIME(1000)
SELECT '111' :: DECIMAL(2147483647)
{noformat}
2. Error messages produced by Catalog and SqlValidator are inconsistent:
{noformat}
ALTER TABLE t ADD COLUMN valint3 varchar(0)
Error: Length for column 'VALINT3' of type 'STRING' must be at least 1
SELECT 1::VARCHAR(0)
Error: Length for type 'VARCHAR' must be at least 1
{noformat}
was:
1. SqlValidator accept values for precision / scale that lay beyond max
precision / scale values defined by IgniteTypeSystem.
2. Error messages produced by Catalog and SqlValidator are inconsistent:
{noformat}
ALTER TABLE t ADD COLUMN valint3 varchar(0)
Error: Length for column 'VALINT3' of type 'STRING' must be at least 1
SELECT 1::VARCHAR(0)
Error: Length for type 'VARCHAR' must be at least 1
{noformat}
> Sql. Type parameters such precision / scale / length are not properly checked.
> --
>
> Key: IGNITE-22312
> URL: https://issues.apache.org/jira/browse/IGNITE-22312
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
>
> 1. SqlValidator accepts values for precision / scale that lay beyond max
> precision / scale values defined by IgniteTypeSystem:
> {noformat}
> SELECT '12:34:54'::TIME(1000)
> SELECT '111' :: DECIMAL(2147483647)
> {noformat}
> 2. Error messages produced by Catalog and SqlValidator are inconsistent:
> {noformat}
> ALTER TABLE t ADD COLUMN valint3 varchar(0)
> Error: Length for column 'VALINT3' of type 'STRING' must be at least 1
> SELECT 1::VARCHAR(0)
> Error: Length for type 'VARCHAR' must be at least 1
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22312) Sql. Type parameters such precision / scale / length are not properly checked.
Maksim Zhuravkov created IGNITE-22312:
-
Summary: Sql. Type parameters such precision / scale / length are
not properly checked.
Key: IGNITE-22312
URL: https://issues.apache.org/jira/browse/IGNITE-22312
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Maksim Zhuravkov
1. SqlValidator accept values for precision / scale that lay beyond max
precision / scale values defined by IgniteTypeSystem.
2. Error messages produced by Catalog and SqlValidator are inconsistent:
{noformat}
ALTER TABLE t ADD COLUMN valint3 varchar(0)
Error: Length for column 'VALINT3' of type 'STRING' must be at least 1
SELECT 1::VARCHAR(0)
Error: Length for type 'VARCHAR' must be at least 1
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20966) Improve error messages for schema change validation failures
[
https://issues.apache.org/jira/browse/IGNITE-20966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philipp Shergalis updated IGNITE-20966:
---
Reviewer: Roman Puchkovskiy (was: Aleksandr Polovtsev)
> Improve error messages for schema change validation failures
>
>
> Key: IGNITE-20966
> URL: https://issues.apache.org/jira/browse/IGNITE-20966
> Project: Ignite
> Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Assignee: Philipp Shergalis
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> At least, 'Commit failed because schema %d is not forward-compatible with %d
> for table %d' should be improved to make it useful for an end-user. We
> shoiuld at least add table name to the message.
>
> What was done:
> Final error contains descriptions of all failed validations, i.e.
> {quote}"Name of the table has been changed; Added nonnull columns without
> default value: [NON_NULL_WITHOUT_DEFAULT_COL];
> Columns were dropped; Columns change validation failed: [TYPE_CHANGED_COL:
> Type changed;
> ADD_DEFAULT_COL: Default value changed; CHANGE_DEFAULT_COL: Default value
> changed; DROP_DEFAULT_COL: Default value changed]"
> {quote}
> . Where it was trivial, changed tableID to table name - for the case when
> table was already dropped created a new issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22272) Rework Catalog API
[
https://issues.apache.org/jira/browse/IGNITE-22272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vadim Kolodin updated IGNITE-22272:
---
Description:
* Do not return a Query that has to be executed, run it immediately. For
example: *Table table = catalog.createTable(Pojo.class)*
* All methods should be async-first
* Rename *create* to *createTable* (recordClass and KV methods)
* all *createTable* methods should return a {*}Table{*}. Especially important
for record and KV cases, where the resulting name is not obvious
* add option to specify column/index order in builders, annotations - explicit
order or implicit "default" (in case of composite index, colocation columns)
was:
* Do not return a Query that has to be executed, run it immediately. For
example: *Table table = catalog.createTable(Pojo.class)*
* All methods should be async-first
* Rename *create* to *createTable* (recordClass and KV methods)
* all *createTable* methods should return a {*}Table{*}. Especially important
for record and KV cases, where the resulting name is not obvious
* add option to specify column/index order in builders, annotations (in case
of composite index, colocation columns)
> Rework Catalog API
> --
>
> Key: IGNITE-22272
> URL: https://issues.apache.org/jira/browse/IGNITE-22272
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Tupitsyn
>Priority: Critical
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> * Do not return a Query that has to be executed, run it immediately. For
> example: *Table table = catalog.createTable(Pojo.class)*
> * All methods should be async-first
> * Rename *create* to *createTable* (recordClass and KV methods)
> * all *createTable* methods should return a {*}Table{*}. Especially
> important for record and KV cases, where the resulting name is not obvious
> * add option to specify column/index order in builders, annotations -
> explicit order or implicit "default" (in case of composite index, colocation
> columns)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18372) Add CDC metrics to KafkaToIgniteStreamer
[
https://issues.apache.org/jira/browse/IGNITE-18372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Davydov reassigned IGNITE-18372:
---
Assignee: Maksim Davydov
> Add CDC metrics to KafkaToIgniteStreamer
>
>
> Key: IGNITE-18372
> URL: https://issues.apache.org/jira/browse/IGNITE-18372
> Project: Ignite
> Issue Type: New Feature
> Components: extensions
>Reporter: Ilya Shishkov
>Assignee: Maksim Davydov
>Priority: Major
> Labels: IEP-59, ise
>
> We need metrics for received events count and last received event timestamp
> for the {{KafkaToIgniteStreamer}}, because there can be situations, when
> events sent by {{IgniteToKafkaStreamer}} are lost in Kafka due to Kafka
> failures or topic's retention configuration.
> In such situations we should be able to compare to sent messages count on
> source cluster with received messages count on destination one. Timestamp of
> last received event would be also useful.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22272) Rework Catalog API
[
https://issues.apache.org/jira/browse/IGNITE-22272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vadim Kolodin updated IGNITE-22272:
---
Description:
* Do not return a Query that has to be executed, run it immediately. For
example: *Table table = catalog.createTable(Pojo.class)*
* All methods should be async-first
* Rename *create* to *createTable* (recordClass and KV methods)
* all *createTable* methods should return a {*}Table{*}. Especially important
for record and KV cases, where the resulting name is not obvious
* add option to specify column/index order in builders, annotations (in case
of composite index, colocation columns)
was:
* Do not return a Query that has to be executed, run it immediately. For
example: *Table table = catalog.createTable(Pojo.class)*
* All methods should be async-first
* Rename *create* to *createTable* (recordClass and KV methods)
* all *createTable* methods should return a {*}Table{*}. Especially important
for record and KV cases, where the resulting name is not obvious
* add option to specify column/index order (in case of composite index,
colocation columns)
> Rework Catalog API
> --
>
> Key: IGNITE-22272
> URL: https://issues.apache.org/jira/browse/IGNITE-22272
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Tupitsyn
>Priority: Critical
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> * Do not return a Query that has to be executed, run it immediately. For
> example: *Table table = catalog.createTable(Pojo.class)*
> * All methods should be async-first
> * Rename *create* to *createTable* (recordClass and KV methods)
> * all *createTable* methods should return a {*}Table{*}. Especially
> important for record and KV cases, where the resulting name is not obvious
> * add option to specify column/index order in builders, annotations (in case
> of composite index, colocation columns)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22272) Rework Catalog API
[
https://issues.apache.org/jira/browse/IGNITE-22272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vadim Kolodin updated IGNITE-22272:
---
Description:
* Do not return a Query that has to be executed, run it immediately. For
example: *Table table = catalog.createTable(Pojo.class)*
* All methods should be async-first
* Rename *create* to *createTable* (recordClass and KV methods)
* all *createTable* methods should return a {*}Table{*}. Especially important
for record and KV cases, where the resulting name is not obvious
* add option to specify column/index order (in case of composite index,
colocation columns)
was:
* Do not return a Query that has to be executed, run it immediately. For
example: *Table table = catalog.createTable(Pojo.class)*
* All methods should be async-first
* Rename *create* to *createTable* (recordClass and KV methods)
* all *createTable* methods should return a *Table*. Especially important for
record and KV cases, where the resulting name is not obvious
> Rework Catalog API
> --
>
> Key: IGNITE-22272
> URL: https://issues.apache.org/jira/browse/IGNITE-22272
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Tupitsyn
>Priority: Critical
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> * Do not return a Query that has to be executed, run it immediately. For
> example: *Table table = catalog.createTable(Pojo.class)*
> * All methods should be async-first
> * Rename *create* to *createTable* (recordClass and KV methods)
> * all *createTable* methods should return a {*}Table{*}. Especially
> important for record and KV cases, where the resulting name is not obvious
> * add option to specify column/index order (in case of composite index,
> colocation columns)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22311) Fix checkstyle in spring-ses-ext
[ https://issues.apache.org/jira/browse/IGNITE-22311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848884#comment-17848884 ] Andrey Novikov commented on IGNITE-22311: - LGTM > Fix checkstyle in spring-ses-ext > > > Key: IGNITE-22311 > URL: https://issues.apache.org/jira/browse/IGNITE-22311 > Project: Ignite > Issue Type: Improvement >Reporter: Nusrat Shakarov >Assignee: Nusrat Shakarov >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22028) Thin client: Implement invoke/invokeAll operations
[
https://issues.apache.org/jira/browse/IGNITE-22028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848883#comment-17848883
]
Ignite TC Bot commented on IGNITE-22028:
{panel:title=Branch: [pull/11358/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11358/head] Base: [master] : New Tests
(15)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Thin Client: Java{color} [[tests
15|https://ci2.ignite.apache.org/viewLog.html?buildId=7880978]]
* {color:#013220}ClientTestSuite: InvokeTest.testInvokeSimpleCase[Atomic -
PASSED{color}
* {color:#013220}ClientTestSuite: InvokeTest.testSerialization[Atomic -
PASSED{color}
* {color:#013220}ClientTestSuite: InvokeTest.testWithKeepBinary[Atomic -
PASSED{color}
* {color:#013220}ClientTestSuite: InvokeTest.testAsync[Atomic - PASSED{color}
* {color:#013220}ClientTestSuite: InvokeTest.testInvokeAllSimpleCase[Atomic -
PASSED{color}
* {color:#013220}ClientTestSuite: InvokeTest.testInvokeSimpleCase[Atomic -
PASSED{color}
* {color:#013220}ClientTestSuite: InvokeTest.testSerialization[Atomic -
PASSED{color}
* {color:#013220}ClientTestSuite: InvokeTest.testAsyncExceptionHandling[Atomic
- PASSED{color}
* {color:#013220}ClientTestSuite: InvokeTest.testExceptionHandling[Atomic -
PASSED{color}
* {color:#013220}ClientTestSuite: InvokeTest.testWithKeepBinary[Atomic -
PASSED{color}
* {color:#013220}ClientTestSuite: InvokeTest.testExplicitTx[Atomic -
PASSED{color}
... and 4 new tests
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7880181buildTypeId=IgniteTests24Java8_RunAll]
> Thin client: Implement invoke/invokeAll operations
> --
>
> Key: IGNITE-22028
> URL: https://issues.apache.org/jira/browse/IGNITE-22028
> Project: Ignite
> Issue Type: New Feature
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: IEP-122, ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We must implement invoke/invokeAll methods for thin client.
> Dev. list thread and IEP should be started to discuss protocol and
> implementation details.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22292) Moving LogSyncer from Loza and RaftServer and pass it to usages as IgniteComponent
[
https://issues.apache.org/jira/browse/IGNITE-22292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-22292:
-
Labels: ignite-3 (was: )
> Moving LogSyncer from Loza and RaftServer and pass it to usages as
> IgniteComponent
> --
>
> Key: IGNITE-22292
> URL: https://issues.apache.org/jira/browse/IGNITE-22292
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Efremov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
>
> *Description*
> The main goal is to remove {{LogSyncer}} from {{Loza}} and especially method
> {{{}Loza#getLogSyncer{}}}.
> *Motivation*
> # There is an intention to hide all raft-specific entities behind
> replication layer and log syncer is an entity that sticking out. Besides it's
> only needs for engines and may be passed though {{IgniteImpl}} as an ignite
> component.
> # All current implementations except {{DefaultLogStorageFactory}} are not
> implements properly sync method at all that looks like the reason for
> interface segregation between {{LogSyncer}} and {{LogStorageFactory.}}
> *Definition of done*
> # There no more {{Loza#getLogSyncer}} method and its' calls.
> # {{LogSyncer}} and {{LogStorageFactory}} interfaces are separated.{{{}
> {}}}
> # {{LogSyncer}} creates and injects into engines as {{IgniteComponent}} in
> {{{}IgniteIml{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22311) Fix checkstyle in spring-ses-ext
[ https://issues.apache.org/jira/browse/IGNITE-22311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nusrat Shakarov reassigned IGNITE-22311: Assignee: Nusrat Shakarov > Fix checkstyle in spring-ses-ext > > > Key: IGNITE-22311 > URL: https://issues.apache.org/jira/browse/IGNITE-22311 > Project: Ignite > Issue Type: Improvement >Reporter: Nusrat Shakarov >Assignee: Nusrat Shakarov >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22311) Fix checkstyle in spring-ses-ext
Nusrat Shakarov created IGNITE-22311: Summary: Fix checkstyle in spring-ses-ext Key: IGNITE-22311 URL: https://issues.apache.org/jira/browse/IGNITE-22311 Project: Ignite Issue Type: Improvement Reporter: Nusrat Shakarov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22305) Change API usage of Placement driver for ClientPrimaryReplicaTracker from TablePartitionId to ZonePartitionId
[
https://issues.apache.org/jira/browse/IGNITE-22305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev reassigned IGNITE-22305:
Assignee: Mirza Aliev
> Change API usage of Placement driver for ClientPrimaryReplicaTracker from
> TablePartitionId to ZonePartitionId
> -
>
> Key: IGNITE-22305
> URL: https://issues.apache.org/jira/browse/IGNITE-22305
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
> decompose original task to several subtasks.
> In this ticket we need to use previously created decorator for Placement
> Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for
> {{ClientPrimaryReplicaTracker}} where {{PlacementDriver.getPrimaryReplica}}
> was used before. See spreadsheet from
> https://issues.apache.org/jira/browse/IGNITE-21858 with details about places
> to change.
> This will be the last place of PD API where {{TablePartitionId}} is used, so
> after that we can get rid of decorator and rename
> {{getPrimaryReplicaForTable}} and {{awaitPrimaryReplicaForTable}} and also we
> can move logic from the decorator to LeaseTracker. Also
> {{LeaseTracker#tablePartIdToZoneIdProvider}} could removed.
> h3. Definition of done
> All usages of {{PlacementDriver}} API with {{TablePartitionId}}
> ({{getPrimaryReplica}}) in {{ClientPrimaryReplicaTracker}} must be changed to
> new methods which use {{ZonePartitionId}} (with tableId). Also
> {{LeaseTracker#tablePartIdToZoneIdProvider}} must be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22310) Handling of TxCleanupMessage takes too much time on the network thread
Aleksandr Polovtsev created IGNITE-22310:
Summary: Handling of TxCleanupMessage takes too much time on the
network thread
Key: IGNITE-22310
URL: https://issues.apache.org/jira/browse/IGNITE-22310
Project: Ignite
Issue Type: Improvement
Reporter: Aleksandr Polovtsev
When running tests on my local machine, I've encountered a lot of messages like
"Message handling has been too long" for messages of type {{TxCleanupMessage}}.
Looks like the sync part of the {{TxCleanupRequestHandler}} should either be
optimized or dispatched onto a different thread.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20966) Improve error messages for schema change validation failures
[
https://issues.apache.org/jira/browse/IGNITE-20966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philipp Shergalis updated IGNITE-20966:
---
Description:
At least, 'Commit failed because schema %d is not forward-compatible with %d
for table %d' should be improved to make it useful for an end-user. We shoiuld
at least add table name to the message.
What was done:
Final error contains descriptions of all failed validations, i.e.
{quote}"Name of the table has been changed; Added nonnull columns without
default value: [NON_NULL_WITHOUT_DEFAULT_COL];
Columns were dropped; Columns change validation failed: [TYPE_CHANGED_COL: Type
changed;
ADD_DEFAULT_COL: Default value changed; CHANGE_DEFAULT_COL: Default value
changed; DROP_DEFAULT_COL: Default value changed]"
{quote}
. Where it was trivial, changed tableID to table name - for the case when table
was already dropped created a new issue.
was:At least, 'Commit failed because schema %d is not forward-compatible with
%d for table %d' should be improved to make it useful for an end-user. We
shoiuld at least add table name to the message.
> Improve error messages for schema change validation failures
>
>
> Key: IGNITE-20966
> URL: https://issues.apache.org/jira/browse/IGNITE-20966
> Project: Ignite
> Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Assignee: Philipp Shergalis
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> At least, 'Commit failed because schema %d is not forward-compatible with %d
> for table %d' should be improved to make it useful for an end-user. We
> shoiuld at least add table name to the message.
>
> What was done:
> Final error contains descriptions of all failed validations, i.e.
> {quote}"Name of the table has been changed; Added nonnull columns without
> default value: [NON_NULL_WITHOUT_DEFAULT_COL];
> Columns were dropped; Columns change validation failed: [TYPE_CHANGED_COL:
> Type changed;
> ADD_DEFAULT_COL: Default value changed; CHANGE_DEFAULT_COL: Default value
> changed; DROP_DEFAULT_COL: Default value changed]"
> {quote}
> . Where it was trivial, changed tableID to table name - for the case when
> table was already dropped created a new issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22308) .NET: Windows build fails due to vulnerable Newtonsoft.Json version
[
https://issues.apache.org/jira/browse/IGNITE-22308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848834#comment-17848834
]
Pavel Tupitsyn commented on IGNITE-22308:
-
Merged to master:
[a2cd44cd7873f5104253434f15eb740d98f20a51|https://github.com/apache/ignite/commit/a2cd44cd7873f5104253434f15eb740d98f20a51]
> .NET: Windows build fails due to vulnerable Newtonsoft.Json version
> ---
>
> Key: IGNITE-22308
> URL: https://issues.apache.org/jira/browse/IGNITE-22308
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.17
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code}
> C:\opt\BuildAgent\work\cfbab08dcf053850\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Apache.Ignite.Core.Tests.csproj
> : error NU1903: Warning As Error: Package 'Newtonsoft.Json' 12.0.3 has a
> known high severity vulnerability,
> https://github.com/advisories/GHSA-5crp-9r3c-p9vr
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22308) .NET: Windows build fails due to vulnerable Newtonsoft.Json version
[
https://issues.apache.org/jira/browse/IGNITE-22308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-22308:
Ignite Flags: (was: Docs Required,Release Notes Required)
> .NET: Windows build fails due to vulnerable Newtonsoft.Json version
> ---
>
> Key: IGNITE-22308
> URL: https://issues.apache.org/jira/browse/IGNITE-22308
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.17
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code}
> C:\opt\BuildAgent\work\cfbab08dcf053850\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Apache.Ignite.Core.Tests.csproj
> : error NU1903: Warning As Error: Package 'Newtonsoft.Json' 12.0.3 has a
> known high severity vulnerability,
> https://github.com/advisories/GHSA-5crp-9r3c-p9vr
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22308) .NET: Windows build fails due to vulnerable Newtonsoft.Json version
[
https://issues.apache.org/jira/browse/IGNITE-22308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848830#comment-17848830
]
Pavel Tupitsyn commented on IGNITE-22308:
-
Build fixed:
*
https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetWindows?branch=pull%2F11359%2Fhead=overview=builds
*
https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux?branch=pull%2F11359%2Fhead=overview=builds
> .NET: Windows build fails due to vulnerable Newtonsoft.Json version
> ---
>
> Key: IGNITE-22308
> URL: https://issues.apache.org/jira/browse/IGNITE-22308
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.17
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> C:\opt\BuildAgent\work\cfbab08dcf053850\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Apache.Ignite.Core.Tests.csproj
> : error NU1903: Warning As Error: Package 'Newtonsoft.Json' 12.0.3 has a
> known high severity vulnerability,
> https://github.com/advisories/GHSA-5crp-9r3c-p9vr
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22309) Use name of the table instead of ID in IncompatibleSchemaException
Philipp Shergalis created IGNITE-22309: -- Summary: Use name of the table instead of ID in IncompatibleSchemaException Key: IGNITE-22309 URL: https://issues.apache.org/jira/browse/IGNITE-22309 Project: Ignite Issue Type: Improvement Reporter: Philipp Shergalis There is a TODO in the code. If the table was already dropped since the beginning of the operation, it's not trivial to get it's name. Nevertheless, ID of the table is meaningless for a user. -- This message was sent by Atlassian Jira (v8.20.10#820010)
