[jira] [Updated] (IGNITE-22072) Fix the extensions for Custom Metrics
[ https://issues.apache.org/jira/browse/IGNITE-22072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22072: -- Labels: ise (was: ) > Fix the extensions for Custom Metrics > - > > Key: IGNITE-22072 > URL: https://issues.apache.org/jira/browse/IGNITE-22072 > Project: Ignite > Issue Type: Task >Reporter: Vladimir Steshin >Priority: Critical > Labels: ise > > The custom metrics expose new public _MetricRegistry_, renames internal > _MetricRegistry_->_MetricRegistryImpl_ and changes imports/API of > _CdcConsumer_. The related code won't compile. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22072) Fix the extensions for Custom Metrics
[ https://issues.apache.org/jira/browse/IGNITE-22072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22072: -- Summary: Fix the extensions for Custom Metrics (was: Fix the extensions for CustomMetrics) > Fix the extensions for Custom Metrics > - > > Key: IGNITE-22072 > URL: https://issues.apache.org/jira/browse/IGNITE-22072 > Project: Ignite > Issue Type: Task >Reporter: Vladimir Steshin >Priority: Critical > > The custom metrics expose new public _MetricRegistry_, renames internal > _MetricRegistry_->_MetricRegistryImpl_ and changes imports/API of > _CdcConsumer_. The related code won't compile. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22072) Fix the extensions for CustomMetrics
Vladimir Steshin created IGNITE-22072: - Summary: Fix the extensions for CustomMetrics Key: IGNITE-22072 URL: https://issues.apache.org/jira/browse/IGNITE-22072 Project: Ignite Issue Type: Task Reporter: Vladimir Steshin The custom metrics expose new public _MetricRegistry_, renames internal _MetricRegistry_->_MetricRegistryImpl_ and changes imports/API of _CdcConsumer_. The related code won't compile. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15616) Calcite. Failed to parse UPDATE query.
[
https://issues.apache.org/jira/browse/IGNITE-15616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-15616:
--
Description:
Seems we need to support DEFAULT in Parser.jj or extend it
{noformat}
SqlNode SqlUpdate() :
...
id = SimpleIdentifier() {
targetColumnList.add(id);
}
// TODO: support DEFAULT also
{noformat}
{noformat}
statement ok
UPDATE integers i1 SET i=DEFAULT WHERE i=(SELECT MIN(i) FROM integers WHERE
i1.id id = SimpleIdentifier() {
targetColumnList.add(id);
}
// TODO: support DEFAULT also
{noformat}
{noformat}
statement ok
UPDATE integers i1 SET i=DEFAULT WHERE i=(SELECT MIN(i) FROM integers WHERE
i1.id Calcite. Failed to parse UPDATE query.
> --
>
> Key: IGNITE-15616
> URL: https://issues.apache.org/jira/browse/IGNITE-15616
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeny Stanilovsky
>Priority: Minor
> Labels: calcite, ignite-3
>
> Seems we need to support DEFAULT in Parser.jj or extend it
> {noformat}
> SqlNode SqlUpdate() :
> ...
> id = SimpleIdentifier() {
> targetColumnList.add(id);
> }
> // TODO: support DEFAULT also
> {noformat}
>
> {noformat}
> statement ok
> UPDATE integers i1 SET i=DEFAULT WHERE i=(SELECT MIN(i) FROM integers WHERE
> i1.id query II
> SELECT id, i FROM integers ORDER BY id
>
> 1 NULL
> 2 NULL
> 3 2
> 4 3
> {noformat}
> {noformat}
> Statement [queries=ArrayList [UPDATE integers i1 SET i=DEFAULT WHERE
> i=(SELECT MIN(i) FROM integers WHERE i1.id at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Statement.execute(SqlScriptRunner.java:404)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.run(SqlScriptRunner.java:115)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.ScriptTestRunner$1.run(ScriptTestRunner.java:219)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> parse query.
> at
> org.apache.ignite.internal.processors.query.calcite.util.Commons.parse(Commons.java:205)
> {noformat}
> {noformat}
> /subquery/scalar/test_update_subquery.test[_ignore]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22020) DumpReder misses 'keepRaw' parameter
[ https://issues.apache.org/jira/browse/IGNITE-22020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22020: -- Labels: ise (was: ) > DumpReder misses 'keepRaw' parameter > > > Key: IGNITE-22020 > URL: https://issues.apache.org/jira/browse/IGNITE-22020 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 10m > Remaining Estimate: 0h > > `DumpReaderConfiguration` and `DumpReder` do not use `raw` parameter. Only > `keepBinary` is available. It makes impossible to read data as > `KeyCacheObject` or `CacheObject` . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22020) DumpReder misses 'keepRaw' parameter
[ https://issues.apache.org/jira/browse/IGNITE-22020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-22020: - Assignee: Vladimir Steshin > DumpReder misses 'keepRaw' parameter > > > Key: IGNITE-22020 > URL: https://issues.apache.org/jira/browse/IGNITE-22020 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 10m > Remaining Estimate: 0h > > `DumpReaderConfiguration` and `DumpReder` do not use `raw` parameter. Only > `keepBinary` is available. It makes impossible to read data as > `KeyCacheObject` or `CacheObject` . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22020) DumpReder misses 'keepRaw' parameter
[ https://issues.apache.org/jira/browse/IGNITE-22020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22020: -- Fix Version/s: 2.17 > DumpReder misses 'keepRaw' parameter > > > Key: IGNITE-22020 > URL: https://issues.apache.org/jira/browse/IGNITE-22020 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Priority: Major > Fix For: 2.17 > > Time Spent: 10m > Remaining Estimate: 0h > > `DumpReaderConfiguration` and `DumpReder` do not use `raw` parameter. Only > `keepBinary` is available. It makes impossible to read data as > `KeyCacheObject` or `CacheObject` . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22020) DumpReder misses 'keepRaw' parameter
[ https://issues.apache.org/jira/browse/IGNITE-22020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22020: -- Issue Type: Improvement (was: Bug) > DumpReder misses 'keepRaw' parameter > > > Key: IGNITE-22020 > URL: https://issues.apache.org/jira/browse/IGNITE-22020 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Priority: Major > > `DumpReaderConfiguration` and `DumpReder` do not use `raw` parameter. Only > `keepBinary` is available. It makes impossible to read data as > `KeyCacheObject` or `CacheObject` . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22020) DumpReder misses 'keepRaw' parameter
Vladimir Steshin created IGNITE-22020: - Summary: DumpReder misses 'keepRaw' parameter Key: IGNITE-22020 URL: https://issues.apache.org/jira/browse/IGNITE-22020 Project: Ignite Issue Type: Bug Reporter: Vladimir Steshin `DumpReaderConfiguration` and `DumpReder` do not use `raw` parameter. Only `keepBinary` is available. It makes impossible to read data as `KeyCacheObject` or `CacheObject` . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21656) Cache dump fails on a cache with a node filter.
[
https://issues.apache.org/jira/browse/IGNITE-21656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21656:
--
Fix Version/s: 2.17
> Cache dump fails on a cache with a node filter.
> ---
>
> Key: IGNITE-21656
> URL: https://issues.apache.org/jira/browse/IGNITE-21656
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Ignite may fail to create dump of cache with a node filter.
> 1) If there are no partitions on some node, we assign the empty set as the
> snapshot task result:
> {code:java}
> if (parts.isEmpty() && !withMetaStorage)
> task0 = new GridFinishedFuture<>(Collections.emptySet());
> else {
> ...
> }
> {code}
> Cache dump doesn't contain the metastorage. Further, we may cast the result to
> {code:java}
> SnapshotFutureTaskResult res = (SnapshotFutureTaskResult)task0.result();
> {code}
> but it is a
> {code:java}
> Collections#EMPTY_SET
> {code}
> Stacktrace:
> {code:java}
> [ERROR][snapshot-runner-#413%dump.IgniteCacheDumpSelfTest0%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=CRITICAL_ERROR, err=java.lang.ClassCastException: class
> java.util.Collections$EmptySet cannot be cast to class
> o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
> (java.util.Collections$EmptySet is in module java.base of loader 'bootstrap';
> o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult is in
> unnamed module of loader 'app')]]
> java.lang.ClassCastException: class java.util.Collections$EmptySet cannot be
> cast to class
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
> (java.util.Collections$EmptySet is in module java.base of loader
> 'bootstrap';
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
> is in unnamed module of loader 'app')
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager.lambda$initLocalFullSnapshot$923db49$1(IgniteSnapshotManager.java:1221)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$d8c8d23e$1(GridFinishedFuture.java:180)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$0(GridFinishedFuture.java:163)
> ~[classes/:?]
> {code}
> 2) Even we fix the cast, another failure may arise. If cache with node filter
> was created by a client or not by the excluded node (or may be not from the
> coordinator), the dump content may be checked before anything is written.
> {code:java}
> Caused by: class org.apache.ignite.IgniteException: Ouch! Argument is
> invalid: binary metadata directory not exists
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsVerifyHandler.checkDumpFiles(SnapshotPartitionsVerifyHandler.java:382)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsVerifyHandler.invoke(SnapshotPartitionsVerifyHandler.java:183)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsQuickVerifyHandler.invoke(SnapshotPartitionsQuickVerifyHandler.java:62)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsQuickVerifyHandler.invoke(SnapshotPartitionsQuickVerifyHandler.java:37)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.invoke(IgniteSnapshotManager.java:3396)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.lambda$invokeAll$8d56ceed$1(IgniteSnapshotManager.java:3328)
> at
> org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11715)
> at
> org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11617)
> at
> org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11597)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.invokeAll(IgniteSnapshotManager.java:3325)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager.lambda$initLocalFullSnapshot$923db49$1(IgniteSnapshotManager.java:1254)
> at
> org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$d8c8d23e$1(GridFinishedFuture.java:180)
> at
>
[jira] [Assigned] (IGNITE-21656) Cache dump fails on a cache with a node filter.
[
https://issues.apache.org/jira/browse/IGNITE-21656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin reassigned IGNITE-21656:
-
Assignee: Vladimir Steshin
> Cache dump fails on a cache with a node filter.
> ---
>
> Key: IGNITE-21656
> URL: https://issues.apache.org/jira/browse/IGNITE-21656
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: ise
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Ignite may fail to create dump of cache with a node filter.
> 1) If there are no partitions on some node, we assign the empty set as the
> snapshot task result:
> {code:java}
> if (parts.isEmpty() && !withMetaStorage)
> task0 = new GridFinishedFuture<>(Collections.emptySet());
> else {
> ...
> }
> {code}
> Cache dump doesn't contain the metastorage. Further, we may cast the result to
> {code:java}
> SnapshotFutureTaskResult res = (SnapshotFutureTaskResult)task0.result();
> {code}
> but it is a
> {code:java}
> Collections#EMPTY_SET
> {code}
> Stacktrace:
> {code:java}
> [ERROR][snapshot-runner-#413%dump.IgniteCacheDumpSelfTest0%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=CRITICAL_ERROR, err=java.lang.ClassCastException: class
> java.util.Collections$EmptySet cannot be cast to class
> o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
> (java.util.Collections$EmptySet is in module java.base of loader 'bootstrap';
> o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult is in
> unnamed module of loader 'app')]]
> java.lang.ClassCastException: class java.util.Collections$EmptySet cannot be
> cast to class
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
> (java.util.Collections$EmptySet is in module java.base of loader
> 'bootstrap';
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
> is in unnamed module of loader 'app')
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager.lambda$initLocalFullSnapshot$923db49$1(IgniteSnapshotManager.java:1221)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$d8c8d23e$1(GridFinishedFuture.java:180)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$0(GridFinishedFuture.java:163)
> ~[classes/:?]
> {code}
> 2) Even we fix the cast, another failure may arise. If cache with node filter
> was created by a client or not by the excluded node (or may be not from the
> coordinator), the dump content may be checked before anything is written.
> {code:java}
> Caused by: class org.apache.ignite.IgniteException: Ouch! Argument is
> invalid: binary metadata directory not exists
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsVerifyHandler.checkDumpFiles(SnapshotPartitionsVerifyHandler.java:382)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsVerifyHandler.invoke(SnapshotPartitionsVerifyHandler.java:183)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsQuickVerifyHandler.invoke(SnapshotPartitionsQuickVerifyHandler.java:62)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsQuickVerifyHandler.invoke(SnapshotPartitionsQuickVerifyHandler.java:37)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.invoke(IgniteSnapshotManager.java:3396)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.lambda$invokeAll$8d56ceed$1(IgniteSnapshotManager.java:3328)
> at
> org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11715)
> at
> org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11617)
> at
> org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11597)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.invokeAll(IgniteSnapshotManager.java:3325)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager.lambda$initLocalFullSnapshot$923db49$1(IgniteSnapshotManager.java:1254)
> at
> org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$d8c8d23e$1(GridFinishedFuture.java:180)
> at
>
[jira] [Updated] (IGNITE-21636) Code cleanup
[ https://issues.apache.org/jira/browse/IGNITE-21636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21636: -- Fix Version/s: 2.17 > Code cleanup > > > Key: IGNITE-21636 > URL: https://issues.apache.org/jira/browse/IGNITE-21636 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Trivial > Fix For: 2.17 > > Time Spent: 10m > Remaining Estimate: 0h > > Removing of unused 'mvccEnabled', codestyle fixex, +abbreviations, finals and > etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21636) Code cleanup
[ https://issues.apache.org/jira/browse/IGNITE-21636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21636: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Code cleanup > > > Key: IGNITE-21636 > URL: https://issues.apache.org/jira/browse/IGNITE-21636 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Trivial > Fix For: 2.17 > > Time Spent: 10m > Remaining Estimate: 0h > > Removing of unused 'mvccEnabled', codestyle fixex, +abbreviations, finals and > etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21636) Code cleanup
[ https://issues.apache.org/jira/browse/IGNITE-21636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-21636: - Assignee: Vladimir Steshin > Code cleanup > > > Key: IGNITE-21636 > URL: https://issues.apache.org/jira/browse/IGNITE-21636 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Trivial > Time Spent: 10m > Remaining Estimate: 0h > > Removing of unused 'mvccEnabled', codestyle fixex, +abbreviations, finals and > etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21656) Cache dump fails on a cache with a node filter.
[
https://issues.apache.org/jira/browse/IGNITE-21656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21656:
--
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Cache dump fails on a cache with a node filter.
> ---
>
> Key: IGNITE-21656
> URL: https://issues.apache.org/jira/browse/IGNITE-21656
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ignite may fail to create dump of cache with a node filter.
> 1) If there are no partitions on some node, we assign the empty set as the
> snapshot task result:
> {code:java}
> if (parts.isEmpty() && !withMetaStorage)
> task0 = new GridFinishedFuture<>(Collections.emptySet());
> else {
> ...
> }
> {code}
> Cache dump doesn't contain the metastorage. Further, we may cast the result to
> {code:java}
> SnapshotFutureTaskResult res = (SnapshotFutureTaskResult)task0.result();
> {code}
> but it is a
> {code:java}
> Collections#EMPTY_SET
> {code}
> Stacktrace:
> {code:java}
> [ERROR][snapshot-runner-#413%dump.IgniteCacheDumpSelfTest0%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=CRITICAL_ERROR, err=java.lang.ClassCastException: class
> java.util.Collections$EmptySet cannot be cast to class
> o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
> (java.util.Collections$EmptySet is in module java.base of loader 'bootstrap';
> o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult is in
> unnamed module of loader 'app')]]
> java.lang.ClassCastException: class java.util.Collections$EmptySet cannot be
> cast to class
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
> (java.util.Collections$EmptySet is in module java.base of loader
> 'bootstrap';
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
> is in unnamed module of loader 'app')
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager.lambda$initLocalFullSnapshot$923db49$1(IgniteSnapshotManager.java:1221)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$d8c8d23e$1(GridFinishedFuture.java:180)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$0(GridFinishedFuture.java:163)
> ~[classes/:?]
> {code}
> 2) Even we fix the cast, another failure may arise. If cache with node filter
> was created by a client or not by the excluded node (or may be not from the
> coordinator), the dump content may be checked before anything is written.
> {code:java}
> Caused by: class org.apache.ignite.IgniteException: Ouch! Argument is
> invalid: binary metadata directory not exists
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsVerifyHandler.checkDumpFiles(SnapshotPartitionsVerifyHandler.java:382)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsVerifyHandler.invoke(SnapshotPartitionsVerifyHandler.java:183)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsQuickVerifyHandler.invoke(SnapshotPartitionsQuickVerifyHandler.java:62)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsQuickVerifyHandler.invoke(SnapshotPartitionsQuickVerifyHandler.java:37)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.invoke(IgniteSnapshotManager.java:3396)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.lambda$invokeAll$8d56ceed$1(IgniteSnapshotManager.java:3328)
> at
> org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11715)
> at
> org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11617)
> at
> org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11597)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.invokeAll(IgniteSnapshotManager.java:3325)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager.lambda$initLocalFullSnapshot$923db49$1(IgniteSnapshotManager.java:1254)
> at
> org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$d8c8d23e$1(GridFinishedFuture.java:180)
> at
>
[jira] [Updated] (IGNITE-21656) Cache dump fails on a cache with a node filter.
[
https://issues.apache.org/jira/browse/IGNITE-21656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21656:
--
Description:
Ignite may fail to create dump of cache with a node filter.
1) If there are no partitions on some node, we assign the empty set as the
snapshot task result:
{code:java}
if (parts.isEmpty() && !withMetaStorage)
task0 = new GridFinishedFuture<>(Collections.emptySet());
else {
...
}
{code}
Cache dump doesn't contain the metastorage. Further, we may cast the result to
{code:java}
SnapshotFutureTaskResult res = (SnapshotFutureTaskResult)task0.result();
{code}
but it is a
{code:java}
Collections#EMPTY_SET
{code}
Stacktrace:
{code:java}
[ERROR][snapshot-runner-#413%dump.IgniteCacheDumpSelfTest0%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
[type=CRITICAL_ERROR, err=java.lang.ClassCastException: class
java.util.Collections$EmptySet cannot be cast to class
o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
(java.util.Collections$EmptySet is in module java.base of loader 'bootstrap';
o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult is in
unnamed module of loader 'app')]]
java.lang.ClassCastException: class java.util.Collections$EmptySet cannot be
cast to class
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
(java.util.Collections$EmptySet is in module java.base of loader 'bootstrap';
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
is in unnamed module of loader 'app')
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager.lambda$initLocalFullSnapshot$923db49$1(IgniteSnapshotManager.java:1221)
~[classes/:?]
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$d8c8d23e$1(GridFinishedFuture.java:180)
~[classes/:?]
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$0(GridFinishedFuture.java:163)
~[classes/:?]
{code}
2) Even we fix the cast, another failure may arise. If cache with node filter
was created by a client or not by the excluded node (or may be not from the
coordinator), the dump content may be checked before anything is written.
{code:java}
Caused by: class org.apache.ignite.IgniteException: Ouch! Argument is invalid:
binary metadata directory not exists
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsVerifyHandler.checkDumpFiles(SnapshotPartitionsVerifyHandler.java:382)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsVerifyHandler.invoke(SnapshotPartitionsVerifyHandler.java:183)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsQuickVerifyHandler.invoke(SnapshotPartitionsQuickVerifyHandler.java:62)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsQuickVerifyHandler.invoke(SnapshotPartitionsQuickVerifyHandler.java:37)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.invoke(IgniteSnapshotManager.java:3396)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.lambda$invokeAll$8d56ceed$1(IgniteSnapshotManager.java:3328)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11715)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11617)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11597)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.invokeAll(IgniteSnapshotManager.java:3325)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager.lambda$initLocalFullSnapshot$923db49$1(IgniteSnapshotManager.java:1254)
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$d8c8d23e$1(GridFinishedFuture.java:180)
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$0(GridFinishedFuture.java:163)
... 3 more
Caused by: java.lang.IllegalArgumentException: Ouch! Argument is invalid:
binary metadata directory not exists
at
org.apache.ignite.internal.util.GridArgumentCheck.ensure(GridArgumentCheck.java:110)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.dump.Dump.standaloneKernalContext(Dump.java:169)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.dump.Dump.(Dump.java:149)
at
[jira] [Updated] (IGNITE-21656) Cache dump fails on a cache with a node filter.
[
https://issues.apache.org/jira/browse/IGNITE-21656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21656:
--
Description:
Ignite may fail to create dump of cache with a node filter.
1) If there are no partitions on some node, we assign the empty set as the
snapshot task result:
{code:java}
if (parts.isEmpty() && !withMetaStorage)
task0 = new GridFinishedFuture<>(Collections.emptySet());
else {
...
}
{code}
Cache dump doesn't contain the metastorage. Further, we may cast the result to
{code:java}
SnapshotFutureTaskResult res = (SnapshotFutureTaskResult)task0.result();
{code}
but it is a
{code:java}
Collections#EMPTY_SET
{code}
Stacktrace:
{code:java}
[ERROR][snapshot-runner-#413%dump.IgniteCacheDumpSelfTest0%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
[type=CRITICAL_ERROR, err=java.lang.ClassCastException: class
java.util.Collections$EmptySet cannot be cast to class
o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
(java.util.Collections$EmptySet is in module java.base of loader 'bootstrap';
o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult is in
unnamed module of loader 'app')]]
java.lang.ClassCastException: class java.util.Collections$EmptySet cannot be
cast to class
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
(java.util.Collections$EmptySet is in module java.base of loader 'bootstrap';
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
is in unnamed module of loader 'app')
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager.lambda$initLocalFullSnapshot$923db49$1(IgniteSnapshotManager.java:1221)
~[classes/:?]
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$d8c8d23e$1(GridFinishedFuture.java:180)
~[classes/:?]
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$0(GridFinishedFuture.java:163)
~[classes/:?]
{code}
2) Even we fix the cast, another failure may arise. If cache with node filter
was created by a client or not by the excluded node (or may be not from the
coordinator), it may be checked before any dump data are written.
{code:java}
Caused by: class org.apache.ignite.IgniteException: Ouch! Argument is invalid:
binary metadata directory not exists
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsVerifyHandler.checkDumpFiles(SnapshotPartitionsVerifyHandler.java:382)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsVerifyHandler.invoke(SnapshotPartitionsVerifyHandler.java:183)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsQuickVerifyHandler.invoke(SnapshotPartitionsQuickVerifyHandler.java:62)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsQuickVerifyHandler.invoke(SnapshotPartitionsQuickVerifyHandler.java:37)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.invoke(IgniteSnapshotManager.java:3396)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.lambda$invokeAll$8d56ceed$1(IgniteSnapshotManager.java:3328)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11715)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11617)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11597)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.invokeAll(IgniteSnapshotManager.java:3325)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager.lambda$initLocalFullSnapshot$923db49$1(IgniteSnapshotManager.java:1254)
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$d8c8d23e$1(GridFinishedFuture.java:180)
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$0(GridFinishedFuture.java:163)
... 3 more
Caused by: java.lang.IllegalArgumentException: Ouch! Argument is invalid:
binary metadata directory not exists
at
org.apache.ignite.internal.util.GridArgumentCheck.ensure(GridArgumentCheck.java:110)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.dump.Dump.standaloneKernalContext(Dump.java:169)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.dump.Dump.(Dump.java:149)
at
[jira] [Updated] (IGNITE-21656) Cache dump fails on a cache with a node filter.
[
https://issues.apache.org/jira/browse/IGNITE-21656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21656:
--
Priority: Major (was: Minor)
> Cache dump fails on a cache with a node filter.
> ---
>
> Key: IGNITE-21656
> URL: https://issues.apache.org/jira/browse/IGNITE-21656
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ignite may fail to create dump of cache with a node filter.
> 1) If there are no partitions on some node, we assign the empty set as the
> snapshot task result:
> {code:java}
> if (parts.isEmpty() && !withMetaStorage)
> task0 = new GridFinishedFuture<>(Collections.emptySet());
> else {
> ...
> }
> {code}
> Cache dump doesn't contain the metastorage. Further, we may cast the result to
> {code:java}
> SnapshotFutureTaskResult res = (SnapshotFutureTaskResult)task0.result();
> {code}
> but it is a
> {code:java}
> Collections#EMPTY_SET
> {code}
> Stacktrace:
> {code:java}
> [ERROR][snapshot-runner-#413%dump.IgniteCacheDumpSelfTest0%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=CRITICAL_ERROR, err=java.lang.ClassCastException: class
> java.util.Collections$EmptySet cannot be cast to class
> o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
> (java.util.Collections$EmptySet is in module java.base of loader 'bootstrap';
> o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult is in
> unnamed module of loader 'app')]]
> java.lang.ClassCastException: class java.util.Collections$EmptySet cannot be
> cast to class
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
> (java.util.Collections$EmptySet is in module java.base of loader
> 'bootstrap';
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
> is in unnamed module of loader 'app')
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager.lambda$initLocalFullSnapshot$923db49$1(IgniteSnapshotManager.java:1221)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$d8c8d23e$1(GridFinishedFuture.java:180)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$0(GridFinishedFuture.java:163)
> ~[classes/:?]
> {code}
> 2) Even we fix the cast, further failure appears:
> {code:java}
> private GridKernalContext standaloneKernalContext(File dumpDir, IgniteLogger
> log) {
> File binaryMeta =
> CacheObjectBinaryProcessorImpl.binaryWorkDir(dumpDir.getAbsolutePath(),
> F.first(metadata).folderName());
> File marshaller = new File(dumpDir, DFLT_MARSHALLER_PATH);
> A.ensure(binaryMeta.exists(), "binary metadata directory not exists");
> {code}
> If cache with node filter was created by a client or not by the excluded node
> (or may be not from the coordinator), it may be checked before any dump data
> are written.
> Stacktrace:
> {code:java}
> Caused by: class org.apache.ignite.IgniteException: Ouch! Argument is
> invalid: binary metadata directory not exists
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsVerifyHandler.checkDumpFiles(SnapshotPartitionsVerifyHandler.java:382)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsVerifyHandler.invoke(SnapshotPartitionsVerifyHandler.java:183)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsQuickVerifyHandler.invoke(SnapshotPartitionsQuickVerifyHandler.java:62)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsQuickVerifyHandler.invoke(SnapshotPartitionsQuickVerifyHandler.java:37)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.invoke(IgniteSnapshotManager.java:3396)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.lambda$invokeAll$8d56ceed$1(IgniteSnapshotManager.java:3328)
> at
> org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11715)
> at
> org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11617)
> at
> org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11597)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.invokeAll(IgniteSnapshotManager.java:3325)
[jira] [Updated] (IGNITE-21656) Cache dump fails on a cache with a node filter.
[
https://issues.apache.org/jira/browse/IGNITE-21656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21656:
--
Description:
Ignite may fail to create dump of cache with a node filter.
1) If there are no partitions on some node, we assign the empty set as the
snapshot task result:
{code:java}
if (parts.isEmpty() && !withMetaStorage)
task0 = new GridFinishedFuture<>(Collections.emptySet());
else {
...
}
{code}
Cache dump doesn't contain the metastorage. Further, we may cast the result to
{code:java}
SnapshotFutureTaskResult res = (SnapshotFutureTaskResult)task0.result();
{code}
but it is a
{code:java}
Collections#EMPTY_SET
{code}
Stacktrace:
{code:java}
[ERROR][snapshot-runner-#413%dump.IgniteCacheDumpSelfTest0%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
[type=CRITICAL_ERROR, err=java.lang.ClassCastException: class
java.util.Collections$EmptySet cannot be cast to class
o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
(java.util.Collections$EmptySet is in module java.base of loader 'bootstrap';
o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult is in
unnamed module of loader 'app')]]
java.lang.ClassCastException: class java.util.Collections$EmptySet cannot be
cast to class
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
(java.util.Collections$EmptySet is in module java.base of loader 'bootstrap';
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
is in unnamed module of loader 'app')
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager.lambda$initLocalFullSnapshot$923db49$1(IgniteSnapshotManager.java:1221)
~[classes/:?]
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$d8c8d23e$1(GridFinishedFuture.java:180)
~[classes/:?]
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$0(GridFinishedFuture.java:163)
~[classes/:?]
{code}
2) Even we fix the cast, further failure appears:
{code:java}
private GridKernalContext standaloneKernalContext(File dumpDir, IgniteLogger
log) {
File binaryMeta =
CacheObjectBinaryProcessorImpl.binaryWorkDir(dumpDir.getAbsolutePath(),
F.first(metadata).folderName());
File marshaller = new File(dumpDir, DFLT_MARSHALLER_PATH);
A.ensure(binaryMeta.exists(), "binary metadata directory not exists");
{code}
If cache with node filter was created by a client or not by the excluded node
(or may be not from the coordinator), it may be checked before any dump data
are written.
Stacktrace:
{code:java}
Caused by: class org.apache.ignite.IgniteException: Ouch! Argument is invalid:
binary metadata directory not exists
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsVerifyHandler.checkDumpFiles(SnapshotPartitionsVerifyHandler.java:382)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsVerifyHandler.invoke(SnapshotPartitionsVerifyHandler.java:183)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsQuickVerifyHandler.invoke(SnapshotPartitionsQuickVerifyHandler.java:62)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsQuickVerifyHandler.invoke(SnapshotPartitionsQuickVerifyHandler.java:37)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.invoke(IgniteSnapshotManager.java:3396)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.lambda$invokeAll$8d56ceed$1(IgniteSnapshotManager.java:3328)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11715)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11617)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11597)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.invokeAll(IgniteSnapshotManager.java:3325)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager.lambda$initLocalFullSnapshot$923db49$1(IgniteSnapshotManager.java:1254)
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$d8c8d23e$1(GridFinishedFuture.java:180)
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$0(GridFinishedFuture.java:163)
... 3 more
Caused by: java.lang.IllegalArgumentException: Ouch! Argument is invalid:
binary metadata directory not exists
at
org.apache.ignite.internal.util.GridArgumentCheck.ensure(GridArgumentCheck.java:110)
at
[jira] [Updated] (IGNITE-21656) Cache dump fails on a cache with a node filter.
[
https://issues.apache.org/jira/browse/IGNITE-21656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21656:
--
Labels: ise (was: )
> Cache dump fails on a cache with a node filter.
> ---
>
> Key: IGNITE-21656
> URL: https://issues.apache.org/jira/browse/IGNITE-21656
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Minor
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ignite may fail to create dump of cache with a node filter.
> 1) If there are no partitions on some node, we assign the empty set as the
> snapshot task result:
> {code:java}
> if (parts.isEmpty() && !withMetaStorage)
> task0 = new GridFinishedFuture<>(Collections.emptySet());
> else {
> ...
> }
> {code}
> Cache dump doesn't contain the metastorage. Further, we may cast the result to
> {code:java}
> SnapshotFutureTaskResult res = (SnapshotFutureTaskResult)task0.result();
> {code}
> but it is a
> {code:java}
> Collections#EMPTY_SET
> {code}
> Stacktrace:
> {code:java}
> [ERROR][snapshot-runner-#413%dump.IgniteCacheDumpSelfTest0%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=CRITICAL_ERROR, err=java.lang.ClassCastException: class
> java.util.Collections$EmptySet cannot be cast to class
> o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
> (java.util.Collections$EmptySet is in module java.base of loader 'bootstrap';
> o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult is in
> unnamed module of loader 'app')]]
> java.lang.ClassCastException: class java.util.Collections$EmptySet cannot be
> cast to class
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
> (java.util.Collections$EmptySet is in module java.base of loader
> 'bootstrap';
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
> is in unnamed module of loader 'app')
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager.lambda$initLocalFullSnapshot$923db49$1(IgniteSnapshotManager.java:1221)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$d8c8d23e$1(GridFinishedFuture.java:180)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$0(GridFinishedFuture.java:163)
> ~[classes/:?]
> {code}
> 2) Even we fix the cast, further failure appears:
> {code:java}
> private GridKernalContext standaloneKernalContext(File dumpDir, IgniteLogger
> log) {
> File binaryMeta =
> CacheObjectBinaryProcessorImpl.binaryWorkDir(dumpDir.getAbsolutePath(),
> F.first(metadata).folderName());
> File marshaller = new File(dumpDir, DFLT_MARSHALLER_PATH);
> A.ensure(binaryMeta.exists(), "binary metadata directory not exists");
> {code}
> If cache with node filter was created by a client or not by the excluded node
> (or may be not from the coordinator), it may be checked before any dump data
> are written.
> Stacktrace:
> {code:java}
> Caused by: class org.apache.ignite.IgniteException: Ouch! Argument is
> invalid: binary metadata directory not exists
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsVerifyHandler.checkDumpFiles(SnapshotPartitionsVerifyHandler.java:382)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsVerifyHandler.invoke(SnapshotPartitionsVerifyHandler.java:183)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsQuickVerifyHandler.invoke(SnapshotPartitionsQuickVerifyHandler.java:62)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsQuickVerifyHandler.invoke(SnapshotPartitionsQuickVerifyHandler.java:37)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.invoke(IgniteSnapshotManager.java:3396)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.lambda$invokeAll$8d56ceed$1(IgniteSnapshotManager.java:3328)
> at
> org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11715)
> at
> org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11617)
> at
> org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11597)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.invokeAll(IgniteSnapshotManager.java:3325)
> at
>
[jira] [Updated] (IGNITE-21162) Use table SQL hints
[
https://issues.apache.org/jira/browse/IGNITE-21162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21162:
--
Release Note: Calcite SQL hints are now available at tables. (was: SQL
hints are now available at tables.)
> Use table SQL hints
> ---
>
> Key: IGNITE-21162
> URL: https://issues.apache.org/jira/browse/IGNITE-21162
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Calcite parses and creates hints for 2 SQL nodes:
> 1) For SqlKind.SELECT в SqlToRelConverter.convertQuery() /
> SqlToRelConverter.convertSelectImpl()
> 2) For SqlKind.TABLE_REF in SqlToRelConverter.convertFrom() . Here a hint
> comes directly to a table / table scan
> Currently, we skip #2 in _IgniteTable.toRel()_ not using
> _RelOptTable.ToRelContext.getTableHints()_ . This would allow to set hints
> more precisely:
> {code:sql}
> SELECT T1.V1, T2.V2 FROM TBL1 T1 JOIN TBL2 /*+ FORCE_INDEX(TBL2_IDX2) */ T2
> on T1.V3=T2.V3 and T1.V2=T2.V2 WHERE T2.V1 = ?;
> {code}
> or
> {code:sql}
> SELECT T1.V1, T2.V2 FROM TBL1 T1 JOIN TBL2 /*+ MERGE_JOIN */ T2 on
> T1.V3=T2.V3 and T1.V2=T2.V2 WHERE T2.V1 = ?;
> {code}
> MIght be useful int sub-queries or when aliases are used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21162) Use table SQL hints
[
https://issues.apache.org/jira/browse/IGNITE-21162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21162:
--
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Use table SQL hints
> ---
>
> Key: IGNITE-21162
> URL: https://issues.apache.org/jira/browse/IGNITE-21162
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Calcite parses and creates hints for 2 SQL nodes:
> 1) For SqlKind.SELECT в SqlToRelConverter.convertQuery() /
> SqlToRelConverter.convertSelectImpl()
> 2) For SqlKind.TABLE_REF in SqlToRelConverter.convertFrom() . Here a hint
> comes directly to a table / table scan
> Currently, we skip #2 in _IgniteTable.toRel()_ not using
> _RelOptTable.ToRelContext.getTableHints()_ . This would allow to set hints
> more precisely:
> {code:sql}
> SELECT T1.V1, T2.V2 FROM TBL1 T1 JOIN TBL2 /*+ FORCE_INDEX(TBL2_IDX2) */ T2
> on T1.V3=T2.V3 and T1.V2=T2.V2 WHERE T2.V1 = ?;
> {code}
> or
> {code:sql}
> SELECT T1.V1, T2.V2 FROM TBL1 T1 JOIN TBL2 /*+ MERGE_JOIN */ T2 on
> T1.V3=T2.V3 and T1.V2=T2.V2 WHERE T2.V1 = ?;
> {code}
> MIght be useful int sub-queries or when aliases are used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21162) Use table SQL hints
[
https://issues.apache.org/jira/browse/IGNITE-21162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21162:
--
Release Note: SQL hints are now available at tables.
> Use table SQL hints
> ---
>
> Key: IGNITE-21162
> URL: https://issues.apache.org/jira/browse/IGNITE-21162
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Calcite parses and creates hints for 2 SQL nodes:
> 1) For SqlKind.SELECT в SqlToRelConverter.convertQuery() /
> SqlToRelConverter.convertSelectImpl()
> 2) For SqlKind.TABLE_REF in SqlToRelConverter.convertFrom() . Here a hint
> comes directly to a table / table scan
> Currently, we skip #2 in _IgniteTable.toRel()_ not using
> _RelOptTable.ToRelContext.getTableHints()_ . This would allow to set hints
> more precisely:
> {code:sql}
> SELECT T1.V1, T2.V2 FROM TBL1 T1 JOIN TBL2 /*+ FORCE_INDEX(TBL2_IDX2) */ T2
> on T1.V3=T2.V3 and T1.V2=T2.V2 WHERE T2.V1 = ?;
> {code}
> or
> {code:sql}
> SELECT T1.V1, T2.V2 FROM TBL1 T1 JOIN TBL2 /*+ MERGE_JOIN */ T2 on
> T1.V3=T2.V3 and T1.V2=T2.V2 WHERE T2.V1 = ?;
> {code}
> MIght be useful int sub-queries or when aliases are used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21656) Cache dump fails on a cache with a node filter.
[
https://issues.apache.org/jira/browse/IGNITE-21656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21656:
--
Description:
Ignite fails to create dump of cache with a node filter. If there is no
partitions on some cone, we assign the empty sat an the snapshot task result:
{code:java}
if (parts.isEmpty() && !withMetaStorage)
task0 = new GridFinishedFuture<>(Collections.emptySet());
else {
...
}
{code}
Cache dump doesn't contain the metastoreage. Further, we may cast the result to
{code:java}
SnapshotFutureTaskResult res = (SnapshotFutureTaskResult)task0.result();
{code}
but it is a
{code:java}
Collections#EMPTY_SET
{code}
Stacktrace:
{code:java}
[ERROR][snapshot-runner-#413%dump.IgniteCacheDumpSelfTest0%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
[type=CRITICAL_ERROR, err=java.lang.ClassCastException: class
java.util.Collections$EmptySet cannot be cast to class
o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
(java.util.Collections$EmptySet is in module java.base of loader 'bootstrap';
o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult is in
unnamed module of loader 'app')]]
java.lang.ClassCastException: class java.util.Collections$EmptySet cannot be
cast to class
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
(java.util.Collections$EmptySet is in module java.base of loader 'bootstrap';
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
is in unnamed module of loader 'app')
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager.lambda$initLocalFullSnapshot$923db49$1(IgniteSnapshotManager.java:1221)
~[classes/:?]
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$d8c8d23e$1(GridFinishedFuture.java:180)
~[classes/:?]
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$0(GridFinishedFuture.java:163)
~[classes/:?]
{code}
Even we fix this, we fail further at:
{code:java}
private GridKernalContext standaloneKernalContext(File dumpDir, IgniteLogger
log) {
File binaryMeta =
CacheObjectBinaryProcessorImpl.binaryWorkDir(dumpDir.getAbsolutePath(),
F.first(metadata).folderName());
File marshaller = new File(dumpDir, DFLT_MARSHALLER_PATH);
A.ensure(binaryMeta.exists(), "binary metadata directory not exists");
{code}
If cache with node filter was created by a client or not by the excluded node
(or may be not from the coordinator), it is empty.
Stacktrace:
{code:java}
Caused by: class org.apache.ignite.IgniteException: Ouch! Argument is invalid:
binary metadata directory not exists
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsVerifyHandler.checkDumpFiles(SnapshotPartitionsVerifyHandler.java:382)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsVerifyHandler.invoke(SnapshotPartitionsVerifyHandler.java:183)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsQuickVerifyHandler.invoke(SnapshotPartitionsQuickVerifyHandler.java:62)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsQuickVerifyHandler.invoke(SnapshotPartitionsQuickVerifyHandler.java:37)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.invoke(IgniteSnapshotManager.java:3396)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.lambda$invokeAll$8d56ceed$1(IgniteSnapshotManager.java:3328)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11715)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11617)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11597)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.invokeAll(IgniteSnapshotManager.java:3325)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager.lambda$initLocalFullSnapshot$923db49$1(IgniteSnapshotManager.java:1254)
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$d8c8d23e$1(GridFinishedFuture.java:180)
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$0(GridFinishedFuture.java:163)
... 3 more
Caused by: java.lang.IllegalArgumentException: Ouch! Argument is invalid:
[jira] [Updated] (IGNITE-21656) Cache dump fails on a cache with a node filter.
[
https://issues.apache.org/jira/browse/IGNITE-21656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21656:
--
Description:
Ignite fails to create dump of cache with a node filter. If there is no
partitions on some cone, we assign the empty sat an the snapshot task result:
{code:java}
if (parts.isEmpty() && !withMetaStorage)
task0 = new GridFinishedFuture<>(Collections.emptySet());
else {
...
}
{code}
Cache dump doesn't contain the metastoreage. Further, we may cast the result to
{code:java}
SnapshotFutureTaskResult res = (SnapshotFutureTaskResult)task0.result();
{code}
but it is a
{code:java}
Collections#EMPTY_SET
{code}
Stacktrace:
{code:java}
[ERROR][snapshot-runner-#413%dump.IgniteCacheDumpSelfTest0%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
[type=CRITICAL_ERROR, err=java.lang.ClassCastException: class
java.util.Collections$EmptySet cannot be cast to class
o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
(java.util.Collections$EmptySet is in module java.base of loader 'bootstrap';
o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult is in
unnamed module of loader 'app')]]
java.lang.ClassCastException: class java.util.Collections$EmptySet cannot be
cast to class
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
(java.util.Collections$EmptySet is in module java.base of loader 'bootstrap';
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
is in unnamed module of loader 'app')
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager.lambda$initLocalFullSnapshot$923db49$1(IgniteSnapshotManager.java:1221)
~[classes/:?]
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$d8c8d23e$1(GridFinishedFuture.java:180)
~[classes/:?]
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$0(GridFinishedFuture.java:163)
~[classes/:?]
{code}
Even we fix this, we fail further at:
{code:java}
private GridKernalContext standaloneKernalContext(File dumpDir, IgniteLogger
log) {
File binaryMeta =
CacheObjectBinaryProcessorImpl.binaryWorkDir(dumpDir.getAbsolutePath(),
F.first(metadata).folderName());
File marshaller = new File(dumpDir, DFLT_MARSHALLER_PATH);
A.ensure(binaryMeta.exists(), "binary metadata directory not exists");
{code}
If cache with node filter was created by a client or not by the excluded node
(or may be not from the coordinator), it is empty. CreateDumpFutureTask#start()
is not called.
Stacktrace:
{code:java}
Caused by: class org.apache.ignite.IgniteException: Ouch! Argument is invalid:
binary metadata directory not exists
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsVerifyHandler.checkDumpFiles(SnapshotPartitionsVerifyHandler.java:382)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsVerifyHandler.invoke(SnapshotPartitionsVerifyHandler.java:183)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsQuickVerifyHandler.invoke(SnapshotPartitionsQuickVerifyHandler.java:62)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsQuickVerifyHandler.invoke(SnapshotPartitionsQuickVerifyHandler.java:37)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.invoke(IgniteSnapshotManager.java:3396)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.lambda$invokeAll$8d56ceed$1(IgniteSnapshotManager.java:3328)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11715)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11617)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11597)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.invokeAll(IgniteSnapshotManager.java:3325)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager.lambda$initLocalFullSnapshot$923db49$1(IgniteSnapshotManager.java:1254)
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$d8c8d23e$1(GridFinishedFuture.java:180)
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$0(GridFinishedFuture.java:163)
... 3 more
Caused by:
[jira] [Updated] (IGNITE-21656) Cache dump fails on a cache with a node filter.
[
https://issues.apache.org/jira/browse/IGNITE-21656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21656:
--
Description:
Ignite fails to create dump of cache with a node filter. If there is no
partitions on some cone, we assign the empty sat an the snapshot task result:
{code:java}
if (parts.isEmpty() && !withMetaStorage)
task0 = new GridFinishedFuture<>(Collections.emptySet());
else {
...
}
{code}
Cache dump doesn't contain the metastoreage. Further, we may cast the result to
{code:java}
SnapshotFutureTaskResult res = (SnapshotFutureTaskResult)task0.result();
{code}
but it is a
{code:java}
Collections#EMPTY_SET
{code}
Stacktrace:
{code:java}
[ERROR][snapshot-runner-#413%dump.IgniteCacheDumpSelfTest0%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
[type=CRITICAL_ERROR, err=java.lang.ClassCastException: class
java.util.Collections$EmptySet cannot be cast to class
o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
(java.util.Collections$EmptySet is in module java.base of loader 'bootstrap';
o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult is in
unnamed module of loader 'app')]]
java.lang.ClassCastException: class java.util.Collections$EmptySet cannot be
cast to class
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
(java.util.Collections$EmptySet is in module java.base of loader 'bootstrap';
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
is in unnamed module of loader 'app')
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager.lambda$initLocalFullSnapshot$923db49$1(IgniteSnapshotManager.java:1221)
~[classes/:?]
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$d8c8d23e$1(GridFinishedFuture.java:180)
~[classes/:?]
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$0(GridFinishedFuture.java:163)
~[classes/:?]
{code}
Even we fix this, we fail further at:
{code:java}
private GridKernalContext standaloneKernalContext(File dumpDir, IgniteLogger
log) {
File binaryMeta =
CacheObjectBinaryProcessorImpl.binaryWorkDir(dumpDir.getAbsolutePath(),
F.first(metadata).folderName());
File marshaller = new File(dumpDir, DFLT_MARSHALLER_PATH);
A.ensure(binaryMeta.exists(), "binary metadata directory not exists");
{code}
If cache with node filter was created from client or not from filtered node (or
not from coordinator), it is empty. CreateDumpFutureTask#start() is not called.
Stacktrace:
{code:java}
Caused by: class org.apache.ignite.IgniteException: Ouch! Argument is invalid:
binary metadata directory not exists
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsVerifyHandler.checkDumpFiles(SnapshotPartitionsVerifyHandler.java:382)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsVerifyHandler.invoke(SnapshotPartitionsVerifyHandler.java:183)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsQuickVerifyHandler.invoke(SnapshotPartitionsQuickVerifyHandler.java:62)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsQuickVerifyHandler.invoke(SnapshotPartitionsQuickVerifyHandler.java:37)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.invoke(IgniteSnapshotManager.java:3396)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.lambda$invokeAll$8d56ceed$1(IgniteSnapshotManager.java:3328)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11715)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11617)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11597)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.invokeAll(IgniteSnapshotManager.java:3325)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager.lambda$initLocalFullSnapshot$923db49$1(IgniteSnapshotManager.java:1254)
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$d8c8d23e$1(GridFinishedFuture.java:180)
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$0(GridFinishedFuture.java:163)
... 3 more
Caused by:
[jira] [Updated] (IGNITE-21656) Cache dump fails on a cache with a node filter.
[
https://issues.apache.org/jira/browse/IGNITE-21656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21656:
--
Description:
Ignite fails to create dump of cache with a node filter. If there is no
partitions on some cone, we assign the empty sat an the snapshot task result:
{code:java}
if (parts.isEmpty() && !withMetaStorage)
task0 = new GridFinishedFuture<>(Collections.emptySet());
else {
...
}
{code}
Cache dump doesn't contain the metastoreage. Further, we may cast the result to
{code:java}
SnapshotFutureTaskResult res = (SnapshotFutureTaskResult)task0.result();
{code}
but it is a
{code:java}
Collections#EMPTY_SET
{code}
Stacktrace:
{code:java}
[ERROR][snapshot-runner-#413%dump.IgniteCacheDumpSelfTest0%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
[type=CRITICAL_ERROR, err=java.lang.ClassCastException: class
java.util.Collections$EmptySet cannot be cast to class
o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
(java.util.Collections$EmptySet is in module java.base of loader 'bootstrap';
o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult is in
unnamed module of loader 'app')]]
java.lang.ClassCastException: class java.util.Collections$EmptySet cannot be
cast to class
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
(java.util.Collections$EmptySet is in module java.base of loader 'bootstrap';
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
is in unnamed module of loader 'app')
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager.lambda$initLocalFullSnapshot$923db49$1(IgniteSnapshotManager.java:1221)
~[classes/:?]
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$d8c8d23e$1(GridFinishedFuture.java:180)
~[classes/:?]
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$0(GridFinishedFuture.java:163)
~[classes/:?]
{code}
Even we fix this, we fail at:
{code:java}
private GridKernalContext standaloneKernalContext(File dumpDir, IgniteLogger
log) {
File binaryMeta =
CacheObjectBinaryProcessorImpl.binaryWorkDir(dumpDir.getAbsolutePath(),
F.first(metadata).folderName());
File marshaller = new File(dumpDir, DFLT_MARSHALLER_PATH);
A.ensure(binaryMeta.exists(), "binary metadata directory not exists");
{code}
If cache with node filter was created from client or not from filtered node (or
not from coordinator), it is empty. CreateDumpFutureTask#start() is not called.
Stacktrace:
{code:java}
Caused by: class org.apache.ignite.IgniteException: Ouch! Argument is invalid:
binary metadata directory not exists
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsVerifyHandler.checkDumpFiles(SnapshotPartitionsVerifyHandler.java:382)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsVerifyHandler.invoke(SnapshotPartitionsVerifyHandler.java:183)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsQuickVerifyHandler.invoke(SnapshotPartitionsQuickVerifyHandler.java:62)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsQuickVerifyHandler.invoke(SnapshotPartitionsQuickVerifyHandler.java:37)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.invoke(IgniteSnapshotManager.java:3396)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.lambda$invokeAll$8d56ceed$1(IgniteSnapshotManager.java:3328)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11715)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11617)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11597)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.invokeAll(IgniteSnapshotManager.java:3325)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager.lambda$initLocalFullSnapshot$923db49$1(IgniteSnapshotManager.java:1254)
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$d8c8d23e$1(GridFinishedFuture.java:180)
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$0(GridFinishedFuture.java:163)
... 3 more
Caused by: java.lang.IllegalArgumentException: Ouch!
[jira] [Updated] (IGNITE-21656) Cache dump fails on a cache with a node filter.
[
https://issues.apache.org/jira/browse/IGNITE-21656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21656:
--
Description:
Ignite fails to create dump of cache with a node filter. If there is no
partitions on some cone, we assign the empty sat an the snapshot task result:
{code:java}
if (parts.isEmpty() && !withMetaStorage)
task0 = new GridFinishedFuture<>(Collections.emptySet());
else {
...
}
{code}
Cache dump doesn't contain the metastoreage. Further, we may cast the result to
{code:java}
SnapshotFutureTaskResult res = (SnapshotFutureTaskResult)task0.result();
{code}
but it is a
{code:java}
Collections#EMPTY_SET
{code}
Stacktrace:
{code:java}
[ERROR][snapshot-runner-#413%dump.IgniteCacheDumpSelfTest0%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
[type=CRITICAL_ERROR, err=java.lang.ClassCastException: class
java.util.Collections$EmptySet cannot be cast to class
o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
(java.util.Collections$EmptySet is in module java.base of loader 'bootstrap';
o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult is in
unnamed module of loader 'app')]]
java.lang.ClassCastException: class java.util.Collections$EmptySet cannot be
cast to class
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
(java.util.Collections$EmptySet is in module java.base of loader 'bootstrap';
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
is in unnamed module of loader 'app')
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager.lambda$initLocalFullSnapshot$923db49$1(IgniteSnapshotManager.java:1221)
~[classes/:?]
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$d8c8d23e$1(GridFinishedFuture.java:180)
~[classes/:?]
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$0(GridFinishedFuture.java:163)
~[classes/:?]
{code}
was:
Ignite fails to create dump of cache with a node filter. If there is no
partitions on some cone, we assign the empty sat an the snapshot task result:
{code:java}
if (parts.isEmpty() && !withMetaStorage)
task0 = new GridFinishedFuture<>(Collections.emptySet());
else {
...
}
{code}
Cache dump doesn't contain the metastoreage. Further, we may cast the result to
{code:java}
SnapshotFutureTaskResult res = (SnapshotFutureTaskResult)task0.result();
{code}
but it is a
{code:java}
Collections#EMPTY_SET
{code}
Stacktrace:
{code:java}
[ERROR][snapshot-runner-#413%dump.IgniteCacheDumpSelfTest0%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
[type=CRITICAL_ERROR, err=java.lang.ClassCastException: class
java.util.Collections$EmptySet cannot be cast to class
o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
(java.util.Collections$EmptySet is in module java.base of loader 'bootstrap';
o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult is in
unnamed module of loader 'app')]]
java.lang.ClassCastException: class java.util.Collections$EmptySet cannot be
cast to class
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
(java.util.Collections$EmptySet is in module java.base of loader 'bootstrap';
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
is in unnamed module of loader 'app')
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager.lambda$initLocalFullSnapshot$923db49$1(IgniteSnapshotManager.java:1221)
~[classes/:?]
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$d8c8d23e$1(GridFinishedFuture.java:180)
~[classes/:?]
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$0(GridFinishedFuture.java:163)
~[classes/:?]
{code}
> Cache dump fails on a cache with a node filter.
> ---
>
> Key: IGNITE-21656
> URL: https://issues.apache.org/jira/browse/IGNITE-21656
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ignite fails to create dump of cache with a node filter. If
[jira] [Updated] (IGNITE-21656) Cache dump fails on a cache with a node filter.
[
https://issues.apache.org/jira/browse/IGNITE-21656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21656:
--
Description:
Ignite fails to create dump of cache with a node filter. If there is no
partitions on some cone, we assign the empty sat an the snapshot task result:
{code:java}
if (parts.isEmpty() && !withMetaStorage)
task0 = new GridFinishedFuture<>(Collections.emptySet());
else {
...
}
{code}
Cache dump doesn't contain the metastoreage. Further, we may cast the result to
{code:java}
SnapshotFutureTaskResult res = (SnapshotFutureTaskResult)task0.result();
{code}
but it is a
{code:java}
Collections#EMPTY_SET
{code}
Stacktrace:
{code:java}
[ERROR][snapshot-runner-#413%dump.IgniteCacheDumpSelfTest0%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
[type=CRITICAL_ERROR, err=java.lang.ClassCastException: class
java.util.Collections$EmptySet cannot be cast to class
o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
(java.util.Collections$EmptySet is in module java.base of loader 'bootstrap';
o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult is in
unnamed module of loader 'app')]]
java.lang.ClassCastException: class java.util.Collections$EmptySet cannot be
cast to class
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
(java.util.Collections$EmptySet is in module java.base of loader 'bootstrap';
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
is in unnamed module of loader 'app')
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager.lambda$initLocalFullSnapshot$923db49$1(IgniteSnapshotManager.java:1221)
~[classes/:?]
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$d8c8d23e$1(GridFinishedFuture.java:180)
~[classes/:?]
at
org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$0(GridFinishedFuture.java:163)
~[classes/:?]
{code}
> Cache dump fails on a cache with a node filter.
> ---
>
> Key: IGNITE-21656
> URL: https://issues.apache.org/jira/browse/IGNITE-21656
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ignite fails to create dump of cache with a node filter. If there is no
> partitions on some cone, we assign the empty sat an the snapshot task result:
> {code:java}
> if (parts.isEmpty() && !withMetaStorage)
> task0 = new GridFinishedFuture<>(Collections.emptySet());
> else {
> ...
> }
> {code}
> Cache dump doesn't contain the metastoreage. Further, we may cast the result
> to
> {code:java}
> SnapshotFutureTaskResult res = (SnapshotFutureTaskResult)task0.result();
> {code}
> but it is a
> {code:java}
> Collections#EMPTY_SET
> {code}
> Stacktrace:
> {code:java}
> [ERROR][snapshot-runner-#413%dump.IgniteCacheDumpSelfTest0%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=CRITICAL_ERROR, err=java.lang.ClassCastException: class
> java.util.Collections$EmptySet cannot be cast to class
> o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
> (java.util.Collections$EmptySet is in module java.base of loader 'bootstrap';
> o.a.i.i.processors.cache.persistence.snapshot.SnapshotFutureTaskResult is in
> unnamed module of loader 'app')]]
> java.lang.ClassCastException: class java.util.Collections$EmptySet cannot be
> cast to class
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
> (java.util.Collections$EmptySet is in module java.base of loader
> 'bootstrap';
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTaskResult
> is in unnamed module of loader 'app')
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager.lambda$initLocalFullSnapshot$923db49$1(IgniteSnapshotManager.java:1221)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.future.GridFinishedFuture.lambda$chain$d8c8d23e$1(GridFinishedFuture.java:180)
> ~[classes/:?]
> at
>
[jira] [Created] (IGNITE-21656) Cache dump fails on a cache with a node filter.
Vladimir Steshin created IGNITE-21656: - Summary: Cache dump fails on a cache with a node filter. Key: IGNITE-21656 URL: https://issues.apache.org/jira/browse/IGNITE-21656 Project: Ignite Issue Type: Bug Reporter: Vladimir Steshin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21162) Use table SQL hints
[
https://issues.apache.org/jira/browse/IGNITE-21162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin reassigned IGNITE-21162:
-
Assignee: Vladimir Steshin
> Use table SQL hints
> ---
>
> Key: IGNITE-21162
> URL: https://issues.apache.org/jira/browse/IGNITE-21162
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: ise
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Calcite parses and creates hints for 2 SQL nodes:
> 1) For SqlKind.SELECT в SqlToRelConverter.convertQuery() /
> SqlToRelConverter.convertSelectImpl()
> 2) For SqlKind.TABLE_REF in SqlToRelConverter.convertFrom() . Here a hint
> comes directly to a table / table scan
> Currently, we skip #2 in _IgniteTable.toRel()_ not using
> _RelOptTable.ToRelContext.getTableHints()_ . This would allow to set hints
> more precisely:
> {code:sql}
> SELECT T1.V1, T2.V2 FROM TBL1 T1 JOIN TBL2 /*+ FORCE_INDEX(TBL2_IDX2) */ T2
> on T1.V3=T2.V3 and T1.V2=T2.V2 WHERE T2.V1 = ?;
> {code}
> or
> {code:sql}
> SELECT T1.V1, T2.V2 FROM TBL1 T1 JOIN TBL2 /*+ MERGE_JOIN */ T2 on
> T1.V3=T2.V3 and T1.V2=T2.V2 WHERE T2.V1 = ?;
> {code}
> MIght be useful int sub-queries or when aliases are used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21162) Use table SQL hints
[
https://issues.apache.org/jira/browse/IGNITE-21162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21162:
--
Fix Version/s: 2.17
> Use table SQL hints
> ---
>
> Key: IGNITE-21162
> URL: https://issues.apache.org/jira/browse/IGNITE-21162
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Calcite parses and creates hints for 2 SQL nodes:
> 1) For SqlKind.SELECT в SqlToRelConverter.convertQuery() /
> SqlToRelConverter.convertSelectImpl()
> 2) For SqlKind.TABLE_REF in SqlToRelConverter.convertFrom() . Here a hint
> comes directly to a table / table scan
> Currently, we skip #2 in _IgniteTable.toRel()_ not using
> _RelOptTable.ToRelContext.getTableHints()_ . This would allow to set hints
> more precisely:
> {code:sql}
> SELECT T1.V1, T2.V2 FROM TBL1 T1 JOIN TBL2 /*+ FORCE_INDEX(TBL2_IDX2) */ T2
> on T1.V3=T2.V3 and T1.V2=T2.V2 WHERE T2.V1 = ?;
> {code}
> or
> {code:sql}
> SELECT T1.V1, T2.V2 FROM TBL1 T1 JOIN TBL2 /*+ MERGE_JOIN */ T2 on
> T1.V3=T2.V3 and T1.V2=T2.V2 WHERE T2.V1 = ?;
> {code}
> MIght be useful int sub-queries or when aliases are used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21636) Code cleanup
Vladimir Steshin created IGNITE-21636: - Summary: Code cleanup Key: IGNITE-21636 URL: https://issues.apache.org/jira/browse/IGNITE-21636 Project: Ignite Issue Type: Improvement Reporter: Vladimir Steshin Removing of unused 'mvccEnabled', codestyle fixex, +abbreviations, finals and etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21603) Incorrect backward connection check with loopback address.
[
https://issues.apache.org/jira/browse/IGNITE-21603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21603:
--
Description:
We may skip backward connection check of a previous node if it has the same
loopback address as the current node.
Consider:
# Neither _IgniteConfiguration#setLocalHost()_ or
_TcpDiscoverySpi#setLocalAddress()_ is set. Or the localhost parameter is
"_0.0.0.0_".
# Nodes start on different hosts. All the available host addresses are resolved.
# Among the other addresses, all nodes get the loopback address
"127.0.0.1:47500" (47500 is the default tcp discovery port).
# Cluster starts and works.
# Some node N (A) decides that the connection to node N+1 (B) is lost and tries
to connect to node N+2 (C) and sends _TcpDiscoveryHandshakeRequest_.
# Before C accepts incoming A's connection, it decides to check B and pings it
with _ServerImpl#checkConnection(List addrs, int timeout)_
# Around here, the network is restored, and A can now connect to B anew.
# "_127.0.0.1:47500_" is last in _List_ addrs by
_IgniteUtils#inetAddressesComparator(boolean sameHost)_. But the connect
attempts in _checkConnection(...)_ are parallel. "_127.0.0.1:47500_" answers
first.
# C sees it can connect to "_127.0.0.1:47500_" and chooses it as the alive
address of B. Other pings to rest of B's addresses are ignored.
# But "_127.0.0.1:47500_" is one of C's addresses. C realizes it pinged itself
and marks that B is not reachable:
{code:java}
// If local node was able to connect to previous, confirm that it's
alive.
ok = liveAddr != null && (!liveAddr.getAddress().isLoopbackAddress()
|| !locNode.socketAddresses().contains(liveAddr));
{code}
# C accepts connection from A and answers with
_TcpDiscoveryHandshakeResponse#previousNodeAlive() == false_
# B is ok now, but A connects to C and B is kicked from the ring.
The problem is that C pings itself with B's address "_127.0.0.1:47500_"
was:
We may skip backward connection check to a previous node if it has the same
loopback address as the current node.
Consider:
# Neither _IgniteConfiguration#setLocalHost()_ or
_TcpDiscoverySpi#setLocalAddress()_ is set. Or the localhost parameter is set
to "_0.0.0.0_".
# Nodes start on different hosts. All the available host addresses are resolved
and
# Among the other addresses, all nodes get the loopback address
"127.0.0.1:47500" (47500 is the default tcp discovery port).
# Cluster starts and works. But
# Some node N (A) decides the connection to node N+1 (B) is lost and tries to
connect to node N+2 (C) and sends _TcpDiscoveryHandshakeRequest_.
# Before C accepts incoming A's connection, it decides to check B and pings it
with _ServerImpl#checkConnection(List addrs, int timeout)_
# Around here, the network is restored, and A can now connect to B anew.
# "_127.0.0.1:47500_" is last in _List_ addrs by
_IgniteUtils#inetAddressesComparator(boolean sameHost)_. But the connect
attempts in _checkConnection(...)_ are parallel. "_127.0.0.1:47500_" answers
first.
# C sees it can connect to "_127.0.0.1:47500_" and chooses it as the alive
address of B. Other pings to rest of B's addresses are ignored.
# But "_127.0.0.1:47500_" is one of C's addresses. C realizes it pinged itself
and decides that B is not reachable:
{code:java}
// If local node was able to connect to previous, confirm that it's
alive.
ok = liveAddr != null && (!liveAddr.getAddress().isLoopbackAddress()
|| !locNode.socketAddresses().contains(liveAddr));
{code}
# C accepts connection from A and answers with
_TcpDiscoveryHandshakeResponse#previousNodeAlive() == false_
# But B is ok now. But A connects to C and B is kicked from the ring.
The problem is that C ping itself by B's address "_127.0.0.1:47500_"
> Incorrect backward connection check with loopback address.
> --
>
> Key: IGNITE-21603
> URL: https://issues.apache.org/jira/browse/IGNITE-21603
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We may skip backward connection check of a previous node if it has the same
> loopback address as the current node.
> Consider:
> # Neither _IgniteConfiguration#setLocalHost()_ or
> _TcpDiscoverySpi#setLocalAddress()_ is set. Or the localhost parameter is
> "_0.0.0.0_".
> # Nodes start on different hosts. All the available host addresses are
> resolved.
> # Among the other addresses, all nodes get the loopback address
> "127.0.0.1:47500" (47500 is the default tcp discovery port).
> # Cluster starts and works.
> # Some node N (A) decides that the connection to node N+1 (B) is lost and
> tries to
[jira] [Updated] (IGNITE-21603) Incorrect backward connection check with loopback address.
[
https://issues.apache.org/jira/browse/IGNITE-21603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21603:
--
Fix Version/s: 2.17
> Incorrect backward connection check with loopback address.
> --
>
> Key: IGNITE-21603
> URL: https://issues.apache.org/jira/browse/IGNITE-21603
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We may skip backward connection check to a previous node if it has the same
> loopback address as the current node.
> Consider:
> # Neither _IgniteConfiguration#setLocalHost()_ or
> _TcpDiscoverySpi#setLocalAddress()_ is set. Or the localhost parameter is set
> to "_0.0.0.0_".
> # Nodes start on different hosts. All the available host addresses are
> resolved and
> # Among the other addresses, all nodes get the loopback address
> "127.0.0.1:47500" (47500 is the default tcp discovery port).
> # Cluster starts and works. But
> # Some node N (A) decides the connection to node N+1 (B) is lost and tries to
> connect to node N+2 (C) and sends _TcpDiscoveryHandshakeRequest_.
> # Before C accepts incoming A's connection, it decides to check B and pings
> it with _ServerImpl#checkConnection(List addrs, int
> timeout)_
> # Around here, the network is restored, and A can now connect to B anew.
> # "_127.0.0.1:47500_" is last in _List_ addrs by
> _IgniteUtils#inetAddressesComparator(boolean sameHost)_. But the connect
> attempts in _checkConnection(...)_ are parallel. "_127.0.0.1:47500_" answers
> first.
> # C sees it can connect to "_127.0.0.1:47500_" and chooses it as the alive
> address of B. Other pings to rest of B's addresses are ignored.
> # But "_127.0.0.1:47500_" is one of C's addresses. C realizes it pinged
> itself and decides that B is not reachable:
> {code:java}
> // If local node was able to connect to previous, confirm that it's
> alive.
> ok = liveAddr != null && (!liveAddr.getAddress().isLoopbackAddress()
> || !locNode.socketAddresses().contains(liveAddr));
> {code}
> # C accepts connection from A and answers with
> _TcpDiscoveryHandshakeResponse#previousNodeAlive() == false_
> # But B is ok now. But A connects to C and B is kicked from the ring.
> The problem is that C ping itself by B's address "_127.0.0.1:47500_"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21603) Incorrect backward connection check with loopback address.
[
https://issues.apache.org/jira/browse/IGNITE-21603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21603:
--
Summary: Incorrect backward connection check with loopback address. (was:
Incorrect backward connection chech with loopback address.)
> Incorrect backward connection check with loopback address.
> --
>
> Key: IGNITE-21603
> URL: https://issues.apache.org/jira/browse/IGNITE-21603
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We may skip backward connection check to a previous node if it has the same
> loopback address as the current node.
> Consider:
> # Neither _IgniteConfiguration#setLocalHost()_ or
> _TcpDiscoverySpi#setLocalAddress()_ is set. Or the localhost parameter is set
> to "_0.0.0.0_".
> # Nodes start on different hosts. All the available host addresses are
> resolved and
> # Among the other addresses, all nodes get the loopback address
> "127.0.0.1:47500" (47500 is the default tcp discovery port).
> # Cluster starts and works. But
> # Some node N (A) decides the connection to node N+1 (B) is lost and tries to
> connect to node N+2 (C) and sends _TcpDiscoveryHandshakeRequest_.
> # Before C accepts incoming A's connection, it decides to check B and pings
> it with _ServerImpl#checkConnection(List addrs, int
> timeout)_
> # Around here, the network is restored, and A can now connect to B anew.
> # "_127.0.0.1:47500_" is last in _List_ addrs by
> _IgniteUtils#inetAddressesComparator(boolean sameHost)_. But the connect
> attempts in _checkConnection(...)_ are parallel. "_127.0.0.1:47500_" answers
> first.
> # C sees it can connect to "_127.0.0.1:47500_" and chooses it as the alive
> address of B. Other pings to rest of B's addresses are ignored.
> # But "_127.0.0.1:47500_" is one of C's addresses. C realizes it pinged
> itself and decides that B is not reachable:
> {code:java}
> // If local node was able to connect to previous, confirm that it's
> alive.
> ok = liveAddr != null && (!liveAddr.getAddress().isLoopbackAddress()
> || !locNode.socketAddresses().contains(liveAddr));
> {code}
> # C accepts connection from A and answers with
> _TcpDiscoveryHandshakeResponse#previousNodeAlive() == false_
> # But B is ok now. But A connects to C and B is kicked from the ring.
> The problem is that C ping itself by B's address "_127.0.0.1:47500_"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21607) Code cleanup
[ https://issues.apache.org/jira/browse/IGNITE-21607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-21607: - Assignee: Vladimir Steshin > Code cleanup > > > Key: IGNITE-21607 > URL: https://issues.apache.org/jira/browse/IGNITE-21607 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Fixing of typos, abbreviations, unused code and untyped generics. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21607) Code cleanup
Vladimir Steshin created IGNITE-21607: - Summary: Code cleanup Key: IGNITE-21607 URL: https://issues.apache.org/jira/browse/IGNITE-21607 Project: Ignite Issue Type: Improvement Reporter: Vladimir Steshin Fixing of typos, abbreviations, unused code and untyped generics. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21603) Incorrect backward connection chech with loopback address.
[
https://issues.apache.org/jira/browse/IGNITE-21603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin reassigned IGNITE-21603:
-
Assignee: Vladimir Steshin
> Incorrect backward connection chech with loopback address.
> --
>
> Key: IGNITE-21603
> URL: https://issues.apache.org/jira/browse/IGNITE-21603
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We may skip backward connection check to a previous node if it has the same
> loopback address as the current node.
> Consider:
> # Neither _IgniteConfiguration#setLocalHost()_ or
> _TcpDiscoverySpi#setLocalAddress()_ is set. Or the localhost parameter is set
> to "_0.0.0.0_".
> # Nodes start on different hosts. All the available host addresses are
> resolved and
> # Among the other addresses, all nodes get the loopback address
> "127.0.0.1:47500" (47500 is the default tcp discovery port).
> # Cluster starts and works. But
> # Some node N (A) decides the connection to node N+1 (B) is lost and tries to
> connect to node N+2 (C) and sends _TcpDiscoveryHandshakeRequest_.
> # Before C accepts incoming A's connection, it decides to check B and pings
> it with _ServerImpl#checkConnection(List addrs, int
> timeout)_
> # Around here, the network is restored, and A can now connect to B anew.
> # "_127.0.0.1:47500_" is last in _List_ addrs by
> _IgniteUtils#inetAddressesComparator(boolean sameHost)_. But the connect
> attempts in _checkConnection(...)_ are parallel. "_127.0.0.1:47500_" answers
> first.
> # C sees it can connect to "_127.0.0.1:47500_" and chooses it as the alive
> address of B. Other pings to rest of B's addresses are ignored.
> # But "_127.0.0.1:47500_" is one of C's addresses. C realizes it pinged
> itself and decides that B is not reachable:
> {code:java}
> // If local node was able to connect to previous, confirm that it's
> alive.
> ok = liveAddr != null && (!liveAddr.getAddress().isLoopbackAddress()
> || !locNode.socketAddresses().contains(liveAddr));
> {code}
> # C accepts connection from A and answers with
> _TcpDiscoveryHandshakeResponse#previousNodeAlive() == false_
> # But B is ok now. But A connects to C and B is kicked from the ring.
> The problem is that C ping itself by B's address "_127.0.0.1:47500_"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21603) Incorrect backward connection chech with loopback address.
[
https://issues.apache.org/jira/browse/IGNITE-21603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21603:
--
Summary: Incorrect backward connection chech with loopback address. (was:
Incorrect backward connection chech with loopback address)
> Incorrect backward connection chech with loopback address.
> --
>
> Key: IGNITE-21603
> URL: https://issues.apache.org/jira/browse/IGNITE-21603
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Minor
> Labels: ise
>
> We may skip backward connection check to a previous node if it has the same
> loopback address as the current node.
> Consider:
> # Neither _IgniteConfiguration#setLocalHost()_ or
> _TcpDiscoverySpi#setLocalAddress()_ is set. Or the localhost parameter is set
> to "_0.0.0.0_".
> # Nodes start on different hosts. All the available host addresses are
> resolved and
> # Among the other addresses, all nodes get the loopback address
> "127.0.0.1:47500" (47500 is the default tcp discovery port).
> # Cluster starts and works. But
> # Some node N (A) decides the connection to node N+1 (B) is lost and tries to
> connect to node N+2 (C) and sends _TcpDiscoveryHandshakeRequest_.
> # Before C accepts incoming A's connection, it decides to check B and pings
> it with _ServerImpl#checkConnection(List addrs, int
> timeout)_
> # Around here, the network is restored, and A can now connect to B anew.
> # "_127.0.0.1:47500_" is last in _List_ addrs by
> _IgniteUtils#inetAddressesComparator(boolean sameHost)_. But the connect
> attempts in _checkConnection(...)_ are parallel. "_127.0.0.1:47500_" answers
> first.
> # C sees it can connect to "_127.0.0.1:47500_" and chooses it as the alive
> address of B. Other pings to rest of B's addresses are ignored.
> # But "_127.0.0.1:47500_" is one of C's addresses. C realizes it pinged
> itself and decides that B is not reachable:
> {code:java}
> // If local node was able to connect to previous, confirm that it's
> alive.
> ok = liveAddr != null && (!liveAddr.getAddress().isLoopbackAddress()
> || !locNode.socketAddresses().contains(liveAddr));
> {code}
> # C accepts connection from A and answers with
> _TcpDiscoveryHandshakeResponse#previousNodeAlive() == false_
> # But B is ok now. But A connects to C and B is kicked from the ring.
> The problem is that C ping itself by B's address "_127.0.0.1:47500_"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21603) Incorrect backward connection chech with loopback address
[
https://issues.apache.org/jira/browse/IGNITE-21603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21603:
--
Labels: ise (was: )
> Incorrect backward connection chech with loopback address
> -
>
> Key: IGNITE-21603
> URL: https://issues.apache.org/jira/browse/IGNITE-21603
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
>
> We may skip backward connection check to a previous node if it has the same
> loopback address as the current node.
> Consider:
> # Neither _IgniteConfiguration#setLocalHost()_ or
> _TcpDiscoverySpi#setLocalAddress()_ is set. Or the localhost parameter is set
> to "_0.0.0.0_".
> # Nodes start on different hosts. All the available host addresses are
> resolved and
> # Among the other addresses, all nodes get the loopback address
> "127.0.0.1:47500" (47500 is the default tcp discovery port).
> # Cluster starts and works. But
> # Some node N (A) decides the connection to node N+1 (B) is lost and tries to
> connect to node N+2 (C) and sends _TcpDiscoveryHandshakeRequest_.
> # Before C accepts incoming A's connection, it decides to check B and pings
> it with _ServerImpl#checkConnection(List addrs, int
> timeout)_
> # Around here, the network is restored, and A can now connect to B anew.
> # "_127.0.0.1:47500_" is last in _List_ addrs by
> _IgniteUtils#inetAddressesComparator(boolean sameHost)_. But the connect
> attempts in _checkConnection(...)_ are parallel. "_127.0.0.1:47500_" answers
> first.
> # C sees it can connect to "_127.0.0.1:47500_" and chooses it as the alive
> address of B. Other pings to rest of B's addresses are ignored.
> # But "_127.0.0.1:47500_" is one of C's addresses. C realizes it pinged
> itself and decides that B is not reachable:
> {code:java}
> // If local node was able to connect to previous, confirm that it's
> alive.
> ok = liveAddr != null && (!liveAddr.getAddress().isLoopbackAddress()
> || !locNode.socketAddresses().contains(liveAddr));
> {code}
> # C accepts connection from A and answers with
> _TcpDiscoveryHandshakeResponse#previousNodeAlive() == false_
> # But B is ok now. But A connects to C and B is kicked from the ring.
> The problem is that C ping itself by B's address "_127.0.0.1:47500_"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21603) Incorrect backward connection chech with loopback address
[
https://issues.apache.org/jira/browse/IGNITE-21603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21603:
--
Priority: Minor (was: Major)
> Incorrect backward connection chech with loopback address
> -
>
> Key: IGNITE-21603
> URL: https://issues.apache.org/jira/browse/IGNITE-21603
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Minor
> Labels: ise
>
> We may skip backward connection check to a previous node if it has the same
> loopback address as the current node.
> Consider:
> # Neither _IgniteConfiguration#setLocalHost()_ or
> _TcpDiscoverySpi#setLocalAddress()_ is set. Or the localhost parameter is set
> to "_0.0.0.0_".
> # Nodes start on different hosts. All the available host addresses are
> resolved and
> # Among the other addresses, all nodes get the loopback address
> "127.0.0.1:47500" (47500 is the default tcp discovery port).
> # Cluster starts and works. But
> # Some node N (A) decides the connection to node N+1 (B) is lost and tries to
> connect to node N+2 (C) and sends _TcpDiscoveryHandshakeRequest_.
> # Before C accepts incoming A's connection, it decides to check B and pings
> it with _ServerImpl#checkConnection(List addrs, int
> timeout)_
> # Around here, the network is restored, and A can now connect to B anew.
> # "_127.0.0.1:47500_" is last in _List_ addrs by
> _IgniteUtils#inetAddressesComparator(boolean sameHost)_. But the connect
> attempts in _checkConnection(...)_ are parallel. "_127.0.0.1:47500_" answers
> first.
> # C sees it can connect to "_127.0.0.1:47500_" and chooses it as the alive
> address of B. Other pings to rest of B's addresses are ignored.
> # But "_127.0.0.1:47500_" is one of C's addresses. C realizes it pinged
> itself and decides that B is not reachable:
> {code:java}
> // If local node was able to connect to previous, confirm that it's
> alive.
> ok = liveAddr != null && (!liveAddr.getAddress().isLoopbackAddress()
> || !locNode.socketAddresses().contains(liveAddr));
> {code}
> # C accepts connection from A and answers with
> _TcpDiscoveryHandshakeResponse#previousNodeAlive() == false_
> # But B is ok now. But A connects to C and B is kicked from the ring.
> The problem is that C ping itself by B's address "_127.0.0.1:47500_"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21603) Incorrect backward connection chech with loopback address
[
https://issues.apache.org/jira/browse/IGNITE-21603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21603:
--
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Incorrect backward connection chech with loopback address
> -
>
> Key: IGNITE-21603
> URL: https://issues.apache.org/jira/browse/IGNITE-21603
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Minor
> Labels: ise
>
> We may skip backward connection check to a previous node if it has the same
> loopback address as the current node.
> Consider:
> # Neither _IgniteConfiguration#setLocalHost()_ or
> _TcpDiscoverySpi#setLocalAddress()_ is set. Or the localhost parameter is set
> to "_0.0.0.0_".
> # Nodes start on different hosts. All the available host addresses are
> resolved and
> # Among the other addresses, all nodes get the loopback address
> "127.0.0.1:47500" (47500 is the default tcp discovery port).
> # Cluster starts and works. But
> # Some node N (A) decides the connection to node N+1 (B) is lost and tries to
> connect to node N+2 (C) and sends _TcpDiscoveryHandshakeRequest_.
> # Before C accepts incoming A's connection, it decides to check B and pings
> it with _ServerImpl#checkConnection(List addrs, int
> timeout)_
> # Around here, the network is restored, and A can now connect to B anew.
> # "_127.0.0.1:47500_" is last in _List_ addrs by
> _IgniteUtils#inetAddressesComparator(boolean sameHost)_. But the connect
> attempts in _checkConnection(...)_ are parallel. "_127.0.0.1:47500_" answers
> first.
> # C sees it can connect to "_127.0.0.1:47500_" and chooses it as the alive
> address of B. Other pings to rest of B's addresses are ignored.
> # But "_127.0.0.1:47500_" is one of C's addresses. C realizes it pinged
> itself and decides that B is not reachable:
> {code:java}
> // If local node was able to connect to previous, confirm that it's
> alive.
> ok = liveAddr != null && (!liveAddr.getAddress().isLoopbackAddress()
> || !locNode.socketAddresses().contains(liveAddr));
> {code}
> # C accepts connection from A and answers with
> _TcpDiscoveryHandshakeResponse#previousNodeAlive() == false_
> # But B is ok now. But A connects to C and B is kicked from the ring.
> The problem is that C ping itself by B's address "_127.0.0.1:47500_"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21603) Incorrect backward connection chech with loopback address
[
https://issues.apache.org/jira/browse/IGNITE-21603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21603:
--
Issue Type: Bug (was: Improvement)
> Incorrect backward connection chech with loopback address
> -
>
> Key: IGNITE-21603
> URL: https://issues.apache.org/jira/browse/IGNITE-21603
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
>
> We may skip backward connection check to a previous node if it has the same
> loopback address as the current node.
> Consider:
> # Neither _IgniteConfiguration#setLocalHost()_ or
> _TcpDiscoverySpi#setLocalAddress()_ is set. Or the localhost parameter is set
> to "_0.0.0.0_".
> # Nodes start on different hosts. All the available host addresses are
> resolved and
> # Among the other addresses, all nodes get the loopback address
> "127.0.0.1:47500" (47500 is the default tcp discovery port).
> # Cluster starts and works. But
> # Some node N (A) decides the connection to node N+1 (B) is lost and tries to
> connect to node N+2 (C) and sends _TcpDiscoveryHandshakeRequest_.
> # Before C accepts incoming A's connection, it decides to check B and pings
> it with _ServerImpl#checkConnection(List addrs, int
> timeout)_
> # Around here, the network is restored, and A can now connect to B anew.
> # "_127.0.0.1:47500_" is last in _List_ addrs by
> _IgniteUtils#inetAddressesComparator(boolean sameHost)_. But the connect
> attempts in _checkConnection(...)_ are parallel. "_127.0.0.1:47500_" answers
> first.
> # C sees it can connect to "_127.0.0.1:47500_" and chooses it as the alive
> address of B. Other pings to rest of B's addresses are ignored.
> # But "_127.0.0.1:47500_" is one of C's addresses. C realizes it pinged
> itself and decides that B is not reachable:
> {code:java}
> // If local node was able to connect to previous, confirm that it's
> alive.
> ok = liveAddr != null && (!liveAddr.getAddress().isLoopbackAddress()
> || !locNode.socketAddresses().contains(liveAddr));
> {code}
> # C accepts connection from A and answers with
> _TcpDiscoveryHandshakeResponse#previousNodeAlive() == false_
> # But B is ok now. But A connects to C and B is kicked from the ring.
> The problem is that C ping itself by B's address "_127.0.0.1:47500_"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21603) Incorrect backward connection chech with loopback address
[
https://issues.apache.org/jira/browse/IGNITE-21603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21603:
--
Summary: Incorrect backward connection chech with loopback address (was:
Incorrect bacward connection chech with loopback address)
> Incorrect backward connection chech with loopback address
> -
>
> Key: IGNITE-21603
> URL: https://issues.apache.org/jira/browse/IGNITE-21603
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Priority: Major
>
> We may skip backward connection check to a previous node if it has the same
> loopback address as the current node.
> Consider:
> # Neither _IgniteConfiguration#setLocalHost()_ or
> _TcpDiscoverySpi#setLocalAddress()_ is set. Or the localhost parameter is set
> to "_0.0.0.0_".
> # Nodes start on different hosts. All the available host addresses are
> resolved and
> # Among the other addresses, all nodes get the loopback address
> "127.0.0.1:47500" (47500 is the default tcp discovery port).
> # Cluster starts and works. But
> # Some node N (A) decides the connection to node N+1 (B) is lost and tries to
> connect to node N+2 (C) and sends _TcpDiscoveryHandshakeRequest_.
> # Before C accepts incoming A's connection, it decides to check B and pings
> it with _ServerImpl#checkConnection(List addrs, int
> timeout)_
> # Around here, the network is restored, and A can now connect to B anew.
> # "_127.0.0.1:47500_" is last in _List_ addrs by
> _IgniteUtils#inetAddressesComparator(boolean sameHost)_. But the connect
> attempts in _checkConnection(...)_ are parallel. "_127.0.0.1:47500_" answers
> first.
> # C sees it can connect to "_127.0.0.1:47500_" and chooses it as the alive
> address of B. Other pings to rest of B's addresses are ignored.
> # But "_127.0.0.1:47500_" is one of C's addresses. C realizes it pinged
> itself and decides that B is not reachable:
> {code:java}
> // If local node was able to connect to previous, confirm that it's
> alive.
> ok = liveAddr != null && (!liveAddr.getAddress().isLoopbackAddress()
> || !locNode.socketAddresses().contains(liveAddr));
> {code}
> # C accepts connection from A and answers with
> _TcpDiscoveryHandshakeResponse#previousNodeAlive() == false_
> # But B is ok now. But A connects to C and B is kicked from the ring.
> The problem is that C ping itself by B's address "_127.0.0.1:47500_"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21603) Incorrect bacward connection chech with loopback address
[
https://issues.apache.org/jira/browse/IGNITE-21603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21603:
--
Description:
We may skip backward connection check to a previous node if it has the same
loopback address as the current node.
Consider:
# Neither _IgniteConfiguration#setLocalHost()_ or
_TcpDiscoverySpi#setLocalAddress()_ is set. Or the localhost parameter is set
to "_0.0.0.0_".
# Nodes start on different hosts. All the available host addresses are resolved
and
# Among the other addresses, all nodes get the loopback address
"127.0.0.1:47500" (47500 is the default tcp discovery port).
# Cluster starts and works. But
# Some node N (A) decides the connection to node N+1 (B) is lost and tries to
connect to node N+2 (C) and sends _TcpDiscoveryHandshakeRequest_.
# Before C accepts incoming A's connection, it decides to check B and pings it
with _ServerImpl#checkConnection(List addrs, int timeout)_
# Around here, the network is restored, and A can now connect to B anew.
# "_127.0.0.1:47500_" is last in _List_ addrs by
_IgniteUtils#inetAddressesComparator(boolean sameHost)_. But the connect
attempts in _checkConnection(...)_ are parallel. "_127.0.0.1:47500_" answers
first.
# C sees it can connect to "_127.0.0.1:47500_" and chooses it as the alive
address of B. Other pings to rest of B's addresses are ignored.
# But "_127.0.0.1:47500_" is one of C's addresses. C realizes it pinged itself
and decides that B is not reachable:
{code:java}
// If local node was able to connect to previous, confirm that it's
alive.
ok = liveAddr != null && (!liveAddr.getAddress().isLoopbackAddress()
|| !locNode.socketAddresses().contains(liveAddr));
{code}
# C accepts connection from A and answers with
_TcpDiscoveryHandshakeResponse#previousNodeAlive() == false_
# But B is ok now. But A connects to C and B is kicked from the ring.
The problem is that C ping itself by B's address "_127.0.0.1:47500_"
was:
We may skip backward connection check to a previous node if it has the same
loopback address as the current node.
Consider:
# Neither _IgniteConfiguration#setLocalHost()_ or
_TcpDiscoverySpi#setLocalAddress()_ is set. Or the localhost parameter is set
to "_0.0.0.0_".
# Nodes start on different hosts. All the available host addresses are resolved
and
# Among the other addresses, all nodes get the loopback address
"127.0.0.1:47500" (47500 is the default tcp discovery port).
# Cluster starts and works. But
# Some node N (A) decides the connection to node N+1 (B) is lost and tries to
connect to node N+2 (C) and sends _TcpDiscoveryHandshakeRequest_.
# Before C accepts incoming A's connection, it decides to check B and pings it
with _ServerImpl#checkConnection(List addrs, int timeout)_
# Around here, the network is restored, and A can now connect to B anew.
# "_127.0.0.1:47500_" is last in _List_ addrs by
_IgniteUtils#inetAddressesComparator(boolean sameHost)_. But the connect
attempts in _checkConnection(...)_ are parallel. "_127.0.0.1:47500_" answers
first.
# C sees it can connect to "_127.0.0.1:47500_" and chooses it as the alive
address of B. Other pings to rest of B's addresses are ignored.
# But "_127.0.0.1:47500_" is one of C's addresses. C realizes it pinged itself
and decides that B is not reachable:
{code:java}
// If local node was able to connect to previous, confirm that it's
alive.
ok = liveAddr != null && (!liveAddr.getAddress().isLoopbackAddress()
|| !locNode.socketAddresses().contains(liveAddr));
{code}
_emphasized text_C accepts connection from A and answers with
TcpDiscoveryHandshakeResponse#previousNodeAlive() == false
# But B is ok now. But A connects to C and B is kicked from the ring.
The problem is that C ping itself by B's address "_127.0.0.1:47500_"
> Incorrect bacward connection chech with loopback address
>
>
> Key: IGNITE-21603
> URL: https://issues.apache.org/jira/browse/IGNITE-21603
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Priority: Major
>
> We may skip backward connection check to a previous node if it has the same
> loopback address as the current node.
> Consider:
> # Neither _IgniteConfiguration#setLocalHost()_ or
> _TcpDiscoverySpi#setLocalAddress()_ is set. Or the localhost parameter is set
> to "_0.0.0.0_".
> # Nodes start on different hosts. All the available host addresses are
> resolved and
> # Among the other addresses, all nodes get the loopback address
> "127.0.0.1:47500" (47500 is the default tcp discovery port).
> # Cluster starts and works. But
> # Some node N (A) decides the connection to node N+1 (B) is lost and tries to
> connect to node N+2 (C) and sends _TcpDiscoveryHandshakeRequest_.
> # Before C accepts incoming A's connection, it
[jira] [Created] (IGNITE-21603) Incorrect bacward connection chech with loopback address
Vladimir Steshin created IGNITE-21603:
-
Summary: Incorrect bacward connection chech with loopback address
Key: IGNITE-21603
URL: https://issues.apache.org/jira/browse/IGNITE-21603
Project: Ignite
Issue Type: Improvement
Reporter: Vladimir Steshin
We may skip backward connection check to a previous node if it has the same
loopback address as the current node.
Consider:
# Neither _IgniteConfiguration#setLocalHost()_ or
_TcpDiscoverySpi#setLocalAddress()_ is set. Or the localhost parameter is set
to "_0.0.0.0_".
# Nodes start on different hosts. All the available host addresses are resolved
and
# Among the other addresses, all nodes get the loopback address
"127.0.0.1:47500" (47500 is the default tcp discovery port).
# Cluster starts and works. But
# Some node N (A) decides the connection to node N+1 (B) is lost and tries to
connect to node N+2 (C) and sends _TcpDiscoveryHandshakeRequest_.
# Before C accepts incoming A's connection, it decides to check B and pings it
with _ServerImpl#checkConnection(List addrs, int timeout)_
# Around here, the network is restored, and A can now connect to B anew.
# "_127.0.0.1:47500_" is last in _List_ addrs by
_IgniteUtils#inetAddressesComparator(boolean sameHost)_. But the connect
attempts in _checkConnection(...)_ are parallel. "_127.0.0.1:47500_" answers
first.
# C sees it can connect to "_127.0.0.1:47500_" and chooses it as the alive
address of B. Other pings to rest of B's addresses are ignored.
# But "_127.0.0.1:47500_" is one of C's addresses. C realizes it pinged itself
and decides that B is not reachable:
{code:java}
// If local node was able to connect to previous, confirm that it's
alive.
ok = liveAddr != null && (!liveAddr.getAddress().isLoopbackAddress()
|| !locNode.socketAddresses().contains(liveAddr));
{code}
_emphasized text_C accepts connection from A and answers with
TcpDiscoveryHandshakeResponse#previousNodeAlive() == false
# But B is ok now. But A connects to C and B is kicked from the ring.
The problem is that C ping itself by B's address "_127.0.0.1:47500_"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21482) Fix of initialization of the last version in GridCacheVersionManager
[
https://issues.apache.org/jira/browse/IGNITE-21482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21482:
--
Description:
GridCacheVersionManager has wierd initialization of its _last_ version:
{code:java}
public void onLocalJoin(long topVer) {
long startTime = cctx.kernalContext().discovery().gridStartTime();
if (startTime != 0)
offset = (int)((startTime - TOP_VER_BASE_TIME) / 1000);
last = new GridCacheVersion(0, order.get(), 0, dataCenterId);
...
}
{code}
_topVer_, _nodeOrder_ and _offset_ are ignored. While _GridCacheVersion_ says
'_topVer Topology version plus number of seconds from the start time of the
first grid node._'. If this 'zeroed' value is read before any CRUD, a following
comparation of the versions may fail. This happened in
[IGNITE-21236|https://issues.apache.org/jira/browse/IGNITE-21236].
We should revise the initialization code. The assumed fix is:
{code:java}
last = new GridCacheVersion((int)topVer + offset, order.get(),
(int)cctx.localNode().order(), dataCenterId);
{code}
Or we should remove this last version at all. Looks like we need only the order.
was:
GridCacheVersionManager has wierd initialization of its _last_ version:
{code:java}
public void onLocalJoin(long topVer) {
long startTime = cctx.kernalContext().discovery().gridStartTime();
if (startTime != 0)
offset = (int)((startTime - TOP_VER_BASE_TIME) / 1000);
last = new GridCacheVersion(0, order.get(), 0, dataCenterId);
...
}
{code}
_topVer_, _nodeOrder_ and _offset_ are ignored. While _GridCacheVersion_ says
'_topVer Topology version plus number of seconds from the start time of the
first grid node._'. If this 'zeroed' value is read before any CRUD, a following
comparation of the versions may fail. This happened in
[IGNITE-21236|https://issues.apache.org/jira/browse/IGNITE-21236].
We should revise the initialization code. The assumed fix is:
{code:java}
last = new GridCacheVersion((int)topVer + offset, order.get(),
(int)cctx.localNode().order(), dataCenterId);
{code}
> Fix of initialization of the last version in GridCacheVersionManager
>
>
> Key: IGNITE-21482
> URL: https://issues.apache.org/jira/browse/IGNITE-21482
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> GridCacheVersionManager has wierd initialization of its _last_ version:
> {code:java}
> public void onLocalJoin(long topVer) {
> long startTime = cctx.kernalContext().discovery().gridStartTime();
> if (startTime != 0)
> offset = (int)((startTime - TOP_VER_BASE_TIME) / 1000);
> last = new GridCacheVersion(0, order.get(), 0, dataCenterId);
> ...
> }
> {code}
> _topVer_, _nodeOrder_ and _offset_ are ignored. While _GridCacheVersion_ says
> '_topVer Topology version plus number of seconds from the start time of the
> first grid node._'. If this 'zeroed' value is read before any CRUD, a
> following comparation of the versions may fail. This happened in
> [IGNITE-21236|https://issues.apache.org/jira/browse/IGNITE-21236].
> We should revise the initialization code. The assumed fix is:
> {code:java}
> last = new GridCacheVersion((int)topVer + offset, order.get(),
> (int)cctx.localNode().order(), dataCenterId);
> {code}
> Or we should remove this last version at all. Looks like we need only the
> order.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21485) Refactoring of lost code and codestyle related to GridCacheVersion
[ https://issues.apache.org/jira/browse/IGNITE-21485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21485: -- Ignite Flags: (was: Release Notes Required) > Refactoring of lost code and codestyle related to GridCacheVersion > -- > > Key: IGNITE-21485 > URL: https://issues.apache.org/jira/browse/IGNITE-21485 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Found in [IGNITE-21236|https://issues.apache.org/jira/browse/IGNITE-21236]. > We should remove some lost code, check codestyle a bit and add some asserts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21485) Refactoring of lost code and codestyle related to GridCacheVersion
[ https://issues.apache.org/jira/browse/IGNITE-21485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21485: -- Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Refactoring of lost code and codestyle related to GridCacheVersion > -- > > Key: IGNITE-21485 > URL: https://issues.apache.org/jira/browse/IGNITE-21485 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Found in [IGNITE-21236|https://issues.apache.org/jira/browse/IGNITE-21236]. > We should remove some lost code, check codestyle a bit and add some asserts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21482) Fix of initialization of the last version in GridCacheVersionManager
[
https://issues.apache.org/jira/browse/IGNITE-21482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815291#comment-17815291
]
Vladimir Steshin commented on IGNITE-21482:
---
The only usage of the _last version_ (except the _asserts_) is
inside_GridDhtPartitionsExchangeFuture_. It takes
_GridDhtPartitionsAbstractMessage#lastVersion()_. Looks like only the _order_
is used and fixing of the other fields is safe. The tests have passed.
1) _void updatePartitionFullMap(AffinityTopologyVersion resTopVer,
GridDhtPartitionsFullMessage msg)_:
{code:java}
cctx.versions().onExchange(msg.lastVersion().order());
{code}
2) _void onReceiveSingleMessage(final ClusterNode node, final
GridDhtPartitionsSingleMessage msg)_ , _updateLastVersion(msg.lastVersion())_:
{code:java}
if (old == null || Long.compare(old.order(), ver.order()) < 0)
{code}
3) _void finishExchangeOnCoordinator(@Nullable Collection
sndResNodes)_:
{code:java}
cctx.versions().onExchange(lastVer.get().order());
{code}
> Fix of initialization of the last version in GridCacheVersionManager
>
>
> Key: IGNITE-21482
> URL: https://issues.apache.org/jira/browse/IGNITE-21482
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> GridCacheVersionManager has wierd initialization of its _last_ version:
> {code:java}
> public void onLocalJoin(long topVer) {
> long startTime = cctx.kernalContext().discovery().gridStartTime();
> if (startTime != 0)
> offset = (int)((startTime - TOP_VER_BASE_TIME) / 1000);
> last = new GridCacheVersion(0, order.get(), 0, dataCenterId);
> ...
> }
> {code}
> _topVer_, _nodeOrder_ and _offset_ are ignored. While _GridCacheVersion_ says
> '_topVer Topology version plus number of seconds from the start time of the
> first grid node._'. If this 'zeroed' value is read before any CRUD, a
> following comparation of the versions may fail. This happened in
> [IGNITE-21236|https://issues.apache.org/jira/browse/IGNITE-21236].
> We should revise the initialization code. The assumed fix is:
> {code:java}
> last = new GridCacheVersion((int)topVer + offset, order.get(),
> (int)cctx.localNode().order(), dataCenterId);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21485) Refactoring of lost code and codestyle related to GridCacheVersion
[ https://issues.apache.org/jira/browse/IGNITE-21485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21485: -- Summary: Refactoring of lost code and codestyle related to GridCacheVersion (was: Refactoring of lost code, codestyle related to GridCacheVersion) > Refactoring of lost code and codestyle related to GridCacheVersion > -- > > Key: IGNITE-21485 > URL: https://issues.apache.org/jira/browse/IGNITE-21485 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Priority: Minor > > Found in [IGNITE-21236|https://issues.apache.org/jira/browse/IGNITE-21236]. > We should remove some lost code, check codestyle a bit and add some asserts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21485) Refactoring of lost code, codestyle related to GridCacheVersion
Vladimir Steshin created IGNITE-21485: - Summary: Refactoring of lost code, codestyle related to GridCacheVersion Key: IGNITE-21485 URL: https://issues.apache.org/jira/browse/IGNITE-21485 Project: Ignite Issue Type: Improvement Reporter: Vladimir Steshin Found in [IGNITE-21236|https://issues.apache.org/jira/browse/IGNITE-21236]. We should remove some lost code, check codestyle a bit and add some asserts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21482) Fix of initialization of the last version in GridCacheVersionManager
[
https://issues.apache.org/jira/browse/IGNITE-21482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21482:
--
Description:
GridCacheVersionManager has wierd initialization of its _last_ version:
{code:java}
public void onLocalJoin(long topVer) {
long startTime = cctx.kernalContext().discovery().gridStartTime();
if (startTime != 0)
offset = (int)((startTime - TOP_VER_BASE_TIME) / 1000);
last = new GridCacheVersion(0, order.get(), 0, dataCenterId);
...
}
{code}
_topVer_, _nodeOrder_ and _offset_ are ignored. While _GridCacheVersion_ says
'_topVer Topology version plus number of seconds from the start time of the
first grid node._'. If this 'zeroed' value is read before any CRUD, a following
comparation of the versions may fail. This happened in
[IGNITE-21236|https://issues.apache.org/jira/browse/IGNITE-21236].
We should revise the initialization code. The assumed fix is:
{code:java}
last = new GridCacheVersion((int)topVer + offset, order.get(),
(int)cctx.localNode().order(), dataCenterId);
{code}
was:
GridCacheVersionManager has wierd initialization of its _last_ version:
{code:java}
public void onLocalJoin(long topVer) {
long startTime = cctx.kernalContext().discovery().gridStartTime();
if (startTime != 0)
offset = (int)((startTime - TOP_VER_BASE_TIME) / 1000);
last = new GridCacheVersion(0, order.get(), 0, dataCenterId);
...
}
{code}
_topVer_, _nodeOrder_ and _offset_ are ignored. While _GridCacheVersion_ says
'_topVer Topology version plus number of seconds from the start time of the
first grid node._'. If this 'zeroed' value is read before any CRUD, a following
comparation of the versions may fail. This happened in
[IGNITE-21236|https://issues.apache.org/jira/browse/IGNITE-21236].
We should revise initialization of this value. Assumed fix is:
{code:java}
last = new GridCacheVersion((int)topVer + offset, order.get(),
(int)cctx.localNode().order(), dataCenterId);
{code}
> Fix of initialization of the last version in GridCacheVersionManager
>
>
> Key: IGNITE-21482
> URL: https://issues.apache.org/jira/browse/IGNITE-21482
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Priority: Minor
>
> GridCacheVersionManager has wierd initialization of its _last_ version:
> {code:java}
> public void onLocalJoin(long topVer) {
> long startTime = cctx.kernalContext().discovery().gridStartTime();
> if (startTime != 0)
> offset = (int)((startTime - TOP_VER_BASE_TIME) / 1000);
> last = new GridCacheVersion(0, order.get(), 0, dataCenterId);
> ...
> }
> {code}
> _topVer_, _nodeOrder_ and _offset_ are ignored. While _GridCacheVersion_ says
> '_topVer Topology version plus number of seconds from the start time of the
> first grid node._'. If this 'zeroed' value is read before any CRUD, a
> following comparation of the versions may fail. This happened in
> [IGNITE-21236|https://issues.apache.org/jira/browse/IGNITE-21236].
> We should revise the initialization code. The assumed fix is:
> {code:java}
> last = new GridCacheVersion((int)topVer + offset, order.get(),
> (int)cctx.localNode().order(), dataCenterId);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21482) Fix of initialization of the last version in GridCacheVersionManager
[
https://issues.apache.org/jira/browse/IGNITE-21482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21482:
--
Description:
GridCacheVersionManager has wierd initialization of its _last_ version:
{code:java}
public void onLocalJoin(long topVer) {
long startTime = cctx.kernalContext().discovery().gridStartTime();
if (startTime != 0)
offset = (int)((startTime - TOP_VER_BASE_TIME) / 1000);
last = new GridCacheVersion(0, order.get(), 0, dataCenterId);
...
}
{code}
_topVer_, _nodeOrder_ and _offset_ are ignored. While _GridCacheVersion_ says
'_topVer Topology version plus number of seconds from the start time of the
first grid node._'. If this 'zeroed' value is read before any CRUD, a following
comparation of the versions may fail. This happened in
[IGNITE-21236|https://issues.apache.org/jira/browse/IGNITE-21236].
We should revise initialization of this value. Assumed fix is:
{code:java}
last = new GridCacheVersion((int)topVer + offset, order.get(),
(int)cctx.localNode().order(), dataCenterId);
{code}
was:
GridCacheVersionManager has wierd initialization of its _last_ version:
{code:java}
public void onLocalJoin(long topVer) {
long startTime = cctx.kernalContext().discovery().gridStartTime();
if (startTime != 0)
offset = (int)((startTime - TOP_VER_BASE_TIME) / 1000);
last = new GridCacheVersion(0, order.get(), 0, dataCenterId);
...
}
{code}
_topVer_, _nodeOrder_ and _offset_ are ignored. While _GridCacheVersion_ says
'_topVer Topology version plus number of seconds from the start time of the
first grid node._'. If this value is read before any CRUD, a following version
comparation of the versions may fail. This happened in
[IGNITE-21236|https://issues.apache.org/jira/browse/IGNITE-21236].
We should revise initialization of this value. Assumed fix is:
{code:java}
last = new GridCacheVersion((int)topVer + offset, order.get(),
(int)cctx.localNode().order(), dataCenterId);
{code}
> Fix of initialization of the last version in GridCacheVersionManager
>
>
> Key: IGNITE-21482
> URL: https://issues.apache.org/jira/browse/IGNITE-21482
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Priority: Minor
>
> GridCacheVersionManager has wierd initialization of its _last_ version:
> {code:java}
> public void onLocalJoin(long topVer) {
> long startTime = cctx.kernalContext().discovery().gridStartTime();
> if (startTime != 0)
> offset = (int)((startTime - TOP_VER_BASE_TIME) / 1000);
> last = new GridCacheVersion(0, order.get(), 0, dataCenterId);
> ...
> }
> {code}
> _topVer_, _nodeOrder_ and _offset_ are ignored. While _GridCacheVersion_ says
> '_topVer Topology version plus number of seconds from the start time of the
> first grid node._'. If this 'zeroed' value is read before any CRUD, a
> following comparation of the versions may fail. This happened in
> [IGNITE-21236|https://issues.apache.org/jira/browse/IGNITE-21236].
> We should revise initialization of this value. Assumed fix is:
> {code:java}
> last = new GridCacheVersion((int)topVer + offset, order.get(),
> (int)cctx.localNode().order(), dataCenterId);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21482) Fix of initialization of the last version in GridCacheVersionManager
[
https://issues.apache.org/jira/browse/IGNITE-21482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21482:
--
Description:
GridCacheVersionManager has wierd initialization of its last version:
{code:java}
public void onLocalJoin(long topVer) {
long startTime = cctx.kernalContext().discovery().gridStartTime();
if (startTime != 0)
offset = (int)((startTime - TOP_VER_BASE_TIME) / 1000);
last = new GridCacheVersion(0, order.get(), 0, dataCenterId);
...
}
{code}
_topVer_, _nodeOrder_ and _offset_ are ignored. While _GridCacheVersion_ says
'_topVer Topology version plus number of seconds from the start time of the
first grid node._'. If this value is read before any CRUD, a following version
comparation of the versions may fail. This happened in
[IGNITE-21236|https://issues.apache.org/jira/browse/IGNITE-21236].
We should revise initialization of this value. Assumed fix is:
{code:java}
last = new GridCacheVersion((int)topVer + offset, order.get(),
(int)cctx.localNode().order(), dataCenterId);
{code}
was:
GridCacheVersionManager has wierd initialization of its last version:
{code:java}
public void onLocalJoin(long topVer) {
long startTime = cctx.kernalContext().discovery().gridStartTime();
if (startTime != 0)
offset = (int)((startTime - TOP_VER_BASE_TIME) / 1000);
last = new GridCacheVersion(0, order.get(), 0, dataCenterId);
...
}
{code}
_topVer_, _nodeOrder_ and _offset_ are ignored. While _GridCacheVersion_ says
'_topVer Topology version plus number of seconds from the start time of the
first grid node._'. If this value is read before any CRUD, followinf version
comparation of the version may fail. This happened in [link
title|http://example.com]
> Fix of initialization of the last version in GridCacheVersionManager
>
>
> Key: IGNITE-21482
> URL: https://issues.apache.org/jira/browse/IGNITE-21482
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Priority: Minor
>
> GridCacheVersionManager has wierd initialization of its last version:
> {code:java}
> public void onLocalJoin(long topVer) {
> long startTime = cctx.kernalContext().discovery().gridStartTime();
> if (startTime != 0)
> offset = (int)((startTime - TOP_VER_BASE_TIME) / 1000);
> last = new GridCacheVersion(0, order.get(), 0, dataCenterId);
> ...
> }
> {code}
> _topVer_, _nodeOrder_ and _offset_ are ignored. While _GridCacheVersion_ says
> '_topVer Topology version plus number of seconds from the start time of the
> first grid node._'. If this value is read before any CRUD, a following
> version comparation of the versions may fail. This happened in
> [IGNITE-21236|https://issues.apache.org/jira/browse/IGNITE-21236].
> We should revise initialization of this value. Assumed fix is:
> {code:java}
> last = new GridCacheVersion((int)topVer + offset, order.get(),
> (int)cctx.localNode().order(), dataCenterId);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21482) Fix of initialization of the last version in GridCacheVersionManager
[
https://issues.apache.org/jira/browse/IGNITE-21482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21482:
--
Description:
GridCacheVersionManager has wierd initialization of its _last_ version:
{code:java}
public void onLocalJoin(long topVer) {
long startTime = cctx.kernalContext().discovery().gridStartTime();
if (startTime != 0)
offset = (int)((startTime - TOP_VER_BASE_TIME) / 1000);
last = new GridCacheVersion(0, order.get(), 0, dataCenterId);
...
}
{code}
_topVer_, _nodeOrder_ and _offset_ are ignored. While _GridCacheVersion_ says
'_topVer Topology version plus number of seconds from the start time of the
first grid node._'. If this value is read before any CRUD, a following version
comparation of the versions may fail. This happened in
[IGNITE-21236|https://issues.apache.org/jira/browse/IGNITE-21236].
We should revise initialization of this value. Assumed fix is:
{code:java}
last = new GridCacheVersion((int)topVer + offset, order.get(),
(int)cctx.localNode().order(), dataCenterId);
{code}
was:
GridCacheVersionManager has wierd initialization of its last version:
{code:java}
public void onLocalJoin(long topVer) {
long startTime = cctx.kernalContext().discovery().gridStartTime();
if (startTime != 0)
offset = (int)((startTime - TOP_VER_BASE_TIME) / 1000);
last = new GridCacheVersion(0, order.get(), 0, dataCenterId);
...
}
{code}
_topVer_, _nodeOrder_ and _offset_ are ignored. While _GridCacheVersion_ says
'_topVer Topology version plus number of seconds from the start time of the
first grid node._'. If this value is read before any CRUD, a following version
comparation of the versions may fail. This happened in
[IGNITE-21236|https://issues.apache.org/jira/browse/IGNITE-21236].
We should revise initialization of this value. Assumed fix is:
{code:java}
last = new GridCacheVersion((int)topVer + offset, order.get(),
(int)cctx.localNode().order(), dataCenterId);
{code}
> Fix of initialization of the last version in GridCacheVersionManager
>
>
> Key: IGNITE-21482
> URL: https://issues.apache.org/jira/browse/IGNITE-21482
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Priority: Minor
>
> GridCacheVersionManager has wierd initialization of its _last_ version:
> {code:java}
> public void onLocalJoin(long topVer) {
> long startTime = cctx.kernalContext().discovery().gridStartTime();
> if (startTime != 0)
> offset = (int)((startTime - TOP_VER_BASE_TIME) / 1000);
> last = new GridCacheVersion(0, order.get(), 0, dataCenterId);
> ...
> }
> {code}
> _topVer_, _nodeOrder_ and _offset_ are ignored. While _GridCacheVersion_ says
> '_topVer Topology version plus number of seconds from the start time of the
> first grid node._'. If this value is read before any CRUD, a following
> version comparation of the versions may fail. This happened in
> [IGNITE-21236|https://issues.apache.org/jira/browse/IGNITE-21236].
> We should revise initialization of this value. Assumed fix is:
> {code:java}
> last = new GridCacheVersion((int)topVer + offset, order.get(),
> (int)cctx.localNode().order(), dataCenterId);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21482) Fix of initialization of the last version in GridCacheVersionManager
[
https://issues.apache.org/jira/browse/IGNITE-21482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21482:
--
Description:
GridCacheVersionManager has wierd initialization of its last version:
{code:java}
public void onLocalJoin(long topVer) {
long startTime = cctx.kernalContext().discovery().gridStartTime();
if (startTime != 0)
offset = (int)((startTime - TOP_VER_BASE_TIME) / 1000);
last = new GridCacheVersion(0, order.get(), 0, dataCenterId);
...
}
{code}
_topVer_, _nodeOrder_ and _offset_ are ignored. While _GridCacheVersion_ says
'_topVer Topology version plus number of seconds from the start time of the
first grid node._'. If this value is read before any CRUD, followinf version
comparation of the version may fail. This happened in [link
title|http://example.com]
> Fix of initialization of the last version in GridCacheVersionManager
>
>
> Key: IGNITE-21482
> URL: https://issues.apache.org/jira/browse/IGNITE-21482
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Priority: Minor
>
> GridCacheVersionManager has wierd initialization of its last version:
> {code:java}
> public void onLocalJoin(long topVer) {
> long startTime = cctx.kernalContext().discovery().gridStartTime();
> if (startTime != 0)
> offset = (int)((startTime - TOP_VER_BASE_TIME) / 1000);
> last = new GridCacheVersion(0, order.get(), 0, dataCenterId);
> ...
> }
> {code}
> _topVer_, _nodeOrder_ and _offset_ are ignored. While _GridCacheVersion_ says
> '_topVer Topology version plus number of seconds from the start time of the
> first grid node._'. If this value is read before any CRUD, followinf version
> comparation of the version may fail. This happened in [link
> title|http://example.com]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21482) Fix of initialization of the last version in GridCacheVersionManager
Vladimir Steshin created IGNITE-21482: - Summary: Fix of initialization of the last version in GridCacheVersionManager Key: IGNITE-21482 URL: https://issues.apache.org/jira/browse/IGNITE-21482 Project: Ignite Issue Type: Improvement Reporter: Vladimir Steshin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21482) Fix of initialization of the last version in GridCacheVersionManager
[ https://issues.apache.org/jira/browse/IGNITE-21482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21482: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Fix of initialization of the last version in GridCacheVersionManager > > > Key: IGNITE-21482 > URL: https://issues.apache.org/jira/browse/IGNITE-21482 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21236) Handle DataStreamer entry version in dump
[
https://issues.apache.org/jira/browse/IGNITE-21236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813955#comment-17813955
]
Vladimir Steshin commented on IGNITE-21236:
---
It fails also for the caches filled with the cache API. Not only with the
streamer. The problem seems to rise from wierd initialization
_GridCacheVersionManager#last_:
{code:java}
public void onLocalJoin(long topVer) {
long startTime = cctx.kernalContext().discovery().gridStartTime();
if (startTime != 0)
offset = (int)((startTime - TOP_VER_BASE_TIME) / 1000);
last = new GridCacheVersion(0, order.get(), 0, dataCenterId);
...
}
{code}
It ignores _topVer_, _nodeOrder_ and _offset_. While _GridCacheVersion_ says
'_topVer Topology version plus number of seconds from the start time of the
first grid node._'
> Handle DataStreamer entry version in dump
> -
>
> Key: IGNITE-21236
> URL: https://issues.apache.org/jira/browse/IGNITE-21236
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Timonin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: IEP-109, ise
> Attachments: IgniteCacheDumpSelfTest2.java
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> DataStreamer writes entries with fixed GridCacheVersion, that is greater than
> any existing version.
> During dump creation it filters all such entries by version, and no entries
> created by data streamer lands into the dump.
> Possible solution is to apply all entries with this DataStreamer version to
> dump. Other hand, it might make the dump inconsistent when it's created
> parallel to DataStreamer activity (we have the warn for this case in
> Snapshots already)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21236) Handle DataStreamer entry version in dump
[ https://issues.apache.org/jira/browse/IGNITE-21236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21236: -- Attachment: IgniteCacheDumpSelfTest2.java > Handle DataStreamer entry version in dump > - > > Key: IGNITE-21236 > URL: https://issues.apache.org/jira/browse/IGNITE-21236 > Project: Ignite > Issue Type: Improvement >Reporter: Maksim Timonin >Assignee: Vladimir Steshin >Priority: Major > Labels: IEP-109, ise > Attachments: IgniteCacheDumpSelfTest2.java > > Time Spent: 0.5h > Remaining Estimate: 0h > > DataStreamer writes entries with fixed GridCacheVersion, that is greater than > any existing version. > During dump creation it filters all such entries by version, and no entries > created by data streamer lands into the dump. > Possible solution is to apply all entries with this DataStreamer version to > dump. Other hand, it might make the dump inconsistent when it's created > parallel to DataStreamer activity (we have the warn for this case in > Snapshots already) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21236) Handle DataStreamer entry version in dump
[ https://issues.apache.org/jira/browse/IGNITE-21236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-21236: - Assignee: Vladimir Steshin > Handle DataStreamer entry version in dump > - > > Key: IGNITE-21236 > URL: https://issues.apache.org/jira/browse/IGNITE-21236 > Project: Ignite > Issue Type: Improvement >Reporter: Maksim Timonin >Assignee: Vladimir Steshin >Priority: Major > Labels: IEP-109, ise > > DataStreamer writes entries with fixed GridCacheVersion, that is greater than > any existing version. > During dump creation it filters all such entries by version, and no entries > created by data streamer lands into the dump. > Possible solution is to apply all entries with this DataStreamer version to > dump. Other hand, it might make the dump inconsistent when it's created > parallel to DataStreamer activity (we have the warn for this case in > Snapshots already) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21350) Primary key index from cache dump doesn't match the original one.
[ https://issues.apache.org/jira/browse/IGNITE-21350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21350: -- Priority: Minor (was: Major) > Primary key index from cache dump doesn't match the original one. > - > > Key: IGNITE-21350 > URL: https://issues.apache.org/jira/browse/IGNITE-21350 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Priority: Minor > Labels: ise > Attachments: IgniteRestoreDDLIndexDumpTest.java > > > The primary index is not correctly read from a cache dump. At least for > DDL-created caches/tables. Index columns are different. See the test. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21350) Primary key index from cache dump doesn't match the original one.
[ https://issues.apache.org/jira/browse/IGNITE-21350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21350: -- Attachment: (was: IgniteRestoreDDLIndexDumpTest.java) > Primary key index from cache dump doesn't match the original one. > - > > Key: IGNITE-21350 > URL: https://issues.apache.org/jira/browse/IGNITE-21350 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Priority: Major > Labels: ise > Attachments: IgniteRestoreDDLIndexDumpTest.java > > > The primary index is not correctly read from a cache dump. At least for > DDL-created caches/tables. Index columns are different. See the test. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21350) Primary key index from cache dump doesn't match the original one.
[ https://issues.apache.org/jira/browse/IGNITE-21350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21350: -- Attachment: IgniteRestoreDDLIndexDumpTest-1.java > Primary key index from cache dump doesn't match the original one. > - > > Key: IGNITE-21350 > URL: https://issues.apache.org/jira/browse/IGNITE-21350 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Priority: Major > Labels: ise > Attachments: IgniteRestoreDDLIndexDumpTest.java > > > The primary index is not correctly read from a cache dump. At least for > DDL-created caches/tables. Index columns are different. See the test. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21350) Primary key index from cache dump doesn't match the original one.
[ https://issues.apache.org/jira/browse/IGNITE-21350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21350: -- Attachment: (was: IgniteRestoreDDLIndexDumpTest-1.java) > Primary key index from cache dump doesn't match the original one. > - > > Key: IGNITE-21350 > URL: https://issues.apache.org/jira/browse/IGNITE-21350 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Priority: Major > Labels: ise > Attachments: IgniteRestoreDDLIndexDumpTest.java > > > The primary index is not correctly read from a cache dump. At least for > DDL-created caches/tables. Index columns are different. See the test. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21350) Primary key index from cache dump doesn't match the original one.
[ https://issues.apache.org/jira/browse/IGNITE-21350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21350: -- Attachment: IgniteRestoreDDLIndexDumpTest.java > Primary key index from cache dump doesn't match the original one. > - > > Key: IGNITE-21350 > URL: https://issues.apache.org/jira/browse/IGNITE-21350 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Priority: Major > Labels: ise > Attachments: IgniteRestoreDDLIndexDumpTest.java > > > The primary index is not correctly read from a cache dump. At least for > DDL-created caches/tables. Index columns are different. See the test. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21350) Primary key index from cache dump doesn't match the original one.
[ https://issues.apache.org/jira/browse/IGNITE-21350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21350: -- Description: The primary index is not correctly read from a cache dump. At least for DDL-created caches/tables. Index columns are different. See the test. (was: The indexes are not correctly restored from cache dumps. At least for DDL-created caches/tables. Neither dumped CacheConfiguration or StoredCacheData doesn't contain entire indexes info. Moreover, StoredCacheData is the internal and should not be used at all (see [1]). Test attached. [1] https://issues.apache.org/jira/browse/IGNITE-21333) > Primary key index from cache dump doesn't match the original one. > - > > Key: IGNITE-21350 > URL: https://issues.apache.org/jira/browse/IGNITE-21350 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Priority: Major > Labels: ise > Attachments: IgniteRestoreDDLIndexDumpTest.java > > > The primary index is not correctly read from a cache dump. At least for > DDL-created caches/tables. Index columns are different. See the test. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21350) Primary key index from cache dump doesn't match the original one.
[ https://issues.apache.org/jira/browse/IGNITE-21350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21350: -- Summary: Primary key index from cache dump doesn't match the original one. (was: Indexes are corrupted after restoring for a dump.) > Primary key index from cache dump doesn't match the original one. > - > > Key: IGNITE-21350 > URL: https://issues.apache.org/jira/browse/IGNITE-21350 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Priority: Major > Labels: ise > Attachments: IgniteRestoreDDLIndexDumpTest.java > > > The indexes are not correctly restored from cache dumps. At least for > DDL-created caches/tables. Neither dumped CacheConfiguration or > StoredCacheData doesn't contain entire indexes info. Moreover, > StoredCacheData is the internal and should not be used at all (see [1]). Test > attached. > [1] https://issues.apache.org/jira/browse/IGNITE-21333 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21350) Indexes are corrupted after restoring for a dump.
[ https://issues.apache.org/jira/browse/IGNITE-21350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21350: -- Labels: ise (was: ) > Indexes are corrupted after restoring for a dump. > - > > Key: IGNITE-21350 > URL: https://issues.apache.org/jira/browse/IGNITE-21350 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Priority: Major > Labels: ise > Attachments: IgniteRestoreDDLIndexDumpTest.java > > > The indexes are not correctly restored from cache dumps. At least for > DDL-created caches/tables. Neither dumped CacheConfiguration or > StoredCacheData doesn't contain entire indexes info. Moreover, > StoredCacheData is the internal and should not be used at all (see [1]). Test > attached. > [1] https://issues.apache.org/jira/browse/IGNITE-21333 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21350) Indexes are corrupted after restoring for a dump.
[ https://issues.apache.org/jira/browse/IGNITE-21350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21350: -- Description: The indexes are not correctly restored from cache dumps. At least for DDL-created caches/tables. Neither dumped CacheConfiguration or StoredCacheData doesn't contain entire indexes info. Moreover, StoredCacheData is the internal and should not be used at all (see [1]). Test attached. [1] https://issues.apache.org/jira/browse/IGNITE-21333 was: The indexes are not correctly restored from cache dumps. At least for DDL-created caches/tables. Neither dumped CacheConfiguration or StoredCacheData doesn't contain entire indexes info. Moreover, StoredCacheData is the internal and should not be used at all (see [1]). Test attached. [1] https://issues.apache.org/jira/browse/IGNITE-21333? > Indexes are corrupted after restoring for a dump. > - > > Key: IGNITE-21350 > URL: https://issues.apache.org/jira/browse/IGNITE-21350 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Priority: Major > Attachments: IgniteRestoreDDLIndexDumpTest.java > > > The indexes are not correctly restored from cache dumps. At least for > DDL-created caches/tables. Neither dumped CacheConfiguration or > StoredCacheData doesn't contain entire indexes info. Moreover, > StoredCacheData is the internal and should not be used at all (see [1]). Test > attached. > [1] https://issues.apache.org/jira/browse/IGNITE-21333 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21350) Indexes are corrupted after restoring for a dump.
[ https://issues.apache.org/jira/browse/IGNITE-21350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21350: -- Attachment: IgniteRestoreDDLIndexDumpTest.java > Indexes are corrupted after restoring for a dump. > - > > Key: IGNITE-21350 > URL: https://issues.apache.org/jira/browse/IGNITE-21350 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Priority: Major > Attachments: IgniteRestoreDDLIndexDumpTest.java > > > The indexes are not correctly restored from cache dumps. At least for > DDL-created caches/tables. Neither dumped CacheConfiguration or > StoredCacheData doesn't contain entire indexes info. Moreover, > StoredCacheData is the internal and should not be used at all (see [1]). Test > attached. > [1] https://issues.apache.org/jira/browse/IGNITE-21333? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21350) Indexes are corrupted after restoring for a dump.
Vladimir Steshin created IGNITE-21350: - Summary: Indexes are corrupted after restoring for a dump. Key: IGNITE-21350 URL: https://issues.apache.org/jira/browse/IGNITE-21350 Project: Ignite Issue Type: Bug Reporter: Vladimir Steshin The indexes are not correctly restored from cache dumps. At least for DDL-created caches/tables. Neither dumped CacheConfiguration or StoredCacheData doesn't contain entire indexes info. Moreover, StoredCacheData is the internal and should not be used at all (see [1]). Test attached. [1] https://issues.apache.org/jira/browse/IGNITE-21333? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21338) Add affinity function to ClientCacheConfiguration
[ https://issues.apache.org/jira/browse/IGNITE-21338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21338: -- Labels: ise (was: ) > Add affinity function to ClientCacheConfiguration > - > > Key: IGNITE-21338 > URL: https://issues.apache.org/jira/browse/IGNITE-21338 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Priority: Major > Labels: ise > > Currently, ClientCacheConfiguration has no the affinity function parameter. > The thin client should have an ability to set it for the cache it creates. > Without it, for instance, user may not properly restore a cache from a cache > dump using the thin client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21338) Add affinity function to ClientCacheConfiguration
Vladimir Steshin created IGNITE-21338: - Summary: Add affinity function to ClientCacheConfiguration Key: IGNITE-21338 URL: https://issues.apache.org/jira/browse/IGNITE-21338 Project: Ignite Issue Type: Improvement Reporter: Vladimir Steshin Currently, ClientCacheConfiguration has no the affinity function parameter. The thin client should have an ability to set it for the cache it creates. Without it, for instance, user may not properly restore a cache from a cache dump using the thin client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21333) Remove internal class from the dump consumer public API
[
https://issues.apache.org/jira/browse/IGNITE-21333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21333:
--
Description:
{code:java}
org.apache.ignite.dump.DumpConsumer
{code}
is a public API. But it has an internal class StoredCacheData as a parameter in
{code:java}
void onCacheConfigs(Iterator caches);
{code}
We should change it to CacheConfiguration. Or we may consider what part of
CacheConfiguration's a user wants to get.
was:
{code:java}
org.apache.ignite.dump.DumpConsumer
{code}
is a public API. But it has an internal class StoredCacheData as a parameter in
{code:java}
void onCacheConfigs(Iterator caches);
{code}
We should change it to CacheConfiguration. Or we may consider what part of
CacheConfiguration's a user wanted to get.
> Remove internal class from the dump consumer public API
> ---
>
> Key: IGNITE-21333
> URL: https://issues.apache.org/jira/browse/IGNITE-21333
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
>
> {code:java}
> org.apache.ignite.dump.DumpConsumer
> {code}
> is a public API. But it has an internal class StoredCacheData as a parameter
> in
> {code:java}
> void onCacheConfigs(Iterator caches);
> {code}
> We should change it to CacheConfiguration. Or we may consider what part of
> CacheConfiguration's a user wants to get.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21333) Remove internal class from the dump consumer public API
Vladimir Steshin created IGNITE-21333:
-
Summary: Remove internal class from the dump consumer public API
Key: IGNITE-21333
URL: https://issues.apache.org/jira/browse/IGNITE-21333
Project: Ignite
Issue Type: Bug
Reporter: Vladimir Steshin
{code:java}
org.apache.ignite.dump.DumpConsumer
{code}
is a public API. But it has an internal class StoredCacheData as a parameter in
{code:java}
void onCacheConfigs(Iterator caches);
{code}
We should change it to CacheConfiguration. Or we may consider which
CacheConfiguration's data user wanted to get.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21333) Remove internal class from the dump consumer public API
[
https://issues.apache.org/jira/browse/IGNITE-21333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21333:
--
Description:
{code:java}
org.apache.ignite.dump.DumpConsumer
{code}
is a public API. But it has an internal class StoredCacheData as a parameter in
{code:java}
void onCacheConfigs(Iterator caches);
{code}
We should change it to CacheConfiguration. Or we may consider what part of
CacheConfiguration's a user wanted to get.
was:
{code:java}
org.apache.ignite.dump.DumpConsumer
{code}
is a public API. But it has an internal class StoredCacheData as a parameter in
{code:java}
void onCacheConfigs(Iterator caches);
{code}
We should change it to CacheConfiguration. Or we may consider which
CacheConfiguration's data user wanted to get.
> Remove internal class from the dump consumer public API
> ---
>
> Key: IGNITE-21333
> URL: https://issues.apache.org/jira/browse/IGNITE-21333
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
>
> {code:java}
> org.apache.ignite.dump.DumpConsumer
> {code}
> is a public API. But it has an internal class StoredCacheData as a parameter
> in
> {code:java}
> void onCacheConfigs(Iterator caches);
> {code}
> We should change it to CacheConfiguration. Or we may consider what part of
> CacheConfiguration's a user wanted to get.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21333) Remove internal class from the dump consumer public API
[
https://issues.apache.org/jira/browse/IGNITE-21333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21333:
--
Labels: ise (was: )
> Remove internal class from the dump consumer public API
> ---
>
> Key: IGNITE-21333
> URL: https://issues.apache.org/jira/browse/IGNITE-21333
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
>
> {code:java}
> org.apache.ignite.dump.DumpConsumer
> {code}
> is a public API. But it has an internal class StoredCacheData as a parameter
> in
> {code:java}
> void onCacheConfigs(Iterator caches);
> {code}
> We should change it to CacheConfiguration. Or we may consider which
> CacheConfiguration's data user wanted to get.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (IGNITE-21165) .NET platform test timeouts after ClientServerCompatibilityTest
[ https://issues.apache.org/jira/browse/IGNITE-21165 ]
Vladimir Steshin deleted comment on IGNITE-21165:
---
was (Author: vladsz83):
[~ptupitsyn], could you take a look please? The timeouts have gone.
> .NET platform test timeouts after ClientServerCompatibilityTest
> ---
>
> Key: IGNITE-21165
> URL: https://issues.apache.org/jira/browse/IGNITE-21165
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
> Attachments:
> Ignite_Tests_2.x_JDK_8_11_Platform_.NET_Core_Linux_39429.log.zip
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There are many timeouted test runs in the .NET suite. Example:
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
> {code:java}
> The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
> {buildId=7678070} has been running for more than 40 minutes. Terminating...
> {code}
> Looks like only port 47500 is requested while server node started on another.
> Probably a previous test didn't release the port yet.
> {code:java}
> Successfully bound communication NIO server to TCP port [port=47101,
> locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
> {code}
> {code:java}
> Failed to connect to any address from IP finder (make sure IP finder
> addresses are correct and firewalls are disabled on all host machines):
> [/127.0.0.1:47500]
> {code}
> It looks like this issue happens on JDK8 only. And only on Linux.
> _ClientServerCompatibilityTest_ starts a server node with _Runner.java_,
> _PlatformProcessUtils#startProcess()_ and stops with
> _PlatformProcessUtils#destriyProcess()_. On Windows, additional
> {code:java}
> serverProc.KillProcessTree();
> {code}
> is applied.
> We should wait until _java.lang.Process_ completely stops.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21165) .NET platform test timeouts after ClientServerCompatibilityTest
[
https://issues.apache.org/jira/browse/IGNITE-21165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21165:
--
Description:
There are many timeouted test runs in the .NET suite. Example:
https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
{code:java}
The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
{buildId=7678070} has been running for more than 40 minutes. Terminating...
{code}
Looks like only port 47500 is requested while server node started on another.
Probably a previous test didn't release the port yet.
{code:java}
Successfully bound communication NIO server to TCP port [port=47101,
locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
{code}
{code:java}
Failed to connect to any address from IP finder (make sure IP finder addresses
are correct and firewalls are disabled on all host machines): [/127.0.0.1:47500]
{code}
It looks like this issue happens on JDK8 only. And only on Linux.
_ClientServerCompatibilityTest_ starts a server node with _Runner.java_,
_PlatformProcessUtils#startProcess()_ and stops with
_PlatformProcessUtils#destriyProcess()_. On Windows, additional
{code:java}
serverProc.KillProcessTree();
{code}
is applied.
We should wait until _java.lang.Process_ completely stops.
was:
There are many timeouted test runs in the .NET suite. Example:
https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
{code:java}
The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
{buildId=7678070} has been running for more than 40 minutes. Terminating...
{code}
Looks like only port 47500 is requested while server node started on another.
Probably a previous test didn't release the port yet.
{code:java}
Successfully bound communication NIO server to TCP port [port=47101,
locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
{code}
{code:java}
Failed to connect to any address from IP finder (make sure IP finder addresses
are correct and firewalls are disabled on all host machines): [/127.0.0.1:47500]
{code}
It looks like this issue happens on JDK8 only. And only on Linux.
_ClientServerCompatibilityTest_ starts a server node with _Runner.java_,
_PlatformProcessUtils#startProcess()_ and stops with
_PlatformProcessUtils#stopProcess()_. On Windows, additional
{code:java}
serverProc.KillProcessTree();
{code}
is applied.
We should wait until _java.lang.Process_ completely stops.
> .NET platform test timeouts after ClientServerCompatibilityTest
> ---
>
> Key: IGNITE-21165
> URL: https://issues.apache.org/jira/browse/IGNITE-21165
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
> Attachments:
> Ignite_Tests_2.x_JDK_8_11_Platform_.NET_Core_Linux_39429.log.zip
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There are many timeouted test runs in the .NET suite. Example:
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
> {code:java}
> The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
> {buildId=7678070} has been running for more than 40 minutes. Terminating...
> {code}
> Looks like only port 47500 is requested while server node started on another.
> Probably a previous test didn't release the port yet.
> {code:java}
> Successfully bound communication NIO server to TCP port [port=47101,
> locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
> {code}
> {code:java}
> Failed to connect to any address from IP finder (make sure IP finder
> addresses are correct and firewalls are disabled on all host machines):
> [/127.0.0.1:47500]
> {code}
> It looks like this issue happens on JDK8 only. And only on Linux.
> _ClientServerCompatibilityTest_ starts a server node with _Runner.java_,
> _PlatformProcessUtils#startProcess()_ and stops with
> _PlatformProcessUtils#destriyProcess()_. On Windows, additional
> {code:java}
> serverProc.KillProcessTree();
> {code}
> is applied.
> We should wait until _java.lang.Process_ completely stops.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21163) .NET platform test timeouts
[
https://issues.apache.org/jira/browse/IGNITE-21163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin reassigned IGNITE-21163:
-
Assignee: Vladimir Steshin
> .NET platform test timeouts
> ---
>
> Key: IGNITE-21163
> URL: https://issues.apache.org/jira/browse/IGNITE-21163
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>
> There are many timeouted test runs in the .NET suite. For example:
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
> "The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
> {buildId=7678070} has been running for more than 40 minutes. Terminating..."
> Looks like only port 47500 is requested while server node started on another.
> Probably a previous test didn't release the port yet.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21165) .NET platform test timeouts after ClientServerCompatibilityTest
[
https://issues.apache.org/jira/browse/IGNITE-21165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804644#comment-17804644
]
Vladimir Steshin commented on IGNITE-21165:
---
[~ptupitsyn], could you take a look please? The timeouts have gone.
> .NET platform test timeouts after ClientServerCompatibilityTest
> ---
>
> Key: IGNITE-21165
> URL: https://issues.apache.org/jira/browse/IGNITE-21165
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
> Attachments:
> Ignite_Tests_2.x_JDK_8_11_Platform_.NET_Core_Linux_39429.log.zip
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There are many timeouted test runs in the .NET suite. Example:
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
> {code:java}
> The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
> {buildId=7678070} has been running for more than 40 minutes. Terminating...
> {code}
> Looks like only port 47500 is requested while server node started on another.
> Probably a previous test didn't release the port yet.
> {code:java}
> Successfully bound communication NIO server to TCP port [port=47101,
> locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
> {code}
> {code:java}
> Failed to connect to any address from IP finder (make sure IP finder
> addresses are correct and firewalls are disabled on all host machines):
> [/127.0.0.1:47500]
> {code}
> It looks like this issue happens on JDK8 only. And only on Linux.
> _ClientServerCompatibilityTest_ starts a server node with _Runner.java_,
> _PlatformProcessUtils#startProcess()_ and stops with
> _PlatformProcessUtils#stopProcess()_. On Windows, additional
> {code:java}
> serverProc.KillProcessTree();
> {code}
> is applied.
> We should wait until _java.lang.Process_ completely stops.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21165) .NET platform test timeouts after ClientServerCompatibilityTest
[
https://issues.apache.org/jira/browse/IGNITE-21165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21165:
--
Description:
There are many timeouted test runs in the .NET suite. Example:
https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
{code:java}
The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
{buildId=7678070} has been running for more than 40 minutes. Terminating...
{code}
Looks like only port 47500 is requested while server node started on another.
Probably a previous test didn't release the port yet.
{code:java}
Successfully bound communication NIO server to TCP port [port=47101,
locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
{code}
{code:java}
Failed to connect to any address from IP finder (make sure IP finder addresses
are correct and firewalls are disabled on all host machines): [/127.0.0.1:47500]
{code}
It looks like this issue happens on JDK8 only. And only on Linux.
_ClientServerCompatibilityTest_ starts a server node with _Runner.java_,
_PlatformProcessUtils#startProcess()_ and stops with
_PlatformProcessUtils#stopProcess()_. On Windows, additional
{code:java}
serverProc.KillProcessTree();
{code}
is applied.
was:
There are many timeouted test runs in the .NET suite. Example:
https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
{code:java}
The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
{buildId=7678070} has been running for more than 40 minutes. Terminating...
{code}
Looks like only port 47500 is requested while server node started on another.
Probably a previous test didn't release the port yet.
{code:java}
Successfully bound communication NIO server to TCP port [port=47101,
locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
{code}
{code:java}
Failed to connect to any address from IP finder (make sure IP finder addresses
are correct and firewalls are disabled on all host machines): [/127.0.0.1:47500]
{code}
It looks like happens on JDK8 only. And only on Linux.
> .NET platform test timeouts after ClientServerCompatibilityTest
> ---
>
> Key: IGNITE-21165
> URL: https://issues.apache.org/jira/browse/IGNITE-21165
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
> Attachments:
> Ignite_Tests_2.x_JDK_8_11_Platform_.NET_Core_Linux_39429.log.zip
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There are many timeouted test runs in the .NET suite. Example:
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
> {code:java}
> The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
> {buildId=7678070} has been running for more than 40 minutes. Terminating...
> {code}
> Looks like only port 47500 is requested while server node started on another.
> Probably a previous test didn't release the port yet.
> {code:java}
> Successfully bound communication NIO server to TCP port [port=47101,
> locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
> {code}
> {code:java}
> Failed to connect to any address from IP finder (make sure IP finder
> addresses are correct and firewalls are disabled on all host machines):
> [/127.0.0.1:47500]
> {code}
> It looks like this issue happens on JDK8 only. And only on Linux.
> _ClientServerCompatibilityTest_ starts a server node with _Runner.java_,
> _PlatformProcessUtils#startProcess()_ and stops with
> _PlatformProcessUtils#stopProcess()_. On Windows, additional
> {code:java}
> serverProc.KillProcessTree();
> {code}
> is applied.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21165) .NET platform test timeouts after ClientServerCompatibilityTest
[
https://issues.apache.org/jira/browse/IGNITE-21165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21165:
--
Description:
There are many timeouted test runs in the .NET suite. Example:
https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
{code:java}
The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
{buildId=7678070} has been running for more than 40 minutes. Terminating...
{code}
Looks like only port 47500 is requested while server node started on another.
Probably a previous test didn't release the port yet.
{code:java}
Successfully bound communication NIO server to TCP port [port=47101,
locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
{code}
{code:java}
Failed to connect to any address from IP finder (make sure IP finder addresses
are correct and firewalls are disabled on all host machines): [/127.0.0.1:47500]
{code}
It looks like this issue happens on JDK8 only. And only on Linux.
_ClientServerCompatibilityTest_ starts a server node with _Runner.java_,
_PlatformProcessUtils#startProcess()_ and stops with
_PlatformProcessUtils#stopProcess()_. On Windows, additional
{code:java}
serverProc.KillProcessTree();
{code}
is applied.
We should wait until _java.lang.Process_ completely stops.
was:
There are many timeouted test runs in the .NET suite. Example:
https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
{code:java}
The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
{buildId=7678070} has been running for more than 40 minutes. Terminating...
{code}
Looks like only port 47500 is requested while server node started on another.
Probably a previous test didn't release the port yet.
{code:java}
Successfully bound communication NIO server to TCP port [port=47101,
locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
{code}
{code:java}
Failed to connect to any address from IP finder (make sure IP finder addresses
are correct and firewalls are disabled on all host machines): [/127.0.0.1:47500]
{code}
It looks like this issue happens on JDK8 only. And only on Linux.
_ClientServerCompatibilityTest_ starts a server node with _Runner.java_,
_PlatformProcessUtils#startProcess()_ and stops with
_PlatformProcessUtils#stopProcess()_. On Windows, additional
{code:java}
serverProc.KillProcessTree();
{code}
is applied.
We shoul wait until _java.lang.Process_ completely stops.
> .NET platform test timeouts after ClientServerCompatibilityTest
> ---
>
> Key: IGNITE-21165
> URL: https://issues.apache.org/jira/browse/IGNITE-21165
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
> Attachments:
> Ignite_Tests_2.x_JDK_8_11_Platform_.NET_Core_Linux_39429.log.zip
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There are many timeouted test runs in the .NET suite. Example:
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
> {code:java}
> The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
> {buildId=7678070} has been running for more than 40 minutes. Terminating...
> {code}
> Looks like only port 47500 is requested while server node started on another.
> Probably a previous test didn't release the port yet.
> {code:java}
> Successfully bound communication NIO server to TCP port [port=47101,
> locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
> {code}
> {code:java}
> Failed to connect to any address from IP finder (make sure IP finder
> addresses are correct and firewalls are disabled on all host machines):
> [/127.0.0.1:47500]
> {code}
> It looks like this issue happens on JDK8 only. And only on Linux.
> _ClientServerCompatibilityTest_ starts a server node with _Runner.java_,
> _PlatformProcessUtils#startProcess()_ and stops with
> _PlatformProcessUtils#stopProcess()_. On Windows, additional
> {code:java}
> serverProc.KillProcessTree();
> {code}
> is applied.
> We should wait until _java.lang.Process_ completely stops.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21165) .NET platform test timeouts after ClientServerCompatibilityTest
[
https://issues.apache.org/jira/browse/IGNITE-21165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21165:
--
Description:
There are many timeouted test runs in the .NET suite. Example:
https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
{code:java}
The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
{buildId=7678070} has been running for more than 40 minutes. Terminating...
{code}
Looks like only port 47500 is requested while server node started on another.
Probably a previous test didn't release the port yet.
{code:java}
Successfully bound communication NIO server to TCP port [port=47101,
locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
{code}
{code:java}
Failed to connect to any address from IP finder (make sure IP finder addresses
are correct and firewalls are disabled on all host machines): [/127.0.0.1:47500]
{code}
It looks like this issue happens on JDK8 only. And only on Linux.
_ClientServerCompatibilityTest_ starts a server node with _Runner.java_,
_PlatformProcessUtils#startProcess()_ and stops with
_PlatformProcessUtils#stopProcess()_. On Windows, additional
{code:java}
serverProc.KillProcessTree();
{code}
is applied.
We shoul wait until _java.lang.Process_ completely stops.
was:
There are many timeouted test runs in the .NET suite. Example:
https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
{code:java}
The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
{buildId=7678070} has been running for more than 40 minutes. Terminating...
{code}
Looks like only port 47500 is requested while server node started on another.
Probably a previous test didn't release the port yet.
{code:java}
Successfully bound communication NIO server to TCP port [port=47101,
locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
{code}
{code:java}
Failed to connect to any address from IP finder (make sure IP finder addresses
are correct and firewalls are disabled on all host machines): [/127.0.0.1:47500]
{code}
It looks like this issue happens on JDK8 only. And only on Linux.
_ClientServerCompatibilityTest_ starts a server node with _Runner.java_,
_PlatformProcessUtils#startProcess()_ and stops with
_PlatformProcessUtils#stopProcess()_. On Windows, additional
{code:java}
serverProc.KillProcessTree();
{code}
is applied.
> .NET platform test timeouts after ClientServerCompatibilityTest
> ---
>
> Key: IGNITE-21165
> URL: https://issues.apache.org/jira/browse/IGNITE-21165
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
> Attachments:
> Ignite_Tests_2.x_JDK_8_11_Platform_.NET_Core_Linux_39429.log.zip
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There are many timeouted test runs in the .NET suite. Example:
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
> {code:java}
> The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
> {buildId=7678070} has been running for more than 40 minutes. Terminating...
> {code}
> Looks like only port 47500 is requested while server node started on another.
> Probably a previous test didn't release the port yet.
> {code:java}
> Successfully bound communication NIO server to TCP port [port=47101,
> locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
> {code}
> {code:java}
> Failed to connect to any address from IP finder (make sure IP finder
> addresses are correct and firewalls are disabled on all host machines):
> [/127.0.0.1:47500]
> {code}
> It looks like this issue happens on JDK8 only. And only on Linux.
> _ClientServerCompatibilityTest_ starts a server node with _Runner.java_,
> _PlatformProcessUtils#startProcess()_ and stops with
> _PlatformProcessUtils#stopProcess()_. On Windows, additional
> {code:java}
> serverProc.KillProcessTree();
> {code}
> is applied.
> We shoul wait until _java.lang.Process_ completely stops.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21165) .NET platform test timeouts after ClientServerCompatibilityTest
[
https://issues.apache.org/jira/browse/IGNITE-21165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21165:
--
Description:
There are many timeouted test runs in the .NET suite. Example:
https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
{code:java}
The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
{buildId=7678070} has been running for more than 40 minutes. Terminating...
{code}
Looks like only port 47500 is requested while server node started on another.
Probably a previous test didn't release the port yet.
{code:java}
Successfully bound communication NIO server to TCP port [port=47101,
locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
{code}
{code:java}
Failed to connect to any address from IP finder (make sure IP finder addresses
are correct and firewalls are disabled on all host machines): [/127.0.0.1:47500]
{code}
It looks like happens on JDK8 only. And only on Linux.
was:
There are many timeouted test runs in the .NET suite. Example:
https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
{code:java}
The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
{buildId=7678070} has been running for more than 40 minutes. Terminating...
{code}
Looks like only port 47500 is requested while server node started on another.
Probably a previous test didn't release the port yet.
{code:java}
Successfully bound communication NIO server to TCP port [port=47101,
locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
{code}
{code:java}
Failed to connect to any address from IP finder (make sure IP finder addresses
are correct and firewalls are disabled on all host machines): [/127.0.0.1:47500]
{code}
> .NET platform test timeouts after ClientServerCompatibilityTest
> ---
>
> Key: IGNITE-21165
> URL: https://issues.apache.org/jira/browse/IGNITE-21165
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
> Attachments:
> Ignite_Tests_2.x_JDK_8_11_Platform_.NET_Core_Linux_39429.log.zip
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There are many timeouted test runs in the .NET suite. Example:
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
> {code:java}
> The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
> {buildId=7678070} has been running for more than 40 minutes. Terminating...
> {code}
> Looks like only port 47500 is requested while server node started on another.
> Probably a previous test didn't release the port yet.
> {code:java}
> Successfully bound communication NIO server to TCP port [port=47101,
> locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
> {code}
> {code:java}
> Failed to connect to any address from IP finder (make sure IP finder
> addresses are correct and firewalls are disabled on all host machines):
> [/127.0.0.1:47500]
> {code}
> It looks like happens on JDK8 only. And only on Linux.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21165) .NET platform test timeouts after ClientServerCompatibilityTest
[
https://issues.apache.org/jira/browse/IGNITE-21165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21165:
--
Description:
There are many timeouted test runs in the .NET suite. Example:
https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
{code:java}
The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
{buildId=7678070} has been running for more than 40 minutes. Terminating...
{code}
Looks like only port 47500 is requested while server node started on another.
Probably a previous test didn't release the port yet.
{code:java}
Successfully bound communication NIO server to TCP port [port=47101,
locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
{code}
{code:java}
Failed to connect to any address from IP finder (make sure IP finder addresses
are correct and firewalls are disabled on all host machines): [/127.0.0.1:47500]
{code}
was:
There are many timeouted test runs in the .NET suite. Example:
https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
{code:java}
The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
{buildId=7678070} has been running for more than 40 minutes. Terminating...
{code}
Looks like only port 47500 is requested while server node started on another.
Probably a previous test didn't release the port yet.
{code:java}
Successfully bound communication NIO server to TCP port [port=47101,
locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
{code}
{code:java}
Failed to connect to any address from IP finder (make sure IP finder addresses
are correct and firewalls are disabled on all host machines): [/127.0.0.1:47500]
{code}
If I'm correct, this happens after
{code:java}
Apache.Ignite.Core.Tests.Client.Compatibility.ClientServerCompatibilityTest("org.apache.ignite","2.8.0",6).TestPartitionAwarenessDisablesAutomaticallyOnVersionsOlderThan140
{code}
of after
{code:java}
Apache.Ignite.Core.Tests.Client.Compatibility.ClientServerCompatibilityTest("org.apache.ignite","2.8.0",6).TestWithExpiryPolicyThrowCorrectExceptionOnVersionsOlderThan150
{code}
The issue might be related to:
{code:java}
JAVA_HOME: /opt/java/jdk-ora-8
{code}
{code:java}
if (TestUtilsJni.GetJavaMajorVersion() <= 11)
{
// Old Ignite versions can't start on new JDKs (support was
not yet added).
yield return new object[] { JavaServer.GroupIdIgnite,
"2.4.0", 0 };
yield return new object[] { JavaServer.GroupIdIgnite,
"2.6.0", 1 };
}
{code}
{code:java}
Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/ignite/ignite-core/2.4.0/ignite-core-2.4.0.jar
{code}
{code:java}
PlatformProcessUtils >> [INFO] Compiling 1 source file to
/data/tcAgent/work/7bc1c54bc719b67c/modules/platforms/dotnet/Apache.Ignite.Core.Tests/JavaServer/target/classes
PlatformProcessUtils >> [WARNING]
/data/tcAgent/work/7bc1c54bc719b67c/modules/platforms/dotnet/Apache.Ignite.Core.Tests/JavaServer/src/main/java/Runner.java:
/data/tcAgent/work/7bc1c54bc719b67c/modules/platforms/dotnet/Apache.Ignite.Core.Tests/JavaServer/src/main/java/Runner.java
uses unchecked or unsafe operations.
PlatformProcessUtils >> [WARNING]
/data/tcAgent/work/7bc1c54bc719b67c/modules/platforms/dotnet/Apache.Ignite.Core.Tests/JavaServer/src/main/java/Runner.java:
Recompile with -Xlint:unchecked for details.
PlatformProcessUtils >> [INFO]
PlatformProcessUtils >> [INFO] --- exec-maven-plugin:3.0.0:java (default-cli) @
ignite-maven-server ---
PlatformProcessUtils >> Can't load log handler
"org.apache.ignite.logger.java.JavaLoggerFileHandler"
PlatformProcessUtils >> java.lang.ClassNotFoundException:
org.apache.ignite.logger.java.JavaLoggerFileHandler
PlatformProcessUtils >> java.lang.ClassNotFoundException:
org.apache.ignite.logger.java.JavaLoggerFileHandler
PlatformProcessUtils >> at
java.net.URLClassLoader.findClass(URLClassLoader.java:382)
PlatformProcessUtils >> at
java.lang.ClassLoader.loadClass(ClassLoader.java:418)
PlatformProcessUtils >> at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:355)
PlatformProcessUtils >> at
java.lang.ClassLoader.loadClass(ClassLoader.java:351)
PlatformProcessUtils >> at
java.util.logging.LogManager$5.run(LogManager.java:965)
PlatformProcessUtils >> at
java.security.AccessController.doPrivileged(Native Method)
PlatformProcessUtils >> at
java.util.logging.LogManager.loadLoggerHandlers(LogManager.java:958)
PlatformProcessUtils >> at
java.util.logging.LogManager.initializeGlobalHandlers(LogManager.java:1578)
PlatformProcessUtils >> at
java.util.logging.LogManager.access$1500(LogManager.java:145)
PlatformProcessUtils >> at
[jira] [Updated] (IGNITE-21186) Fix abbrevation build failure
[ https://issues.apache.org/jira/browse/IGNITE-21186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21186: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Fix abbrevation build failure > - > > Key: IGNITE-21186 > URL: https://issues.apache.org/jira/browse/IGNITE-21186 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > [ERROR] > /modules/calcite/src/main/java/org/apache/ignite/internal/processors/query/calcite/rule/AbstractIgniteJoinConverterRule.java:107: > Abbrevation should be used for unableToProcess! Please, use proc, instead of > Process [IgniteAbbrevationsRule] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21186) Fix abbrevation build failure
[ https://issues.apache.org/jira/browse/IGNITE-21186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21186: -- Fix Version/s: 2.17 > Fix abbrevation build failure > - > > Key: IGNITE-21186 > URL: https://issues.apache.org/jira/browse/IGNITE-21186 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.17 >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Fix For: 2.17 > > Time Spent: 10m > Remaining Estimate: 0h > > [ERROR] > /modules/calcite/src/main/java/org/apache/ignite/internal/processors/query/calcite/rule/AbstractIgniteJoinConverterRule.java:107: > Abbrevation should be used for unableToProcess! Please, use proc, instead of > Process [IgniteAbbrevationsRule] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21186) Fix abbrevation build failure
[ https://issues.apache.org/jira/browse/IGNITE-21186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21186: -- Affects Version/s: 2.17 > Fix abbrevation build failure > - > > Key: IGNITE-21186 > URL: https://issues.apache.org/jira/browse/IGNITE-21186 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.17 >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > [ERROR] > /modules/calcite/src/main/java/org/apache/ignite/internal/processors/query/calcite/rule/AbstractIgniteJoinConverterRule.java:107: > Abbrevation should be used for unableToProcess! Please, use proc, instead of > Process [IgniteAbbrevationsRule] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21186) Fix abbrevation build failure
[ https://issues.apache.org/jira/browse/IGNITE-21186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21186: -- Priority: Major (was: Blocker) > Fix abbrevation build failure > - > > Key: IGNITE-21186 > URL: https://issues.apache.org/jira/browse/IGNITE-21186 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > [ERROR] > /modules/calcite/src/main/java/org/apache/ignite/internal/processors/query/calcite/rule/AbstractIgniteJoinConverterRule.java:107: > Abbrevation should be used for unableToProcess! Please, use proc, instead of > Process [IgniteAbbrevationsRule] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21156) [IEP-114] Custom metrics introduction
[ https://issues.apache.org/jira/browse/IGNITE-21156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-21156: - Assignee: Vladimir Steshin > [IEP-114] Custom metrics introduction > - > > Key: IGNITE-21156 > URL: https://issues.apache.org/jira/browse/IGNITE-21156 > Project: Ignite > Issue Type: Task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: iep-114, ise > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21186) Fix abbrevation build failure
[ https://issues.apache.org/jira/browse/IGNITE-21186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21186: -- Priority: Blocker (was: Major) > Fix abbrevation build failure > - > > Key: IGNITE-21186 > URL: https://issues.apache.org/jira/browse/IGNITE-21186 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Blocker > Time Spent: 10m > Remaining Estimate: 0h > > [ERROR] > /modules/calcite/src/main/java/org/apache/ignite/internal/processors/query/calcite/rule/AbstractIgniteJoinConverterRule.java:107: > Abbrevation should be used for unableToProcess! Please, use proc, instead of > Process [IgniteAbbrevationsRule] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21186) Fix abbrevation build failure
[ https://issues.apache.org/jira/browse/IGNITE-21186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-21186: - Assignee: Vladimir Steshin > Fix abbrevation build failure > - > > Key: IGNITE-21186 > URL: https://issues.apache.org/jira/browse/IGNITE-21186 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > [ERROR] > /modules/calcite/src/main/java/org/apache/ignite/internal/processors/query/calcite/rule/AbstractIgniteJoinConverterRule.java:107: > Abbrevation should be used for unableToProcess! Please, use proc, instead of > Process [IgniteAbbrevationsRule] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21156) [IEP-114] Custom metrics introduction
[ https://issues.apache.org/jira/browse/IGNITE-21156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21156: -- Labels: eip-144 ise (was: eip-144) > [IEP-114] Custom metrics introduction > - > > Key: IGNITE-21156 > URL: https://issues.apache.org/jira/browse/IGNITE-21156 > Project: Ignite > Issue Type: Task >Reporter: Vladimir Steshin >Priority: Major > Labels: eip-144, ise > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21156) [IEP-114] Custom metrics introduction
[ https://issues.apache.org/jira/browse/IGNITE-21156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21156: -- Labels: iep-114 ise (was: eip-144 ise) > [IEP-114] Custom metrics introduction > - > > Key: IGNITE-21156 > URL: https://issues.apache.org/jira/browse/IGNITE-21156 > Project: Ignite > Issue Type: Task >Reporter: Vladimir Steshin >Priority: Major > Labels: iep-114, ise > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21165) .NET platform test timeouts after
[
https://issues.apache.org/jira/browse/IGNITE-21165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21165:
--
Summary: .NET platform test timeouts after (was: .NET platform test
timeouts)
> .NET platform test timeouts after
> --
>
> Key: IGNITE-21165
> URL: https://issues.apache.org/jira/browse/IGNITE-21165
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
> Attachments:
> Ignite_Tests_2.x_JDK_8_11_Platform_.NET_Core_Linux_39429.log.zip
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There are many timeouted test runs in the .NET suite. Example:
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
> {code:java}
> The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
> {buildId=7678070} has been running for more than 40 minutes. Terminating...
> {code}
> Looks like only port 47500 is requested while server node started on another.
> Probably a previous test didn't release the port yet.
> {code:java}
> Successfully bound communication NIO server to TCP port [port=47101,
> locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
> {code}
> {code:java}
> Failed to connect to any address from IP finder (make sure IP finder
> addresses are correct and firewalls are disabled on all host machines):
> [/127.0.0.1:47500]
> {code}
> If I'm correct, this happens after
> {code:java}
> Apache.Ignite.Core.Tests.Client.Compatibility.ClientServerCompatibilityTest("org.apache.ignite","2.8.0",6).TestPartitionAwarenessDisablesAutomaticallyOnVersionsOlderThan140
> {code}
> of after
> {code:java}
> Apache.Ignite.Core.Tests.Client.Compatibility.ClientServerCompatibilityTest("org.apache.ignite","2.8.0",6).TestWithExpiryPolicyThrowCorrectExceptionOnVersionsOlderThan150
> {code}
> The issue might be related to:
> {code:java}
> JAVA_HOME: /opt/java/jdk-ora-8
> {code}
> {code:java}
> if (TestUtilsJni.GetJavaMajorVersion() <= 11)
> {
> // Old Ignite versions can't start on new JDKs (support
> was not yet added).
> yield return new object[] { JavaServer.GroupIdIgnite,
> "2.4.0", 0 };
> yield return new object[] { JavaServer.GroupIdIgnite,
> "2.6.0", 1 };
> }
> {code}
> {code:java}
> Downloading from central:
> https://repo.maven.apache.org/maven2/org/apache/ignite/ignite-core/2.4.0/ignite-core-2.4.0.jar
> {code}
> {code:java}
> PlatformProcessUtils >> [INFO] Compiling 1 source file to
> /data/tcAgent/work/7bc1c54bc719b67c/modules/platforms/dotnet/Apache.Ignite.Core.Tests/JavaServer/target/classes
> PlatformProcessUtils >> [WARNING]
> /data/tcAgent/work/7bc1c54bc719b67c/modules/platforms/dotnet/Apache.Ignite.Core.Tests/JavaServer/src/main/java/Runner.java:
>
> /data/tcAgent/work/7bc1c54bc719b67c/modules/platforms/dotnet/Apache.Ignite.Core.Tests/JavaServer/src/main/java/Runner.java
> uses unchecked or unsafe operations.
> PlatformProcessUtils >> [WARNING]
> /data/tcAgent/work/7bc1c54bc719b67c/modules/platforms/dotnet/Apache.Ignite.Core.Tests/JavaServer/src/main/java/Runner.java:
> Recompile with -Xlint:unchecked for details.
> PlatformProcessUtils >> [INFO]
> PlatformProcessUtils >> [INFO] --- exec-maven-plugin:3.0.0:java (default-cli)
> @ ignite-maven-server ---
> PlatformProcessUtils >> Can't load log handler
> "org.apache.ignite.logger.java.JavaLoggerFileHandler"
> PlatformProcessUtils >> java.lang.ClassNotFoundException:
> org.apache.ignite.logger.java.JavaLoggerFileHandler
> PlatformProcessUtils >> java.lang.ClassNotFoundException:
> org.apache.ignite.logger.java.JavaLoggerFileHandler
> PlatformProcessUtils >> at
> java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> PlatformProcessUtils >> at
> java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> PlatformProcessUtils >> at
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:355)
> PlatformProcessUtils >> at
> java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> PlatformProcessUtils >> at
> java.util.logging.LogManager$5.run(LogManager.java:965)
> PlatformProcessUtils >> at
> java.security.AccessController.doPrivileged(Native Method)
> PlatformProcessUtils >> at
> java.util.logging.LogManager.loadLoggerHandlers(LogManager.java:958)
> PlatformProcessUtils >> at
> java.util.logging.LogManager.initializeGlobalHandlers(LogManager.java:1578)
> PlatformProcessUtils >> at
> java.util.logging.LogManager.access$1500(LogManager.java:145)
> PlatformProcessUtils >> at
> java.util.logging.LogManager$RootLogger.accessCheckedHandlers(LogManager.java:1667)
> PlatformProcessUtils >> at
>
[jira] [Updated] (IGNITE-21165) .NET platform test timeouts after ClientServerCompatibilityTest
[
https://issues.apache.org/jira/browse/IGNITE-21165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21165:
--
Summary: .NET platform test timeouts after ClientServerCompatibilityTest
(was: .NET platform test timeouts after )
> .NET platform test timeouts after ClientServerCompatibilityTest
> ---
>
> Key: IGNITE-21165
> URL: https://issues.apache.org/jira/browse/IGNITE-21165
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
> Attachments:
> Ignite_Tests_2.x_JDK_8_11_Platform_.NET_Core_Linux_39429.log.zip
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There are many timeouted test runs in the .NET suite. Example:
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
> {code:java}
> The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
> {buildId=7678070} has been running for more than 40 minutes. Terminating...
> {code}
> Looks like only port 47500 is requested while server node started on another.
> Probably a previous test didn't release the port yet.
> {code:java}
> Successfully bound communication NIO server to TCP port [port=47101,
> locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
> {code}
> {code:java}
> Failed to connect to any address from IP finder (make sure IP finder
> addresses are correct and firewalls are disabled on all host machines):
> [/127.0.0.1:47500]
> {code}
> If I'm correct, this happens after
> {code:java}
> Apache.Ignite.Core.Tests.Client.Compatibility.ClientServerCompatibilityTest("org.apache.ignite","2.8.0",6).TestPartitionAwarenessDisablesAutomaticallyOnVersionsOlderThan140
> {code}
> of after
> {code:java}
> Apache.Ignite.Core.Tests.Client.Compatibility.ClientServerCompatibilityTest("org.apache.ignite","2.8.0",6).TestWithExpiryPolicyThrowCorrectExceptionOnVersionsOlderThan150
> {code}
> The issue might be related to:
> {code:java}
> JAVA_HOME: /opt/java/jdk-ora-8
> {code}
> {code:java}
> if (TestUtilsJni.GetJavaMajorVersion() <= 11)
> {
> // Old Ignite versions can't start on new JDKs (support
> was not yet added).
> yield return new object[] { JavaServer.GroupIdIgnite,
> "2.4.0", 0 };
> yield return new object[] { JavaServer.GroupIdIgnite,
> "2.6.0", 1 };
> }
> {code}
> {code:java}
> Downloading from central:
> https://repo.maven.apache.org/maven2/org/apache/ignite/ignite-core/2.4.0/ignite-core-2.4.0.jar
> {code}
> {code:java}
> PlatformProcessUtils >> [INFO] Compiling 1 source file to
> /data/tcAgent/work/7bc1c54bc719b67c/modules/platforms/dotnet/Apache.Ignite.Core.Tests/JavaServer/target/classes
> PlatformProcessUtils >> [WARNING]
> /data/tcAgent/work/7bc1c54bc719b67c/modules/platforms/dotnet/Apache.Ignite.Core.Tests/JavaServer/src/main/java/Runner.java:
>
> /data/tcAgent/work/7bc1c54bc719b67c/modules/platforms/dotnet/Apache.Ignite.Core.Tests/JavaServer/src/main/java/Runner.java
> uses unchecked or unsafe operations.
> PlatformProcessUtils >> [WARNING]
> /data/tcAgent/work/7bc1c54bc719b67c/modules/platforms/dotnet/Apache.Ignite.Core.Tests/JavaServer/src/main/java/Runner.java:
> Recompile with -Xlint:unchecked for details.
> PlatformProcessUtils >> [INFO]
> PlatformProcessUtils >> [INFO] --- exec-maven-plugin:3.0.0:java (default-cli)
> @ ignite-maven-server ---
> PlatformProcessUtils >> Can't load log handler
> "org.apache.ignite.logger.java.JavaLoggerFileHandler"
> PlatformProcessUtils >> java.lang.ClassNotFoundException:
> org.apache.ignite.logger.java.JavaLoggerFileHandler
> PlatformProcessUtils >> java.lang.ClassNotFoundException:
> org.apache.ignite.logger.java.JavaLoggerFileHandler
> PlatformProcessUtils >> at
> java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> PlatformProcessUtils >> at
> java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> PlatformProcessUtils >> at
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:355)
> PlatformProcessUtils >> at
> java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> PlatformProcessUtils >> at
> java.util.logging.LogManager$5.run(LogManager.java:965)
> PlatformProcessUtils >> at
> java.security.AccessController.doPrivileged(Native Method)
> PlatformProcessUtils >> at
> java.util.logging.LogManager.loadLoggerHandlers(LogManager.java:958)
> PlatformProcessUtils >> at
> java.util.logging.LogManager.initializeGlobalHandlers(LogManager.java:1578)
> PlatformProcessUtils >> at
> java.util.logging.LogManager.access$1500(LogManager.java:145)
> PlatformProcessUtils >> at
>
