[
https://issues.apache.org/jira/browse/IGNITE-26690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Pochatkin reassigned IGNITE-26690:
------------------------------------------
Assignee: Mikhail Pochatkin
> Unable to update at least storage profiles
> ------------------------------------------
>
> Key: IGNITE-26690
> URL: https://issues.apache.org/jira/browse/IGNITE-26690
> Project: Ignite
> Issue Type: Bug
> Reporter: Mikhail Efremov
> Assignee: Mikhail Pochatkin
> Priority: Blocker
> Labels: ignite-3, release-3.1.0-blocker
> Attachments: Screenshot 2025-10-13 at 16.25.05.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Description*
> Scenario to reproduce:
> # Download zip archives with CLI and DB, unzip locally and run both with
> ./ignite3-cli-3.1.0/bin/ignite3 and ./ignite3-db-3.0.0/bin/ignite3db with
> defaults and without any changes.
> # Init cluster in CLI with {{cluster init --name=test
> --metastorage-group=defaultNode}}
> # Try to add a new storage profile from
> [docs|https://ignite.apache.org/docs/ignite3/latest/administrators-guide/storage]:
> {{{}node config update
> "ignite.storage.profiles:{rocksProfile{engine:rocksdb,size:10000{}}}"}}
> After step 3 we will get an error:
> {code:java}
> [defaultNode]> node config update
> "ignite.storage.profiles:{rocksProfile{engine:rocksdb,size:10000}}"
> Trace ID: e0d518cf-31d2-4d5d-86bc-48abf0f17aad
> Failed to apply configuration
> {code}
> Screenshot is attached.
> -*Workaround*-
> +{*}UPD{*}: Somewhy seems like the workaround below *doesn't work* sometimes.
> But still worth to mention this.+
> To figure out what is going on we can configure {{jvm arguments with
> -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=127.0.0.1:8000}}
> and attach to the launched AI3 instance, add breakpoint on the single line
> with an exception trowing with the message on {{HoconPresentation.java:93}}
> and retry the scenario (codebase on {{{}branch ignite-3.1.0{}}}). Breakpoint
> will be triggered and in e there will be the true cause:
> {{{}NullPointerException{}}}. In the cause’s stacktrace we will find a
> potential reason: inside {{renderHoconString}} we will fail on {{boolean
> hasInjectedValues = !node.isEmpty() &&
> getFirstNode(node).injectedValueFieldName() != null;}} on line
> {{{}ConverterToMapVisitor.java:154{}}}. The {{node}} and
> {{getFirstNode(node)}} both are possible {{null}} value, but the idea is:
> some read configuration node is null (in particular – storage profiles node).
> Let’s find then that from a time ago AI3's configuration file
> {{etc/ignite-config.conf}} was shrink to this:
> {code:java}
> ignite {
> network {
> nodeFinder {
> netClusterNodes=[
> "localhost:3344"
> ]
> type=STATIC
> }
> port=3344
> }
> }{code}
> We may suspect that the node tries to read this file and insert new storage
> profile, but during tree visiting cannot find {{storage.profiles}} node and
> got NPE then. Let’s insert storage profiles section to the file:
> {code:java}
> ignite {
> network {
> nodeFinder {
> netClusterNodes=[
> "localhost:3344"
> ]
> type=STATIC
> }
> port=3344
> }
> storage {
> profiles=[
> {
> engine=aipersist
> name=default
> replacementMode=CLOCK
> sizeBytes=-1
> }
> ]
> }
> }
> {code}
> And restart the node. Check that the default profile is still there:
> {code:java}
> [defaultNode]> node config show ignite.storage.profiles
> [
> engine=aipersist
> name=default
> replacementMode=CLOCK
> sizeBytes=-1
> ]
> {code}
> ({*}NB{*}: wrong indentation level!)
> Then let’s try to add new {{rocksdb}} storage profile again:
> {code:java}
> [defaultNode]> node config update
> "ignite.storage.profiles:{rocksProfile{engine:rocksdb,size:10000}}"
> Node configuration updated. Restart the node to apply changes.
> {code}
> So, it solved the problem, let’s restart the node and re-check profiles list:
> {code:java}
> [defaultNode]> node config show ignite.storage.profiles
> [
> engine=aipersist
> name=default
> replacementMode=CLOCK
> sizeBytes=-1
> ,
> engine=rocksdb
> name=rocksProfile
> sizeBytes=10000
> writeBufferSizeBytes=67108864
> ]
> {code}
> So, workaround works, but the bug is still presented.
> *Motivation*
> We have to fix this because it’s definitely not normal that on release a user
> is unable to change any piece of configuration and as workaround we want to
> suggest to write all defaults to the configuration file manually to evade
> NPEs.
> *Definition of Done*
> User is able to make any configuration update that is described in
> documentation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
