WowAce

r183

I get this on all my chars at some point playing, the count is different. Highest was in the 500s i think.

AceTimer-3.0: Warning: The addon/module 'ZOMGSelfBuffs' has 349 live timers.  Surely that's not intended?

New record, just went upto 1852 in ZOMGBuffTehRaid module. I am not in a raid. I was soloing in strathholme at this point.

For me this started when i started to play my Mage, on my Warrior where i only have my Shout i didnt see it.

I just got 622 live timers in module 'ZOMGSelfBuffs' while running instances on my mage.

same here-longer you play on char count goes higher-my highest was about 1,5-2k

Not sure why this would happen. Each timer is always destroyed if a new replacement is needed.. Will get back to you on that...

The timer cancel code seemed correct when I looked at it, so I started digging around inside of AceTimer. I believe the issue is caused by CancelTimer simply marking a timer as removed, and it doesn't actually get cleaned up until the next tick (which may be several OnUpdate()s later). If timers get destroyed and re-created multiple times in a single frame it could cause issues with AceTimer not being able to reclaim them fast enough.

One idea I was thinking about trying out was to set a flag to prevent the rescheduling of certain timers (namely the GCD one) until the timer fires. That may not be appropriate for some of them, however, if the duration needs to be changed.

I noticed after farming a lot of baron instances, and getting timer messages over 1500, my wow started getting really laggy and jerky. I don't know if it was caused by this tough.

Definitely not fixed with the latest update. I just got the message again for 135 live timers.

Still happening in r186.

Maybe it is time for a complete overhaul and remake...time to "hit the drawing board" as they say and to start over.

"I believe the issue is caused by CancelTimer simply marking a timer as removed, and it doesn't actually get cleaned up until the next tick (which may be several OnUpdate()s later). If timers get destroyed and re-created multiple times in a single frame it could cause issues with AceTimer not being able to reclaim them fast enough."

Well, since Ace3 went to release from beta years ago, this mod is the very first one I've tested that has brought up this warning. Including many others that include extensive timing capabilities. It could be that you actually are producing too many registered timers at any set point and time instead of it being that AceTimer is not recognizing the destruction/recreation of them fast enough.

As per the Dec. 30, 2007 changelog of AceTimer-3.0 by mikk (r428): "- We now output a warning if an addon/module is seen to have "lots of timers" registered (currently defined as ==BUCKETS, 131). This problem has been seen in enough addons to justify the warning, imnsho. It's also damn cheap to do inside the cleaner." And a code comment from the current AceTimer-3.0 release r895 (from a year ago): "CAUTION: The BUCKETS constant constrains how many timers can be efficiently handled. With too many hash collisions, performance will decrease."

If this was common behavior in the majority of mods I've tested in the past two years, would be willing to give the "incorrect marking" theory some backup. But its not. As mentioned, this is the first mod I've seen produce this warning message that I can remember.

So hopefully a proper fix can be found.

