[ https://issues.jboss.org/browse/ISPN-863?page=com.atlassian.jira.plugin.s... ] Manik Surtani commented on ISPN-863: ------------------------------------ This is pretty hard to do, in a manner that performs well. One option may be to force lazy deserialization - which stores entries in serialized, byte array form - which will make calculating footprint easier/faster. Still, deciding which entries to evict could be expensive. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-863?page=com.atlassian.jira.plugin.s... ] Dave Marion commented on ISPN-863: ---------------------------------- I read over JBCACHE-11, seemed to get complicated pretty quickly. I was thinking of a more coarse-grained approach that was not a per cache setting, but a global one. If used memory greater than some threshold (i.e. 85%), then start evicting entries from the caches according to the cache specified eviction strategy. Maybe a naive thought on my part, but probably an easier to implement first cut. The desired side-effect here is that I don't need to specify maxEntries; I can keep as many entries in the cache as possible. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-863?page=com.atlassian.jira.plugin.s... ] Dave Marion commented on ISPN-863: ---------------------------------- Initially, yes, I was thinking of the Runtime methods freeMemory and maxMemory. Chances are that garbage collection will be occurring the closer you are to reaching the defined (-Xmx) limit of the JVM. I think there a couple of ways to implement this. If 85% is the threshold, then stop evicting when memory usage drops below some other threshold (i.e. 80%). Or, I was just looking at the Java 6 API, and it appears that another option would be to use the MemoryPoolMXBean. You could receive notifications when the threshold has been exceeded and after garbage collection has occurred to see what the free memory is. There are some examples of notification and polling mechanisms. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-863?page=com.atlassian.jira.plugin.s... ] Dave Marion commented on ISPN-863: ---------------------------------- I will do that when I get home tonight from work. Thanks. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-863?page=com.atlassian.jira.plugin.s... ] Manik Surtani commented on ISPN-863: ------------------------------------ Yes, it would be one of those features that one would have to "use with care". It certainly won't be enabled by default, and an appropriate log message about the potential for other apps in the same VM leaking memory should be made clear. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-863?page=com.atlassian.jira.plugin.s... ] Mircea Markus commented on ISPN-863: ------------------------------------ @Dave @Galder if all the info is keept in binary format (useLazyDeserialization=true) then one can estimate how much heap is being used by the cache by summing up the size of all the cache entries stored (byte[]). This can then be multiplied with a coefficient: that is ISPN's internal structure for holding the data. This would allow one to configure ISPN as follows: in this JVM I only want ISPN to occupy 300Mb and leave the rest for the other applications. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-863?page=com.atlassian.jira.plugin.s... ] Mircea Markus commented on ISPN-863: ------------------------------------ @Manik Agreed. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-863?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño updated ISPN-863: ---------------------------------- Fix Version/s: 5.0.0.BETA2 (was: 5.0.0.BETA1) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-863?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño updated ISPN-863: ---------------------------------- Fix Version/s: 5.0.0.CR2 (was: 5.0.0.CR1) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-863?page=com.atlassian.jira.plugin.s... ] Manik Surtani updated ISPN-863: ------------------------------- Fix Version/s: 5.0.0.CR4 (was: 5.0.0.CR3) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-863?page=com.atlassian.jira.plugin.s... ] Manik Surtani updated ISPN-863: ------------------------------- JBoss Forum Reference: http://community.jboss.org/thread/160571?tstart=0 (was: http://community.jboss.org/thread/160571?tstart=0) @Dave - what's the status with this? Are you still working with Vladimir on contributing this patch? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-863?page=com.atlassian.jira.plugin.s... ] Manik Surtani updated ISPN-863: ------------------------------- Fix Version/s: 5.2.0.Final (was: 5.0.0.FINAL) Forum Reference: http://community.jboss.org/thread/160571?tstart=0 (was: http://community.jboss.org/thread/160571?tstart=0) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-863?page=com.atlassian.jira.plugin.s... ] Manik Surtani updated ISPN-863: ------------------------------- Assignee: Pete Muir (was: Dave Marion) Fix Version/s: 5.2.0.ALPHA1 Priority: Blocker (was: Major) Forum Reference: http://community.jboss.org/thread/160571?tstart=0 (was: http://community.jboss.org/thread/160571?tstart=0) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-863?page=com.atlassian.jira.plugin.s... ] Pete Muir reassigned ISPN-863: ------------------------------ Assignee: (was: Pete Muir) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-863?page=com.atlassian.jira.plugin.s... ] Robert Stupp commented on ISPN-863: ----------------------------------- I have got some experiences with memory (heap) based eviction. Eviction based on freeMemory()/totalMemory() is too simple - just because you might not be the only thing inside a JVM. And even if you evict the objects (no more references to the objects) the GC might not collect that garbage right when you "think" it does - this process is too complicated as it could be reflected into some simple and fast piece of code - just think about in which generation the evicted objects were (new gen is collected more often as eden space for example) and which types of GC you are currently using. The only solution I imagine is to specify some kind of "occupied heap" settings. There are two solutions that might work: * Estimate the size of an object (graph) by using reflection - expensive * Estimate the size of an object graph using serialization - expensive - but ISPN already performs serialization - it would be possible to remember the serialized size (if using Java serialization) * Estimate the size using Java's Instrumentation interface - not suitable but possible and not that expensive - but might cause conflicts when using profilers -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-863?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño updated ISPN-863: ---------------------------------- Fix Version/s: 5.2.0.Beta1 (was: 5.2.0.Alpha4) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-863?page=com.atlassian.jira.plugin.s... ] Mircea Markus commented on ISPN-863: ------------------------------------ [~snazy]re: 3, the instrumentation interface is expensive as well. Also in order not to count objects twice you'll have to check double references to the same objects, i.e. keep an object graph, i.e. costly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-863?page=com.atlassian.jira.plugin.s... ] Mircea Markus commented on ISPN-863: ------------------------------------ [~manik] doesn't seem like this will make it in the timeline of 5.2 os I've moved it to the next release. If you think it can make it please amend. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira