> On Feb. 5, 2013, 1:15 p.m., Kishan Kavala wrote: > > usage/src/com/cloud/usage/UsageManagerImpl.java, line 557 > > <https://reviews.apache.org/r/8971/diff/2/?file=255149#file255149line557> > > > > This should be hostAggregatedStat.setAggBytesSent( > > userStat.getNetBytesSent() + userStat.getCurrentBytesSent()); > > > > Note that Agg = net + current > > Wei Zhou wrote: > From the logic of original source code, hostAggregatedStat is the > aggregated statistics which group by hostKey(DataCenterId-AccountId-DeviceId). > So I set agg=agg+net+current, not agg=net+current. > > Kishan Kavala wrote: > Agreed, this part looks fine. What about case below: > - daily aggregation was used for 1month and changed to 15min aggregation > for the 2nd month. > > Will this transition cause any issues?
I think no. The cloud-management and cloud-usage service have to be restarted after we change the configuration of usage.stats.job.aggregation.range or usage.stats.job.exec.time. Otherwise, the change will not be effective. After restarting services, the old threads(UsageManager, Heartbeat) are dropped, and new threads are created. It will be ok. Between the start time and next job execution time, the thread Heartbeat will handle the data in database periodically (every usage.stats.job.aggregation.range minutes). After that, the UsageManager will do it. - Wei ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8971/#review16109 ----------------------------------------------------------- On Feb. 4, 2013, 12:27 p.m., Wei Zhou wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/8971/ > ----------------------------------------------------------- > > (Updated Feb. 4, 2013, 12:27 p.m.) > > > Review request for cloudstack, Kishan Kavala and Rohit Yadav. > > > Description > ------- > > The usage sever does not handle data in the correct time. For example, it > regards the data traffic between 9:15-9:30 as the data traffic between > 9:30-9:45. > > If the interval is set to 1440(this means usge server calculate the data from > 0:00-23:59:59 at predefined time). The usage server regards the data traffic > between the server starting time(such as 13:00) to the next day(13:00) as the > data traffic between 0:00 an 23:59:59. > > Another problem is, when the usage.stats.job.aggregation.range is set to N( > for example, 15), the usage job handle the data every N+1 minutes( for > example 16). > > This is a patch for this issue (all details are described here: > https://issues.apache.org/jira/browse/CLOUDSTACK-962 ). > This patch depends on the patch for CLOUDSTACK-685 which is fixed in 4.0.1. > You can get from: > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=2f1d83037bd4bb1165b378d6c1dfc2815f696681 > > > This addresses bug CLOUDSTACK-962. > > > Diffs > ----- > > server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java > 943c85f > server/src/com/cloud/user/dao/UserStatisticsDao.java eb175ca > server/src/com/cloud/user/dao/UserStatisticsDaoImpl.java fd7795a > usage/src/com/cloud/usage/UsageManagerImpl.java 53ebb14 > > Diff: https://reviews.apache.org/r/8971/diff/ > > > Testing > ------- > > The patch is tested in CloudStack Virtual Router environment (Advanced > Networking, not Basic Networking). > > usage.stats.job.aggregation.range = 5, the usage server collects data every > 10 minutes (such as collect data traffic between 13:00:00-13:10:00 at > 13:10:00). > usage.stats.job.aggregation.range = 15, the usage server collects data every > 15 minutes (such as collect data traffic between 13:00:00-13:15:00 at > 13:15:00). > usage.stats.job.aggregation.range = 60, the usage server collects data every > hour (such as collect data traffic between 13:00:00-14:00:00 at 14:10). > usage.stats.job.aggregation.range = 1440, the usage server collects data > every day (such as collect data traffic between 0:00:00-23:59:59 at 0:30). > > > Thanks, > > Wei Zhou > >
