[jira] [Created] (IGNITE-15125) Implement naive baseline
Alexander Lapin created IGNITE-15125: Summary: Implement naive baseline Key: IGNITE-15125 URL: https://issues.apache.org/jira/browse/IGNITE-15125 Project: Ignite Issue Type: Bug Reporter: Alexander Lapin Assignee: Alexander Lapin In order to satisfy the needs on assignments recalculation on topology changes it's required to implement baseline concept. It might be a naive one that will contain all topology nodes and will change on every node add/left event. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15122) Calcite. Remove sync mode of RootNode#closeInternal
[ https://issues.apache.org/jira/browse/IGNITE-15122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17381063#comment-17381063 ] Stanilovsky Evgeny commented on IGNITE-15122: - looks good. > Calcite. Remove sync mode of RootNode#closeInternal > --- > > Key: IGNITE-15122 > URL: https://issues.apache.org/jira/browse/IGNITE-15122 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently we are waiting on future to complete inside RootNode#closeInternal. > It potentially could causes a query to stale in case someone will invoke this > method inside a taskExecutor. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15124) Merge master to sql-calcite feature branch
Alexander Belyak created IGNITE-15124: - Summary: Merge master to sql-calcite feature branch Key: IGNITE-15124 URL: https://issues.apache.org/jira/browse/IGNITE-15124 Project: Ignite Issue Type: Improvement Reporter: Alexander Belyak Assignee: Alexander Belyak -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15079) SharedPageLockTracker.structureNameToId map is populated but never cleaned - 1.3G retained heap
[ https://issues.apache.org/jira/browse/IGNITE-15079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380707#comment-17380707 ] Semyon Danilov commented on IGNITE-15079: - LGTM! Thank you > SharedPageLockTracker.structureNameToId map is populated but never cleaned - > 1.3G retained heap > --- > > Key: IGNITE-15079 > URL: https://issues.apache.org/jira/browse/IGNITE-15079 > Project: Ignite > Issue Type: Task >Affects Versions: 2.10 >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Fix For: 2.12 > > Attachments: structureNameById.png > > Time Spent: 10m > Remaining Estimate: 0h > > I can see SharedPageLockTracker.structureNameToId.put() being called, but > never remove() or clear(). > Naturally, this leads to memory leak. During 36d uptime, an 1.3G of total > retained heap (keys, values and cells) were reached. This is unacceptable, it > should have either TTL or max size to avoid using 1% of heap (20% in this > case). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-14843) Avoid probing follower if it's dead by discovery
[ https://issues.apache.org/jira/browse/IGNITE-14843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov resolved IGNITE-14843. Resolution: Won't Fix Sometime a discovery event is lost with the current implementation on node restarts, so it's not possible to solely relay on this for replicator management. Closing ticket for now. It can be re-evaluated as soon as a discovery is proven to work reliably. > Avoid probing follower if it's dead by discovery > > > Key: IGNITE-14843 > URL: https://issues.apache.org/jira/browse/IGNITE-14843 > Project: Ignite > Issue Type: Task >Reporter: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > > We can remove some computations (checking for dead nodes) and replace it with > SWIM node alive event - start replicator when the event is received. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15123) Calcite. Multi-tuple insert fails on validation
[
https://issues.apache.org/jira/browse/IGNITE-15123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-15123:
--
Environment: (was:
{noformat}
class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
validate query.
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareQuery(ExecutionServiceImpl.java:531)
at
org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.queryPlan(QueryPlanCacheImpl.java:84)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeQuery(ExecutionServiceImpl.java:391)
at
org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:259)
at
org.apache.ignite.internal.processors.query.calcite.integration.AbstractDdlIntegrationTest.executeSql(AbstractDdlIntegrationTest.java:77)
at
org.apache.ignite.internal.processors.query.calcite.integration.TableDdlIntegrationTest.test(TableDdlIntegrationTest.java:91)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2432)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.apache.calcite.tools.ValidationException:
org.apache.calcite.runtime.CalciteContextException: From line 1, column 18 to
line 1, column 44: Values passed to VALUES operator must have compatible types
at
org.apache.ignite.internal.processors.query.calcite.prepare.IgnitePlanner.validate(IgnitePlanner.java:175)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareDml(ExecutionServiceImpl.java:601)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareSingle(ExecutionServiceImpl.java:565)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareQuery(ExecutionServiceImpl.java:514)
... 17 more
Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1,
column 18 to line 1, column 44: Values passed to VALUES operator must have
compatible types
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at
org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:506)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:917)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:902)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5271)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateValues(SqlValidatorImpl.java:5217)
at
org.apache.calcite.sql.validate.TableConstructorNamespace.validateImpl(TableConstructorNamespace.java:61)
at
org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:89)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1098)
at
org.apache.ignite.internal.processors.query.calcite.prepare.IgniteSqlValidator.validateNamespace(IgniteSqlValidator.java:196)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:1069)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateInsert(SqlValidatorImpl.java:4594)
at
org.apache.ignite.internal.processors.query.calcite.prepare.IgniteSqlValidator.validateInsert(IgniteSqlValidator.java:115)
at org.apache.calcite.sql.SqlInsert.validate(SqlInsert.java:166)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1044)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.val
[jira] [Updated] (IGNITE-15123) Calcite. Multi-tuple insert fails on validation
[
https://issues.apache.org/jira/browse/IGNITE-15123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-15123:
--
Description:
Currently a query like below fails on validation step:
{code:java}
create table test(d date);
insert into test values('1990-01-01'),(null);
{code}
The reason is an extra validation step for insert with several tuples. This
validation checks that all tuples have the same degree and the types of the
corresponding fields throughout all tuples have the same family.
In the example above types are mismatched cause type of the first tuple is
CHAR, and type of the second tuple is DATE (because it's derived from table).
{noformat}
class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
validate query.
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareQuery(ExecutionServiceImpl.java:531)
at
org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.queryPlan(QueryPlanCacheImpl.java:84)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeQuery(ExecutionServiceImpl.java:391)
at
org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:259)
at
org.apache.ignite.internal.processors.query.calcite.integration.AbstractDdlIntegrationTest.executeSql(AbstractDdlIntegrationTest.java:77)
at
org.apache.ignite.internal.processors.query.calcite.integration.TableDdlIntegrationTest.test(TableDdlIntegrationTest.java:91)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2432)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.apache.calcite.tools.ValidationException:
org.apache.calcite.runtime.CalciteContextException: From line 1, column 18 to
line 1, column 44: Values passed to VALUES operator must have compatible types
at
org.apache.ignite.internal.processors.query.calcite.prepare.IgnitePlanner.validate(IgnitePlanner.java:175)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareDml(ExecutionServiceImpl.java:601)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareSingle(ExecutionServiceImpl.java:565)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareQuery(ExecutionServiceImpl.java:514)
... 17 more
Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1,
column 18 to line 1, column 44: Values passed to VALUES operator must have
compatible types
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at
org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:506)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:917)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:902)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5271)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateValues(SqlValidatorImpl.java:5217)
at
org.apache.calcite.sql.validate.TableConstructorNamespace.validateImpl(TableConstructorNamespace.java:61)
at
org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:89)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1098)
at
org.apache.ignite.internal.processors.query.calcite.prepare.IgniteSqlValidator.validateNamespace(IgniteSqlValidator.java:196)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(Sq
[jira] [Created] (IGNITE-15123) Calcite. Multi-tuple insert fails on validation
Konstantin Orlov created IGNITE-15123:
-
Summary: Calcite. Multi-tuple insert fails on validation
Key: IGNITE-15123
URL: https://issues.apache.org/jira/browse/IGNITE-15123
Project: Ignite
Issue Type: Bug
Environment:
{noformat}
class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
validate query.
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareQuery(ExecutionServiceImpl.java:531)
at
org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.queryPlan(QueryPlanCacheImpl.java:84)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeQuery(ExecutionServiceImpl.java:391)
at
org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:259)
at
org.apache.ignite.internal.processors.query.calcite.integration.AbstractDdlIntegrationTest.executeSql(AbstractDdlIntegrationTest.java:77)
at
org.apache.ignite.internal.processors.query.calcite.integration.TableDdlIntegrationTest.test(TableDdlIntegrationTest.java:91)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2432)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.apache.calcite.tools.ValidationException:
org.apache.calcite.runtime.CalciteContextException: From line 1, column 18 to
line 1, column 44: Values passed to VALUES operator must have compatible types
at
org.apache.ignite.internal.processors.query.calcite.prepare.IgnitePlanner.validate(IgnitePlanner.java:175)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareDml(ExecutionServiceImpl.java:601)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareSingle(ExecutionServiceImpl.java:565)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareQuery(ExecutionServiceImpl.java:514)
... 17 more
Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1,
column 18 to line 1, column 44: Values passed to VALUES operator must have
compatible types
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at
org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:506)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:917)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:902)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5271)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateValues(SqlValidatorImpl.java:5217)
at
org.apache.calcite.sql.validate.TableConstructorNamespace.validateImpl(TableConstructorNamespace.java:61)
at
org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:89)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1098)
at
org.apache.ignite.internal.processors.query.calcite.prepare.IgniteSqlValidator.validateNamespace(IgniteSqlValidator.java:196)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:1069)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateInsert(SqlValidatorImpl.java:4594)
at
org.apache.ignite.internal.processors.query.calcite.prepare.IgniteSqlValidator.validateInsert(IgniteSqlValidator.java:115)
at org.apache.calcite.sql.SqlInsert.validate(SqlInsert.java:166)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedEx
[jira] [Commented] (IGNITE-15019) ITNodeTest.testFollowerStartStopFollowing is flaky
[
https://issues.apache.org/jira/browse/IGNITE-15019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380683#comment-17380683
]
Alexey Scherbakov commented on IGNITE-15019:
[~maliev]
LGTM
> ITNodeTest.testFollowerStartStopFollowing is flaky
> --
>
> Key: IGNITE-15019
> URL: https://issues.apache.org/jira/browse/IGNITE-15019
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha2
>Reporter: Ivan Bessonov
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> [ERROR]
> org.apache.ignite.raft.jraft.core.ITNodeTest.testFollowerStartStopFollowing
> Time elapsed: 1.557 s <<< FAILURE!
> org.opentest4j.AssertionFailedError: expected: <2> but was: <3>
> at
> org.apache.ignite.raft.jraft.core.ITNodeTest.testFollowerStartStopFollowing(ITNodeTest.java:2686)
> {code}
> This is all I have from logs. Must be a race somewhere
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15019) ITNodeTest.testFollowerStartStopFollowing is flaky
[
https://issues.apache.org/jira/browse/IGNITE-15019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380682#comment-17380682
]
Mirza Aliev commented on IGNITE-15019:
--
[~ascherbakov] I've removed mentioned flag, could you please review it again?
> ITNodeTest.testFollowerStartStopFollowing is flaky
> --
>
> Key: IGNITE-15019
> URL: https://issues.apache.org/jira/browse/IGNITE-15019
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha2
>Reporter: Ivan Bessonov
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> [ERROR]
> org.apache.ignite.raft.jraft.core.ITNodeTest.testFollowerStartStopFollowing
> Time elapsed: 1.557 s <<< FAILURE!
> org.opentest4j.AssertionFailedError: expected: <2> but was: <3>
> at
> org.apache.ignite.raft.jraft.core.ITNodeTest.testFollowerStartStopFollowing(ITNodeTest.java:2686)
> {code}
> This is all I have from logs. Must be a race somewhere
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14840) Get rid of slf4j in jraft package
[ https://issues.apache.org/jira/browse/IGNITE-14840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev reassigned IGNITE-14840: Assignee: Mirza Aliev > Get rid of slf4j in jraft package > - > > Key: IGNITE-14840 > URL: https://issues.apache.org/jira/browse/IGNITE-14840 > Project: Ignite > Issue Type: Task >Reporter: Alexey Scherbakov >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > > We should replace slf4j logging with IgniteLogger. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15058) testLockUnlock is flaky
[ https://issues.apache.org/jira/browse/IGNITE-15058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380665#comment-17380665 ] Mirza Aliev commented on IGNITE-15058: -- I've tried to reproduce the bug more than 2500 times and haven't succeeded. Also, the test looks a bit fragile when you run it on a device with a loaded CPU, so I would say that there is nothing to fix. > testLockUnlock is flaky > --- > > Key: IGNITE-15058 > URL: https://issues.apache.org/jira/browse/IGNITE-15058 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > > ThreadIdTest.testLockUnlock:62 expected:<1000.0> but was:<987.0> -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15080) Calcite. Functions extends string parameters by trailing spaces
[
https://issues.apache.org/jira/browse/IGNITE-15080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-15080:
---
Description:
I discovered the strange behavior of functions with several string parameters,
which then returns one of these parameters. In this case, the returned
parameter string is expanded with trailing spaces to the length of the longest
string.
{code:java}
query T
SELECT COALESCE(COALESCE(null, 'world'), 'blabla')
world - result is 'world ' - so we have extra trailing spaces from max length
string parameter'blabla'{code}
{code:java}
query I
SELECT DECODE(102, 101, 'IBM', 102, 'GRIDGAIN', 103, 'Hewlett Packard','BALL')
GRIDGAIN - result is 'GRIDGAIN ' - so we have extra traiing spaces from
max length string parameter 'Hewlett Packard'{code}
see src/test/sql/function/generic/test_decode.test_ignore
see src/test/sql/function/generic/test_coalesce.test_ignore
was:
simple query
{code:java}
SELECT COALESCE(null, null, 'first', 'second', null){code}
returns 'first ' string instead of 'first'
see src/test/sql/function/generic/test_coalesce.test_ignore
> Calcite. Functions extends string parameters by trailing spaces
> ---
>
> Key: IGNITE-15080
> URL: https://issues.apache.org/jira/browse/IGNITE-15080
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
>
> I discovered the strange behavior of functions with several string
> parameters, which then returns one of these parameters. In this case, the
> returned parameter string is expanded with trailing spaces to the length of
> the longest string.
> {code:java}
> query T
> SELECT COALESCE(COALESCE(null, 'world'), 'blabla')
>
> world - result is 'world ' - so we have extra trailing spaces from max
> length string parameter'blabla'{code}
> {code:java}
> query I
> SELECT DECODE(102, 101, 'IBM', 102, 'GRIDGAIN', 103, 'Hewlett Packard','BALL')
>
> GRIDGAIN - result is 'GRIDGAIN ' - so we have extra traiing spaces
> from max length string parameter 'Hewlett Packard'{code}
> see src/test/sql/function/generic/test_decode.test_ignore
> see src/test/sql/function/generic/test_coalesce.test_ignore
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15080) Calcite. Functions extends string parameters by trailing spaces
[
https://issues.apache.org/jira/browse/IGNITE-15080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-15080:
---
Summary: Calcite. Functions extends string parameters by trailing spaces
(was: Calcite. COALESCE returns trailing space for some cases)
> Calcite. Functions extends string parameters by trailing spaces
> ---
>
> Key: IGNITE-15080
> URL: https://issues.apache.org/jira/browse/IGNITE-15080
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
>
> simple query
> {code:java}
> SELECT COALESCE(null, null, 'first', 'second', null){code}
> returns 'first ' string instead of 'first'
> see src/test/sql/function/generic/test_coalesce.test_ignore
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15121) WALRecordTest fails due to missing PARTITION_META_PAGE_DELTA_RECORD_V4 record
[ https://issues.apache.org/jira/browse/IGNITE-15121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380603#comment-17380603 ] Pavel Tupitsyn commented on IGNITE-15121: - [~slava.koptilin] looks good to me. > WALRecordTest fails due to missing PARTITION_META_PAGE_DELTA_RECORD_V4 record > -- > > Key: IGNITE-15121 > URL: https://issues.apache.org/jira/browse/IGNITE-15121 > Project: Ignite > Issue Type: Bug >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.12 > > Time Spent: 10m > Remaining Estimate: 0h > > The following tests do not pass due to missing a WAL record related to > PARTITION_META_PAGE_DELTA_RECORD_V4: > - WALRecordTest.testAllTestWalRecordBuilderConfigured > - > WALRecordSerializationTest.testAllWalRecordsSerializedAndDeserializedSuccessfully > The fix is obvious, need to add corresponding UnsupportedWalRecord to > RecordUtils. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14838) Fix up messaging in jraft.
[ https://issues.apache.org/jira/browse/IGNITE-14838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev reassigned IGNITE-14838: Assignee: Aleksandr Polovtcev > Fix up messaging in jraft. > -- > > Key: IGNITE-14838 > URL: https://issues.apache.org/jira/browse/IGNITE-14838 > Project: Ignite > Issue Type: Task >Reporter: Alexey Scherbakov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > > Currently jraft uses hand coded messages. > This should be cleaned up and switched to generated factories. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15019) ITNodeTest.testFollowerStartStopFollowing is flaky
[
https://issues.apache.org/jira/browse/IGNITE-15019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380601#comment-17380601
]
Alexey Scherbakov commented on IGNITE-15019:
[~maliev]
I think we don't need this [1] at all, can you wipe it from the code ?
All the rest is good.
[1] org.apache.ignite.raft.jraft.RaftGroupService#sharedRpcServer
> ITNodeTest.testFollowerStartStopFollowing is flaky
> --
>
> Key: IGNITE-15019
> URL: https://issues.apache.org/jira/browse/IGNITE-15019
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha2
>Reporter: Ivan Bessonov
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> [ERROR]
> org.apache.ignite.raft.jraft.core.ITNodeTest.testFollowerStartStopFollowing
> Time elapsed: 1.557 s <<< FAILURE!
> org.opentest4j.AssertionFailedError: expected: <2> but was: <3>
> at
> org.apache.ignite.raft.jraft.core.ITNodeTest.testFollowerStartStopFollowing(ITNodeTest.java:2686)
> {code}
> This is all I have from logs. Must be a race somewhere
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15121) WALRecordTest fails due to missing PARTITION_META_PAGE_DELTA_RECORD_V4 record
[ https://issues.apache.org/jira/browse/IGNITE-15121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380597#comment-17380597 ] Vyacheslav Koptilin commented on IGNITE-15121: -- I don't think that there is a reason for running RunAll. It seems to me, it is enough Basic1 and Inspections suites. https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Basic1?branch=pull%2F9253%2Fhead&mode=builds https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_InspectionsCore?branch=pull%2F9253%2Fhead&buildTypeTab=overview&mode=builds#all-projects > WALRecordTest fails due to missing PARTITION_META_PAGE_DELTA_RECORD_V4 record > -- > > Key: IGNITE-15121 > URL: https://issues.apache.org/jira/browse/IGNITE-15121 > Project: Ignite > Issue Type: Bug >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.12 > > Time Spent: 10m > Remaining Estimate: 0h > > The following tests do not pass due to missing a WAL record related to > PARTITION_META_PAGE_DELTA_RECORD_V4: > - WALRecordTest.testAllTestWalRecordBuilderConfigured > - > WALRecordSerializationTest.testAllWalRecordsSerializedAndDeserializedSuccessfully > The fix is obvious, need to add corresponding UnsupportedWalRecord to > RecordUtils. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15122) Calcite. Remove sync mode of RootNode#closeInternal
Konstantin Orlov created IGNITE-15122: - Summary: Calcite. Remove sync mode of RootNode#closeInternal Key: IGNITE-15122 URL: https://issues.apache.org/jira/browse/IGNITE-15122 Project: Ignite Issue Type: Bug Components: sql Reporter: Konstantin Orlov Assignee: Konstantin Orlov Currently we are waiting on future to complete inside RootNode#closeInternal. It potentially could causes a query to stale in case someone will invoke this method inside a taskExecutor. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15079) SharedPageLockTracker.structureNameToId map is populated but never cleaned - 1.3G retained heap
[
https://issues.apache.org/jira/browse/IGNITE-15079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380535#comment-17380535
]
Ignite TC Bot commented on IGNITE-15079:
{panel:title=Branch: [pull/9250/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9250/head] Base: [master] : New Tests
(7)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Basic 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6084718]]
* {color:#013220}IgniteBasicTestSuite: IntHashMapTest.testClear - PASSED{color}
{color:#8b}PDS 4{color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=6085387]]
* {color:#013220}IgnitePdsTestSuite4:
PageLockTrackerResourcesTest.testStructureIdLeakOnNodeDestroy - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
PageLockTrackerResourcesTest.testStructureIdLeakOnCacheDestroy - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
SharedPageLockTrackerTest.testCloseListener[trackerType=1] - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
SharedPageLockTrackerTest.testCloseListener[trackerType=4] - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
SharedPageLockTrackerTest.testCloseListener[trackerType=3] - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
SharedPageLockTrackerTest.testCloseListener[trackerType=2] - PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6084779&buildTypeId=IgniteTests24Java8_RunAll]
> SharedPageLockTracker.structureNameToId map is populated but never cleaned -
> 1.3G retained heap
> ---
>
> Key: IGNITE-15079
> URL: https://issues.apache.org/jira/browse/IGNITE-15079
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.10
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Fix For: 2.12
>
> Attachments: structureNameById.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I can see SharedPageLockTracker.structureNameToId.put() being called, but
> never remove() or clear().
> Naturally, this leads to memory leak. During 36d uptime, an 1.3G of total
> retained heap (keys, values and cells) were reached. This is unacceptable, it
> should have either TTL or max size to avoid using 1% of heap (20% in this
> case).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15121) WALRecordTest fails due to missing PARTITION_META_PAGE_DELTA_RECORD_V4 record
Vyacheslav Koptilin created IGNITE-15121: Summary: WALRecordTest fails due to missing PARTITION_META_PAGE_DELTA_RECORD_V4 record Key: IGNITE-15121 URL: https://issues.apache.org/jira/browse/IGNITE-15121 Project: Ignite Issue Type: Bug Reporter: Vyacheslav Koptilin Assignee: Vyacheslav Koptilin Fix For: 2.12 The following tests do not pass due to missing a WAL record related to PARTITION_META_PAGE_DELTA_RECORD_V4: - WALRecordTest.testAllTestWalRecordBuilderConfigured - WALRecordSerializationTest.testAllWalRecordsSerializedAndDeserializedSuccessfully The fix is obvious, need to add corresponding UnsupportedWalRecord to RecordUtils. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15118) Add handshake timeout to pyignite client
[
https://issues.apache.org/jira/browse/IGNITE-15118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-15118:
-
Description: Additional handshake timeout should be added to both
{{Client}} and {{AioClient}}. (was: Addition handshake timeout should be added
to both {{Client}} and {{AioClient}}.)
> Add handshake timeout to pyignite client
>
>
> Key: IGNITE-15118
> URL: https://issues.apache.org/jira/browse/IGNITE-15118
> Project: Ignite
> Issue Type: Improvement
> Components: python, thin client
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Labels: python, thin
>
> Additional handshake timeout should be added to both {{Client}} and
> {{AioClient}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15120) Condition isTombstone() is required
Alexander Lapin created IGNITE-15120:
Summary: Condition isTombstone() is required
Key: IGNITE-15120
URL: https://issues.apache.org/jira/browse/IGNITE-15120
Project: Ignite
Issue Type: Bug
Reporter: Alexander Lapin
Assignee: Andrey N. Gura
Currently
{code:java}
Conditions.notExists(key){code}
will both return true if there were no such key or if it was removed. New
condition that will allow to detect whether a key was removed or not created is
required. It might look like
{code:java}
Conditions.isTombstone(key){code}
or similar.
Seems that it'll be also helpful if
org.apache.ignite.internal.metastorage.client.Conditions#notExists
javadoc' will be more specific about tombstone case.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-15117) Support CDC for in-memory caches
[ https://issues.apache.org/jira/browse/IGNITE-15117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov reassigned IGNITE-15117: Assignee: Nikolay Izhikov > Support CDC for in-memory caches > > > Key: IGNITE-15117 > URL: https://issues.apache.org/jira/browse/IGNITE-15117 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-59 > > Right now CDC is supported only for persistent caches. > To support CDC feature for in-memory caches we should support enabling WAL > for in-memory caches. > Only DataRecord is required for CDC so we can write only specific that types > of records to the WAL. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13558) GridCacheProcessor should implement better parallelization when restoring partition states on startup
[
https://issues.apache.org/jira/browse/IGNITE-13558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380498#comment-17380498
]
Ignite TC Bot commented on IGNITE-13558:
{panel:title=Branch: [pull/9243/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9243/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6079240&buildTypeId=IgniteTests24Java8_RunAll]
> GridCacheProcessor should implement better parallelization when restoring
> partition states on startup
> -
>
> Key: IGNITE-13558
> URL: https://issues.apache.org/jira/browse/IGNITE-13558
> Project: Ignite
> Issue Type: Improvement
> Components: persistence
>Reporter: Sergey Chugunov
>Assignee: Denis Chudov
>Priority: Major
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> GridCacheProcessor#restorePartitionStates method tries to employ striped pool
> to restore partition states in parallel but level of parallelization is down
> only to cache group per thread.
> It is not enough and not utilizes resources effectively in case of one cache
> group much bigger than the others.
> We need to parallel restore process down to individual partitions to get the
> most from the available resources and speed up node startup.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-15099) Wrong heartbeat update while waiting for a checkpoint by timeout
[
https://issues.apache.org/jira/browse/IGNITE-15099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-15099:
--
Assignee: Aleksey Plekhanov
> Wrong heartbeat update while waiting for a checkpoint by timeout
>
>
> Key: IGNITE-15099
> URL: https://issues.apache.org/jira/browse/IGNITE-15099
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11, 2.12
>Reporter: Ilya Shishkov
>Assignee: Aleksey Plekhanov
>Priority: Minor
> Labels: ise
> Attachments: Checkpointer_fake_block_master.patch
>
>
> This problem occurs under these conditions:
> * native persistence is turned on
> * failureDetectionTimeout < checkpointFrequency
> * checkpoints are sometimes skipped by timeout (more often, more probable
> the problem occurrence)
> There is a race condition between a listener execution and finishing of a
> pending future (see CheckpointContextImpl#executor body [1]). In some cases
> future can finish before listener closure, therefore updating of a heartbeat
> in listener can occur after call of _blockingSectionBegin_ in
> Checkpointer#waitCheckpointEvent, i.e. after Checkpointer started to wait for
> next checkpoint (see [2]).
> {code:java|title=CheckpointContextImpl#executor}
> @Override public Executor executor() {
> return asyncRunner == null ? null : cmd -> {
> try {
> GridFutureAdapter res = new GridFutureAdapter<>();
> res.listen(fut -> heartbeatUpdater.updateHeartbeat()); //
> Listener is invoked concurrently with pending future finish
> asyncRunner.execute(U.wrapIgniteFuture(cmd, res));
> pendingTaskFuture.add(res);
> }
> catch (RejectedExecutionException e) {
> assert false : "A task should never be rejected by async
> runner";
> }
> };
> }
> {code}
> {code:java|title=Checkpointer#waitCheckpointEvent}
> try {
> synchronized (this) {
> long remaining = U.nanosToMillis(scheduledCp.nextCpNanos -
> System.nanoTime());
> while (remaining > 0 && !isCancelled()) {
> blockingSectionBegin();
> try {
> wait(remaining);
> // At this point and till blockingSectionEnd call heartbeat
> should be equal to Long.MAX_VALUE
> remaining = U.nanosToMillis(scheduledCp.nextCpNanos -
> System.nanoTime());
> }
> finally {
> blockingSectionEnd();
> }
> }
> }
> }
> {code}
>
> If interval between checkpoints (_checkpointFrequency_) is greater than the
> _failureDetectionTimeout_, then update of heartbeat in _blockingSectionEnd_
> may cause an error message in log, because a checkpoint thread is treated as
> blocked (but in fact it was not).
> *Reproducer of problem:* [3]. Even if test was not failed you can see log
> message with incorrect heartbeat after waiting for checkpoint.
>
> Links:
> #
> [CheckpointContextImpl#executor|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/checkpoint/CheckpointContextImpl.java#L104]
> #
> [Checkpointer#waitCheckpointEvent|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/checkpoint/Checkpointer.java#L816]
> # Reproducer: [^Checkpointer_fake_block_master.patch].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-13669) Implement date&time native types
[ https://issues.apache.org/jira/browse/IGNITE-13669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-13669: -- Comment: was deleted (was: Data and date-time types occupy 3 and 7 bytes regarding the Layout. Does it make sense to align them to 4 and 8?) > Implement date&time native types > > > Key: IGNITE-13669 > URL: https://issues.apache.org/jira/browse/IGNITE-13669 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > Fix For: 3.0.0-alpha3 > > Original Estimate: 240h > Remaining Estimate: 240h > > Besides the types themselves, it may be beneficial to provide date/time field > extraction methods so that they can be read without object creation. The > layout is described in the IEP. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14870) Define a mechanism for exchanging discovery metadata
[ https://issues.apache.org/jira/browse/IGNITE-14870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14870: - Description: When a node joins a cluster it needs to send and receive some discovery metadata, for example: # A node might need to provide some credentials and/or some of its configuration values in order to be validated against the state of the cluster. # A node might need to obtain some information about the cluster when accepted into the topology, e.g. addresses of the nodes that host the metastorage. We should develop a mechanism for both sending and receiving some data before a node is accepted into the topology. As a proof of concept it will be enough to receive information about the nodes hosting the metastorage. was: When a node joins a cluster it needs to send and receive some discovery metadata, for example: # A node might need to provide some credentials and/or some of its configuration values in order to be validated against the state of the cluster. # A node might need to obtain some information about the cluster when accepted into the topology, e.g. addresses of the nodes that host the metastorage. We should develop a mechanism for both sending and receiving some data before a node is accepted into the topology. > Define a mechanism for exchanging discovery metadata > > > Key: IGNITE-14870 > URL: https://issues.apache.org/jira/browse/IGNITE-14870 > Project: Ignite > Issue Type: Task > Components: networking >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > > When a node joins a cluster it needs to send and receive some discovery > metadata, for example: > # A node might need to provide some credentials and/or some of its > configuration values in order to be validated against the state of the > cluster. > # A node might need to obtain some information about the cluster when > accepted into the topology, e.g. addresses of the nodes that host the > metastorage. > We should develop a mechanism for both sending and receiving some data before > a node is accepted into the topology. As a proof of concept it will be enough > to receive information about the nodes hosting the metastorage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13669) Implement date&time native types
[ https://issues.apache.org/jira/browse/IGNITE-13669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-13669: - Assignee: Andrey Mashenkov > Implement date&time native types > > > Key: IGNITE-13669 > URL: https://issues.apache.org/jira/browse/IGNITE-13669 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > Fix For: 3.0.0-alpha3 > > Original Estimate: 240h > Remaining Estimate: 240h > > Besides the types themselves, it may be beneficial to provide date/time field > extraction methods so that they can be read without object creation. The > layout is described in the IEP. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14871) Implement a validation protocol for the nodes entering the topology
[ https://issues.apache.org/jira/browse/IGNITE-14871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14871: - Description: When a node enters the cluster, its configuration needs to be validated in order to maintain cluster-wide invariants and to prohibit a non-compatible or malicious node from entering the topology. h2. Possible approaches h3. Remote validation The entering node sends some metadata (e.g. its version) to a random remote node, which validates the metadata and issues the permit for the node to join. *Pros:* * Possibly better security: a malicious node would have to imitate valid requirements. *Cons:* * Harder to maintain backwards compatibility: old nodes need to predict what information a new node might send. h3. Local validation The entering node collects some metadata from a random remote node and decides whether it is able to join the cluster or not. *Pros:* * Easier to maintain backwards-compatibility: a new node knows if older nodes are compatible with it. * Modular validation architecture: each plugin can independently register its cluster state requirements. *Cons:* * Possible security issues: a malicious node can enter the cluster more easily. However, this may be mitigated by signing the handshake messages. was: When a node enters the cluster, its configuration needs to be validated in order to maintain cluster-wide invariants and to prohibit a non-compatible or malicious node from entering the topology. h2. Possible approaches h3. Remote validation The entering node sends some metadata (e.g. its version) to a random remote node, which validates the metadata and issues the permit for the node to join. *Pros:* * ??? *Cons:* * Harder to maintain backwards compatibility: old nodes need to predict what information a new node might send. h3. Local validation The entering node collects some metadata from a random remote node and decides whether it is able to join the cluster or not. *Pros:* * Easier to maintain backwards-compatibility: a new node knows if older nodes are compatible with it. * Modular validation architecture: each plugin can independently register its requirements. *Cons:* * Possible security issues: a malicious node can enter the cluster more easily. However, this may be mitigated by signing the handshake messages. > Implement a validation protocol for the nodes entering the topology > --- > > Key: IGNITE-14871 > URL: https://issues.apache.org/jira/browse/IGNITE-14871 > Project: Ignite > Issue Type: Task > Components: networking >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > > When a node enters the cluster, its configuration needs to be validated in > order to maintain cluster-wide invariants and to prohibit a non-compatible or > malicious node from entering the topology. > h2. Possible approaches > h3. Remote validation > The entering node sends some metadata (e.g. its version) to a random remote > node, which validates the metadata and issues the permit for the node to join. > *Pros:* > * Possibly better security: a malicious node would have to imitate valid > requirements. > *Cons:* > * Harder to maintain backwards compatibility: old nodes need to predict what > information a new node might send. > h3. Local validation > The entering node collects some metadata from a random remote node and > decides whether it is able to join the cluster or not. > *Pros:* > * Easier to maintain backwards-compatibility: a new node knows if older > nodes are compatible with it. > * Modular validation architecture: each plugin can independently register > its cluster state requirements. > *Cons:* > * Possible security issues: a malicious node can enter the cluster more > easily. However, this may be mitigated by signing the handshake messages. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15078) Remove usages of SimpleDateFormat
[
https://issues.apache.org/jira/browse/IGNITE-15078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-15078:
-
Fix Version/s: (was: 2.11)
> Remove usages of SimpleDateFormat
> -
>
> Key: IGNITE-15078
> URL: https://issues.apache.org/jira/browse/IGNITE-15078
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Minor
>
> {{SimpleDateFormat}} is not thread-safe, but is used all over the codebase,
> even in multithreaded context. We should migrate to a more contemporary and
> thread-safe {{DateTimeFormatter}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15119) Use UUID as the ClusterNode ID
[
https://issues.apache.org/jira/browse/IGNITE-15119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-15119:
-
Description: We currently rely on the ScaleCube's cluster member ID, which
is a {{UUID}} converted into a {{String}}. Since UUIDs have more efficient
{{hashCode}} and {{equals}} implementations, it is proposed to convert the
ScaleCube's IDs back into UUIDs inside our {{ClusterNode}} class. (was: We
currently rely on the ScaleCube's cluster member ID, which is a {{UUID
converted into a String. Since UUIDs have more efficient hashCode}} and
{{equals}} implementations, it is proposed to convert the ScaleCube's IDs back
into {{UUIDs inside our ClusterNode}} class.)
> Use UUID as the ClusterNode ID
> --
>
> Key: IGNITE-15119
> URL: https://issues.apache.org/jira/browse/IGNITE-15119
> Project: Ignite
> Issue Type: Task
> Components: networking
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Trivial
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> We currently rely on the ScaleCube's cluster member ID, which is a {{UUID}}
> converted into a {{String}}. Since UUIDs have more efficient {{hashCode}} and
> {{equals}} implementations, it is proposed to convert the ScaleCube's IDs
> back into UUIDs inside our {{ClusterNode}} class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15119) Use UUID as the ClusterNode ID
[
https://issues.apache.org/jira/browse/IGNITE-15119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-15119:
-
Description: We currently rely on the ScaleCube's cluster member ID, which
is a {{UUID converted into a String. Since UUIDs have more efficient hashCode}}
and {{equals}} implementations, it is proposed to convert the ScaleCube's IDs
back into {{UUIDs inside our ClusterNode}} class. (was: We currently rely on
the ScaleCube's cluster member ID, which is a {{UUID }}converted into a{{
String. }}Since {{UUID}}s have more efficient {{hashCode}} and {{equals}}
implementations, it is proposed to convert the ScaleCube's IDs back into
{{UUID}}s inside our {{ClusterNode}} class.)
> Use UUID as the ClusterNode ID
> --
>
> Key: IGNITE-15119
> URL: https://issues.apache.org/jira/browse/IGNITE-15119
> Project: Ignite
> Issue Type: Task
> Components: networking
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Trivial
> Labels: ignite-3
>
> We currently rely on the ScaleCube's cluster member ID, which is a {{UUID
> converted into a String. Since UUIDs have more efficient hashCode}} and
> {{equals}} implementations, it is proposed to convert the ScaleCube's IDs
> back into {{UUIDs inside our ClusterNode}} class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15119) Use UUID as the ClusterNode ID
[
https://issues.apache.org/jira/browse/IGNITE-15119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-15119:
--
Fix Version/s: 3.0.0-alpha3
> Use UUID as the ClusterNode ID
> --
>
> Key: IGNITE-15119
> URL: https://issues.apache.org/jira/browse/IGNITE-15119
> Project: Ignite
> Issue Type: Task
> Components: networking
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Trivial
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> We currently rely on the ScaleCube's cluster member ID, which is a {{UUID
> converted into a String. Since UUIDs have more efficient hashCode}} and
> {{equals}} implementations, it is proposed to convert the ScaleCube's IDs
> back into {{UUIDs inside our ClusterNode}} class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15119) Use UUID as the ClusterNode ID
Aleksandr Polovtcev created IGNITE-15119:
Summary: Use UUID as the ClusterNode ID
Key: IGNITE-15119
URL: https://issues.apache.org/jira/browse/IGNITE-15119
Project: Ignite
Issue Type: Task
Components: networking
Reporter: Aleksandr Polovtcev
Assignee: Aleksandr Polovtcev
We currently rely on the ScaleCube's cluster member ID, which is a {{UUID
}}converted into a{{ String. }}Since {{UUID}}s have more efficient {{hashCode}}
and {{equals}} implementations, it is proposed to convert the ScaleCube's IDs
back into {{UUID}}s inside our {{ClusterNode}} class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15103) Add logging to pyignite client
[
https://issues.apache.org/jira/browse/IGNITE-15103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380466#comment-17380466
]
Igor Sapego commented on IGNITE-15103:
--
[~ivandasch] looks good to me
> Add logging to pyignite client
> --
>
> Key: IGNITE-15103
> URL: https://issues.apache.org/jira/browse/IGNITE-15103
> Project: Ignite
> Issue Type: Improvement
> Components: python, thin client
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Labels: python, thin
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently, there is no logging at all, should be added using {{logging}}
> module
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14968) classnotfoundexception in transaction cache of entryprocessor using annotation
[ https://issues.apache.org/jira/browse/IGNITE-14968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] xingzhou updated IGNITE-14968: -- Reviewer: Alexey Scherbakov (was: Andrew) > classnotfoundexception in transaction cache of entryprocessor using annotation > -- > > Key: IGNITE-14968 > URL: https://issues.apache.org/jira/browse/IGNITE-14968 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.9 >Reporter: xingzhou >Priority: Critical > Fix For: 2.9 > > Attachments: application.log > > Original Estimate: 24h > Time Spent: 10m > Remaining Estimate: 23h 50m > > Recurrence conditions > 1. Transaction cache > 2.backups>0 > 3. Using annotation for entryprocessor > 4. Cluster node > 2 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15118) Add handshake timeout to pyignite client
[
https://issues.apache.org/jira/browse/IGNITE-15118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-15118:
-
Labels: python thin (was: )
> Add handshake timeout to pyignite client
>
>
> Key: IGNITE-15118
> URL: https://issues.apache.org/jira/browse/IGNITE-15118
> Project: Ignite
> Issue Type: Improvement
> Components: python, thin client
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Labels: python, thin
>
> Addition handshake timeout should be added to both {{Client}} and
> {{AioClient}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15118) Add handshake timeout to pyignite client
[
https://issues.apache.org/jira/browse/IGNITE-15118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-15118:
-
Component/s: thin client
python
> Add handshake timeout to pyignite client
>
>
> Key: IGNITE-15118
> URL: https://issues.apache.org/jira/browse/IGNITE-15118
> Project: Ignite
> Issue Type: Improvement
> Components: python, thin client
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
>
> Addition handshake timeout should be added to both {{Client}} and
> {{AioClient}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15118) Add handshake timeout to pyignite client
Ivan Daschinsky created IGNITE-15118:
Summary: Add handshake timeout to pyignite client
Key: IGNITE-15118
URL: https://issues.apache.org/jira/browse/IGNITE-15118
Project: Ignite
Issue Type: Improvement
Reporter: Ivan Daschinsky
Assignee: Ivan Daschinsky
Addition handshake timeout should be added to both {{Client}} and {{AioClient}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
