Grouper Users - Open Discussion List

[Chris Hyzer <>]

I was able to reproduce the problem with the grouper client code below.  If I 
change to this in grouper.ehcache.xml it fixes the problem:

  <cache  name="edu.internet2.middleware.grouper.Membership.getGroup"
          maxElementsInMemory="1000"
          eternal="false"
          timeToIdleSeconds="-1"
          timeToLiveSeconds="-1"
          overflowToDisk="false"
  />

If this is a high priority problem and you don't want to set the cache to -1, 
I can clear the cache on group updates.  However, if this doesn't fix the 
whole problem, and want to wait for a better caching strategy, that is fine 
too.  We should bump that up in priority...

BTW the query cache is for querying.  In this case the code retrieves the 
memberships via query, then based on groupIds gets the groups via this cache. 
 So as you found, turning off the query cache wont solve it in this specific 
case.

Thanks!
Chris


    // make sure group exists
    GrouperSession grouperSession = GrouperSession.startRootSession();
    Group group = Group.saveGroup(grouperSession, "aStem:aGroup", null,
        "aStem:aGroup", "aGroup", "description1", null, true);

    String wsUserLabel = GrouperClientUtils.propertiesValue(
        "grouperClient.webService.user.label", true);
    String wsUserString = GrouperClientUtils.propertiesValue(
        "grouperClient.webService." + wsUserLabel, true);
    Subject wsUser = SubjectFinder.findByIdOrIdentifier(wsUserString, true);

    group.grantPriv(wsUser, AccessPrivilege.READ, false);
    group.grantPriv(wsUser, AccessPrivilege.VIEW, false);

    // add a subject
    group.addMember(SubjectTestHelper.SUBJ0, false);

    WsGetGroupsResults wsGetGroupsResults = new 
GcGetGroups().addSubjectId(SubjectTestHelper.SUBJ0_ID).execute();

    assertEquals("description1", 
wsGetGroupsResults.getResults()[0].getWsGroups()[0].getDescription());
    
    //change the description
    WsGroupToSave wsGroupToSave = new WsGroupToSave();
    wsGroupToSave.setWsGroupLookup(new WsGroupLookup("aStem:aGroup", null));
    WsGroup wsGroup = new WsGroup();
    wsGroup.setDescription("description2");
    wsGroup.setName("aStem:aGroup");
    wsGroup.setDisplayExtension("aGroup");
    wsGroupToSave.setWsGroup(wsGroup);
    WsGroupSaveResults wsGroupSaveResults = new 
GcGroupSave().addGroupToSave(wsGroupToSave).execute();
    assertEquals("description2", 
wsGroupSaveResults.getResults()[0].getWsGroup().getDescription());
    
    //get groups for user again
    wsGetGroupsResults = new 
GcGetGroups().addSubjectId(SubjectTestHelper.SUBJ0_ID).execute();

    assertEquals("description2", 
wsGetGroupsResults.getResults()[0].getWsGroups()[0].getDescription());
    

-----Original Message-----
From: Hans Zandbelt 
[mailto:]
 
Sent: Monday, March 01, 2010 1:05 PM
To: Chris Hyzer
Cc: 
;
 

Subject: Re: [grouper-users] getGroups caching?

Hi Chris,

Chris Hyzer wrote, On 3/1/10 7:00 PM:
> Unfortunately yes, it is the expected behavior, though, if you let me know 
> the version of Grouper and more details about the calls you are making, we 
> could discuss clearing relevant caches if group updates occur...  if you 
> are connecting to the same web services server, it will work with your use 
> case.  If you do load balancing, and hit a different server in a cluster, 
> then it wont work until we redo how caching works.

I was just asking because the issue also occurs for _new_ groups (see
original mail). I would expect a cache miss for new groups...

We run grouper 1.5.0; no load-balancing involved.

I have set

  hibernate.cache.use_query_cache = false

in grouper.hibernate.properties and restarted tomcat, but the behaviour
did not change.

I guess the other suggestions regarding ehcache won't help then, right?

Regards,

Hans.

> 
> Thanks!
> Chris
> 
> -----Original Message-----
> From: Hans Zandbelt 
> [mailto:]
>  
> Sent: Monday, March 01, 2010 11:55 AM
> To: Chris Hyzer
> Cc: 
> ;
>  
> 
> Subject: Re: [grouper-users] getGroups caching?
> 
> Hi Chris,
> 
> Chris Hyzer wrote, On 3/1/10 2:57 PM:
>> Not sure if that will work or not, if not, then the cache settings are in 
>> ehcache.xml and grouper.ehcache.xml, might only need to change the 
>> defaults, though might need to tweak others in the file.  If you want, I 
>> can try to reproduce it and see exactly what works.
> 
> We will try tweaking the (3) options that you suggested and report back
> on this list.
> 
> Just to be sure: this is expected behaviour under the current caching
> implementation, right?
> 
> Thanks,
> 
> Hans.
> 
> BTW: we use the Grouper 1.5.0 release
> 
>> Thanks,
>> Chris
>>
>> -----Original Message-----
>> From: Hans Zandbelt 
>> [mailto:]
>>  
>> Sent: Monday, March 01, 2010 4:37 AM
>> To: 
>> 
>> Cc: 
>> 
>> Subject: [grouper-users] getGroups caching?
>>
>> Hi,
>>
>> We currently experience an issue when updating group information:
>>
>> when updating the description of an existing group using groupSave, this
>> call returns OK and shows in the response information that the
>> description was indeed updated to the new value.
>>
>> However, a subsequent call to getGroups still returns the old
>> description for that specific group. Only after some delay (half a
>> minute or so), the getGroups call returns the correct information.
>>
>> (BTW: this issue also shows when creating groups: the description does
>> not even exist at first in the getGroups results, only after some delay)
>>
>> It looks like group information for getGroups is cached, at least for
>> the "description" part; is this assumption true, and if so, can we
>> modify this behaviour?
>>
>> Regards,
>>
>> Hans.
>>
> 
> 


-- 
Hans Zandbelt                    

SURFnet                             http://www.surfnet.nl