Still unable to reproduce this on either my shaman or my priest, even when chain dungeon running. :(

Just got this error for the first time on a level 4 Paladin - has only 1 buff to track (Seal of Righteousness).

"AceTimer-3.0: Warning: The addon/module 'ZOMGBuffTehRaid' has 186 live timers. Surely that's not intended?"

Tracking this down somewhat. Looks like it's a bit of a misleading error from AceTimer. The way it works is with extensive use of reusable objects for the timers. And although the timer heap for ZOMG is as big as it says, they're all discarded and inactive timers (timer.callback == nil). I'm doing some work to cut down on how many are created. And might just do away with AceTimer altogether..

Have opened a ticket about it on the Ace3 area. Waiting on a response. It might well be that AceTimer-3 was never designed to cope with deleting a lot of timers and re-using them so frequently.

I hope you guys are able to do something about this. If you google, you can see other addons had similar errors in 2009 (aloft, elitist group, inline aura, etc) and were able to address it somehow.

Yeh. I wouldn't actually worry about it though. The message is a bit misleading and wrong in so far as they're not live timers. Just one is. It's counting them before it does an internal tidy-up from what I can tell. But I do know 100% that they're all discarded correctly. AceTimer is not checking if the timer still has a .callback field when it counts them up.

An update to the Ace3 ticket 205 that Zeksie filed about this problem two weeks ago. There have been responses in the past two days from mikk & Nevcairiel.

I just got a timer-related error that I haven't seen yet:

1x AceTimer-3.0: CancelTimer(handle[, silent]): 'table: 35773478' - no such timer registered:
ZOMGBuffs--16612\ZOMGBuffs.lua:3949: in function `?'
CallbackHandler-1.0-6 (Ace3):147: in function <...Ons\Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:147>
<string>:"safecall Dispatcher[1]":4: in function <[string "safecall Dispatcher[1]"]:4>
<in C code>: ?
<string>:"safecall Dispatcher[1]":13: in function `?'
CallbackHandler-1.0-6 (Ace3):92: in function `Fire'
AceEvent-3.0-3 (Ace3):120: in function <Ace3\AceEvent-3.0\AceEvent-3.0.lua:119>

  ---

Some text from the pointer to the Ace3 dev response I mentioned below for those who haven't been there yet.

mikk (referring to timers that are not live): "...they in fact still live in the hash buckets, and there's no fast way of getting them out of there until the next time the timer code processes that bucket.

&

"A REschedule facility was indeed considered but in reality it ends up being a wrapper for cancel+schedule since there are no shortcuts that you can take. AceTimer was written to be maximally fast when scheduling already."

Nevcairiel: "If you create and cancel that many timers, you should probably re-think your design.. An idea that was mentioned by someone else below.

As a comparison, a mod using Ace3 (& AceTimer-3.0) which does essentially the same things this one does, but doesn't seem to have a problem with AceTimer: BuffBroker.

Back in the Ace2 days, ZOMGBuffs was far & away the most reliable, best designed mod of this type. Would be nice to see it return to that.

Some text from the pointer to the Ace3 dev response I mentioned below for those who haven't been there yet.

mikk (referring to timers that are not live): "...they in fact still live in the hash buckets, and there's no fast way of getting them out of there until the next time the timer code processes that bucket.

&

"A REschedule facility was indeed considered but in reality it ends up being a wrapper for cancel+schedule since there are no shortcuts that you can take. AceTimer was written to be maximally fast when scheduling already."

Nevcairiel: "If you create and cancel that many timers, you should probably re-think your design". An idea that was mentioned by someone else below.

As a comparison, a mod using Ace3 (& AceTimer-3.0) which does essentially the same things this one does, but doesn't seem to have a problem with AceTimer: BuffBroker.

Not using ZOMGBuffs currently due to this problem. Back in the Ace2 days, it was far & away the most reliable, best designed mod of this type. Would be nice to see it return to that.

Some text from the pointer to the Ace3 dev response I mentioned below for those who haven't been there yet.

mikk (referring to timers that are not live): "...they in fact still live in the hash buckets, and there's no fast way of getting them out of there until the next time the timer code processes that bucket.

&

"A REschedule facility was indeed considered but in reality it ends up being a wrapper for cancel+schedule since there are no shortcuts that you can take. AceTimer was written to be maximally fast when scheduling already."

Nevcairiel: "If you create and cancel that many timers, you should probably re-think your design". An idea that was mentioned by someone else below.

As a comparison, a mod using Ace3 (& AceTimer-3.0) which does essentially the same things this one does, but doesn't seem to have a problem with AceTimer: BuffBroker.

Not using ZOMGBuffs currently due to this problem which has yet to be completely fixed. Back in the Ace2 days, it was far & away the most reliable, best designed mod of this type. Would be nice to see it return to that.

Does this still happen? I don't remember the last time I've seen one of these messages.