Uploaded image for project: 'Grouper'
  1. Grouper
  2. GRP-313

caching should be changed so we can read changed data

    XMLWordPrintable

Details

    • Improvement
    • Resolution: Unresolved
    • Minor
    • None
    • 1.4.2
    • None
    • None

    Description

      I was able to reproduce this, thanks for the grouperClient commands.

      There is caching in Grouper which will not update right away for changes like this.

      This particular cache I believe is in grouper.ehcache.xml:

      <cache name="edu.internet2.middleware.grouper.privs.CachingAccessResolver.HasPrivilege"
      maxElementsInMemory="500"
      eternal="false"
      timeToIdleSeconds="30"
      timeToLiveSeconds="120"
      overflowToDisk="false"
      />

      I think you will see after 2 minutes, the group will be updated. Right now, if you want values right away, you will need to change that 120 to something smaller.

      If there is a cluster of WS servers, then Im not sure how we can get around this. If you have one server, then we should be able to see where groups are being used in all caches, and update them (though this will not be trivial). Another option is a flag to the WS which says "don't read from cache". This would be for UIs and things where someone changed something and they want to see the changes... in this particular case, the "Group" object being cached I would think should be kept in a central place in memory so it is easy to change. Right now the objects are kind of chaotically sprinkled throughout the cache...

      From: Paul Gazda Paul.Gazda@nau.edu
      Sent: Monday, August 31, 2009 2:39 PM
      To: grouper-users@internet2.edu
      Subject: [grouper-users] Getting stale group attributes with getGrouperPrivilegesLiteWs

      When I retrieve all the groups a subject has admin privilege on using GrouperClient and getGrouperPrivilegesLiteWs, I am getting stale values for the attributes of the groups returned. The sequence below demonstrates how I changed the description of group ENT:pag-test from "desc 3" to "desc 4". When the group is queried using getGrouperPrivilegesLiteWs, the old value of "desc 3" is returned. When queried with findGroupsWs, the new value of "desc 4" is retrieved.

      Is there caching of group attributes happening with getGrouperPrivilegesLiteWs? I've tried to find something about this in this list's archives, but could not.

      (initial description value "desc 3")
      java -jar grouperClient.jar --operation=findGroupsWs --queryFilterType=FIND_BY_GROUP_NAME_EXACT --groupName=ENT:pag-test
      Index 0, name: ENT:pag-test, displayName: ENT:pag-test, extension: pag-test, displayExtension: pag-test, description: desc 3

      (change description to "desc 4")
      java -jar grouperClient.jar --operation=groupSaveWs --name=ENT:pag-test --description="desc 4"
      Success: T: code: SUCCESS_UPDATED: ENT:pag-test

      (retrieve with getGrouperPrivilegesLiteWs - shows old "desc 3" value)
      java -jar grouperClient.jar --operation=getGrouperPrivilegesLiteWs --privilegeType=access --privilegeName=admin --subjectId=testSubject
      Index 0, success: T, code: SUCCESS, group: ENT:pag-test, subject: testSubject, description: desc 3, access: admin

      (retrieve with findGroupsWs - shows new "desc 4" value)
      java -jar grouperClient.jar --operation=findGroupsWs --queryFilterType=FIND_BY_GROUP_NAME_EXACT --groupName=ENT:pag-test Index 0, name: ENT:pag-test, displayName: ENT:pag-test, extension: pag-test, displayExtension: pag-test, description: desc 4

      (retrieve again with getGrouperPrivilegesLiteWs - still shows old "desc 3" value)
      java -jar grouperClient.jar --operation=getGrouperPrivilegesLiteWs --privilegeType=access --privilegeName=admin --subjectId= testSubject
      Index 0, success: T, code: SUCCESS, group: ENT:pag-test, subject: testSubject, description: desc 3, access: admin

      Paul Gazda

      Attachments

        Activity

          People

            chris.hyzer@at.internet2.edu Chris Hyzer (upenn.edu)
            chris.hyzer@at.internet2.edu Chris Hyzer (upenn.edu)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated: