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

Remove Pre-Built Views/View Pooling - Replace with Object Serialization/Caching

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.3
    • Component/s: User Interface
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Similar issues:
      KULRICE-7013Research the ability to have pre-built views or components
      KULRICE-5380remove Timestamp from immutable *Member objects and replace with DateTime
      KULRICE-4642Remove support for object remoting
      KULRICE-8268broker pool optimization (4067)
      KULRICE-6413Remove BusAdminService and ability to "update" pool settings from the "Thread Pool" user interface as it's functionality is currently problematic
      KULRICE-767Create a Global Replace/Remove Document
      KULRICE-2437Replace KEW Workgroup and WorkgroupService with calls to KIM IdentityManagementService
      KULRICE-14123Add init view caching ability
      KULRICE-9552Deprecate old business object classes and document replacements (if any)
      KULRICE-12918XA Connection Pool Does Not Wait For Connection
    • Rice Module:
      KRAD
    • KRAD Feature Area:
      Data Dictionary
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Include in Release Notes?:
      Yes

      Description

      View Pools are a mechanism to separate the processing of the next view (in ideal conditions) from the user's interactions, but the processing is still affecting the overall performance of the machine. It is just an asynchronous problem with respect to the user.

      Instead, at MSU we've removed view pooling and have switched to using object serialization. We've cached the output from writing the object (byte arrray), and re-use that byte array as part of the read operation to create the objects.

      By doing this, we've dropped the respective cpu utilization caused by spring as part of the view generation from 20% down to 4% (according to yourkit). The read operation to create the view objects takes about 35 ms (on a beefy machine). Which I believe is pretty much negligible from the user's perspective.

      I would imagine the memory utilization should decrease as well, since all of those pre-built views won't be sitting around waiting to be consumed.

      Attached is a patch that gives an example of how to accomplish this task. There's probably better homes for the implementation than what I've created.

        Issue Links

          Activity

          Hide
          Jeff Domeyer (Inactive) added a comment -

          Related Jiras:
          KULRICE-7944
          KULRICE-7013

          Show
          Jeff Domeyer (Inactive) added a comment - Related Jiras: KULRICE-7944 KULRICE-7013
          Hide
          Jeff Domeyer (Inactive) added a comment -

          Also, forgot to include the changes to org.kuali.rice.krad.datadictionary.DictionaryBeanBase.
          We changed that to implement serializable as well, so the object serialization actually works.

          Show
          Jeff Domeyer (Inactive) added a comment - Also, forgot to include the changes to org.kuali.rice.krad.datadictionary.DictionaryBeanBase. We changed that to implement serializable as well, so the object serialization actually works.
          Hide
          Jeff Domeyer (Inactive) added a comment -

          including dictionarybeanbase

          Show
          Jeff Domeyer (Inactive) added a comment - including dictionarybeanbase
          Hide
          Jeff Domeyer (Inactive) added a comment -

          This one does the same change for the getViewsForType method (which lookups use)

          Show
          Jeff Domeyer (Inactive) added a comment - This one does the same change for the getViewsForType method (which lookups use)
          Hide
          Jeff Domeyer (Inactive) added a comment -

          Changed the cached HashMap in the DataDictionaryCachingServiceImpl to a ConcurrentHashMap

          Show
          Jeff Domeyer (Inactive) added a comment - Changed the cached HashMap in the DataDictionaryCachingServiceImpl to a ConcurrentHashMap
          Hide
          Jerry Neal (Inactive) added a comment -

          Hi Jeff,

          I was comparing this to another solution a developer wrote that keep an instance of the view in memory and then used copied the view for new requests.

          When I put this into place, all the component were coming up readonly. Looking at the bean after it is reconstructed, everything looked fine exception the expression graph (which is a Map<String, String>) was not copied. I could not see any reason why it would not be. Did you run into anything like that?

          thanks,
          Jerry

          Show
          Jerry Neal (Inactive) added a comment - Hi Jeff, I was comparing this to another solution a developer wrote that keep an instance of the view in memory and then used copied the view for new requests. When I put this into place, all the component were coming up readonly. Looking at the bean after it is reconstructed, everything looked fine exception the expression graph (which is a Map<String, String>) was not copied. I could not see any reason why it would not be. Did you run into anything like that? thanks, Jerry
          Hide
          Jeff Domeyer (Inactive) added a comment -

          If I remember correctly, the cached object is just supposed to be an identical copy to what the bean definition is that spring returns. Isn't the expression graph populated after that step as part of the view lifecycle?

          Since the bean definitions were all prototypes, spring was constantly trying to rebuild the objects from scratch (since post-processing set instance specific values like expressions and we weren't sharing those values across all instances). So I figured the purpose of the spring configuration was to give a default set of initial values, which never changed unless the bean definition was changed. So the answer that spring returned was written to an array and stored for later conversion to an object when needed (Object Serialization).

          Show
          Jeff Domeyer (Inactive) added a comment - If I remember correctly, the cached object is just supposed to be an identical copy to what the bean definition is that spring returns. Isn't the expression graph populated after that step as part of the view lifecycle? Since the bean definitions were all prototypes, spring was constantly trying to rebuild the objects from scratch (since post-processing set instance specific values like expressions and we weren't sharing those values across all instances). So I figured the purpose of the spring configuration was to give a default set of initial values, which never changed unless the bean definition was changed. So the answer that spring returned was written to an array and stored for later conversion to an object when needed (Object Serialization).
          Hide
          Jerry Neal (Inactive) added a comment -

          Hi Jeff,

          The expression graph gets built through a bean post processor, so it should exist when we get the bean out of the factory (I verified this with previous behavior). Very strange, cause everything else looks good. I'll keep looking into it. Might have to go with the copy, which is probably about the same performance wise. Either way should be a good improvement.

          Thanks!
          Jerry

          Show
          Jerry Neal (Inactive) added a comment - Hi Jeff, The expression graph gets built through a bean post processor, so it should exist when we get the bean out of the factory (I verified this with previous behavior). Very strange, cause everything else looks good. I'll keep looking into it. Might have to go with the copy, which is probably about the same performance wise. Either way should be a good improvement. Thanks! Jerry

            People

            • Assignee:
              Jerry Neal (Inactive)
              Reporter:
              Jeff Domeyer (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Structure Helper Panel