<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div>Hi All,<br><br></div>We have some issues with a few flows on master where the lock acquired is being <br>released more than once. This could be a real problem in cases where the lock is<br></div>prematurely released for a second command that had acquired the lock which the first <br>command has released.<br><br></div>For instance<br></div><div><br>1. Command A has acquired the VM lock and executes a child command.<br></div>2. The child command releases the lock <br></div>3. Command B now acquires the VM lock<br></div>4. Command A continues execution and finally releases the lock the second time<br></div>5. The Command B&#39;s lock has now been released prematurely by Command A.<br></div><div><br></div><div>The tell tale sign indicating that a flow is one of the offending flows is the warning <br></div><div>message in the logs indicating that a previously released lock is being released again.<br></div><div><br></div><div><pre class="gmail-bz_comment_text gmail-bz_wrap_comment_text" id="gmail-comment_text_0">[org.ovirt.engine.core.bll.lock.InMemoryLockManager] (EE-ManagedThreadFactory-engine-Thread-6) [1435f925] Trying to release exclusive lock which does not exist, lock key: &#39;53cfa6c3-ecd6-4796-84cb-5c53d7c2a77fVDS_FENCE&#39;</pre><br></div>I have seen issues with Live Merge [1], Moving storage domain to maintenance[2] ,<br>VdsNotRespondingTreatmentCommand [3] and Creating a snapshot [4].<br><br></div>I have submitted some patches to fix the issue with Live Merge [5], Moving storage domain to maintenance [6]  and VdsNotRespondingTreatmentCommand [7].<br><br></div>The multiple lock release issue needs to fixed and if you are the owner of a flow please<br></div>make sure the flow does not log a warning message to the logs. There is no single</div><div>solution to fix the issue, this has be done flow by flow. But below are a few pointers</div><div><br></div><div>1. If a command has a callback and the command is executing a child command, which <br></div><div>in turn is executing a few child commands. The child command should also have a</div><div>command callback so that the locks are released by the framework. Example patch [6]</div><div><br></div><div>2. If a parent has acquired the lock and is executing a child command with cloned <br></div><div>context, to make sure that the child does not release the locks acquired by the parent</div><div> pass the cloned parent context with out locks to the child. Example patch [7]</div><div><br></div><div><br></div>Thanks<br><br></div>Ravi<br><br><div><div><div><div><div><div><br>[1] <a href="https://bugzilla.redhat.com/1568556">https://bugzilla.redhat.com/1568556</a><br>[2] <a href="https://bugzilla.redhat.com/1568447">https://bugzilla.redhat.com/1568447</a><br>[3] <a href="https://bugzilla.redhat.com/1571300">https://bugzilla.redhat.com/1571300</a><br>[4] <a href="https://bugzilla.redhat.com/1569625">https://bugzilla.redhat.com/1569625</a></div><div><a href="https://bugzilla.redhat.com/1569625"><br></a></div><div>[5] <a href="https://gerrit.ovirt.org/#/c/90482/">https://gerrit.ovirt.org/#/c/90482/</a></div><div>[6] <a href="https://gerrit.ovirt.org/#/c/90411/">https://gerrit.ovirt.org/#/c/90411/</a></div><div>[7] <a href="https://gerrit.ovirt.org/#/c/90568/">https://gerrit.ovirt.org/#/c/90568/</a><br><div><div><div><div><div><br><br></div></div></div></div></div></div></div></div></div></div></div></div>