Brock - by changing the DAILY_SECS to 30 you are now triggering a check for updates every 30 secs that calls img_obj.inventory and is cpu intensive, which is not what we'd want I think.
I would put the DAILY_SECS back to 24*60*60, but leave the rest of the webrev as is. JR Brock Pytlik wrote: > New webrev: > http://cr.opensolaris.org/~bpytlik/ips-5171-v2/ > > jmr wrote: >> J - isn't the problem that self.time_until_next_check can be negative >> in is_check_required() if the machine has been off for a few days and >> then gets turned back on. The correct solution would seem to be to >> set the self.time_until_next_check = self.refresh_period once you >> know a check is needed. >> >> def is_check_required(self): >> : >> if self.time_until_next_check <= 0: >> self.time_until_next_check = self.refresh_period >> return True >> else: >> return False >> >> The call in: >> >> def do_next_check(self): >> : >> if self.time_until_next_check > DAILY_SECS: >> next_check_time = DAILY_SECS >> >> Is ok if the refresh period is > a day and you have the period set to >> weekly and the machine is up for more than a day then this ensures >> the is_check_required() gets fired everyday the machine is up. >> >> JR >> >> >> This should be fine as [EMAIL PROTECTED] wrote: >>> Negative time doesn't make sense. If next_check_time is <= 0, isn't it >>> time to check right now? >>> >>> If the time_until_next_check is < refresh_period, I think we should >>> simply perform the check and then set next_check to now + >>> refresh_period. I think that would make this a little easier to >>> follow. >>> >>> -j >>> >>> >>> On Mon, Nov 17, 2008 at 06:01:14PM -0800, Brock Pytlik wrote: >>> >>>> Ok, then since we've observed time can be negative, that's the >>>> right delay in this situation? Would replacing 0 with 10 make >>>> everyone happy? >>>> >>>> Brock >>>> >>>> jmr wrote: >>>> >>>>> Brock if we ever hit next_check_time < 0 and set next_check_time >>>>> = 0: >>>>> >>>>> 333 + if next_check_time < 0: >>>>> 334 + next_check_time = 0 >>>>> >>>>> Then you will go into a spin in the call to: >>>>> 337 + gobject.timeout_add(0, self.do_next_check) >>>>> >>>>> This is what was happening in the bug we tracked down last week. >>>>> >>>>> JR >>>>> >>>>> Brock Pytlik wrote: >>>>> >>>>>> Webrev: >>>>>> http://cr.opensolaris.org/~bpytlik/ips-5171-v1/ >>>>>> >>>>>> Bug: >>>>>> http://defect.opensolaris.org/bz/show_bug.cgi?id=5171 >>>>>> Updatemanager eating 50% of the CPU >>>>>> >>>>>> This changes so that the next check to check for updates isn't >>>>>> scheduled until after the current check for updates happens. >>>>>> >>>>>> Brock >>>>>> _______________________________________________ >>>>>> pkg-discuss mailing list >>>>>> [email protected] >>>>>> http://mail.opensolaris.org/mailman/listinfo/pkg-discuss >>>>>> >>>> _______________________________________________ >>>> pkg-discuss mailing list >>>> [email protected] >>>> http://mail.opensolaris.org/mailman/listinfo/pkg-discuss >>>> >> > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
