ARTEMIS-6117 allow configuration of journal file lock check period

[gtully]

AssistedBy: Claude

[gtully]

feedback required on the names. do we want to limit to journal-file or leave open to be potentially used by the distributed file lock? The existing JournalLockAcquisitionTimeout is an existing related entry.

[clebertsuconic]

I looked into this from the functionality POV and I think it's okay.

However, I know where this is coming from, and I think the server will still shutdown on critical error when the device (or network) is offline. This is only useful if the server is completely idle and even then I'm not sure if the OS will keep the file handles active in case of a network outage on a NFS.

This may be okay if the server is idle when the network outage happens, but even that would need to be tested I guess.

[jbertram]

Currently have 2 distinct file-lock implementations:

• org.apache.activemq.artemis.core.server.impl.FileLockNodeManager
• org.apache.activemq.artemis.lockmanager.file.FileBasedLockManager

In my opinion, we should consolidate on the lock-manager one, but we'll need to implement some stuff that it's lacking compared to the other one.

In any case, the configuration is done completely differently so I'm OK with this PR.

[gtully]

agree, if the broker is busy it may see an io error before the lock monitor does. But if those errors can be relayed to a client via failed sends/acks that could be ok. We would need to avoid the shutdown up to some threshold.

If we know that the underlying file system has a recovery time of say 5s, and will block during an outage.
What existing configuration options do we have to around journal IO to make it more tolerant?

[gtully]

Relating to blocking writes, the journal-file-open-timeout defaults to 5s, that would cause a critical io error if exceeded. To match a 5s MTR, that would need to be increased otherwise it could trip before the lock monitor.

   <journal-file-open-timeout>15</journal-file-open-timeout>