Grouper Users - Open Discussion List

[Hans Zandbelt <>]

Hi Chris,

Chris Hyzer wrote, On 3/1/10 8:04 PM:
> 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...

This seems to solve the immediate problem for us, although we would be
interested in updates on the caching implementation.

> 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.

Ok, thanks for your help!

Hans.

> 
> 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