Is there a reason for limiting the number of active timers in the agent to 20 ? I’m constantly running against that limit so if at all possible, would be good to relax that a bit. I can understand that the device is limiting it for memory reasons, but shouldn’t be an issue on the agent side ?
The limitations of timers is one of the very few implementation weaknesses in the agents.
For the reason you state and others, I wrote a timer layer for the agent a few months ago. It allowed me to consolidate multiple timers so that they only used a single resource. It also allows me to tag them so I can filter them out if the instance that they depend on is killed or deleted. Additionally, there’s no way of telling how close you are to the 20 timer limit, until you hit it.
20 was picked quite arbitrarily, but it seems a sensible number in that if you’re needing more than that, maybe you need a better way to manage them too (as coverdriven found!)
Sure, i will have to manage them in the current generation with an abstraction layer, i’m doing that already to schedule known future events. There’s over 50 of them… But i typically use timers too for code threads that need a short unexpected delay. Once in a while they all come together (on top of the already used timers for schedulers, event listeners, timeout checkers,…) and i hit the limit.
So, the question really was, is there a way to increase the 20 for future releases so this happens less frequent ? The imp.wakeup mechanism is great in it’s ability to set and forget without a lot of hassle around it. Having to make it more complex just to avoid hitting an arbitrary limit isn’t really the answer long term IMHO 
Would a supported library for timer management help here?