[jira] [Assigned] (IGNITE-20813) Sql. Introduce InternalSqlRow as resulting row of QueryProcessor
[
https://issues.apache.org/jira/browse/IGNITE-20813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich reassigned IGNITE-20813:
--
Assignee: Yury Gerzhedovich
> Sql. Introduce InternalSqlRow as resulting row of QueryProcessor
>
>
> Key: IGNITE-20813
> URL: https://issues.apache.org/jira/browse/IGNITE-20813
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> As for now, the method signature of
> {{QueryProcessor#querySingleAsync}} looks like this:
> {code:java}
> CompletableFuture>> querySingleAsync(
> SqlProperties properties,
> IgniteTransactions transactions,
> @Nullable InternalTransaction transaction,
> String qry,
> Object... params
> );
> {code}
>
> The problem is that client code may not need de-serialised row right here
> right now (for instance, thin client handler will send those rows down the
> channel anyway), yet current signature force us to do deserialisation from a
> storage format.
> Let's change the signature to return something that extends InternalTuple,
> but also provides a way to get column value by having only index of column of
> interest (e.g. {{@Nullable Object get(int idx)}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20854) Configure idleSafeTimePropagationPeriod with a distributed property
[ https://issues.apache.org/jira/browse/IGNITE-20854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786643#comment-17786643 ] Roman Puchkovskiy commented on IGNITE-20854: Thanks! > Configure idleSafeTimePropagationPeriod with a distributed property > --- > > Key: IGNITE-20854 > URL: https://issues.apache.org/jira/browse/IGNITE-20854 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Gagarkin >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3, tech-debt > Fix For: 3.0.0-beta2 > > Time Spent: 50m > Remaining Estimate: 0h > > Currently, the setting is obtained using system properties. We should make it > a distributed configuration property. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20759) Tcp handshake in communication spi hangs on JDK 12 and later
[
https://issues.apache.org/jira/browse/IGNITE-20759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-20759:
-
Fix Version/s: 2.16
> Tcp handshake in communication spi hangs on JDK 12 and later
>
>
> Key: IGNITE-20759
> URL: https://issues.apache.org/jira/browse/IGNITE-20759
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.15
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Labels: ise
> Fix For: 2.16
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> This issue is reproduced in {{GridTcpCommunicationSpiSslSelfTest}}. All tests
> hangs during tcp handshake process in infinite loop in
> {{org.apache.ignite.spi.communication.tcp.internal.TcpHandshakeExecutor#tcpHandshake}}.
> Seems that fixes in IGNITE-16622 are not enough
> The main reason of this behaviour --
> https://bugs.openjdk.org/browse/JDK-8277307. Post handshake message seems to
> be too large for being written in one step, but we don't try to resend the
> rest in
> {{org.apache.ignite.internal.util.nio.GridNioServer.DirectNioClientWorker#processWriteSsl}}
> since the ssl handshake is considered to be finished.
> WA -- set {{-Djdk.tls.server.enableSessionTicketExtension=false}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20854) Configure idleSafeTimePropagationPeriod with a distributed property
[ https://issues.apache.org/jira/browse/IGNITE-20854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-20854: - Fix Version/s: 3.0.0-beta2 > Configure idleSafeTimePropagationPeriod with a distributed property > --- > > Key: IGNITE-20854 > URL: https://issues.apache.org/jira/browse/IGNITE-20854 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Gagarkin >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3, tech-debt > Fix For: 3.0.0-beta2 > > Time Spent: 40m > Remaining Estimate: 0h > > Currently, the setting is obtained using system properties. We should make it > a distributed configuration property. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20854) Configure idleSafeTimePropagationPeriod with a distributed property
[ https://issues.apache.org/jira/browse/IGNITE-20854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786639#comment-17786639 ] Aleksandr Polovtcev commented on IGNITE-20854: -- Looking good, merged. > Configure idleSafeTimePropagationPeriod with a distributed property > --- > > Key: IGNITE-20854 > URL: https://issues.apache.org/jira/browse/IGNITE-20854 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Gagarkin >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3, tech-debt > Time Spent: 40m > Remaining Estimate: 0h > > Currently, the setting is obtained using system properties. We should make it > a distributed configuration property. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20865) Ignite 3.0: Criteria API queries
[ https://issues.apache.org/jira/browse/IGNITE-20865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov updated IGNITE-20865: Labels: ignite-3 (was: ) > Ignite 3.0: Criteria API queries > > > Key: IGNITE-20865 > URL: https://issues.apache.org/jira/browse/IGNITE-20865 > Project: Ignite > Issue Type: Epic > Components: sql >Reporter: Andrey Novikov >Priority: Major > Labels: ignite-3 > > Criteria Query is logically just a facade for SQL – same way as Criteria API > is a facade for SQL in JPA. The easiest way to implement this feature then is > to just generate SQL queries. > There are different gateways to a table called Table Views. Currently we have > RecordView and KeyValueView. *Each view* should have the Criteria Query API. > The only difference is the type of objects the query result maps to. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20866) Race condition in configuration initialization using meta storage revision
[
https://issues.apache.org/jira/browse/IGNITE-20866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786380#comment-17786380
]
Kirill Tkalenko commented on IGNITE-20866:
--
Looks good.
> Race condition in configuration initialization using meta storage revision
> --
>
> Key: IGNITE-20866
> URL: https://issues.apache.org/jira/browse/IGNITE-20866
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Gagarkin
>Assignee: Ivan Gagarkin
>Priority: Critical
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {*}Summary{*}{_}:{_} Initialization of the cluster configuration using meta
> storage revision 0 leads to race conditions, resulting in potential
> misconfiguration.
> {*}Analysis{*}: Currently, the system applies the initial cluster
> configuration locally when the meta-storage revision is at 0. This approach
> can lead to race conditions where the initial configuration might be
> overlooked if the revision number changes during the initialization process.
> _Suggested Fix:_ We should modify the initialization logic to:
> # Use the local revision of the configuration key.
> # If the local revision is absent, only then fall back to the initial
> configuration.
> This approach would prevent the configuration from being ignored due to
> changes in the meta-store revision.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20866) Race condition in configuration initialization using meta storage revision
[
https://issues.apache.org/jira/browse/IGNITE-20866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-20866:
-
Ignite Flags: (was: Release Notes Required)
> Race condition in configuration initialization using meta storage revision
> --
>
> Key: IGNITE-20866
> URL: https://issues.apache.org/jira/browse/IGNITE-20866
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Gagarkin
>Assignee: Ivan Gagarkin
>Priority: Critical
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {*}Summary{*}{_}:{_} Initialization of the cluster configuration using meta
> storage revision 0 leads to race conditions, resulting in potential
> misconfiguration.
> {*}Analysis{*}: Currently, the system applies the initial cluster
> configuration locally when the meta-storage revision is at 0. This approach
> can lead to race conditions where the initial configuration might be
> overlooked if the revision number changes during the initialization process.
> _Suggested Fix:_ We should modify the initialization logic to:
> # Use the local revision of the configuration key.
> # If the local revision is absent, only then fall back to the initial
> configuration.
> This approach would prevent the configuration from being ignored due to
> changes in the meta-store revision.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20866) Race condition in configuration initialization using meta storage revision
[
https://issues.apache.org/jira/browse/IGNITE-20866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-20866:
-
Fix Version/s: 3.0.0-beta2
> Race condition in configuration initialization using meta storage revision
> --
>
> Key: IGNITE-20866
> URL: https://issues.apache.org/jira/browse/IGNITE-20866
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Gagarkin
>Assignee: Ivan Gagarkin
>Priority: Critical
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {*}Summary{*}{_}:{_} Initialization of the cluster configuration using meta
> storage revision 0 leads to race conditions, resulting in potential
> misconfiguration.
> {*}Analysis{*}: Currently, the system applies the initial cluster
> configuration locally when the meta-storage revision is at 0. This approach
> can lead to race conditions where the initial configuration might be
> overlooked if the revision number changes during the initialization process.
> _Suggested Fix:_ We should modify the initialization logic to:
> # Use the local revision of the configuration key.
> # If the local revision is absent, only then fall back to the initial
> configuration.
> This approach would prevent the configuration from being ignored due to
> changes in the meta-store revision.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20866) Race condition in configuration initialization using meta storage revision
[
https://issues.apache.org/jira/browse/IGNITE-20866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-20866:
-
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Race condition in configuration initialization using meta storage revision
> --
>
> Key: IGNITE-20866
> URL: https://issues.apache.org/jira/browse/IGNITE-20866
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Gagarkin
>Assignee: Ivan Gagarkin
>Priority: Critical
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {*}Summary{*}{_}:{_} Initialization of the cluster configuration using meta
> storage revision 0 leads to race conditions, resulting in potential
> misconfiguration.
> {*}Analysis{*}: Currently, the system applies the initial cluster
> configuration locally when the meta-storage revision is at 0. This approach
> can lead to race conditions where the initial configuration might be
> overlooked if the revision number changes during the initialization process.
> _Suggested Fix:_ We should modify the initialization logic to:
> # Use the local revision of the configuration key.
> # If the local revision is absent, only then fall back to the initial
> configuration.
> This approach would prevent the configuration from being ignored due to
> changes in the meta-store revision.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20869) CompletableFuture with orTimeout has noticeable performance impact
[ https://issues.apache.org/jira/browse/IGNITE-20869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-20869: Description: [This |https://github.com/apache/ignite-3/blob/82c74598b5006ea3e4e86da744a68022dd799c89/modules/network/src/main/java/org/apache/ignite/network/DefaultMessagingService.java#L254-L255]line of code cost us near the 3us from the 26us of the whole query (~10%). The reason is the orTimeout(...) call. The simple switch to simple new CompletableFuture() give us 10% boost from 26us/s to 23us/s in the 1-node fsync=false run of SelectBenchmark.kvGet. was: [This |https://github.com/apache/ignite-3/blob/82c74598b5006ea3e4e86da744a68022dd799c89/modules/network/src/main/java/org/apache/ignite/network/DefaultMessagingService.java#L254-L255]line of code cost us near the 3us from the 26us of the whole query (~10%). The reason is the orTimeout(...) call. > CompletableFuture with orTimeout has noticeable performance impact > -- > > Key: IGNITE-20869 > URL: https://issues.apache.org/jira/browse/IGNITE-20869 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Priority: Major > > [This > |https://github.com/apache/ignite-3/blob/82c74598b5006ea3e4e86da744a68022dd799c89/modules/network/src/main/java/org/apache/ignite/network/DefaultMessagingService.java#L254-L255]line > of code cost us near the 3us from the 26us of the whole query (~10%). The > reason is the orTimeout(...) call. > The simple switch to simple new CompletableFuture() give us 10% boost from > 26us/s to 23us/s in the 1-node fsync=false run of SelectBenchmark.kvGet. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20869) CompletableFuture with orTimeout has noticeable performance impact
Kirill Gusakov created IGNITE-20869: --- Summary: CompletableFuture with orTimeout has noticeable performance impact Key: IGNITE-20869 URL: https://issues.apache.org/jira/browse/IGNITE-20869 Project: Ignite Issue Type: Improvement Reporter: Kirill Gusakov [This |https://github.com/apache/ignite-3/blob/82c74598b5006ea3e4e86da744a68022dd799c89/modules/network/src/main/java/org/apache/ignite/network/DefaultMessagingService.java#L254-L255]line of code cost us near the 3us from the 26us of the whole query (~10%). The reason is the orTimeout(...) call. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20867) Server nodes crash after create persistent cache with /" name
[
https://issues.apache.org/jira/browse/IGNITE-20867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Amelchev updated IGNITE-20867:
-
Summary: Server nodes crash after create persistent cache with /" name
(was: [Thin client] Server nodes crash after create persistent cache with /"
name )
> Server nodes crash after create persistent cache with /" name
> --
>
> Key: IGNITE-20867
> URL: https://issues.apache.org/jira/browse/IGNITE-20867
> Project: Ignite
> Issue Type: Bug
>Reporter: Anastasia Iakimova
>Assignee: Anastasia Iakimova
>Priority: Major
> Labels: ise
> Time Spent: 20m
> Remaining Estimate: 0h
>
> ignite.log:
> {code:java}
> 2023-11-14 18:12:34.985 [INFO
> ][exchange-worker-#75][org.apache.ignite.internal.exchange.time] Started
> exchange init [topVer=AffinityTopologyVersion [topVer=4, minorTopVer=32],
> crd=false, evt=DISCOVERY_CUSTOM_EVT, evtNode=d91c8f37
> -dc4f-435e-97dc-8ec02b953b6a, customEvt=DynamicCacheChangeBatch
> [id=3a05698cb81-782afb33-985f-4efc-a47f-2c178ae29301, reqs=ArrayList
> [DynamicCacheChangeRequest [cacheName=/", hasCfg=true,
> nodeId=d91c8f37-dc4f-435e-97dc-8ec02b953b6
> a, clientStartOnly=false, stop=false, destroy=false,
> disabledAfterStart=false]], exchangeActions=ExchangeActions
> [startCaches=[/"], stopCaches=null, startGrps=[/"], stopGrps=[],
> resetParts=null, finalizePartitionCounters=false, stateChangeRequest=null],
> startCaches=false], allowMerge=false, exchangeFreeSwitch=false]
> 2023-11-14 18:12:34.989 [ERROR][exchange-worker-#75][] Critical system error
> detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.IgniteCheckedException: Failed to initialize cache working directory
> (failed to create, make sure the work folder has correct permissions):
> /u01/ift/storage/server/data/ise_ift_ignite05/cache-/"]]
> org.apache.ignite.IgniteCheckedException: Failed to initialize cache working
> directory (failed to create, make sure the work folder has correct
> permissions): /u01/ift/storage/server/data/ise_ift_ignite05/cache-/"
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.checkAndInitCacheWorkDir(FilePageStoreManager.java:796)
> ~[ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.CachesRegistry.persistCacheConfigurations(CachesRegistry.java:275)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.CachesRegistry.registerAllCachesAndGroups(CachesRegistry.java:262)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.CachesRegistry.update(CachesRegistry.java:200)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:877)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:1462)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:980)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3338)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:3172)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: java.nio.file.NoSuchFileException:
> /u01/ift/storage/server/data/ise_ift_ignite05/cache-/"
> at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) ~[?:?]
> at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) ~[?:?]
> at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) ~[?:?]
> at
>
[jira] [Created] (IGNITE-20868) ReplicaService whenCompleteAsync waste significant amount of time
Kirill Gusakov created IGNITE-20868:
---
Summary: ReplicaService whenCompleteAsync waste significant amount
of time
Key: IGNITE-20868
URL: https://issues.apache.org/jira/browse/IGNITE-20868
Project: Ignite
Issue Type: Improvement
Reporter: Kirill Gusakov
During the YCSB 1-node embedded run we found out the following behaviour: [this
code
|https://github.com/apache/ignite-3/blob/82c74598b5006ea3e4e86da744a68022dd799c89/modules/replicator/src/main/java/org/apache/ignite/internal/replicator/ReplicaService.java#L92]
takes significant time to execute, because of whenCompleteAsync:
{code:java}
private CompletableFuture sendToReplica(String targetNodeConsistentId,
ReplicaRequest req) {
CompletableFuture res = new CompletableFuture<>();
// TODO: IGNITE-17824 Use named executor instead of default one in
order to process replica Response.
messagingService.invoke(targetNodeConsistentId, req,
RPC_TIMEOUT).whenCompleteAsync(
{code}
The simple switch to simple whenComplete give us a boost from 26us/s to 13us/s
in the 1-node fsync=false run of SelectBenchmark.kvGet
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20867) [Thin client] Server nodes crash after create persistent cache with /" name
[
https://issues.apache.org/jira/browse/IGNITE-20867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Amelchev updated IGNITE-20867:
-
Summary: [Thin client] Server nodes crash after create persistent cache
with /" name (was: [Thin client] Server nodes crash cluster after create
persistent cache with /" name )
> [Thin client] Server nodes crash after create persistent cache with /" name
>
>
> Key: IGNITE-20867
> URL: https://issues.apache.org/jira/browse/IGNITE-20867
> Project: Ignite
> Issue Type: Bug
>Reporter: Anastasia Iakimova
>Assignee: Anastasia Iakimova
>Priority: Major
> Labels: ise
>
> ignite.log:
> {code:java}
> 2023-11-14 18:12:34.985 [INFO
> ][exchange-worker-#75][org.apache.ignite.internal.exchange.time] Started
> exchange init [topVer=AffinityTopologyVersion [topVer=4, minorTopVer=32],
> crd=false, evt=DISCOVERY_CUSTOM_EVT, evtNode=d91c8f37
> -dc4f-435e-97dc-8ec02b953b6a, customEvt=DynamicCacheChangeBatch
> [id=3a05698cb81-782afb33-985f-4efc-a47f-2c178ae29301, reqs=ArrayList
> [DynamicCacheChangeRequest [cacheName=/", hasCfg=true,
> nodeId=d91c8f37-dc4f-435e-97dc-8ec02b953b6
> a, clientStartOnly=false, stop=false, destroy=false,
> disabledAfterStart=false]], exchangeActions=ExchangeActions
> [startCaches=[/"], stopCaches=null, startGrps=[/"], stopGrps=[],
> resetParts=null, finalizePartitionCounters=false, stateChangeRequest=null],
> startCaches=false], allowMerge=false, exchangeFreeSwitch=false]
> 2023-11-14 18:12:34.989 [ERROR][exchange-worker-#75][] Critical system error
> detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.IgniteCheckedException: Failed to initialize cache working directory
> (failed to create, make sure the work folder has correct permissions):
> /u01/ift/storage/server/data/ise_ift_ignite05/cache-/"]]
> org.apache.ignite.IgniteCheckedException: Failed to initialize cache working
> directory (failed to create, make sure the work folder has correct
> permissions): /u01/ift/storage/server/data/ise_ift_ignite05/cache-/"
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.checkAndInitCacheWorkDir(FilePageStoreManager.java:796)
> ~[ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.CachesRegistry.persistCacheConfigurations(CachesRegistry.java:275)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.CachesRegistry.registerAllCachesAndGroups(CachesRegistry.java:262)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.CachesRegistry.update(CachesRegistry.java:200)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:877)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:1462)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:980)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3338)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:3172)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: java.nio.file.NoSuchFileException:
> /u01/ift/storage/server/data/ise_ift_ignite05/cache-/"
> at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) ~[?:?]
> at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) ~[?:?]
> at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) ~[?:?]
> at
>
[jira] [Updated] (IGNITE-20867) [Thin client] Server nodes crash cluster after create persistent cache with /" name
[
https://issues.apache.org/jira/browse/IGNITE-20867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Amelchev updated IGNITE-20867:
-
Summary: [Thin client] Server nodes crash cluster after create persistent
cache with /" name (was: [Thin client] Server nodes crash cluster after
create cache with /" name )
> [Thin client] Server nodes crash cluster after create persistent cache with
> /" name
>
>
> Key: IGNITE-20867
> URL: https://issues.apache.org/jira/browse/IGNITE-20867
> Project: Ignite
> Issue Type: Bug
>Reporter: Anastasia Iakimova
>Assignee: Anastasia Iakimova
>Priority: Major
> Labels: ise
>
> ignite.log:
> {code:java}
> 2023-11-14 18:12:34.985 [INFO
> ][exchange-worker-#75][org.apache.ignite.internal.exchange.time] Started
> exchange init [topVer=AffinityTopologyVersion [topVer=4, minorTopVer=32],
> crd=false, evt=DISCOVERY_CUSTOM_EVT, evtNode=d91c8f37
> -dc4f-435e-97dc-8ec02b953b6a, customEvt=DynamicCacheChangeBatch
> [id=3a05698cb81-782afb33-985f-4efc-a47f-2c178ae29301, reqs=ArrayList
> [DynamicCacheChangeRequest [cacheName=/", hasCfg=true,
> nodeId=d91c8f37-dc4f-435e-97dc-8ec02b953b6
> a, clientStartOnly=false, stop=false, destroy=false,
> disabledAfterStart=false]], exchangeActions=ExchangeActions
> [startCaches=[/"], stopCaches=null, startGrps=[/"], stopGrps=[],
> resetParts=null, finalizePartitionCounters=false, stateChangeRequest=null],
> startCaches=false], allowMerge=false, exchangeFreeSwitch=false]
> 2023-11-14 18:12:34.989 [ERROR][exchange-worker-#75][] Critical system error
> detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.IgniteCheckedException: Failed to initialize cache working directory
> (failed to create, make sure the work folder has correct permissions):
> /u01/ift/storage/server/data/ise_ift_ignite05/cache-/"]]
> org.apache.ignite.IgniteCheckedException: Failed to initialize cache working
> directory (failed to create, make sure the work folder has correct
> permissions): /u01/ift/storage/server/data/ise_ift_ignite05/cache-/"
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.checkAndInitCacheWorkDir(FilePageStoreManager.java:796)
> ~[ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.CachesRegistry.persistCacheConfigurations(CachesRegistry.java:275)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.CachesRegistry.registerAllCachesAndGroups(CachesRegistry.java:262)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.CachesRegistry.update(CachesRegistry.java:200)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:877)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:1462)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:980)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3338)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:3172)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: java.nio.file.NoSuchFileException:
> /u01/ift/storage/server/data/ise_ift_ignite05/cache-/"
> at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) ~[?:?]
> at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) ~[?:?]
> at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) ~[?:?]
> at
>
[jira] [Updated] (IGNITE-20867) [Thin client] Server nodes crash cluster after create cache with /" name
[
https://issues.apache.org/jira/browse/IGNITE-20867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Amelchev updated IGNITE-20867:
-
Summary: [Thin client] Server nodes crash cluster after create cache with
/" name (was: [Thin client] Fix stop cluster after create cache with /" name )
> [Thin client] Server nodes crash cluster after create cache with /" name
> -
>
> Key: IGNITE-20867
> URL: https://issues.apache.org/jira/browse/IGNITE-20867
> Project: Ignite
> Issue Type: Bug
>Reporter: Anastasia Iakimova
>Assignee: Anastasia Iakimova
>Priority: Major
> Labels: ise
>
> ignite.log:
> {code:java}
> 2023-11-14 18:12:34.985 [INFO
> ][exchange-worker-#75][org.apache.ignite.internal.exchange.time] Started
> exchange init [topVer=AffinityTopologyVersion [topVer=4, minorTopVer=32],
> crd=false, evt=DISCOVERY_CUSTOM_EVT, evtNode=d91c8f37
> -dc4f-435e-97dc-8ec02b953b6a, customEvt=DynamicCacheChangeBatch
> [id=3a05698cb81-782afb33-985f-4efc-a47f-2c178ae29301, reqs=ArrayList
> [DynamicCacheChangeRequest [cacheName=/", hasCfg=true,
> nodeId=d91c8f37-dc4f-435e-97dc-8ec02b953b6
> a, clientStartOnly=false, stop=false, destroy=false,
> disabledAfterStart=false]], exchangeActions=ExchangeActions
> [startCaches=[/"], stopCaches=null, startGrps=[/"], stopGrps=[],
> resetParts=null, finalizePartitionCounters=false, stateChangeRequest=null],
> startCaches=false], allowMerge=false, exchangeFreeSwitch=false]
> 2023-11-14 18:12:34.989 [ERROR][exchange-worker-#75][] Critical system error
> detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.IgniteCheckedException: Failed to initialize cache working directory
> (failed to create, make sure the work folder has correct permissions):
> /u01/ift/storage/server/data/ise_ift_ignite05/cache-/"]]
> org.apache.ignite.IgniteCheckedException: Failed to initialize cache working
> directory (failed to create, make sure the work folder has correct
> permissions): /u01/ift/storage/server/data/ise_ift_ignite05/cache-/"
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.checkAndInitCacheWorkDir(FilePageStoreManager.java:796)
> ~[ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.CachesRegistry.persistCacheConfigurations(CachesRegistry.java:275)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.CachesRegistry.registerAllCachesAndGroups(CachesRegistry.java:262)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.CachesRegistry.update(CachesRegistry.java:200)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:877)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:1462)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:980)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3338)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:3172)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: java.nio.file.NoSuchFileException:
> /u01/ift/storage/server/data/ise_ift_ignite05/cache-/"
> at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) ~[?:?]
> at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) ~[?:?]
> at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) ~[?:?]
> at
> sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:389)
[jira] [Updated] (IGNITE-20867) [Thin client] Fix stop cluster after create cache with /" name
[
https://issues.apache.org/jira/browse/IGNITE-20867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anastasia Iakimova updated IGNITE-20867:
Summary: [Thin client] Fix stop cluster after create cache with /" name
(was: [Thin client] Fix channel closing on create cache with /" name)
> [Thin client] Fix stop cluster after create cache with /" name
> ---
>
> Key: IGNITE-20867
> URL: https://issues.apache.org/jira/browse/IGNITE-20867
> Project: Ignite
> Issue Type: Bug
>Reporter: Anastasia Iakimova
>Assignee: Anastasia Iakimova
>Priority: Major
> Labels: ise
>
> ignite.log:
> {code:java}
> 2023-11-14 18:12:34.985 [INFO
> ][exchange-worker-#75][org.apache.ignite.internal.exchange.time] Started
> exchange init [topVer=AffinityTopologyVersion [topVer=4, minorTopVer=32],
> crd=false, evt=DISCOVERY_CUSTOM_EVT, evtNode=d91c8f37
> -dc4f-435e-97dc-8ec02b953b6a, customEvt=DynamicCacheChangeBatch
> [id=3a05698cb81-782afb33-985f-4efc-a47f-2c178ae29301, reqs=ArrayList
> [DynamicCacheChangeRequest [cacheName=/", hasCfg=true,
> nodeId=d91c8f37-dc4f-435e-97dc-8ec02b953b6
> a, clientStartOnly=false, stop=false, destroy=false,
> disabledAfterStart=false]], exchangeActions=ExchangeActions
> [startCaches=[/"], stopCaches=null, startGrps=[/"], stopGrps=[],
> resetParts=null, finalizePartitionCounters=false, stateChangeRequest=null],
> startCaches=false], allowMerge=false, exchangeFreeSwitch=false]
> 2023-11-14 18:12:34.989 [ERROR][exchange-worker-#75][] Critical system error
> detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.IgniteCheckedException: Failed to initialize cache working directory
> (failed to create, make sure the work folder has correct permissions):
> /u01/ift/storage/server/data/ise_ift_ignite05/cache-/"]]
> org.apache.ignite.IgniteCheckedException: Failed to initialize cache working
> directory (failed to create, make sure the work folder has correct
> permissions): /u01/ift/storage/server/data/ise_ift_ignite05/cache-/"
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.checkAndInitCacheWorkDir(FilePageStoreManager.java:796)
> ~[ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.CachesRegistry.persistCacheConfigurations(CachesRegistry.java:275)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.CachesRegistry.registerAllCachesAndGroups(CachesRegistry.java:262)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.CachesRegistry.update(CachesRegistry.java:200)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:877)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:1462)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:980)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3338)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:3172)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: java.nio.file.NoSuchFileException:
> /u01/ift/storage/server/data/ise_ift_ignite05/cache-/"
> at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) ~[?:?]
> at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) ~[?:?]
> at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) ~[?:?]
> at
> sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:389)
> ~[?:?]
> at
[jira] [Created] (IGNITE-20867) [Thin client] Fix channel closing on create cache with /" name
Anastasia Iakimova created IGNITE-20867:
---
Summary: [Thin client] Fix channel closing on create cache with /"
name
Key: IGNITE-20867
URL: https://issues.apache.org/jira/browse/IGNITE-20867
Project: Ignite
Issue Type: Bug
Reporter: Anastasia Iakimova
ignite.log:
{code:java}
2023-11-14 18:12:34.985 [INFO
][exchange-worker-#75][org.apache.ignite.internal.exchange.time] Started
exchange init [topVer=AffinityTopologyVersion [topVer=4, minorTopVer=32],
crd=false, evt=DISCOVERY_CUSTOM_EVT, evtNode=d91c8f37
-dc4f-435e-97dc-8ec02b953b6a, customEvt=DynamicCacheChangeBatch
[id=3a05698cb81-782afb33-985f-4efc-a47f-2c178ae29301, reqs=ArrayList
[DynamicCacheChangeRequest [cacheName=/", hasCfg=true,
nodeId=d91c8f37-dc4f-435e-97dc-8ec02b953b6
a, clientStartOnly=false, stop=false, destroy=false,
disabledAfterStart=false]], exchangeActions=ExchangeActions [startCaches=[/"],
stopCaches=null, startGrps=[/"], stopGrps=[], resetParts=null,
finalizePartitionCounters=false, stateChangeRequest=null], startCaches=false],
allowMerge=false, exchangeFreeSwitch=false]
2023-11-14 18:12:34.989 [ERROR][exchange-worker-#75][] Critical system error
detected. Will be handled accordingly to configured handler
[hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
o.a.i.IgniteCheckedException: Failed to initialize cache working directory
(failed to create, make sure the work folder has correct permissions):
/u01/ift/storage/server/data/ise_ift_ignite05/cache-/"]]
org.apache.ignite.IgniteCheckedException: Failed to initialize cache working
directory (failed to create, make sure the work folder has correct
permissions): /u01/ift/storage/server/data/ise_ift_ignite05/cache-/"
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.checkAndInitCacheWorkDir(FilePageStoreManager.java:796)
~[ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
at
org.apache.ignite.internal.processors.cache.CachesRegistry.persistCacheConfigurations(CachesRegistry.java:275)
[ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
at
org.apache.ignite.internal.processors.cache.CachesRegistry.registerAllCachesAndGroups(CachesRegistry.java:262)
[ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
at
org.apache.ignite.internal.processors.cache.CachesRegistry.update(CachesRegistry.java:200)
[ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
at
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:877)
[ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:1462)
[ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:980)
[ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3338)
[ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:3172)
[ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
[ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
at java.lang.Thread.run(Thread.java:834) [?:?]
Caused by: java.nio.file.NoSuchFileException:
/u01/ift/storage/server/data/ise_ift_ignite05/cache-/"
at
sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) ~[?:?]
at
sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) ~[?:?]
at
sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) ~[?:?]
at
sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:389)
~[?:?]
at java.nio.file.Files.createDirectory(Files.java:690) ~[?:?]
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.checkAndInitCacheWorkDir(FilePageStoreManager.java:791)
~[ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
... 10 more
2023-11-14 18:12:34.997 [WARN
][exchange-worker-#75][org.apache.ignite.internal.processors.cache.CacheDiagnosticManager]
Page locks dump:
2023-11-14 18:12:34.998 [ERROR][exchange-worker-#75][] JVM will be halted
immediately due to the failure:
[jira] [Assigned] (IGNITE-20867) [Thin client] Fix channel closing on create cache with /" name
[
https://issues.apache.org/jira/browse/IGNITE-20867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anastasia Iakimova reassigned IGNITE-20867:
---
Assignee: Anastasia Iakimova
> [Thin client] Fix channel closing on create cache with /" name
> --
>
> Key: IGNITE-20867
> URL: https://issues.apache.org/jira/browse/IGNITE-20867
> Project: Ignite
> Issue Type: Bug
>Reporter: Anastasia Iakimova
>Assignee: Anastasia Iakimova
>Priority: Major
> Labels: ise
>
> ignite.log:
> {code:java}
> 2023-11-14 18:12:34.985 [INFO
> ][exchange-worker-#75][org.apache.ignite.internal.exchange.time] Started
> exchange init [topVer=AffinityTopologyVersion [topVer=4, minorTopVer=32],
> crd=false, evt=DISCOVERY_CUSTOM_EVT, evtNode=d91c8f37
> -dc4f-435e-97dc-8ec02b953b6a, customEvt=DynamicCacheChangeBatch
> [id=3a05698cb81-782afb33-985f-4efc-a47f-2c178ae29301, reqs=ArrayList
> [DynamicCacheChangeRequest [cacheName=/", hasCfg=true,
> nodeId=d91c8f37-dc4f-435e-97dc-8ec02b953b6
> a, clientStartOnly=false, stop=false, destroy=false,
> disabledAfterStart=false]], exchangeActions=ExchangeActions
> [startCaches=[/"], stopCaches=null, startGrps=[/"], stopGrps=[],
> resetParts=null, finalizePartitionCounters=false, stateChangeRequest=null],
> startCaches=false], allowMerge=false, exchangeFreeSwitch=false]
> 2023-11-14 18:12:34.989 [ERROR][exchange-worker-#75][] Critical system error
> detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.IgniteCheckedException: Failed to initialize cache working directory
> (failed to create, make sure the work folder has correct permissions):
> /u01/ift/storage/server/data/ise_ift_ignite05/cache-/"]]
> org.apache.ignite.IgniteCheckedException: Failed to initialize cache working
> directory (failed to create, make sure the work folder has correct
> permissions): /u01/ift/storage/server/data/ise_ift_ignite05/cache-/"
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.checkAndInitCacheWorkDir(FilePageStoreManager.java:796)
> ~[ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.CachesRegistry.persistCacheConfigurations(CachesRegistry.java:275)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.CachesRegistry.registerAllCachesAndGroups(CachesRegistry.java:262)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.CachesRegistry.update(CachesRegistry.java:200)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:877)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:1462)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:980)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3338)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:3172)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: java.nio.file.NoSuchFileException:
> /u01/ift/storage/server/data/ise_ift_ignite05/cache-/"
> at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) ~[?:?]
> at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) ~[?:?]
> at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) ~[?:?]
> at
> sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:389)
> ~[?:?]
> at java.nio.file.Files.createDirectory(Files.java:690) ~[?:?]
> at
>
[jira] [Assigned] (IGNITE-20866) Race condition in configuration initialization using meta storage revision
[
https://issues.apache.org/jira/browse/IGNITE-20866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin reassigned IGNITE-20866:
--
Assignee: Ivan Gagarkin
> Race condition in configuration initialization using meta storage revision
> --
>
> Key: IGNITE-20866
> URL: https://issues.apache.org/jira/browse/IGNITE-20866
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Gagarkin
>Assignee: Ivan Gagarkin
>Priority: Critical
> Labels: ignite-3
>
> {*}Summary{*}{_}:{_} Initialization of the cluster configuration using meta
> storage revision 0 leads to race conditions, resulting in potential
> misconfiguration.
> {*}Analysis{*}: Currently, the system applies the initial cluster
> configuration locally when the meta-storage revision is at 0. This approach
> can lead to race conditions where the initial configuration might be
> overlooked if the revision number changes during the initialization process.
> _Suggested Fix:_ We should modify the initialization logic to:
> # Use the local revision of the configuration key.
> # If the local revision is absent, only then fall back to the initial
> configuration.
> This approach would prevent the configuration from being ignored due to
> changes in the meta-store revision.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20866) Race condition in configuration initialization using meta storage revision
Ivan Gagarkin created IGNITE-20866:
--
Summary: Race condition in configuration initialization using meta
storage revision
Key: IGNITE-20866
URL: https://issues.apache.org/jira/browse/IGNITE-20866
Project: Ignite
Issue Type: Bug
Reporter: Ivan Gagarkin
{*}Summary{*}{_}:{_} Initialization of the cluster configuration using meta
storage revision 0 leads to race conditions, resulting in potential
misconfiguration.
{*}Analysis{*}: Currently, the system applies the initial cluster configuration
locally when the meta-storage revision is at 0. This approach can lead to race
conditions where the initial configuration might be overlooked if the revision
number changes during the initialization process.
_Suggested Fix:_ We should modify the initialization logic to:
# Use the local revision of the configuration key.
# If the local revision is absent, only then fall back to the initial
configuration.
This approach would prevent the configuration from being ignored due to changes
in the meta-store revision.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20832) .NET: Thin 3.0: TestDroppedConnectionIsRestoredOnDemand is flaky
[
https://issues.apache.org/jira/browse/IGNITE-20832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786331#comment-17786331
]
Pavel Tupitsyn commented on IGNITE-20832:
-
100 green builds:
https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunNetTests?branch=pull%2F2842=overview=builds#all-projects
> .NET: Thin 3.0: TestDroppedConnectionIsRestoredOnDemand is flaky
>
>
> Key: IGNITE-20832
> URL: https://issues.apache.org/jira/browse/IGNITE-20832
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Can be reproduced locally by running the test in a loop (Run Selected Tests
> Until Failure in Rider)
> {code}
> Expected: No Exception to be thrown
> But was: at
> Apache.Ignite.Internal.ClientFailoverSocket.DoOutInOpAndGetSocketAsync(ClientOp
> clientOp, Transaction tx, PooledArrayBuffer request, PreferredNode
> preferredNode, IRetryPolicy retryPolicyOverride) in
> /home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/ClientFailoverSocket.cs:line
> 195
>at Apache.Ignite.Internal.ClientFailoverSocket.DoOutInOpAsync(ClientOp
> clientOp, PooledArrayBuffer request, PreferredNode preferredNode) in
> /home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/ClientFailoverSocket.cs:line
> 153
>at Apache.Ignite.Internal.Table.Tables.GetTablesAsync() in
> /home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/Table/Tables.cs:line
> 63
>at
> Apache.Ignite.Tests.ReconnectTests.<>c__DisplayClass3_0.d.MoveNext()
> in
> /home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite.Tests/ReconnectTests.cs:line
> 80
> --- End of stack trace from previous location ---
>at
> NUnit.Framework.Internal.TaskAwaitAdapter.GenericAdapter`1.BlockUntilCompleted()
>at
> NUnit.Framework.Internal.MessagePumpStrategy.NoMessagePumpStrategy.WaitForCompletion(AwaitAdapter
> awaiter)
>at NUnit.Framework.Internal.AsyncToSyncAdapter.Await(Func`1 invoke)
>at NUnit.Framework.Internal.ExceptionHelper.RecordException(Delegate
> parameterlessDelegate, String parameterName)>
>at
> Apache.Ignite.Tests.ReconnectTests.TestDroppedConnectionIsRestoredOnDemand()
> in
> /home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite.Tests/ReconnectTests.cs:line
> 80
>at
> System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.AsyncStateMachineBox`1.ExecutionContextCallback(Object
> s)
>at
> Apache.Ignite.Tests.ReconnectTests.TestDroppedConnectionIsRestoredOnDemand()
> in
> /home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite.Tests/ReconnectTests.cs:line
> 80
>at
> NUnit.Framework.Internal.TaskAwaitAdapter.GenericAdapter`1.BlockUntilCompleted()
>at
> NUnit.Framework.Internal.MessagePumpStrategy.NoMessagePumpStrategy.WaitForCompletion(AwaitAdapter
> awaiter)
>at NUnit.Framework.Internal.AsyncToSyncAdapter.Await(Func`1 invoke)
>at
> NUnit.Framework.Internal.Commands.TestMethodCommand.RunTestMethod(TestExecutionContext
> context)
>at
> NUnit.Framework.Internal.Commands.TestMethodCommand.Execute(TestExecutionContext
> context)
>at
> NUnit.Framework.Internal.Commands.TimeoutCommand.<>c__DisplayClass5_0.b__0()
>at System.Threading.Tasks.Task`1.InnerInvoke()
>at System.Threading.Tasks.Task.<>c.<.cctor>b__272_0(Object obj)
> -
> One or more child tests had errors
> Exception doesn't have a stacktrace
> Fake server started [port=40179, test=TestDroppedConnectionIsRestoredOnDemand]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20865) Ignite 3.0: Criteria API queries
Andrey Novikov created IGNITE-20865: --- Summary: Ignite 3.0: Criteria API queries Key: IGNITE-20865 URL: https://issues.apache.org/jira/browse/IGNITE-20865 Project: Ignite Issue Type: Epic Components: sql Reporter: Andrey Novikov Criteria Query is logically just a facade for SQL – same way as Criteria API is a facade for SQL in JPA. The easiest way to implement this feature then is to just generate SQL queries. There are different gateways to a table called Table Views. Currently we have RecordView and KeyValueView. *Each view* should have the Criteria Query API. The only difference is the type of objects the query result maps to. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20852) Connection attempt clinches may cause connection failure
[ https://issues.apache.org/jira/browse/IGNITE-20852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-20852: --- Summary: Connection attempt clinches may cause connection failure (was: Connection attempt clinches may case connection failure) > Connection attempt clinches may cause connection failure > > > Key: IGNITE-20852 > URL: https://issues.apache.org/jira/browse/IGNITE-20852 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > A clinch is a situation when two nodes (A and B) try to establish logical > connections to each other at the same time. Only one of the connections can > remain, so another one is aborted. When such an abortion happens, the client > that initiated the aborted physical connection must be transparently switched > to the connection opened 'from the other side'. > Instead, in most of the clinches, MessagingService gets an exception as a > result of the clinch resolution on one of the sides. We must avoid this. > Another problem is that the clinch resulution protocol sometimes kills an > 'almost established connection' (or even a fully estabished connection) [that > has managed to aquire recovery descriptors on both sides] just because > another connection (that has just failed to aquire first recovery descriptor) > is preferred by the tie-breaker. The tie-breaker must only be used in true > clinch situations (each of the competitors have 1 descriptor aquired). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20701) Thin 3.0: Partition awareness uses leader instead of primary replica
[ https://issues.apache.org/jira/browse/IGNITE-20701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786319#comment-17786319 ] Igor Sapego commented on IGNITE-20701: -- Looks good to me. > Thin 3.0: Partition awareness uses leader instead of primary replica > > > Key: IGNITE-20701 > URL: https://issues.apache.org/jira/browse/IGNITE-20701 > Project: Ignite > Issue Type: Bug > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > h2. Problem > * *Partition Leader* and *Primary Partition Replica* can be two different > nodes. > * Primary replica can handle requests more efficiently > * *InternalTableImpl#assignments* is used for client partition awareness, but > it returns leaders > h2. Action Items > * Fix *ClientTablePartitionAssignmentGetRequest* to return primary replica > per partition > * Fix *ClientInboundMessageHandler.onPartitionAssignmentChanged* to notify > about primary change (lease based?) > All the fixes are server-side; in theory, we don't need to fix the clients. > Consult [~sanpwc] for more details. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20852) Connection attempt clinches may case connection failure
[ https://issues.apache.org/jira/browse/IGNITE-20852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy reassigned IGNITE-20852: -- Assignee: Roman Puchkovskiy > Connection attempt clinches may case connection failure > --- > > Key: IGNITE-20852 > URL: https://issues.apache.org/jira/browse/IGNITE-20852 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > A clinch is a situation when two nodes (A and B) try to establish logical > connections to each other at the same time. Only one of the connections can > remain, so another one is aborted. When such an abortion happens, the client > that initiated the aborted physical connection must be transparently switched > to the connection opened 'from the other side'. > Instead, in most of the clinches, MessagingService gets an exception as a > result of the clinch resolution on one of the sides. We must avoid this. > Another problem is that the clinch resulution protocol sometimes kills an > 'almost established connection' (or even a fully estabished connection) [that > has managed to aquire recovery descriptors on both sides] just because > another connection (that has just failed to aquire first recovery descriptor) > is preferred by the tie-breaker. The tie-breaker must only be used in true > clinch situations (each of the competitors have 1 descriptor aquired). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20860) Сheck the correctness of the catalog version recovery
[ https://issues.apache.org/jira/browse/IGNITE-20860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786309#comment-17786309 ] Roman Puchkovskiy commented on IGNITE-20860: The patch looks good to me > Сheck the correctness of the catalog version recovery > - > > Key: IGNITE-20860 > URL: https://issues.apache.org/jira/browse/IGNITE-20860 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > I did not find a test that would check that when restoring the catalog > versions during the node recovery phase, they were correct. > So that there would be no situation that after restoring the catalog, the > versions would be at those timestamps at which they were actually created and > not the timestamp of the start of the node, for example. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20594) Replace ThreadLocal ByteBuffer with PooledAllocator
[ https://issues.apache.org/jira/browse/IGNITE-20594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuri Naryshkin reassigned IGNITE-20594: --- Assignee: Yuri Naryshkin (was: Nikolay Izhikov) > Replace ThreadLocal ByteBuffer with PooledAllocator > --- > > Key: IGNITE-20594 > URL: https://issues.apache.org/jira/browse/IGNITE-20594 > Project: Ignite > Issue Type: Task >Reporter: Nikolay Izhikov >Assignee: Yuri Naryshkin >Priority: Major > Labels: IEP-109, ise > > Current approach uses thread local ByteBuffer to write data while dumping > caches. > This can lead to memory overhead when only some threads from pool modifies > data (call writeChanged) and for each thread separate ByteBuffer allocated. > We have PooledAllocator that can provide ability to reduce memory overhead. > Need to study if it can be used in this case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20768) Test coverege of batch operations
[
https://issues.apache.org/jira/browse/IGNITE-20768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-20768:
Assignee: Kirill Sizov
> Test coverege of batch operations
> -
>
> Key: IGNITE-20768
> URL: https://issues.apache.org/jira/browse/IGNITE-20768
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Kirill Sizov
>Priority: Major
> Labels: ignite-3
>
> Investigation during the implementation of IGNITE-20609 shows that no one
> fails when we have a mistace in the patch.
> The first place not covered by tests in the code:
> {code:title=PartitionReplicaListener.java}
> if (lastCommitTimestamp != null || row != null) {
> TimedBinaryRowMessageBuilder rowMsgBldr =
> MSG_FACTORY.timedBinaryRowMessage();
> if (lastCommitTimestamp != null) {
> rowMsgBldr.timestamp(lastCommitTimestamp.longValue());
> }
> if (row != null) {
> rowMsgBldr.binaryRowMessage(binaryRowMessage(row));
> }
> bldr.messageRowToUpdate(rowMsgBldr.build());
> }
> {code}
> We need to add a test for batch operations that has both fields (not nulles):
> _lastCommitTimestamp_ and _row_.
> The second
> {code:title=StorageUpdateHandler.java}
> performStorageCleanupIfNeeded(txId, rowId, entry.getValue() == null ? null :
> entry.getValue().commitTimestamp());
> {code}
> We need to add a test for batch operations where `entry.getValue()` is null.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20766) Deal with the primary replica provider in integration tests
[ https://issues.apache.org/jira/browse/IGNITE-20766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-20766: Assignee: Vladislav Pyatkov > Deal with the primary replica provider in integration tests > --- > > Key: IGNITE-20766 > URL: https://issues.apache.org/jira/browse/IGNITE-20766 > Project: Ignite > Issue Type: Bug >Reporter: Kirill Tkalenko >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > In the process of implementing IGNITE-20678, it turned out that using > *TestPlacementDriver* in tests *ItRebalanceDistributedTest* and > *ItIgniteNodeRestartTest* does not look correct, since for each node the > primary replica will be defined as the node (primary replica) itself, which > can lead to unpredictable behavior, we need to figure this out. > Definition of done > Both thests have an integration nature; the cluster contains more than one > node, and the nodes use the network. In these circumstances, the primary > replica can be changed during an integration test and is not predetermined. > # I believe the test implementation of the placement drive is not applicable > here; this is a better way to instance the production implementation. Look at > the PR attached. > # Or it would be better to rewrite the test to use the original Ignite node > instead of the particular instantiated nodes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20365) Add ability to intentionally change primary replica
[
https://issues.apache.org/jira/browse/IGNITE-20365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-20365:
Assignee: Alexander Lapin
> Add ability to intentionally change primary replica
> ---
>
> Key: IGNITE-20365
> URL: https://issues.apache.org/jira/browse/IGNITE-20365
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
> Labels: ignite-3
>
> Some tests, e.g. testTxStateReplicaRequestMissLeaderMiss expects primary
> replica to be changed. Earlier when primary replica was collocated with
> leader refreshAndGetLeaderWithTerm was used in order to change leader and
> thus primary replica. Now when Placement driver assigns primary replica it's
> no longer the case. All in all, some PlacementDriver#changePrimaryReplica or
> similar will be useful, at least within tests.
>
> *Implementation Details*
> +Important note:+ The lease contract prohibits intersecting leases. We don't
> want to break this contract, so we will have to wait until the current lease
> ends before another replica becomes primary.
> There are two ways to implement this functionality - either extend
> {{PlacementDriver}} in the product or change only the test code. Looks like
> the second approach is not enough if we start a test ignite instance using an
> {{IgniteImpl}} class. So we might need to consider extend the production
> code. Moreover, such change might become the first step towards a graceful
> cluster reconfiguration.
> The code that is responsible for managing lease resides in {{LeaseTracker}}
> and {{LeaseUpdater}}. To do the required change we can add a pending lease
> with the start time in the future. We should make sure that both there
> places, as well as any recovery code accounts for it. Now the next lease is
> added ONLY when the current one ends.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20779) Transaction operation might throw no exception on enlisting attempt, while transaction is in FINISHING state
[
https://issues.apache.org/jira/browse/IGNITE-20779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-20779:
Assignee: Vladislav Pyatkov
> Transaction operation might throw no exception on enlisting attempt, while
> transaction is in FINISHING state
>
>
> Key: IGNITE-20779
> URL: https://issues.apache.org/jira/browse/IGNITE-20779
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> Read-write lock is used in ReadWriteTransactionImpl to _enlist_ a partition
> and to _finish_ the transaction ({_}read{_} and _write_ locks are acquired
> respectively). But only final state is checked inside the lock (COMMITTED or
> ABORTED), while this state is set asynchronously when the transaction is
> finished *and* the response is received from the commit partition.
> ReadWriteTransactionImpl#finish sets FINISHING state synchronously, so this
> state must also be checked within the locks.
> h3. Implementation notes
> # Add checking the FINISHING state to the method
> ReadWriteTransactionImpl#checkEnlistReady
> # add checking the FINISHING state to the method
> ReadWriteTransactionImpl#finish
> # rename checkEnlistReady to checkEnlistPossible (optional)
> # add assertion that ReadWriteTransactionImpl#finishFuture is null before
> assigning a value to it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20863) Selecting indexes when performing update operations for partition
[ https://issues.apache.org/jira/browse/IGNITE-20863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko reassigned IGNITE-20863: Assignee: Kirill Tkalenko > Selecting indexes when performing update operations for partition > - > > Key: IGNITE-20863 > URL: https://issues.apache.org/jira/browse/IGNITE-20863 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > To implement IGNITE-20125, we need to correctly select the indexes into which > we will insert data during update operations for partitions. > What do we need for this: > # Catalog version of the transaction by beginTs of the txId. > # Catalog version of the update operation for the transaction. > An approximate index selection algorithm: > # Start with the catalog version at the beginning of the transaction. > # Selecting all indexes by catalog version for a specific table. > ## If the index is not in the resulting selection, then simply add it. > ## If the index is already present in the resulting selection, then we do > nothing. > ## If the index is present in the resulting selection but not in the catalog > version, then depending on its status it will be: > ### registered - the index will be removed from the resulting selection. > ### available - will remain in the resulting selection. > # Increase the catalog version, if it is greater than the directory version > for the update operation, then we will complete the index selection, else go > to p. 2. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20605) Restore scaleUp/scaleDown timers
[ https://issues.apache.org/jira/browse/IGNITE-20605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-20605: Assignee: Mirza Aliev > Restore scaleUp/scaleDown timers > > > Key: IGNITE-20605 > URL: https://issues.apache.org/jira/browse/IGNITE-20605 > Project: Ignite > Issue Type: Bug >Reporter: Mirza Aliev >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > > h3. *Motivation* > We need to restore timers that were scheduled before node restart. > h3. *Definition of done* > Timers are rescheduled after restart > h3. *Implementation notes* > It is valid to just schedule local timers according to scaleUp/ScaleDown > timers values from the Catalog, and as a revision take maxScUpFromMap or > maxScDownFromMap from topologyAugmentationMap, where maxScUpFromMap and > maxScDownFromMap are max revision from topologyAugmentationMap of the entry, > which was associated with addition and removal of nodes respectively -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20604) Reimplement CausalityDataNodesEngine#dataNodes according to Catalog and recovery changes
[
https://issues.apache.org/jira/browse/IGNITE-20604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-20604:
Assignee: Mirza Aliev
> Reimplement CausalityDataNodesEngine#dataNodes according to Catalog and
> recovery changes
>
>
> Key: IGNITE-20604
> URL: https://issues.apache.org/jira/browse/IGNITE-20604
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> h3. *Motivation*
> After Catalog was introduced and recovery for Distribution zone manager was
> completed, it is needed to reimplement {{CausalityDataNodesEngine#dataNodes}}
> according to the new circumstances. Most of the code from this method must be
> removed, and entities from the catalog must be reused.
> h3. *Definition of done*
> {{CausalityDataNodesEngine#dataNodes}} is reimplemented according to the new
> circumstances.
> h3. *Implementation notes*
> Seems that we can remove {{CausalityDataNodesEngine#zonesVersionedCfg}} could
> be removed and Catalog must be used, also we don't need logic for
> {{CausalityDataNodesEngine#getLastConfigRevision}} because it is guaranteed
> that immediate scale Up/Down intents will be handled in the corresponding
> handler
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20603) Restore topologyAugmentationMap on a node restart
[
https://issues.apache.org/jira/browse/IGNITE-20603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-20603:
Assignee: Mirza Aliev
> Restore topologyAugmentationMap on a node restart
> -
>
> Key: IGNITE-20603
> URL: https://issues.apache.org/jira/browse/IGNITE-20603
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> h3. *Motivation*
> It is possible that some events were propagated to {{ms.logicalTopology}},
> but restart happened when we were updating topologyAugmentationMap in
> {{DistributionZoneManager#createMetastorageTopologyListener}}. That means
> that augmentation that must be added to {{zone.topologyAugmentationMap}}
> wasn't added and we need to recover this information.
> h3. *Definition of done*
> On a node restart, topologyAugmentationMap must be correctly restored
> according to {{ms.logicalTopology}} state.
> h3. *Implementation notes*
> For every zone, compare {{MS.local.logicalTopology.revision}} with
> max(maxScUpFromMap, maxScDownFromMap). If {{logicalTopology.revision}} is
> greater than max(maxScUpFromMap, maxScDownFromMap), that means that some
> topology changes haven't been propagated to topologyAugmentationMap before
> restart and appropriate timers haven't been scheduled. To fill the gap in
> topologyAugmentationMap, compare {{MS.local.logicalTopology}} with
> {{lastSeenLogicalTopology}} and enhance topologyAugmentationMap with the
> nodes that did not have time to be propagated to topologyAugmentationMap
> before restart. {{lastSeenTopology}} is calculated in the following way: we
> read {{MS.local.dataNodes}}, also we take max(scaleUpTriggerKey,
> scaleDownTriggerKey) and retrieve all additions and removals of nodes from
> the topologyAugmentationMap using max(scaleUpTriggerKey, scaleDownTriggerKey)
> as the left bound. After that apply these changes to the map with nodes
> counters from {{MS.local.dataNodes}} and take nodes only with the positive
> counters. This is the lastSeenTopology. Comparing it with
> {{MS.local.logicalTopology}} will tell us which nodes were not added or
> removed and weren't propagated to topologyAugmentationMap before restart. We
> take these differences and add them to the topologyAugmentationMap. As a
> revision (key for topologyAugmentationMap) take
> {{MS.local.logicalTopology.revision}}. It is safe to take this revision,
> because if some node was added to the {{ms.topology}} after immediate data
> nodes recalculation, this added node must restore this immediate data nodes'
> recalculation intent.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20701) Thin 3.0: Partition awareness uses leader instead of primary replica
[ https://issues.apache.org/jira/browse/IGNITE-20701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786244#comment-17786244 ] Pavel Tupitsyn commented on IGNITE-20701: - Separate ticket created to fix Compute: IGNITE-20864 > Thin 3.0: Partition awareness uses leader instead of primary replica > > > Key: IGNITE-20701 > URL: https://issues.apache.org/jira/browse/IGNITE-20701 > Project: Ignite > Issue Type: Bug > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > h2. Problem > * *Partition Leader* and *Primary Partition Replica* can be two different > nodes. > * Primary replica can handle requests more efficiently > * *InternalTableImpl#assignments* is used for client partition awareness, but > it returns leaders > h2. Action Items > * Fix *ClientTablePartitionAssignmentGetRequest* to return primary replica > per partition > * Fix *ClientInboundMessageHandler.onPartitionAssignmentChanged* to notify > about primary change (lease based?) > All the fixes are server-side; in theory, we don't need to fix the clients. > Consult [~sanpwc] for more details. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20701) Thin 3.0: Partition awareness uses leader instead of primary replica
[ https://issues.apache.org/jira/browse/IGNITE-20701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786245#comment-17786245 ] Pavel Tupitsyn commented on IGNITE-20701: - [~isapego] please have a look too. > Thin 3.0: Partition awareness uses leader instead of primary replica > > > Key: IGNITE-20701 > URL: https://issues.apache.org/jira/browse/IGNITE-20701 > Project: Ignite > Issue Type: Bug > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > h2. Problem > * *Partition Leader* and *Primary Partition Replica* can be two different > nodes. > * Primary replica can handle requests more efficiently > * *InternalTableImpl#assignments* is used for client partition awareness, but > it returns leaders > h2. Action Items > * Fix *ClientTablePartitionAssignmentGetRequest* to return primary replica > per partition > * Fix *ClientInboundMessageHandler.onPartitionAssignmentChanged* to notify > about primary change (lease based?) > All the fixes are server-side; in theory, we don't need to fix the clients. > Consult [~sanpwc] for more details. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20864) IgniteComputeImpl should use primary replica for executeColocated
[ https://issues.apache.org/jira/browse/IGNITE-20864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20864: Description: See IGNITE-20701 for more details. We should use primary replica instead of leader to execute colocated computations. > IgniteComputeImpl should use primary replica for executeColocated > - > > Key: IGNITE-20864 > URL: https://issues.apache.org/jira/browse/IGNITE-20864 > Project: Ignite > Issue Type: Bug > Components: compute >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > See IGNITE-20701 for more details. We should use primary replica instead of > leader to execute colocated computations. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20864) IgniteComputeImpl should use primary replica for executeColocated
Pavel Tupitsyn created IGNITE-20864: --- Summary: IgniteComputeImpl should use primary replica for executeColocated Key: IGNITE-20864 URL: https://issues.apache.org/jira/browse/IGNITE-20864 Project: Ignite Issue Type: Bug Components: compute Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20701) Thin 3.0: Partition awareness uses leader instead of primary replica
[ https://issues.apache.org/jira/browse/IGNITE-20701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20701: Description: h2. Problem * *Partition Leader* and *Primary Partition Replica* can be two different nodes. * Primary replica can handle requests more efficiently * *InternalTableImpl#assignments* is used for client partition awareness, but it returns leaders h2. Action Items * Fix *ClientTablePartitionAssignmentGetRequest* to return primary replica per partition * Fix *ClientInboundMessageHandler.onPartitionAssignmentChanged* to notify about primary change (lease based?) All the fixes are server-side; in theory, we don't need to fix the clients. Consult [~sanpwc] for more details. was: h2. Problem * *Partition Leader* and *Primary Partition Replica* can be two different nodes. * Primary replica can handle requests more efficiently * *InternalTableImpl#assignments* is used for client partition awareness, but it returns leaders h2. Action Items * Fix *ClientTablePartitionAssignmentGetRequest* to return primary replica per partition * Fix *ClientInboundMessageHandler.onPartitionAssignmentChanged* to notify about primary change (lease based?) * Fix *IgniteCompute.executeColocated* the same way All the fixes are server-side; in theory, we don't need to fix the clients. Consult [~sanpwc] for more details. > Thin 3.0: Partition awareness uses leader instead of primary replica > > > Key: IGNITE-20701 > URL: https://issues.apache.org/jira/browse/IGNITE-20701 > Project: Ignite > Issue Type: Bug > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > h2. Problem > * *Partition Leader* and *Primary Partition Replica* can be two different > nodes. > * Primary replica can handle requests more efficiently > * *InternalTableImpl#assignments* is used for client partition awareness, but > it returns leaders > h2. Action Items > * Fix *ClientTablePartitionAssignmentGetRequest* to return primary replica > per partition > * Fix *ClientInboundMessageHandler.onPartitionAssignmentChanged* to notify > about primary change (lease based?) > All the fixes are server-side; in theory, we don't need to fix the clients. > Consult [~sanpwc] for more details. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20854) Configure idleSafeTimePropagationPeriod with a distributed property
[ https://issues.apache.org/jira/browse/IGNITE-20854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy reassigned IGNITE-20854: -- Assignee: Roman Puchkovskiy > Configure idleSafeTimePropagationPeriod with a distributed property > --- > > Key: IGNITE-20854 > URL: https://issues.apache.org/jira/browse/IGNITE-20854 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Gagarkin >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3, tech-debt > Time Spent: 10m > Remaining Estimate: 0h > > Currently, the setting is obtained using system properties. We should make it > a distributed configuration property. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20839) Compute jobs queue
[ https://issues.apache.org/jira/browse/IGNITE-20839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin reassigned IGNITE-20839: -- Assignee: Mikhail Pochatkin > Compute jobs queue > -- > > Key: IGNITE-20839 > URL: https://issues.apache.org/jira/browse/IGNITE-20839 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > > A job queue is a structure showing upcoming Compute jobs for each node. From > this definition it follows that each node will have its own queue and no > mechanism for sharing information about queues is yet expected. > > The standard queue interface is almost enough for us, with the exception of > the priority adding method. When adding jobs to the queue normally, we will > follow the FIFO strategy, i.e. the default priority value when adding a job > to the queue is 0. > > Priority is an int value between [Int.MIN_VALUE, Int.MAX_VALUE]. Jobs with > the same priority have a FIFO resolving strategy. -- This message was sent by Atlassian Jira (v8.20.10#820010)
