Last week Luis announced the release of ColdBox 2.6.2. They've got a pretty impressive list of fixes and enhancements in this release. The reason I was excited to see it though is because a bug I found was fixed in it. It's kind of cool to have had an impact (small as it may be) on a community product.The bug in question is #639: "Cache: Threshold checks not looking at the max heap size but just the total, reporting less free percentage than it should". We ran into this a couple months ago while developing our new app using ColdBox. ColdBox cache will let you set a minimum percentage memory threshold so it will stop caching and throw an error when the percentage of free memory on the heap goes beneath your set threshold. 
[code]<!--ColdBox Cache Parameter: Free JVM Memory % Threshold (0=not used)-->
<Setting name="CacheFreeMemoryPercentageThreshold" value="10"/>
[/code]
The problem was that we would occasionally receive an out of memory error from ColdBox when it was trying cache stuff but the heap had plenty of free space on it. When I monitored the memory on our dev server I found the error would be thrown at times when the memory looked like the screen shot below. Let me stop for a moment and explain the three memory numbers Java gives us:
  • Max Memory - This is the maximum size the heap will be allowed to grow to.
  • Total Memory - This is the amount of memory currently allocated to the heap from the OS. Unless your JVM config settings use the same min and max heap settings, this value will start out low and grow as your application requests additional RAM from the OS.
  • Free Memory - This is the amount of allocated heap memory that is not in use. Subtracting this amount from the Total Memory will tell you the amount of your heap currently in use.
The max heap size on our dev box is 1 Gig. If you look at the screen shot you can see it shows a point in time where the OS had allocated our JVM 776 MB of RAM of which 761 MB was in use. (15 MB were free) It can be concluded that 98% of the allocated memory for CF is in use. (761/776) This would be a misleading number to use since CF has been instructed to take up to 1 Gig which means that really only about 74% of the maximum possible memory is in use. (761/1024) In the ColdBox Framework ver 2.6.1 in the cacheManage.cfc, the following line of code was being used to determined the percentage of free memory left: 
[code]<cfset jvmThreshold = ( (getJavaRuntime().getRuntime().freeMemory() / getJavaRuntime().getRuntime().totalMemory() ) * 100 )>
[/code]
However, to be fair (and avoid false out-of-memory errors) it should have used maxMemory() instead of totalMemory() like so: 
[code]<cfset jvmThreshold = ( (getJavaRuntime().getRuntime().freeMemory() / getJavaRuntime().getRuntime().maxMemory() ) * 100 )>
[/code]
This bug and many others have been fixed in the 2.6.2 release. We just installed 2.6.2 on our dev server tonight. If you haven't already, I would recommend trying it out. Remember though, any changes you had made to the framework should be evaluated and migrated as necessary to the new version. Out of the four changes I had made to 2.6.1 on my own, 3 of them had been changed already in 2.6.2. (Not all were bugs, most where just additional try catches and such.)