Suggested as a way to reproduce larger sizes in the cache is a site that has more roles that normal. Would need to test that.

In relation to the changes made in SVN against this ticket:

I don't follow how using an inner class would use more memory compared to a normal class.

The only difference between a normal class and an inner class is that the inner class holds a reference to the containing class. In this case DbAuthzGroupService should be a singleton as it's a spring managed bean so there should only be one copy in the JVM shared by all the inner classes.

This was open so I'm going to resolve this as incomplete based on the comments.

I think there might be some more improvements to be made around this cache still but it doesn't appear to be that bad in local tests.

The 125000 is probably too high though for a typical server (what the default is set at for this right now where most other defaults are 10000)

So 10K for 1 user, 100K for 10 users, 1MB for 100 users, 10MB for 1000 users so 1GB (at least) for 100000 users. It looks pretty predicatable to me? Even if the 80K is true that's only
really bad at 100K entries, and I'm not seeing that locally unless this is caching some much larger set?

org.sakaiproject.authz.impl.DbAuthzGroupService.realmRoleGroupCache: count:7 hits:15 misses:19 hit%:44 heap:124856
org.sakaiproject.authz.impl.DbAuthzGroupService.realmRoleGroupCache: count:108 hits:1103 misses:120 hit%:90 heap:1321272
org.sakaiproject.authz.impl.DbAuthzGroupService.realmRoleGroupCache: count:510 hits:10694 misses:522 hit%:95 heap:5653696

I can't seem to reproduce this any more on trunk. I get over 1000 items in the cache by using a script to login with 500 users and the heap memory graphs don't seem to look any different than with this cache turned off. I know ehcache was upgraded, but even after 1000 items in the cache, it hasn't increased by that much. Unless there's some edge cases that significantly increase this?

Is UMich still working on this one?