On Friday I was looking at the CollectionResourceWrapper code to diagnose a garbage-collection-CPU-exhaustion problem at a customer (ticket 1454). Inside it is a static HashMap (s_cache) that holds the previous value of every thresholdable resource. This HashMap grows without any items ever being removed, it only processes updates so it COULD be the source of a resource leak if you added and removed nodes that are doing data collection. The old stale resource values from deleted nodes would just accumulate in the HashMap without ever aging out.
I have not changed this behavior yet but I did make some improvements to the code (added synchronization blocks and missing static/final modifiers) and I fixed a bug in the counter rate calculations that has been in there since last summer (Alejandro and Craig Miskell did the work here to fix some other counter threshold problems). This commit was dc8f7e419384cb1b1ba610e548bf4426a6b43228 and I only did it in master since it didn't seem like a likely bug in the real world and I could not find any related JIRA issues that would have been caused by it. The static hashmap itself has been in there at least 2 years and we haven't had problems with it as far as I know but it seems dangerous and likely to cause problems for customers who are collecting a large number of unique resource values while adding and deleting nodes regularly. Do you think we should add an aging process to the thresholding cache? Or maybe add listeners that can detect when the data points are no longer going to be updated and remove them from the cache? Seth Leger The OpenNMS Group ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Please read the OpenNMS Mailing List FAQ: http://www.opennms.org/index.php/Mailing_List_FAQ opennms-devel mailing list To *unsubscribe* or change your subscription options, see the bottom of this page: https://lists.sourceforge.net/lists/listinfo/opennms-devel
