[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: - Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > 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 > > -- 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: - Fix Version/s: python-0.6.1 > 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 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18788) Query listener in python thin client fire events only if a debug logging level enabled
Ivan Daschinsky created IGNITE-18788: Summary: 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 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18787) Sql. TPC-H query#22:
Maksim Zhuravkov created IGNITE-18787:
-
Summary: Sql. TPC-H query#22:
Key: IGNITE-18787
URL: https://issues.apache.org/jira/browse/IGNITE-18787
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Maksim Zhuravkov
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.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.Selec
[jira] [Updated] (IGNITE-18787) Sql. TPC-H query#22:
[
https://issues.apache.org/jira/browse/IGNITE-18787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18787:
--
Labels: calcite2-required calcite3-required ignite-3 (was: )
> Sql. TPC-H query#22:
> -
>
> 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.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:1078)
> at
> org.apache.calcite.sq
[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:
--
Summary: Sql. TPC-H query#6: Failed to parse query: BETWEEN operator has no
terminating AND (was: Sql. Tpc-H query#6: Failed to parse query: BETWEEN
operator has no terminating AND)
> Sql. TPC-H query#6: Failed to parse query: BETWEEN operator has no
> terminating AND
> --
>
> Key: IGNITE-18786
> URL: https://issues.apache.org/jira/browse/IGNITE-18786
> 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
>
>
> Sql parser is unable to parse TPC-H query#6:
> {code:java}
> SELECT sum(l_extendedprice * l_discount) AS revenue
> FROM
> lineitem
> WHERE
> l_shipdate >= DATE '1994-01-01'
> AND l_shipdate < DATE '1994-01-01' + INTERVAL '1' YEAR
> AND l_discount BETWEEN decimal '0.06' - decimal '0.01' AND decimal '0.06' +
> decimal '0.01'
> AND l_quantity < 24
> {code}
> 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.platf
[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:
--
Summary: Sql. Tpc-H query#6: Failed to parse query: BETWEEN operator has no
terminating AND (was: Sql. Tpc-H q6: Failed to parse query: BETWEEN operator
has no terminating AND)
> Sql. Tpc-H query#6: Failed to parse query: BETWEEN operator has no
> terminating AND
> --
>
> Key: IGNITE-18786
> URL: https://issues.apache.org/jira/browse/IGNITE-18786
> 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
>
>
> Sql parser is unable to parse TPC-H query#6:
> {code:java}
> SELECT sum(l_extendedprice * l_discount) AS revenue
> FROM
> lineitem
> WHERE
> l_shipdate >= DATE '1994-01-01'
> AND l_shipdate < DATE '1994-01-01' + INTERVAL '1' YEAR
> AND l_discount BETWEEN decimal '0.06' - decimal '0.01' AND decimal '0.06' +
> decimal '0.01'
> AND l_quantity < 24
> {code}
> 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.e
[jira] [Created] (IGNITE-18786) Sql. Tpc-H q6: Failed to parse query: BETWEEN operator has no terminating AND
Maksim Zhuravkov created IGNITE-18786:
-
Summary: Sql. Tpc-H q6: Failed to parse query: BETWEEN operator
has no terminating AND
Key: IGNITE-18786
URL: https://issues.apache.org/jira/browse/IGNITE-18786
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Maksim Zhuravkov
Fix For: 3.0.0-beta2
Sql parser is unable to parse TPC-H query#6:
{code:java}
SELECT sum(l_extendedprice * l_discount) AS revenue
FROM
lineitem
WHERE
l_shipdate >= DATE '1994-01-01'
AND l_shipdate < DATE '1994-01-01' + INTERVAL '1' YEAR
AND l_discount BETWEEN decimal '0.06' - decimal '0.01' AND decimal '0.06' +
decimal '0.01'
AND l_quantity < 24
{code}
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.descr
[jira] [Assigned] (IGNITE-18756) Awaiting for nodes are appeared in distribution zone data nodes.
[ https://issues.apache.org/jira/browse/IGNITE-18756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel reassigned IGNITE-18756: -- Assignee: Sergey Uttsel > Awaiting for nodes are appeared in distribution zone data nodes. > > > Key: IGNITE-18756 > URL: https://issues.apache.org/jira/browse/IGNITE-18756 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3 > > h3. Motivation > Awaiting for nodes are appeared in distribution zone data nodes. > Now when nodes were started and joined to physical topology it's enough to > create table with assignments on these nodes. When we get rid of > BaselineManager#nodes then the data nodes of the distribution zone will be > used to create assignments for partitions. > In order for the nodes from the physical topology are in the assignments when > table is creating, it's need to wait until these nodes are added to the data > nodes of the distribution zone. > h3. Definition of Done > At the time of table creating data nodes from the physical topology must also > be in the data nodes of the distribution zone. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18785) Sql. Appending a NULL value in binary tuple builder with disabled NULLs
[
https://issues.apache.org/jira/browse/IGNITE-18785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-18785:
--
Description:
This error occurs in sql logic tests:
{code:java}
(test_big_insert.test:28). Statement: INSERT INTO integers VALUES (DEFAULT, 4);
{code}
{code:java}
(left_join_issue_1172.test:77). Statement: insert into t1 (id) values (1), (1),
(DEFAULT);
{code}
{code:java}
Not expected result at: (test_big_insert.test:28). Statement: INSERT INTO
integers VALUES (DEFAULT, 4);
org.opentest4j.AssertionFailedError: Not expected result at:
(test_big_insert.test:28). Statement: INSERT INTO integers VALUES (DEFAULT, 4);
at
app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at
app//org.apache.ignite.internal.sqllogic.Statement.execute(Statement.java:110)
at
app//org.apache.ignite.internal.sqllogic.SqlScriptRunner.run(SqlScriptRunner.java:70)
at
app//org.junit.jupiter.api.AssertTimeout.lambda$assertTimeoutPreemptively$2(AssertTimeout.java:102)
at
app//org.junit.jupiter.api.AssertTimeout.lambda$assertTimeoutPreemptively$4(AssertTimeout.java:138)
at
java.base@11.0.14.1/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base@11.0.14.1/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base@11.0.14.1/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base@11.0.14.1/java.lang.Thread.run(Thread.java:829)
Caused by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:6cd6e1a2-7872-4451-8230-73ce17c8ff34 IGN-CMN-65535
TraceId:6cd6e1a2-7872-4451-8230-73ce17c8ff34 Appending a NULL value in binary
tuple builder with disabled NULLs
at
jdk.internal.reflect.GeneratedConstructorAccessor26.newInstance(Unknown Source)
at
java.base@11.0.14.1/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
java.base@11.0.14.1/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at
app//org.apache.ignite.lang.IgniteException.wrap(IgniteException.java:277)
at app//org.apache.ignite.sql.Session.execute(Session.java:60)
at
app//org.apache.ignite.internal.sqllogic.ScriptContext.executeQuery(ScriptContext.java:89)
at
app//org.apache.ignite.internal.sqllogic.Statement.execute(Statement.java:108)
... 7 more
Caused by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:6cd6e1a2-7872-4451-8230-73ce17c8ff34 Appending a NULL value in binary
tuple builder with disabled NULLs
at
app//org.apache.ignite.lang.IgniteException.wrap(IgniteException.java:289)
at
app//org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$0(AsyncSqlCursorImpl.java:77)
at
java.base@11.0.14.1/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at
java.base@11.0.14.1/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
at
java.base@11.0.14.1/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base@11.0.14.1/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
app//org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.lambda$closeAsync$0(AsyncRootNode.java:157)
at
java.base@11.0.14.1/java.util.concurrent.ConcurrentLinkedQueue.forEachFrom(ConcurrentLinkedQueue.java:1037)
at
java.base@11.0.14.1/java.util.concurrent.ConcurrentLinkedQueue.forEach(ConcurrentLinkedQueue.java:1054)
at
app//org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.closeAsync(AsyncRootNode.java:157)
at
app//org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.onError(AsyncRootNode.java:112)
at
app//org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:140)
at
app//org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:140)
at
app//org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:140)
at
app//org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:307)
at
app//org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:80)
... 3 more
Caused by: java.lang.IllegalStateException: Appending a NULL value in binary
tuple builder with disabled NULLs
at
org.apache.ignite.internal.binarytuple.BinaryTupleBuilder.appendNull(BinaryTupleBuilder.java:123)
at
org.apache.ignite.internal.schema.row.RowAssembler.appendNull(RowAssembler.java:264)
at
org.apac
[jira] [Created] (IGNITE-18785) Sql. Appending a NULL value in binary tuple builder with disabled NULLs
Maksim Zhuravkov created IGNITE-18785:
-
Summary: Sql. Appending a NULL value in binary tuple builder with
disabled NULLs
Key: IGNITE-18785
URL: https://issues.apache.org/jira/browse/IGNITE-18785
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Maksim Zhuravkov
Fix For: 3.0.0-beta2
This error occurs in sql logic tests:
{code:java}
(test_big_insert.test:28). Statement: INSERT INTO integers VALUES (DEFAULT, 4);
{code}
{code:java}
Not expected result at: (left_join_issue_1172.test:77). Statement: insert into
t1 (id) values (1), (1), (DEFAULT);
{code}
{code:java}
Not expected result at: (test_big_insert.test:28). Statement: INSERT INTO
integers VALUES (DEFAULT, 4);
org.opentest4j.AssertionFailedError: Not expected result at:
(test_big_insert.test:28). Statement: INSERT INTO integers VALUES (DEFAULT, 4);
at
app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at
app//org.apache.ignite.internal.sqllogic.Statement.execute(Statement.java:110)
at
app//org.apache.ignite.internal.sqllogic.SqlScriptRunner.run(SqlScriptRunner.java:70)
at
app//org.junit.jupiter.api.AssertTimeout.lambda$assertTimeoutPreemptively$2(AssertTimeout.java:102)
at
app//org.junit.jupiter.api.AssertTimeout.lambda$assertTimeoutPreemptively$4(AssertTimeout.java:138)
at
java.base@11.0.14.1/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base@11.0.14.1/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base@11.0.14.1/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base@11.0.14.1/java.lang.Thread.run(Thread.java:829)
Caused by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:6cd6e1a2-7872-4451-8230-73ce17c8ff34 IGN-CMN-65535
TraceId:6cd6e1a2-7872-4451-8230-73ce17c8ff34 Appending a NULL value in binary
tuple builder with disabled NULLs
at
jdk.internal.reflect.GeneratedConstructorAccessor26.newInstance(Unknown Source)
at
java.base@11.0.14.1/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
java.base@11.0.14.1/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at
app//org.apache.ignite.lang.IgniteException.wrap(IgniteException.java:277)
at app//org.apache.ignite.sql.Session.execute(Session.java:60)
at
app//org.apache.ignite.internal.sqllogic.ScriptContext.executeQuery(ScriptContext.java:89)
at
app//org.apache.ignite.internal.sqllogic.Statement.execute(Statement.java:108)
... 7 more
Caused by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:6cd6e1a2-7872-4451-8230-73ce17c8ff34 Appending a NULL value in binary
tuple builder with disabled NULLs
at
app//org.apache.ignite.lang.IgniteException.wrap(IgniteException.java:289)
at
app//org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$0(AsyncSqlCursorImpl.java:77)
at
java.base@11.0.14.1/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at
java.base@11.0.14.1/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
at
java.base@11.0.14.1/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base@11.0.14.1/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
app//org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.lambda$closeAsync$0(AsyncRootNode.java:157)
at
java.base@11.0.14.1/java.util.concurrent.ConcurrentLinkedQueue.forEachFrom(ConcurrentLinkedQueue.java:1037)
at
java.base@11.0.14.1/java.util.concurrent.ConcurrentLinkedQueue.forEach(ConcurrentLinkedQueue.java:1054)
at
app//org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.closeAsync(AsyncRootNode.java:157)
at
app//org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.onError(AsyncRootNode.java:112)
at
app//org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:140)
at
app//org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:140)
at
app//org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:140)
at
app//org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:307)
at
app//org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:80)
... 3 more
Caused by: java.lang.IllegalStateException: Appending a NULL value in binary
tuple builder with disa
[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=17688094#comment-17688094 ] Igor Sapego commented on IGNITE-18773: -- [~ptupitsyn] looks good. > .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] [Commented] (IGNITE-18719) [IEP-80] Deprecate lazy flag of SqlFieldsQuery
[
https://issues.apache.org/jira/browse/IGNITE-18719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17688031#comment-17688031
]
Ignite TC Bot commented on IGNITE-18719:
{panel:title=Branch: [pull/10518/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10518/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7045079&buildTypeId=IgniteTests24Java8_RunAll]
> [IEP-80] Deprecate lazy flag of SqlFieldsQuery
> --
>
> Key: IGNITE-18719
> URL: https://issues.apache.org/jira/browse/IGNITE-18719
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-80, ise
> Fix For: 2.15
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Lazy flag has known issues leading to cluster stability.
> {{lazy=false}} can be implemented with certain page size like
> {{pageSize==Long.MAX_VALUE.}}
> To improve stability of the default deployments we must
> * deprecate lazy flag in 2.15
> * make queries lazy by default.
> * remove lazy flag in 2.16
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18784) Repair disable test on Windows with reason IGNITE-17601
Mikhail Pochatkin created IGNITE-18784: -- Summary: Repair disable test on Windows with reason IGNITE-17601 Key: IGNITE-18784 URL: https://issues.apache.org/jira/browse/IGNITE-18784 Project: Ignite Issue Type: Improvement Reporter: Mikhail Pochatkin These tests are disable with reason IGNITE-17601: * org.apache.ignite.raft.jraft.core.ItNodeTest#testSetPeer2 * org.apache.ignite.internal.cluster.management.raft.RocksDbClusterStateStorageManagerTest * org.apache.ignite.internal.sql.engine.exec.rel.ExecutionTest * org.apache.ignite.internal.sql.engine.planner.PlannerTest Need to repair it and enable on Windows -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17601) Fix flaky tests and Windows incompatibility in tests
[ https://issues.apache.org/jira/browse/IGNITE-17601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17688013#comment-17688013 ] Mikhail Pochatkin commented on IGNITE-17601: So, lets finish with IGNITE-18784 and close this epic > Fix flaky tests and Windows incompatibility in tests > > > Key: IGNITE-17601 > URL: https://issues.apache.org/jira/browse/IGNITE-17601 > Project: Ignite > Issue Type: Epic >Reporter: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17601) Fix flaky tests and Windows incompatibility in tests
[ https://issues.apache.org/jira/browse/IGNITE-17601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17688012#comment-17688012 ] Mikhail Pochatkin commented on IGNITE-17601: Oh, I see. Let me create a ticket to fix these disabled tests > Fix flaky tests and Windows incompatibility in tests > > > Key: IGNITE-17601 > URL: https://issues.apache.org/jira/browse/IGNITE-17601 > Project: Ignite > Issue Type: Epic >Reporter: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (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:all-tabpanel ] Maksim Timonin updated IGNITE-18783: Fix Version/s: 2.15 > 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 > > > 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-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:all-tabpanel ] Maksim Timonin updated IGNITE-18783: Ignite Flags: (was: Docs Required,Release Notes Required) > 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 > > > 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] [Created] (IGNITE-18783) DistributedProcess hangs if a single future completes with AssertionError
Maksim Timonin created IGNITE-18783: --- Summary: 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 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] [Commented] (IGNITE-17601) Fix flaky tests and Windows incompatibility in tests
[ https://issues.apache.org/jira/browse/IGNITE-17601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17687999#comment-17687999 ] Evgeny Stanilovsky commented on IGNITE-17601: - we can`t do it before all mentions of this issue are removed from code. > Fix flaky tests and Windows incompatibility in tests > > > Key: IGNITE-17601 > URL: https://issues.apache.org/jira/browse/IGNITE-17601 > Project: Ignite > Issue Type: Epic >Reporter: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18640) Implement placement driver best-effort single actor selector and fail-over
[
https://issues.apache.org/jira/browse/IGNITE-18640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-18640:
-
Description:
h3. Motivation
As a prerequisite, it's worth to mention that placement drive itself should be
reliable and have corresponding fail-over logic, meaning that placement driver
service should be distributed in a way that if one of its nodes fails another
one picks up the flag. On the other hand, despite the fact, that it's valid to
have more than one PD active actors (the one that will check topology, send
leaseGrant msg, etc) it's better to have one only in order to reduce the amount
of unnecessary calculations, messaging duplication and so on. So, to sum up:
* PD may work on top of meta storage, using it as a consensus provider.
* There may be more than one active PD actors, that try to evaluate primary
replica along with corresponding lease, send leaseGrant msg, etc, meaning that
actions should be idempotent or that we should have an ability to skip
stale/concurrent triggers.
* It worth to have at least best-effort single actor selection logic.
h3. Definition of Done
* Almost always (because of best-effort nature, it's not always) there's only
one PD active actor if there's a majority in ms group.
* If for some reason active actor fails, another one will picks up the flag as
fast as possible.
* It's still valid to have multiple active actors at the same time. If you
guys have any ideas of how to implement not more than one actor, please share
them.
h3. Implementation Notes
Assuming that we have a distributed onLeaderElected(Peer leader, long term)
callback we may implement following logic on PlacementDriverManager#start()
* register ms.onLeaderElected()
{code:java}
ms.onLeaderElected((leader, term) -> {
if (term > lastSeenTerm) {
if (leader.equlas(localNode)) {
// Become an active actor.
} else {
// Discard activeness.
}
} else {
// No-op, just a stale update.
}
});{code}
* refreshLeader and to exact the same logic as the one mentioned above in
order to become and active actor if there already was a leader during listener
registration.
was:
h3. Motivation
As a prerequisite, it's worth to mention that placement drive itself should be
reliable and have corresponding fail-over logic, meaning that placement driver
service should be distributed in a way that if one of its nodes fails another
one picks up the flag. On the other hand, despite the fact, that it's valid to
have more than one PD active actors (the one that will check topology, send
leaseGrant msg, etc) it's better to have one only in order to reduce the amount
of unnecessary calculations, messaging duplication and so on. So, to sum up:
* PD may work on top of meta storage, using it as a consensus provider.
* There may be more than one active PD actors, that try to evaluate primary
replica along with corresponding lease, send leaseGrant msg, etc, meaning that
actions should be idempotent or that we should have an ability to skip
stale/concurrent triggers.
* It worth to have at least best-effort single actor selection logic.
h3. Definition of Done
* Almost always (because of best-effort nature, it's not always) there's only
one PD active actor if there's a majority in ms group.
* If for some reason active actor fails, another one will picks up the flag as
fast as possible.
* It's still valid to have multiple active actors at the same time. If you
guys have any ideas of how to implement not more than one actor, please share
them.
h3. Implementation Notes
Assuming that we have a distributed onLeaderElected(Peer leader, long term)
[callback|https://issues.apache.org/jira/browse/IGNITE-18639] we may implement
following logic on PlacementDriverManager#start()
# register ms.onLeaderElected()
{code:java}
ms.onLeaderElected((leader, term) -> {
if (term > lastSeenTerm) {
if (leader.equlas(localNode)) {
// Become an active actor.
} else {
// Discard activeness.
}
} else {
// No-op, just a stale update.
}
});{code}
# refreshLeader and to exact the same logic as the one mentioned above in
order to become and active actor if there already was a leader during listener
registration.
> Implement placement driver best-effort single actor selector and fail-over
> --
>
> Key: IGNITE-18640
> URL: https://issues.apache.org/jira/browse/IGNITE-18640
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
>
[jira] [Commented] (IGNITE-17601) Fix flaky tests and Windows incompatibility in tests
[ https://issues.apache.org/jira/browse/IGNITE-17601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17687965#comment-17687965 ] Mikhail Pochatkin commented on IGNITE-17601: [~zstan] I think that this epic can be closed, all linked tasks are closed. > Fix flaky tests and Windows incompatibility in tests > > > Key: IGNITE-17601 > URL: https://issues.apache.org/jira/browse/IGNITE-17601 > Project: Ignite > Issue Type: Epic >Reporter: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18308) RestAddressReporterTest fails on Windows
[
https://issues.apache.org/jira/browse/IGNITE-18308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Pochatkin updated IGNITE-18308:
---
Epic Link: IGNITE-17601
> RestAddressReporterTest fails on Windows
>
>
> Key: IGNITE-18308
> URL: https://issues.apache.org/jira/browse/IGNITE-18308
> Project: Ignite
> Issue Type: Bug
> Components: cli, rest
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> IGNITE-17754 introduced the test but it fails on Windows:
> {code:java}
> java.nio.file.InvalidPathException: Illegal char <:> at index 4:
> file:///C:/Users/Vadim/AppData/Local/Temp/junit16215531435219780615//nosuchpath
> at
> java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
> at
> java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
> at
> java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
> at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
> at
> java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:229)
> at java.base/java.nio.file.Path.of(Path.java:147)
> at
> org.apache.ignite.internal.component.RestAddressReporterTest.throwsExceptionWhenThereIsNoFile(RestAddressReporterTest.java:75)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18530) Integration test failures on Windows
[ https://issues.apache.org/jira/browse/IGNITE-18530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin updated IGNITE-18530: --- Epic Link: IGNITE-17601 > Integration test failures on Windows > > > Key: IGNITE-18530 > URL: https://issues.apache.org/jira/browse/IGNITE-18530 > Project: Ignite > Issue Type: Bug >Reporter: Vadim Pakhnushev >Assignee: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > Some of the runner integration tests fail on Windows due to the hardcoded > "\n" conversion when parsing the SQL query results. The tests are > ItProjectScanMergeRuleTest, ItJoinTest and ItAggregatesTest. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18236) Cache objects transformation
[
https://issues.apache.org/jira/browse/IGNITE-18236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17687946#comment-17687946
]
Ignite TC Bot commented on IGNITE-18236:
{panel:title=Branch: [pull/10393/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10393/head] Base: [master] : New Tests
(42)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Index Query API{color} [[tests
8|https://ci2.ignite.apache.org/viewLog.html?buildId=7043354]]
* {color:#013220}IndexQueryTestSuite:
IndexQueryCacheKeyValueTransformedFieldsTest.testValueAliasUpperField -
PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryCacheKeyValueTransformedFieldsTest.testValueAliasField - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryCacheKeyValueTransformedFieldsTest.testValueLowerField - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryCacheKeyValueTransformedFieldsTest.testKeyAliasField - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryCacheKeyValueTransformedFieldsTest.testValueField - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryCacheKeyValueTransformedFieldsTest.testKeyLowerField - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryCacheKeyValueTransformedFieldsTest.testKeyField - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryCacheKeyValueTransformedFieldsTest.testKeyAliasUpperField -
PASSED{color}
{color:#8b}Cache 13{color} [[tests
12|https://ci2.ignite.apache.org/viewLog.html?buildId=7043316]]
* {color:#013220}IgniteCacheTestSuite13:
CacheObjectsTransformationTest.testTransformable[mode=ATOMIC] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
CacheObjectsTransformationTest.testUntransformable[mode=ATOMIC] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
CacheObjectsTransformationTest.testTransformable[mode=TRANSACTIONAL] -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
CacheObjectsTransformationTest.testUntransformable[mode=TRANSACTIONAL] -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
CacheObjectsTransformationEvolutionTest.testString[mode=TRANSACTIONAL] -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
CacheObjectsTransformationEvolutionTest.testObject[mode=TRANSACTIONAL] -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
CacheObjectsTransformationEvolutionTest.testBinaryObject[mode=TRANSACTIONAL] -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
CacheObjectsTransformationEvolutionTest.testInt[mode=TRANSACTIONAL] -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
CacheObjectsTransformationEvolutionTest.testString[mode=ATOMIC] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
CacheObjectsTransformationEvolutionTest.testObject[mode=ATOMIC] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
CacheObjectsTransformationEvolutionTest.testBinaryObject[mode=ATOMIC] -
PASSED{color}
... and 1 new tests
{color:#8b}Cache Objects Compression{color} [[tests
22|https://ci2.ignite.apache.org/viewLog.html?buildId=7043418]]
* {color:#013220}IgniteCompressionTestSuite:
CacheObjectsCompressionConsumptionTest.testWrappedStringBinaryArray[mode=THIN_CLIENT]
- PASSED{color}
* {color:#013220}IgniteCompressionTestSuite:
CacheObjectsCompressionConsumptionTest.testStringArray[mode=NODE] -
PASSED{color}
* {color:#013220}IgniteCompressionTestSuite:
CacheObjectsCompressionConsumptionTest.testString[mode=NODE] - PASSED{color}
* {color:#013220}IgniteCompressionTestSuite:
CacheObjectsCompressionConsumptionTest.testIncompressible[mode=NODE] -
PASSED{color}
* {color:#013220}IgniteCompressionTestSuite:
CacheObjectsCompressionConsumptionTest.testString[mode=THIN_CLIENT] -
PASSED{color}
* {color:#013220}IgniteCompressionTestSuite:
CacheObjectsCompressionConsumptionTest.testIncompressible[mode=THIN_CLIENT] -
PASSED{color}
* {color:#013220}IgniteCompressionTestSuite:
CacheObjectsCompressionConsumptionTest.testWrappedString[mode=THIN_CLIENT] -
PASSED{color}
* {color:#013220}IgniteCompressionTestSuite:
CacheObjectsCompressionConsumptionTest.testWrappedStringArray[mode=THIN_CLIENT]
- PASSED{color}
* {color:#013220}IgniteCompressionTestSuite:
CacheObjectsCompressionConsumptionTest.testWrappedString[mode=PERSISTENT] -
PASSED{color}
* {color:#013220}IgniteCompressionTestSuite:
CacheObjectsCompressionConsumptionTest.testWrappedStringArray[mode=PERSISTENT]
- PASSED{color}
* {color:#013220}IgniteCompressionTestSuite:
CacheObjectsCompressionConsumptionTest.testWrappedStringBinaryArray[mode=PERSISTENT]
- PASSED{color}
... and 11 new tests
{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7043419&buildTypeId=IgniteTests24Java8_RunAll]
> Cache objects transformation
>
>
> Ke
[jira] [Commented] (IGNITE-17601) Fix flaky tests and Windows incompatibility in tests
[ https://issues.apache.org/jira/browse/IGNITE-17601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17687920#comment-17687920 ] Evgeny Stanilovsky commented on IGNITE-17601: - [~Mikhail Pochatkin] what kind of problem you observed here ? > Fix flaky tests and Windows incompatibility in tests > > > Key: IGNITE-17601 > URL: https://issues.apache.org/jira/browse/IGNITE-17601 > Project: Ignite > Issue Type: Epic >Reporter: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-18750) .NET: Compute modificators are not reset properly after task execution.
[
https://issues.apache.org/jira/browse/IGNITE-18750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov resolved IGNITE-18750.
-
Resolution: Fixed
> .NET: Compute modificators are not reset properly after task execution.
> ---
>
> Key: IGNITE-18750
> URL: https://issues.apache.org/jira/browse/IGNITE-18750
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: .NET
> Fix For: 2.15
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Consider the followig exampte (It can be placed in ComputeApiTest to run it)
> {code:java}
> [Test]
> public void TestTaskOptionsPropagation()
> {
> ICompute compute = _grid1.GetCompute();
>
> compute.WithTimeout(500).Call(new ComputeFunc());
> compute.ExecuteJavaTask(ComputeClientTests.TestTask,
> (long)1000);
> }
> {code}
> Currently compute.ExecuteJavaTask call will fail with timeout exception even
> no "withTimeout" modifier was applied.
> It happens because during PlatformCompute#processInLongOutLong execution we
> apply task modifiers to both compute instances. As a result after
> `compute.WithTimeout(500).Call(new ComputeFunc());` execution
> `computeForPlatform` compute instance will reset its task modifiers and
> `compute`
> comput instance will not.
> So the next task execution after `compute.WithTimeout(500).Call(new
> ComputeFunc());` that uses `compute`instance will be executed with timout
> modifier applied even it was not applied by the user.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18750) .NET: Compute modificators are not reset properly after task execution.
[
https://issues.apache.org/jira/browse/IGNITE-18750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17687918#comment-17687918
]
Mikhail Petrov commented on IGNITE-18750:
-
[~namelchev] Thank you for the review.
> .NET: Compute modificators are not reset properly after task execution.
> ---
>
> Key: IGNITE-18750
> URL: https://issues.apache.org/jira/browse/IGNITE-18750
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: .NET
> Fix For: 2.15
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Consider the followig exampte (It can be placed in ComputeApiTest to run it)
> {code:java}
> [Test]
> public void TestTaskOptionsPropagation()
> {
> ICompute compute = _grid1.GetCompute();
>
> compute.WithTimeout(500).Call(new ComputeFunc());
> compute.ExecuteJavaTask(ComputeClientTests.TestTask,
> (long)1000);
> }
> {code}
> Currently compute.ExecuteJavaTask call will fail with timeout exception even
> no "withTimeout" modifier was applied.
> It happens because during PlatformCompute#processInLongOutLong execution we
> apply task modifiers to both compute instances. As a result after
> `compute.WithTimeout(500).Call(new ComputeFunc());` execution
> `computeForPlatform` compute instance will reset its task modifiers and
> `compute`
> comput instance will not.
> So the next task execution after `compute.WithTimeout(500).Call(new
> ComputeFunc());` that uses `compute`instance will be executed with timout
> modifier applied even it was not applied by the user.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18750) .NET: Compute modificators are not reset properly after task execution.
[
https://issues.apache.org/jira/browse/IGNITE-18750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-18750:
Ignite Flags: (was: Docs Required,Release Notes Required)
> .NET: Compute modificators are not reset properly after task execution.
> ---
>
> Key: IGNITE-18750
> URL: https://issues.apache.org/jira/browse/IGNITE-18750
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: .NET
> Fix For: 2.15
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Consider the followig exampte (It can be placed in ComputeApiTest to run it)
> {code:java}
> [Test]
> public void TestTaskOptionsPropagation()
> {
> ICompute compute = _grid1.GetCompute();
>
> compute.WithTimeout(500).Call(new ComputeFunc());
> compute.ExecuteJavaTask(ComputeClientTests.TestTask,
> (long)1000);
> }
> {code}
> Currently compute.ExecuteJavaTask call will fail with timeout exception even
> no "withTimeout" modifier was applied.
> It happens because during PlatformCompute#processInLongOutLong execution we
> apply task modifiers to both compute instances. As a result after
> `compute.WithTimeout(500).Call(new ComputeFunc());` execution
> `computeForPlatform` compute instance will reset its task modifiers and
> `compute`
> comput instance will not.
> So the next task execution after `compute.WithTimeout(500).Call(new
> ComputeFunc());` that uses `compute`instance will be executed with timout
> modifier applied even it was not applied by the user.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18750) .NET: Compute modificators are not reset properly after task execution.
[
https://issues.apache.org/jira/browse/IGNITE-18750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17687915#comment-17687915
]
Ignite TC Bot commented on IGNITE-18750:
{panel:title=Branch: [pull/10523/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10523/head] Base: [master] : New Tests
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Platform .NET (Core Linux){color} [[tests
2|https://ci2.ignite.apache.org/viewLog.html?buildId=7046653]]
* {color:#013220}DotNetCore:
ComputeApiTestFullFooter.TestTaskOptionsPropagation - PASSED{color}
* {color:#013220}DotNetCore: ComputeApiTest.TestTaskOptionsPropagation -
PASSED{color}
{color:#8b}Platform .NET (Windows){color} [[tests
2|https://ci2.ignite.apache.org/viewLog.html?buildId=7045795]]
* {color:#013220}exe: ComputeApiTestFullFooter.TestTaskOptionsPropagation -
PASSED{color}
* {color:#013220}exe: ComputeApiTest.TestTaskOptionsPropagation - PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7045829&buildTypeId=IgniteTests24Java8_RunAll]
> .NET: Compute modificators are not reset properly after task execution.
> ---
>
> Key: IGNITE-18750
> URL: https://issues.apache.org/jira/browse/IGNITE-18750
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: .NET
> Fix For: 2.15
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Consider the followig exampte (It can be placed in ComputeApiTest to run it)
> {code:java}
> [Test]
> public void TestTaskOptionsPropagation()
> {
> ICompute compute = _grid1.GetCompute();
>
> compute.WithTimeout(500).Call(new ComputeFunc());
> compute.ExecuteJavaTask(ComputeClientTests.TestTask,
> (long)1000);
> }
> {code}
> Currently compute.ExecuteJavaTask call will fail with timeout exception even
> no "withTimeout" modifier was applied.
> It happens because during PlatformCompute#processInLongOutLong execution we
> apply task modifiers to both compute instances. As a result after
> `compute.WithTimeout(500).Call(new ComputeFunc());` execution
> `computeForPlatform` compute instance will reset its task modifiers and
> `compute`
> comput instance will not.
> So the next task execution after `compute.WithTimeout(500).Call(new
> ComputeFunc());` that uses `compute`instance will be executed with timout
> modifier applied even it was not applied by the user.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18750) .NET: Compute modificators are not reset properly after task execution.
[
https://issues.apache.org/jira/browse/IGNITE-18750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17687914#comment-17687914
]
Ignite TC Bot commented on IGNITE-18750:
{panel:title=Branch: [pull/10523/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10523/head] Base: [master] : New Tests
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Platform .NET (Core Linux){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=7072492]]
* {color:#013220}DotNetCore: ComputeApiTest.TestTaskOptionsPropagation -
PASSED{color}
* {color:#013220}DotNetCore:
ComputeApiTestFullFooter.TestTaskOptionsPropagation - PASSED{color}
{color:#8b}Platform .NET (Windows){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=7072493]]
* {color:#013220}exe: ComputeApiTest.TestTaskOptionsPropagation - PASSED{color}
* {color:#013220}exe: ComputeApiTestFullFooter.TestTaskOptionsPropagation -
PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=7072527&buildTypeId=IgniteTests24Java8_RunAll]
> .NET: Compute modificators are not reset properly after task execution.
> ---
>
> Key: IGNITE-18750
> URL: https://issues.apache.org/jira/browse/IGNITE-18750
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: .NET
> Fix For: 2.15
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Consider the followig exampte (It can be placed in ComputeApiTest to run it)
> {code:java}
> [Test]
> public void TestTaskOptionsPropagation()
> {
> ICompute compute = _grid1.GetCompute();
>
> compute.WithTimeout(500).Call(new ComputeFunc());
> compute.ExecuteJavaTask(ComputeClientTests.TestTask,
> (long)1000);
> }
> {code}
> Currently compute.ExecuteJavaTask call will fail with timeout exception even
> no "withTimeout" modifier was applied.
> It happens because during PlatformCompute#processInLongOutLong execution we
> apply task modifiers to both compute instances. As a result after
> `compute.WithTimeout(500).Call(new ComputeFunc());` execution
> `computeForPlatform` compute instance will reset its task modifiers and
> `compute`
> comput instance will not.
> So the next task execution after `compute.WithTimeout(500).Call(new
> ComputeFunc());` that uses `compute`instance will be executed with timout
> modifier applied even it was not applied by the user.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18774) PartitionReplicaListenerTest#testReadOnlyGetAllAfterRowRewrite hangs forever
[ https://issues.apache.org/jira/browse/IGNITE-18774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17687913#comment-17687913 ] Vladislav Pyatkov commented on IGNITE-18774: Merged f3ac586d7da227e79a0c80e8488a667b73b1f2bb > PartitionReplicaListenerTest#testReadOnlyGetAllAfterRowRewrite hangs forever > > > Key: IGNITE-18774 > URL: https://issues.apache.org/jira/browse/IGNITE-18774 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Denis Chudov >Priority: Blocker > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunUnitTests/7069824?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandBuildProblemsSection=true&expandBuildChangesSection=true -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18774) PartitionReplicaListenerTest#testReadOnlyGetAllAfterRowRewrite hangs forever
[ https://issues.apache.org/jira/browse/IGNITE-18774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17687912#comment-17687912 ] Vladislav Pyatkov commented on IGNITE-18774: LGTM > PartitionReplicaListenerTest#testReadOnlyGetAllAfterRowRewrite hangs forever > > > Key: IGNITE-18774 > URL: https://issues.apache.org/jira/browse/IGNITE-18774 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Denis Chudov >Priority: Blocker > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunUnitTests/7069824?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandBuildProblemsSection=true&expandBuildChangesSection=true -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18581) Bootstrap Configuration: don't save bootstrap configuration in vault
[ https://issues.apache.org/jira/browse/IGNITE-18581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-18581: --- Ignite Flags: Docs Required (was: Docs Required,Release Notes Required) > Bootstrap Configuration: don't save bootstrap configuration in vault > > > Key: IGNITE-18581 > URL: https://issues.apache.org/jira/browse/IGNITE-18581 > Project: Ignite > Issue Type: New Feature > Components: build >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 2h > Remaining Estimate: 0h > > *Motivation* > *There is no single mechanism for changing the configuration* > As described above currently a user needs to modify two different > configuration files (vars.env and ignite-conf.conf) in order to configure a > node. But these configuration files perform different tasks. At the moment, > the vars.env file specifies the arguments that are necessary to start the > node and read the configuration properties, if necessary, from the vault. > This is the name of the node, the path to the vault work directory, the path > to the configuration file, and the node finder argument. If the first three > have a clear purpose, because without them it is impossible to start reading > the configuration, then the last argument is quite controversial and its > necessity does not seem obvious. > *Mixing of Ignite node configuration and state* > Currently after the first node start provided bootstrap configuration is > stored in the local node vault. After the node is restarted, the new > bootstrap configuration is merged with what was saved to the local vault; if > the user deleted or commented out any property in the configuration file > before restarting the node, then it will be applied from the saved > configuration from the last run. This can cause a lot of confusion on the > part of the user because the application applies some of the properties for > the user. So, in conclusion, the current mechanism of configuration storage > looks more like migrating configuration to node state and we have the > stateful node after start. > This ticket reqiore changes to stop saving the starting configuration to the > local vault. It is proposed to make the configuration file on the local fs > the only source of truth, and the node should also read this file every time > it starts. In such a case, changing the file by the user and restarting the > node will apply those changes. These changes should be validated before > applying and saving. > Manual changes in config file should be applied only after node restart. In > case when a user modified a configuration file manually (modified config > file) with some errors after restart, the node should fail to start with a > good explanation of reasons and the user should understand which kind of > error presented in the config file. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18782) Snapshot restore might fail after cluster become active due to transition state
[ https://issues.apache.org/jira/browse/IGNITE-18782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-18782: Ignite Flags: (was: Docs Required,Release Notes Required) > Snapshot restore might fail after cluster become active due to transition > state > --- > > Key: IGNITE-18782 > URL: https://issues.apache.org/jira/browse/IGNITE-18782 > Project: Ignite > Issue Type: Bug >Reporter: Maksim Timonin >Priority: Major > > `ign.cluster().state(ClusterState.ACTIVE)` activates cluster but after this > method returns some grid nodes might be in transition state - > `ctx.state().clusterState().transition() == true`. > Ignite nodes checks the transition state before restoring snapshot, and then > restoring procedure might fail. > Also, it looks like `GridClusterStateProcessor#publicApiState(boolean > waitForTransition)` doesn't check transition state. Example is > IgniteClusterSnapshotRestoreSelfTest#testUserClassRestored - it's required to > explicitly check transition to start restoring snapshot, usage of the > publicApiState call doesn't help. Maybe bug here? > There are some possible ways to fix it: > # `state(ClusterState.ACTIVE)` should return after transition has fully > completed > # Snapshot restoring should await while transition state finished. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18782) Snapshot restore might fail after cluster become active due to transition state
Maksim Timonin created IGNITE-18782: --- Summary: Snapshot restore might fail after cluster become active due to transition state Key: IGNITE-18782 URL: https://issues.apache.org/jira/browse/IGNITE-18782 Project: Ignite Issue Type: Bug Reporter: Maksim Timonin `ign.cluster().state(ClusterState.ACTIVE)` activates cluster but after this method returns some grid nodes might be in transition state - `ctx.state().clusterState().transition() == true`. Ignite nodes checks the transition state before restoring snapshot, and then restoring procedure might fail. Also, it looks like `GridClusterStateProcessor#publicApiState(boolean waitForTransition)` doesn't check transition state. Example is IgniteClusterSnapshotRestoreSelfTest#testUserClassRestored - it's required to explicitly check transition to start restoring snapshot, usage of the publicApiState call doesn't help. Maybe bug here? There are some possible ways to fix it: # `state(ClusterState.ACTIVE)` should return after transition has fully completed # Snapshot restoring should await while transition state finished. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18732) Remove blocking calls from SchemaManager
[
https://issues.apache.org/jira/browse/IGNITE-18732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-18732:
-
Fix Version/s: 3.0.0-beta2
> Remove blocking calls from SchemaManager
>
>
> Key: IGNITE-18732
> URL: https://issues.apache.org/jira/browse/IGNITE-18732
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Minor
> Labels: ignite-3, tech-debt
> Fix For: 3.0.0-beta2
>
>
> {{SchemaManager}} class has two methods, that perform a blocking {{get}} call
> on a {{CompletableFuture}}: {{latestSchemaVersion}} and {{schemaByVersion}}.
> Instead, these methods should return the future and its callers must be
> rewritten in an asynchronous style.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18764) Cluster snapshot doesn't restore marshaller data
[ https://issues.apache.org/jira/browse/IGNITE-18764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-18764: Fix Version/s: 2.15 > Cluster snapshot doesn't restore marshaller data > > > Key: IGNITE-18764 > URL: https://issues.apache.org/jira/browse/IGNITE-18764 > Project: Ignite > Issue Type: Bug >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: ise > Fix For: 2.15 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Case: > # There is a cache - IgniteCache > # cache.put(0, new BetterAccount()), where BetterAccount extends Account > # createSnapshot() > # restoreSnapshot on clean environment > # cache.get(0) throws java.lang.ClassNotFoundException: Failed to resolve > class name [platformId=0, platform=Java, typeId=-68243360] > Reason that Ignite restores binary meta but misses marshaller data. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18764) Cluster snapshot doesn't restore marshaller data
[ https://issues.apache.org/jira/browse/IGNITE-18764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-18764: Ignite Flags: (was: Docs Required,Release Notes Required) > Cluster snapshot doesn't restore marshaller data > > > Key: IGNITE-18764 > URL: https://issues.apache.org/jira/browse/IGNITE-18764 > Project: Ignite > Issue Type: Bug >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: ise > Time Spent: 1.5h > Remaining Estimate: 0h > > Case: > # There is a cache - IgniteCache > # cache.put(0, new BetterAccount()), where BetterAccount extends Account > # createSnapshot() > # restoreSnapshot on clean environment > # cache.get(0) throws java.lang.ClassNotFoundException: Failed to resolve > class name [platformId=0, platform=Java, typeId=-68243360] > Reason that Ignite restores binary meta but misses marshaller data. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18764) Cluster snapshot doesn't restore marshaller data
[
https://issues.apache.org/jira/browse/IGNITE-18764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17687884#comment-17687884
]
Ignite TC Bot commented on IGNITE-18764:
{panel:title=Branch: [pull/10527/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 TIMEOUT , Exit Code
, TC_SERVICE_MESSAGE
|https://ci2.ignite.apache.org/viewLog.html?buildId=7047584]]
{panel}
{panel:title=Branch: [pull/10527/head] Base: [master] : New Tests
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Disk Page Compressions 1{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7047592]]
* {color:#013220}IgnitePdsCompressionTestSuite:
IgniteClusterSnapshotRestoreSelfTest.testUserClassRestored[Encryption=false] -
PASSED{color}
{color:#8b}Snapshots{color} [[tests
2|https://ci2.ignite.apache.org/viewLog.html?buildId=7047616]]
* {color:#013220}IgniteSnapshotTestSuite:
IgniteClusterSnapshotRestoreSelfTest.testUserClassRestored[Encryption=false] -
PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteClusterSnapshotRestoreSelfTest.testUserClassRestored[Encryption=true] -
PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7046903&buildTypeId=IgniteTests24Java8_RunAll]
> Cluster snapshot doesn't restore marshaller data
>
>
> Key: IGNITE-18764
> URL: https://issues.apache.org/jira/browse/IGNITE-18764
> Project: Ignite
> Issue Type: Bug
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Labels: ise
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Case:
> # There is a cache - IgniteCache
> # cache.put(0, new BetterAccount()), where BetterAccount extends Account
> # createSnapshot()
> # restoreSnapshot on clean environment
> # cache.get(0) throws java.lang.ClassNotFoundException: Failed to resolve
> class name [platformId=0, platform=Java, typeId=-68243360]
> Reason that Ignite restores binary meta but misses marshaller data.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18632) Barrier for locks after cleanup started
[ https://issues.apache.org/jira/browse/IGNITE-18632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov reassigned IGNITE-18632: -- Assignee: Vladislav Pyatkov > 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 > > *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] [Assigned] (IGNITE-18746) Sql. Some muted slow tests failed after IGNITE-13022
[ https://issues.apache.org/jira/browse/IGNITE-18746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky reassigned IGNITE-18746: --- Assignee: Evgeny Stanilovsky > Sql. Some muted slow tests failed after IGNITE-13022 > > > Key: IGNITE-18746 > URL: https://issues.apache.org/jira/browse/IGNITE-18746 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > orderby1_10_7.test_slow failed after IGNITE-13022 > it can be fixed by porting: https://issues.apache.org/jira/browse/IGNITE-17889 > Probably in scope of this issue it would be helpful to fix code duplication : > RexUtils#buildHashSearchBounds(org.apache.calcite.plan.RelOptCluster, > org.apache.calcite.rex.RexNode, org.apache.calcite.rel.type.RelDataType, > org.apache.calcite.util.ImmutableBitSet) > RexUtils#buildHashSearchBounds(org.apache.calcite.plan.RelOptCluster, > org.apache.calcite.rel.RelCollation, org.apache.calcite.rex.RexNode, > org.apache.calcite.rel.type.RelDataType, > org.apache.calcite.util.ImmutableBitSet) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18780) Remove note about Services being unsupported
[ https://issues.apache.org/jira/browse/IGNITE-18780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18780: Ignite Flags: (was: Docs Required,Release Notes Required) > Remove note about Services being unsupported > > > Key: IGNITE-18780 > URL: https://issues.apache.org/jira/browse/IGNITE-18780 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > > On page: > [https://ignite.apache.org/docs/latest/net-specific/net-platform-interoperability#mixed-platform-clusters] > > Services are supported in mixed-platform clusters, including Java ↔︎ .NET > service calls, as explained in > [https://www.gridgain.com/docs/latest/developers-guide/net-specific/net-java-services-execution] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18780) Remove note about Services being unsupported
[ https://issues.apache.org/jira/browse/IGNITE-18780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17687872#comment-17687872 ] Pavel Tupitsyn commented on IGNITE-18780: - Merged to master: bbcc563ccee1ef92bcd3b7c17331c7f2c4538dfa > Remove note about Services being unsupported > > > Key: IGNITE-18780 > URL: https://issues.apache.org/jira/browse/IGNITE-18780 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > On page: > [https://ignite.apache.org/docs/latest/net-specific/net-platform-interoperability#mixed-platform-clusters] > > Services are supported in mixed-platform clusters, including Java ↔︎ .NET > service calls, as explained in > [https://www.gridgain.com/docs/latest/developers-guide/net-specific/net-java-services-execution] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18779) Fix typos in Ignite .NET doc
[ https://issues.apache.org/jira/browse/IGNITE-18779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18779: Ignite Flags: (was: Docs Required,Release Notes Required) > Fix typos in Ignite .NET doc > > > Key: IGNITE-18779 > URL: https://issues.apache.org/jira/browse/IGNITE-18779 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > > This page name has .NT, need to change it to .NET: > [https://ignite.apache.org/docs/latest/net-specific/net-java-services-execution] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18779) Fix typos in Ignite .NET doc
[ https://issues.apache.org/jira/browse/IGNITE-18779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17687868#comment-17687868 ] Pavel Tupitsyn commented on IGNITE-18779: - Merged to master: df5f77e656c175ced96db2f58eccdfd481d8cff4 > Fix typos in Ignite .NET doc > > > Key: IGNITE-18779 > URL: https://issues.apache.org/jira/browse/IGNITE-18779 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > This page name has .NT, need to change it to .NET: > [https://ignite.apache.org/docs/latest/net-specific/net-java-services-execution] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18781) Strange ports used - Failed to process selector key
[ https://issues.apache.org/jira/browse/IGNITE-18781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Tenter updated IGNITE-18781: Summary: Strange ports used - Failed to process selector key (was: Strange outgoing ports used - Failed to process selector key) > Strange ports used - Failed to process selector key > --- > > Key: IGNITE-18781 > URL: https://issues.apache.org/jira/browse/IGNITE-18781 > Project: Ignite > Issue Type: Bug > Components: networking >Affects Versions: 2.14 >Reporter: Christopher Tenter >Priority: Major > Attachments: ignitelog.txt > > > A two-node cluster occasionally cannot communicate when ignite uses a strange > local or remote port. We've opened all ports that are documented here > [https://ignite.apache.org/docs/latest/clustering/network-configuration] > > However, ignite uses a seemingly random port for connecting to the other node > sometimes. By default all ports are closed in the firewall, so the connection > fails with message "Failed to process selector key" > > Here are some connections that ignite attempts: > locAddr=/10.125.100.93:20395, rmtAddr=/10.125.100.179:47100 > locAddr=/10.125.100.93:10800, rmtAddr=/10.125.100.93:1851 > locAddr=/10.125.100.93:10800, rmtAddr=/10.125.100.93:1775 > locAddr=/10.125.100.93:1323, rmtAddr=/10.125.100.179:47100 > > So ports 20395, 1851, 1775, 1323 are used, but they are closed in the > firewall. The ports change all the time. If I add them to the firewall, it > doesn't take long until another unknown one pops up. I could not find them > anywhere in the ignite documentation. Where do they come from and how to fix > it? > > The network settings in the server config looks like this: > > > > class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder"> > > > 10.125.100.93 > 10.125.100.179 > > > > > > > > > class="org.apache.ignite.configuration.TransactionConfiguration"> > > > > > > class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi"> > > > > > > Full log output of the "Failed to process selector key" error attached. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18781) Strange outgoing ports used - Failed to process selector key
Christopher Tenter created IGNITE-18781: --- Summary: Strange outgoing ports used - Failed to process selector key Key: IGNITE-18781 URL: https://issues.apache.org/jira/browse/IGNITE-18781 Project: Ignite Issue Type: Bug Components: networking Affects Versions: 2.14 Reporter: Christopher Tenter Attachments: ignitelog.txt A two-node cluster occasionally cannot communicate when ignite uses a strange local or remote port. We've opened all ports that are documented here [https://ignite.apache.org/docs/latest/clustering/network-configuration] However, ignite uses a seemingly random port for connecting to the other node sometimes. By default all ports are closed in the firewall, so the connection fails with message "Failed to process selector key" Here are some connections that ignite attempts: locAddr=/10.125.100.93:20395, rmtAddr=/10.125.100.179:47100 locAddr=/10.125.100.93:10800, rmtAddr=/10.125.100.93:1851 locAddr=/10.125.100.93:10800, rmtAddr=/10.125.100.93:1775 locAddr=/10.125.100.93:1323, rmtAddr=/10.125.100.179:47100 So ports 20395, 1851, 1775, 1323 are used, but they are closed in the firewall. The ports change all the time. If I add them to the firewall, it doesn't take long until another unknown one pops up. I could not find them anywhere in the ignite documentation. Where do they come from and how to fix it? The network settings in the server config looks like this: 10.125.100.93 10.125.100.179 Full log output of the "Failed to process selector key" error attached. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18779) Fix typos in Ignite .NET doc
[ https://issues.apache.org/jira/browse/IGNITE-18779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Gusev reassigned IGNITE-18779: --- Assignee: Igor Gusev > Fix typos in Ignite .NET doc > > > Key: IGNITE-18779 > URL: https://issues.apache.org/jira/browse/IGNITE-18779 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > This page name has .NT, need to change it to .NET: > [https://ignite.apache.org/docs/latest/net-specific/net-java-services-execution] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18780) Remove note about Services being unsupported
[ https://issues.apache.org/jira/browse/IGNITE-18780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Gusev reassigned IGNITE-18780: --- Assignee: Igor Gusev > Remove note about Services being unsupported > > > Key: IGNITE-18780 > URL: https://issues.apache.org/jira/browse/IGNITE-18780 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > On page: > [https://ignite.apache.org/docs/latest/net-specific/net-platform-interoperability#mixed-platform-clusters] > > Services are supported in mixed-platform clusters, including Java ↔︎ .NET > service calls, as explained in > [https://www.gridgain.com/docs/latest/developers-guide/net-specific/net-java-services-execution] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18780) Remove note about Services being unsupported
Igor Gusev created IGNITE-18780: --- Summary: Remove note about Services being unsupported Key: IGNITE-18780 URL: https://issues.apache.org/jira/browse/IGNITE-18780 Project: Ignite Issue Type: Task Components: documentation Reporter: Igor Gusev On page: [https://ignite.apache.org/docs/latest/net-specific/net-platform-interoperability#mixed-platform-clusters] Services are supported in mixed-platform clusters, including Java ↔︎ .NET service calls, as explained in [https://www.gridgain.com/docs/latest/developers-guide/net-specific/net-java-services-execution] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18779) Fix typos in Ignite .NET doc
[ https://issues.apache.org/jira/browse/IGNITE-18779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Gusev updated IGNITE-18779: Summary: Fix typos in Ignite .NET doc (was: Fixe typos in Ignite .NET doc) > Fix typos in Ignite .NET doc > > > Key: IGNITE-18779 > URL: https://issues.apache.org/jira/browse/IGNITE-18779 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > This page name has .NT, need to change it to .NET: > [https://ignite.apache.org/docs/latest/net-specific/net-java-services-execution] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18779) Fixe typos in Ignite .NET doc
Igor Gusev created IGNITE-18779: --- Summary: Fixe typos in Ignite .NET doc Key: IGNITE-18779 URL: https://issues.apache.org/jira/browse/IGNITE-18779 Project: Ignite Issue Type: Task Components: documentation Reporter: Igor Gusev This page name has .NT, need to change it to .NET: [https://ignite.apache.org/docs/latest/net-specific/net-java-services-execution] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18777) .NET: Thin 3.0: LINQ: Log generated SQL in debug mode
[ https://issues.apache.org/jira/browse/IGNITE-18777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17687859#comment-17687859 ] Pavel Tupitsyn commented on IGNITE-18777: - Merged to main: bac5e650fd410fc76f3095eb3c761ce3a0e0b0a3 > .NET: Thin 3.0: LINQ: Log generated SQL in debug mode > - > > Key: IGNITE-18777 > URL: https://issues.apache.org/jira/browse/IGNITE-18777 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Minor > Labels: .NET, LINQ, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > While we provide *ToQueryString* extension method to examine generated SQL, > it has limitations: > * Requires code changes to see SQL > * Does not work for aggregates (Min, Max, Avg, Single, etc) > Log generated SQL with debug level, so it is possible to see all queries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18778) Move test related entry point to testFixtures
Mikhail Pochatkin created IGNITE-18778: -- Summary: Move test related entry point to testFixtures Key: IGNITE-18778 URL: https://issues.apache.org/jira/browse/IGNITE-18778 Project: Ignite Issue Type: Improvement Reporter: Mikhail Pochatkin Currently, org.apache.ignite.Ignition org.apache.ignite.IgnitionManager contains different methods but not all methods related to production and used only in test. Need to separate test methods to testFixtures and leave only production related enties on production code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18720) Validate corrupted WAL segment while restoring incremental snapshot
[ https://issues.apache.org/jira/browse/IGNITE-18720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin reassigned IGNITE-18720: --- Assignee: Maksim Timonin > Validate corrupted WAL segment while restoring incremental snapshot > --- > > 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 > > 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] [Assigned] (IGNITE-18565) Modify getOrCreateMvPartition and getMvPartition of MvTableStorage to return the future
[ https://issues.apache.org/jira/browse/IGNITE-18565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko reassigned IGNITE-18565: Assignee: Kirill Tkalenko > Modify getOrCreateMvPartition and getMvPartition of MvTableStorage to return > the future > --- > > Key: IGNITE-18565 > URL: https://issues.apache.org/jira/browse/IGNITE-18565 > Project: Ignite > Issue Type: Task >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > We need to make *MvTableStorage#getOrCreateMvPartition* and > *MvTableStorage#getMvPartition* return the > *CompletableFuture*. > Since, for example, we need to wait for the partition to be deleted before > creating / recreating it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18777) .NET: Thin 3.0: LINQ: Log generated SQL in debug mode
[ https://issues.apache.org/jira/browse/IGNITE-18777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17687801#comment-17687801 ] Igor Sapego commented on IGNITE-18777: -- [~ptupitsyn] looks good to me. > .NET: Thin 3.0: LINQ: Log generated SQL in debug mode > - > > Key: IGNITE-18777 > URL: https://issues.apache.org/jira/browse/IGNITE-18777 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Minor > Labels: .NET, LINQ, ignite-3 > Fix For: 3.0.0-beta2 > > > While we provide *ToQueryString* extension method to examine generated SQL, > it has limitations: > * Requires code changes to see SQL > * Does not work for aggregates (Min, Max, Avg, Single, etc) > Log generated SQL with debug level, so it is possible to see all queries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
