Thanks for the comment! On Fri, Feb 7, 2014 at 3:25 PM, Chiradeep Vittal < chiradeep.vit...@citrix.com> wrote:
> +1. > * The guideline is not clear as to when a developer should use this > executor. Why not use it all the time (even for a single command) > The mechanism behind is NOT a "producer-consumer" model. It's just a queue(or a list) to delay the commands execution for now. Only the code would generated a large number of commands would need to use this, and basically that's the VR reboot/re-create at this time. > * Are there any issues when there are multiple management servers involved? > It would remain the same as before. One VR(host) would only operated by one mgmt server, the other one would reroute all the related commands to the mgmt server in charge. And as soon as aggregated execution started, it would block all the commands at least in VR level(also in the host queue if network.element.sequence.execution is true). > * Any threading concerns? That is, multiple threads are attempting to > update the VR, some are using the aggregated approach, some are not. > It is not a multithread solution in my mind. One queue for one VR, and would be created only "prepare" func called. All the following commands, no matter from which thread, would goes to this queue(by hooking sendCommandsToRouter in VR), wait until "complete" func called(which is expected quite soon). > * What is the default value of aggregated period? > No default, commands would wait until "complete" func called. > * What if the caller dies before calling completeAggregatedExecution > As noted in the spec, exception handler should call abortAggregatedExecution(). As design for VR booting up period, one failure would means VR fail to boot up. And, before commands send to VR, all the exception should be handled by mgmt server. I don't think there are any factor we cannot control would impact the command generation. But nonetheless, abortAggregatedExecution() is provided to clean up the queue and fail the execution. > * what is the queue mechanism? LinkedBlockingQueue? > Since it's not async, any ordered queue should be fine. Probably I should call it ArrayList... > * Any impact on the agent thread pool size? Does this use its own thread > pool? > No thread pool. > * > Can we also address the case of restoring state to a VR when restarting > the VR outside of CloudStack. > No. That's not in the scope. I was willing to take a more radical approach for this work, but practically I would want to solve the 80% problem this time(which is VR booting/upgrading time). --Sheng > > On 2/6/14 5:03 PM, "Sheng Yang" <sh...@yasker.org> wrote: > > >Hi Devs, > > > >Here I'd like to introduce this improvement of VR. > > > >https://issues.apache.org/jira/browse/CLOUDSTACK-6047 > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Virtual+Router+aggr > >egated+command+execution > > > >In short, we would speed up VR's rebooting and re-creating, by aggregated > >execution the CloudStack configuration commands when booting up. Hopefully > >we can get it done in O(1) rather than O(n)(which is current state). > > > >And to prepare for this work, I've get a long expected code refactor done. > >Now one VirtualRoutingResources would take over all the VR execution > >commands(rather than every hypervisor's resource). From now on, you would > >only need to modify one place in order to update VR commands. > > > >I've put some details of VR aggregated execution in the FS. > > > >Comments are welcome! > > > >--Sheng > >
