Skip to Content.
Sympa Menu

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

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] getGroups caching?


Chronological Thread 
  • From: Hans Zandbelt <>
  • To: Chris Hyzer <>
  • Cc: "" <>, "" <>
  • Subject: Re: [grouper-users] getGroups caching?
  • Date: Mon, 01 Mar 2010 20:25:39 +0100

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



Archive powered by MHonArc 2.6.16.

Top of Page