Arik Hadas has posted comments on this change.

Change subject: engine : Command Executor should persist command before 
submitting to threadpool
......................................................................


Patch Set 2:

(1 comment)

http://gerrit.ovirt.org/#/c/29219/2/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/tasks/CommandExecutor.java
File 
backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/tasks/CommandExecutor.java:

Line 94:                                     break;
Line 95:                                 case REJECTED:
Line 96:                                 case NOT_STARTED:
Line 97:                                     
executeAsyncCommand(cmdEntity.getCommandType(), 
cmdEntity.getActionParameters());
Line 98:                                     break;
> I would consider having a method (boolean method) which indicates whether t
I would say that we should not save rejected/not_started commands in the DB if 
the boolean you suggests to add is false :)

We were/are already working on replacing DB-based mechanisms with 
in-memory-based ones (e.g, DB locks->in memory locks was already done, managing 
VM statuses from the DB -> manage them with in-memory manager is something we 
plan to do).

Here, we put things into the DB and then query them. there is a caching layer, 
but we need it because we use the DB as bus of messages between threads and we 
want to have better performance.

I think that in general the information should not be persisted into the DB but 
to be passed as we did with the AutoStartVmsRunner job. We can dump relevant 
data into the DB when it could be useful on the engine startup (for example: 
when async commands starts, when command is rejected/not_started and should be 
re-triggered after the engine restarts, etc)

Doing that, we can consolidate the similar handling in invokeCallbackMethods 
and initCommandExecutor: in initCommandExecutor we'll just fetch from the DB 
the relevant data and put it in the in-memory one, and all the handling will be 
made only in invokeCallbackMethods (again, please look at AutoStartVmsRunner)

What do you think?
Line 99:                                 default:
Line 100:                                     addToCallBackMap(cmdEntity);
Line 101:                             }
Line 102:                         }


-- 
To view, visit http://gerrit.ovirt.org/29219
To unsubscribe, visit http://gerrit.ovirt.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I4d510836dc822a95198dc1db4a4f74206466f0c9
Gerrit-PatchSet: 2
Gerrit-Project: ovirt-engine
Gerrit-Branch: master
Gerrit-Owner: Ravi Nori <rn...@redhat.com>
Gerrit-Reviewer: Arik Hadas <aha...@redhat.com>
Gerrit-Reviewer: Michal Skrivanek <michal.skriva...@redhat.com>
Gerrit-Reviewer: Oved Ourfali <oourf...@redhat.com>
Gerrit-Reviewer: Ravi Nori <rn...@redhat.com>
Gerrit-Reviewer: Yair Zaslavsky <yzasl...@redhat.com>
Gerrit-Reviewer: automat...@ovirt.org
Gerrit-Reviewer: oVirt Jenkins CI Server
Gerrit-HasComments: Yes
_______________________________________________
Engine-patches mailing list
Engine-patches@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-patches

Reply via email to