There are some variables with irregular names in MessageStoreConfig

[daixiansuo]

Base Info

branch: 4.9.x
RocketMQ Version: 4.9.6-SNAPSHOT

Description

There are some variables with irregular names in MessageStoreConfig, as follows:

1. destroyMapedFileIntervalForcibly ----> destroyMappedFileIntervalForcibly
2. putMsgIndexHightWater ----> putMsgIndexHighWater
3. flushLeastPagesWhenWarmMapedFile ----> flushLeastPagesWhenWarmMappedFile
4. warmMapedFileEnable ----> warmMappedFileEnable

What impact will it bring ?

• broker.conf
• It is itself an incorrect.

Finally, as to whether this issue needs to be corrected, I am willing to participate in it if necessary.

[daixiansuo]

---

#6512 Reply：’There may be compatibility issues when modify variable name‘

Yes, I have also considered this aspect of the problem. However, we will eventually have to face this problem.

At present, it seems that only the broker side is affected, and there are three solutions for this problem:

1. Leave it alone and keep it as it is.
2. Direct modification, not compatible with earlier versions, please describe the modification clearly in the release document.
3. Compatible with lower versions, you can add a compatible processing interface to the MixAll.properties2Object(p,o) method, which not only solves the current problem, but also achieves mapping and conversion capabilities.

How do we deal with this issue?

[xdkxlk]

Maybe we need a function like ＂alias＂ before rename the name of configuration

[lizhimins]

The abbreviation such as "Msg" is not standardized. Perhaps we can develop a special item on configuration management, where we need to consider compatibility issues between new and old names when deciding on a new name.

[caigy]

#6512 Reply：’There may be compatibility issues when modify variable name‘

Yes, I have also considered this aspect of the problem. However, we will eventually have to face this problem.

At present, it seems that only the broker side is affected, and there are three solutions for this problem:

1. Leave it alone and keep it as it is.
2. Direct modification, not compatible with earlier versions, please describe the modification clearly in the release document.
3. Compatible with lower versions, you can add a compatible processing interface to the MixAll.properties2Object(p,o) method, which not only solves the current problem, but also achieves mapping and conversion capabilities.

How do we deal with this issue?

Maybe we can add new configuration keys and mark those to be replaced as deprecated first, and make a plan to remove them in a future version.

[daixiansuo]

I'm sorry everyone, l was laid off recently to deal with arbitration matters, so l didn't have time to reply.
Regarding this issue, l will close it first, and we can have a brief communication at the weekly community meeting online.

Finally, thank you all for your replies to this question. @caigy @lizhimins @xdkxlk