Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-6436

Tune ehcache configuration for the various rice modules

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0.0-rc1, 2.0
    • Component/s: Configuration
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Similar issues:
      KULRICE-5966update ehcache configurations to set cache's to expire
      KULRICE-9537Document the approach for conversion to krad-data of the various internal Rice modules
      KULRICE-6265Add documentation to the KSB Technical Guide on Performance Tuning
      KULRICE-3075Fix various pieces of missing KIM configuration and data
      KULRICE-8503Allow EhCache entries to be created on the fly
      KULRICE-1444Develop and document a service naming standard for Rice modules
      KULRICE-8298Add ehCache caching setup to KRAD
      KULRICE-6105JVM Tuning parameters
      KULRICE-11373Module configurer changes required to have both the module spring MVC and the module services in the same context
      KULRICE-6338Various issues getting KIM LDAP module to work properly
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      We should read the documentation on this subject, taking a quick look through our existing ehcache configuration files I'm not sure I understand how the settings there were chosen. For example we have updateCheck="true" everywhere which means that the ehcache company will be able to get feedback information about our caches and whatnot (presumably making calls back into their server) as well as making periodic calls to the server to see if a newer version of the software is available. Which brings up another point, as part of this we should look at upgrading to ehcache 2.5.0 (which appears to be an impactful change from the perspective of configuration).

      Also, the various caches in KIM were fairly tuned with various settings. We need to re-examine how we have all of our cache stuff setup.

      Also, we need to document the process that someone would use to customize the various rice caches during implementation.

        Activity

        Hide
        Jeremy Hanson added a comment -

        I've been working with the cache today, trying to get ehcache 2.5 working. I have it working (just adding some config stuff to the ehcache files, but I've run into a problem with the mac os x virtual machine. I don't think it is a big deal, but it looks bad in the logs

        http://www.codespot.net/blog/2012/01/measuring-java-object-sizes/

        In the logs I get a full thread dump, then the following messages.
        2012-01-05 12:38:36,765 [Thread-3] u:/d: INFO net.sf.ehcache.pool.sizeof.AgentLoader - Failed to attach to VM and load the agent: class java.lang.reflect.InvocationTargetException: null
        2012-01-05 12:38:36,777 [Thread-3] u:/d: INFO net.sf.ehcache.pool.sizeof.JvmInformation - Detected JVM data model settings of: 64-Bit HotSpot JVM with Compressed OOPs and Concurrent Mark-and-Sweep GC
        2012-01-05 12:38:36,777 [Thread-3] u:/d: INFO net.sf.ehcache.pool.impl.DefaultSizeOfEngine - using Unsafe sizeof engine

        sounds like it is mainly an odd issue with the mac os jvm, and after it fails the AgentLoader reverts to other workable solutions.

        Also, I'd like to discuss trying to figure out the best heap size limits to set for ehcache. We can either use the heap size limits or an entries limit.

        Show
        Jeremy Hanson added a comment - I've been working with the cache today, trying to get ehcache 2.5 working. I have it working (just adding some config stuff to the ehcache files, but I've run into a problem with the mac os x virtual machine. I don't think it is a big deal, but it looks bad in the logs http://www.codespot.net/blog/2012/01/measuring-java-object-sizes/ In the logs I get a full thread dump, then the following messages. 2012-01-05 12:38:36,765 [Thread-3] u:/d: INFO net.sf.ehcache.pool.sizeof.AgentLoader - Failed to attach to VM and load the agent: class java.lang.reflect.InvocationTargetException: null 2012-01-05 12:38:36,777 [Thread-3] u:/d: INFO net.sf.ehcache.pool.sizeof.JvmInformation - Detected JVM data model settings of: 64-Bit HotSpot JVM with Compressed OOPs and Concurrent Mark-and-Sweep GC 2012-01-05 12:38:36,777 [Thread-3] u:/d: INFO net.sf.ehcache.pool.impl.DefaultSizeOfEngine - using Unsafe sizeof engine sounds like it is mainly an odd issue with the mac os jvm, and after it fails the AgentLoader reverts to other workable solutions. Also, I'd like to discuss trying to figure out the best heap size limits to set for ehcache. We can either use the heap size limits or an entries limit.
        Hide
        Jessica Coltrin (Inactive) added a comment -

        Closing since these items are now in the release notes.

        Show
        Jessica Coltrin (Inactive) added a comment - Closing since these items are now in the release notes.

          People

          • Assignee:
            Jeremy Hanson
            Reporter:
            Eric Westfall
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Structure Helper Panel