[jira] [Assigned] (IGNITE-17116) Add architecture documentation for CLI module.
[ https://issues.apache.org/jira/browse/IGNITE-17116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-17116: -- Assignee: Aleksandr > Add architecture documentation for CLI module. > -- > > Key: IGNITE-17116 > URL: https://issues.apache.org/jira/browse/IGNITE-17116 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > A developer should read the documentation and: > * how to create an executable command > * how to test an executable command (unit and integration) > * how to create an interactive command > * how to test an interactive command > Also, the ExecutionPepiline concept and the extention mechanismshould be > described. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16945) Implement Version REST API group
[ https://issues.apache.org/jira/browse/IGNITE-16945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-16945: --- Description: h3. Version REST API Provide the build version for the node. ||Method||Path||Parameters||Description|| |GET|/management/v1/node/version/| |Return node build version in semver format.| was: h3. Version REST API Provide the build version for the node. ||Method||Path||Parameters||Description|| |GET|/management/v1/version/| |Return node build version in semver format.| > Implement Version REST API group > > > Key: IGNITE-16945 > URL: https://issues.apache.org/jira/browse/IGNITE-16945 > Project: Ignite > Issue Type: Task > Components: rest >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > h3. Version REST API > Provide the build version for the node. > ||Method||Path||Parameters||Description|| > |GET|/management/v1/node/version/| |Return node build version in semver > format.| -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17574) AssertionError "According to the JRaft protocol ECATCHUP is expected" is thrown on reconfiguration error
[
https://issues.apache.org/jira/browse/IGNITE-17574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-17574:
---
Reviewer: Roman Puchkovskiy
Description:
{noformat}
java.lang.AssertionError: According to the JRaft protocol, ECATCHUP is expected
at
org.apache.ignite.internal.table.distributed.raft.RebalanceRaftGroupEventsListener.onReconfigurationError(RebalanceRaftGroupEventsListener.java:205)
at
java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
at
org.apache.ignite.internal.table.distributed.raft.RebalanceRaftGroupEventsListener.onReconfigurationError(RebalanceRaftGroupEventsListener.java:189)
at
org.apache.ignite.raft.jraft.core.NodeImpl$ConfigurationCtx.lambda$reset$0(NodeImpl.java:453)
at org.apache.ignite.raft.jraft.util.Utils$1.run(Utils.java:161)
at
org.apache.ignite.internal.testframework.util.DirectExecutor.submit(DirectExecutor.java:68)
at org.apache.ignite.raft.jraft.util.Utils.runInThread(Utils.java:131)
at
org.apache.ignite.raft.jraft.util.Utils.runClosureInThread(Utils.java:158)
at
org.apache.ignite.raft.jraft.core.NodeImpl$ConfigurationCtx.reset(NodeImpl.java:459)
{noformat}
was:
{noformat}
java.lang.AssertionError: According to the JRaft protocol, ECATCHUP is expected
at
org.apache.ignite.internal.table.distributed.raft.RebalanceRaftGroupEventsListener.onReconfigurationError(RebalanceRaftGroupEventsListener.java:205)
at
java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
at
org.apache.ignite.internal.table.distributed.raft.RebalanceRaftGroupEventsListener.onReconfigurationError(RebalanceRaftGroupEventsListener.java:189)
at
org.apache.ignite.raft.jraft.core.NodeImpl$ConfigurationCtx.lambda$reset$0(NodeImpl.java:453)
at org.apache.ignite.raft.jraft.util.Utils$1.run(Utils.java:161)
at
org.apache.ignite.internal.testframework.util.DirectExecutor.submit(DirectExecutor.java:68)
at org.apache.ignite.raft.jraft.util.Utils.runInThread(Utils.java:131)
at
org.apache.ignite.raft.jraft.util.Utils.runClosureInThread(Utils.java:158)
at
org.apache.ignite.raft.jraft.core.NodeImpl$ConfigurationCtx.reset(NodeImpl.java:459)
{noformat}
> AssertionError "According to the JRaft protocol ECATCHUP is expected" is
> thrown on reconfiguration error
>
>
> Key: IGNITE-17574
> URL: https://issues.apache.org/jira/browse/IGNITE-17574
> Project: Ignite
> Issue Type: Bug
>Reporter: Semyon Danilov
>Assignee: Semyon Danilov
>Priority: Major
> Labels: ignite-3
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {noformat}
> java.lang.AssertionError: According to the JRaft protocol, ECATCHUP is
> expected
> at
> org.apache.ignite.internal.table.distributed.raft.RebalanceRaftGroupEventsListener.onReconfigurationError(RebalanceRaftGroupEventsListener.java:205)
> at
> java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
> at
> org.apache.ignite.internal.table.distributed.raft.RebalanceRaftGroupEventsListener.onReconfigurationError(RebalanceRaftGroupEventsListener.java:189)
> at
> org.apache.ignite.raft.jraft.core.NodeImpl$ConfigurationCtx.lambda$reset$0(NodeImpl.java:453)
> at org.apache.ignite.raft.jraft.util.Utils$1.run(Utils.java:161)
> at
> org.apache.ignite.internal.testframework.util.DirectExecutor.submit(DirectExecutor.java:68)
> at org.apache.ignite.raft.jraft.util.Utils.runInThread(Utils.java:131)
> at
> org.apache.ignite.raft.jraft.util.Utils.runClosureInThread(Utils.java:158)
> at
> org.apache.ignite.raft.jraft.core.NodeImpl$ConfigurationCtx.reset(NodeImpl.java:459)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17574) AssertionError "According to the JRaft protocol ECATCHUP is expected" is thrown on reconfiguration error
[
https://issues.apache.org/jira/browse/IGNITE-17574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17584980#comment-17584980
]
Roman Puchkovskiy commented on IGNITE-17574:
The patch looks good to me
> AssertionError "According to the JRaft protocol ECATCHUP is expected" is
> thrown on reconfiguration error
>
>
> Key: IGNITE-17574
> URL: https://issues.apache.org/jira/browse/IGNITE-17574
> Project: Ignite
> Issue Type: Bug
>Reporter: Semyon Danilov
>Assignee: Semyon Danilov
>Priority: Major
> Labels: ignite-3
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {noformat}
> java.lang.AssertionError: According to the JRaft protocol, ECATCHUP is
> expected
> at
> org.apache.ignite.internal.table.distributed.raft.RebalanceRaftGroupEventsListener.onReconfigurationError(RebalanceRaftGroupEventsListener.java:205)
> at
> java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
> at
> org.apache.ignite.internal.table.distributed.raft.RebalanceRaftGroupEventsListener.onReconfigurationError(RebalanceRaftGroupEventsListener.java:189)
> at
> org.apache.ignite.raft.jraft.core.NodeImpl$ConfigurationCtx.lambda$reset$0(NodeImpl.java:453)
> at org.apache.ignite.raft.jraft.util.Utils$1.run(Utils.java:161)
> at
> org.apache.ignite.internal.testframework.util.DirectExecutor.submit(DirectExecutor.java:68)
> at org.apache.ignite.raft.jraft.util.Utils.runInThread(Utils.java:131)
> at
> org.apache.ignite.raft.jraft.util.Utils.runClosureInThread(Utils.java:158)
> at
> org.apache.ignite.raft.jraft.core.NodeImpl$ConfigurationCtx.reset(NodeImpl.java:459)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17112) Consistency check must fix counter after the consistency fix
[
https://issues.apache.org/jira/browse/IGNITE-17112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-17112:
--
Release Note: Consistency check now able to fix counters after the
consistency fix
> Consistency check must fix counter after the consistency fix
>
>
> Key: IGNITE-17112
> URL: https://issues.apache.org/jira/browse/IGNITE-17112
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31, ise
> Fix For: 2.14
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Consistency repair repairs the consistency for the data committed on at least
> single node.
> But partition counter may have gaps for prepared, but not committed data, and
> such gaps will cause exception on cluster activation:
> {noformat}
> 2022-06-03 22:01:59.695
> [ERROR][sys-#322][org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager]
> Failed to update partition counter. Most probably a node with most actual
> data is out of topology or data streamer is used in preload mode
> (allowOverride=false) concurrently with cache transactions [grpName=XXX,
> partId=9099]
> org.apache.ignite.IgniteCheckedException: Failed to update the counter
> [newVal=4854911, curState=Counter [lwm=4854911, holes={4854912=Item
> [start=4854912, delta=1]}, maxApplied=4854913, hwm=4854911]]
> at
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl.update(PartitionUpdateCounterTrackingImpl.java:153)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterErrorWrapper.update(PartitionUpdateCounterErrorWrapper.java:97)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateCounter(IgniteCacheOffheapManagerImpl.java:1687)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.updateCounter(GridCacheOffheapManager.java:2530)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.updateCounter(GridDhtLocalPartition.java:913)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.update(GridDhtPartitionTopologyImpl.java:1491)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.lambda$updatePartitionFullMap$81bdb8e8$1(GridDhtPartitionsExchangeFuture.java:4817)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at
> org.apache.ignite.internal.util.IgniteUtils.lambda$null$1(IgniteUtils.java:11358)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [?:1.8.0_322]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [?:1.8.0_322]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [?:1.8.0_322]
> at java.lang.Thread.run(Thread.java:750)
> {noformat}
> Consistency check via cli must close this gaps on successful consistency
> repair.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17577) Refactor MVPartitionStorage together with corresponding implementation in order to use HybridTimestamp instead of Timestamp
Alexander Lapin created IGNITE-17577: Summary: Refactor MVPartitionStorage together with corresponding implementation in order to use HybridTimestamp instead of Timestamp Key: IGNITE-17577 URL: https://issues.apache.org/jira/browse/IGNITE-17577 Project: Ignite Issue Type: Improvement Reporter: Alexander Lapin As a starting point in order to satisfy tx protocol it's required to rework MVPartitionStorage and corresponding implementation with HybridTimestamp instead of Timestamp. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17191) Consistency check should support cacheGroup as a param as well
[ https://issues.apache.org/jira/browse/IGNITE-17191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-17191: -- Release Note: Consistency check now support cacheGroup as a param as well > Consistency check should support cacheGroup as a param as well > -- > > Key: IGNITE-17191 > URL: https://issues.apache.org/jira/browse/IGNITE-17191 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-31 > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > Both cache and cacheGroup should be supported at --cache param -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17191) Consistency check should support cacheGroup as a param as well
[ https://issues.apache.org/jira/browse/IGNITE-17191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-17191: -- Fix Version/s: 2.14 > Consistency check should support cacheGroup as a param as well > -- > > Key: IGNITE-17191 > URL: https://issues.apache.org/jira/browse/IGNITE-17191 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-31 > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > Both cache and cacheGroup should be supported at --cache param -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17112) Consistency check must fix counter after the consistency fix
[
https://issues.apache.org/jira/browse/IGNITE-17112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17584910#comment-17584910
]
Anton Vinogradov commented on IGNITE-17112:
---
[~mmuzaf], thanks for the review!
Merged to the master.
> Consistency check must fix counter after the consistency fix
>
>
> Key: IGNITE-17112
> URL: https://issues.apache.org/jira/browse/IGNITE-17112
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31, ise
> Fix For: 2.14
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Consistency repair repairs the consistency for the data committed on at least
> single node.
> But partition counter may have gaps for prepared, but not committed data, and
> such gaps will cause exception on cluster activation:
> {noformat}
> 2022-06-03 22:01:59.695
> [ERROR][sys-#322][org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager]
> Failed to update partition counter. Most probably a node with most actual
> data is out of topology or data streamer is used in preload mode
> (allowOverride=false) concurrently with cache transactions [grpName=XXX,
> partId=9099]
> org.apache.ignite.IgniteCheckedException: Failed to update the counter
> [newVal=4854911, curState=Counter [lwm=4854911, holes={4854912=Item
> [start=4854912, delta=1]}, maxApplied=4854913, hwm=4854911]]
> at
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl.update(PartitionUpdateCounterTrackingImpl.java:153)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterErrorWrapper.update(PartitionUpdateCounterErrorWrapper.java:97)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateCounter(IgniteCacheOffheapManagerImpl.java:1687)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.updateCounter(GridCacheOffheapManager.java:2530)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.updateCounter(GridDhtLocalPartition.java:913)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.update(GridDhtPartitionTopologyImpl.java:1491)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.lambda$updatePartitionFullMap$81bdb8e8$1(GridDhtPartitionsExchangeFuture.java:4817)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at
> org.apache.ignite.internal.util.IgniteUtils.lambda$null$1(IgniteUtils.java:11358)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [?:1.8.0_322]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [?:1.8.0_322]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [?:1.8.0_322]
> at java.lang.Thread.run(Thread.java:750)
> {noformat}
> Consistency check via cli must close this gaps on successful consistency
> repair.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17537) Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
[
https://issues.apache.org/jira/browse/IGNITE-17537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina updated IGNITE-17537:
Flags: (was: Patch)
> Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
> --
>
> Key: IGNITE-17537
> URL: https://issues.apache.org/jira/browse/IGNITE-17537
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Trivial
> Labels: ise, newbie
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Execution of {{control.sh --tx}} command produces output of matching
> transactions, eg.:
> {quote}Matching transactions:
> Tx: [xid=fdc4d720281--0fd8-0177--0012, label=null,
> state=ACTIVE, startTime=2022-07-06 05:05:07.432,
> {*}{color:#ff}duration=778{color}{*}, isolation=REPEATABLE_READ,
> concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=199,
> minorTopVer=0], {*}{color:#ff}timeout=4{color}{*}, ...]
> {quote}
> But, from the above line it is unclear, that in fact, duration is printed in
> seconds [1], while timeout is printed in milliseconds.
> We can improve output in one of the following ways:
> # Explicitly append unit for seconds and milliseconds.
> # Print duration and timeout in same units: both in seconds or both in
> milliseconds.
> Links:
> #
> https://github.com/apache/ignite/blob/bf9a460eccd07701cacac2a414c65707243350f1/modules/core/src/main/java/org/apache/ignite/internal/visor/tx/VisorTxInfo.java#L286
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17537) Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
[
https://issues.apache.org/jira/browse/IGNITE-17537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina updated IGNITE-17537:
Flags: Patch
> Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
> --
>
> Key: IGNITE-17537
> URL: https://issues.apache.org/jira/browse/IGNITE-17537
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Trivial
> Labels: ise, newbie
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Execution of {{control.sh --tx}} command produces output of matching
> transactions, eg.:
> {quote}Matching transactions:
> Tx: [xid=fdc4d720281--0fd8-0177--0012, label=null,
> state=ACTIVE, startTime=2022-07-06 05:05:07.432,
> {*}{color:#ff}duration=778{color}{*}, isolation=REPEATABLE_READ,
> concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=199,
> minorTopVer=0], {*}{color:#ff}timeout=4{color}{*}, ...]
> {quote}
> But, from the above line it is unclear, that in fact, duration is printed in
> seconds [1], while timeout is printed in milliseconds.
> We can improve output in one of the following ways:
> # Explicitly append unit for seconds and milliseconds.
> # Print duration and timeout in same units: both in seconds or both in
> milliseconds.
> Links:
> #
> https://github.com/apache/ignite/blob/bf9a460eccd07701cacac2a414c65707243350f1/modules/core/src/main/java/org/apache/ignite/internal/visor/tx/VisorTxInfo.java#L286
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17576) Update Ignite dependency: MySQL Connector
[ https://issues.apache.org/jira/browse/IGNITE-17576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-17576: Ignite Flags: (was: Docs Required,Release Notes Required) > Update Ignite dependency: MySQL Connector > - > > Key: IGNITE-17576 > URL: https://issues.apache.org/jira/browse/IGNITE-17576 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Major > Labels: newbie > > Update Ignite dependency: MySQL Connector 8.0.26 to 8.0.30 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17576) Update Ignite dependency: MySQL Connector
[ https://issues.apache.org/jira/browse/IGNITE-17576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-17576: Ignite Flags: Docs Required,Release Notes Required > Update Ignite dependency: MySQL Connector > - > > Key: IGNITE-17576 > URL: https://issues.apache.org/jira/browse/IGNITE-17576 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Major > Labels: newbie > > Update Ignite dependency: MySQL Connector 8.0.26 to 8.0.30 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17576) Update Ignite dependency: MySQL Connector
[ https://issues.apache.org/jira/browse/IGNITE-17576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-17576: External issue URL: (was: https://github.com/apache/ignite/pull/9385) Ignite Flags: (was: Docs Required,Release Notes Required) Labels: newbie (was: ) > Update Ignite dependency: MySQL Connector > - > > Key: IGNITE-17576 > URL: https://issues.apache.org/jira/browse/IGNITE-17576 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Major > Labels: newbie > > Update Ignite dependency: MySQL Connector 8.0.26 to 8.0.30 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17576) Update Ignite dependency: MySQL Connector
Julia Bakulina created IGNITE-17576: --- Summary: Update Ignite dependency: MySQL Connector Key: IGNITE-17576 URL: https://issues.apache.org/jira/browse/IGNITE-17576 Project: Ignite Issue Type: Improvement Reporter: Julia Bakulina Assignee: Julia Bakulina Update Ignite dependency: MySQL Connector 8.0.26 to 8.0.30 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17317) Test IgnitePdsBinaryMetadataAsyncWritingTest.testNodeIsStoppedOnExceptionDuringStoringMetadata is flaky on TC
[
https://issues.apache.org/jira/browse/IGNITE-17317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17584835#comment-17584835
]
Sergey Chugunov commented on IGNITE-17317:
--
[~tledkov], I reset both flags. The ticket is really minor, doesn't deserve to
be mentioned in RNs or docs.
> Test
> IgnitePdsBinaryMetadataAsyncWritingTest.testNodeIsStoppedOnExceptionDuringStoringMetadata
> is flaky on TC
> -
>
> Key: IGNITE-17317
> URL: https://issues.apache.org/jira/browse/IGNITE-17317
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Test history is available here: [TC
> link|https://ci.ignite.apache.org/test/-1717009344468901983?currentProjectId=IgniteTests24Java8=%3Cdefault%3E]
> Test fails on a cache put operation before a condition being verified is
> reached:
> {code:java}
> org.apache.ignite.cache.CachePartialUpdateException: Failed to update keys
> (retry update if possible).: [2]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1260)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:2111)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1347)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:870)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgnitePdsBinaryMetadataAsyncWritingTest.testNodeIsStoppedOnExceptionDuringStoringMetadata(IgnitePdsBinaryMetadataAsyncWritingTest.java:257)
> {code}
> There is also a stack trace in logs indicating there is some problem when
> writing to WAL:
> {code:java}
> org.apache.ignite.cache.CachePartialUpdateException: Failed to update keys
> (retry update if possible).: [2]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1260)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:2111)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1347)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:870)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgnitePdsBinaryMetadataAsyncWritingTest.testNodeIsStoppedOnExceptionDuringStoringMetadata(IgnitePdsBinaryMetadataAsyncWritingTest.java:257)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2428)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: class
> org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException:
> Failed to update keys (retry update if possible).: [2]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:401)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.onPrimaryResponse(GridNearAtomicSingleUpdateFuture.java:248)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateResponse(GridDhtAtomicCache.java:3213)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$500(GridDhtAtomicCache.java:145)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:305)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:300)
> at
>
[jira] [Updated] (IGNITE-17317) Test IgnitePdsBinaryMetadataAsyncWritingTest.testNodeIsStoppedOnExceptionDuringStoringMetadata is flaky on TC
[
https://issues.apache.org/jira/browse/IGNITE-17317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Chugunov updated IGNITE-17317:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Test
> IgnitePdsBinaryMetadataAsyncWritingTest.testNodeIsStoppedOnExceptionDuringStoringMetadata
> is flaky on TC
> -
>
> Key: IGNITE-17317
> URL: https://issues.apache.org/jira/browse/IGNITE-17317
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Test history is available here: [TC
> link|https://ci.ignite.apache.org/test/-1717009344468901983?currentProjectId=IgniteTests24Java8=%3Cdefault%3E]
> Test fails on a cache put operation before a condition being verified is
> reached:
> {code:java}
> org.apache.ignite.cache.CachePartialUpdateException: Failed to update keys
> (retry update if possible).: [2]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1260)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:2111)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1347)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:870)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgnitePdsBinaryMetadataAsyncWritingTest.testNodeIsStoppedOnExceptionDuringStoringMetadata(IgnitePdsBinaryMetadataAsyncWritingTest.java:257)
> {code}
> There is also a stack trace in logs indicating there is some problem when
> writing to WAL:
> {code:java}
> org.apache.ignite.cache.CachePartialUpdateException: Failed to update keys
> (retry update if possible).: [2]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1260)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:2111)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1347)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:870)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgnitePdsBinaryMetadataAsyncWritingTest.testNodeIsStoppedOnExceptionDuringStoringMetadata(IgnitePdsBinaryMetadataAsyncWritingTest.java:257)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2428)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: class
> org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException:
> Failed to update keys (retry update if possible).: [2]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:401)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.onPrimaryResponse(GridNearAtomicSingleUpdateFuture.java:248)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateResponse(GridDhtAtomicCache.java:3213)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$500(GridDhtAtomicCache.java:145)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:305)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:300)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1151)
> at
>
[jira] [Commented] (IGNITE-17317) Test IgnitePdsBinaryMetadataAsyncWritingTest.testNodeIsStoppedOnExceptionDuringStoringMetadata is flaky on TC
[
https://issues.apache.org/jira/browse/IGNITE-17317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17584811#comment-17584811
]
Taras Ledkov commented on IGNITE-17317:
---
[~sergeychugunov], are release notes really required for this issue? Please add
notes or reset the flag.
> Test
> IgnitePdsBinaryMetadataAsyncWritingTest.testNodeIsStoppedOnExceptionDuringStoringMetadata
> is flaky on TC
> -
>
> Key: IGNITE-17317
> URL: https://issues.apache.org/jira/browse/IGNITE-17317
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Test history is available here: [TC
> link|https://ci.ignite.apache.org/test/-1717009344468901983?currentProjectId=IgniteTests24Java8=%3Cdefault%3E]
> Test fails on a cache put operation before a condition being verified is
> reached:
> {code:java}
> org.apache.ignite.cache.CachePartialUpdateException: Failed to update keys
> (retry update if possible).: [2]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1260)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:2111)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1347)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:870)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgnitePdsBinaryMetadataAsyncWritingTest.testNodeIsStoppedOnExceptionDuringStoringMetadata(IgnitePdsBinaryMetadataAsyncWritingTest.java:257)
> {code}
> There is also a stack trace in logs indicating there is some problem when
> writing to WAL:
> {code:java}
> org.apache.ignite.cache.CachePartialUpdateException: Failed to update keys
> (retry update if possible).: [2]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1260)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:2111)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1347)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:870)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgnitePdsBinaryMetadataAsyncWritingTest.testNodeIsStoppedOnExceptionDuringStoringMetadata(IgnitePdsBinaryMetadataAsyncWritingTest.java:257)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2428)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: class
> org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException:
> Failed to update keys (retry update if possible).: [2]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:401)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.onPrimaryResponse(GridNearAtomicSingleUpdateFuture.java:248)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateResponse(GridDhtAtomicCache.java:3213)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$500(GridDhtAtomicCache.java:145)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:305)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:300)
> at
>
[jira] [Commented] (IGNITE-17433) SQL API: When cursor is closed, internal exception is thrown from fetchNextPage
[ https://issues.apache.org/jira/browse/IGNITE-17433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17584809#comment-17584809 ] Pavel Tupitsyn commented on IGNITE-17433: - [~tledkov] thanks, my bad. > SQL API: When cursor is closed, internal exception is thrown from > fetchNextPage > --- > > Key: IGNITE-17433 > URL: https://issues.apache.org/jira/browse/IGNITE-17433 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > * Introduce error code for closed cursor scenario > * Fix client side to throw the same exception too > * Add shared tests to ItSqlAsynchronousApiTest, ItSqlSynchronousApiTest -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17433) SQL API: When cursor is closed, internal exception is thrown from fetchNextPage
[ https://issues.apache.org/jira/browse/IGNITE-17433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17433: Fix Version/s: 3.0.0-alpha6 > SQL API: When cursor is closed, internal exception is thrown from > fetchNextPage > --- > > Key: IGNITE-17433 > URL: https://issues.apache.org/jira/browse/IGNITE-17433 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > Time Spent: 0.5h > Remaining Estimate: 0h > > * Introduce error code for closed cursor scenario > * Fix client side to throw the same exception too > * Add shared tests to ItSqlAsynchronousApiTest, ItSqlSynchronousApiTest -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17556) Ignite doc: Wrong use of setValueFields function in CacheJdbcPojoStore demo
[
https://issues.apache.org/jira/browse/IGNITE-17556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-17556:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Ignite doc: Wrong use of setValueFields function in CacheJdbcPojoStore demo
> ---
>
> Key: IGNITE-17556
> URL: https://issues.apache.org/jira/browse/IGNITE-17556
> Project: Ignite
> Issue Type: Bug
> Components: documentation
>Affects Versions: 2.13
>Reporter: YuJue Li
>Assignee: YuJue Li
>Priority: Trivial
> Fix For: 2.14
>
> Attachments:
> 0001-IGNITE-17556-Ignite-doc-Wrong-use-of-setValueFields-.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The following page of documentation provides an example of configuring
> CacheJdbcPojoStore
> https://ignite.apache.org/docs/latest/persistence/external-storage#cachejdbcpojostore
> In particular, it suggest to set value fields as follows:
> {code:java}
> ...
> personType.setValueFields(new JdbcTypeField(java.sql.Types.INTEGER, "id",
> Integer.class, "id"));
> personType.setValueFields(new JdbcTypeField(java.sql.Types.VARCHAR,
> "name", String.class, "name"));
> ...
> {code}
> The code above looks incorrect just because the second method call will be
> taken into account and overrides the previous one.
> The example should be corrected:
> {code:java}
> ...
> personType.setValueFields(
> new JdbcTypeField(java.sql.Types.INTEGER, "id", Integer.class, "id"),
> new JdbcTypeField(java.sql.Types.VARCHAR, "name", String.class,
> "name"));
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17556) Ignite doc: Wrong use of setValueFields function in CacheJdbcPojoStore demo
[
https://issues.apache.org/jira/browse/IGNITE-17556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-17556:
-
Reviewer: Vyacheslav Koptilin
> Ignite doc: Wrong use of setValueFields function in CacheJdbcPojoStore demo
> ---
>
> Key: IGNITE-17556
> URL: https://issues.apache.org/jira/browse/IGNITE-17556
> Project: Ignite
> Issue Type: Bug
> Components: documentation
>Affects Versions: 2.13
>Reporter: YuJue Li
>Assignee: YuJue Li
>Priority: Trivial
> Fix For: 2.14
>
> Attachments:
> 0001-IGNITE-17556-Ignite-doc-Wrong-use-of-setValueFields-.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The following page of documentation provides an example of configuring
> CacheJdbcPojoStore
> https://ignite.apache.org/docs/latest/persistence/external-storage#cachejdbcpojostore
> In particular, it suggest to set value fields as follows:
> {code:java}
> ...
> personType.setValueFields(new JdbcTypeField(java.sql.Types.INTEGER, "id",
> Integer.class, "id"));
> personType.setValueFields(new JdbcTypeField(java.sql.Types.VARCHAR,
> "name", String.class, "name"));
> ...
> {code}
> The code above looks incorrect just because the second method call will be
> taken into account and overrides the previous one.
> The example should be corrected:
> {code:java}
> ...
> personType.setValueFields(
> new JdbcTypeField(java.sql.Types.INTEGER, "id", Integer.class, "id"),
> new JdbcTypeField(java.sql.Types.VARCHAR, "name", String.class,
> "name"));
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-15620) Calcite. Support for ARRAY_AGG function.
[
https://issues.apache.org/jira/browse/IGNITE-15620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov resolved IGNITE-15620.
---
Release Note: Change resolution to duplicate.
Resolution: Duplicate
> Calcite. Support for ARRAY_AGG function.
>
>
> Key: IGNITE-15620
> URL: https://issues.apache.org/jira/browse/IGNITE-15620
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required, ignite-3
> Fix For: 2.14
>
>
> This function already implemented in
> [CALCITE-4335|https://issues.apache.org/jira/browse/CALCITE-4335]. Need
> support it locally.
> Affected tests:
> {{src/test/sql/types/list/array_agg.test_ignored}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17556) Ignite doc: Wrong use of setValueFields function in CacheJdbcPojoStore demo
[
https://issues.apache.org/jira/browse/IGNITE-17556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-17556:
-
Description:
The following page of documentation provides an example of configuring
CacheJdbcPojoStore
https://ignite.apache.org/docs/latest/persistence/external-storage#cachejdbcpojostore
In particular, it suggest to set value fields as follows:
{code:java}
...
personType.setValueFields(new JdbcTypeField(java.sql.Types.INTEGER, "id",
Integer.class, "id"));
personType.setValueFields(new JdbcTypeField(java.sql.Types.VARCHAR, "name",
String.class, "name"));
...
{code}
The code above looks incorrect just because the second method call will be
taken into account and overrides the previous one.
The example should be corrected:
{code:java}
...
personType.setValueFields(
new JdbcTypeField(java.sql.Types.INTEGER, "id", Integer.class, "id"),
new JdbcTypeField(java.sql.Types.VARCHAR, "name", String.class,
"name"));
...
{code}
was:
The following page of documentation provides an example of configuring
CacheJdbcPojoStore
https://ignite.apache.org/docs/latest/persistence/external-storage#cachejdbcpojostore
In particular, it suggest to set value fields as follows:
{code:java}
...
personType.setValueFields(new JdbcTypeField(java.sql.Types.INTEGER, "id",
Integer.class, "id"));
personType.setValueFields(new JdbcTypeField(java.sql.Types.VARCHAR, "name",
String.class, "name"));
...
{code}
The code above looks incorrect just because the second method call will be
taken into account and overrides the previous one.
The example should be corrected:
{code:java}
...
personType.setValueFields(
new JdbcTypeField(java.sql.Types.INTEGER, "id", Integer.class, "id"),
new JdbcTypeField(java.sql.Types.VARCHAR, "name", String.class,
"name"));
...
> Ignite doc: Wrong use of setValueFields function in CacheJdbcPojoStore demo
> ---
>
> Key: IGNITE-17556
> URL: https://issues.apache.org/jira/browse/IGNITE-17556
> Project: Ignite
> Issue Type: Bug
> Components: documentation
>Affects Versions: 2.13
>Reporter: YuJue Li
>Assignee: YuJue Li
>Priority: Trivial
> Fix For: 2.14
>
> Attachments:
> 0001-IGNITE-17556-Ignite-doc-Wrong-use-of-setValueFields-.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The following page of documentation provides an example of configuring
> CacheJdbcPojoStore
> https://ignite.apache.org/docs/latest/persistence/external-storage#cachejdbcpojostore
> In particular, it suggest to set value fields as follows:
> {code:java}
> ...
> personType.setValueFields(new JdbcTypeField(java.sql.Types.INTEGER, "id",
> Integer.class, "id"));
> personType.setValueFields(new JdbcTypeField(java.sql.Types.VARCHAR,
> "name", String.class, "name"));
> ...
> {code}
> The code above looks incorrect just because the second method call will be
> taken into account and overrides the previous one.
> The example should be corrected:
> {code:java}
> ...
> personType.setValueFields(
> new JdbcTypeField(java.sql.Types.INTEGER, "id", Integer.class, "id"),
> new JdbcTypeField(java.sql.Types.VARCHAR, "name", String.class,
> "name"));
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (IGNITE-15620) Calcite. Support for ARRAY_AGG function.
[
https://issues.apache.org/jira/browse/IGNITE-15620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov reopened IGNITE-15620:
---
> Calcite. Support for ARRAY_AGG function.
>
>
> Key: IGNITE-15620
> URL: https://issues.apache.org/jira/browse/IGNITE-15620
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required, ignite-3
> Fix For: 2.14
>
>
> This function already implemented in
> [CALCITE-4335|https://issues.apache.org/jira/browse/CALCITE-4335]. Need
> support it locally.
> Affected tests:
> {{src/test/sql/types/list/array_agg.test_ignored}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17556) Ignite doc: Wrong use of setValueFields function in CacheJdbcPojoStore demo
[
https://issues.apache.org/jira/browse/IGNITE-17556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-17556:
-
Description:
The following page of documentation provides an example of configuring
CacheJdbcPojoStore
https://ignite.apache.org/docs/latest/persistence/external-storage#cachejdbcpojostore
In particular, it suggest to set value fields as follows:
{code:java}
...
personType.setValueFields(new JdbcTypeField(java.sql.Types.INTEGER, "id",
Integer.class, "id"));
personType.setValueFields(new JdbcTypeField(java.sql.Types.VARCHAR, "name",
String.class, "name"));
...
{code}
The code above looks incorrect just because the second method call will be
taken into account and overrides the previous one.
The example should be corrected:
{code:java}
...
personType.setValueFields(
new JdbcTypeField(java.sql.Types.INTEGER, "id", Integer.class, "id"),
new JdbcTypeField(java.sql.Types.VARCHAR, "name", String.class,
"name"));
...
was:https://ignite.apache.org/docs/latest/persistence/external-storage#
> Ignite doc: Wrong use of setValueFields function in CacheJdbcPojoStore demo
> ---
>
> Key: IGNITE-17556
> URL: https://issues.apache.org/jira/browse/IGNITE-17556
> Project: Ignite
> Issue Type: Bug
> Components: documentation
>Affects Versions: 2.13
>Reporter: YuJue Li
>Assignee: YuJue Li
>Priority: Trivial
> Fix For: 2.14
>
> Attachments:
> 0001-IGNITE-17556-Ignite-doc-Wrong-use-of-setValueFields-.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The following page of documentation provides an example of configuring
> CacheJdbcPojoStore
> https://ignite.apache.org/docs/latest/persistence/external-storage#cachejdbcpojostore
> In particular, it suggest to set value fields as follows:
> {code:java}
> ...
> personType.setValueFields(new JdbcTypeField(java.sql.Types.INTEGER, "id",
> Integer.class, "id"));
> personType.setValueFields(new JdbcTypeField(java.sql.Types.VARCHAR,
> "name", String.class, "name"));
> ...
> {code}
> The code above looks incorrect just because the second method call will be
> taken into account and overrides the previous one.
> The example should be corrected:
> {code:java}
> ...
> personType.setValueFields(
> new JdbcTypeField(java.sql.Types.INTEGER, "id", Integer.class, "id"),
> new JdbcTypeField(java.sql.Types.VARCHAR, "name", String.class,
> "name"));
> ...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17433) SQL API: When cursor is closed, internal exception is thrown from fetchNextPage
[ https://issues.apache.org/jira/browse/IGNITE-17433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17584783#comment-17584783 ] Taras Ledkov commented on IGNITE-17433: --- [~ptupitsyn], I've removed 2.14 fix version. Please specify appropriate version number for ignite-3. > SQL API: When cursor is closed, internal exception is thrown from > fetchNextPage > --- > > Key: IGNITE-17433 > URL: https://issues.apache.org/jira/browse/IGNITE-17433 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > * Introduce error code for closed cursor scenario > * Fix client side to throw the same exception too > * Add shared tests to ItSqlAsynchronousApiTest, ItSqlSynchronousApiTest -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17433) SQL API: When cursor is closed, internal exception is thrown from fetchNextPage
[ https://issues.apache.org/jira/browse/IGNITE-17433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-17433: -- Fix Version/s: (was: 2.14) > SQL API: When cursor is closed, internal exception is thrown from > fetchNextPage > --- > > Key: IGNITE-17433 > URL: https://issues.apache.org/jira/browse/IGNITE-17433 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > * Introduce error code for closed cursor scenario > * Fix client side to throw the same exception too > * Add shared tests to ItSqlAsynchronousApiTest, ItSqlSynchronousApiTest -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16806) Cache put/SQL table insert fails if SQL index created and LocalDateTime is used as value.
[
https://issues.apache.org/jira/browse/IGNITE-16806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-16806:
Release Note: Fixed insertion of values with java LocalDate, LocalTime and
LocalDateTime types via SQL. (was: Fixed insertion of values with java
LocalDate, LocalTime and LocalDateTime types in SQL table.)
> Cache put/SQL table insert fails if SQL index created and LocalDateTime is
> used as value.
> -
>
> Key: IGNITE-16806
> URL: https://issues.apache.org/jira/browse/IGNITE-16806
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: ise.lts
> Fix For: 2.14
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Reproducer:
> {code:java}
> /** */
> public class LocalDateIndexTest extends AbstractIndexingCommonTest {
> /** */
> @Test
> public void test() throws Exception {
> IgniteEx ignite = startGrids(2);
> SqlFieldsQuery qry = new SqlFieldsQuery(
> "CREATE TABLE DATA (STR VARCHAR PRIMARY KEY, LOCDATETIME
> TIMESTAMP) WITH" +
> " \"KEY_TYPE=java.lang.String" +
> ",
> VALUE_TYPE=org.apache.ignite.internal.processors.query.LocalDateIndexTest$Data"
> +
> ", CACHE_NAME=" + DEFAULT_CACHE_NAME + "\"");
> ignite.context().query().querySqlFields(qry, false).getAll();
> qry = new SqlFieldsQuery("CREATE INDEX TEST_IDX ON DATA(LOCDATETIME
> DESC);");
> ignite.context().query().querySqlFields(qry, false).getAll();
> //ignite.cache(DEFAULT_CACHE_NAME).put("0", new Data("0",
> LocalDateTime.MAX));
> qry = new SqlFieldsQuery("INSERT INTO DATA(_key, str, locDateTime)
> values(?, ?, ?)").setArgs("0", "0", LocalDateTime.MAX);
> ignite.context().query().querySqlFields(qry, false).getAll();
> }
> public static class Data implements Serializable {
> /** Serial version UID. */
> private static final long serialVersionUID = 1L;
> /** */
> public String str;
> /** */
> public LocalDateTime locDateTime;
> /** */
> public Data(String str, LocalDateTime locDateTime) {
> this.str = str;
> this.locDateTime = locDateTime;
> }
> }
> }
> {code}
> Exception:
> {code:java}
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Type
> for a column 'LOCDATETIME' is not compatible with index definition. Expected
> 'Timestamp', actual type 'LocalDateTime'
> at
> org.apache.ignite.internal.processors.query.QueryTypeDescriptorImpl.validateIndexes(QueryTypeDescriptorImpl.java:735)
> at
> org.apache.ignite.internal.processors.query.QueryTypeDescriptorImpl.validateKeyAndValue(QueryTypeDescriptorImpl.java:606)
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlan.processRow(UpdatePlan.java:295)
> at
> org.apache.ignite.internal.processors.query.h2.dml.DmlUtils.dmlDoInsert(DmlUtils.java:212)
> at
> org.apache.ignite.internal.processors.query.h2.dml.DmlUtils.processSelectResult(DmlUtils.java:185)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdateNonTransactional(IgniteH2Indexing.java:2902)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdate(IgniteH2Indexing.java:2747)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdateDistributed(IgniteH2Indexing.java:2673)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeDml(IgniteH2Indexing.java:1263)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1185)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:3005)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:2988)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:3650)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$3(GridQueryProcessor.java:3022)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:3094)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2982)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2909)
> at
>
[jira] [Assigned] (IGNITE-17481) Ignite shutdown sequence throws a ClassCastException from inside GridManagerAdapter on latest Java 11.0.16 and 17.0.4 point releases
[
https://issues.apache.org/jira/browse/IGNITE-17481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov reassigned IGNITE-17481:
--
Assignee: Ivan Bessonov
> Ignite shutdown sequence throws a ClassCastException from inside
> GridManagerAdapter on latest Java 11.0.16 and 17.0.4 point releases
>
>
> Key: IGNITE-17481
> URL: https://issues.apache.org/jira/browse/IGNITE-17481
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 2.7, 2.8, 2.9, 2.10,
> 2.12, 2.13
>Reporter: Paolo de Dios
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.15
>
>
>
> {{When ClassLoaders are undeployed, the
> `GridDeploymentStoreAdapter.clearSerializationCache()` method attempts to
> clear serialization caches to avoid PermGen memory leaks. The implementation
> of this optimization seems to no longer work as the underlying JVM
> implementaiton of `java.io.ObjectInputStream$Caches` and
> java.io.ObjectOutputStream$Caches` no longer maintain a private cache of
> subclass security audit results as a java.util.Map, which Ignite expects
> inside
> `[GridDeploymentStoreAdapter.clearSerializationCache()|https://github.com/apache/ignite/blob/da8a6bb4756c998aa99494d395752be96d841ec8/modules/core/src/main/java/org/apache/ignite/internal/managers/deployment/GridDeploymentStoreAdapter.java#L151]`.}}
>
> *Stacktrace*
>
> {code:java}
> [INFO ] 2022-08-06T20:28:04,778+ T=[vert.x-eventloop-thread-4]
> L=[GridDeploymentLocalStore] - Removed undeployed class: GridDeployment
> [ts=1659817673460, depMode=SHARED,
> clsLdr=jdk.internal.loader.ClassLoaders$AppClassLoader@277050dc,
> clsLdrId=b2497d47281-7ff6d972-ec5d-4d9c-bc60-95463b5e10b6, userVer=0,
> loc=true,
> sampleClsName=org.apache.ignite.internal.processors.cache.distributed.dht.preloader.IgniteDhtPartitionHistorySuppliersMap,
> pendingUndeploy=false, undeployed=true, usage=0]
> [ERROR] 2022-08-06T20:28:04,778+ T=[vert.x-eventloop-thread-4] L=[local]
> - Failed to stop component (ignoring): GridManagerAdapter [enabled=true,
> name=o.a.i.i.managers.deployment.GridDeploymentManager]
> java.lang.ClassCastException: class java.io.ObjectInputStream$Caches$1 cannot
> be cast to class java.util.Map (java.io.ObjectInputStream$Caches$1 and
> java.util.Map are in module java.base of loader 'bootstrap')
> at
> org.apache.ignite.internal.managers.deployment.GridDeploymentStoreAdapter.clearSerializationCache(GridDeploymentStoreAdapter.java:151)
> ~[proof-web-gateway-1.0.0+4dbe618b49758c4e-aio.jar:1.0.0]
> at
> org.apache.ignite.internal.managers.deployment.GridDeploymentStoreAdapter.clearSerializationCaches(GridDeploymentStoreAdapter.java:120)
> ~[proof-web-gateway-1.0.0+4dbe618b49758c4e-aio.jar:1.0.0]
> at
> org.apache.ignite.internal.managers.deployment.GridDeploymentLocalStore.undeploy(GridDeploymentLocalStore.java:565)
> ~[proof-web-gateway-1.0.0+4dbe618b49758c4e-aio.jar:1.0.0]
> at
> org.apache.ignite.internal.managers.deployment.GridDeploymentLocalStore.stop(GridDeploymentLocalStore.java:101)
> ~[proof-web-gateway-1.0.0+4dbe618b49758c4e-aio.jar:1.0.0]
> at
> org.apache.ignite.internal.managers.deployment.GridDeploymentManager.storesStop(GridDeploymentManager.java:630)
> ~[proof-web-gateway-1.0.0+4dbe618b49758c4e-aio.jar:1.0.0]
> at
> org.apache.ignite.internal.managers.deployment.GridDeploymentManager.stop(GridDeploymentManager.java:137)
> ~[proof-web-gateway-1.0.0+4dbe618b49758c4e-aio.jar:1.0.0]
> at
> org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:1928)
> ~[proof-web-gateway-1.0.0+4dbe618b49758c4e-aio.jar:1.0.0]
> at
> org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:1806)
> ~[proof-web-gateway-1.0.0+4dbe618b49758c4e-aio.jar:1.0.0]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2382)
> ~[proof-web-gateway-1.0.0+4dbe618b49758c4e-aio.jar:1.0.0]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2205)
> ~[proof-web-gateway-1.0.0+4dbe618b49758c4e-aio.jar:1.0.0]
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:350)
> ~[proof-web-gateway-1.0.0+4dbe618b49758c4e-aio.jar:1.0.0]
> at org.apache.ignite.Ignition.stop(Ignition.java:230)
> ~[proof-web-gateway-1.0.0+4dbe618b49758c4e-aio.jar:1.0.0]
> at
> io.appliedtheory.disco.services.IgniteClusterBootstrap.stop(IgniteClusterBootstrap.java:1148)
> ~[proof-web-gateway-1.0.0+4dbe618b49758c4e-aio.jar:1.0.0]
> at
>
[jira] [Updated] (IGNITE-17574) AssertionError "According to the JRaft protocol ECATCHUP is expected" is thrown on reconfiguration error
[
https://issues.apache.org/jira/browse/IGNITE-17574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semyon Danilov updated IGNITE-17574:
Description:
{noformat}
java.lang.AssertionError: According to the JRaft protocol, ECATCHUP is expected
at
org.apache.ignite.internal.table.distributed.raft.RebalanceRaftGroupEventsListener.onReconfigurationError(RebalanceRaftGroupEventsListener.java:205)
at
java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
at
org.apache.ignite.internal.table.distributed.raft.RebalanceRaftGroupEventsListener.onReconfigurationError(RebalanceRaftGroupEventsListener.java:189)
at
org.apache.ignite.raft.jraft.core.NodeImpl$ConfigurationCtx.lambda$reset$0(NodeImpl.java:453)
at org.apache.ignite.raft.jraft.util.Utils$1.run(Utils.java:161)
at
org.apache.ignite.internal.testframework.util.DirectExecutor.submit(DirectExecutor.java:68)
at org.apache.ignite.raft.jraft.util.Utils.runInThread(Utils.java:131)
at
org.apache.ignite.raft.jraft.util.Utils.runClosureInThread(Utils.java:158)
at
org.apache.ignite.raft.jraft.core.NodeImpl$ConfigurationCtx.reset(NodeImpl.java:459)
{noformat}
> AssertionError "According to the JRaft protocol ECATCHUP is expected" is
> thrown on reconfiguration error
>
>
> Key: IGNITE-17574
> URL: https://issues.apache.org/jira/browse/IGNITE-17574
> Project: Ignite
> Issue Type: Bug
>Reporter: Semyon Danilov
>Assignee: Semyon Danilov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> java.lang.AssertionError: According to the JRaft protocol, ECATCHUP is
> expected
> at
> org.apache.ignite.internal.table.distributed.raft.RebalanceRaftGroupEventsListener.onReconfigurationError(RebalanceRaftGroupEventsListener.java:205)
> at
> java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
> at
> org.apache.ignite.internal.table.distributed.raft.RebalanceRaftGroupEventsListener.onReconfigurationError(RebalanceRaftGroupEventsListener.java:189)
> at
> org.apache.ignite.raft.jraft.core.NodeImpl$ConfigurationCtx.lambda$reset$0(NodeImpl.java:453)
> at org.apache.ignite.raft.jraft.util.Utils$1.run(Utils.java:161)
> at
> org.apache.ignite.internal.testframework.util.DirectExecutor.submit(DirectExecutor.java:68)
> at org.apache.ignite.raft.jraft.util.Utils.runInThread(Utils.java:131)
> at
> org.apache.ignite.raft.jraft.util.Utils.runClosureInThread(Utils.java:158)
> at
> org.apache.ignite.raft.jraft.core.NodeImpl$ConfigurationCtx.reset(NodeImpl.java:459)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17574) AssertionError "According to the JRaft protocol ECATCHUP is expected" is thrown on reconfiguration error
[ https://issues.apache.org/jira/browse/IGNITE-17574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semyon Danilov updated IGNITE-17574: Summary: AssertionError "According to the JRaft protocol ECATCHUP is expected" is thrown on reconfiguration error (was: AssertionError "According to the JRaft protocol ECATCHUP is expected" is always thrown on reconfiguration error) > AssertionError "According to the JRaft protocol ECATCHUP is expected" is > thrown on reconfiguration error > > > Key: IGNITE-17574 > URL: https://issues.apache.org/jira/browse/IGNITE-17574 > Project: Ignite > Issue Type: Bug >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17359) Sql. Implement session auto expiration
[ https://issues.apache.org/jira/browse/IGNITE-17359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17584765#comment-17584765 ] Yury Gerzhedovich commented on IGNITE-17359: [~korlov] , coud you please review the patch again. > Sql. Implement session auto expiration > --- > > Key: IGNITE-17359 > URL: https://issues.apache.org/jira/browse/IGNITE-17359 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0.0-alpha5 >Reporter: Konstantin Orlov >Assignee: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > Time Spent: 50m > Remaining Estimate: 0h > > Currently server-side sessions are created but never deleted. Session objects > clogs the memory and lead to OOME. > Need to introduce background task to check each session from time to time and > clean up those that have expired. Also user should be able to set session > timeout, but right now it hardcoded value. > start point - > org.apache.ignite.internal.sql.engine.session.SessionManager#activeSessions -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17575) RocksDB Hash Index storage creates a single storage for all partitions
[
https://issues.apache.org/jira/browse/IGNITE-17575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-17575:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> RocksDB Hash Index storage creates a single storage for all partitions
> --
>
> Key: IGNITE-17575
> URL: https://issues.apache.org/jira/browse/IGNITE-17575
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> There's a bug in RocksDbTableStorage: it doesn't take into account that every
> partition has a separate index storage. Instead it creates a single storage
> when {{getOrCreateHashIndex}} is called.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17575) RocksDB Hash Index storage creates a single storage for all partitions
[
https://issues.apache.org/jira/browse/IGNITE-17575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-17575:
-
Description: There's a bug in RocksDbTableStorage: it doesn't take into
account that every partition has a separate index storage. Instead it creates a
single storage when {{getOrCreateHashIndex}} is called.
> RocksDB Hash Index storage creates a single storage for all partitions
> --
>
> Key: IGNITE-17575
> URL: https://issues.apache.org/jira/browse/IGNITE-17575
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> There's a bug in RocksDbTableStorage: it doesn't take into account that every
> partition has a separate index storage. Instead it creates a single storage
> when {{getOrCreateHashIndex}} is called.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17575) RocksDB Hash Index storage creates a single storage for all partitions
Aleksandr Polovtcev created IGNITE-17575: Summary: RocksDB Hash Index storage creates a single storage for all partitions Key: IGNITE-17575 URL: https://issues.apache.org/jira/browse/IGNITE-17575 Project: Ignite Issue Type: Bug Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16755) C++ Thin: Add user threadpool size option to public configuration
[ https://issues.apache.org/jira/browse/IGNITE-16755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-16755: -- Release Note: Added user thread pool size to public configuration of the C++ thin client > C++ Thin: Add user threadpool size option to public configuration > - > > Key: IGNITE-16755 > URL: https://issues.apache.org/jira/browse/IGNITE-16755 > Project: Ignite > Issue Type: Bug > Components: thin client >Affects Versions: 2.12 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.14 > > Time Spent: 0.5h > Remaining Estimate: 0h > > There are some cases when application creates many instances of C++ thin > client. Therefore each client instance spawns many threads (equals number of > cores). I propose add configuration to > ignite::thin::IgniteClientConfiguration which will override default > threadpool size when provided. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17236) inline size usage of index-reader
[ https://issues.apache.org/jira/browse/IGNITE-17236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-17236: -- Release Note: Improved index-reader.sh utility: analyze and output information about the actual usage of inline space in the index. > inline size usage of index-reader > - > > Key: IGNITE-17236 > URL: https://issues.apache.org/jira/browse/IGNITE-17236 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Minor > Fix For: 2.14 > > Time Spent: 1h > Remaining Estimate: 0h > > It will be useful to analyze and output information about actual usage of > inline space in index. > Those information can hint use about suboptimal usage of space in index > entries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17391) speed up index-reader.sh
[ https://issues.apache.org/jira/browse/IGNITE-17391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-17391: -- Release Note: Improved speed of the index-reader.sh utility > speed up index-reader.sh > > > Key: IGNITE-17391 > URL: https://issues.apache.org/jira/browse/IGNITE-17391 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Nikolay Izhikov >Priority: Minor > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > Utility index-reader.sh when analyzing files index.bin larger works longer > than we would like, for example: the analysis of indexes for 100 GB took more > than 15 hours, provided that the virtual machine is idle according to the > main indicators (CPU/MEM/HDD). We need to be able to speed up the application. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16986) Incorrect GridCacheManager#stop parameters
[ https://issues.apache.org/jira/browse/IGNITE-16986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-16986: -- Release Note: Fixed incorrect params of GridCacheManager#stop method. > Incorrect GridCacheManager#stop parameters > --- > > Key: IGNITE-16986 > URL: https://issues.apache.org/jira/browse/IGNITE-16986 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.13 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > IGNITE-8911 introduced an optimization that lets ignite skip cache destroy if > the whole cache group is going to be destroyed. However, this leads to > GridCacheManager#stop receiving incorrect destroy argument and potentially > not performing some tasks (for example, not dropping statistics). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17537) Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
[
https://issues.apache.org/jira/browse/IGNITE-17537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17584750#comment-17584750
]
Ignite TC Bot commented on IGNITE-17537:
{panel:title=Branch: [pull/10215/head] Base: [master] : Possible Blockers
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Queries 2 (lazy=true){color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6573692]]
* IgniteBinaryCacheQueryLazyTestSuite2:
DynamicIndexReplicatedTransactionalConcurrentSelfTest.testConcurrentOperationsAndCacheStartStopMultithreaded
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache 6{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6573624]]
* IgniteCacheTestSuite6: CacheExchangeMergeTest.testMergeServersFail1_4 - Test
has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache (Expiry Policy){color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6573629]]
* IgniteCacheExpiryPolicyTestSuite:
GridCacheTtlManagerNotificationTest.testThatNotificationWorkAsExpectedInMultithreadedMode
- Test has low fail rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/10215/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6573719buildTypeId=IgniteTests24Java8_RunAll]
> Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
> --
>
> Key: IGNITE-17537
> URL: https://issues.apache.org/jira/browse/IGNITE-17537
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Trivial
> Labels: ise, newbie
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Execution of {{control.sh --tx}} command produces output of matching
> transactions, eg.:
> {quote}Matching transactions:
> Tx: [xid=fdc4d720281--0fd8-0177--0012, label=null,
> state=ACTIVE, startTime=2022-07-06 05:05:07.432,
> {*}{color:#ff}duration=778{color}{*}, isolation=REPEATABLE_READ,
> concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=199,
> minorTopVer=0], {*}{color:#ff}timeout=4{color}{*}, ...]
> {quote}
> But, from the above line it is unclear, that in fact, duration is printed in
> seconds [1], while timeout is printed in milliseconds.
> We can improve output in one of the following ways:
> # Explicitly append unit for seconds and milliseconds.
> # Print duration and timeout in same units: both in seconds or both in
> milliseconds.
> Links:
> #
> https://github.com/apache/ignite/blob/bf9a460eccd07701cacac2a414c65707243350f1/modules/core/src/main/java/org/apache/ignite/internal/visor/tx/VisorTxInfo.java#L286
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15834) Read Repair should support arrays and collections as values
[ https://issues.apache.org/jira/browse/IGNITE-15834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-15834: -- Release Note: Improved `--consistency repair` command of the control.sh utility; Read Repair now support arrays and collections as values. (was: Read Repair now support arrays and collections as values) > Read Repair should support arrays and collections as values > --- > > Key: IGNITE-15834 > URL: https://issues.apache.org/jira/browse/IGNITE-15834 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-31 > Fix For: 2.14 > > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16977) Move DATE/TIME/TIMESTAMP indexes processing from ignite-indexing module to core
[
https://issues.apache.org/jira/browse/IGNITE-16977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16977:
---
Ignite Flags: (was: Release Notes Required)
> Move DATE/TIME/TIMESTAMP indexes processing from ignite-indexing module to
> core
> ---
>
> Key: IGNITE-16977
> URL: https://issues.apache.org/jira/browse/IGNITE-16977
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently all types of indexes except DATE, TIME and TIMESTAMP are processed
> in core module (see \{{IndexKeyFactory#wrap}}). DATE, TIME and TIMESTAMP
> types are processed in ignite-indexing module (see usages of
> \{{IndexKeyFactory#register}}).
> To get rid of H2 dependency by other query engines (Calcite) we should
> process indexes of all types by core module (with PDS backward compatibility).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-16806) Cache put/SQL table insert fails if SQL index created and LocalDateTime is used as value.
[
https://issues.apache.org/jira/browse/IGNITE-16806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-16806:
Release Note: Fixed insertion of values with java LocalDate, LocalTime and
LocalDateTime types in SQL table.
> Cache put/SQL table insert fails if SQL index created and LocalDateTime is
> used as value.
> -
>
> Key: IGNITE-16806
> URL: https://issues.apache.org/jira/browse/IGNITE-16806
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: ise.lts
> Fix For: 2.14
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Reproducer:
> {code:java}
> /** */
> public class LocalDateIndexTest extends AbstractIndexingCommonTest {
> /** */
> @Test
> public void test() throws Exception {
> IgniteEx ignite = startGrids(2);
> SqlFieldsQuery qry = new SqlFieldsQuery(
> "CREATE TABLE DATA (STR VARCHAR PRIMARY KEY, LOCDATETIME
> TIMESTAMP) WITH" +
> " \"KEY_TYPE=java.lang.String" +
> ",
> VALUE_TYPE=org.apache.ignite.internal.processors.query.LocalDateIndexTest$Data"
> +
> ", CACHE_NAME=" + DEFAULT_CACHE_NAME + "\"");
> ignite.context().query().querySqlFields(qry, false).getAll();
> qry = new SqlFieldsQuery("CREATE INDEX TEST_IDX ON DATA(LOCDATETIME
> DESC);");
> ignite.context().query().querySqlFields(qry, false).getAll();
> //ignite.cache(DEFAULT_CACHE_NAME).put("0", new Data("0",
> LocalDateTime.MAX));
> qry = new SqlFieldsQuery("INSERT INTO DATA(_key, str, locDateTime)
> values(?, ?, ?)").setArgs("0", "0", LocalDateTime.MAX);
> ignite.context().query().querySqlFields(qry, false).getAll();
> }
> public static class Data implements Serializable {
> /** Serial version UID. */
> private static final long serialVersionUID = 1L;
> /** */
> public String str;
> /** */
> public LocalDateTime locDateTime;
> /** */
> public Data(String str, LocalDateTime locDateTime) {
> this.str = str;
> this.locDateTime = locDateTime;
> }
> }
> }
> {code}
> Exception:
> {code:java}
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Type
> for a column 'LOCDATETIME' is not compatible with index definition. Expected
> 'Timestamp', actual type 'LocalDateTime'
> at
> org.apache.ignite.internal.processors.query.QueryTypeDescriptorImpl.validateIndexes(QueryTypeDescriptorImpl.java:735)
> at
> org.apache.ignite.internal.processors.query.QueryTypeDescriptorImpl.validateKeyAndValue(QueryTypeDescriptorImpl.java:606)
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlan.processRow(UpdatePlan.java:295)
> at
> org.apache.ignite.internal.processors.query.h2.dml.DmlUtils.dmlDoInsert(DmlUtils.java:212)
> at
> org.apache.ignite.internal.processors.query.h2.dml.DmlUtils.processSelectResult(DmlUtils.java:185)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdateNonTransactional(IgniteH2Indexing.java:2902)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdate(IgniteH2Indexing.java:2747)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdateDistributed(IgniteH2Indexing.java:2673)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeDml(IgniteH2Indexing.java:1263)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1185)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:3005)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:2988)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:3650)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$3(GridQueryProcessor.java:3022)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:3094)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2982)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2909)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2882)
[jira] [Updated] (IGNITE-17243) Durable background task is not started when BLT node joined cluster after activation
[
https://issues.apache.org/jira/browse/IGNITE-17243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-17243:
---
Release Note: Fixed durable background task start on BLT node joined to the
active cluster
> Durable background task is not started when BLT node joined cluster after
> activation
>
>
> Key: IGNITE-17243
> URL: https://issues.apache.org/jira/browse/IGNITE-17243
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When BLT node joined to the active cluster, variable
> {{DurableBackgroundTasksProcessor#prohibitionExecTasks}} is not cleared
> correctly and durable background tasks are not started on this node.
> Reproducer:
> {code:java}
> public void testNodeJoinAfterActivation() throws Exception {
> IgniteEx n = startGrid(0);
> startGrid(1);
> n.cluster().state(ACTIVE);
> stopGrid(1);
> n = startGrid(1);
> SimpleTask t = new SimpleTask("t");
> n.context().durableBackgroundTask().executeAsync(t, true);
> assertEquals(STARTED, tasks(n).get(t.name()).state());
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15329) Atomics should be repairable by Read Repair
[ https://issues.apache.org/jira/browse/IGNITE-15329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-15329: -- Release Note: Improved `--consistency repair` command of the control.sh utility; atomic caches now repairable by Read Repair (was: Atomic caches now repairable by Read Repair) > Atomics should be repairable by Read Repair > --- > > Key: IGNITE-15329 > URL: https://issues.apache.org/jira/browse/IGNITE-15329 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-12, iep-31 > Fix For: 2.14 > > Time Spent: 4.5h > Remaining Estimate: 0h > > It's pretty clear that it's impossible to fix atomics with "Read Repair" > atomically since it's impossible to lock entries during the repair process. > Even get from backups has no guarantee to return consistent values under load. > But to fix we must also perform an additional step - cache put. > So, value can be changed between gets, can be changed after gets but before > put, but it still seems to be possible to automize the fix. > Idea is to decide what entry won on the last check attempt and put this value > using the entry processor. > During the entry processor execution, we should check the current node's > value, and if the value is as it was during the check we must replace it with > the consistent value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-12852) Comma in field is not supported by COPY command
[ https://issues.apache.org/jira/browse/IGNITE-12852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-12852: -- Release Note: Fixed parsing quoted delimiters in CSV fields content for SQL command COPY. > Comma in field is not supported by COPY command > --- > > Key: IGNITE-12852 > URL: https://issues.apache.org/jira/browse/IGNITE-12852 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: YuJue Li >Assignee: Anton Kurbanov >Priority: Critical > Fix For: 2.14 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > CREATE TABLE test(a int,b varchar(100),c int,PRIMARY key(a)); > > a.csv: > 1,"a,b",2 > > COPY FROM '/data/a.csv' INTO test (a,b,c) FORMAT CSV; > > The copy command fails because there is a comma in the second field,but this > is a fully legal and compliant CSV format -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16806) Cache put/SQL table insert fails if SQL index created and LocalDateTime is used as value.
[
https://issues.apache.org/jira/browse/IGNITE-16806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-16806:
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Cache put/SQL table insert fails if SQL index created and LocalDateTime is
> used as value.
> -
>
> Key: IGNITE-16806
> URL: https://issues.apache.org/jira/browse/IGNITE-16806
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: ise.lts
> Fix For: 2.14
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Reproducer:
> {code:java}
> /** */
> public class LocalDateIndexTest extends AbstractIndexingCommonTest {
> /** */
> @Test
> public void test() throws Exception {
> IgniteEx ignite = startGrids(2);
> SqlFieldsQuery qry = new SqlFieldsQuery(
> "CREATE TABLE DATA (STR VARCHAR PRIMARY KEY, LOCDATETIME
> TIMESTAMP) WITH" +
> " \"KEY_TYPE=java.lang.String" +
> ",
> VALUE_TYPE=org.apache.ignite.internal.processors.query.LocalDateIndexTest$Data"
> +
> ", CACHE_NAME=" + DEFAULT_CACHE_NAME + "\"");
> ignite.context().query().querySqlFields(qry, false).getAll();
> qry = new SqlFieldsQuery("CREATE INDEX TEST_IDX ON DATA(LOCDATETIME
> DESC);");
> ignite.context().query().querySqlFields(qry, false).getAll();
> //ignite.cache(DEFAULT_CACHE_NAME).put("0", new Data("0",
> LocalDateTime.MAX));
> qry = new SqlFieldsQuery("INSERT INTO DATA(_key, str, locDateTime)
> values(?, ?, ?)").setArgs("0", "0", LocalDateTime.MAX);
> ignite.context().query().querySqlFields(qry, false).getAll();
> }
> public static class Data implements Serializable {
> /** Serial version UID. */
> private static final long serialVersionUID = 1L;
> /** */
> public String str;
> /** */
> public LocalDateTime locDateTime;
> /** */
> public Data(String str, LocalDateTime locDateTime) {
> this.str = str;
> this.locDateTime = locDateTime;
> }
> }
> }
> {code}
> Exception:
> {code:java}
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Type
> for a column 'LOCDATETIME' is not compatible with index definition. Expected
> 'Timestamp', actual type 'LocalDateTime'
> at
> org.apache.ignite.internal.processors.query.QueryTypeDescriptorImpl.validateIndexes(QueryTypeDescriptorImpl.java:735)
> at
> org.apache.ignite.internal.processors.query.QueryTypeDescriptorImpl.validateKeyAndValue(QueryTypeDescriptorImpl.java:606)
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlan.processRow(UpdatePlan.java:295)
> at
> org.apache.ignite.internal.processors.query.h2.dml.DmlUtils.dmlDoInsert(DmlUtils.java:212)
> at
> org.apache.ignite.internal.processors.query.h2.dml.DmlUtils.processSelectResult(DmlUtils.java:185)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdateNonTransactional(IgniteH2Indexing.java:2902)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdate(IgniteH2Indexing.java:2747)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdateDistributed(IgniteH2Indexing.java:2673)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeDml(IgniteH2Indexing.java:1263)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1185)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:3005)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:2988)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:3650)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$3(GridQueryProcessor.java:3022)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:3094)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2982)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2909)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2882)
> at
>
[jira] [Updated] (IGNITE-16877) C++ Thin: Implement ScanQuery
[ https://issues.apache.org/jira/browse/IGNITE-16877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-16877: -- Release Note: Added support ScanQuery for C++ thin client. > C++ Thin: Implement ScanQuery > - > > Key: IGNITE-16877 > URL: https://issues.apache.org/jira/browse/IGNITE-16877 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Affects Versions: 2.12 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.14 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Need to add the ScanQuery API to C++ thin client: > * The ScanQuery must have a partition property: it may be used to do parallel > initial data load to improve performance. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15837) Read Repair should support binary keys
[ https://issues.apache.org/jira/browse/IGNITE-15837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-15837: -- Release Note: Improved `--consistency repair` command of the control.sh utility; Read Repair now support binary keys. (was: Improved `"--consistency repair` command of the control.sh utility; Read Repair now support binary keys.) > Read Repair should support binary keys > -- > > Key: IGNITE-15837 > URL: https://issues.apache.org/jira/browse/IGNITE-15837 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-31 > Fix For: 2.14 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15837) Read Repair should support binary keys
[ https://issues.apache.org/jira/browse/IGNITE-15837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-15837: -- Release Note: Improved `"--consistency repair` command of the control.sh utility; Read Repair now support binary keys. (was: Read Repair now support binary keys) > Read Repair should support binary keys > -- > > Key: IGNITE-15837 > URL: https://issues.apache.org/jira/browse/IGNITE-15837 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-31 > Fix For: 2.14 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15329) Atomics should be repairable by Read Repair
[ https://issues.apache.org/jira/browse/IGNITE-15329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-15329: -- Release Note: Atomic caches now repairable by Read Repair (was: Atomic. caches now repairable by Read Repair) > Atomics should be repairable by Read Repair > --- > > Key: IGNITE-15329 > URL: https://issues.apache.org/jira/browse/IGNITE-15329 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-12, iep-31 > Fix For: 2.14 > > Time Spent: 4.5h > Remaining Estimate: 0h > > It's pretty clear that it's impossible to fix atomics with "Read Repair" > atomically since it's impossible to lock entries during the repair process. > Even get from backups has no guarantee to return consistent values under load. > But to fix we must also perform an additional step - cache put. > So, value can be changed between gets, can be changed after gets but before > put, but it still seems to be possible to automize the fix. > Idea is to decide what entry won on the last check attempt and put this value > using the entry processor. > During the entry processor execution, we should check the current node's > value, and if the value is as it was during the check we must replace it with > the consistent value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15329) Atomics should be repairable by Read Repair
[ https://issues.apache.org/jira/browse/IGNITE-15329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-15329: -- Release Note: Atomic. caches now repairable by Read Repair > Atomics should be repairable by Read Repair > --- > > Key: IGNITE-15329 > URL: https://issues.apache.org/jira/browse/IGNITE-15329 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-12, iep-31 > Fix For: 2.14 > > Time Spent: 4.5h > Remaining Estimate: 0h > > It's pretty clear that it's impossible to fix atomics with "Read Repair" > atomically since it's impossible to lock entries during the repair process. > Even get from backups has no guarantee to return consistent values under load. > But to fix we must also perform an additional step - cache put. > So, value can be changed between gets, can be changed after gets but before > put, but it still seems to be possible to automize the fix. > Idea is to decide what entry won on the last check attempt and put this value > using the entry processor. > During the entry processor execution, we should check the current node's > value, and if the value is as it was during the check we must replace it with > the consistent value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15837) Read Repair should support binary keys
[ https://issues.apache.org/jira/browse/IGNITE-15837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-15837: -- Release Note: Read Repair now support binary keys > Read Repair should support binary keys > -- > > Key: IGNITE-15837 > URL: https://issues.apache.org/jira/browse/IGNITE-15837 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-31 > Fix For: 2.14 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15834) Read Repair should support arrays and collections as values
[ https://issues.apache.org/jira/browse/IGNITE-15834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-15834: -- Release Note: Read Repair now support arrays and collections as values > Read Repair should support arrays and collections as values > --- > > Key: IGNITE-15834 > URL: https://issues.apache.org/jira/browse/IGNITE-15834 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-31 > Fix For: 2.14 > > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17033) Move ignite-aop to the Ignite Extensions
[ https://issues.apache.org/jira/browse/IGNITE-17033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-17033: - Release Note: Moved inigte-aop module to the Ignite Extensions project > Move ignite-aop to the Ignite Extensions > > > Key: IGNITE-17033 > URL: https://issues.apache.org/jira/browse/IGNITE-17033 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > The ignite-aop module must be moved to the Ignite Extension since it has not > been updated for a few years and it is not configured on TC for running tests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-13570) Migrate OSGI module to ignite-extensions
[ https://issues.apache.org/jira/browse/IGNITE-13570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-13570: - Release Note: Moved inigte-osgi module to the Ignite Extensions project > Migrate OSGI module to ignite-extensions > > > Key: IGNITE-13570 > URL: https://issues.apache.org/jira/browse/IGNITE-13570 > Project: Ignite > Issue Type: Sub-task > Components: extensions >Reporter: Alexey Goncharuk >Assignee: Maxim Muzafarov >Priority: Major > Labels: ignite-osgi > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > Migrate OSGI module to ignite-extensions > https://github.com/apache/ignite-extensions > Details: > https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IndependentIntegrations -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-16975) Windows support for CLI
[ https://issues.apache.org/jira/browse/IGNITE-16975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17584735#comment-17584735 ] Vadim Pakhnushev commented on IGNITE-16975: --- !image-2022-08-25-12-40-20-454.png! instead of underline Also fg(2) doesn't render as green > Windows support for CLI > --- > > Key: IGNITE-16975 > URL: https://issues.apache.org/jira/browse/IGNITE-16975 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr >Priority: Minor > Labels: ignite-3, ignite-3-cli-tool > Attachments: image-2022-08-25-12-40-20-454.png > > > The "support" means: > * command output is rendered well (tables, json) > * autocompletion, command history support > * ANSI colors support > Environments: Windows Command Line, Powershell. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17430) Sql. Provide commands and handlers for index related operations
[ https://issues.apache.org/jira/browse/IGNITE-17430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17584736#comment-17584736 ] Konstantin Orlov commented on IGNITE-17430: --- Hi, [~amashenkov]! I've left a few comments in PR. Please take a look > Sql. Provide commands and handlers for index related operations > --- > > Key: IGNITE-17430 > URL: https://issues.apache.org/jira/browse/IGNITE-17430 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > After IGNITE-17429 and backend for index management will be implemented, we > need to connect both parts together. For thus, we need to implement AST to > Command conversion as well as handlers for new index-related commands which > will delegate invocations to index manager (similar to table-related > commands). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16975) Windows support for CLI
[ https://issues.apache.org/jira/browse/IGNITE-16975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vadim Pakhnushev updated IGNITE-16975: -- Attachment: image-2022-08-25-12-40-20-454.png > Windows support for CLI > --- > > Key: IGNITE-16975 > URL: https://issues.apache.org/jira/browse/IGNITE-16975 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr >Priority: Minor > Labels: ignite-3, ignite-3-cli-tool > Attachments: image-2022-08-25-12-40-20-454.png > > > The "support" means: > * command output is rendered well (tables, json) > * autocompletion, command history support > * ANSI colors support > Environments: Windows Command Line, Powershell. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-12622) Forbid mixed cache groups with both atomic and transactional caches
[ https://issues.apache.org/jira/browse/IGNITE-12622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov reassigned IGNITE-12622: Assignee: (was: Maxim Muzafarov) > Forbid mixed cache groups with both atomic and transactional caches > --- > > Key: IGNITE-12622 > URL: https://issues.apache.org/jira/browse/IGNITE-12622 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Ivan Rakov >Priority: Major > Labels: IEP-80, newbie > Fix For: 2.15 > > > Apparently it's possible in Ignite to configure a cache group with both > ATOMIC and TRANSACTIONAL caches. > IgniteCacheGroupsTest#testContinuousQueriesMultipleGroups* tests. > As per discussed on dev list > (http://apache-ignite-developers.2346864.n4.nabble.com/Forbid-mixed-cache-groups-with-both-atomic-and-transactional-caches-td45586.html), > the community has concluded that such configurations should be prohibited. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-12622) Forbid mixed cache groups with both atomic and transactional caches
[ https://issues.apache.org/jira/browse/IGNITE-12622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov reassigned IGNITE-12622: Assignee: Maxim Muzafarov > Forbid mixed cache groups with both atomic and transactional caches > --- > > Key: IGNITE-12622 > URL: https://issues.apache.org/jira/browse/IGNITE-12622 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Ivan Rakov >Assignee: Maxim Muzafarov >Priority: Major > Labels: IEP-80, newbie > Fix For: 2.15 > > > Apparently it's possible in Ignite to configure a cache group with both > ATOMIC and TRANSACTIONAL caches. > IgniteCacheGroupsTest#testContinuousQueriesMultipleGroups* tests. > As per discussed on dev list > (http://apache-ignite-developers.2346864.n4.nabble.com/Forbid-mixed-cache-groups-with-both-atomic-and-transactional-caches-td45586.html), > the community has concluded that such configurations should be prohibited. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-12622) Forbid mixed cache groups with both atomic and transactional caches
[ https://issues.apache.org/jira/browse/IGNITE-12622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12622: - Labels: IEP-80 newbie (was: IEP-80) > Forbid mixed cache groups with both atomic and transactional caches > --- > > Key: IGNITE-12622 > URL: https://issues.apache.org/jira/browse/IGNITE-12622 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Ivan Rakov >Priority: Major > Labels: IEP-80, newbie > Fix For: 2.15 > > > Apparently it's possible in Ignite to configure a cache group with both > ATOMIC and TRANSACTIONAL caches. > IgniteCacheGroupsTest#testContinuousQueriesMultipleGroups* tests. > As per discussed on dev list > (http://apache-ignite-developers.2346864.n4.nabble.com/Forbid-mixed-cache-groups-with-both-atomic-and-transactional-caches-td45586.html), > the community has concluded that such configurations should be prohibited. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-12622) Forbid mixed cache groups with both atomic and transactional caches
[ https://issues.apache.org/jira/browse/IGNITE-12622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov reassigned IGNITE-12622: Assignee: (was: Ivan Rakov) > Forbid mixed cache groups with both atomic and transactional caches > --- > > Key: IGNITE-12622 > URL: https://issues.apache.org/jira/browse/IGNITE-12622 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Ivan Rakov >Priority: Major > Labels: IEP-80 > Fix For: 2.15 > > > Apparently it's possible in Ignite to configure a cache group with both > ATOMIC and TRANSACTIONAL caches. > IgniteCacheGroupsTest#testContinuousQueriesMultipleGroups* tests. > As per discussed on dev list > (http://apache-ignite-developers.2346864.n4.nabble.com/Forbid-mixed-cache-groups-with-both-atomic-and-transactional-caches-td45586.html), > the community has concluded that such configurations should be prohibited. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17160) Minor improvements in index-reader
[ https://issues.apache.org/jira/browse/IGNITE-17160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-17160: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Minor improvements in index-reader > -- > > Key: IGNITE-17160 > URL: https://issues.apache.org/jira/browse/IGNITE-17160 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Priority: Trivial > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > Code of index reader contains many compiler and IDE warnings that can be > easily fixed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (IGNITE-17453) Calcite Engine: ORDER BY Optimization
[
https://issues.apache.org/jira/browse/IGNITE-17453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov reopened IGNITE-17453:
---
> Calcite Engine: ORDER BY Optimization
> -
>
> Key: IGNITE-17453
> URL: https://issues.apache.org/jira/browse/IGNITE-17453
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.13
>Reporter: YuJue Li
>Priority: Critical
> Labels: calcite3-required
> Fix For: 2.14
>
>
> 1.start a node;
> 2.create table:
> CREATE TABLE PI_COM_DAY
> (COM_ID VARCHAR(30) NOT NULL ,
> ITEM_ID VARCHAR(30) NOT NULL ,
> DATE1 VARCHAR(8) NOT NULL ,
> KIND VARCHAR(1),
> QTY_IOD DECIMAL(18, 6) ,
> AMT_IOD DECIMAL(18, 6) ,
> PRIMARYKEY (COM_ID,ITEM_ID,DATE1))
> WITH"template=partitioned,CACHE_NAME=PI_COM_DAY";
> CREATE INDEX IDX_PI_COM_DAY_ITEM_DATE ON PI_COM_DAY(ITEM_ID);
>
> 3.insert some data, for example, 1m;
> 4.execute sql:
> select * from pi_com_day order by item_id desc limit 10;
> normal.
> select /*+ QUERY_ENGINE('calcite') */ * from pi_com_day order by item_id desc
> limit 10;
> then OOM.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-17453) Calcite Engine: ORDER BY Optimization
[
https://issues.apache.org/jira/browse/IGNITE-17453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov resolved IGNITE-17453.
---
Release Note: Change resolution to duplicate
Resolution: Duplicate
> Calcite Engine: ORDER BY Optimization
> -
>
> Key: IGNITE-17453
> URL: https://issues.apache.org/jira/browse/IGNITE-17453
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.13
>Reporter: YuJue Li
>Priority: Critical
> Labels: calcite3-required
> Fix For: 2.14
>
>
> 1.start a node;
> 2.create table:
> CREATE TABLE PI_COM_DAY
> (COM_ID VARCHAR(30) NOT NULL ,
> ITEM_ID VARCHAR(30) NOT NULL ,
> DATE1 VARCHAR(8) NOT NULL ,
> KIND VARCHAR(1),
> QTY_IOD DECIMAL(18, 6) ,
> AMT_IOD DECIMAL(18, 6) ,
> PRIMARYKEY (COM_ID,ITEM_ID,DATE1))
> WITH"template=partitioned,CACHE_NAME=PI_COM_DAY";
> CREATE INDEX IDX_PI_COM_DAY_ITEM_DATE ON PI_COM_DAY(ITEM_ID);
>
> 3.insert some data, for example, 1m;
> 4.execute sql:
> select * from pi_com_day order by item_id desc limit 10;
> normal.
> select /*+ QUERY_ENGINE('calcite') */ * from pi_com_day order by item_id desc
> limit 10;
> then OOM.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17432) ignitevisorcmd can't run in jdk17 env
[ https://issues.apache.org/jira/browse/IGNITE-17432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-17432: -- Release Note: Fixed run ignitevisorcmd in JDK 17 environment > ignitevisorcmd can't run in jdk17 env > - > > Key: IGNITE-17432 > URL: https://issues.apache.org/jira/browse/IGNITE-17432 > Project: Ignite > Issue Type: Bug > Components: cli >Affects Versions: 2.13 >Reporter: YuJue Li >Assignee: YuJue Li >Priority: Minor > Fix For: 2.14 > > Attachments: > 0001-IGNITE-17432-ignitevisorcmd-can-t-run-in-jdk17-env.patch > > Time Spent: 20m > Remaining Estimate: 0h > > Unrecognized VM option 'MaxPermSize=128M' > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17387) Protocol version mismatch in case of a long password
[
https://issues.apache.org/jira/browse/IGNITE-17387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-17387:
--
Release Note: Fixed server-side message parsing for big messages from thin
clients.
> Protocol version mismatch in case of a long password
>
>
> Key: IGNITE-17387
> URL: https://issues.apache.org/jira/browse/IGNITE-17387
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.13
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If user specifies a password longer than 64k (with the default conf) we get a
> protocol mismatch error:
> {code}
> org.apache.ignite.internal.client.thin.ClientProtocolError: Protocol version
> mismatch: client 1.7.0 / server 2.8.0. Server details: Unsupported version:
> 1.0.0
> {code}
> It happens because of the overflow of socket send buffer (limit is 64K see
> https://docs.oracle.com/javase/7/docs/api/java/net/ServerSocket.html#setReceiveBufferSize(int)
> ).
> So WA is to extend default socket buffers size and add limitation to their
> passwords sizes (e.g restrict max password size to 32K).
> {code}
> // if password is about 60K it will be OK for default config, if more than
> 64K you will receive version protocol error (because
> // TcpClientChannel would read wrong data from buffer). Here we extend
> default buffer sizes to 100K to bypass this issue.
> new ClientConnectorConfiguration()
> .setSocketSendBufferSize(100 * 1024)
> .setSocketReceiveBufferSize(100 * 1024)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-16777) clearAsync could lead to a block of the management pool
[
https://issues.apache.org/jira/browse/IGNITE-16777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-16777:
--
Release Note: Fixed an issue that could lead to a block of the management
pool in case of using clearSync
> clearAsync could lead to a block of the management pool
> ---
>
> Key: IGNITE-16777
> URL: https://issues.apache.org/jira/browse/IGNITE-16777
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.12
>Reporter: Maria Makedonskaya
>Assignee: Denis Chudov
>Priority: Major
> Labels: ise.lts
> Fix For: 2.14
>
> Attachments: ClearAsyncNearCachesTest.java
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> In the case of using near caches when we call clearAsync there is a chain
> future(see
> org.apache.ignite.internal.processors.cache.GridCacheAdapter#clearAsync(java.util.Set extends K>)) where we synchronously wait for execution of ClearTask on near
> nodes. This logic leads to the possibility of blocking all threads in the
> management pool (reproducer attached).
> Stack trace of waiting thread:
> {noformat}
> "mgmt-#297%ignite.SizeTaskTest24%@5869" prio=5 tid=0x149 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$8.applyx(GridCacheAdapter.java:1231)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$8.applyx(GridCacheAdapter.java:1229)
> at
> org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:70)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:30)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener$$$capture(GridFutureAdapter.java:399)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:-1)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:511)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:490)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1650)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.finishTask(GridTaskWorker.java:1618)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.reduce(GridTaskWorker.java:1194)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:976)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.processJobExecuteResponse(GridTaskProcessor.java:1155)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor$JobMessageListener.onMessage(GridTaskProcessor.java:1390)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1907)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:242)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
> at
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17114) Idle_verify must print and compare full partition counter state instead of just LWM
[ https://issues.apache.org/jira/browse/IGNITE-17114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-17114: -- Release Note: Fixed the command `idle_verify` of the control.sh utility; the command prints and compares full partition counter state. > Idle_verify must print and compare full partition counter state instead of > just LWM > --- > > Key: IGNITE-17114 > URL: https://issues.apache.org/jira/browse/IGNITE-17114 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-31, ise > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > Gaps also should be printed/compared. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17385) Frequent commits of single cache transactions can lead GridCacheAdapter#asyncOpsSem permits overflow
[
https://issues.apache.org/jira/browse/IGNITE-17385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Timonin updated IGNITE-17385:
Release Note: Fixed overflowing async operation permits maximum for
explicit transaction with single write entry
> Frequent commits of single cache transactions can lead
> GridCacheAdapter#asyncOpsSem permits overflow
>
>
> Key: IGNITE-17385
> URL: https://issues.apache.org/jira/browse/IGNITE-17385
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Maksim Timonin
>Priority: Major
> Labels: ise
> Fix For: 2.14
>
> Attachments: SemaphorePermitsExceeded.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When you commit a transaction, which was _explicitly started only over a
> single cache_, then {{GridCacheAdapter#asyncOpRelease}} is called without
> {{GridCacheAdapter#asyncOpAcquire}}. This situation can lead to continuous
> grow of permits count in {{GridCacheAdapter#asyncOpsSem}} and to overflow
> with a further failure of node started the transaction:
> {code}
> Critical system error detected. Will be handled accordingly to configured
> handler
> [hnd=o.a.i.i.processors.cache.transactions.TxAsyncOpsSemaphorePermitsExeededTest$$Lambda$42/1924582348@7379bebb,
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=java.lang.Error: Maximum
> permit count exceeded]]
> {code}
> As you can see in [1], in case of the single cache context, transaction will
> be commited by calling of {{GridCacheAdapter#commitTxAsync}}, which invokes
> {{GridCacheAdapter#asyncOpRelease}} later. But, when multiple caches affected
> by transaction, {{GridNearTxLocal#commitNearTxLocalAsync}} is called to
> commit transaction, and no invokes of {{GridCacheAdapter#asyncOpRelease}}
> occur.
> So, the greater the load (RPS / TPS) with a such single cache transactions,
> the faster the failure of a node will happen.
> Reproducer of the problem: [^SemaphorePermitsExceeded.patch]. It prints
> additional messages, when semaphore is released, or acquired.
> Links:
> #
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheSharedContext.java#L1122
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17399) CDC: expiration of entries are not applied on destination cluster
[
https://issues.apache.org/jira/browse/IGNITE-17399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Timonin updated IGNITE-17399:
Release Note: Fixed expiration doesn't apply for cache entries replicated
with CDC
> CDC: expiration of entries are not applied on destination cluster
> -
>
> Key: IGNITE-17399
> URL: https://issues.apache.org/jira/browse/IGNITE-17399
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Maksim Timonin
>Priority: Minor
> Labels: IEP-59, ise
> Fix For: 2.14
>
> Attachments: ExpiryCdcReproducer.patch
>
>
> There are two points, which should be noted:
> # Removes of entries on expiration are not captured by {{CdcConsumer}} and
> {{WalRecordsConsumer}}. So, removes are not propagated to a destination
> cluster.
> # Entries, which was put via the {{CdcEventsApplier}} are not expired in
> destination cluster, even if cache is configured with expiry policy.
> Reproducer: [^ExpiryCdcReproducer.patch]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17154) Fix handle BinaryObjectException at the thin JDBC
[
https://issues.apache.org/jira/browse/IGNITE-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-17154:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Fix handle BinaryObjectException at the thin JDBC
> -
>
> Key: IGNITE-17154
> URL: https://issues.apache.org/jira/browse/IGNITE-17154
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Failed to get enum via sqlite
> {code:java}
> Error: Statement is closed. (state=,code=0)
> java.sql.SQLException: Statement is closed.
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.ensureNotClosed(JdbcThinStatement.java:950)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.getWarnings(JdbcThinStatement.java:546)
> at sqlline.Commands.execute(Commands.java:849)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17145) Fix handle BinaryObjectException at the thin JDBC
[
https://issues.apache.org/jira/browse/IGNITE-17145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-17145:
--
Release Note: Fixed handle BinaryObjectException on response deserialize at
the thin JDBC.
> Fix handle BinaryObjectException at the thin JDBC
> -
>
> Key: IGNITE-17145
> URL: https://issues.apache.org/jira/browse/IGNITE-17145
> Project: Ignite
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 2.13
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I am trying to get enum field using sqlline, but failed with error Statement
> is closed.
> {code}
> 0: jdbc:ignite:thin://127.0.0.1> select status from nebulaclusterinfo;
> Error: Statement is closed. (state=,code=0)
> java.sql.SQLException: Statement is closed.
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.ensureNotClosed(JdbcThinStatement.java:950)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.getWarnings(JdbcThinStatement.java:546)
> at sqlline.Commands.execute(Commands.java:849)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> 0: jdbc:ignite:thin://127.0.0.1> select count(status) from nebulaclusterinfo;
> ++
> | COUNT(STATUS) |
> ++
> | 310|
> ++
> 1 row selected (0.108 seconds)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17455) IndexQuery should support setPartition
[ https://issues.apache.org/jira/browse/IGNITE-17455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-17455: Release Note: Added opportunity to specify single partition for IndexQuery > IndexQuery should support setPartition > -- > > Key: IGNITE-17455 > URL: https://issues.apache.org/jira/browse/IGNITE-17455 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-71, ise > Fix For: 2.14 > > Time Spent: 50m > Remaining Estimate: 0h > > Currently IndexQuery doesn't support querying specified partition. But other > types of queries provide this option - ScanQuery, SqlFieldsQuery. > It's useful option for working with affinity requests. Then IndexQuery should > work over single partition. > To make it possible to migrate to IndexQuery from others queries let's add > such opportunity. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16318) Empty binary object is incorrect written/read/modified
[
https://issues.apache.org/jira/browse/IGNITE-16318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-16318:
--
Release Note: Fixed write empty binary object.
> Empty binary object is incorrect written/read/modified
> --
>
> Key: IGNITE-16318
> URL: https://issues.apache.org/jira/browse/IGNITE-16318
> Project: Ignite
> Issue Type: Bug
> Components: binary, cache
>Reporter: Andrey Belyaev
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Cache interceptor cause problem of missing binary scheme if sql insert
> contains only entry key fields and no one value field pass in query.
> There is exception happened if inside interceptor we try to make
> BinaryObjectBuilder from entry value BinaryObject (#toBuilder()) and then
> request builder for any field.
> Interceptor example:
> {code:java}
> new CacheInterceptorAdapter() {
> @Nullable
> @Override public BinaryObject onBeforePut(Cache.Entry BinaryObject> entry, BinaryObject newVal) {
> BinaryObjectBuilder newValBuilder = newVal.toBuilder();
> String bValue = newValBuilder.getField("B"); // Cannot find schema
> for object with compact footer
> // ...
> }
> } {code}
> It's a pretty serious error which currupt and shutdown grid.
> Code example:
> {code:java}
> LinkedHashMap fields = new LinkedHashMap<>();
> fields.put("A", "java.lang.String");
> fields.put("B", "java.lang.String");
> fields.put("C", "java.lang.String");
> Set keyFields = new LinkedHashSet<>();
> keyFields.add("A");
> CacheInterceptorAdapter cacheInterceptorAdapter = new
> CacheInterceptorAdapter() {
> @Nullable
> @Override public BinaryObject onBeforePut(Cache.Entry BinaryObject> entry, BinaryObject newVal) {
> BinaryObjectBuilder newValBuilder = newVal.toBuilder();
> String bValue = newValBuilder.getField("B"); // Cannot find schema
> for object with compact footer
> if (bValue == null || bValue.isEmpty()) {
> newValBuilder.setField("B", "Some value");
> }
> return newValBuilder.build();
> }
> };
> CacheConfiguration cacheConfiguration = new CacheConfiguration<>()
> .setName("TEST_CACHE")
> .setKeyConfiguration(new CacheKeyConfiguration()
> .setTypeName("TEST_CACHE_KEY")
> .setAffinityKeyFieldName("InternalId"))
> .setQueryEntities(Collections.singleton(new QueryEntity()
> .setTableName("TEST_CACHE")
> .setKeyType("TEST_CACHE_KEY")
> .setValueType("TEST_CACHE_VALUE")
> .setFields(fields)
> .setKeyFields(keyFields)))
> .setInterceptor(cacheInterceptorAdapter);
> IgniteConfiguration igniteConfiguration = new IgniteConfiguration()
> .setCacheConfiguration(cacheConfiguration);
> try (Ignite ignite = Ignition.start(igniteConfiguration)) {
> IgniteCache testCache = ignite.getOrCreateCache("TEST_CACHE");
> // putSql
> testCache.query(new SqlFieldsQuery("INSERT INTO TEST_CACHE (A) VALUES
> ('1234')"));
> }{code}
> Exception:
> {code:java}
> [2022-01-18 13:12:32,727][ERROR][main][CacheObjectBinaryProcessorImpl] Timed
> out while waiting for schema update [typeId=1147851335, schemaId=0]
> [2022-01-18 13:12:32,730][ERROR][main][root] Critical system error detected.
> Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is
> corrupted [groupId=-838655627, pageIds=[844420635166307], msg=Runtime failure
> on search row: SearchRow [key=TEST_CACHE_KEY [idHash=100929741,
> hash=-639470899, A=123], hash=-639470899, cacheId=0
> class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> B+Tree is corrupted [groupId=-838655627, pageIds=[844420635166307],
> msg=Runtime failure on search row: SearchRow [key=TEST_CACHE_KEY
> [idHash=100929741, hash=-639470899, A=123], hash=-639470899, cacheId=0]]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.corruptedTreeException(BPlusTree.java:6237)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1988)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1742)
> at
>
[jira] [Updated] (IGNITE-16873) C++ thin client SqlFieldsQuery should allow setting a partition
[ https://issues.apache.org/jira/browse/IGNITE-16873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-16873: -- Release Note: Added partition property to SqlFieldsQuery for C++ thin client. > C++ thin client SqlFieldsQuery should allow setting a partition > --- > > Key: IGNITE-16873 > URL: https://issues.apache.org/jira/browse/IGNITE-16873 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Affects Versions: 2.12 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > C++ client node queries (ScanQuery and SqlFiedsQuery) allow setting a > partition the query would be executed on. This can be used to improve initial > data load performance significantly > The C++ thin client SqlFieldsQuery API has no partition property and that > makes the initial data load performance unacceptable. > Need to add the partition property to SqlFieldsQuery. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17496) LWM may be after HWM (reserved) on primary after the node restart
[
https://issues.apache.org/jira/browse/IGNITE-17496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-17496:
--
Release Note: Fixed partition update counter tracking on primary after the
node restart
> LWM may be after HWM (reserved) on primary after the node restart
> -
>
> Key: IGNITE-17496
> URL: https://issues.apache.org/jira/browse/IGNITE-17496
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.14
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:java}
> java.lang.AssertionError: LWM after HWM: lwm=10010, hwm=10003, cntr=Counter
> [lwm=10010, missed=[10011 - 10012, 10021, 10031 - 10032, 10043 - 10044],
> maxApplied=10047, hwm=10004]
> at
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl.reserve(PartitionUpdateCounterTrackingImpl.java:265)
> at
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterErrorWrapper.reserve(PartitionUpdateCounterErrorWrapper.java:58)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.getAndIncrementUpdateCounter(IgniteCacheOffheapManagerImpl.java:1620)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.getAndIncrementUpdateCounter(GridCacheOffheapManager.java:2538)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.getAndIncrementUpdateCounter(GridDhtLocalPartition.java:942)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.calculatePartitionUpdateCounters(IgniteTxLocalAdapter.java:510)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1360)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:730)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1136)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:400)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:581)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:378)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:201)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:175)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:135)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:223)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:221)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1151)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:592)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:393)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:110)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:309)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1907)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:243)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
> at
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:637)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at java.lang.Thread.run(Thread.java:750) {code}
> It looks like we have incorrect initialization problem here.
> For example,
[jira] [Updated] (IGNITE-17502) Tasks to sent the snapshot files are not ordered
[
https://issues.apache.org/jira/browse/IGNITE-17502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-17502:
--
Release Note: Fixed tasks to sent snapshot files.
> Tasks to sent the snapshot files are not ordered
>
>
> Key: IGNITE-17502
> URL: https://issues.apache.org/jira/browse/IGNITE-17502
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: ise
> Fix For: 2.14
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Tasks to sent the snapshot files are not ordered. This leads to socket
> timeout in a file sender while thread is busy by sending to other node:
> {noformat}
> sender.send(part1);
> ...
> otherSender.send(part3);
> ...
> // `sender` throws socket timeout exception.
> sender.send(part2);
> {noformat}
> {noformat}
> java.io.EOFException: null
> at
> java.io.ObjectInputStream$BlockDataInputStream.readBoolean(ObjectInputStream.java:3120)
> ~[?:1.8.0_201]
> at java.io.ObjectInputStream.readBoolean(ObjectInputStream.java:966)
> ~[?:1.8.0_201]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.receiveFromChannel(GridIoManager.java:2935)
> [classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processOpenedChannel(GridIoManager.java:2895)
> [classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4900(GridIoManager.java:244)
> [classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$7.run(GridIoManager.java:1237)
> [classes/:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [?:1.8.0_201]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [?:1.8.0_201]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_201]
> ...
> Caused by: org.apache.ignite.IgniteCheckedException: Requested topic is busy
> by another transmission. It's not allowed to process different sessions over
> the same topic simultaneously. Channel will be closed
> [initMsg=SessionChannelMessage
> [sesId=9c855b38281-d8dcd34f-916f-49d0-a453-cd1866acfce1],
> channel=java.nio.channels.SocketChannel[connected local=/127.0.0.1:47102
> remote=/127.0.0.1:55621], nodeId=5ace7280-b08a-4cf9-b428-7f70ef70]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processOpenedChannel(GridIoManager.java:2867)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4900(GridIoManager.java:244)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$7.run(GridIoManager.java:1237)
> ~[classes/:?]
> ... 3 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17531) Tests covers consistency repair at inconsistent cluster with nonfinalized counters
[ https://issues.apache.org/jira/browse/IGNITE-17531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-17531: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Tests covers consistency repair at inconsistent cluster with nonfinalized > counters > -- > > Key: IGNITE-17531 > URL: https://issues.apache.org/jira/browse/IGNITE-17531 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Fix For: 2.14 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Test must > 1) Generate data with missed unordered update counter (gaps) > 2) Perform restart with rebalance (full or historiical) > 3) Check consistency on restart using idle_verify > 4) Fix inconsistency using consistency_repair > 5) Check result using idle_verify > The main goal is to check recovery at production (where cluster may fail > under the load) tools and approaches. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16869) Upgrade org.springframework:spring-core in ignite-extensions for CVE-2022-22965 (a.k.a. Spring4Shell)
[ https://issues.apache.org/jira/browse/IGNITE-16869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-16869: -- Release Note: Updated Spring dependency version (fixes CVE-2022-22965) > Upgrade org.springframework:spring-core in ignite-extensions for > CVE-2022-22965 (a.k.a. Spring4Shell) > - > > Key: IGNITE-16869 > URL: https://issues.apache.org/jira/browse/IGNITE-16869 > Project: Ignite > Issue Type: Bug > Components: extensions >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Critical > Labels: ise.lts > Fix For: 2.14 > > > Upgrade org.springframework:spring-beans to version 5.2.20 or later > Upgrade org.springframework:spring-core to version 5.2.20 or later > Vulnerable versions: < 5.2.20 > Patched version: 5.2.20 > Spring Framework prior to versions 5.2.20 and 5.3.18 contains a remote code > execution vulnerability known as Spring4Shell. > Impact > A Spring MVC or Spring WebFlux application running on JDK 9+ may be > vulnerable to remote code execution (RCE) via data binding. The specific > exploit requires the application to run on Tomcat as a WAR deployment. If the > application is deployed as a Spring Boot executable jar, i.e. the default, it > is not vulnerable to the exploit. However, the nature of the vulnerability is > more general, and there may be other ways to exploit it. > These are the prerequisites for the exploit: > JDK 9 or higher > Apache Tomcat as the Servlet container > Packaged as WAR > spring-webmvc or spring-webflux dependency > Patches > Spring Framework 5.3.18 and 5.2.20 > Spring Boot 2.6.6 and 2.5.12 > Workarounds > For those who are unable to upgrade, leaked reports recommend setting > disallowedFields on WebDataBinder through an @ControllerAdvice. This works > generally, but as a centrally applied workaround fix, may leave some > loopholes, in particular if a controller sets disallowedFields locally > through its own @InitBinder method, which overrides the global setting. > To apply the workaround in a more fail-safe way, applications could extend > RequestMappingHandlerAdapter to update the WebDataBinder at the end after all > other initialization. In order to do that, a Spring Boot application can > declare a WebMvcRegistrations bean (Spring MVC) or a WebFluxRegistrations > bean (Spring WebFlux). > > The idea is to do the following: > # Remove ignite-spring-data and ignite-spring-data_2.0 > # Update ignite-spring-data_2.2 module to depend on the latest Spring > version in branch 5.2 (it's currently 5.2.21) > # Probably also rename ignite-spring-data_2.2 extension to > ignite-spring-data (dropping the version postfix). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17559) IgniteSetClientTests.TestCopyToInvalidArguments fails on Windows
[
https://issues.apache.org/jira/browse/IGNITE-17559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-17559:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> IgniteSetClientTests.TestCopyToInvalidArguments fails on Windows
>
>
> Key: IGNITE-17559
> URL: https://issues.apache.org/jira/browse/IGNITE-17559
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.14
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> https://ci.ignite.apache.org/test/-420042244593401280?currentProjectId=IgniteTests24Java8=%3Cdefault%3E
> {code}
> Expected string length 75 but was 79. Strings differ at index 29.
> Expected: "...r required. (Parameter 'arrayIndex')\nActual value was -1."
> But was: "...r required.\r\nParameter name: arrayIndex\r\nActual value was
> -1."
> -^
>at
> Apache.Ignite.Core.Tests.Client.DataStructures.IgniteSetClientTests.TestCopyToInvalidArguments()
> in
> C:\BuildAgent\work\7bc1c54bc719b67c\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Client\DataStructures\IgniteSetClientTests.cs:line
> 219
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17574) AssertionError "According to the JRaft protocol ECATCHUP is expected" is always thrown on reconfiguration error
Semyon Danilov created IGNITE-17574: --- Summary: AssertionError "According to the JRaft protocol ECATCHUP is expected" is always thrown on reconfiguration error Key: IGNITE-17574 URL: https://issues.apache.org/jira/browse/IGNITE-17574 Project: Ignite Issue Type: Bug Reporter: Semyon Danilov Assignee: Semyon Danilov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17395) Thin 3.0: Design Partition Awareness for Ignite-3
[ https://issues.apache.org/jira/browse/IGNITE-17395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego reassigned IGNITE-17395: Assignee: (was: Igor Sapego) > Thin 3.0: Design Partition Awareness for Ignite-3 > -- > > Key: IGNITE-17395 > URL: https://issues.apache.org/jira/browse/IGNITE-17395 > Project: Ignite > Issue Type: Task > Components: thin client >Reporter: Igor Sapego >Priority: Major > Labels: ignite-3 > > Need to design Partition Awareness feature for Ignite-3 (here is analogue for > Ignite-2: > [IEP-23|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+Thin+Clients]). > As a result, IEP should be created, discussed on the devlist and approved > for development. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17537) Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
[
https://issues.apache.org/jira/browse/IGNITE-17537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17584673#comment-17584673
]
Julia Bakulina commented on IGNITE-17537:
-
1) ", duration=" + getDuration() {*}/ 1000{*};
", timeout=" + getTimeout();
VisorTxInfo class:
[https://github.com/apache/ignite/blob/bf9a460eccd07701cacac2a414c65707243350f1/modules/core/src/main/java/org/apache/ignite/internal/visor/tx/VisorTxInfo.java#L286]
2) long duration from getDuration() is in milliseconds as per VisorTxTask class
(long duration = U.currentTimeMillis() - locTx.startTime()):
[https://github.com/apache/ignite/blob/f6e2ebe8e62b3e442bda2a70f19544261b3c0cfa/modules/core/src/main/java/org/apache/ignite/internal/visor/tx/VisorTxTask.java#L243]
3) long timeout is in milliseconds as per IgniteInternalTx interface ("Gets
timeout value in milliseconds for this transaction"):
[https://github.com/apache/ignite/blob/e2008f4652544e51c75a8586ef8aee82fb2923b9/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/transactions/IgniteInternalTx.java#L148]
>From the above 1) -3) after dividing into 1000 the duration is in seconds
>while timeout is still in milliseconds which should be explicitly highlighted.
> Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
> --
>
> Key: IGNITE-17537
> URL: https://issues.apache.org/jira/browse/IGNITE-17537
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Trivial
> Labels: ise, newbie
>
> Execution of {{control.sh --tx}} command produces output of matching
> transactions, eg.:
> {quote}Matching transactions:
> Tx: [xid=fdc4d720281--0fd8-0177--0012, label=null,
> state=ACTIVE, startTime=2022-07-06 05:05:07.432,
> {*}{color:#ff}duration=778{color}{*}, isolation=REPEATABLE_READ,
> concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=199,
> minorTopVer=0], {*}{color:#ff}timeout=4{color}{*}, ...]
> {quote}
> But, from the above line it is unclear, that in fact, duration is printed in
> seconds [1], while timeout is printed in milliseconds.
> We can improve output in one of the following ways:
> # Explicitly append unit for seconds and milliseconds.
> # Print duration and timeout in same units: both in seconds or both in
> milliseconds.
> Links:
> #
> https://github.com/apache/ignite/blob/bf9a460eccd07701cacac2a414c65707243350f1/modules/core/src/main/java/org/apache/ignite/internal/visor/tx/VisorTxInfo.java#L286
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-14914) Support in() clause in IndexQuery.
[
https://issues.apache.org/jira/browse/IGNITE-14914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Timonin updated IGNITE-14914:
Release Note: Added support for IN criterion for IndexQuery:
IndexQuery.setCriteria(in("A", Arrays.asList(1, 2 ,3))). (was: IndexQuery
supports IN criterion: IndexQuery.setCriteria(in("A", Arrays.asList(1, 2 ,3))).)
> Support in() clause in IndexQuery.
> --
>
> Key: IGNITE-14914
> URL: https://issues.apache.org/jira/browse/IGNITE-14914
> Project: Ignite
> Issue Type: New Feature
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Labels: IEP-71, ise
> Fix For: 2.14
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> IndexQuery should support IN criterion:
> {{IndexQuery.setCriteria(in("A", Arrays.asList(1, 2 ,3)));}}
> # IN criterion accepts collection of values to find. This collections is
> transformed to {{SortedSet(1, 2, 3)}} because IndexQuery provides to user
> sorted result.
> # When IN applies on first indexed field - IN(A0, A1) for index (A, B) - it
> converts to multiple {{eq}} operations are joint with OR operation:
> {{{}EQ(A0) or EQ(A1){}}}.
> # Other range criteria for other fields are applied to every such separate
> operation:
> {{IN(A0, A1) and GT(B)}} converts to {{{}(EQ(A0) and GT(B)) or (EQ(A1) and
> GT(B)){}}}.
> # When IN applies to non-leading indexed field - IN(B0, B1) for index (A, B)
> - it works like a filter for prepared range:
> {{GTE(A) and IN(B0, B1)}} converts to range {{[[A, B0]; [A, B1]]}} and every
> cache entry within this range is checked for being included to SortedSet(B0,
> B1).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17511) Support IndexQuery for Java ThinClient
[ https://issues.apache.org/jira/browse/IGNITE-17511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-17511: Release Note: Java ThinClient now supports IndexQuery feature. (was: Java ThinClient supports IndexQuery feature.) > Support IndexQuery for Java ThinClient > -- > > Key: IGNITE-17511 > URL: https://issues.apache.org/jira/browse/IGNITE-17511 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-71, ise > Fix For: 2.14 > > Time Spent: 0.5h > Remaining Estimate: 0h > > ThinClient doesn't support IndexQuery. Let's fix it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17511) Support IndexQuery for Java ThinClient
[ https://issues.apache.org/jira/browse/IGNITE-17511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-17511: Release Note: Added support of IndexQuery feature in Java thin client. (was: Java ThinClient now supports IndexQuery feature.) > Support IndexQuery for Java ThinClient > -- > > Key: IGNITE-17511 > URL: https://issues.apache.org/jira/browse/IGNITE-17511 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-71, ise > Fix For: 2.14 > > Time Spent: 0.5h > Remaining Estimate: 0h > > ThinClient doesn't support IndexQuery. Let's fix it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-12852) Comma in field is not supported by COPY command
[ https://issues.apache.org/jira/browse/IGNITE-12852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17584664#comment-17584664 ] Taras Ledkov edited comment on IGNITE-12852 at 8/25/22 7:00 AM: [~antkr], please add release notes because two options are added for COPY command. Cherry-picked to [ignite-2.14|https://github.com/apache/ignite/commit/5a59c22960d0d3df3a2c25036b0e5ca86aab950d] was (Author: tledkov): [~antkr], please add release notes because two options are added for COPY command. > Comma in field is not supported by COPY command > --- > > Key: IGNITE-12852 > URL: https://issues.apache.org/jira/browse/IGNITE-12852 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: YuJue Li >Assignee: Anton Kurbanov >Priority: Critical > Fix For: 2.14 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > CREATE TABLE test(a int,b varchar(100),c int,PRIMARY key(a)); > > a.csv: > 1,"a,b",2 > > COPY FROM '/data/a.csv' INTO test (a,b,c) FORMAT CSV; > > The copy command fails because there is a comma in the second field,but this > is a fully legal and compliant CSV format -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-12852) Comma in field is not supported by COPY command
[ https://issues.apache.org/jira/browse/IGNITE-12852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17584664#comment-17584664 ] Taras Ledkov commented on IGNITE-12852: --- [~antkr], please add release notes because two options are added for COPY command. > Comma in field is not supported by COPY command > --- > > Key: IGNITE-12852 > URL: https://issues.apache.org/jira/browse/IGNITE-12852 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: YuJue Li >Assignee: Anton Kurbanov >Priority: Critical > Fix For: 2.14 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > CREATE TABLE test(a int,b varchar(100),c int,PRIMARY key(a)); > > a.csv: > 1,"a,b",2 > > COPY FROM '/data/a.csv' INTO test (a,b,c) FORMAT CSV; > > The copy command fails because there is a comma in the second field,but this > is a fully legal and compliant CSV format -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17511) Support IndexQuery for Java ThinClient
[ https://issues.apache.org/jira/browse/IGNITE-17511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-17511: Release Note: Java ThinClient supports IndexQuery feature. > Support IndexQuery for Java ThinClient > -- > > Key: IGNITE-17511 > URL: https://issues.apache.org/jira/browse/IGNITE-17511 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-71, ise > Fix For: 2.14 > > Time Spent: 0.5h > Remaining Estimate: 0h > > ThinClient doesn't support IndexQuery. Let's fix it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-14914) Support in() clause in IndexQuery.
[
https://issues.apache.org/jira/browse/IGNITE-14914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Timonin updated IGNITE-14914:
Release Note: IndexQuery supports IN criterion:
IndexQuery.setCriteria(in("A", Arrays.asList(1, 2 ,3))).
> Support in() clause in IndexQuery.
> --
>
> Key: IGNITE-14914
> URL: https://issues.apache.org/jira/browse/IGNITE-14914
> Project: Ignite
> Issue Type: New Feature
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Labels: IEP-71, ise
> Fix For: 2.14
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> IndexQuery should support IN criterion:
> {{IndexQuery.setCriteria(in("A", Arrays.asList(1, 2 ,3)));}}
> # IN criterion accepts collection of values to find. This collections is
> transformed to {{SortedSet(1, 2, 3)}} because IndexQuery provides to user
> sorted result.
> # When IN applies on first indexed field - IN(A0, A1) for index (A, B) - it
> converts to multiple {{eq}} operations are joint with OR operation:
> {{{}EQ(A0) or EQ(A1){}}}.
> # Other range criteria for other fields are applied to every such separate
> operation:
> {{IN(A0, A1) and GT(B)}} converts to {{{}(EQ(A0) and GT(B)) or (EQ(A1) and
> GT(B)){}}}.
> # When IN applies to non-leading indexed field - IN(B0, B1) for index (A, B)
> - it works like a filter for prepared range:
> {{GTE(A) and IN(B0, B1)}} converts to range {{[[A, B0]; [A, B1]]}} and every
> cache entry within this range is checked for being included to SortedSet(B0,
> B1).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-12852) Comma in field is not supported by COPY command
[ https://issues.apache.org/jira/browse/IGNITE-12852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17584241#comment-17584241 ] Taras Ledkov edited comment on IGNITE-12852 at 8/25/22 6:53 AM: [~antkr] 1. I guess this patch could be merged because it fixes significant functionality for users. 2. Agreed. I guess we can introduce one or more parse option to tune parser behavior. However, checking that the number of fields in the rows is the same looks good. was (Author: tledkov): [~antkr] 1. I guess this patch could me merged because it fixes significant functionality for users. 2. Agreed. I guess we can introduce one or more parse option to tune parser behavior. However, checking that the number of fields in the rows is the same looks good. > Comma in field is not supported by COPY command > --- > > Key: IGNITE-12852 > URL: https://issues.apache.org/jira/browse/IGNITE-12852 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: YuJue Li >Assignee: Anton Kurbanov >Priority: Critical > Fix For: 2.14 > > Time Spent: 1h > Remaining Estimate: 0h > > CREATE TABLE test(a int,b varchar(100),c int,PRIMARY key(a)); > > a.csv: > 1,"a,b",2 > > COPY FROM '/data/a.csv' INTO test (a,b,c) FORMAT CSV; > > The copy command fails because there is a comma in the second field,but this > is a fully legal and compliant CSV format -- This message was sent by Atlassian Jira (v8.20.10#820010)
