Yair Zaslavsky has posted comments on this change.
Change subject: core : BLL changes for Multi-Tier fencing
......................................................................
Patch Set 10: (1 inline comment)
....................................................
File
backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/FenceVdsBaseCommand.java
Line 301: executor = new FencingExecutor(getVds(),
FenceActionType.Status);
Line 302:
fenceInvocationResult.setSucceeded(waitForStatus(getVds().getvds_name(),
getParameters().getAction(), order));
Line 303: }
Line 304: finally {
Line 305: latch.countDown();
You are right. There can be a race between the assignment of the result (done
in the thread executing the fence command) and the await. If you see -
http://stackoverflow.com/questions/65035/in-java-does-return-trump-finally You
can see an example where finally is called before an assignment/usage of the
returned value is performed. in this case, if finally is called before, the
calling thread (that lunched the two threads) may stop blocking on await, and
continue and use the "old data". I suggest we change runThread to return void.
runThread will put an FenceInvocationResult object in a sync queue (perhaps a
blocking queue) .
For "START" - we will dequeue only one element.
For "STOP" - we will dequeue two elements.
FenceInvocationResult must also include the order enum - to determine if this
is a secondary or primary result (as due to agents behavior + multithreading
issues it may be that the first object in the queue is actually for the
secondary device).
Line 306: }
Line 307: }
Line 308: return fenceInvocationResult;
Line 309: }
--
To view, visit http://gerrit.ovirt.org/10260
To unsubscribe, visit http://gerrit.ovirt.org/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I82f243593f2b361ca75d97e06f9aede246d4a1b1
Gerrit-PatchSet: 10
Gerrit-Project: ovirt-engine
Gerrit-Branch: master
Gerrit-Owner: Eli Mesika <emes...@redhat.com>
Gerrit-Reviewer: Eli Mesika <emes...@redhat.com>
Gerrit-Reviewer: Liron Aravot <lara...@redhat.com>
Gerrit-Reviewer: Michael Kublin <mkub...@redhat.com>
Gerrit-Reviewer: Yair Zaslavsky <yzasl...@redhat.com>
Gerrit-Reviewer: liron aravot <liron.ara...@gmail.com>
_______________________________________________
Engine-patches mailing list
Engine-patches@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-patches
