My instinct is that this <WRITE> error is just indicating that there's some issue with the TLS communication. Can you confirm using another method that the certificate(s) are appropriate?

What is the error from the API when unsecured? Is there a test version of the API you can test without TLS?

Hi Jack,

Generally it can be a bit difficult to track lock issues because there is not an after-the-fact audit of locks. To answer a question like this would likely need additional context that the WRC (support) could help you collect. In my experience, this may involve setting up a script to collect lock snapshots over intervals so you can review problem periods and cross reference which processes are running at those times and taking those locks. This could involve running irisstat / SystemCheck.

I'm not sure I follow your question about lock propagation - is this a failover mirror or a reporting mirror? If a failover mirror, locking is irrelevant. The primary is sending sets/kills and the backup member has no independent ability to lock / make changes. If R/W reporting - that would be a situation I am less familiar with, though my suspicion is that as locks are stored in memory that they are handled independently on each node.