[jira] [Created] (IGNITE-18807) Cache generated classes for future reuse
Ivan Bessonov created IGNITE-18807: -- Summary: Cache generated classes for future reuse Key: IGNITE-18807 URL: https://issues.apache.org/jira/browse/IGNITE-18807 Project: Ignite Issue Type: Improvement Reporter: Ivan Bessonov Assignee: Ivan Bessonov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18023) Implement GC API in page Memory based MV partition storages
[ https://issues.apache.org/jira/browse/IGNITE-18023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-18023: - Fix Version/s: 3.0.0-beta2 > Implement GC API in page Memory based MV partition storages > --- > > Key: IGNITE-18023 > URL: https://issues.apache.org/jira/browse/IGNITE-18023 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Please refer to Epic for details. > What I assume should happen: we probably need a hard synchronization on > RowIds. And by that I mean a striped lock for reading/writing from/into a > chain. > I see no other options, but if there are better ideas - go ahead. > All tests should pass, maybe more tests added if there are problems > discovered. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18806) Update Events Page on the Website
[ https://issues.apache.org/jira/browse/IGNITE-18806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kseniya Romanova updated IGNITE-18806: -- Description: Please update the pages with events 1) https://ignite.apache.org/ here in the FEATURED EVENT section we need to change 2022 Summit for the 2023 upcoming event [2) https://ignite.apache.org/events.html|https://ignite.apache.org/events.html] * Put to the FEATURED EVENT section the upcoming summit (June 6) * Please move past events from the UPCOMING EVENTS SCHEDULE * Please add to the past offline event these 2 below 15 December 2023 How did we build rebalance into the distributed database architecture Vlad will describe how the rebalance procedure is changed due to developing replication protocols, and how former processes modified in the new circumstances. Vlad Pyatkov Highload++ Armenia Yerevan, Armenia Link: [https://highload.am/2022/abstracts/9687] 15 December 2023 Practical aspects of B+ trees Many engineers are familiar with B+ tree data structure and its application inside DBMS. But how does it work internally in order to provide concurrency, reliability, high throughput and all the other great features? In the talk Nikolay will try to give brief overview of methods and tweaks from real-world DB. Nikolay Izhikov Highload++ Armenia Yerevan, Armenia Link: [https://highload.am/2022/abstracts/9677] was: Please update the page [https://ignite.apache.org/events.html] 1)Put to the FEATURED EVENT section the upcoming summit (June 6) 2)Please move past events from the UPCOMING EVENTS SCHEDULE 3)Please add to the past offline event these 2: 15 December 2023 How did we build rebalance into the distributed database architecture Vlad will describe how the rebalance procedure is changed due to developing replication protocols, and how former processes modified in the new circumstances. Vlad Pyatkov Highload++ Armenia Yerevan, Armenia Link: https://highload.am/2022/abstracts/9687 15 December 2023 Practical aspects of B+ trees Many engineers are familiar with B+ tree data structure and its application inside DBMS. But how does it work internally in order to provide concurrency, reliability, high throughput and all the other great features? In the talk Nikolay will try to give brief overview of methods and tweaks from real-world DB. Nikolay Izhikov Highload++ Armenia Yerevan, Armenia Link: https://highload.am/2022/abstracts/9677 > Update Events Page on the Website > - > > Key: IGNITE-18806 > URL: https://issues.apache.org/jira/browse/IGNITE-18806 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Kseniya Romanova >Assignee: Erlan Aytpaev >Priority: Major > > Please update the pages with events > 1) https://ignite.apache.org/ > here in the FEATURED EVENT section we need to change 2022 Summit for the > 2023 upcoming event > [2) > https://ignite.apache.org/events.html|https://ignite.apache.org/events.html] > * Put to the FEATURED EVENT section the upcoming summit (June 6) > * Please move past events from the UPCOMING EVENTS SCHEDULE > * Please add to the past offline event these 2 below > > 15 December 2023 > How did we build rebalance into the distributed database architecture > Vlad will describe how the rebalance procedure is changed due to developing > replication protocols, and how former processes modified in the new > circumstances. > Vlad Pyatkov > Highload++ Armenia > Yerevan, Armenia > Link: [https://highload.am/2022/abstracts/9687] > 15 December 2023 > Practical aspects of B+ trees > Many engineers are familiar with B+ tree data structure and its application > inside DBMS. But how does it work internally in order to provide concurrency, > reliability, high throughput and all the other great features? In the talk > Nikolay will try to give brief overview of methods and tweaks from real-world > DB. > Nikolay Izhikov > Highload++ Armenia > Yerevan, Armenia > Link: [https://highload.am/2022/abstracts/9677] > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18806) Update Events Page on the Website
Kseniya Romanova created IGNITE-18806: - Summary: Update Events Page on the Website Key: IGNITE-18806 URL: https://issues.apache.org/jira/browse/IGNITE-18806 Project: Ignite Issue Type: Task Components: website Reporter: Kseniya Romanova Assignee: Erlan Aytpaev Please update the page [https://ignite.apache.org/events.html] 1)Put to the FEATURED EVENT section the upcoming summit (June 6) 2)Please move past events from the UPCOMING EVENTS SCHEDULE 3)Please add to the past offline event these 2: 15 December 2023 How did we build rebalance into the distributed database architecture Vlad will describe how the rebalance procedure is changed due to developing replication protocols, and how former processes modified in the new circumstances. Vlad Pyatkov Highload++ Armenia Yerevan, Armenia Link: https://highload.am/2022/abstracts/9687 15 December 2023 Practical aspects of B+ trees Many engineers are familiar with B+ tree data structure and its application inside DBMS. But how does it work internally in order to provide concurrency, reliability, high throughput and all the other great features? In the talk Nikolay will try to give brief overview of methods and tweaks from real-world DB. Nikolay Izhikov Highload++ Armenia Yerevan, Armenia Link: https://highload.am/2022/abstracts/9677 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18645) Sql. Type System. Reject plans with not matching dynamic parameters types during query validation.
[ https://issues.apache.org/jira/browse/IGNITE-18645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-18645: -- Description: Current implementation of dynamic parameters does not allow to reject plans that may fail runtime. Solution: * dynamic parameters can be casted to appropriate types depending on the current context. If E1 with operand O1 expects a type T1 dynamic parameter D1 must be explicitly casted to T1 if it is possible. And if a cast is not possible a query must be rejected. * in order to make type inference/type coercion possible we should use types of concrete values of dynamic parameters specified with a query. This is a topic for discussion and investigation. was: Current implementation of dynamic parameters does not allow to reject plans that may fail runtime. Solution: * dynamic parameters can be casted to appropriate types depending on the current context. If E1 with operand O1 expects a type T1 dynamic parameter D1 must be explicitly casted T1 if it possible if a cast is not possible a query must be rejected. * in order to make type inference/type coercion possible we should use types of concrete values of dynamic parameters specified with a query. This is a topic for discussion and investigation. > Sql. Type System. Reject plans with not matching dynamic parameters types > during query validation. > -- > > Key: IGNITE-18645 > URL: https://issues.apache.org/jira/browse/IGNITE-18645 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Major > Labels: calcite2-required, calcite3-required, ignite-3 > Fix For: 3.0.0-beta2 > > > Current implementation of dynamic parameters does not allow to reject plans > that may fail runtime. Solution: > * dynamic parameters can be casted to appropriate types depending on the > current context. If E1 with operand O1 expects a type T1 dynamic parameter D1 > must be explicitly casted to T1 if it is possible. And if a cast is not > possible a query must be rejected. > * in order to make type inference/type coercion possible we should use types > of concrete values of dynamic parameters specified with a query. > This is a topic for discussion and investigation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18803) Fix compilation error of ignite-hibernate-ext
[
https://issues.apache.org/jira/browse/IGNITE-18803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Nikolaev updated IGNITE-18803:
Labels: ise newbie (was: newbie)
> Fix compilation error of ignite-hibernate-ext
> -
>
> Key: IGNITE-18803
> URL: https://issues.apache.org/jira/browse/IGNITE-18803
> Project: Ignite
> Issue Type: Bug
> Components: extensions
> Environment:
>Reporter: Ilya Shishkov
>Assignee: Aleksandr Nikolaev
>Priority: Minor
> Labels: ise, newbie
>
> Build fails because {{CacheMetricsMXBean}} was deleted from Apache Ignite:
> {noformat}
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[44,32]
> cannot find symbol
> symbol: class CacheMetricsMXBean
> location: package org.apache.ignite.mxbean
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[549,22]
> cannot find symbol
> symbol: class CacheMetricsMXBean
> location: class org.apache.ignite.cache.hibernate.HibernateCacheProxy
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[554,22]
> cannot find symbol
> symbol: class CacheMetricsMXBean
> location: class org.apache.ignite.cache.hibernate.HibernateCacheProxy
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[549,5]
> method does not override or implement a method from a supertype
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[550,30]
> cannot find symbol
> symbol: method clusterMxBean()
> location: interface
> org.apache.ignite.internal.processors.cache.IgniteInternalCache
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[554,5]
> method does not override or implement a method from a supertype
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[555,30]
> cannot find symbol
> symbol: method localMxBean()
> location: interface
> org.apache.ignite.internal.processors.cache.IgniteInternalCache
> {noformat}
> Build history on TC1 & TC2:
> #
> https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?branch=%3Cdefault%3E&mode=builds
> #
> https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?branch=%3Cdefault%3E&mode=builds
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18804) Sql. TPC-H. ClassCastException in aggregate functions.
[
https://issues.apache.org/jira/browse/IGNITE-18804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18804:
--
Summary: Sql. TPC-H. ClassCastException in aggregate functions. (was: Sql.
Tpc-H. ClassCastException in aggregate functions.)
> Sql. TPC-H. ClassCastException in aggregate functions.
> --
>
> Key: IGNITE-18804
> URL: https://issues.apache.org/jira/browse/IGNITE-18804
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> TPC-H queries 1, 17, 20 fail with similar errors caused by class cast
> exceptions in aggregate functions:
> {code:java}
> // q1 Caused by: java.lang.ClassCastException: class java.lang.Long cannot be
> cast to class java.math.BigDecimal (java.lang.Long and java.math.BigDecimal
> are in module java.base of loader 'bootstrap')
> // at
> org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalSumEmptyIsZero.add(Accumulators.java:588)
> // q17 Caused by: java.lang.ClassCastException: class java.lang.Long cannot
> be cast to class java.math.BigDecimal (java.lang.Long and
> java.math.BigDecimal are in module java.base of loader 'bootstrap')
> //at
> org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalAvg.add(Accumulators.java:270)
> // q20 class java.lang.Long cannot be cast to class java.math.BigDecimal
> (java.lang.Long and java.math.BigDecimal are in module java.base of loader
> 'bootstrap')
> //at
> org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalSumEmptyIsZero.add(Accumulators.java:588)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18805) Sql. TPC-H. ClassCastExceptions in predicate expressions
[
https://issues.apache.org/jira/browse/IGNITE-18805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18805:
--
Summary: Sql. TPC-H. ClassCastExceptions in predicate expressions (was:
Sql. Tpc-H. ClassCastExceptions in predicate expressions)
> Sql. TPC-H. ClassCastExceptions in predicate expressions
>
>
> Key: IGNITE-18805
> URL: https://issues.apache.org/jira/browse/IGNITE-18805
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> TPC-H queries 4, 16, 19, 21 fail with similar errors caused by class cast
> exceptions in generaned predicate expressions:
> {code:java}
> // Error
> //
> org.apache.ignite.internal.sql.engine.exec.exp.ExpressionFactoryImpl$PredicateImpl.test(ExpressionFactoryImpl.java:610)
> // q16: Caused by: java.lang.ClassCastException: class java.lang.String
> cannot be cast to class java.lang.Boolean (java.lang.String and
> java.lang.Boolean are in module java.base of loader 'bootstrap')
> // q21 q4 Caused by: java.lang.ClassCastException: class
> java.time.LocalDateTime cannot be cast to class java.lang.Long
> (java.time.LocalDateTime and java.lang.Long are in module java.base of loader
> 'bootstrap')
> // q19: Caused by: java.lang.ClassCastException: class
> java.math.BigDecimal cannot be cast to class java.lang.Long
> (java.math.BigDecimal and java.lang.Long are in module java.base of loader
> 'bootstrap')
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18786) Sql. TPC-H query#6: Failed to parse query: BETWEEN operator has no terminating AND
[
https://issues.apache.org/jira/browse/IGNITE-18786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18786:
--
Description:
Sql parser is unable to parse TPC-H query#6.
Error:
{code:java}
org.apache.ignite.sql.SqlException: IGN-SQL-3
TraceId:f9be2841-ea95-4995-bde3-27742e8642dd Failed to parse query: BETWEEN
operator has no terminating AND
at
org.apache.ignite.internal.util.ExceptionUtils.lambda$withCauseAndCode$3(ExceptionUtils.java:408)
at
org.apache.ignite.internal.util.ExceptionUtils.withCauseInternal(ExceptionUtils.java:435)
at
org.apache.ignite.internal.util.ExceptionUtils.withCauseAndCode(ExceptionUtils.java:408)
at
org.apache.ignite.internal.sql.engine.util.Commons.parse(Commons.java:751)
at
org.apache.ignite.internal.sql.engine.framework.TestNode.prepare(TestNode.java:190)
at
org.apache.ignite.internal.sql.engine.benchmarks.TpcTest$RunQuery.executeQuery(TpcTest.java:154)
at
org.apache.ignite.internal.sql.engine.benchmarks.TpcTest$RunQuery.execute(TpcTest.java:141)
at
org.junit.jupiter.engine.descriptor.DynamicTestTestDescriptor.lambda$execute$0(DynamicTestTestDescriptor.java:53)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
org.junit.jupiter.api.extension.InvocationInterceptor.interceptDynamicTest(InvocationInterceptor.java:167)
at
org.junit.jupiter.api.extension.InvocationInterceptor.interceptDynamicTest(InvocationInterceptor.java:184)
at
org.junit.jupiter.engine.descriptor.DynamicTestTestDescriptor.lambda$execute$1(DynamicTestTestDescriptor.java:61)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptorCall.lambda$ofVoid$0(InvocationInterceptorChain.java:78)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at
org.junit.jupiter.engine.descriptor.DynamicTestTestDescriptor.execute(DynamicTestTestDescriptor.java:60)
at
org.junit.jupiter.engine.descriptor.DynamicTestTestDescriptor.execute(DynamicTestTestDescriptor.java:32)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at
org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
at
org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.submit(SameThreadHierarchicalTestExecutorService.java:35)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask$DefaultDynamicTestExecutor.execute(NodeTestTask.java:226)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask$DefaultDynamicTestExecutor.execute(NodeTestTask.java:204)
at java.base/java.util.Optional.ifPresent(Optional.java:183)
at
org.junit.jupiter.engine.descriptor.TestFactoryTestDescriptor.lambda$invokeTestMethod$1(TestFactoryTestDescriptor.java:108)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.descriptor.TestFactoryTestDescriptor.invokeTestMethod(TestFactoryTestDescriptor.java:95)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:135)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:66)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeT
[jira] [Updated] (IGNITE-18787) Sql. TPC-H query#22: No match found for function signature
[
https://issues.apache.org/jira/browse/IGNITE-18787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18787:
--
Description:
SqlValidator rejects TPC-H query#22 with an error that a function does not
exist.
{code:java}
Failed to prepare a query
org.apache.calcite.runtime.CalciteContextException: From line 15, column 18 to
line 15, column 38: No match found for function signature SUBSTR(,
, )
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at
org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:505)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:932)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:917)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5362)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.handleUnresolvedFunction(SqlValidatorImpl.java:1955)
at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:326)
at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:231)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:6373)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:6360)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:161)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1869)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1854)
at
org.apache.calcite.sql.type.SqlTypeUtil.deriveType(SqlTypeUtil.java:200)
at
org.apache.calcite.sql.type.InferTypes.lambda$static$0(InferTypes.java:47)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.inferUnknownTypes(IgniteSqlValidator.java:541)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.inferUnknownTypes(IgniteSqlValidator.java:564)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.inferUnknownTypes(IgniteSqlValidator.java:564)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateWhereOrOn(SqlValidatorImpl.java:4422)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateWhereClause(SqlValidatorImpl.java:4414)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3700)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateSelect(IgniteSqlValidator.java:251)
at
org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:64)
at
org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:89)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1107)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:1078)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3381)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3360)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3697)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateSelect(IgniteSqlValidator.java:251)
at
org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:64)
at
org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:89)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1107)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:1078)
at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:248)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1053)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:759)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validate(IgniteSqlValidator.java:136)
at
org.apache.ignite.internal.sql.engine.prepare.IgnitePlanner.validateAndGetTypeMetadata(IgnitePlanner.java:210)
at
org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareQuery$3(PrepareServiceImpl.java:234)
at
java.base/java.util.concurrent.Completabl
[jira] [Created] (IGNITE-18805) Sql. Tpc-H. ClassCastExceptions in predicate expressions
Maksim Zhuravkov created IGNITE-18805:
-
Summary: Sql. Tpc-H. ClassCastExceptions in predicate expressions
Key: IGNITE-18805
URL: https://issues.apache.org/jira/browse/IGNITE-18805
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Maksim Zhuravkov
Fix For: 3.0.0-beta2
TPC-H queries 4, 16, 19, 21 fail with similar errors caused by class cast
exceptions in generaned predicate expressions:
{code:java}
// Error
//
org.apache.ignite.internal.sql.engine.exec.exp.ExpressionFactoryImpl$PredicateImpl.test(ExpressionFactoryImpl.java:610)
// q16: Caused by: java.lang.ClassCastException: class java.lang.String
cannot be cast to class java.lang.Boolean (java.lang.String and
java.lang.Boolean are in module java.base of loader 'bootstrap')
// q21 q4 Caused by: java.lang.ClassCastException: class
java.time.LocalDateTime cannot be cast to class java.lang.Long
(java.time.LocalDateTime and java.lang.Long are in module java.base of loader
'bootstrap')
// q19: Caused by: java.lang.ClassCastException: class java.math.BigDecimal
cannot be cast to class java.lang.Long (java.math.BigDecimal and java.lang.Long
are in module java.base of loader 'bootstrap')
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18804) Sql. Tpc-H. ClassCastException in aggregate functions.
[
https://issues.apache.org/jira/browse/IGNITE-18804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18804:
--
Description:
TPC-H queries 1, 17, 20 fail with similar errors caused by class cast
exceptions in aggregate functions:
{code:java}
// q1 Caused by: java.lang.ClassCastException: class java.lang.Long cannot be
cast to class java.math.BigDecimal (java.lang.Long and java.math.BigDecimal are
in module java.base of loader 'bootstrap')
// at
org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalSumEmptyIsZero.add(Accumulators.java:588)
// q17 Caused by: java.lang.ClassCastException: class java.lang.Long cannot be
cast to class java.math.BigDecimal (java.lang.Long and java.math.BigDecimal are
in module java.base of loader 'bootstrap')
// at
org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalAvg.add(Accumulators.java:270)
// q20 class java.lang.Long cannot be cast to class java.math.BigDecimal
(java.lang.Long and java.math.BigDecimal are in module java.base of loader
'bootstrap')
// at
org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalSumEmptyIsZero.add(Accumulators.java:588)
{code}
was:
TPC-H queries 1, 17, 20 fail with similar errors caused by class cast
exceptions in aggregate functions:
{code:java}
// q1 Caused by: java.lang.ClassCastException: class java.lang.Long cannot be
cast to class java.math.BigDecimal (java.lang.Long and java.math.BigDecimal are
in module java.base of loader 'bootstrap')
// at
org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalSumEmptyIsZero.add(Accumulators.java:588)
// q17 Caused by: java.lang.ClassCastException: class java.lang.Long cannot be
cast to class java.math.BigDecimal (java.lang.Long and java.math.BigDecimal are
in module java.base of loader 'bootstrap')
// at
org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalAvg.add(Accumulators.java:270)
// q20 class java.lang.Long cannot be cast to class java.math.BigDecimal
(java.lang.Long and java.math.BigDecimal are in module java.base of loader
'bootstrap')
// at
org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalSumEmptyIsZero.add(Accumulators.java:588)
{code}
Query#1:
{code:java}
SELECT
l_returnflag,
l_linestatus,
sum(l_quantity) AS sum_qty,
sum(l_extendedprice) AS sum_base_price,
sum(l_extendedprice * (1 - l_discount)) AS sum_disc_price,
sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) AS sum_charge,
avg(l_quantity) AS avg_qty,
avg(l_extendedprice) AS avg_price,
avg(l_discount) AS avg_disc,
count(*) AS count_order
FROM
lineitem
WHERE
l_shipdate <= DATE '1998-12-01' - INTERVAL '90' DAY
GROUP BY
l_returnflag,
l_linestatus
ORDER BY
l_returnflag,
l_linestatus
{code}
Query#17:
{code:java}
SELECT sum(l_extendedprice) / 7.0 AS avg_yearly
FROM
lineitem,
part
WHERE
p_partkey = l_partkey
AND p_brand = 'Brand#23'
AND p_container = 'MED BOX'
AND l_quantity < (
SELECT 0.2 * avg(l_quantity)
FROM
lineitem
WHERE
l_partkey = p_partkey
)
{code}
Query#20:
{code:java}
SELECT
s_name,
s_address
FROM
supplier, nation
WHERE
s_suppkey IN (
SELECT ps_suppkey
FROM
partsupp
WHERE
ps_partkey IN (
SELECT p_partkey
FROM
part
WHERE
p_name LIKE 'forest%'
)
AND ps_availqty > (
SELECT 0.5 * sum(l_quantity)
FROM
lineitem
WHERE
l_partkey = ps_partkey
AND l_suppkey = ps_suppkey
AND l_shipdate >= date('1994-01-01')
AND l_shipdate < date('1994-01-01') + interval '1' YEAR
)
)
AND s_nationkey = n_nationkey
AND n_name = 'CANADA'
ORDER BY s_name
{code}
> Sql. Tpc-H. ClassCastException in aggregate functions.
> --
>
> Key: IGNITE-18804
> URL: https://issues.apache.org/jira/browse/IGNITE-18804
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> TPC-H queries 1, 17, 20 fail with similar errors caused by class cast
> exceptions in aggregate functions:
> {code:java}
> // q1 Caused by: java.lang.ClassCastException: class java.lang.Long
[jira] [Updated] (IGNITE-18804) Sql. Tpc-H. ClassCastException in aggregate functions.
[
https://issues.apache.org/jira/browse/IGNITE-18804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18804:
--
Summary: Sql. Tpc-H. ClassCastException in aggregate functions. (was: Sql.
Tpc-H. ClassCastException in aggregate functions. Queries 1, 17, 20.)
> Sql. Tpc-H. ClassCastException in aggregate functions.
> --
>
> Key: IGNITE-18804
> URL: https://issues.apache.org/jira/browse/IGNITE-18804
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> TPC-H queries 1, 17, 20 fail with similar errors caused by class cast
> exceptions in aggregate functions:
> {code:java}
> // q1 Caused by: java.lang.ClassCastException: class java.lang.Long cannot be
> cast to class java.math.BigDecimal (java.lang.Long and java.math.BigDecimal
> are in module java.base of loader 'bootstrap')
> // at
> org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalSumEmptyIsZero.add(Accumulators.java:588)
> // q17 Caused by: java.lang.ClassCastException: class java.lang.Long cannot
> be cast to class java.math.BigDecimal (java.lang.Long and
> java.math.BigDecimal are in module java.base of loader 'bootstrap')
> //at
> org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalAvg.add(Accumulators.java:270)
> // q20 class java.lang.Long cannot be cast to class java.math.BigDecimal
> (java.lang.Long and java.math.BigDecimal are in module java.base of loader
> 'bootstrap')
> //at
> org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalSumEmptyIsZero.add(Accumulators.java:588)
> {code}
> Query#1:
> {code:java}
> SELECT
> l_returnflag,
> l_linestatus,
> sum(l_quantity) AS sum_qty,
> sum(l_extendedprice) AS sum_base_price,
> sum(l_extendedprice * (1 - l_discount)) AS sum_disc_price,
> sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) AS sum_charge,
> avg(l_quantity) AS avg_qty,
> avg(l_extendedprice) AS avg_price,
> avg(l_discount) AS avg_disc,
> count(*) AS count_order
> FROM
> lineitem
> WHERE
> l_shipdate <= DATE '1998-12-01' - INTERVAL '90' DAY
> GROUP BY
> l_returnflag,
> l_linestatus
> ORDER BY
> l_returnflag,
> l_linestatus
> {code}
> Query#17:
> {code:java}
> SELECT sum(l_extendedprice) / 7.0 AS avg_yearly
> FROM
> lineitem,
> part
> WHERE
> p_partkey = l_partkey
> AND p_brand = 'Brand#23'
> AND p_container = 'MED BOX'
> AND l_quantity < (
> SELECT 0.2 * avg(l_quantity)
> FROM
> lineitem
> WHERE
> l_partkey = p_partkey
> )
> {code}
> Query#20:
> {code:java}
> SELECT
> s_name,
> s_address
> FROM
> supplier, nation
> WHERE
> s_suppkey IN (
> SELECT ps_suppkey
> FROM
> partsupp
> WHERE
> ps_partkey IN (
> SELECT p_partkey
> FROM
> part
> WHERE
> p_name LIKE 'forest%'
> )
> AND ps_availqty > (
> SELECT 0.5 * sum(l_quantity)
> FROM
> lineitem
> WHERE
> l_partkey = ps_partkey
> AND l_suppkey = ps_suppkey
> AND l_shipdate >= date('1994-01-01')
> AND l_shipdate < date('1994-01-01') + interval '1' YEAR
> )
> )
> AND s_nationkey = n_nationkey
> AND n_name = 'CANADA'
> ORDER BY s_name
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18804) Sql. Tpc-H. ClassCastException in aggregate functions. Queries 1, 17, 20.
[
https://issues.apache.org/jira/browse/IGNITE-18804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18804:
--
Description:
TPC-H queries 1, 17, 20 fail with similar errors caused by class cast
exceptions in aggregate functions:
{code:java}
// q1 Caused by: java.lang.ClassCastException: class java.lang.Long cannot be
cast to class java.math.BigDecimal (java.lang.Long and java.math.BigDecimal are
in module java.base of loader 'bootstrap')
// at
org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalSumEmptyIsZero.add(Accumulators.java:588)
// q17 Caused by: java.lang.ClassCastException: class java.lang.Long cannot be
cast to class java.math.BigDecimal (java.lang.Long and java.math.BigDecimal are
in module java.base of loader 'bootstrap')
// at
org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalAvg.add(Accumulators.java:270)
// q20 class java.lang.Long cannot be cast to class java.math.BigDecimal
(java.lang.Long and java.math.BigDecimal are in module java.base of loader
'bootstrap')
// at
org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalSumEmptyIsZero.add(Accumulators.java:588)
{code}
Query#1:
{code:java}
SELECT
l_returnflag,
l_linestatus,
sum(l_quantity) AS sum_qty,
sum(l_extendedprice) AS sum_base_price,
sum(l_extendedprice * (1 - l_discount)) AS sum_disc_price,
sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) AS sum_charge,
avg(l_quantity) AS avg_qty,
avg(l_extendedprice) AS avg_price,
avg(l_discount) AS avg_disc,
count(*) AS count_order
FROM
lineitem
WHERE
l_shipdate <= DATE '1998-12-01' - INTERVAL '90' DAY
GROUP BY
l_returnflag,
l_linestatus
ORDER BY
l_returnflag,
l_linestatus
{code}
Query#17:
{code:java}
SELECT sum(l_extendedprice) / 7.0 AS avg_yearly
FROM
lineitem,
part
WHERE
p_partkey = l_partkey
AND p_brand = 'Brand#23'
AND p_container = 'MED BOX'
AND l_quantity < (
SELECT 0.2 * avg(l_quantity)
FROM
lineitem
WHERE
l_partkey = p_partkey
)
{code}
Query#20:
{code:java}
SELECT
s_name,
s_address
FROM
supplier, nation
WHERE
s_suppkey IN (
SELECT ps_suppkey
FROM
partsupp
WHERE
ps_partkey IN (
SELECT p_partkey
FROM
part
WHERE
p_name LIKE 'forest%'
)
AND ps_availqty > (
SELECT 0.5 * sum(l_quantity)
FROM
lineitem
WHERE
l_partkey = ps_partkey
AND l_suppkey = ps_suppkey
AND l_shipdate >= date('1994-01-01')
AND l_shipdate < date('1994-01-01') + interval '1' YEAR
)
)
AND s_nationkey = n_nationkey
AND n_name = 'CANADA'
ORDER BY s_name
{code}
was:
Queries 1, 17, 20 fail with similar errors caused by class cast exceptions in
aggregate functions:
{code:java}
// q20 class java.lang.Long cannot be cast to class java.math.BigDecimal
(java.lang.Long and java.math.BigDecimal are in module java.base of loader
'bootstrap')
// at
org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalSumEmptyIsZero.add(Accumulators.java:588)
// q17 Caused by: java.lang.ClassCastException: class java.lang.Long cannot
be cast to class java.math.BigDecimal (java.lang.Long and java.math.BigDecimal
are in module java.base of loader 'bootstrap')
// at
org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalAvg.add(Accumulators.java:270)
// q1 Caused by: java.lang.ClassCastException: class java.lang.Long cannot
be cast to class java.math.BigDecimal (java.lang.Long and java.math.BigDecimal
are in module java.base of loader 'bootstrap')
// at
org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalSumEmptyIsZero.add(Accumulators.java:588)
{code}
Query#1:
{code:java}
SELECT
l_returnflag,
l_linestatus,
sum(l_quantity) AS sum_qty,
sum(l_extendedprice) AS sum_base_price,
sum(l_extendedprice * (1 - l_discount)) AS sum_disc_price,
sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) AS sum_charge,
avg(l_quantity) AS avg_qty,
avg(l_extendedprice) AS avg_price,
avg(l_discount) AS avg_disc,
count(*) AS count_order
FROM
lineitem
WHERE
l_sh
[jira] [Updated] (IGNITE-18804) Sql. Tpc-H. ClassCastException in aggregate functions. Queries 1, 17, 20.
[
https://issues.apache.org/jira/browse/IGNITE-18804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18804:
--
Description:
Queries 1, 17, 20 fail with similar errors caused by class cast exceptions in
aggregate functions:
{code:java}
// q20 class java.lang.Long cannot be cast to class java.math.BigDecimal
(java.lang.Long and java.math.BigDecimal are in module java.base of loader
'bootstrap')
// at
org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalSumEmptyIsZero.add(Accumulators.java:588)
// q17 Caused by: java.lang.ClassCastException: class java.lang.Long cannot
be cast to class java.math.BigDecimal (java.lang.Long and java.math.BigDecimal
are in module java.base of loader 'bootstrap')
// at
org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalAvg.add(Accumulators.java:270)
// q1 Caused by: java.lang.ClassCastException: class java.lang.Long cannot
be cast to class java.math.BigDecimal (java.lang.Long and java.math.BigDecimal
are in module java.base of loader 'bootstrap')
// at
org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalSumEmptyIsZero.add(Accumulators.java:588)
{code}
Query#1:
{code:java}
SELECT
l_returnflag,
l_linestatus,
sum(l_quantity) AS sum_qty,
sum(l_extendedprice) AS sum_base_price,
sum(l_extendedprice * (1 - l_discount)) AS sum_disc_price,
sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) AS sum_charge,
avg(l_quantity) AS avg_qty,
avg(l_extendedprice) AS avg_price,
avg(l_discount) AS avg_disc,
count(*) AS count_order
FROM
lineitem
WHERE
l_shipdate <= DATE '1998-12-01' - INTERVAL '90' DAY
GROUP BY
l_returnflag,
l_linestatus
ORDER BY
l_returnflag,
l_linestatus
{code}
Query#17:
{code:java}
SELECT sum(l_extendedprice) / 7.0 AS avg_yearly
FROM
lineitem,
part
WHERE
p_partkey = l_partkey
AND p_brand = 'Brand#23'
AND p_container = 'MED BOX'
AND l_quantity < (
SELECT 0.2 * avg(l_quantity)
FROM
lineitem
WHERE
l_partkey = p_partkey
)
{code}
Query#20:
{code:java}
SELECT
s_name,
s_address
FROM
supplier, nation
WHERE
s_suppkey IN (
SELECT ps_suppkey
FROM
partsupp
WHERE
ps_partkey IN (
SELECT p_partkey
FROM
part
WHERE
p_name LIKE 'forest%'
)
AND ps_availqty > (
SELECT 0.5 * sum(l_quantity)
FROM
lineitem
WHERE
l_partkey = ps_partkey
AND l_suppkey = ps_suppkey
AND l_shipdate >= date('1994-01-01')
AND l_shipdate < date('1994-01-01') + interval '1' YEAR
)
)
AND s_nationkey = n_nationkey
AND n_name = 'CANADA'
ORDER BY s_name
{code}
was:
Queries 1, 17, 20 fail with similar errors caused by class cast exceptions in
aggregate functions:
{code:java}
// q20 class java.lang.Long cannot be cast to class java.math.BigDecimal
(java.lang.Long and java.math.BigDecimal are in module java.base of loader
'bootstrap')
// at
org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalSumEmptyIsZero.add(Accumulators.java:588)
// q17 Caused by: java.lang.ClassCastException: class java.lang.Long cannot
be cast to class java.math.BigDecimal (java.lang.Long and java.math.BigDecimal
are in module java.base of loader 'bootstrap')
// at
org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalAvg.add(Accumulators.java:270)
// q1 Caused by: java.lang.ClassCastException: class java.lang.Long cannot
be cast to class java.math.BigDecimal (java.lang.Long and java.math.BigDecimal
are in module java.base of loader 'bootstrap')
// at
org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalSumEmptyIsZero.add(Accumulators.java:588)
{code}
> Sql. Tpc-H. ClassCastException in aggregate functions. Queries 1, 17, 20.
> -
>
> Key: IGNITE-18804
> URL: https://issues.apache.org/jira/browse/IGNITE-18804
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Queries 1, 17, 20 fail with similar errors caused by class cast exceptions in
> aggregate functions:
> {code:java}
> // q20 class java.lang.Long c
[jira] [Updated] (IGNITE-18804) Sql. Tpc-H. ClassCastException in aggregate functions. Queries 1, 17, 20.
[
https://issues.apache.org/jira/browse/IGNITE-18804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18804:
--
Labels: calcite2-required calcite3-required ignite-3 (was: )
> Sql. Tpc-H. ClassCastException in aggregate functions. Queries 1, 17, 20.
> -
>
> Key: IGNITE-18804
> URL: https://issues.apache.org/jira/browse/IGNITE-18804
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Queries 1, 17, 20 fail with similar errors caused by class cast exceptions in
> aggregate functions:
> {code:java}
> // q20 class java.lang.Long cannot be cast to class java.math.BigDecimal
> (java.lang.Long and java.math.BigDecimal are in module java.base of loader
> 'bootstrap')
> //at
> org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalSumEmptyIsZero.add(Accumulators.java:588)
> // q17 Caused by: java.lang.ClassCastException: class java.lang.Long
> cannot be cast to class java.math.BigDecimal (java.lang.Long and
> java.math.BigDecimal are in module java.base of loader 'bootstrap')
> //at
> org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalAvg.add(Accumulators.java:270)
> // q1 Caused by: java.lang.ClassCastException: class java.lang.Long
> cannot be cast to class java.math.BigDecimal (java.lang.Long and
> java.math.BigDecimal are in module java.base of loader 'bootstrap')
> //at
> org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalSumEmptyIsZero.add(Accumulators.java:588)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18796) testRetryReadPolicyRetriesReadOperations is flaky
[
https://issues.apache.org/jira/browse/IGNITE-18796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17688608#comment-17688608
]
Pavel Tupitsyn commented on IGNITE-18796:
-
Merged to main: d7d4d6cbf782c0ec7754989f33994ecef74a1c23
> testRetryReadPolicyRetriesReadOperations is flaky
> -
>
> Key: IGNITE-18796
> URL: https://issues.apache.org/jira/browse/IGNITE-18796
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> org.apache.ignite.client.IgniteClientConnectionException: IGN-CLIENT-1
> TraceId:043303fc-3705-4eea-a7b3-81c7692a3807 IGN-CLIENT-1
> TraceId:043303fc-3705-4eea-a7b3-81c7692a3807 Channel is closed
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
> at org.apache.ignite.lang.IgniteException.wrap(IgniteException.java:277)
> at
> org.apache.ignite.internal.client.ClientUtils.sync(ClientUtils.java:50)
> at
> org.apache.ignite.internal.client.table.ClientRecordBinaryView.get(ClientRecordBinaryView.java:62)
> at
> org.apache.ignite.internal.client.table.ClientRecordBinaryView.get(ClientRecordBinaryView.java:40)
> at
> org.apache.ignite.client.RetryPolicyTest.testRetryReadPolicyRetriesReadOperations(RetryPolicyTest.java:178)
> at jdk.internal.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:725)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:214)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:210)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:135)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:66)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
> at
> org.junit.platform.engine.support.hierarchical.Nod
[jira] [Created] (IGNITE-18804) Sql. Tpc-H. ClassCastException in aggregate functions. Queries 1, 17, 20.
Maksim Zhuravkov created IGNITE-18804:
-
Summary: Sql. Tpc-H. ClassCastException in aggregate functions.
Queries 1, 17, 20.
Key: IGNITE-18804
URL: https://issues.apache.org/jira/browse/IGNITE-18804
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Maksim Zhuravkov
Fix For: 3.0.0-beta2
Queries 1, 17, 20 fail with similar errors caused by class cast exceptions in
aggregate functions:
{code:java}
// q20 class java.lang.Long cannot be cast to class java.math.BigDecimal
(java.lang.Long and java.math.BigDecimal are in module java.base of loader
'bootstrap')
// at
org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalSumEmptyIsZero.add(Accumulators.java:588)
// q17 Caused by: java.lang.ClassCastException: class java.lang.Long cannot
be cast to class java.math.BigDecimal (java.lang.Long and java.math.BigDecimal
are in module java.base of loader 'bootstrap')
// at
org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalAvg.add(Accumulators.java:270)
// q1 Caused by: java.lang.ClassCastException: class java.lang.Long cannot
be cast to class java.math.BigDecimal (java.lang.Long and java.math.BigDecimal
are in module java.base of loader 'bootstrap')
// at
org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators$DecimalSumEmptyIsZero.add(Accumulators.java:588)
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18787) Sql. TPC-H query#22: No match found for function signature
[
https://issues.apache.org/jira/browse/IGNITE-18787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18787:
--
Summary: Sql. TPC-H query#22: No match found for function signature (was:
Sql. TPC-H query#22: )
> Sql. TPC-H query#22: No match found for function signature
> ---
>
> Key: IGNITE-18787
> URL: https://issues.apache.org/jira/browse/IGNITE-18787
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> SqlValidator rejects TPC-H query#22 with an error that a function does not
> exist.
> {code:java}
> SELECT
> cntrycode,
> count(*) AS numcust,
> sum(c_acctbal) AS totacctbal
> FROM (
> SELECT
> substr(c_phone, 1, 2) AS cntrycode,
> c_acctbal
> FROM
> customer
> WHERE
> substr(c_phone, 1, 2) IN
> ('13', '31', '23', '29', '30', '18', '17')
>AND c_acctbal > (
> SELECT avg(c_acctbal)
> FROM
> customer
> WHERE
> c_acctbal > 0.00
>AND substr(c_phone, 1, 2) IN
>('13', '31', '23', '29', '30', '18', '17')
> )
>AND NOT exists(
> SELECT *
> FROM
> orders
> WHERE
> o_custkey = c_custkey
> )
> ) AS custsale
> GROUP BY
> cntrycode
> ORDER BY
> cntrycode
> {code}
> Error:
> {code:java}
> Failed to prepare a query
> org.apache.calcite.runtime.CalciteContextException: From line 15, column 18
> to line 15, column 38: No match found for function signature
> SUBSTR(, , )
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:505)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:932)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:917)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5362)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.handleUnresolvedFunction(SqlValidatorImpl.java:1955)
> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:326)
> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:231)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:6373)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:6360)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:161)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1869)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1854)
> at
> org.apache.calcite.sql.type.SqlTypeUtil.deriveType(SqlTypeUtil.java:200)
> at
> org.apache.calcite.sql.type.InferTypes.lambda$static$0(InferTypes.java:47)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.inferUnknownTypes(IgniteSqlValidator.java:541)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.inferUnknownTypes(IgniteSqlValidator.java:564)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.inferUnknownTypes(IgniteSqlValidator.java:564)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateWhereOrOn(SqlValidatorImpl.java:4422)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateWhereClause(SqlValidatorImpl.java:4414)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3700)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateSelect(IgniteSqlValidator.java:251)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:64)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:89)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1107)
> at
> org.apache.c
[jira] [Commented] (IGNITE-18796) testRetryReadPolicyRetriesReadOperations is flaky
[
https://issues.apache.org/jira/browse/IGNITE-18796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17688596#comment-17688596
]
Igor Sapego commented on IGNITE-18796:
--
Looks good to me.
> testRetryReadPolicyRetriesReadOperations is flaky
> -
>
> Key: IGNITE-18796
> URL: https://issues.apache.org/jira/browse/IGNITE-18796
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> {code}
> org.apache.ignite.client.IgniteClientConnectionException: IGN-CLIENT-1
> TraceId:043303fc-3705-4eea-a7b3-81c7692a3807 IGN-CLIENT-1
> TraceId:043303fc-3705-4eea-a7b3-81c7692a3807 Channel is closed
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
> at org.apache.ignite.lang.IgniteException.wrap(IgniteException.java:277)
> at
> org.apache.ignite.internal.client.ClientUtils.sync(ClientUtils.java:50)
> at
> org.apache.ignite.internal.client.table.ClientRecordBinaryView.get(ClientRecordBinaryView.java:62)
> at
> org.apache.ignite.internal.client.table.ClientRecordBinaryView.get(ClientRecordBinaryView.java:40)
> at
> org.apache.ignite.client.RetryPolicyTest.testRetryReadPolicyRetriesReadOperations(RetryPolicyTest.java:178)
> at jdk.internal.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:725)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:214)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:210)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:135)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:66)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
> at
> org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.
[jira] [Assigned] (IGNITE-18803) Fix compilation error of ignite-hibernate-ext
[
https://issues.apache.org/jira/browse/IGNITE-18803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Nikolaev reassigned IGNITE-18803:
---
Assignee: Aleksandr Nikolaev
> Fix compilation error of ignite-hibernate-ext
> -
>
> Key: IGNITE-18803
> URL: https://issues.apache.org/jira/browse/IGNITE-18803
> Project: Ignite
> Issue Type: Bug
> Components: extensions
> Environment:
>Reporter: Ilya Shishkov
>Assignee: Aleksandr Nikolaev
>Priority: Minor
> Labels: newbie
>
> Build fails because {{CacheMetricsMXBean}} was deleted from Apache Ignite:
> {noformat}
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[44,32]
> cannot find symbol
> symbol: class CacheMetricsMXBean
> location: package org.apache.ignite.mxbean
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[549,22]
> cannot find symbol
> symbol: class CacheMetricsMXBean
> location: class org.apache.ignite.cache.hibernate.HibernateCacheProxy
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[554,22]
> cannot find symbol
> symbol: class CacheMetricsMXBean
> location: class org.apache.ignite.cache.hibernate.HibernateCacheProxy
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[549,5]
> method does not override or implement a method from a supertype
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[550,30]
> cannot find symbol
> symbol: method clusterMxBean()
> location: interface
> org.apache.ignite.internal.processors.cache.IgniteInternalCache
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[554,5]
> method does not override or implement a method from a supertype
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[555,30]
> cannot find symbol
> symbol: method localMxBean()
> location: interface
> org.apache.ignite.internal.processors.cache.IgniteInternalCache
> {noformat}
> Build history on TC1 & TC2:
> #
> https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?branch=%3Cdefault%3E&mode=builds
> #
> https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?branch=%3Cdefault%3E&mode=builds
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17952) Sql. Make SQL distributed again
[ https://issues.apache.org/jira/browse/IGNITE-17952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov reassigned IGNITE-17952: - Assignee: Konstantin Orlov > Sql. Make SQL distributed again > --- > > Key: IGNITE-17952 > URL: https://issues.apache.org/jira/browse/IGNITE-17952 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Attachments: StopCalciteModuleTest.patch > > > As a first step in integrating RW transactions, we were forced to abandon the > execution of distributed queries. > After IGNITE-17950 and IGNITE-17951 will be implemented, we need to switch > back to a distributed execution. For this let's remove LOCAL_TRAITS_SET, and > start to pass proper txId when performing a scan over local partition. > Do not forget: > * Fix all TODO marked IGNITE-17952. > * Fix StopCalciteModuleTest (patch attached). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18803) Fix compilation error of ignite-hibernate-ext
[
https://issues.apache.org/jira/browse/IGNITE-18803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-18803:
---
Labels: newbie (was: )
> Fix compilation error of ignite-hibernate-ext
> -
>
> Key: IGNITE-18803
> URL: https://issues.apache.org/jira/browse/IGNITE-18803
> Project: Ignite
> Issue Type: Bug
> Components: extensions
> Environment:
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: newbie
>
> Build fails because {{CacheMetricsMXBean}} was deleted from Apache Ignite:
> {noformat}
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[44,32]
> cannot find symbol
> symbol: class CacheMetricsMXBean
> location: package org.apache.ignite.mxbean
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[549,22]
> cannot find symbol
> symbol: class CacheMetricsMXBean
> location: class org.apache.ignite.cache.hibernate.HibernateCacheProxy
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[554,22]
> cannot find symbol
> symbol: class CacheMetricsMXBean
> location: class org.apache.ignite.cache.hibernate.HibernateCacheProxy
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[549,5]
> method does not override or implement a method from a supertype
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[550,30]
> cannot find symbol
> symbol: method clusterMxBean()
> location: interface
> org.apache.ignite.internal.processors.cache.IgniteInternalCache
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[554,5]
> method does not override or implement a method from a supertype
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[555,30]
> cannot find symbol
> symbol: method localMxBean()
> location: interface
> org.apache.ignite.internal.processors.cache.IgniteInternalCache
> {noformat}
> Build history on TC1 & TC2:
> #
> https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?branch=%3Cdefault%3E&mode=builds
> #
> https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?branch=%3Cdefault%3E&mode=builds
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18803) Fix compilation error of ignite-hibernate-ext
[
https://issues.apache.org/jira/browse/IGNITE-18803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-18803:
---
Description:
Build fails because {{CacheMetricsMXBean}} was deleted from Apache Ignite:
{noformat}
/opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[44,32]
cannot find symbol
symbol: class CacheMetricsMXBean
location: package org.apache.ignite.mxbean
/opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[549,22]
cannot find symbol
symbol: class CacheMetricsMXBean
location: class org.apache.ignite.cache.hibernate.HibernateCacheProxy
/opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[554,22]
cannot find symbol
symbol: class CacheMetricsMXBean
location: class org.apache.ignite.cache.hibernate.HibernateCacheProxy
/opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[549,5]
method does not override or implement a method from a supertype
/opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[550,30]
cannot find symbol
symbol: method clusterMxBean()
location: interface
org.apache.ignite.internal.processors.cache.IgniteInternalCache
/opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[554,5]
method does not override or implement a method from a supertype
/opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[555,30]
cannot find symbol
symbol: method localMxBean()
location: interface
org.apache.ignite.internal.processors.cache.IgniteInternalCache
{noformat}
Build history on TC1 & TC2:
#
https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?branch=%3Cdefault%3E&mode=builds
#
https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?branch=%3Cdefault%3E&mode=builds
was:
{noformat}
/opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[44,32]
cannot find symbol
symbol: class CacheMetricsMXBean
location: package org.apache.ignite.mxbean
/opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[549,22]
cannot find symbol
symbol: class CacheMetricsMXBean
location: class org.apache.ignite.cache.hibernate.HibernateCacheProxy
/opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[554,22]
cannot find symbol
symbol: class CacheMetricsMXBean
location: class org.apache.ignite.cache.hibernate.HibernateCacheProxy
/opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[549,5]
method does not override or implement a method from a supertype
/opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[550,30]
cannot find symbol
symbol: method clusterMxBean()
location: interface
org.apache.ignite.internal.processors.cache.IgniteInternalCache
/opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[554,5]
method does not override or implement a method from a supertype
/opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[555,30]
cannot find symbol
symbol: method localMxBean()
location: interface
org.apache.ignite.internal.processors.cache.IgniteInternalCache
{noformat}
> Fix compilation error of ignite-hibernate-ext
> -
>
> Key: IGNITE-18803
> URL: https://issues.apache.org/jira/browse/IGNITE-18803
> Project: Ignite
> Issue Type: Bug
> Components: extensions
> Environment:
>Reporter: Ilya Shishkov
>Priority: Minor
>
> Build fails because {{CacheMetricsMXBean}} was deleted from Apache Ignite:
> {noformat}
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[44,32]
> cannot find symbol
> symbol: class CacheMetricsMXBean
> location: package org.apache.ignit
[jira] [Updated] (IGNITE-18803) Fix compilation error of ignite-hibernate-ext
[
https://issues.apache.org/jira/browse/IGNITE-18803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-18803:
---
Issue Type: Bug (was: Test)
> Fix compilation error of ignite-hibernate-ext
> -
>
> Key: IGNITE-18803
> URL: https://issues.apache.org/jira/browse/IGNITE-18803
> Project: Ignite
> Issue Type: Bug
> Components: extensions
> Environment:
>Reporter: Ilya Shishkov
>Priority: Minor
>
> {noformat}
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[44,32]
> cannot find symbol
> symbol: class CacheMetricsMXBean
> location: package org.apache.ignite.mxbean
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[549,22]
> cannot find symbol
> symbol: class CacheMetricsMXBean
> location: class org.apache.ignite.cache.hibernate.HibernateCacheProxy
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[554,22]
> cannot find symbol
> symbol: class CacheMetricsMXBean
> location: class org.apache.ignite.cache.hibernate.HibernateCacheProxy
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[549,5]
> method does not override or implement a method from a supertype
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[550,30]
> cannot find symbol
> symbol: method clusterMxBean()
> location: interface
> org.apache.ignite.internal.processors.cache.IgniteInternalCache
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[554,5]
> method does not override or implement a method from a supertype
> /opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[555,30]
> cannot find symbol
> symbol: method localMxBean()
> location: interface
> org.apache.ignite.internal.processors.cache.IgniteInternalCache
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18803) Fix compilation error of ignite-hibernate-ext
Ilya Shishkov created IGNITE-18803:
--
Summary: Fix compilation error of ignite-hibernate-ext
Key: IGNITE-18803
URL: https://issues.apache.org/jira/browse/IGNITE-18803
Project: Ignite
Issue Type: Test
Components: extensions
Environment:
Reporter: Ilya Shishkov
{noformat}
/opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[44,32]
cannot find symbol
symbol: class CacheMetricsMXBean
location: package org.apache.ignite.mxbean
/opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[549,22]
cannot find symbol
symbol: class CacheMetricsMXBean
location: class org.apache.ignite.cache.hibernate.HibernateCacheProxy
/opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[554,22]
cannot find symbol
symbol: class CacheMetricsMXBean
location: class org.apache.ignite.cache.hibernate.HibernateCacheProxy
/opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[549,5]
method does not override or implement a method from a supertype
/opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[550,30]
cannot find symbol
symbol: method clusterMxBean()
location: interface
org.apache.ignite.internal.processors.cache.IgniteInternalCache
/opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[554,5]
method does not override or implement a method from a supertype
/opt/buildagent/work/9319dd66c384518/modules/hibernate-ext/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateCacheProxy.java:[555,30]
cannot find symbol
symbol: method localMxBean()
location: interface
org.apache.ignite.internal.processors.cache.IgniteInternalCache
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18632) Barrier for locks after cleanup started
[ https://issues.apache.org/jira/browse/IGNITE-18632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17688537#comment-17688537 ] Vladislav Pyatkov commented on IGNITE-18632: Merged 5186f9497130b1a8bd8191a9b66b0c318c40b15a > Barrier for locks after cleanup started > --- > > Key: IGNITE-18632 > URL: https://issues.apache.org/jira/browse/IGNITE-18632 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > Time Spent: 50m > Remaining Estimate: 0h > > *Motivation* > Transaction locks are acquired on primary replicas and must be released on tx > cleanup (on processing of cleanup request to primary replica). This means, no > lock for certain transaction can be acquired after the processing of cleanup > request has begun. However, messaging protocol doesn't provide any > linearization guarantees, so we should have this synchronization implemented > in replica listener. For current implementation the following is possible: > - put request and cleanup request for the same primary replica and for the > same transaction are reordered by messaging; > - cleanup starts and releases locks for corresponding tx; > - processing of put request starts and acquires locks that will never be > released. > *Definition of done:* > After cleanup for certain transaction on certain primary replilca has > started, it's impossible to acquire lock for this transaction on this primary > replica. > *Implementation notes:* > There is synchronization between adding write intents to storage on primary > replica and cleanup start (see IGNITE-18527 ). The implementation should take > into account that cleanup can't start while write intentis being written into > a storage, and cleanup command should not be fired before update command. > However, this ticket is not only about update requests/commands, as read > requests also acquire locks on primary replica, and they also need to be > synchronized with cleanup. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18632) Barrier for locks after cleanup started
[ https://issues.apache.org/jira/browse/IGNITE-18632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17688518#comment-17688518 ] Denis Chudov commented on IGNITE-18632: --- LGTM. > Barrier for locks after cleanup started > --- > > Key: IGNITE-18632 > URL: https://issues.apache.org/jira/browse/IGNITE-18632 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > Time Spent: 40m > Remaining Estimate: 0h > > *Motivation* > Transaction locks are acquired on primary replicas and must be released on tx > cleanup (on processing of cleanup request to primary replica). This means, no > lock for certain transaction can be acquired after the processing of cleanup > request has begun. However, messaging protocol doesn't provide any > linearization guarantees, so we should have this synchronization implemented > in replica listener. For current implementation the following is possible: > - put request and cleanup request for the same primary replica and for the > same transaction are reordered by messaging; > - cleanup starts and releases locks for corresponding tx; > - processing of put request starts and acquires locks that will never be > released. > *Definition of done:* > After cleanup for certain transaction on certain primary replilca has > started, it's impossible to acquire lock for this transaction on this primary > replica. > *Implementation notes:* > There is synchronization between adding write intents to storage on primary > replica and cleanup start (see IGNITE-18527 ). The implementation should take > into account that cleanup can't start while write intentis being written into > a storage, and cleanup command should not be fired before update command. > However, this ticket is not only about update requests/commands, as read > requests also acquire locks on primary replica, and they also need to be > synchronized with cleanup. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18802) CMake: Add option for disabling ignite headers install target
Dmitrii Zabotlin created IGNITE-18802: - Summary: CMake: Add option for disabling ignite headers install target Key: IGNITE-18802 URL: https://issues.apache.org/jira/browse/IGNITE-18802 Project: Ignite Issue Type: Improvement Components: platforms Reporter: Dmitrii Zabotlin Assignee: Dmitrii Zabotlin CMake option, that allows to disable install target or the Ignite headers. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18794) .NET: Thin 3.0: DivideByZeroException in GetPreferredNode
[
https://issues.apache.org/jira/browse/IGNITE-18794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17688512#comment-17688512
]
Pavel Tupitsyn commented on IGNITE-18794:
-
Merged to main: 562721aed06b75fa77e649b43b2c3d75e62b84e0
> .NET: Thin 3.0: DivideByZeroException in GetPreferredNode
> -
>
> Key: IGNITE-18794
> URL: https://issues.apache.org/jira/browse/IGNITE-18794
> Project: Ignite
> Issue Type: Improvement
> Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Flaky failure:
> {code}
> System.DivideByZeroException : Attempted to divide by zero.
>at Apache.Ignite.Internal.Table.Table.GetPreferredNode(Int32
> colocationHash, ITransaction transaction) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/Table.cs:line
> 197
>at
> Apache.Ignite.Internal.Compute.Compute.ExecuteColocatedAsync[T,TKey](String
> tableName, TKey key, Func`2 serializerHandlerFunc, String jobClassName,
> Object[] args) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Compute/Compute.cs:line
> 191
>at Apache.Ignite.Internal.Compute.Compute.ExecuteColocatedAsync[T](String
> tableName, IIgniteTuple key, String jobClassName, Object[] args)
>at
> Apache.Ignite.Tests.Compute.ComputeTests.TestExecuteColocatedUpdatesTableCacheOnTableDrop()
> in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Compute/ComputeTests.cs:line
> 281
>at
> Apache.Ignite.Tests.Compute.ComputeTests.TestExecuteColocatedUpdatesTableCacheOnTableDrop()
> in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Compute/ComputeTests.cs:line
> 287
>at
> NUnit.Framework.Internal.TaskAwaitAdapter.GenericAdapter`1.BlockUntilCompleted()
> {code}
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunNetTests/7075329?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&pluginCoverage=true&expandBuildTestsSection=true&expandBuildChangesSection=true
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18794) .NET: Thin 3.0: DivideByZeroException in GetPreferredNode
[
https://issues.apache.org/jira/browse/IGNITE-18794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17688509#comment-17688509
]
Igor Sapego commented on IGNITE-18794:
--
Looks good to me
> .NET: Thin 3.0: DivideByZeroException in GetPreferredNode
> -
>
> Key: IGNITE-18794
> URL: https://issues.apache.org/jira/browse/IGNITE-18794
> Project: Ignite
> Issue Type: Improvement
> Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Flaky failure:
> {code}
> System.DivideByZeroException : Attempted to divide by zero.
>at Apache.Ignite.Internal.Table.Table.GetPreferredNode(Int32
> colocationHash, ITransaction transaction) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/Table.cs:line
> 197
>at
> Apache.Ignite.Internal.Compute.Compute.ExecuteColocatedAsync[T,TKey](String
> tableName, TKey key, Func`2 serializerHandlerFunc, String jobClassName,
> Object[] args) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Compute/Compute.cs:line
> 191
>at Apache.Ignite.Internal.Compute.Compute.ExecuteColocatedAsync[T](String
> tableName, IIgniteTuple key, String jobClassName, Object[] args)
>at
> Apache.Ignite.Tests.Compute.ComputeTests.TestExecuteColocatedUpdatesTableCacheOnTableDrop()
> in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Compute/ComputeTests.cs:line
> 281
>at
> Apache.Ignite.Tests.Compute.ComputeTests.TestExecuteColocatedUpdatesTableCacheOnTableDrop()
> in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Compute/ComputeTests.cs:line
> 287
>at
> NUnit.Framework.Internal.TaskAwaitAdapter.GenericAdapter`1.BlockUntilCompleted()
> {code}
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunNetTests/7075329?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&pluginCoverage=true&expandBuildTestsSection=true&expandBuildChangesSection=true
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18794) .NET: Thin 3.0: DivideByZeroException in GetPreferredNode
[
https://issues.apache.org/jira/browse/IGNITE-18794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18794:
Ignite Flags: (was: Docs Required,Release Notes Required)
> .NET: Thin 3.0: DivideByZeroException in GetPreferredNode
> -
>
> Key: IGNITE-18794
> URL: https://issues.apache.org/jira/browse/IGNITE-18794
> Project: Ignite
> Issue Type: Improvement
> Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Flaky failure:
> {code}
> System.DivideByZeroException : Attempted to divide by zero.
>at Apache.Ignite.Internal.Table.Table.GetPreferredNode(Int32
> colocationHash, ITransaction transaction) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/Table.cs:line
> 197
>at
> Apache.Ignite.Internal.Compute.Compute.ExecuteColocatedAsync[T,TKey](String
> tableName, TKey key, Func`2 serializerHandlerFunc, String jobClassName,
> Object[] args) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Compute/Compute.cs:line
> 191
>at Apache.Ignite.Internal.Compute.Compute.ExecuteColocatedAsync[T](String
> tableName, IIgniteTuple key, String jobClassName, Object[] args)
>at
> Apache.Ignite.Tests.Compute.ComputeTests.TestExecuteColocatedUpdatesTableCacheOnTableDrop()
> in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Compute/ComputeTests.cs:line
> 281
>at
> Apache.Ignite.Tests.Compute.ComputeTests.TestExecuteColocatedUpdatesTableCacheOnTableDrop()
> in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Compute/ComputeTests.cs:line
> 287
>at
> NUnit.Framework.Internal.TaskAwaitAdapter.GenericAdapter`1.BlockUntilCompleted()
> {code}
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunNetTests/7075329?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&pluginCoverage=true&expandBuildTestsSection=true&expandBuildChangesSection=true
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18752) Sql. Bump calcite version to 1.33.0
[ https://issues.apache.org/jira/browse/IGNITE-18752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-18752: - Assignee: Maksim Zhuravkov > Sql. Bump calcite version to 1.33.0 > --- > > Key: IGNITE-18752 > URL: https://issues.apache.org/jira/browse/IGNITE-18752 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Evgeny Stanilovsky >Assignee: Maksim Zhuravkov >Priority: Major > Labels: calcite2-required, calcite3-required, ignite-3 > > New ver of apache calcite is available [1], ARG_MIN and ARG_MAX are appended > [2] probably we need to check it on ignite side. Also we need to remove > mention of CALCITE-5253 from code and fix a tests (for ai-3 only) and > CALCITE-5297 (for probably both) > [1] https://calcite.apache.org/docs/history.html#v1-33-0 > [2] https://issues.apache.org/jira/browse/CALCITE-5283 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-18394) Metastorage learners support
[ https://issues.apache.org/jira/browse/IGNITE-18394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev resolved IGNITE-18394. -- Resolution: Fixed > Metastorage learners support > > > Key: IGNITE-18394 > URL: https://issues.apache.org/jira/browse/IGNITE-18394 > Project: Ignite > Issue Type: Epic >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > > We want to use the learner mechanism in MetaStorage, i.e. a learner is > started on every Ignite node if it isn't already a voting member of the > MetaStorage Group. > This will allow us to simplify the current implementation in the following > ways: > 1. Get rid of a pull model based on Watchers. Instead all updates will arrive > at the Raft listener. > 2. Simplify MetaStorage Raft storage due to the removal of the Watch > functionality. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18783) DistributedProcess hangs if a single future completes with AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-18783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17688491#comment-17688491
]
Ignite TC Bot commented on IGNITE-18783:
{panel:title=Branch: [pull/10537/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10537/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Basic 1{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7049181]]
* {color:#013220}IgniteBasicTestSuite:
DistributedProcessTest.testAssertionErrorHandled - PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7048257&buildTypeId=IgniteTests24Java8_RunAll]
> DistributedProcess hangs if a single future completes with AssertionError
> -
>
> Key: IGNITE-18783
> URL: https://issues.apache.org/jira/browse/IGNITE-18783
> Project: Ignite
> Issue Type: Bug
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Fix For: 2.15
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> DistributedProcess#sendSingleMessage tries to cast local process future error
> to Exception, while it might completed with AssertionError.
> In a such case SingleMessage isn't sent, and originated node hangs while
> waiting response from the node.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18738) Implement Index Cleanup on transaction rollback
[ https://issues.apache.org/jira/browse/IGNITE-18738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-18738: - Labels: ignite-3 (was: ) > Implement Index Cleanup on transaction rollback > --- > > Key: IGNITE-18738 > URL: https://issues.apache.org/jira/browse/IGNITE-18738 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 50m > Remaining Estimate: 0h > > As part of the partition storage implementation , it is necessary to > implement an index cleanup mechanism for cases when transactions are aborted > and a rollback is required. This cleanup process should ensure that any index > updates made during the transaction are properly removed to maintain the > integrity. > This mechanism should be abstract enough so that it can be later used for the > garbage collection. > https://issues.apache.org/jira/browse/IGNITE-17673 contains a pseudo-code for > the index cleanup algorithm -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18789) Sql. The sign of the default values for precision and scale is not kept
[
https://issues.apache.org/jira/browse/IGNITE-18789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-18789:
-
Labels: ignite-3 (was: )
> Sql. The sign of the default values for precision and scale is not kept
> ---
>
> Key: IGNITE-18789
> URL: https://issues.apache.org/jira/browse/IGNITE-18789
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> SQL standard says:
> {code:java}
> If or is not specified explicitly, then the corresponding
> element of the descriptor effectively contains the null value.{code}
> But we keep our default values. That led to at least a few issues:
> 1) metadata will return incorrect information. For example type DECIMAL will
> be returned as DECIMAL(32767, 0)
> 2) The same issue will be for TYPEOF function for DECIMAL column will be
> returned DECIMAL(32767, 0)
> To fix the issue we should amend restrictions for configurations that are
> currently are not allowed to keep negative values and keep as special values
> sign default precision and/or scale, or do the properties like a nullable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18760) Prepare rebalance tickets breakdown
[ https://issues.apache.org/jira/browse/IGNITE-18760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-18760: - Labels: ignite-3 (was: ) > Prepare rebalance tickets breakdown > --- > > Key: IGNITE-18760 > URL: https://issues.apache.org/jira/browse/IGNITE-18760 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > > After the merging deisgn doc from IGNITE-18634 we need to breakdown the resul > design to separate atomic issues -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18752) Sql. Bump calcite version to 1.33.0
[ https://issues.apache.org/jira/browse/IGNITE-18752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-18752: - Component/s: sql > Sql. Bump calcite version to 1.33.0 > --- > > Key: IGNITE-18752 > URL: https://issues.apache.org/jira/browse/IGNITE-18752 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Evgeny Stanilovsky >Priority: Major > Labels: calcite2-required, calcite3-required, ignite-3 > > New ver of apache calcite is available [1], ARG_MIN and ARG_MAX are appended > [2] probably we need to check it on ignite side. Also we need to remove > mention of CALCITE-5253 from code and fix a tests (for ai-3 only) and > CALCITE-5297 (for probably both) > [1] https://calcite.apache.org/docs/history.html#v1-33-0 > [2] https://issues.apache.org/jira/browse/CALCITE-5283 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18752) Sql. Bump calcite version to 1.33.0
[ https://issues.apache.org/jira/browse/IGNITE-18752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-18752: - Labels: calcite2-required calcite3-required ignite-3 (was: calcite2-required calcite3-required) > Sql. Bump calcite version to 1.33.0 > --- > > Key: IGNITE-18752 > URL: https://issues.apache.org/jira/browse/IGNITE-18752 > Project: Ignite > Issue Type: Improvement >Reporter: Evgeny Stanilovsky >Priority: Major > Labels: calcite2-required, calcite3-required, ignite-3 > > New ver of apache calcite is available [1], ARG_MIN and ARG_MAX are appended > [2] probably we need to check it on ignite side. Also we need to remove > mention of CALCITE-5253 from code and fix a tests (for ai-3 only) and > CALCITE-5297 (for probably both) > [1] https://calcite.apache.org/docs/history.html#v1-33-0 > [2] https://issues.apache.org/jira/browse/CALCITE-5283 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18743) Prepare the first version of a design for schema synchronization
[ https://issues.apache.org/jira/browse/IGNITE-18743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-18743: - Labels: ignite-3 (was: ) > Prepare the first version of a design for schema synchronization > > > Key: IGNITE-18743 > URL: https://issues.apache.org/jira/browse/IGNITE-18743 > Project: Ignite > Issue Type: Task > Components: persistence >Reporter: Sergey Chugunov >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > The first version has to give an overall view of how schema synchronization > will work and how the most important cases will be addressed (like multiple > versions of schemas, concurrent user ops and so on). > Some ideas are explained (very briefly though) in > [IEP-91|https://cwiki.apache.org/confluence/display/IGNITE/IEP-91:+Transaction+protocol#IEP91:Transactionprotocol-Lock-freeRWtransactions] > document (see *Application to metadata management* section), we need to > clarify them and cover with more details. > As a result of the task should be a document and a set of several > ready-for-development tasks to implement at least happy-cases of the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18742) Implement logic for a maintenance phase of group lease management
[ https://issues.apache.org/jira/browse/IGNITE-18742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-18742: - Labels: ignite-3 (was: ) > Implement logic for a maintenance phase of group lease management > - > > Key: IGNITE-18742 > URL: https://issues.apache.org/jira/browse/IGNITE-18742 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18748) Sql. Planner optimization for JOIN. Benchmarks
[ https://issues.apache.org/jira/browse/IGNITE-18748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-18748: - Labels: ignite-3 (was: ) > Sql. Planner optimization for JOIN. Benchmarks > -- > > Key: IGNITE-18748 > URL: https://issues.apache.org/jira/browse/IGNITE-18748 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > We have an issue with long query planning for queries with a few joins. > Unfortunately, it is just our feeling and we don't have real understanding of > performance. > So, to have a real picture we should have the ability to run some benchmarks > and use it to evaluate any changes which could lead to increasing or > decreasing planning time. > Let's have a look at third-party tests which could use real-life queries, > e.g. TPCH, and snatch some set of the queries for our mini benchmark. Also > will need to provide some explanation why we use a concrete set of queries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18797) Sql. Custom types. Provide information about available custom data types to TypeUtils and ConverterUtils.
[ https://issues.apache.org/jira/browse/IGNITE-18797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-18797: --- Fix Version/s: (was: 3.0.0-beta2) > Sql. Custom types. Provide information about available custom data types to > TypeUtils and ConverterUtils. > -- > > Key: IGNITE-18797 > URL: https://issues.apache.org/jira/browse/IGNITE-18797 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: calcite2-required, calcite3-required, ignite-3 > > Provide information on available custom types to TypesUtils and > ConverterUtils to minimise the number of places to update, when a new custom > data type is added. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18739) Cleanup indexes as part of garbage collection
[ https://issues.apache.org/jira/browse/IGNITE-18739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-18739: - Labels: ignite-3 (was: ) > Cleanup indexes as part of garbage collection > - > > Key: IGNITE-18739 > URL: https://issues.apache.org/jira/browse/IGNITE-18739 > Project: Ignite > Issue Type: Improvement >Reporter: Semyon Danilov >Priority: Major > Labels: ignite-3 > > To maintain the integrity of the partition storage, it is necessary to > implement a mechanism for cleaning up indexes during the garbage collection > process. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-18582) Bootstrap Configuration: REST should modify conf file
[ https://issues.apache.org/jira/browse/IGNITE-18582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17688473#comment-17688473 ] Mikhail Pochatkin edited comment on IGNITE-18582 at 2/14/23 11:48 AM: -- Fixed by https://issues.apache.org/jira/browse/IGNITE-18581 was (Author: JIRAUSER289101): https://issues.apache.org/jira/browse/IGNITE-18581 > Bootstrap Configuration: REST should modify conf file > - > > Key: IGNITE-18582 > URL: https://issues.apache.org/jira/browse/IGNITE-18582 > Project: Ignite > Issue Type: New Feature > Components: build >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > > https://issues.apache.org/jira/browse/IGNITE-18581 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17647) Include in incremental snapshot transactions committed by TxRecovery
[ https://issues.apache.org/jira/browse/IGNITE-17647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-17647: Parent: (was: IGNITE-17177) Issue Type: Improvement (was: Sub-task) > Include in incremental snapshot transactions committed by TxRecovery > > > Key: IGNITE-17647 > URL: https://issues.apache.org/jira/browse/IGNITE-17647 > Project: Ignite > Issue Type: Improvement >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-89, ise > > Currently IS is considered inconsistent if any checked transction committed > during TxRecovery mechanism. > But there are cases when it's possisble to find whether tx should be included > to IS or not: > # Transaction on nodes are PREPARED > # Every node adds the transaction to await list > # Originated node (client) fails. > # Nodes starts communicate with each other to find transaction status. > During this communication it's possible to make a decision. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18443) Sql. Provide extend commands and handlers for distributed zones operation
[
https://issues.apache.org/jira/browse/IGNITE-18443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18443:
---
Epic Link: IGNITE-18528
> Sql. Provide extend commands and handlers for distributed zones operation
> -
>
> Key: IGNITE-18443
> URL: https://issues.apache.org/jira/browse/IGNITE-18443
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> After implementing IGNITE-18254 and IGNITE-18156 we have handlers just for
> part of parameters: name, {{{}DATA_NODES_AUTO_ADJUST{}}},
> DATA_NODES_AUTO_ADJUST_SCALE_UP, DATA_NODES_AUTO_ADJUST_SCALE_DOWN. Need to
> provide DDL commands and their handlers to altering and create zones
> configuration, as well as translation to these command from AST
> representation for all the rest parameters.
> As a result, we will be able to translate AST to a command (see
> DdlSqlToCommandConverter) and execute this command in order to apply changes
> to configuration (see DdlCommandHandler).
> The following configuration parameters should be covered by the ticket for
> CREATE and ALTER operations: PARTITIONS, REPLICAS, AFFINITY_FUNCTION,
> DATA_NODES_FILTER
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17647) Include in incremental snapshot transactions committed by TxRecovery
[ https://issues.apache.org/jira/browse/IGNITE-17647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-17647: Description: Currently IS is considered inconsistent if any checked transction committed during TxRecovery mechanism. But there are cases when it's possisble to find whether tx should be included to IS or not: # Transaction on nodes are PREPARED # Every node adds the transaction to await list # Originated node (client) fails. # Nodes starts communicate with each other to find transaction status. During this communication it's possible to make a decision. was: Cut is inconsistent, if a transaction wasn't set with txCutVer. It's possible for transaction recovery cases, when Near node failed and didn't send the Finish message on one or more participated nodes. But relying on transaction recovery protocol it's possible to assign txCutVer from primary, if at least single Finish message was sent. > Include in incremental snapshot transactions committed by TxRecovery > > > Key: IGNITE-17647 > URL: https://issues.apache.org/jira/browse/IGNITE-17647 > Project: Ignite > Issue Type: Sub-task >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-89, ise > > Currently IS is considered inconsistent if any checked transction committed > during TxRecovery mechanism. > But there are cases when it's possisble to find whether tx should be included > to IS or not: > # Transaction on nodes are PREPARED > # Every node adds the transaction to await list > # Originated node (client) fails. > # Nodes starts communicate with each other to find transaction status. > During this communication it's possible to make a decision. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17647) Include in incremental snapshot transactions committed by TxRecovery
[ https://issues.apache.org/jira/browse/IGNITE-17647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-17647: Summary: Include in incremental snapshot transactions committed by TxRecovery (was: Assign ConsistentCutVersion for transaction recovery case) > Include in incremental snapshot transactions committed by TxRecovery > > > Key: IGNITE-17647 > URL: https://issues.apache.org/jira/browse/IGNITE-17647 > Project: Ignite > Issue Type: Sub-task >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-89, ise > > Cut is inconsistent, if a transaction wasn't set with txCutVer. It's possible > for transaction recovery cases, when Near node failed and didn't send the > Finish message on one or more participated nodes. > But relying on transaction recovery protocol it's possible to assign txCutVer > from primary, if at least single Finish message was sent. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18801) Sql. UUID. Add an SQL function that generates a random UUID.
Maksim Zhuravkov created IGNITE-18801: - Summary: Sql. UUID. Add an SQL function that generates a random UUID. Key: IGNITE-18801 URL: https://issues.apache.org/jira/browse/IGNITE-18801 Project: Ignite Issue Type: Improvement Components: sql Affects Versions: 3.0.0-beta2 Reporter: Maksim Zhuravkov Add an SQL function that generates a random UUID. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18800) Create better DEVNOTES for Gradle build
Mikhail Pochatkin created IGNITE-18800: -- Summary: Create better DEVNOTES for Gradle build Key: IGNITE-18800 URL: https://issues.apache.org/jira/browse/IGNITE-18800 Project: Ignite Issue Type: Improvement Reporter: Mikhail Pochatkin Modify DEVNOTES and describe better ussual command for build, test, integrationTest, etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18799) Sql. Custom types. Implement a basic set of test cases for a custom data type.
Maksim Zhuravkov created IGNITE-18799: - Summary: Sql. Custom types. Implement a basic set of test cases for a custom data type. Key: IGNITE-18799 URL: https://issues.apache.org/jira/browse/IGNITE-18799 Project: Ignite Issue Type: Improvement Components: sql Affects Versions: 3.0.0-beta2 Reporter: Maksim Zhuravkov To simplify the process of adding a new custom data type it would be a good idea to have a basic set of test cases that automates (at least partially) the process of writing tests for a new custom data type. * CREATE TABLE (as non primary key column) * CREATE TABLE (as a primary key, if supported) * INSERT * UPDATE * SELECT * (WHERE clause) * ? Expressions: * IN expression * CASE expression * CASTS (if supported) * Binary comparison operators * Aggregate functions (if supported) * ? Other: * Dynamic Parameters * ? If a custom data type supports implicit casts from some type the above checks for v must be also provided. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18675) cleanup map on cache group destroy implemented
[ https://issues.apache.org/jira/browse/IGNITE-18675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17688458#comment-17688458 ] Vyacheslav Koptilin commented on IGNITE-18675: -- Hello [~brat_kuzma], Could you please provide more details on this issue? It is not quite clear what the issue is about. > cleanup map on cache group destroy implemented > -- > > Key: IGNITE-18675 > URL: https://issues.apache.org/jira/browse/IGNITE-18675 > Project: Ignite > Issue Type: Bug >Reporter: Denis Kuznetsov >Assignee: Denis Kuznetsov >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18798) Sql. Custom types. UUID literal.
Maksim Zhuravkov created IGNITE-18798:
-
Summary: Sql. Custom types. UUID literal.
Key: IGNITE-18798
URL: https://issues.apache.org/jira/browse/IGNITE-18798
Project: Ignite
Issue Type: Improvement
Components: sql
Affects Versions: 3.0.0-beta2
Reporter: Maksim Zhuravkov
At the moment in order to specify an UUID user must use a cast operator (string
-> uuid) or rely on implicit casts (which only work in some contexts).
Implement UUID literal in parser to allow to define an UUID literal.
{code:java}
SELECT UUID 'fd10556e-fc27-4a99-b5e4-89b8344cb3ce';
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18797) Sql. Custom types. Provide information about available custom data types to TypeUtils and ConverterUtils.
Maksim Zhuravkov created IGNITE-18797: - Summary: Sql. Custom types. Provide information about available custom data types to TypeUtils and ConverterUtils. Key: IGNITE-18797 URL: https://issues.apache.org/jira/browse/IGNITE-18797 Project: Ignite Issue Type: Improvement Components: sql Reporter: Maksim Zhuravkov Fix For: 3.0.0-beta2 Provide information on available custom types to TypesUtils and ConverterUtils to minimise the number of places to update, when a new custom data type is added. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18796) testRetryReadPolicyRetriesReadOperations is flaky
Pavel Tupitsyn created IGNITE-18796:
---
Summary: testRetryReadPolicyRetriesReadOperations is flaky
Key: IGNITE-18796
URL: https://issues.apache.org/jira/browse/IGNITE-18796
Project: Ignite
Issue Type: Improvement
Components: thin client
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 3.0.0-beta2
{code}
org.apache.ignite.client.IgniteClientConnectionException: IGN-CLIENT-1
TraceId:043303fc-3705-4eea-a7b3-81c7692a3807 IGN-CLIENT-1
TraceId:043303fc-3705-4eea-a7b3-81c7692a3807 Channel is closed
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at org.apache.ignite.lang.IgniteException.wrap(IgniteException.java:277)
at
org.apache.ignite.internal.client.ClientUtils.sync(ClientUtils.java:50)
at
org.apache.ignite.internal.client.table.ClientRecordBinaryView.get(ClientRecordBinaryView.java:62)
at
org.apache.ignite.internal.client.table.ClientRecordBinaryView.get(ClientRecordBinaryView.java:40)
at
org.apache.ignite.client.RetryPolicyTest.testRetryReadPolicyRetriesReadOperations(RetryPolicyTest.java:178)
at jdk.internal.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:725)
at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
at
org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:214)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:210)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:135)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:66)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at
org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:9
[jira] [Updated] (IGNITE-18796) testRetryReadPolicyRetriesReadOperations is flaky
[
https://issues.apache.org/jira/browse/IGNITE-18796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18796:
Labels: ignite-3 (was: )
> testRetryReadPolicyRetriesReadOperations is flaky
> -
>
> Key: IGNITE-18796
> URL: https://issues.apache.org/jira/browse/IGNITE-18796
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> {code}
> org.apache.ignite.client.IgniteClientConnectionException: IGN-CLIENT-1
> TraceId:043303fc-3705-4eea-a7b3-81c7692a3807 IGN-CLIENT-1
> TraceId:043303fc-3705-4eea-a7b3-81c7692a3807 Channel is closed
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
> at org.apache.ignite.lang.IgniteException.wrap(IgniteException.java:277)
> at
> org.apache.ignite.internal.client.ClientUtils.sync(ClientUtils.java:50)
> at
> org.apache.ignite.internal.client.table.ClientRecordBinaryView.get(ClientRecordBinaryView.java:62)
> at
> org.apache.ignite.internal.client.table.ClientRecordBinaryView.get(ClientRecordBinaryView.java:40)
> at
> org.apache.ignite.client.RetryPolicyTest.testRetryReadPolicyRetriesReadOperations(RetryPolicyTest.java:178)
> at jdk.internal.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:725)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:214)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:210)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:135)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:66)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
> at
> org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask
[jira] [Updated] (IGNITE-18794) .NET: Thin 3.0: DivideByZeroException in GetPreferredNode
[
https://issues.apache.org/jira/browse/IGNITE-18794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18794:
Labels: .NET ignite-3 (was: )
> .NET: Thin 3.0: DivideByZeroException in GetPreferredNode
> -
>
> Key: IGNITE-18794
> URL: https://issues.apache.org/jira/browse/IGNITE-18794
> Project: Ignite
> Issue Type: Improvement
> Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Flaky failure:
> {code}
> System.DivideByZeroException : Attempted to divide by zero.
>at Apache.Ignite.Internal.Table.Table.GetPreferredNode(Int32
> colocationHash, ITransaction transaction) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/Table.cs:line
> 197
>at
> Apache.Ignite.Internal.Compute.Compute.ExecuteColocatedAsync[T,TKey](String
> tableName, TKey key, Func`2 serializerHandlerFunc, String jobClassName,
> Object[] args) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Compute/Compute.cs:line
> 191
>at Apache.Ignite.Internal.Compute.Compute.ExecuteColocatedAsync[T](String
> tableName, IIgniteTuple key, String jobClassName, Object[] args)
>at
> Apache.Ignite.Tests.Compute.ComputeTests.TestExecuteColocatedUpdatesTableCacheOnTableDrop()
> in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Compute/ComputeTests.cs:line
> 281
>at
> Apache.Ignite.Tests.Compute.ComputeTests.TestExecuteColocatedUpdatesTableCacheOnTableDrop()
> in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Compute/ComputeTests.cs:line
> 287
>at
> NUnit.Framework.Internal.TaskAwaitAdapter.GenericAdapter`1.BlockUntilCompleted()
> {code}
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunNetTests/7075329?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&pluginCoverage=true&expandBuildTestsSection=true&expandBuildChangesSection=true
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18720) Failed to find IncrementalSnapshotFinishRecord if snapshot has multiple segments
[ https://issues.apache.org/jira/browse/IGNITE-18720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-18720: Description: Currently IS during restore checks IncrementalSnapshotFinishRecord in last segment, but it's incorrectly get it. Files.list() doesn't provide guarantees for ordering, also alphabetical order might be wrong - we must check FileDescriptor of WAL segment to ensure the order. (was: By default WAL iterator skips corrupted segment. For restoring snapshot it's required to fail if segment is corrupted.) > Failed to find IncrementalSnapshotFinishRecord if snapshot has multiple > segments > > > Key: IGNITE-18720 > URL: https://issues.apache.org/jira/browse/IGNITE-18720 > Project: Ignite > Issue Type: Sub-task >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-89, ise > Time Spent: 10m > Remaining Estimate: 0h > > Currently IS during restore checks IncrementalSnapshotFinishRecord in last > segment, but it's incorrectly get it. Files.list() doesn't provide guarantees > for ordering, also alphabetical order might be wrong - we must check > FileDescriptor of WAL segment to ensure the order. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18720) Failed to find IncrementalSnapshotFinishRecord if snapshot has multiple segments
[ https://issues.apache.org/jira/browse/IGNITE-18720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-18720: Summary: Failed to find IncrementalSnapshotFinishRecord if snapshot has multiple segments (was: Validate corrupted WAL segment while restoring incremental snapshot) > Failed to find IncrementalSnapshotFinishRecord if snapshot has multiple > segments > > > Key: IGNITE-18720 > URL: https://issues.apache.org/jira/browse/IGNITE-18720 > Project: Ignite > Issue Type: Sub-task >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-89, ise > Time Spent: 10m > Remaining Estimate: 0h > > By default WAL iterator skips corrupted segment. For restoring snapshot it's > required to fail if segment is corrupted. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18788) Query listener in python thin client fire events only if a debug logging level enabled
[ https://issues.apache.org/jira/browse/IGNITE-18788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-18788: - Release Note: * Fixed query listener firing events only if a debug logging level enabled > Query listener in python thin client fire events only if a debug logging > level enabled > -- > > Key: IGNITE-18788 > URL: https://issues.apache.org/jira/browse/IGNITE-18788 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Affects Versions: python-0.6.0 >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Minor > Fix For: python-0.6.1 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-18788) Query listener in python thin client fire events only if a debug logging level enabled
[ https://issues.apache.org/jira/browse/IGNITE-18788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky resolved IGNITE-18788. -- Resolution: Fixed [~NIzhikov] Thanks for review, merged > Query listener in python thin client fire events only if a debug logging > level enabled > -- > > Key: IGNITE-18788 > URL: https://issues.apache.org/jira/browse/IGNITE-18788 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Affects Versions: python-0.6.0 >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Minor > Fix For: python-0.6.1 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18795) ItClusterManagerTest#testNodeRestart is flaky
[
https://issues.apache.org/jira/browse/IGNITE-18795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-18795:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> ItClusterManagerTest#testNodeRestart is flaky
> -
>
> Key: IGNITE-18795
> URL: https://issues.apache.org/jira/browse/IGNITE-18795
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
>
> This test fails sometimes with the following error:
> {noformat}
> java.lang.AssertionError:
> Expected: is iterable with items [ [id=65b15c06-2a55-4718-ac16-033a4e12775c, name=icmt_tnr_1,
> address=192.168.10.11:1, nodeMetadata=null]>, [id=a2386ee4-1190-4160-bda2-004d469c282b, name=icmt_tnr_10001,
> address=192.168.10.11:10001, nodeMetadata=null]>] in any order
> but: was <[ClusterNode [id=65b15c06-2a55-4718-ac16-033a4e12775c,
> name=icmt_tnr_1, address=192.168.10.11:1, nodeMetadata=null]]>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18795) ItClusterManagerTest#testNodeRestart is flaky
Aleksandr Polovtcev created IGNITE-18795:
Summary: ItClusterManagerTest#testNodeRestart is flaky
Key: IGNITE-18795
URL: https://issues.apache.org/jira/browse/IGNITE-18795
Project: Ignite
Issue Type: Bug
Reporter: Aleksandr Polovtcev
Assignee: Aleksandr Polovtcev
This test fails sometimes with the following error:
{noformat}
java.lang.AssertionError:
Expected: is iterable with items [, ] in any order
but: was <[ClusterNode [id=65b15c06-2a55-4718-ac16-033a4e12775c,
name=icmt_tnr_1, address=192.168.10.11:1, nodeMetadata=null]]>
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18795) ItClusterManagerTest#testNodeRestart is flaky
[
https://issues.apache.org/jira/browse/IGNITE-18795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-18795:
-
Labels: ignite-3 (was: )
> ItClusterManagerTest#testNodeRestart is flaky
> -
>
> Key: IGNITE-18795
> URL: https://issues.apache.org/jira/browse/IGNITE-18795
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
> Labels: ignite-3
>
> This test fails sometimes with the following error:
> {noformat}
> java.lang.AssertionError:
> Expected: is iterable with items [ [id=65b15c06-2a55-4718-ac16-033a4e12775c, name=icmt_tnr_1,
> address=192.168.10.11:1, nodeMetadata=null]>, [id=a2386ee4-1190-4160-bda2-004d469c282b, name=icmt_tnr_10001,
> address=192.168.10.11:10001, nodeMetadata=null]>] in any order
> but: was <[ClusterNode [id=65b15c06-2a55-4718-ac16-033a4e12775c,
> name=icmt_tnr_1, address=192.168.10.11:1, nodeMetadata=null]]>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18722) C++ thin: inconsistent state SQL and direct KV api during tx
[ https://issues.apache.org/jira/browse/IGNITE-18722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17688418#comment-17688418 ] Igor Sapego commented on IGNITE-18722: -- For other API usage questions please send a message to user mailing list (you can find it here: https://ignite.apache.org/resources.html), or stack overflow. > C++ thin: inconsistent state SQL and direct KV api during tx > > > Key: IGNITE-18722 > URL: https://issues.apache.org/jira/browse/IGNITE-18722 > Project: Ignite > Issue Type: Bug > Components: sql, thin client >Affects Versions: 2.14 > Environment: Windows 10 x64 > ignite 2.14.0 >Reporter: Christopher Tenter >Priority: Major > > My cache config looks like this: > > > > > > > > > > > > > value="java.lang.String"/> > value="G3::VirtualFile"/> > > value="virtualName"/> > > > value="java.lang.String"/> > value="java.lang.String"/> > value="java.lang.UUID"/> > value="java.lang.Boolean"/> > > > > > > > > # create cache > # start a tx on it > # write key-value pairs with the key-value api > # use sql query to read these pairs > > The SQL queries cannot see the key-value pairs for as long as the transaction > is open. After commit they become visible in SQL. It is problematic because I > rely on the SQL query to iterate through the KV pairs, as there seems to be > no other way to iterate a cache. This way I have to do additional bookkeeping > of which pairs have changed in the tx and fix the SQL query results when a tx > is running. > Is this a cache config issue or intended behavior? A way to iterate the cache > items in the key-value API would be appreciated too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-18722) C++ thin: inconsistent state SQL and direct KV api during tx
[ https://issues.apache.org/jira/browse/IGNITE-18722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego resolved IGNITE-18722. -- Resolution: Not A Problem > C++ thin: inconsistent state SQL and direct KV api during tx > > > Key: IGNITE-18722 > URL: https://issues.apache.org/jira/browse/IGNITE-18722 > Project: Ignite > Issue Type: Bug > Components: sql, thin client >Affects Versions: 2.14 > Environment: Windows 10 x64 > ignite 2.14.0 >Reporter: Christopher Tenter >Priority: Major > > My cache config looks like this: > > > > > > > > > > > > > value="java.lang.String"/> > value="G3::VirtualFile"/> > > value="virtualName"/> > > > value="java.lang.String"/> > value="java.lang.String"/> > value="java.lang.UUID"/> > value="java.lang.Boolean"/> > > > > > > > > # create cache > # start a tx on it > # write key-value pairs with the key-value api > # use sql query to read these pairs > > The SQL queries cannot see the key-value pairs for as long as the transaction > is open. After commit they become visible in SQL. It is problematic because I > rely on the SQL query to iterate through the KV pairs, as there seems to be > no other way to iterate a cache. This way I have to do additional bookkeeping > of which pairs have changed in the tx and fix the SQL query results when a tx > is running. > Is this a cache config issue or intended behavior? A way to iterate the cache > items in the key-value API would be appreciated too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18267) Set up parallel feature for CDC build configuration
[ https://issues.apache.org/jira/browse/IGNITE-18267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov updated IGNITE-18267: --- Priority: Minor (was: Major) > Set up parallel feature for CDC build configuration > --- > > Key: IGNITE-18267 > URL: https://issues.apache.org/jira/browse/IGNITE-18267 > Project: Ignite > Issue Type: Sub-task > Components: extensions >Reporter: Ilya Shishkov >Priority: Minor > Labels: DevOps, IEP-59, ise, teamcity > > Parallel testing can be done by adding _Parallel tests_ feature [1] to CDC > build configuration here [2]. > # https://www.jetbrains.com/help/teamcity/cloud/parallel-tests.html > # > https://ci.ignite.apache.org/admin/editBuildFeatures.html?id=buildType:IgniteExtensions_Tests_Cdc -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18722) C++ thin: inconsistent state SQL and direct KV api during tx
[ https://issues.apache.org/jira/browse/IGNITE-18722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17688415#comment-17688415 ] Igor Sapego commented on IGNITE-18722: -- Hello, [~ct7]. This is a known limitation - current SQL implementation is not transactional, only KV API is affected by transactions. > C++ thin: inconsistent state SQL and direct KV api during tx > > > Key: IGNITE-18722 > URL: https://issues.apache.org/jira/browse/IGNITE-18722 > Project: Ignite > Issue Type: Bug > Components: sql, thin client >Affects Versions: 2.14 > Environment: Windows 10 x64 > ignite 2.14.0 >Reporter: Christopher Tenter >Priority: Major > > My cache config looks like this: > > > > > > > > > > > > > value="java.lang.String"/> > value="G3::VirtualFile"/> > > value="virtualName"/> > > > value="java.lang.String"/> > value="java.lang.String"/> > value="java.lang.UUID"/> > value="java.lang.Boolean"/> > > > > > > > > # create cache > # start a tx on it > # write key-value pairs with the key-value api > # use sql query to read these pairs > > The SQL queries cannot see the key-value pairs for as long as the transaction > is open. After commit they become visible in SQL. It is problematic because I > rely on the SQL query to iterate through the KV pairs, as there seems to be > no other way to iterate a cache. This way I have to do additional bookkeeping > of which pairs have changed in the tx and fix the SQL query results when a tx > is running. > Is this a cache config issue or intended behavior? A way to iterate the cache > items in the key-value API would be appreciated too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18793) Create public docs for LINQ
[ https://issues.apache.org/jira/browse/IGNITE-18793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Gusev reassigned IGNITE-18793: --- Assignee: Igor Gusev > Create public docs for LINQ > --- > > Key: IGNITE-18793 > URL: https://issues.apache.org/jira/browse/IGNITE-18793 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Labels: LINQ, ignite-3 > > We need to add public documentation for LINQ. See developer docs for the > feature: > https://github.com/apache/ignite-3/pull/1668/files#diff-3724a56204d638a452bcc442d20f2c21bedb421ef0b4535e442a782397bd3a5d -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18794) .NET: Thin 3.0: DivideByZeroException in GetPreferredNode
Pavel Tupitsyn created IGNITE-18794:
---
Summary: .NET: Thin 3.0: DivideByZeroException in GetPreferredNode
Key: IGNITE-18794
URL: https://issues.apache.org/jira/browse/IGNITE-18794
Project: Ignite
Issue Type: Improvement
Components: platforms, thin client
Affects Versions: 3.0.0-beta1
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 3.0.0-beta2
Flaky failure:
{code}
System.DivideByZeroException : Attempted to divide by zero.
at Apache.Ignite.Internal.Table.Table.GetPreferredNode(Int32 colocationHash,
ITransaction transaction) in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/Table.cs:line
197
at
Apache.Ignite.Internal.Compute.Compute.ExecuteColocatedAsync[T,TKey](String
tableName, TKey key, Func`2 serializerHandlerFunc, String jobClassName,
Object[] args) in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Compute/Compute.cs:line
191
at Apache.Ignite.Internal.Compute.Compute.ExecuteColocatedAsync[T](String
tableName, IIgniteTuple key, String jobClassName, Object[] args)
at
Apache.Ignite.Tests.Compute.ComputeTests.TestExecuteColocatedUpdatesTableCacheOnTableDrop()
in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Compute/ComputeTests.cs:line
281
at
Apache.Ignite.Tests.Compute.ComputeTests.TestExecuteColocatedUpdatesTableCacheOnTableDrop()
in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Compute/ComputeTests.cs:line
287
at
NUnit.Framework.Internal.TaskAwaitAdapter.GenericAdapter`1.BlockUntilCompleted()
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18794) .NET: Thin 3.0: DivideByZeroException in GetPreferredNode
[
https://issues.apache.org/jira/browse/IGNITE-18794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18794:
Description:
Flaky failure:
{code}
System.DivideByZeroException : Attempted to divide by zero.
at Apache.Ignite.Internal.Table.Table.GetPreferredNode(Int32 colocationHash,
ITransaction transaction) in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/Table.cs:line
197
at
Apache.Ignite.Internal.Compute.Compute.ExecuteColocatedAsync[T,TKey](String
tableName, TKey key, Func`2 serializerHandlerFunc, String jobClassName,
Object[] args) in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Compute/Compute.cs:line
191
at Apache.Ignite.Internal.Compute.Compute.ExecuteColocatedAsync[T](String
tableName, IIgniteTuple key, String jobClassName, Object[] args)
at
Apache.Ignite.Tests.Compute.ComputeTests.TestExecuteColocatedUpdatesTableCacheOnTableDrop()
in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Compute/ComputeTests.cs:line
281
at
Apache.Ignite.Tests.Compute.ComputeTests.TestExecuteColocatedUpdatesTableCacheOnTableDrop()
in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Compute/ComputeTests.cs:line
287
at
NUnit.Framework.Internal.TaskAwaitAdapter.GenericAdapter`1.BlockUntilCompleted()
{code}
https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunNetTests/7075329?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&pluginCoverage=true&expandBuildTestsSection=true&expandBuildChangesSection=true
was:
Flaky failure:
{code}
System.DivideByZeroException : Attempted to divide by zero.
at Apache.Ignite.Internal.Table.Table.GetPreferredNode(Int32 colocationHash,
ITransaction transaction) in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/Table.cs:line
197
at
Apache.Ignite.Internal.Compute.Compute.ExecuteColocatedAsync[T,TKey](String
tableName, TKey key, Func`2 serializerHandlerFunc, String jobClassName,
Object[] args) in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Compute/Compute.cs:line
191
at Apache.Ignite.Internal.Compute.Compute.ExecuteColocatedAsync[T](String
tableName, IIgniteTuple key, String jobClassName, Object[] args)
at
Apache.Ignite.Tests.Compute.ComputeTests.TestExecuteColocatedUpdatesTableCacheOnTableDrop()
in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Compute/ComputeTests.cs:line
281
at
Apache.Ignite.Tests.Compute.ComputeTests.TestExecuteColocatedUpdatesTableCacheOnTableDrop()
in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Compute/ComputeTests.cs:line
287
at
NUnit.Framework.Internal.TaskAwaitAdapter.GenericAdapter`1.BlockUntilCompleted()
{code}
> .NET: Thin 3.0: DivideByZeroException in GetPreferredNode
> -
>
> Key: IGNITE-18794
> URL: https://issues.apache.org/jira/browse/IGNITE-18794
> Project: Ignite
> Issue Type: Improvement
> Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Fix For: 3.0.0-beta2
>
>
> Flaky failure:
> {code}
> System.DivideByZeroException : Attempted to divide by zero.
>at Apache.Ignite.Internal.Table.Table.GetPreferredNode(Int32
> colocationHash, ITransaction transaction) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/Table.cs:line
> 197
>at
> Apache.Ignite.Internal.Compute.Compute.ExecuteColocatedAsync[T,TKey](String
> tableName, TKey key, Func`2 serializerHandlerFunc, String jobClassName,
> Object[] args) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Compute/Compute.cs:line
> 191
>at Apache.Ignite.Internal.Compute.Compute.ExecuteColocatedAsync[T](String
> tableName, IIgniteTuple key, String jobClassName, Object[] args)
>at
> Apache.Ignite.Tests.Compute.ComputeTests.TestExecuteColocatedUpdatesTableCacheOnTableDrop()
> in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Compute/ComputeTests.cs:line
> 281
>at
> Apache.Ignite.Tests.Compute.ComputeTests.TestExecuteColocatedUpdatesTableCacheOnTableDrop()
> in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Compute/ComputeTests.cs:line
> 287
>at
> NUnit.Framework.Internal.TaskAwaitAdapter.GenericAdapter`1.BlockUntilCompleted()
> {code}
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunNetTests/7075329?hideProblemsFromDepende
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
https://issues.apache.org/jira/browse/IGNITE-15322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-15322:
Description:
For example, this code needs TASK_EXECUTE permissions.
{code:java}
Affinity affinity = ignite.affinity("TEST");
affinity.mapKeysToNodes(Arrays.asList(1L,100L, 1000L));{code}
This is unexpected behavior, because:
- the task started implicitly (under the hood), customer should not to know
about it.
- this is a system task (not defined by a customer), the tasks needs for a
normal grid workflow.
Also, I suppose there are any other implicitly tasks, which could lead to
unexpected behavior (need permissions).
Proposed way to solve this issue:
1. Add mechanism to destinguish whether task class is SYSTEM (part of the
Ignite codebase) or USER.
Here we can reuse SecurityUtils#isSystemType mechanism that is used in Ignite
Sanbox implementation.
2. Add mechanism to detect if task execution was initiated by the user (PUBLIC
CALL) or by the Ignite system itself (INTERNAL CALL).
It seems that the easiest way to achieve this is to completely separate the
public and private Compute APIs.
Task executioin requests received through Ignite Thin Clients are considered
PUBLIC CALLs.
The first two steps give us the ability to
A. safely skip authorization of SYSTEM tasks which are
called through INTERNAL API.
B. keep authorization of PUBLIC tasks intact
C. prevent users of calling SYSTEM tasks directly through PUBLIC API ( it means
that all user task execution requests received through REST or Thin client
protocols MUST be executed through PUBLIC API).
3. Add the ability to explicitly specify for SYSTEM
task/callable/runnable/closure what permission should be checked before its
execution.
It can be solved by introducing optionsl interface that compute job can
implement.
{code:java}
/** */
public interface SecurityAwareJob {
/** */
public SecurityPermissionSet requiredPermissions();
}
{code}
4. SYSTEM tasks can splitted into two categories -
SYSTEM INTERNAL (tasks that are not available to the user) and SYSTEM PUBLIC
tasks (tasks that are part oof the ignite code but are available to the user
and can be executed through the PUBLIC API)
Examples of SYSTEM public tasks -
- Visor tasks on which the user control script is implemented
- JDBC tasks
All of them are executed through Thin Client which is considered Public API.
Considering that SYSTEM PUBLIC tasks can potentially be executed by the user,
we must force the developer to explicitly specify permissions for tasks of this
type. It can be done by checking that SYSTEM tasks that are executed through
PUBLIC API impelements SecurityPermissionAware interface described above.
||X||Public API||Private API||
|PUBLIC task|auth by task name|restricted|
|SYSTEM INTERNAL task|restricted|auth skipped|
|SYSTEM PUBLIC task|auth by explicitly specified permissions|auth by explicitly
specified permissions|
5. Authorization of SYSTEM tasks cancellation must be skipped it they are
canceled by the same user who started them, oterwise dedicated permissions is
required (e.g. ADMIN_KILL). USER tasks cancellation is performed by their names.
Possible troubles:
1. Mentioned SecurityUtils#isSystemType works only for the ignite-core module.
If some tasks are defined inside other Ignite modules - they will not be
considered SYSTEM. Currently there are no such task.
2. Currently all DotNet tasks are authorized by the name of the SYSTEM wrapper
task. We should decide how to properly fix their authorization.
3. We must decide what permissions are required for Visor tasks.
was:
For example, this code needs TASK_EXECUTE permissions.
{code:java}
Affinity affinity = ignite.affinity("TEST");
affinity.mapKeysToNodes(Arrays.asList(1L,100L, 1000L));{code}
This is unexpected behavior, because:
- the task started implicitly (under the hood), customer should not to know
about it.
- this is a system task (not defined by a customer), the tasks needs for a
normal grid workflow.
Also, I suppose there are any other implicitly tasks, which could lead to
unexpected behavior (need permissions).
Proposed way to solve this issue:
1. Add mechanism to destinguish whether task class is SYSTEM (part of the
Ignite codebase) or USER.
Here we can reuse SecurityUtils#isSystemType mechanism that is used in Ignite
Sanbox implementation.
2. Add mechanism to detect if task execution was initiated by the user (PUBLIC
CALL) or by the Ignite system itself (INTERNAL CALL).
It seems that the easiest way to achieve this is to completely separate the
public and private Compute APIs.
Task executioin requests received through Ignite Thin Clients are considered
PUBLIC CALLs.
The first two steps give us the ability to
A. safely skip authorization of SYSTEM tasks which are
called through INTERNAL API.
B. keep authorization of PUBLIC tasks intact
C. prevent u
[jira] [Assigned] (IGNITE-18741) Implement PD-side logic for an initialization phase of group lease management
[ https://issues.apache.org/jira/browse/IGNITE-18741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov reassigned IGNITE-18741: -- Assignee: Vladislav Pyatkov > Implement PD-side logic for an initialization phase of group lease management > - > > Key: IGNITE-18741 > URL: https://issues.apache.org/jira/browse/IGNITE-18741 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > Attachments: Снимок экрана от 2023-02-07 15-49-29.png, Снимок экрана > от 2023-02-07 16-23-51.png > > > h3. Motivation > There are two phases of lease management: > * *initialization* - _new_ leases management. // marked with greed > * *maintenance* - already existing leases management. // marked with orange > !Снимок экрана от 2023-02-07 15-49-29.png! > Given ticket is about new leases management on the placement driver side(the > active actor one). So it covers the *flow* from the detection of a > replication group appearance in the logical topology *to* sending leaseGrant > message to the primary replica candidate. > h3. Definition of Done > # All triggers related to new primary replica candidate appearance are > covered. > # Placement driver starts primary replica candidate promotion event loop. > h3. Implementation Notes > 1.Following events should be considered as triggers related to new primary > replica candidate appearance: > * MetaStorage based logical topology updates. We use MS and not CMG events > here in order to linearize logical topology updates with other configuration > events. Please pay attention that DistributionZone logic is responsible for > population ms with logical topology, following key > DISTRIBUTION_ZONE_LOGICAL_TOPOLOGY_KEY is used and yep we may rename it. > * Replication group assignment updates. > As usual, we should first register listeners and then initialize the flow > according to already existing assignments and logical topology. > 2. Following steps inside primary replica candidate promotion event loop are > expected > !Снимок экрана от 2023-02-07 16-23-51.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18793) Create public docs for LINQ
Igor Gusev created IGNITE-18793: --- Summary: Create public docs for LINQ Key: IGNITE-18793 URL: https://issues.apache.org/jira/browse/IGNITE-18793 Project: Ignite Issue Type: Task Components: documentation Reporter: Igor Gusev We need to add public documentation for LINQ. See developer docs for the feature: https://github.com/apache/ignite-3/pull/1668/files#diff-3724a56204d638a452bcc442d20f2c21bedb421ef0b4535e442a782397bd3a5d -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18792) Create docs for Distribution zones
[ https://issues.apache.org/jira/browse/IGNITE-18792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Gusev updated IGNITE-18792: Description: We need to add docs for distribution zones feature. (was: We need to add public documentation for LINQ. See developer docs for the feature: https://github.com/apache/ignite-3/pull/1668/files#diff-3724a56204d638a452bcc442d20f2c21bedb421ef0b4535e442a782397bd3a5d) > Create docs for Distribution zones > -- > > Key: IGNITE-18792 > URL: https://issues.apache.org/jira/browse/IGNITE-18792 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Priority: Major > Labels: LINQ, ignite-3 > > We need to add docs for distribution zones feature. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18792) Create docs for Distribution zones
[ https://issues.apache.org/jira/browse/IGNITE-18792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Gusev updated IGNITE-18792: Labels: ignite-3 (was: LINQ ignite-3) > Create docs for Distribution zones > -- > > Key: IGNITE-18792 > URL: https://issues.apache.org/jira/browse/IGNITE-18792 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Priority: Major > Labels: ignite-3 > > We need to add docs for distribution zones feature. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18792) Create docs for Distribution zones
Igor Gusev created IGNITE-18792: --- Summary: Create docs for Distribution zones Key: IGNITE-18792 URL: https://issues.apache.org/jira/browse/IGNITE-18792 Project: Ignite Issue Type: Task Components: documentation Reporter: Igor Gusev We need to add public documentation for LINQ. See developer docs for the feature: https://github.com/apache/ignite-3/pull/1668/files#diff-3724a56204d638a452bcc442d20f2c21bedb421ef0b4535e442a782397bd3a5d -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18773) .NET: Thin 3.0: Document LINQ features
[ https://issues.apache.org/jira/browse/IGNITE-18773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17688383#comment-17688383 ] Pavel Tupitsyn commented on IGNITE-18773: - Merged to main: 68c7200fbb8284e793c154a4a1b32f8e232acdac > .NET: Thin 3.0: Document LINQ features > -- > > Key: IGNITE-18773 > URL: https://issues.apache.org/jira/browse/IGNITE-18773 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta2 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: LINQ, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Add README.md which describes all supported LINQ features. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18773) .NET: Thin 3.0: Document LINQ features
[ https://issues.apache.org/jira/browse/IGNITE-18773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17688379#comment-17688379 ] Igor Gusev commented on IGNITE-18773: - Looks great! > .NET: Thin 3.0: Document LINQ features > -- > > Key: IGNITE-18773 > URL: https://issues.apache.org/jira/browse/IGNITE-18773 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta2 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: LINQ, ignite-3 > Fix For: 3.0.0-beta2 > > > Add README.md which describes all supported LINQ features. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
https://issues.apache.org/jira/browse/IGNITE-15322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-15322:
Description:
For example, this code needs TASK_EXECUTE permissions.
{code:java}
Affinity affinity = ignite.affinity("TEST");
affinity.mapKeysToNodes(Arrays.asList(1L,100L, 1000L));{code}
This is unexpected behavior, because:
- the task started implicitly (under the hood), customer should not to know
about it.
- this is a system task (not defined by a customer), the tasks needs for a
normal grid workflow.
Also, I suppose there are any other implicitly tasks, which could lead to
unexpected behavior (need permissions).
Proposed way to solve this issue:
1. Add mechanism to destinguish whether task class is SYSTEM (part of the
Ignite codebase) or USER.
Here we can reuse SecurityUtils#isSystemType mechanism that is used in Ignite
Sanbox implementation.
2. Add mechanism to detect if task execution was initiated by the user (PUBLIC
CALL) or by the Ignite system itself (INTERNAL CALL).
It seems that the easiest way to achieve this is to completely separate the
public and private Compute APIs.
Task executioin requests received through Ignite Thin Clients are considered
PUBLIC CALLs.
The first two steps give us the ability to
A. safely skip authorization of SYSTEM tasks which are
called through INTERNAL API.
B. keep authorization of PUBLIC tasks intact
C. prevent users of calling SYSTEM tasks directly through PUBLIC API ( it means
that all user task execution requests received through REST or Thin client
protocols MUST be executed through PUBLIC API).
3. Add the ability to explicitly specify for SYSTEM
task/callable/runnable/closure what permission should be checked before its
execution. This helps to skip sending task execution requests between nodes if
the user does not have permission to execute the task.
It can be solved by introducing optionsl interface that compute job can
implement.
{code:java}
/** */
public interface SecurityAwareJob {
/** */
public SecurityPermissionSet requiredPermissions();
}
{code}
4. SYSTEM tasks can splitted into two categories -
SYSTEM INTERNAL (tasks that are not available to the user) and SYSTEM PUBLIC
tasks (tasks that are part oof the ignite code but are available to the user
and can be executed through the PUBLIC API)
Examples of SYSTEM public tasks -
- Visor tasks on which the user control script is implemented
- JDBC tasks
All of them are executed through Thin Client which is considered Public API.
Considering that SYSTEM PUBLIC tasks can potentially be executed by the user,
we must force the developer to explicitly specify permissions for tasks of this
type. It can be done by checking that SYSTEM tasks that are executed through
PUBLIC API impelements SecurityPermissionAware interface described above.
||X||Public API||Private API||
|PUBLIC task|auth by task name|restricted|
|SYSTEM INTERNAL task|restricted|auth skipped|
|SYSTEM PUBLIC task|auth by explicitly specified permissions|auth by explicitly
specified permissions|
5. Authorization of SYSTEM tasks cancellation must be skipped it they are
canceled by the same user who started them, oterwise dedicated permissions is
required (e.g. ADMIN_KILL). USER tasks cancellation is performed by their names.
Possible troubles:
1. Mentioned SecurityUtils#isSystemType works only for the ignite-core module.
If some tasks are defined inside other Ignite modules - they will not be
considered SYSTEM. Currently there are no such task.
2. Currently all DotNet tasks are authorized by the name of the SYSTEM wrapper
task. We should decide how to properly fix their authorization.
3. We must decide what permissions are required for Visor tasks.
was:
For example, this code needs TASK_EXECUTE permissions.
{code:java}
Affinity affinity = ignite.affinity("TEST");
affinity.mapKeysToNodes(Arrays.asList(1L,100L, 1000L));{code}
This is unexpected behavior, because:
- the task started implicitly (under the hood), customer should not to know
about it.
- this is a system task (not defined by a customer), the tasks needs for a
normal grid workflow.
Also, I suppose there are any other implicitly tasks, which could lead to
unexpected behavior (need permissions).
Proposed way to solve this issue:
1. Add mechanism to destinguish whether task class is SYSTEM (part of the
Ignite codebase) or USER.
Here we can reuse SecurityUtils#isSystemType mechanism that is used in Ignite
Sanbox implementation.
2. Add mechanism to detect if task execution was initiated by the user (PUBLIC
CALL) or by the Ignite system itself (INTERNAL CALL).
It seems that the easiest way to achieve this is to completely separate the
public and private Compute APIs.
Task executioin requests received through Ignite Thin Clients are considered
PUBLIC CALLs.
The first two steps give us the ability to
A. safely skip author
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
https://issues.apache.org/jira/browse/IGNITE-15322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-15322:
Description:
For example, this code needs TASK_EXECUTE permissions.
{code:java}
Affinity affinity = ignite.affinity("TEST");
affinity.mapKeysToNodes(Arrays.asList(1L,100L, 1000L));{code}
This is unexpected behavior, because:
- the task started implicitly (under the hood), customer should not to know
about it.
- this is a system task (not defined by a customer), the tasks needs for a
normal grid workflow.
Also, I suppose there are any other implicitly tasks, which could lead to
unexpected behavior (need permissions).
Proposed way to solve this issue:
1. Add mechanism to destinguish whether task class is SYSTEM (part of the
Ignite codebase) or USER.
Here we can reuse SecurityUtils#isSystemType mechanism that is used in Ignite
Sanbox implementation.
2. Add mechanism to detect if task execution was initiated by the user (PUBLIC
CALL) or by the Ignite system itself (INTERNAL CALL).
It seems that the easiest way to achieve this is to completely separate the
public and private Compute APIs.
Task executioin requests received through Ignite Thin Clients are considered
PUBLIC CALLs.
The first two steps give us the ability to
A. safely skip authorization of SYSTEM tasks which are
called through INTERNAL API unless permissions are specified explicitly (see
clause 3).
B. keep authorization of PUBLIC tasks intact
C. prevent users of calling SYSTEM tasks directly through PUBLIC API ( it means
that all user task execution requests received through REST or Thin client
protocols MUST be executed through PUBLIC API).
3. Add the ability to explicitly specify for SYSTEM
task/callable/runnable/closure what permission should be checked before its
execution. This helps to skip sending task execution requests between nodes if
the user does not have permission to execute the task.
It can be solved by introducing optionsl interface that compute job can
implement.
{code:java}
/** */
public interface SecurityAwareJob {
/** */
public SecurityPermissionSet requiredPermissions();
}
{code}
4. SYSTEM tasks can splitted into two categories -
SYSTEM INTERNAL (tasks that are not available to the user) and SYSTEM PUBLIC
tasks (tasks that are part oof the ignite code but are available to the user
and can be executed through the PUBLIC API)
Examples of SYSTEM public tasks -
- Visor tasks on which the user control script is implemented
- JDBC tasks
All of them are executed through Thin Client which is considered Public API.
Considering that SYSTEM PUBLIC tasks can potentially be executed by the user,
we must force the developer to explicitly specify permissions for tasks of this
type. It can be done by checking that SYSTEM tasks that are executed through
PUBLIC API impelements SecurityPermissionAware interface described above.
||X||Public API||Private API||
|PUBLIC task|auth by task name|restricted|
|SYSTEM INTERNAL task|restricted|auth skipped|
|SYSTEM PUBLIC task|auth by explicitly specified permissions|auth by explicitly
specified permissions|
5. Authorization of SYSTEM tasks cancellation must be skipped it they are
canceled by the same user who started them, oterwise dedicated permissions is
required (e.g. ADMIN_KILL). USER tasks cancellation is performed by their names.
Possible troubles:
1. Mentioned SecurityUtils#isSystemType works only for the ignite-core module.
If some tasks are defined inside other Ignite modules - they will not be
considered SYSTEM. Currently there are no such task.
2. Currently all DotNet tasks are authorized by the name of the SYSTEM wrapper
task. We should decide how to properly fix their authorization.
3. We must decide what permissions are required for Visor tasks.
was:
For example, this code needs TASK_EXECUTE permissions.
{code:java}
Affinity affinity = ignite.affinity("TEST");
affinity.mapKeysToNodes(Arrays.asList(1L,100L, 1000L));{code}
This is unexpected behavior, because:
- the task started implicitly (under the hood), customer should not to know
about it.
- this is a system task (not defined by a customer), the tasks needs for a
normal grid workflow.
Also, I suppose there are any other implicitly tasks, which could lead to
unexpected behavior (need permissions).
Proposed way to solve this issue:
1. Add mechanism to destinguish whether task class is SYSTEM (part of the
Ignite codebase) or USER.
Here we can reuse SecurityUtils#isSystemType mechanism that is used in Ignite
Sanbox implementation.
2. Add mechanism to detect if task execution was initiated by the user (PUBLIC
CALL) or by the Ignite system itself (INTERNAL CALL).
It seems that the easiest way to achieve this is to completely separate the
public and private Compute APIs.
Task executioin requests received through Ignite Thin Clients are considered
PUBLIC CALLs.
For I
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
https://issues.apache.org/jira/browse/IGNITE-15322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-15322:
Description:
For example, this code needs TASK_EXECUTE permissions.
{code:java}
Affinity affinity = ignite.affinity("TEST");
affinity.mapKeysToNodes(Arrays.asList(1L,100L, 1000L));{code}
This is unexpected behavior, because:
- the task started implicitly (under the hood), customer should not to know
about it.
- this is a system task (not defined by a customer), the tasks needs for a
normal grid workflow.
Also, I suppose there are any other implicitly tasks, which could lead to
unexpected behavior (need permissions).
Proposed way to solve this issue:
1. Add mechanism to destinguish whether task class is SYSTEM (part of the
Ignite codebase) or USER.
Here we can reuse SecurityUtils#isSystemType mechanism that is used in Ignite
Sanbox implementation.
2. Add mechanism to detect if task execution was initiated by the user (PUBLIC
CALL) or by the Ignite system itself (INTERNAL CALL).
It seems that the easiest way to achieve this is to completely separate the
public and private Compute APIs.
Task executioin requests received through Ignite Thin Clients are considered
PUBLIC CALLs.
For Ignite node API we can provide dedicated methods to obtain internal version
of compute instances in IgniteEx and force developers to use them for any
internal means.
{code:java}
public interface IgniteEx extends Ignite {
/** */
public IgniteCompute internalCompute();
/** */
public IgniteCompute internalCompute(ClusterGroup grp);
}
{code}
The first two steps give us the ability to
A. safely skip authorization of SYSTEM tasks which are
called through INTERNAL API unless permissions are specified explicitly (see
clause 3).
B. keep authorization of PUBLIC tasks intact
C. prevent users of calling SYSTEM tasks directly through PUBLIC API ( it means
that all user task execution requests received through REST or Thin client
protocols MUST be executed through PUBLIC API).
3. Add the ability to explicitly specify for SYSTEM
task/callable/runnable/closure what permission should be checked before its
execution. This helps to skip sending task execution requests between nodes if
the user does not have permission to execute the task.
It can be solved by introducing optionsl interface that compute job can
implement.
{code:java}
/** */
public interface SecurityAwareJob {
/** */
public SecurityPermissionSet requiredPermissions();
}
{code}
4. SYSTEM tasks can splitted into two categories -
SYSTEM INTERNAL (tasks that are not available to the user) and SYSTEM PUBLIC
tasks (tasks that are part oof the ignite code but are available to the user
and can be executed through the PUBLIC API)
Examples of SYSTEM public tasks -
- Visor tasks on which the user control script is implemented
- JDBC tasks
All of them are executed through Thin Client which is considered Public API.
Considering that SYSTEM PUBLIC tasks can potentially be executed by the user,
we must force the developer to explicitly specify permissions for tasks of this
type. It can be done by checking that SYSTEM tasks that are executed through
PUBLIC API impelements SecurityPermissionAware interface described above.
||X||Public API||Private API||
|PUBLIC task|auth by task name|restricted|
|SYSTEM INTERNAL task|restricted|auth skipped|
|SYSTEM PUBLIC task|auth by explicitly specified permissions|auth by explicitly
specified permissions|
5. Authorization of SYSTEM tasks cancellation must be skipped it they are
canceled by the same user who started them, oterwise dedicated permissions is
required (e.g. ADMIN_KILL). USER tasks cancellation is performed by their names.
Possible troubles:
1. Mentioned SecurityUtils#isSystemType works only for the ignite-core module.
If some tasks are defined inside other Ignite modules - they will not be
considered SYSTEM. Currently there are no such task.
2. Currently all DotNet tasks are authorized by the name of the SYSTEM wrapper
task. We should decide how to properly fix their authorization.
3. We must decide what permissions are required for Visor tasks.
was:
For example, this code needs TASK_EXECUTE permissions.
{code:java}
Affinity affinity = ignite.affinity("TEST");
affinity.mapKeysToNodes(Arrays.asList(1L,100L, 1000L));{code}
This is unexpected behavior, because:
- the task started implicitly (under the hood), customer should not to know
about it.
- this is a system task (not defined by a customer), the tasks needs for a
normal grid workflow.
Also, I suppose there are any other implicitly tasks, which could lead to
unexpected behavior (need permissions).
Possible way to solve this issue:
1. Add mechanism to destinguish whether task class is SYSTEM (part of the
Ignite codebase) or USER.
Here we can reuse SecurityUtils#isSystemType mechanism that is used in Ignite
Sanbo
[jira] [Created] (IGNITE-18791) Add SSL client authenticaiton support to REST
Aleksandr created IGNITE-18791: -- Summary: Add SSL client authenticaiton support to REST Key: IGNITE-18791 URL: https://issues.apache.org/jira/browse/IGNITE-18791 Project: Ignite Issue Type: Task Components: rest Reporter: Aleksandr Ignite TCP client supports the ssl client authentication. The REST interface should support it as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18791) Add SSL client authenticaiton support to REST
[ https://issues.apache.org/jira/browse/IGNITE-18791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-18791: -- Assignee: Aleksandr > Add SSL client authenticaiton support to REST > - > > Key: IGNITE-18791 > URL: https://issues.apache.org/jira/browse/IGNITE-18791 > Project: Ignite > Issue Type: Task > Components: rest >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > Ignite TCP client supports the ssl client authentication. The REST interface > should support it as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18790) Add SSL support for the Ignite JDBC driver
[ https://issues.apache.org/jira/browse/IGNITE-18790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-18790: --- Epic Link: IGNITE-18575 > Add SSL support for the Ignite JDBC driver > -- > > Key: IGNITE-18790 > URL: https://issues.apache.org/jira/browse/IGNITE-18790 > Project: Ignite > Issue Type: Task > Components: jdbc >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > This ticket should be based on the changes from IGNITE-18578. > Add JDBC-level properties for SSL support. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18790) Add SSL support for the Ignite JDBC driver
Aleksandr created IGNITE-18790: -- Summary: Add SSL support for the Ignite JDBC driver Key: IGNITE-18790 URL: https://issues.apache.org/jira/browse/IGNITE-18790 Project: Ignite Issue Type: Task Components: jdbc Reporter: Aleksandr This ticket should be based on the changes from IGNITE-18578. Add JDBC-level properties for SSL support. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18790) Add SSL support for the Ignite JDBC driver
[ https://issues.apache.org/jira/browse/IGNITE-18790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-18790: -- Assignee: Aleksandr > Add SSL support for the Ignite JDBC driver > -- > > Key: IGNITE-18790 > URL: https://issues.apache.org/jira/browse/IGNITE-18790 > Project: Ignite > Issue Type: Task > Components: jdbc >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > This ticket should be based on the changes from IGNITE-18578. > Add JDBC-level properties for SSL support. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18789) Sql. The sign of the default values for precision and scale is not kept
[
https://issues.apache.org/jira/browse/IGNITE-18789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18789:
---
Description:
SQL standard says:
{code:java}
If or is not specified explicitly, then the corresponding
element of the descriptor effectively contains the null value.{code}
But we keep our default values. That led to at least a few issues:
1) metadata will return incorrect information. For example type DECIMAL will be
returned as DECIMAL(32767, 0)
2) The same issue will be for TYPEOF function for DECIMAL column will be
returned DECIMAL(32767, 0)
To fix the issue we should amend restrictions for configurations that are
currently are not allowed to keep negative values and keep as special values
sign default precision and/or scale, or do the properties like a nullable.
was:
SQL standard says:
If or is not specified explicitly, then the corresponding
element of the descriptor effectively contains the null value.
But we keep our default values. That led to at least a few issues:
1) metadata will return incorrect information. For example type DECIMAL will be
returned as DECIMAL(32767, 0)
2) The same issue will be for TYPEOF function for DECIMAL column will be
returned DECIMAL(32767, 0)
To fix the issue we should amend restrictions for configurations that are
currently are not allowed to keep negative values and keep as special values
sign default precision and/or scale, or do the properties like a nullable.
> Sql. The sign of the default values for precision and scale is not kept
> ---
>
> Key: IGNITE-18789
> URL: https://issues.apache.org/jira/browse/IGNITE-18789
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
>
> SQL standard says:
> {code:java}
> If or is not specified explicitly, then the corresponding
> element of the descriptor effectively contains the null value.{code}
> But we keep our default values. That led to at least a few issues:
> 1) metadata will return incorrect information. For example type DECIMAL will
> be returned as DECIMAL(32767, 0)
> 2) The same issue will be for TYPEOF function for DECIMAL column will be
> returned DECIMAL(32767, 0)
> To fix the issue we should amend restrictions for configurations that are
> currently are not allowed to keep negative values and keep as special values
> sign default precision and/or scale, or do the properties like a nullable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18789) Sql. The sign of the default values for precision and scale is not kept
Yury Gerzhedovich created IGNITE-18789: -- Summary: Sql. The sign of the default values for precision and scale is not kept Key: IGNITE-18789 URL: https://issues.apache.org/jira/browse/IGNITE-18789 Project: Ignite Issue Type: Improvement Components: sql Reporter: Yury Gerzhedovich SQL standard says: If or is not specified explicitly, then the corresponding element of the descriptor effectively contains the null value. But we keep our default values. That led to at least a few issues: 1) metadata will return incorrect information. For example type DECIMAL will be returned as DECIMAL(32767, 0) 2) The same issue will be for TYPEOF function for DECIMAL column will be returned DECIMAL(32767, 0) To fix the issue we should amend restrictions for configurations that are currently are not allowed to keep negative values and keep as special values sign default precision and/or scale, or do the properties like a nullable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
