--add-opens JVM flag for alarm propagation: unnecessary on 4.0.32+?

Ignition Modules MQTT Modules
1

Per the Alarm Event Propagation docs, alarm propagation requires adding --add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED to data/ignition.conf. I tested this on my local machine on Ignition 8.1 with versions .30, .31, .32, and .34 of MQTT Transmission:

Version --add-opens set Result
.31 NO Every alarm transition fails with JsonIOException from AgentAlarmListener (line 109) → no alarm metric on the wire
.31 YES Works
.32 NO Works
.32 YES Works

Was .32 shipped with changes that make the setting of --add-opens in ignition.conf unnecessary? If so, would it be possible to update the docs?

Why this is relevant to our team: We have multiple ignition instances that we’d like to get alarming data out of using the MQTT Transmission module. If we can simply upgrade the module through the gateway without needing to worry about updating each instance’s ignition.conf file that would be much preferable because the MQTT Transmission Alarm Propagation docs mention that we’d need to stop and restart the Ignition instance to make the edit to ignition.conf, an uptime concern for us.

2

This is interesting. There were some changes to how we convert alarm event Objects and JSON in the code. However, I don’t see anything that should’ve caused this JVM to no longer be required. I suspect certain alarm events would/could be a problem if the JVM arg was not present.

3

Thanks for the reply Wes. Please keep me posted if you have any additional findings or ways to replicate the necessity of the additional parameter. In .32+, I was testing with a Memory Tag (not sure if relevant), no edits to ignition.conf and all the permutations I could think of with alarm triggering, acking, and clearing, publishing to my MQTT broker over JSON. All the messages came through cleanly as I’d expect, and didn’t see anything of concern in the wrapper.log