Re: [DISCUSS] Allow UPDATE on settings virtual table to change running configuration

[Benedict]

Could you describe the issues? Config that is globally exposed should ideally be immutable with final members, in which case volatile is only necessary if you’re using the config parameter in a tight loop that you need to witness a new value - which shouldn’t apply to any of our config. There are some weird niches, like updating long values on some (unsupported by us) JVMs that may tear. Technically you also require it for visibility with the JMM. But in practice it is mostly unnecessary. Often what seems to be a volatile issue is really something else. On 22 Feb 2023, at 13:18, Benjamin Lerer <b.le...@gmail.com> wrote:  I have seen issues with some updatable parameters which were missing the volatile keyword. Le mer. 22 févr. 2023 à 11:36, Aleksey Yeshchenko <alek...@apple.com> a écrit : FWIW most of those volatile fields, if not in fact all of them, should NOT be volatile at all. Someone started the trend and most folks have been copycatting or doing the same for consistency with the rest of the codebase. Please definitely don’t rely on that. On 21 Feb 2023, at 21:06, Maxim Muzafarov <mmu...@apache.org> wrote: 1. Rely on the volatile keyword in front of fields in the Config class; I would say this is the most confusing option for me because it doesn't give us all the guarantees we need, and also: - We have no explicit control over what exactly we expose to a user. When we modify the JMX API, we're implementing a new method for the MBean, which in turn makes this action an explicit exposure; - The volatile keyword is not the only way to achieve thread safety, and looks strange for the public API design point; - A good example is the setEnableDropCompactStorage method, which changes the volatile field, but is only visible for testing purposes;