+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) * Are there any issues when there are multiple management servers involved? * Any threading concerns? That is, multiple threads are attempting to update the VR, some are using the aggregated approach, some are not. * What is the default value of aggregated period? * What if the caller dies before calling completeAggregatedExecution * what is the queue mechanism? LinkedBlockingQueue? * Any impact on the agent thread pool size? Does this use its own thread pool? * Can we also address the case of restoring state to a VR when restarting the VR outside of CloudStack.
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
