[jira] [Commented] (IGNITE-16040) Calcite. Unable to plan query with several correlated sub-queries in select list
[
https://issues.apache.org/jira/browse/IGNITE-16040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598630#comment-17598630
]
Yury Gerzhedovich commented on IGNITE-16040:
[~zstan], I mean test with select from discription of the ticket.
src/integrationTest/sql/sqlite/select1/select1_erroneous_res.test_ignored
> Calcite. Unable to plan query with several correlated sub-queries in select
> list
>
>
> Key: IGNITE-16040
> URL: https://issues.apache.org/jira/browse/IGNITE-16040
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently the query like below can't be planned by calcite-based sql engine:
> {code:java}
> SELECT a+b*2,
>(a+b+c+d+e)/5,
>(SELECT count(*) FROM t1 AS x WHERE x.c>t1.c AND x.d(SELECT count(*) FROM t1 AS x WHERE x.babs(b-c),
>a-b
> FROM t1
> WHERE EXISTS(SELECT 1 FROM t1 AS x WHERE x.bAND c>d
> ORDER BY 6,5,4,1,3,2
> {code}
> Need to figure it out how to fix this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17606) C++ 3.0: Heartbeats
[ https://issues.apache.org/jira/browse/IGNITE-17606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-17606: - Epic Link: (was: IGNITE-17424) > C++ 3.0: Heartbeats > --- > > Key: IGNITE-17606 > URL: https://issues.apache.org/jira/browse/IGNITE-17606 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Igor Sapego >Priority: Major > Labels: ignite-3 > > Implement heartbeats as described in [IEP-83 Thin Client > Keepalive|https://cwiki.apache.org/confluence/display/IGNITE/IEP-83+Thin+Client+Keepalive]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17605) C++ 3.0: RetryPolicy
[ https://issues.apache.org/jira/browse/IGNITE-17605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-17605: - Epic Link: (was: IGNITE-17424) > C++ 3.0: RetryPolicy > > > Key: IGNITE-17605 > URL: https://issues.apache.org/jira/browse/IGNITE-17605 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Igor Sapego >Priority: Major > Labels: ignite-3 > > Implement RetryPolicy like in 2.x, see > https://cwiki.apache.org/confluence/display/IGNITE/IEP-82+Thin+Client+Retry+Policy > and IGNITE-16026 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17607) C++ 3.0: Compute API
Igor Sapego created IGNITE-17607: Summary: C++ 3.0: Compute API Key: IGNITE-17607 URL: https://issues.apache.org/jira/browse/IGNITE-17607 Project: Ignite Issue Type: New Feature Components: thin client Reporter: Igor Sapego Need to support Compute API in C++ client as it is done for .NET client in IGNITE-16735. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17606) C++ 3.0: Heartbeats
Igor Sapego created IGNITE-17606: Summary: C++ 3.0: Heartbeats Key: IGNITE-17606 URL: https://issues.apache.org/jira/browse/IGNITE-17606 Project: Ignite Issue Type: New Feature Components: thin client Reporter: Igor Sapego Implement heartbeats as described in [IEP-83 Thin Client Keepalive|https://cwiki.apache.org/confluence/display/IGNITE/IEP-83+Thin+Client+Keepalive]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17605) C++ 3.0: RetryPolicy
[ https://issues.apache.org/jira/browse/IGNITE-17605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-17605: - Description: Implement RetryPolicy like in 2.x, see https://cwiki.apache.org/confluence/display/IGNITE/IEP-82+Thin+Client+Retry+Policy and IGNITE-16026 > C++ 3.0: RetryPolicy > > > Key: IGNITE-17605 > URL: https://issues.apache.org/jira/browse/IGNITE-17605 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Igor Sapego >Priority: Major > Labels: ignite-3 > > Implement RetryPolicy like in 2.x, see > https://cwiki.apache.org/confluence/display/IGNITE/IEP-82+Thin+Client+Retry+Policy > and IGNITE-16026 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17605) C++ 3.0: Add RetryPolicy
Igor Sapego created IGNITE-17605: Summary: C++ 3.0: Add RetryPolicy Key: IGNITE-17605 URL: https://issues.apache.org/jira/browse/IGNITE-17605 Project: Ignite Issue Type: New Feature Components: thin client Reporter: Igor Sapego -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17605) C++ 3.0: RetryPolicy
[ https://issues.apache.org/jira/browse/IGNITE-17605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-17605: - Summary: C++ 3.0: RetryPolicy (was: C++ 3.0: Add RetryPolicy) > C++ 3.0: RetryPolicy > > > Key: IGNITE-17605 > URL: https://issues.apache.org/jira/browse/IGNITE-17605 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Igor Sapego >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17604) C++ 3.0: Implement transactions support
Igor Sapego created IGNITE-17604: Summary: C++ 3.0: Implement transactions support Key: IGNITE-17604 URL: https://issues.apache.org/jira/browse/IGNITE-17604 Project: Ignite Issue Type: New Feature Components: thin client Reporter: Igor Sapego Implement transactions support as it was done for Java client in IGNITE-15240 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-16136) System Thread pool starvation and out of memory
[
https://issues.apache.org/jira/browse/IGNITE-16136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598591#comment-17598591
]
Maxim Muzafarov commented on IGNITE-16136:
--
[~Sawfish], [~Norbert Löffler]
Are you using the Apache Ignite 2.7.6 ? I can cherry-pick this issue to the
related branch, so you can test the patch. However, it will be a bit difficult
due to the release is completely outdated and there is no guarantee of success
for that.
> System Thread pool starvation and out of memory
> ---
>
> Key: IGNITE-16136
> URL: https://issues.apache.org/jira/browse/IGNITE-16136
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7.6
>Reporter: David Albrecht
>Assignee: Maxim Muzafarov
>Priority: Critical
> Labels: ise
> Fix For: 2.14
>
> Attachments: configuration.zip, image-2021-12-15-21-13-43-775.png,
> image-2021-12-15-21-17-47-652.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> We are experiencing thread pool starvations and after some time out of memory
> exceptions in some of our ignite client nodes while the server node seems to
> be running without any problems. It seems like all sys threads are stuck when
> calling MarshallerContextImpl.getClassName. Which in turn leads to a growing
> worker queue.
>
> First warnings regarding the thread pool starvation:
> {code:java}
> 10.12.21 11:22:34.603 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:27:34.654 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:32:34.713 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:37:34.764 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:42:34.796 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:47:34.839 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> {code}
> Out of memory error leading to a crash of the application:
> {code}
> Exception: java.lang.OutOfMemoryError thrown from the
> UncaughtExceptionHandler in thread "https-openssl-nio-16443-ClientPoller"
> Exception: java.lang.OutOfMemoryError thrown from the
> UncaughtExceptionHandler in thread "ajp-nio-16009-ClientPoller"
> 11-Dec-2021 03:07:24.446 SEVERE [Catalina-utility-1]
> org.apache.coyote.AbstractProtocol.startAsyncTimeout Error processing async
> timeouts
> java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError:
> Java heap space
> {code}
> The queue full of messages:
> !image-2021-12-15-21-17-47-652.png!
> It seems like all sys threads are stuck while waiting at:
> {code}
> sys-#170
> at jdk.internal.misc.Unsafe.park(ZJ)V (Native Method)
> at java.util.concurrent.locks.LockSupport.park()V (LockSupport.java:323)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(Z)Ljava/lang/Object;
> (GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get()Ljava/lang/Object;
> (GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClassName(BI)Ljava/lang/String;
> (MarshallerContextImpl.java:379)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClass(ILjava/lang/ClassLoader;)Ljava/lang/Class;
> (MarshallerContextImpl.java:344)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(Ljava/util/concurrent/ConcurrentMap;ILjava/lang/ClassLoader;Lorg/apache/ignite/marshaller/MarshallerContext;Lorg/apache/ignite/internal/marshaller/optimized/OptimizedMarshallerIdMapper;)Lorg/apache/ignite/internal/marshaller/optimized/OptimizedClassDescriptor;
> (OptimizedMarshallerUtils.java:264)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0()Ljava/lang/Object;
> (OptimizedObjectInputStream.java:341)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride()Ljava/lang/Object;
>
[jira] [Commented] (IGNITE-16136) System Thread pool starvation and out of memory
[
https://issues.apache.org/jira/browse/IGNITE-16136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598573#comment-17598573
]
Maxim Muzafarov commented on IGNITE-16136:
--
[~tledkov]
You're right. The client node can't handle the mapping request due to the
SYSTEM_POOL is busy by cache event messages. The issue described above related
both for marshalling and binary metadata requests and leads for the system
thread pool starvation.
For the client node binary metadata and marshalling mappings propaged thought
the discovery and communication SPIs. If the client node is waiting for the
reply from the server node and concurrently receives the required mappings from
discovery messages, then we can for sure release the thread locks immediately,
thus no starvation will occur.
Moving processing of such a messages to the dedicated pool sound reasonable for
me, but should be widely discussed with the whole Community. Currently, there
is no need of such an actions to fix the starvation.
> System Thread pool starvation and out of memory
> ---
>
> Key: IGNITE-16136
> URL: https://issues.apache.org/jira/browse/IGNITE-16136
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7.6
>Reporter: David Albrecht
>Assignee: Maxim Muzafarov
>Priority: Critical
> Labels: ise
> Fix For: 2.14
>
> Attachments: configuration.zip, image-2021-12-15-21-13-43-775.png,
> image-2021-12-15-21-17-47-652.png
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> We are experiencing thread pool starvations and after some time out of memory
> exceptions in some of our ignite client nodes while the server node seems to
> be running without any problems. It seems like all sys threads are stuck when
> calling MarshallerContextImpl.getClassName. Which in turn leads to a growing
> worker queue.
>
> First warnings regarding the thread pool starvation:
> {code:java}
> 10.12.21 11:22:34.603 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:27:34.654 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:32:34.713 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:37:34.764 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:42:34.796 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:47:34.839 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> {code}
> Out of memory error leading to a crash of the application:
> {code}
> Exception: java.lang.OutOfMemoryError thrown from the
> UncaughtExceptionHandler in thread "https-openssl-nio-16443-ClientPoller"
> Exception: java.lang.OutOfMemoryError thrown from the
> UncaughtExceptionHandler in thread "ajp-nio-16009-ClientPoller"
> 11-Dec-2021 03:07:24.446 SEVERE [Catalina-utility-1]
> org.apache.coyote.AbstractProtocol.startAsyncTimeout Error processing async
> timeouts
> java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError:
> Java heap space
> {code}
> The queue full of messages:
> !image-2021-12-15-21-17-47-652.png!
> It seems like all sys threads are stuck while waiting at:
> {code}
> sys-#170
> at jdk.internal.misc.Unsafe.park(ZJ)V (Native Method)
> at java.util.concurrent.locks.LockSupport.park()V (LockSupport.java:323)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(Z)Ljava/lang/Object;
> (GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get()Ljava/lang/Object;
> (GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClassName(BI)Ljava/lang/String;
> (MarshallerContextImpl.java:379)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClass(ILjava/lang/ClassLoader;)Ljava/lang/Class;
> (MarshallerContextImpl.java:344)
> at
>
[jira] [Commented] (IGNITE-16136) System Thread pool starvation and out of memory
[
https://issues.apache.org/jira/browse/IGNITE-16136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598569#comment-17598569
]
Ignite TC Bot commented on IGNITE-16136:
{panel:title=Branch: [pull/10204/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10204/head] Base: [master] : New Tests
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Basic 4{color} [[tests
3|https://ci2.ignite.apache.org/viewLog.html?buildId=6584544]]
* {color:#013220}IgniteBasicTestSuite2:
IgniteMarshallerCacheClientRequestsMappingTest.testBinaryMetaDelayedForComputeJobResult
- PASSED{color}
* {color:#013220}IgniteBasicTestSuite2:
IgniteMarshallerCacheClientRequestsMappingTest.testDiscoeryBinaryMetaDelayedWithOverfloodThreadPool
- PASSED{color}
* {color:#013220}IgniteBasicTestSuite2:
IgniteMarshallerCacheClientRequestsMappingTest.testDiscoeryMarshallerDelayedWithOverfloodThreadPool
- PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6584650buildTypeId=IgniteTests24Java8_RunAll]
> System Thread pool starvation and out of memory
> ---
>
> Key: IGNITE-16136
> URL: https://issues.apache.org/jira/browse/IGNITE-16136
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7.6
>Reporter: David Albrecht
>Assignee: Maxim Muzafarov
>Priority: Critical
> Labels: ise
> Fix For: 2.14
>
> Attachments: configuration.zip, image-2021-12-15-21-13-43-775.png,
> image-2021-12-15-21-17-47-652.png
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> We are experiencing thread pool starvations and after some time out of memory
> exceptions in some of our ignite client nodes while the server node seems to
> be running without any problems. It seems like all sys threads are stuck when
> calling MarshallerContextImpl.getClassName. Which in turn leads to a growing
> worker queue.
>
> First warnings regarding the thread pool starvation:
> {code:java}
> 10.12.21 11:22:34.603 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:27:34.654 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:32:34.713 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:37:34.764 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:42:34.796 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:47:34.839 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> {code}
> Out of memory error leading to a crash of the application:
> {code}
> Exception: java.lang.OutOfMemoryError thrown from the
> UncaughtExceptionHandler in thread "https-openssl-nio-16443-ClientPoller"
> Exception: java.lang.OutOfMemoryError thrown from the
> UncaughtExceptionHandler in thread "ajp-nio-16009-ClientPoller"
> 11-Dec-2021 03:07:24.446 SEVERE [Catalina-utility-1]
> org.apache.coyote.AbstractProtocol.startAsyncTimeout Error processing async
> timeouts
> java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError:
> Java heap space
> {code}
> The queue full of messages:
> !image-2021-12-15-21-17-47-652.png!
> It seems like all sys threads are stuck while waiting at:
> {code}
> sys-#170
> at jdk.internal.misc.Unsafe.park(ZJ)V (Native Method)
> at java.util.concurrent.locks.LockSupport.park()V (LockSupport.java:323)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(Z)Ljava/lang/Object;
> (GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get()Ljava/lang/Object;
> (GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClassName(BI)Ljava/lang/String;
> (MarshallerContextImpl.java:379)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClass(ILjava/lang/ClassLoader;)Ljava/lang/Class;
>
[jira] [Comment Edited] (IGNITE-15862) Fix kubernetes ConfigMap docs on site
[ https://issues.apache.org/jira/browse/IGNITE-15862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598565#comment-17598565 ] Aleksandr edited comment on IGNITE-15862 at 8/31/22 6:47 PM: - [~nsafonov] I made a new [PR 10232|https://github.com/apache/ignite/pull/10232] since the previous one was erased by a ticket IGNITE-15197 Could you look at the fix? was (Author: aonikolaev): [~nsafonov] I made a new PR since the previous one was erased by a ticket [IGNITE-15197| https://issues.apache.org/jira/browse/IGNITE-15197] Could you look at the fix? > Fix kubernetes ConfigMap docs on site > - > > Key: IGNITE-15862 > URL: https://issues.apache.org/jira/browse/IGNITE-15862 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Minor > Fix For: 2.14 > > Time Spent: 1h > Remaining Estimate: 0h > > There is an error in the configuration file on the site > node-configuration.xml for ConfigMap in the installation instructions in > kubernetes: > > > although if you follow the instructions, the following values should be > namespace =ignite and serviceName=ignite-service > [https://ignite.apache.org/docs/latest/installation/kubernetes/gke-deployment.html] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-15862) Fix kubernetes ConfigMap docs on site
[ https://issues.apache.org/jira/browse/IGNITE-15862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598565#comment-17598565 ] Aleksandr commented on IGNITE-15862: [~nsafonov] I made a new PR since the previous one was erased by a ticket [IGNITE-15197| https://issues.apache.org/jira/browse/IGNITE-15197] Could you look at the fix? > Fix kubernetes ConfigMap docs on site > - > > Key: IGNITE-15862 > URL: https://issues.apache.org/jira/browse/IGNITE-15862 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Minor > Fix For: 2.14 > > Time Spent: 1h > Remaining Estimate: 0h > > There is an error in the configuration file on the site > node-configuration.xml for ConfigMap in the installation instructions in > kubernetes: > > > although if you follow the instructions, the following values should be > namespace =ignite and serviceName=ignite-service > [https://ignite.apache.org/docs/latest/installation/kubernetes/gke-deployment.html] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15862) Fix kubernetes ConfigMap docs on site
[ https://issues.apache.org/jira/browse/IGNITE-15862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-15862: --- Description: There is an error in the configuration file on the site node-configuration.xml for ConfigMap in the installation instructions in kubernetes: although if you follow the instructions, the following values should be namespace =ignite and serviceName=ignite-service [https://ignite.apache.org/docs/latest/installation/kubernetes/gke-deployment.html] was: There is an error in the configuration file on the site node-configuration.xml for ConfigMap in the installation instructions in kybernetes: although if you follow the instructions, the following values should be namespace =ignite and serviceName=ignite-service https://ignite.apache.org/docs/latest/installation/kubernetes/gke-deployment.html > Fix kubernetes ConfigMap docs on site > - > > Key: IGNITE-15862 > URL: https://issues.apache.org/jira/browse/IGNITE-15862 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Minor > Fix For: 2.14 > > Time Spent: 50m > Remaining Estimate: 0h > > There is an error in the configuration file on the site > node-configuration.xml for ConfigMap in the installation instructions in > kubernetes: > > > although if you follow the instructions, the following values should be > namespace =ignite and serviceName=ignite-service > [https://ignite.apache.org/docs/latest/installation/kubernetes/gke-deployment.html] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17600) Fix control.sh index rebuild args
[
https://issues.apache.org/jira/browse/IGNITE-17600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598554#comment-17598554
]
Ignite TC Bot commented on IGNITE-17600:
{panel:title=Branch: [pull/10228/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10228/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=6583038buildTypeId=IgniteTests24Java8_RunAll]
> Fix control.sh index rebuild args
> --
>
> Key: IGNITE-17600
> URL: https://issues.apache.org/jira/browse/IGNITE-17600
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr
>Assignee: Aleksandr
>Priority: Minor
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The documentation says that the command control.sh --cache
> indexes_force_rebuild accepts arguments --cache-name and --cache-group, but
> in reality it expects --cache-name{*}s{*} and --cache-group{*}s{*}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17260) Enrich IgniteTransactions and Transaction interfaces with RO related methods
[
https://issues.apache.org/jira/browse/IGNITE-17260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-17260:
Assignee: Vyacheslav Koptilin (was: Alexander Lapin)
> Enrich IgniteTransactions and Transaction interfaces with RO related methods
>
>
> Key: IGNITE-17260
> URL: https://issues.apache.org/jira/browse/IGNITE-17260
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Labels: ignite-3, transaction3_ro
>
> It's required to explicitly register an intent of starting readOnly
> transaction, so that overloaded versions
> {code:java}
> Transaction begin(HybridTimestamp timestamp){code}
> and
> {code:java}
> CompletableFuture beginAsync(HybridTimestamp timestamp){code}
> should be added to IgniteTransactions together with corresponding
> implementation.
> Besides that Transaction interface should be extended with
> {code:java}
> boolean isReadOnly();{code}
> and
> {code:java}
> HybridTimestamp timestamp();{code}
> methods.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17260) Enrich IgniteTransactions and Transaction interfaces with RO related methods
[
https://issues.apache.org/jira/browse/IGNITE-17260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-17260:
Assignee: Alexander Lapin (was: Vyacheslav Koptilin)
> Enrich IgniteTransactions and Transaction interfaces with RO related methods
>
>
> Key: IGNITE-17260
> URL: https://issues.apache.org/jira/browse/IGNITE-17260
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
> Labels: ignite-3, transaction3_ro
>
> It's required to explicitly register an intent of starting readOnly
> transaction, so that overloaded versions
> {code:java}
> Transaction begin(HybridTimestamp timestamp){code}
> and
> {code:java}
> CompletableFuture beginAsync(HybridTimestamp timestamp){code}
> should be added to IgniteTransactions together with corresponding
> implementation.
> Besides that Transaction interface should be extended with
> {code:java}
> boolean isReadOnly();{code}
> and
> {code:java}
> HybridTimestamp timestamp();{code}
> methods.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17602) Trace identifier of an exception can be lost during transferring ReplicaRespone from replica node to ReplicaService
[
https://issues.apache.org/jira/browse/IGNITE-17602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598529#comment-17598529
]
Vyacheslav Koptilin commented on IGNITE-17602:
--
Hello [~sanpwc], [~vpyatkov],
Could you please take a look at
https://github.com/gridgain/apache-ignite-3/pull/56 ?
> Trace identifier of an exception can be lost during transferring
> ReplicaRespone from replica node to ReplicaService
> ---
>
> Key: IGNITE-17602
> URL: https://issues.apache.org/jira/browse/IGNITE-17602
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Labels: ignite-3
>
> Current implementation of processing _ReplicaResponse_ has the following
> drawbacks:
> - if sending _ReplicaRequest_ failed for some reason, _ReplicaService_ just
> throw new exception without preserving traceId if it exists
> {code:java}
> return messagingService.invoke(node.address(), req,
> RPC_TIMEOUT).handle((response, throwable) -> {
> if (throwable != null) {
> if (throwable instanceof TimeoutException) {
> throw new ReplicationTimeoutException(req.groupId());
> } else if (throwable instanceof PrimaryReplicaMissException) {
> throw (PrimaryReplicaMissException) throwable;
> }
> throw new ReplicationException(req.groupId(), throwable); <- original
> traceId will be lost
> {code}
> - _ErrorReplicaResponse_ explicitly transfer error code of an exception, its
> traceId etc. It seems to me, we can just transfer an exception (our messaging
> service properly marshal/unmarshal throwables)
> - _org.apache.ignite.internal.replicator.exception.ExceptionUtils_ does not
> care about _IgniteInternalChackedException_. For instance _LockException_
> (which is checked exception) is transformed to _IgniteInternalException_.
> In addition, _TransactionImpl_ does not properly handle _ExecutionException_:
> {code:java}
> @Override
> public void commit() throws TransactionException {
> try {
> commitAsync().get();
> } catch (ExecutionException e) {
> if (e.getCause() instanceof TransactionException) {
> throw (TransactionException) e.getCause();
> } else {
> throw new TransactionException(e.getCause());
> }
> } catch (Exception e) {
> throw new TransactionException(e);
> }
> }
> {code}
> We should not re-throw _e.getCause()_ because we will lost a stack frame
> related to _ExecutionException_, and therefore the resulting stack trace will
> not show a code path/method that called _commit()_.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17602) Trace identifier of an exception can be lost during transferring ReplicaRespone from replica node to ReplicaService
[
https://issues.apache.org/jira/browse/IGNITE-17602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-17602:
-
Description:
Current implementation of processing _ReplicaResponse_ has the following
drawbacks:
- if sending _ReplicaRequest_ failed for some reason, _ReplicaService_ just
throw new exception without preserving traceId if it exists
{code:java}
return messagingService.invoke(node.address(), req,
RPC_TIMEOUT).handle((response, throwable) -> {
if (throwable != null) {
if (throwable instanceof TimeoutException) {
throw new ReplicationTimeoutException(req.groupId());
} else if (throwable instanceof PrimaryReplicaMissException) {
throw (PrimaryReplicaMissException) throwable;
}
throw new ReplicationException(req.groupId(), throwable); <- original
traceId will be lost
{code}
- _ErrorReplicaResponse_ explicitly transfer error code of an exception, its
traceId etc. It seems to me, we can just transfer an exception (our messaging
service properly marshal/unmarshal throwables)
- _org.apache.ignite.internal.replicator.exception.ExceptionUtils_ does not
care about _IgniteInternalChackedException_. For instance _LockException_
(which is checked exception) is transformed to _IgniteInternalException_.
In addition, _TransactionImpl_ does not properly handle _ExecutionException_:
{code:java}
@Override
public void commit() throws TransactionException {
try {
commitAsync().get();
} catch (ExecutionException e) {
if (e.getCause() instanceof TransactionException) {
throw (TransactionException) e.getCause();
} else {
throw new TransactionException(e.getCause());
}
} catch (Exception e) {
throw new TransactionException(e);
}
}
{code}
We should not re-throw _e.getCause()_ because we will lost a stack frame
related to _ExecutionException_, and therefore the resulting stack trace will
not show a code path/method that called _commit()_.
was:
Current implementation of processing ReplicaResponse has the following
drawbacks:
- if sending ReplicaRequest failed for some reason, ReplicaService just throw
new exception without preserving traceId if it exists
{code:java}
return messagingService.invoke(node.address(), req,
RPC_TIMEOUT).handle((response, throwable) -> {
if (throwable != null) {
if (throwable instanceof TimeoutException) {
throw new ReplicationTimeoutException(req.groupId());
} else if (throwable instanceof PrimaryReplicaMissException) {
throw (PrimaryReplicaMissException) throwable;
}
throw new ReplicationException(req.groupId(), throwable); <- original
traceId will be lost
{code}
- ErrorReplicaResponse explicitly transfer error code of exception, its
traceId etc. It seems to me, we can just transfer the exception (our messaging
service properly marshal/unmarshal throwables)
- org.apache.ignite.internal.replicator.exception.ExceptionUtils does not care
about IgniteInternalChackedException. For instance LockException (which is
checked exception) is transformed to IgniteInternalException.
In addition, TransactionImpl does not properly handle ExecutionException:
{code:java}
@Override
public void commit() throws TransactionException {
try {
commitAsync().get();
} catch (ExecutionException e) {
if (e.getCause() instanceof TransactionException) {
throw (TransactionException) e.getCause();
} else {
throw new TransactionException(e.getCause());
}
} catch (Exception e) {
throw new TransactionException(e);
}
}
{code}
We should not re-throw e.getCause() because we will lost a stack frame related
to ExecutionException, and therefore the resulting stack trace will not show a
code path/method that called commit().
> Trace identifier of an exception can be lost during transferring
> ReplicaRespone from replica node to ReplicaService
> ---
>
> Key: IGNITE-17602
> URL: https://issues.apache.org/jira/browse/IGNITE-17602
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Labels: ignite-3
>
> Current implementation of processing _ReplicaResponse_ has the following
> drawbacks:
> - if sending _ReplicaRequest_ failed for some reason, _ReplicaService_ just
> throw new exception without preserving traceId if it exists
> {code:java}
> return messagingService.invoke(node.address(), req,
> RPC_TIMEOUT).handle((response, throwable)
[jira] [Commented] (IGNITE-17603) onGet not triggered in Cache Interceptor
[
https://issues.apache.org/jira/browse/IGNITE-17603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598514#comment-17598514
]
Stephen Darlington commented on IGNITE-17603:
-
Also possibly related to IGNITE-1903 .
> onGet not triggered in Cache Interceptor
>
>
> Key: IGNITE-17603
> URL: https://issues.apache.org/jira/browse/IGNITE-17603
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.9.1
> Environment: Mac, Java 11
>Reporter: Stephen Darlington
>Priority: Major
>
> The onGet method in cache interceptors appears not to be called since version
> 2.9.0. Or at least, the API changed. I have the following code:
> CacheConfiguration cacheConfiguration = new
> CacheConfiguration<>();
> cacheConfiguration.setName("PERSON_CACHE");
> cacheConfiguration.setAtomicityMode(CacheAtomicityMode.ATOMIC);
> cacheConfiguration.setIndexedTypes(Long.class, Person.class);
> cacheConfiguration.setInterceptor(new CacheInterceptor Object>() \{
> @Override
> public Object onGet(Long aLong, Object p) {
> Person person = (Person)p;
> return new Person(new
> StringBuilder(person.getName()).reverse().toString(), person.getHeight());
> }
> @Override
> public Object onBeforePut(Cache.Entry entry, Object
> p) \{
> if (p.getClass().equals(Person.class)) {
> Person person = (Person)p;
> return new Person(new
> StringBuilder(person.getName()).reverse().toString(), person.getHeight());
> }
> else if (p.getClass().equals(BinaryObjectImpl.class)) \{
> BinaryObjectBuilder person = ((BinaryObject)
> p).toBuilder();
> String name = person.getField("name");
> person.setField("name", new
> StringBuilder(name).reverse().toString());
> return person.build();
> }
> else \{
> return null;
> }
> }
> @Override
> public void onAfterPut(Cache.Entry entry) \{
> // do nothing
> }
> @Override
> public IgniteBiTuple
> onBeforeRemove(Cache.Entry entry) \{
> return new IgniteBiTuple<>(true, entry.getValue());
> }
> @Override
> public void onAfterRemove(Cache.Entry entry) \{
> // do nothing
> }
> });
> It reverses the name before storing it and reverses it again on a get. In
> 2.9.0 this works as expected. In every version since it fails. It reverses
> the string on a put but the onGet method never gets called.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17603) onGet not triggered in Cache Interceptor
[
https://issues.apache.org/jira/browse/IGNITE-17603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598513#comment-17598513
]
Stephen Darlington commented on IGNITE-17603:
-
Caused by / related to IGNITE-13417?
> onGet not triggered in Cache Interceptor
>
>
> Key: IGNITE-17603
> URL: https://issues.apache.org/jira/browse/IGNITE-17603
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.9.1
> Environment: Mac, Java 11
>Reporter: Stephen Darlington
>Priority: Major
>
> The onGet method in cache interceptors appears not to be called since version
> 2.9.0. Or at least, the API changed. I have the following code:
> CacheConfiguration cacheConfiguration = new
> CacheConfiguration<>();
> cacheConfiguration.setName("PERSON_CACHE");
> cacheConfiguration.setAtomicityMode(CacheAtomicityMode.ATOMIC);
> cacheConfiguration.setIndexedTypes(Long.class, Person.class);
> cacheConfiguration.setInterceptor(new CacheInterceptor Object>() \{
> @Override
> public Object onGet(Long aLong, Object p) {
> Person person = (Person)p;
> return new Person(new
> StringBuilder(person.getName()).reverse().toString(), person.getHeight());
> }
> @Override
> public Object onBeforePut(Cache.Entry entry, Object
> p) \{
> if (p.getClass().equals(Person.class)) {
> Person person = (Person)p;
> return new Person(new
> StringBuilder(person.getName()).reverse().toString(), person.getHeight());
> }
> else if (p.getClass().equals(BinaryObjectImpl.class)) \{
> BinaryObjectBuilder person = ((BinaryObject)
> p).toBuilder();
> String name = person.getField("name");
> person.setField("name", new
> StringBuilder(name).reverse().toString());
> return person.build();
> }
> else \{
> return null;
> }
> }
> @Override
> public void onAfterPut(Cache.Entry entry) \{
> // do nothing
> }
> @Override
> public IgniteBiTuple
> onBeforeRemove(Cache.Entry entry) \{
> return new IgniteBiTuple<>(true, entry.getValue());
> }
> @Override
> public void onAfterRemove(Cache.Entry entry) \{
> // do nothing
> }
> });
> It reverses the name before storing it and reverses it again on a get. In
> 2.9.0 this works as expected. In every version since it fails. It reverses
> the string on a put but the onGet method never gets called.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17603) onGet not triggered in Cache Interceptor
Stephen Darlington created IGNITE-17603:
---
Summary: onGet not triggered in Cache Interceptor
Key: IGNITE-17603
URL: https://issues.apache.org/jira/browse/IGNITE-17603
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.9.1
Environment: Mac, Java 11
Reporter: Stephen Darlington
The onGet method in cache interceptors appears not to be called since version
2.9.0. Or at least, the API changed. I have the following code:
CacheConfiguration cacheConfiguration = new
CacheConfiguration<>();
cacheConfiguration.setName("PERSON_CACHE");
cacheConfiguration.setAtomicityMode(CacheAtomicityMode.ATOMIC);
cacheConfiguration.setIndexedTypes(Long.class, Person.class);
cacheConfiguration.setInterceptor(new CacheInterceptor()
\{
@Override
public Object onGet(Long aLong, Object p) {
Person person = (Person)p;
return new Person(new
StringBuilder(person.getName()).reverse().toString(), person.getHeight());
}
@Override
public Object onBeforePut(Cache.Entry entry, Object
p) \{
if (p.getClass().equals(Person.class)) {
Person person = (Person)p;
return new Person(new
StringBuilder(person.getName()).reverse().toString(), person.getHeight());
}
else if (p.getClass().equals(BinaryObjectImpl.class)) \{
BinaryObjectBuilder person = ((BinaryObject) p).toBuilder();
String name = person.getField("name");
person.setField("name", new
StringBuilder(name).reverse().toString());
return person.build();
}
else \{
return null;
}
}
@Override
public void onAfterPut(Cache.Entry entry) \{
// do nothing
}
@Override
public IgniteBiTuple
onBeforeRemove(Cache.Entry entry) \{
return new IgniteBiTuple<>(true, entry.getValue());
}
@Override
public void onAfterRemove(Cache.Entry entry) \{
// do nothing
}
});
It reverses the name before storing it and reverses it again on a get. In 2.9.0
this works as expected. In every version since it fails. It reverses the string
on a put but the onGet method never gets called.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17499) Service method invocation excepition is not propagated to thin client side.
[ https://issues.apache.org/jira/browse/IGNITE-17499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-17499: Fix Version/s: 2.14 > Service method invocation excepition is not propagated to thin client side. > --- > > Key: IGNITE-17499 > URL: https://issues.apache.org/jira/browse/IGNITE-17499 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Labels: ise > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > https://issues.apache.org/jira/browse/IGNITE-13389 introduced dedicated flag > that make it possible to propagate server side stacktrace to a thin client > side. The mentoined above propagation does not work for exceptions that > arises during Ignite Service invocation. > Steps to reproduce: > 1. Start .Net Ignite node > 2. Deploy service which invocation throws an arbitrary uncaught exception > 3. Invoke previously deployed services via Java thin client > As a result, information about the custom code exception is not present in > the exception stacktrace that is thrown after the service call. > The main reason of such behaviour is that > ClientServiceInvokeRequest.java:198 does not propagate initial exception. So > ClientRequestHandler#handleException could not handle exception properly even > if ThinClientConfiguration#sendServerExceptionStackTraceToClient() is enabled. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17602) Trace identifier of an exception can be lost during transferring ReplicaRespone from replica node to ReplicaService
[
https://issues.apache.org/jira/browse/IGNITE-17602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-17602:
-
Description:
Current implementation of processing ReplicaResponse has the following
drawbacks:
- if sending ReplicaRequest failed for some reason, ReplicaService just throw
new exception without preserving traceId if it exists
{code:java}
return messagingService.invoke(node.address(), req,
RPC_TIMEOUT).handle((response, throwable) -> {
if (throwable != null) {
if (throwable instanceof TimeoutException) {
throw new ReplicationTimeoutException(req.groupId());
} else if (throwable instanceof PrimaryReplicaMissException) {
throw (PrimaryReplicaMissException) throwable;
}
throw new ReplicationException(req.groupId(), throwable); <- original
traceId will be lost
{code}
- ErrorReplicaResponse explicitly transfer error code of exception, its
traceId etc. It seems to me, we can just transfer the exception (our messaging
service properly marshal/unmarshal throwables)
- org.apache.ignite.internal.replicator.exception.ExceptionUtils does not care
about IgniteInternalChackedException. For instance LockException (which is
checked exception) is transformed to IgniteInternalException.
In addition, TransactionImpl does not properly handle ExecutionException:
{code:java}
@Override
public void commit() throws TransactionException {
try {
commitAsync().get();
} catch (ExecutionException e) {
if (e.getCause() instanceof TransactionException) {
throw (TransactionException) e.getCause();
} else {
throw new TransactionException(e.getCause());
}
} catch (Exception e) {
throw new TransactionException(e);
}
}
{code}
We should not re-throw e.getCause() because we will lost a stack frame related
to ExecutionException, and therefore the resulting stack trace will not show a
code path/method that called commit().
> Trace identifier of an exception can be lost during transferring
> ReplicaRespone from replica node to ReplicaService
> ---
>
> Key: IGNITE-17602
> URL: https://issues.apache.org/jira/browse/IGNITE-17602
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Labels: ignite-3
>
> Current implementation of processing ReplicaResponse has the following
> drawbacks:
> - if sending ReplicaRequest failed for some reason, ReplicaService just
> throw new exception without preserving traceId if it exists
> {code:java}
> return messagingService.invoke(node.address(), req,
> RPC_TIMEOUT).handle((response, throwable) -> {
> if (throwable != null) {
> if (throwable instanceof TimeoutException) {
> throw new ReplicationTimeoutException(req.groupId());
> } else if (throwable instanceof PrimaryReplicaMissException) {
> throw (PrimaryReplicaMissException) throwable;
> }
> throw new ReplicationException(req.groupId(), throwable); <- original
> traceId will be lost
> {code}
> - ErrorReplicaResponse explicitly transfer error code of exception, its
> traceId etc. It seems to me, we can just transfer the exception (our
> messaging service properly marshal/unmarshal throwables)
> - org.apache.ignite.internal.replicator.exception.ExceptionUtils does not
> care about IgniteInternalChackedException. For instance LockException (which
> is checked exception) is transformed to IgniteInternalException.
> In addition, TransactionImpl does not properly handle ExecutionException:
> {code:java}
> @Override
> public void commit() throws TransactionException {
> try {
> commitAsync().get();
> } catch (ExecutionException e) {
> if (e.getCause() instanceof TransactionException) {
> throw (TransactionException) e.getCause();
> } else {
> throw new TransactionException(e.getCause());
> }
> } catch (Exception e) {
> throw new TransactionException(e);
> }
> }
> {code}
> We should not re-throw e.getCause() because we will lost a stack frame
> related to ExecutionException, and therefore the resulting stack trace will
> not show a code path/method that called commit().
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17499) Service method invocation excepition is not propagated to thin client side.
[ https://issues.apache.org/jira/browse/IGNITE-17499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598464#comment-17598464 ] Ivan Daschinsky commented on IGNITE-17499: -- [~PetrovMikhail] [~tledkov] May be this ticket is worth to be added in 2.14? > Service method invocation excepition is not propagated to thin client side. > --- > > Key: IGNITE-17499 > URL: https://issues.apache.org/jira/browse/IGNITE-17499 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > > https://issues.apache.org/jira/browse/IGNITE-13389 introduced dedicated flag > that make it possible to propagate server side stacktrace to a thin client > side. The mentoined above propagation does not work for exceptions that > arises during Ignite Service invocation. > Steps to reproduce: > 1. Start .Net Ignite node > 2. Deploy service which invocation throws an arbitrary uncaught exception > 3. Invoke previously deployed services via Java thin client > As a result, information about the custom code exception is not present in > the exception stacktrace that is thrown after the service call. > The main reason of such behaviour is that > ClientServiceInvokeRequest.java:198 does not propagate initial exception. So > ClientRequestHandler#handleException could not handle exception properly even > if ThinClientConfiguration#sendServerExceptionStackTraceToClient() is enabled. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17499) Service method invocation excepition is not propagated to thin client side.
[ https://issues.apache.org/jira/browse/IGNITE-17499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598454#comment-17598454 ] Mikhail Petrov commented on IGNITE-17499: - [~xtern] Thanks for the review. > Service method invocation excepition is not propagated to thin client side. > --- > > Key: IGNITE-17499 > URL: https://issues.apache.org/jira/browse/IGNITE-17499 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > > https://issues.apache.org/jira/browse/IGNITE-13389 introduced dedicated flag > that make it possible to propagate server side stacktrace to a thin client > side. The mentoined above propagation does not work for exceptions that > arises during Ignite Service invocation. > Steps to reproduce: > 1. Start .Net Ignite node > 2. Deploy service which invocation throws an arbitrary uncaught exception > 3. Invoke previously deployed services via Java thin client > As a result, information about the custom code exception is not present in > the exception stacktrace that is thrown after the service call. > The main reason of such behaviour is that > ClientServiceInvokeRequest.java:198 does not propagate initial exception. So > ClientRequestHandler#handleException could not handle exception properly even > if ThinClientConfiguration#sendServerExceptionStackTraceToClient() is enabled. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17602) Trace identifier of an exception can be lost during transferring ReplicaRespone from replica node to ReplicaService
Vyacheslav Koptilin created IGNITE-17602: Summary: Trace identifier of an exception can be lost during transferring ReplicaRespone from replica node to ReplicaService Key: IGNITE-17602 URL: https://issues.apache.org/jira/browse/IGNITE-17602 Project: Ignite Issue Type: Bug Reporter: Vyacheslav Koptilin Assignee: Vyacheslav Koptilin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17499) Service method invocation excepition is not propagated to thin client side.
[ https://issues.apache.org/jira/browse/IGNITE-17499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-17499: -- Release Note: Fixed propagation of a service call exception stacktrace to the client side. (was: Fixed propagation of service call exception stacktrace to the client side.) > Service method invocation excepition is not propagated to thin client side. > --- > > Key: IGNITE-17499 > URL: https://issues.apache.org/jira/browse/IGNITE-17499 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > > https://issues.apache.org/jira/browse/IGNITE-13389 introduced dedicated flag > that make it possible to propagate server side stacktrace to a thin client > side. The mentoined above propagation does not work for exceptions that > arises during Ignite Service invocation. > Steps to reproduce: > 1. Start .Net Ignite node > 2. Deploy service which invocation throws an arbitrary uncaught exception > 3. Invoke previously deployed services via Java thin client > As a result, information about the custom code exception is not present in > the exception stacktrace that is thrown after the service call. > The main reason of such behaviour is that > ClientServiceInvokeRequest.java:198 does not propagate initial exception. So > ClientRequestHandler#handleException could not handle exception properly even > if ThinClientConfiguration#sendServerExceptionStackTraceToClient() is enabled. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17499) Service method invocation excepition is not propagated to thin client side.
[ https://issues.apache.org/jira/browse/IGNITE-17499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-17499: -- Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Service method invocation excepition is not propagated to thin client side. > --- > > Key: IGNITE-17499 > URL: https://issues.apache.org/jira/browse/IGNITE-17499 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > > https://issues.apache.org/jira/browse/IGNITE-13389 introduced dedicated flag > that make it possible to propagate server side stacktrace to a thin client > side. The mentoined above propagation does not work for exceptions that > arises during Ignite Service invocation. > Steps to reproduce: > 1. Start .Net Ignite node > 2. Deploy service which invocation throws an arbitrary uncaught exception > 3. Invoke previously deployed services via Java thin client > As a result, information about the custom code exception is not present in > the exception stacktrace that is thrown after the service call. > The main reason of such behaviour is that > ClientServiceInvokeRequest.java:198 does not propagate initial exception. So > ClientRequestHandler#handleException could not handle exception properly even > if ThinClientConfiguration#sendServerExceptionStackTraceToClient() is enabled. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17499) Service method invocation excepition is not propagated to thin client side.
[
https://issues.apache.org/jira/browse/IGNITE-17499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598440#comment-17598440
]
Ignite TC Bot commented on IGNITE-17499:
{panel:title=Branch: [pull/10186/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10186/head] Base: [master] : New Tests
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Platform .NET (Windows){color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6583119]]
* {color:#013220}exe:
ClientConnectionTest.TestSendServerServiceExceptionStackTraceToClient -
PASSED{color}
{color:#8b}Platform .NET (Core Linux){color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6583118]]
* {color:#013220}DotNetCore:
ClientConnectionTest.TestSendServerServiceExceptionStackTraceToClient -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6583150buildTypeId=IgniteTests24Java8_RunAll]
> Service method invocation excepition is not propagated to thin client side.
> ---
>
> Key: IGNITE-17499
> URL: https://issues.apache.org/jira/browse/IGNITE-17499
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Minor
> Labels: ise
>
> https://issues.apache.org/jira/browse/IGNITE-13389 introduced dedicated flag
> that make it possible to propagate server side stacktrace to a thin client
> side. The mentoined above propagation does not work for exceptions that
> arises during Ignite Service invocation.
> Steps to reproduce:
> 1. Start .Net Ignite node
> 2. Deploy service which invocation throws an arbitrary uncaught exception
> 3. Invoke previously deployed services via Java thin client
> As a result, information about the custom code exception is not present in
> the exception stacktrace that is thrown after the service call.
> The main reason of such behaviour is that
> ClientServiceInvokeRequest.java:198 does not propagate initial exception. So
> ClientRequestHandler#handleException could not handle exception properly even
> if ThinClientConfiguration#sendServerExceptionStackTraceToClient() is enabled.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17585) flaky ItCommonApiTest.testSessionExpiration
[
https://issues.apache.org/jira/browse/IGNITE-17585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598410#comment-17598410
]
Yury Gerzhedovich commented on IGNITE-17585:
Tests was unstable due to session expiration period just 1 ms and periodically
GC consume the timeand query doesn't start. The second potential issue of the
test using Thread.sleep itself instead of waitForCondition. To fix the second
part has been inroduced ability retrieve information about live sessions, which
will be usefull for future functionality like a VIEW with a active sessions.
> flaky ItCommonApiTest.testSessionExpiration
> ---
>
> Key: IGNITE-17585
> URL: https://issues.apache.org/jira/browse/IGNITE-17585
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The test ItCommonApiTest.testSessionExpiration is flaky. Let's fix it.
> https://ci.ignite.apache.org/test/-6167055026598275943?currentProjectId=ignite3_Test_IntegrationTests=%3Cdefault%3E
> {code:java}
> org.apache.ignite.lang.IgniteExceptionorg.apache.ignite.lang.IgniteException:
> IGN-CMN-65535 TraceId:336fba3d-323a-4107-8ec1-a31ecfe6cfec IGN-CMN-65535
> TraceId:336fba3d-323a-4107-8ec1-a31ecfe6cfec IGN-CMN-65535
> TraceId:a7e3c0ff-7642-410c-8caa-8790d6ed7c6f at
> org.apache.ignite.internal.sql.api.ItCommonApiTest.testSessionExpiration(ItCommonApiTest.java:68)Caused
> by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:336fba3d-323a-4107-8ec1-a31ecfe6cfec IGN-CMN-65535
> TraceId:a7e3c0ff-7642-410c-8caa-8790d6ed7c6fCaused by:
> org.apache.ignite.internal.sql.engine.exec.ExecutionCancelledException:
> IGN-CMN-65535 TraceId:a7e3c0ff-7642-410c-8caa-8790d6ed7c6f {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17541) Add "set" prefix to ThinClientConfiguration#sendServerExceptionStackTraceToClient()
[
https://issues.apache.org/jira/browse/IGNITE-17541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598401#comment-17598401
]
Ignite TC Bot commented on IGNITE-17541:
{panel:title=Branch: [pull/10230/head] Base: [master] : Possible Blockers
(107)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Windows){color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583231]]
{color:#d04437}Cache 1{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583158]]
{color:#d04437}PDS 2{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583217]]
{color:#d04437}Cache 2{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583163]]
{color:#d04437}SPI (Discovery){color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583247]]
{color:#d04437}Platform C++ CMake (Linux){color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583228]]
{color:#d04437}Platform C++ CMake (Win x64 / Release){color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583227]]
{color:#d04437}PDS 6{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583221]]
{color:#d04437}Cache 13{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583162]]
{color:#d04437}PDS (Indexing){color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583225]]
{color:#d04437}Platform C++ CMake (Linux Clang){color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583229]]
{color:#d04437}Cache (Restarts) 2{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583181]]
{color:#d04437}SPI{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583246]]
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583230]]
{color:#d04437}Continuous Query 2{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583191]]
{color:#d04437}Cache 5{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583166]]
{color:#d04437}Queries 2 (lazy=true){color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583235]]
{color:#d04437}Queries 2{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583234]]
{color:#d04437}PDS 4{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583219]]
{color:#d04437}Cache 3{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583164]]
{color:#d04437}Control Utility{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583194]]
{color:#d04437}PDS (Compatibility){color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583224]]
{color:#d04437}Cache 7{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583168]]
{color:#d04437}Binary Objects{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583157]]
{color:#d04437}Cache (Restarts) 1{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583180]]
{color:#d04437}Cache 12{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583161]]
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583258]]
{color:#d04437}JDBC Driver{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583208]]
{color:#d04437}PDS 3{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583218]]
{color:#d04437}Queries 3 (lazy=true){color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583237]]
{color:#d04437}Cache (Failover) 1{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583173]]
{color:#d04437}Cache (Deadlock Detection){color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583171]]
{color:#d04437}Java Client{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583205]]
{color:#d04437}Basic 1{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583153]]
{color:#d04437}Thin client: Python{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583256]]
{color:#d04437}Cache 6{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583167]]
{color:#d04437}Compute (Affinity Run){color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583187]]
{color:#d04437}Queries 3{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583236]]
{color:#d04437}Cache (Failover)
[jira] [Updated] (IGNITE-17596) ItThinClientComputeTest fails on Windows
[
https://issues.apache.org/jira/browse/IGNITE-17596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Pochatkin updated IGNITE-17596:
---
Epic Link: IGNITE-17601
> ItThinClientComputeTest fails on Windows
>
>
> Key: IGNITE-17596
> URL: https://issues.apache.org/jira/browse/IGNITE-17596
> Project: Ignite
> Issue Type: Bug
>Reporter: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{ItThinClientComputeTest}} fails on Windows due to the not correlated
> changes in two tickets.
> In IGNITE-16734 the test was added which compared the result of
> {{NodeNameJob}} to the hardcoded string.
> In IGNITE-16691
> {{org.apache.ignite.internal.testframework.IgniteTestUtils#testNodeName}} was
> changed so on Windows node name in those tests is now not the expected
> {{"ItThinClientComputeTest_null_3344"}}, but short {{"n_3344"}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17601) Fix flaky tests and Windows incompatibility in tests
Mikhail Pochatkin created IGNITE-17601: -- Summary: Fix flaky tests and Windows incompatibility in tests Key: IGNITE-17601 URL: https://issues.apache.org/jira/browse/IGNITE-17601 Project: Ignite Issue Type: Epic Reporter: Mikhail Pochatkin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17541) Add "set" prefix to ThinClientConfiguration#sendServerExceptionStackTraceToClient()
[
https://issues.apache.org/jira/browse/IGNITE-17541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598394#comment-17598394
]
Ignite TC Bot commented on IGNITE-17541:
{panel:title=Branch: [pull/10230/head] Base: [master] : Possible Blockers
(107)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Windows){color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583231]]
{color:#d04437}Cache 1{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583158]]
{color:#d04437}PDS 2{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583217]]
{color:#d04437}Cache 2{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583163]]
{color:#d04437}SPI (Discovery){color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583247]]
{color:#d04437}Platform C++ CMake (Linux){color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583228]]
{color:#d04437}Platform C++ CMake (Win x64 / Release){color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583227]]
{color:#d04437}PDS 6{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583221]]
{color:#d04437}Cache 13{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583162]]
{color:#d04437}PDS (Indexing){color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583225]]
{color:#d04437}Platform C++ CMake (Linux Clang){color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583229]]
{color:#d04437}Cache (Restarts) 2{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583181]]
{color:#d04437}SPI{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583246]]
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583230]]
{color:#d04437}Continuous Query 2{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583191]]
{color:#d04437}Cache 5{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583166]]
{color:#d04437}Queries 2 (lazy=true){color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583235]]
{color:#d04437}Queries 2{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583234]]
{color:#d04437}PDS 4{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583219]]
{color:#d04437}Cache 3{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583164]]
{color:#d04437}Control Utility{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583194]]
{color:#d04437}PDS (Compatibility){color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583224]]
{color:#d04437}Cache 7{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583168]]
{color:#d04437}Binary Objects{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583157]]
{color:#d04437}Cache (Restarts) 1{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583180]]
{color:#d04437}Cache 12{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583161]]
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583258]]
{color:#d04437}JDBC Driver{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583208]]
{color:#d04437}PDS 3{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583218]]
{color:#d04437}Queries 3 (lazy=true){color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583237]]
{color:#d04437}Cache (Failover) 1{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583173]]
{color:#d04437}Cache (Deadlock Detection){color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583171]]
{color:#d04437}Java Client{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583205]]
{color:#d04437}Basic 1{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583153]]
{color:#d04437}Thin client: Python{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583256]]
{color:#d04437}Cache 6{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583167]]
{color:#d04437}Compute (Affinity Run){color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583187]]
{color:#d04437}Queries 3{color} [[tests 0
CANCELLED|https://ci2.ignite.apache.org/viewLog.html?buildId=6583236]]
{color:#d04437}Cache (Failover)
[jira] [Commented] (IGNITE-16882) Enlist txnState into single parition only
[
https://issues.apache.org/jira/browse/IGNITE-16882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598368#comment-17598368
]
Sergey Uttsel commented on IGNITE-16882:
LGTM.
> Enlist txnState into single parition only
> -
>
> Key: IGNITE-16882
> URL: https://issues.apache.org/jira/browse/IGNITE-16882
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
> Labels: ignite-3, transaction3_rw
>
> Currenlly txState(PENDING|ABORTED|COMMITED) is updated within all enlisted
> partitions which is not an atomic solution. According to new tx design it's
> required to replicate tx state with single partition only.
> As a prerequisite persisted replicated TxnStateStore should be introduced
> https://issues.apache.org/jira/browse/IGNITE-15931
> Such introduction will allow to rework existing tx implementaiton in order to
> store txState only within single partition.
> instead of using
> {code:java}
> partId = abs(txId.hashCode() % partCnt) {code}
> we might use any other idempotent funtion, e.g. first partition of first
> enlisted key.
> Tx.Phase1
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-16882) Enlist txnState into single parition only
[
https://issues.apache.org/jira/browse/IGNITE-16882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598366#comment-17598366
]
Vladislav Pyatkov commented on IGNITE-16882:
LGTM
> Enlist txnState into single parition only
> -
>
> Key: IGNITE-16882
> URL: https://issues.apache.org/jira/browse/IGNITE-16882
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
> Labels: ignite-3, transaction3_rw
>
> Currenlly txState(PENDING|ABORTED|COMMITED) is updated within all enlisted
> partitions which is not an atomic solution. According to new tx design it's
> required to replicate tx state with single partition only.
> As a prerequisite persisted replicated TxnStateStore should be introduced
> https://issues.apache.org/jira/browse/IGNITE-15931
> Such introduction will allow to rework existing tx implementaiton in order to
> store txState only within single partition.
> instead of using
> {code:java}
> partId = abs(txId.hashCode() % partCnt) {code}
> we might use any other idempotent funtion, e.g. first partition of first
> enlisted key.
> Tx.Phase1
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17599) Calcite engine. Support LocalDate/LocalTime types
[
https://issues.apache.org/jira/browse/IGNITE-17599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-17599:
-
Labels: calcite2-required calcite3-required (was: )
> Calcite engine. Support LocalDate/LocalTime types
> -
>
> Key: IGNITE-17599
> URL: https://issues.apache.org/jira/browse/IGNITE-17599
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
>
> H2-based engine works with LocalData/LocalTime types as
> java.sql.Data/java.sql.Time types. To check if value with LocalDate type can
> be inserted to descriptor with type java.sql.Data some logic from
> \{{IgniteH2Indexing.isConvertibleToColumnType}} is used. If Calcite engine
> used without ignite-indexing this logic is unavailable.
> We should:
> # Provide an ability to work in Calcite-based engine with
> LocalDate/LocalTime type in the same way as java.sql.Data/java.sql.Time types.
> # Move \{{IgniteH2Indexing.isConvertibleToColumnType}} logic to the core
> module (perhaps delegating this call from the core to the QueryEngine
> instance)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17596) ItThinClientComputeTest fails on Windows
[
https://issues.apache.org/jira/browse/IGNITE-17596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-17596:
-
Labels: ignite-3 (was: )
> ItThinClientComputeTest fails on Windows
>
>
> Key: IGNITE-17596
> URL: https://issues.apache.org/jira/browse/IGNITE-17596
> Project: Ignite
> Issue Type: Bug
>Reporter: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{ItThinClientComputeTest}} fails on Windows due to the not correlated
> changes in two tickets.
> In IGNITE-16734 the test was added which compared the result of
> {{NodeNameJob}} to the hardcoded string.
> In IGNITE-16691
> {{org.apache.ignite.internal.testframework.IgniteTestUtils#testNodeName}} was
> changed so on Windows node name in those tests is now not the expected
> {{"ItThinClientComputeTest_null_3344"}}, but short {{"n_3344"}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17558) Performance issue while putting stream of data to ignite cache along with searching cache in parallel
[ https://issues.apache.org/jira/browse/IGNITE-17558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598344#comment-17598344 ] Vyacheslav Koptilin commented on IGNITE-17558: -- Hello [~shahidcse...@gmail.com], Thread dumps your attached do not give any clue. The system and striped pools do nothing. This means that ignite node is not under load. Could you please create a simple project/benchmark that demonstrates the problem? > Performance issue while putting stream of data to ignite cache along with > searching cache in parallel > -- > > Key: IGNITE-17558 > URL: https://issues.apache.org/jira/browse/IGNITE-17558 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.11.1 >Reporter: Mohammed Shahid >Priority: Critical > Attachments: roc-ignite.xml, tc1dump.txt, tc4dump.txt > > > I am using 3 node ignite configuration. when i am increasing number of read > and write in parallel the performance of ignite cache response is getting > degraded. > Use case: I need to perform duplicate check for last 7 days of data. > > attached thread dump and ignite configuration file. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17508) Exception handling in the partition replication listener for RAFT futures
[
https://issues.apache.org/jira/browse/IGNITE-17508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598342#comment-17598342
]
Vladislav Pyatkov commented on IGNITE-17508:
Merged e4cc995b22e74078f72f4520feb18a8088833f4b
> Exception handling in the partition replication listener for RAFT futures
> -
>
> Key: IGNITE-17508
> URL: https://issues.apache.org/jira/browse/IGNITE-17508
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> In the replication listener ({_}PartitionReplicaListener{_}) where we have
> the pattern:
> {code:java}
> raftFut.thenApply(ignored -> result);{code}
> we should worry about handling RAFT exceptions, including analyzing whether
> raftFut result.
> Can distinguish following exception types for RAFT:
> * RAFT cannot replicate a command for the timeout ({_}TimeoutException{_}).
> Hence, this exception leads to the replication timeout exception
> ({_}ReplicationTimeoutException{_}).
> * It throws some internal exception ({_}RaftException{_}). This exception
> should be wrapped of the common replication exception
> ({_}ReplicationException{_}).
> * Finally, RAFT throws java exceptions (NullPointerException,
> IndexOutOfRangeException e.t.c). Those exceptions shouldn't be touched, is
> will be through as is.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17508) Exception handling in the partition replication listener for RAFT futures
[
https://issues.apache.org/jira/browse/IGNITE-17508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598341#comment-17598341
]
Vladislav Pyatkov commented on IGNITE-17508:
It will be merged to the feature branch
[ignite3_tx|https://github.com/gridgain/apache-ignite-3/tree/ignite3_tx].
> Exception handling in the partition replication listener for RAFT futures
> -
>
> Key: IGNITE-17508
> URL: https://issues.apache.org/jira/browse/IGNITE-17508
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> In the replication listener ({_}PartitionReplicaListener{_}) where we have
> the pattern:
> {code:java}
> raftFut.thenApply(ignored -> result);{code}
> we should worry about handling RAFT exceptions, including analyzing whether
> raftFut result.
> Can distinguish following exception types for RAFT:
> * RAFT cannot replicate a command for the timeout ({_}TimeoutException{_}).
> Hence, this exception leads to the replication timeout exception
> ({_}ReplicationTimeoutException{_}).
> * It throws some internal exception ({_}RaftException{_}). This exception
> should be wrapped of the common replication exception
> ({_}ReplicationException{_}).
> * Finally, RAFT throws java exceptions (NullPointerException,
> IndexOutOfRangeException e.t.c). Those exceptions shouldn't be touched, is
> will be through as is.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17442) Colorize Ignite test console output
[
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-17442:
--
Summary: Colorize Ignite test console output (was: Colorize Ignite console
output)
> Colorize Ignite test console output
> ---
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: test-framework
> Attachments: LayoutConverterDraft.java, log4j2-test.xml,
> prod-propsal.png
>
>
> Recently completed Ignite migration to use log4j2. So we can use ["highlight"
> conversion
> pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to
> colorize the output.
> Initial proposal for production console output (pretty similar to spring
> boot).
> !prod-propsal.png|width=679,height=337!
> Pattern for log4j 2.18+
> {code:xml}
> pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink,
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold,
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
> %m%n"/>
> {code}
> For the test framework, there is a suggestion - to color the output of each
> node with its own color. Apparently this can't be done without adding your
> own plugin, for example LogEventPatternConverter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17442) Colorize Ignite console output
[
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-17442:
--
Labels: test-framework (was: )
> Colorize Ignite console output
> --
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: test-framework
> Attachments: LayoutConverterDraft.java, log4j2-test.xml,
> prod-propsal.png
>
>
> Recently completed Ignite migration to use log4j2. So we can use ["highlight"
> conversion
> pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to
> colorize the output.
> Initial proposal for production console output (pretty similar to spring
> boot).
> !prod-propsal.png|width=679,height=337!
> Pattern for log4j 2.18+
> {code:xml}
> pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink,
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold,
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
> %m%n"/>
> {code}
> For the test framework, there is a suggestion - to color the output of each
> node with its own color. Apparently this can't be done without adding your
> own plugin, for example LogEventPatternConverter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17508) Exception handling in the partition replication listener for RAFT futures
[
https://issues.apache.org/jira/browse/IGNITE-17508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598300#comment-17598300
]
Sergey Uttsel commented on IGNITE-17508:
[~v.pyatkov] LGTM
> Exception handling in the partition replication listener for RAFT futures
> -
>
> Key: IGNITE-17508
> URL: https://issues.apache.org/jira/browse/IGNITE-17508
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> In the replication listener ({_}PartitionReplicaListener{_}) where we have
> the pattern:
> {code:java}
> raftFut.thenApply(ignored -> result);{code}
> we should worry about handling RAFT exceptions, including analyzing whether
> raftFut result.
> Can distinguish following exception types for RAFT:
> * RAFT cannot replicate a command for the timeout ({_}TimeoutException{_}).
> Hence, this exception leads to the replication timeout exception
> ({_}ReplicationTimeoutException{_}).
> * It throws some internal exception ({_}RaftException{_}). This exception
> should be wrapped of the common replication exception
> ({_}ReplicationException{_}).
> * Finally, RAFT throws java exceptions (NullPointerException,
> IndexOutOfRangeException e.t.c). Those exceptions shouldn't be touched, is
> will be through as is.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17561) SQLException: Hexadecimal string with odd number of characters
[
https://issues.apache.org/jira/browse/IGNITE-17561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598294#comment-17598294
]
Dren commented on IGNITE-17561:
---
Hi [~jooger] ,
I have noticed that this problem occured only on tables where PK contains
timestamp column.
> SQLException: Hexadecimal string with odd number of characters
> --
>
> Key: IGNITE-17561
> URL: https://issues.apache.org/jira/browse/IGNITE-17561
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.13
> Environment: Ignite 2.13.0
>Reporter: Dren
>Priority: Critical
> Attachments: CREATE_TABLE_STAT_ENRICH_PROCESSOR.sql, Ignite_log.txt,
> data_sample_in_table.jpg, error_sql1.jpg, ok_sql2.jpg
>
>
> After in place upgrade from 2.7.6 to 2.13.0 SQL failed with error.
> {code:java}
> //
> Caused by: org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number
> of characters: "2022-08-22 10:30:58.938" [90003-197]
> at
> org.h2.message.DbException.getJdbcSQLException(DbException.java:357)
> ... 57 more {code}
> After creation of new table with same columns and same data SQL return result
> without error.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17339) Implement B+Tree based hash index storage
[ https://issues.apache.org/jira/browse/IGNITE-17339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov reassigned IGNITE-17339: -- Assignee: Ivan Bessonov (was: Kirill Tkalenko) > Implement B+Tree based hash index storage > - > > Key: IGNITE-17339 > URL: https://issues.apache.org/jira/browse/IGNITE-17339 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > > Please refer to IGNITE-17320 and issues from the epic for the gist. It's > basically the same thing, but with hash slapped inside of the tree pages and > a simplified comparison algorithm. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17535) Implementing a hash index B+Tree
[ https://issues.apache.org/jira/browse/IGNITE-17535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598283#comment-17598283 ] Semyon Danilov commented on IGNITE-17535: - The patch looks good to me! > Implementing a hash index B+Tree > > > Key: IGNITE-17535 > URL: https://issues.apache.org/jira/browse/IGNITE-17535 > Project: Ignite > Issue Type: Task >Reporter: Kirill Tkalenko >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > Time Spent: 1h > Remaining Estimate: 0h > > It is necessary to implement a hash index B+Tree, for simplicity, without > inlining a *BinaryTuple*, but simply storing a link to it. > The key will be: hash and link of the *BinaryTuple*. > The value will be: *RowId*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17535) Implementing a hash index B+Tree
[ https://issues.apache.org/jira/browse/IGNITE-17535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semyon Danilov updated IGNITE-17535: Reviewer: Semyon Danilov > Implementing a hash index B+Tree > > > Key: IGNITE-17535 > URL: https://issues.apache.org/jira/browse/IGNITE-17535 > Project: Ignite > Issue Type: Task >Reporter: Kirill Tkalenko >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > Time Spent: 1h > Remaining Estimate: 0h > > It is necessary to implement a hash index B+Tree, for simplicity, without > inlining a *BinaryTuple*, but simply storing a link to it. > The key will be: hash and link of the *BinaryTuple*. > The value will be: *RowId*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17600) Fix control.sh index rebuild args
[
https://issues.apache.org/jira/browse/IGNITE-17600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr updated IGNITE-17600:
---
Fix Version/s: 2.14
> Fix control.sh index rebuild args
> --
>
> Key: IGNITE-17600
> URL: https://issues.apache.org/jira/browse/IGNITE-17600
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr
>Assignee: Aleksandr
>Priority: Minor
> Fix For: 2.14
>
>
> The documentation says that the command control.sh --cache
> indexes_force_rebuild accepts arguments --cache-name and --cache-group, but
> in reality it expects --cache-name{*}s{*} and --cache-group{*}s{*}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17587) The "io.datastorage.StorageSize" metric shows incorrect values in case of multiple persistence dataregions
[
https://issues.apache.org/jira/browse/IGNITE-17587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-17587:
-
Fix Version/s: 2.14
> The "io.datastorage.StorageSize" metric shows incorrect values in case of
> multiple persistence dataregions
> --
>
> Key: IGNITE-17587
> URL: https://issues.apache.org/jira/browse/IGNITE-17587
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: ise
> Fix For: 2.14
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The metric was broken after IGNITE-13207: it sets the value of the last group
> instead of the sum of all groups. See
> {{DataStorageMetricsImpl#onStorageSizeChanged}} for details.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17587) The "io.datastorage.StorageSize" metric shows incorrect values in case of multiple persistence dataregions
[
https://issues.apache.org/jira/browse/IGNITE-17587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598277#comment-17598277
]
Ignite TC Bot commented on IGNITE-17587:
{panel:title=Branch: [pull/10225/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10225/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=6581801buildTypeId=IgniteTests24Java8_RunAll]
> The "io.datastorage.StorageSize" metric shows incorrect values in case of
> multiple persistence dataregions
> --
>
> Key: IGNITE-17587
> URL: https://issues.apache.org/jira/browse/IGNITE-17587
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: ise
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The metric was broken after IGNITE-13207: it sets the value of the last group
> instead of the sum of all groups. See
> {{DataStorageMetricsImpl#onStorageSizeChanged}} for details.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17576) Update Ignite dependency: MySQL Connector
[
https://issues.apache.org/jira/browse/IGNITE-17576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598273#comment-17598273
]
Ignite TC Bot commented on IGNITE-17576:
{panel:title=Branch: [pull/10223/head] Base: [master] : Possible Blockers
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 2{color} [[tests 0 TIMEOUT , Exit Code
|https://ci2.ignite.apache.org/viewLog.html?buildId=6582783]]
{color:#d04437}PDS (Indexing){color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6582845]]
* IgnitePdsWithIndexingCoreTestSuite:
IgniteWalRecoveryTest.testRecoveryNoCheckpoint - Test has low fail rate in base
branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/10223/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=6582882buildTypeId=IgniteTests24Java8_RunAll]
> 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: Minor
> Labels: ise, newbie
> Fix For: 2.14
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Update Ignite dependency: MySQL Connector 8.0.26 to 8.0.30 to avoid CVE
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17600) Fix control.sh index rebuild args
Aleksandr created IGNITE-17600:
--
Summary: Fix control.sh index rebuild args
Key: IGNITE-17600
URL: https://issues.apache.org/jira/browse/IGNITE-17600
Project: Ignite
Issue Type: Improvement
Reporter: Aleksandr
Assignee: Aleksandr
The documentation says that the command control.sh --cache
indexes_force_rebuild accepts arguments --cache-name and --cache-group, but in
reality it expects --cache-name{*}s{*} and --cache-group{*}s{*}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17552) The snapshot error is not propagated to the initiating node if it is not the coordinator.
[
https://issues.apache.org/jira/browse/IGNITE-17552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-17552:
--
Fix Version/s: 2.14
(was: 2.15)
> The snapshot error is not propagated to the initiating node if it is not the
> coordinator.
> -
>
> Key: IGNITE-17552
> URL: https://issues.apache.org/jira/browse/IGNITE-17552
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Stepanov Ilya
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: iep-43, ise
> Fix For: 2.14
>
> Attachments: error.log
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In some cases, when we execute "createSnapshot" on non-coordinator node, the
> snapshot error is not reported in the "LastSnapshotErrorMessage" metric, but
> the "LastSnapshotStartTime" and "LastSnapshotErrorMessage" metrics are
> updated.
> This is misleading that the snapshot was taken successfully.
> The problem concerns not only metrics, despite the error, the user future
> completes successfully and error does not reach the user.
> Reproducer:
> {code:java}
> startGridsWithCache(2, dfltCacheCfg, CACHE_KEYS_RANGE);
> // Must fail, but on non-coordinator finishes successfully.
>
> grid(1).context().cache().context().snapshotMgr().createSnapshot(SNAPSHOT_NAME,
> "/bad/path").get();
> // Fails (as expected).
>
> grid(0).context().cache().context().snapshotMgr().createSnapshot(SNAPSHOT_NAME,
> "/bad/path").get();
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17552) The snapshot error is not propagated to the initiating node if it is not the coordinator.
[
https://issues.apache.org/jira/browse/IGNITE-17552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598258#comment-17598258
]
Pavel Pereslegin commented on IGNITE-17552:
---
[~ivandasch], thanks for the suggestion,
cherry picked into ignite-2.14 branch.
> The snapshot error is not propagated to the initiating node if it is not the
> coordinator.
> -
>
> Key: IGNITE-17552
> URL: https://issues.apache.org/jira/browse/IGNITE-17552
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Stepanov Ilya
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: iep-43, ise
> Fix For: 2.15
>
> Attachments: error.log
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In some cases, when we execute "createSnapshot" on non-coordinator node, the
> snapshot error is not reported in the "LastSnapshotErrorMessage" metric, but
> the "LastSnapshotStartTime" and "LastSnapshotErrorMessage" metrics are
> updated.
> This is misleading that the snapshot was taken successfully.
> The problem concerns not only metrics, despite the error, the user future
> completes successfully and error does not reach the user.
> Reproducer:
> {code:java}
> startGridsWithCache(2, dfltCacheCfg, CACHE_KEYS_RANGE);
> // Must fail, but on non-coordinator finishes successfully.
>
> grid(1).context().cache().context().snapshotMgr().createSnapshot(SNAPSHOT_NAME,
> "/bad/path").get();
> // Fails (as expected).
>
> grid(0).context().cache().context().snapshotMgr().createSnapshot(SNAPSHOT_NAME,
> "/bad/path").get();
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-13726) Add an ability to view count of hot and cold pages in page memory
[ https://issues.apache.org/jira/browse/IGNITE-13726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-13726: --- Release Note: Added system view and histogram to show the distribution of hot and cold pages in the page memory > Add an ability to view count of hot and cold pages in page memory > - > > Key: IGNITE-13726 > URL: https://issues.apache.org/jira/browse/IGNITE-13726 > Project: Ignite > Issue Type: New Feature >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: IEP-35, iep-62 > Fix For: 2.14 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently, we can't determine how many hot (touched recently) and cold pages > we have in the page-memory. This information can be helpful for data region > size tuning and can show the effectiveness of the page replacement algorithm. > Such information can be represented as a histogram showing the count of pages > last touched in each time interval. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17111) Remove the ability to set the lazy flag in SqlFieldsQuery
[ https://issues.apache.org/jira/browse/IGNITE-17111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598235#comment-17598235 ] Evgeny Stanilovsky commented on IGNITE-17111: - [~AldoRaine] i don`t understand your question, is this issue still actual ? > Remove the ability to set the lazy flag in SqlFieldsQuery > - > > Key: IGNITE-17111 > URL: https://issues.apache.org/jira/browse/IGNITE-17111 > Project: Ignite > Issue Type: Improvement >Reporter: Luchnikov Alexander >Priority: Minor > Labels: ise > > Remove the ability to set the lazy flag in SqlFieldsQuery. SqlFieldsQuery > must always be executed as lazy=true. > This property > (org.apache.igniteIgniteSystemProperties#IGNITE_SQL_FORCE_LAZY_RESULT_SET) > refers to the same functionality, but is not used in the code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17585) flaky ItCommonApiTest.testSessionExpiration
[
https://issues.apache.org/jira/browse/IGNITE-17585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598234#comment-17598234
]
Yury Gerzhedovich commented on IGNITE-17585:
[~zstan], thanks for the review. Please check again
> flaky ItCommonApiTest.testSessionExpiration
> ---
>
> Key: IGNITE-17585
> URL: https://issues.apache.org/jira/browse/IGNITE-17585
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The test ItCommonApiTest.testSessionExpiration is flaky. Let's fix it.
> https://ci.ignite.apache.org/test/-6167055026598275943?currentProjectId=ignite3_Test_IntegrationTests=%3Cdefault%3E
> {code:java}
> org.apache.ignite.lang.IgniteExceptionorg.apache.ignite.lang.IgniteException:
> IGN-CMN-65535 TraceId:336fba3d-323a-4107-8ec1-a31ecfe6cfec IGN-CMN-65535
> TraceId:336fba3d-323a-4107-8ec1-a31ecfe6cfec IGN-CMN-65535
> TraceId:a7e3c0ff-7642-410c-8caa-8790d6ed7c6f at
> org.apache.ignite.internal.sql.api.ItCommonApiTest.testSessionExpiration(ItCommonApiTest.java:68)Caused
> by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:336fba3d-323a-4107-8ec1-a31ecfe6cfec IGN-CMN-65535
> TraceId:a7e3c0ff-7642-410c-8caa-8790d6ed7c6fCaused by:
> org.apache.ignite.internal.sql.engine.exec.ExecutionCancelledException:
> IGN-CMN-65535 TraceId:a7e3c0ff-7642-410c-8caa-8790d6ed7c6f {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17552) The snapshot error is not propagated to the initiating node if it is not the coordinator.
[
https://issues.apache.org/jira/browse/IGNITE-17552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598229#comment-17598229
]
Ivan Daschinsky commented on IGNITE-17552:
--
[~xtern] [~tledkov] I suppose this patch could be added to 2.14, couldn't it?
> The snapshot error is not propagated to the initiating node if it is not the
> coordinator.
> -
>
> Key: IGNITE-17552
> URL: https://issues.apache.org/jira/browse/IGNITE-17552
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Stepanov Ilya
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: iep-43, ise
> Fix For: 2.15
>
> Attachments: error.log
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In some cases, when we execute "createSnapshot" on non-coordinator node, the
> snapshot error is not reported in the "LastSnapshotErrorMessage" metric, but
> the "LastSnapshotStartTime" and "LastSnapshotErrorMessage" metrics are
> updated.
> This is misleading that the snapshot was taken successfully.
> The problem concerns not only metrics, despite the error, the user future
> completes successfully and error does not reach the user.
> Reproducer:
> {code:java}
> startGridsWithCache(2, dfltCacheCfg, CACHE_KEYS_RANGE);
> // Must fail, but on non-coordinator finishes successfully.
>
> grid(1).context().cache().context().snapshotMgr().createSnapshot(SNAPSHOT_NAME,
> "/bad/path").get();
> // Fails (as expected).
>
> grid(0).context().cache().context().snapshotMgr().createSnapshot(SNAPSHOT_NAME,
> "/bad/path").get();
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17594) Provide ability to register listeners for query start/finish events
[
https://issues.apache.org/jira/browse/IGNITE-17594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Novikov updated IGNITE-17594:
Description:
Need to expose internal API to provide ability to listen query start/finish
events.
Need to pass following properties: query, queryType,
schemaName, startTime, finishTime, local, {{{}cancellable{}}},
{{{}enforceJoinOrder{}}}, {{{}lazy{}}}, {{{}distributedJoins{}}},
{{failedReason}}
was:
Need to expose internal API to provide ability to listen query start/finish
events.
Need to pass following properties: local, {{{}cancellable{}}},
{{{}enforceJoinOrder{}}}, {{{}lazy{}}}, {{{}distributedJoins{}}},
{{failedReason}}
> Provide ability to register listeners for query start/finish events
> ---
>
> Key: IGNITE-17594
> URL: https://issues.apache.org/jira/browse/IGNITE-17594
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Andrey Novikov
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.15
>
>
> Need to expose internal API to provide ability to listen query start/finish
> events.
> Need to pass following properties: query, queryType,
> schemaName, startTime, finishTime, local, {{{}cancellable{}}},
> {{{}enforceJoinOrder{}}}, {{{}lazy{}}}, {{{}distributedJoins{}}},
> {{failedReason}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17594) Provide ability to register listeners for query start/finish events
[
https://issues.apache.org/jira/browse/IGNITE-17594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Novikov updated IGNITE-17594:
Description:
Need to expose internal API to provide ability to listen query start/finish
events.
Need to pass following properties: local, {{{}cancellable{}}},
{{{}enforceJoinOrder{}}}, {{{}lazy{}}}, {{{}distributedJoins{}}},
{{failedReason}}
was:
To improve monitor of running queries on node we need to pass following
properties {{{}cancellable{}}},
{{{}enforceJoinOrder{}}},{{{}lazy{}}},{{{}distributedJoins{}}},{{{}failedReason{}}}
to existing listeners IgniteH2Indexing#registerQueryStartedListener,
IgniteH2Indexing#registerQueryFinishedListener.
*What to do:*
Add
{{{}enforceJoinOrder{}}},{{{}lazy{}}},{{{}distributedJoins{}}},{{{}failedReason{}}}
to GridQueryFinishedInfo
Add {{{}cancellable{}}},
{{{}enforceJoinOrder{}}},{{{}lazy{}}},{{{}distributedJoins{}}} to
GridQueryStartedInfo
> Provide ability to register listeners for query start/finish events
> ---
>
> Key: IGNITE-17594
> URL: https://issues.apache.org/jira/browse/IGNITE-17594
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Andrey Novikov
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.15
>
>
> Need to expose internal API to provide ability to listen query start/finish
> events.
> Need to pass following properties: local, {{{}cancellable{}}},
> {{{}enforceJoinOrder{}}}, {{{}lazy{}}}, {{{}distributedJoins{}}},
> {{failedReason}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17594) Provide ability to register listeners for query start/finish events
[
https://issues.apache.org/jira/browse/IGNITE-17594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Novikov updated IGNITE-17594:
Summary: Provide ability to register listeners for query start/finish
events (was: Improve structures for query monitoring)
> Provide ability to register listeners for query start/finish events
> ---
>
> Key: IGNITE-17594
> URL: https://issues.apache.org/jira/browse/IGNITE-17594
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Andrey Novikov
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.15
>
>
> To improve monitor of running queries on node we need to pass following
> properties {{{}cancellable{}}},
> {{{}enforceJoinOrder{}}},{{{}lazy{}}},{{{}distributedJoins{}}},{{{}failedReason{}}}
> to existing listeners IgniteH2Indexing#registerQueryStartedListener,
> IgniteH2Indexing#registerQueryFinishedListener.
> *What to do:*
> Add
> {{{}enforceJoinOrder{}}},{{{}lazy{}}},{{{}distributedJoins{}}},{{{}failedReason{}}}
> to GridQueryFinishedInfo
> Add {{{}cancellable{}}},
> {{{}enforceJoinOrder{}}},{{{}lazy{}}},{{{}distributedJoins{}}} to
> GridQueryStartedInfo
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17580) Deprecate SchemaBuilder public API
[ https://issues.apache.org/jira/browse/IGNITE-17580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598223#comment-17598223 ] Evgeny Stanilovsky commented on IGNITE-17580: - looks good > Deprecate SchemaBuilder public API > -- > > Key: IGNITE-17580 > URL: https://issues.apache.org/jira/browse/IGNITE-17580 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > Time Spent: 10m > Remaining Estimate: 0h > > Let's deprecate or move to internal packages, SchemaBuilder public API before > release 3.0 Beta. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17576) Update Ignite dependency: MySQL Connector
[
https://issues.apache.org/jira/browse/IGNITE-17576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598220#comment-17598220
]
Ignite TC Bot commented on IGNITE-17576:
{panel:title=Branch: [pull/10223/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Queries 1{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6581515]]
* IgniteBinaryCacheQueryTestSuite:
DynamicIndexServerCoordinatorBasicSelfTest.testCreateReplicatedTransactional -
Test has low fail rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/10223/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=6581545buildTypeId=IgniteTests24Java8_RunAll]
> 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: Minor
> Labels: ise, newbie
> Fix For: 2.14
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Update Ignite dependency: MySQL Connector 8.0.26 to 8.0.30 to avoid CVE
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-16040) Calcite. Unable to plan query with several correlated sub-queries in select list
[
https://issues.apache.org/jira/browse/IGNITE-16040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598201#comment-17598201
]
Evgeny Stanilovsky commented on IGNITE-16040:
-
[~jooger] what tests you are talking about ? did i miss smt?
> Calcite. Unable to plan query with several correlated sub-queries in select
> list
>
>
> Key: IGNITE-16040
> URL: https://issues.apache.org/jira/browse/IGNITE-16040
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently the query like below can't be planned by calcite-based sql engine:
> {code:java}
> SELECT a+b*2,
>(a+b+c+d+e)/5,
>(SELECT count(*) FROM t1 AS x WHERE x.c>t1.c AND x.d(SELECT count(*) FROM t1 AS x WHERE x.babs(b-c),
>a-b
> FROM t1
> WHERE EXISTS(SELECT 1 FROM t1 AS x WHERE x.bAND c>d
> ORDER BY 6,5,4,1,3,2
> {code}
> Need to figure it out how to fix this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17585) flaky ItCommonApiTest.testSessionExpiration
[
https://issues.apache.org/jira/browse/IGNITE-17585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598197#comment-17598197
]
Evgeny Stanilovsky commented on IGNITE-17585:
-
[~jooger] fill some comments, check plz.
> flaky ItCommonApiTest.testSessionExpiration
> ---
>
> Key: IGNITE-17585
> URL: https://issues.apache.org/jira/browse/IGNITE-17585
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The test ItCommonApiTest.testSessionExpiration is flaky. Let's fix it.
> https://ci.ignite.apache.org/test/-6167055026598275943?currentProjectId=ignite3_Test_IntegrationTests=%3Cdefault%3E
> {code:java}
> org.apache.ignite.lang.IgniteExceptionorg.apache.ignite.lang.IgniteException:
> IGN-CMN-65535 TraceId:336fba3d-323a-4107-8ec1-a31ecfe6cfec IGN-CMN-65535
> TraceId:336fba3d-323a-4107-8ec1-a31ecfe6cfec IGN-CMN-65535
> TraceId:a7e3c0ff-7642-410c-8caa-8790d6ed7c6f at
> org.apache.ignite.internal.sql.api.ItCommonApiTest.testSessionExpiration(ItCommonApiTest.java:68)Caused
> by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:336fba3d-323a-4107-8ec1-a31ecfe6cfec IGN-CMN-65535
> TraceId:a7e3c0ff-7642-410c-8caa-8790d6ed7c6fCaused by:
> org.apache.ignite.internal.sql.engine.exec.ExecutionCancelledException:
> IGN-CMN-65535 TraceId:a7e3c0ff-7642-410c-8caa-8790d6ed7c6f {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17473) Support transactional scan for RW transaction
[ https://issues.apache.org/jira/browse/IGNITE-17473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-17473: -- Description: We need to support transactional scan in SQL engine. At the moment, the transactional protocol has a restriction such that the scan must be issued on the node that initiated the transaction. This makes optimisations related to a distributed sql execution barely usable, but we will deal with this later. As a first step, let's just disable distribution trait in the planner to get local plans. was: We need to support transactional scan in SQL engine. At the moment, the transactional protocol has a restriction such that the scan must be issued on the node that initiated the transaction. This makes optimisations related to a distributed sql execution barely usable, but we will deal with this later. As a first step, let's just disable distribution trait in the planner to get a local plans. > Support transactional scan for RW transaction > - > > Key: IGNITE-17473 > URL: https://issues.apache.org/jira/browse/IGNITE-17473 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > We need to support transactional scan in SQL engine. > At the moment, the transactional protocol has a restriction such that the > scan must be issued on the node that initiated the transaction. This makes > optimisations related to a distributed sql execution barely usable, but we > will deal with this later. As a first step, let's just disable distribution > trait in the planner to get local plans. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17473) Support transactional scan for RW transaction
[ https://issues.apache.org/jira/browse/IGNITE-17473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-17473: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Support transactional scan for RW transaction > - > > Key: IGNITE-17473 > URL: https://issues.apache.org/jira/browse/IGNITE-17473 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > We need to support transactional scan in SQL engine. > At the moment, the transactional protocol has a restriction such that the > scan must be issued on the node that initiated the transaction. This makes > optimisations related to a distributed sql execution barely usable, but we > will deal with this later. As a first step, let's just disable distribution > trait in the planner to get local plans. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17473) Support transactional scan for RW transaction
[ https://issues.apache.org/jira/browse/IGNITE-17473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-17473: -- Description: We need to support transactional scan in SQL engine. At the moment, the transactional protocol has a restriction such that the scan must be issued on the node that initiated the transaction. This makes optimisations related to a distributed sql execution barely usable, but we will deal with this later. As a first step, let's just disable distribution trait in the planner to get a local plans. was: We need to support transactional scan in SQL engine. At the moment, the transactional protocol has a restriction such that the scan must be initiated on the node that initiated the transaction. This makes optimisations related to a distributed sql execution barely usable, but we will deal with this later. As a first step, let's just disable distribution trait in the planner to get a local plans. > Support transactional scan for RW transaction > - > > Key: IGNITE-17473 > URL: https://issues.apache.org/jira/browse/IGNITE-17473 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > We need to support transactional scan in SQL engine. > At the moment, the transactional protocol has a restriction such that the > scan must be issued on the node that initiated the transaction. This makes > optimisations related to a distributed sql execution barely usable, but we > will deal with this later. As a first step, let's just disable distribution > trait in the planner to get a local plans. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17473) Support transactional scan for RW transaction
[ https://issues.apache.org/jira/browse/IGNITE-17473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-17473: -- Description: We need to support transactional scan in SQL engine. At the moment, the transactional protocol has a restriction such that the scan must be initiated on the node that initiated the transaction. This makes optimisations related to a distributed sql execution barely usable, but we will deal with this later. As a first step, let's just disable distribution trait in the planner to get a local plans. was: Right now transaction not sending to remote nodes, so we don't use single transaction for whole query (transaction scan is not possible). Need to transfer transaction metadata to remote nodes and use it during scan. Seems required transfer just transaction id and recover transaction by the id (build transaction instance limited transaction, don't go to transaction coordinator) on remote nodes, however need to understand should we do enlist partitions for scan. Start point: org.apache.ignite.internal.sql.engine.exec.rel.TableScanNode#request > Support transactional scan for RW transaction > - > > Key: IGNITE-17473 > URL: https://issues.apache.org/jira/browse/IGNITE-17473 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > We need to support transactional scan in SQL engine. > At the moment, the transactional protocol has a restriction such that the > scan must be initiated on the node that initiated the transaction. This makes > optimisations related to a distributed sql execution barely usable, but we > will deal with this later. As a first step, let's just disable distribution > trait in the planner to get a local plans. -- This message was sent by Atlassian Jira (v8.20.10#820010)
