Wanted some feedback on this. https://gist.github.com/burtonator/34a67c24ca9ce0574c04
I think I want to refactor the cancel method… it calls purge() which is VERY expensive on large numbers of queues. N^2 expensive. once the cancel() is called, the timer task won’t get executed, HOWEVER there’s still a reference to the Runnable. This is why I think purge() is called. This allows GC to kick in and remove the runnable without waiting for the timer to fire. Which I think is just 30 seconds later but not sure. So I think the workaround here is to not to submit the Runnable itself but a WeakRunnable and then, once we read the TimerTask, we just set the reference to the underlying runnable to null. This will allow GC and we also don’t have to call purge(). Ps. There are some other things that should be cleaned up here. Probably removing synchronized and using ConcurrentHashMap and also probably ditching Timer and moving to Executors.. but that’s another project in and of itself and might introduce bugs for no win. Kevin -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile <https://plus.google.com/102718274791889610666/posts>
