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: Chris Hyzer <>
  • To: Hans Zandbelt <>
  • Cc: "" <>, "" <>
  • Subject: RE: [grouper-users] getGroups caching?
  • Date: Mon, 1 Mar 2010 14:04:20 -0500
  • Accept-language: en-US
  • Acceptlanguage: en-US

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"

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


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


//change the description
WsGroupToSave wsGroupToSave = new WsGroupToSave();
wsGroupToSave.setWsGroupLookup(new WsGroupLookup("aStem:aGroup", null));
WsGroup wsGroup = new WsGroup();
WsGroupSaveResults wsGroupSaveResults = new

//get groups for user again
wsGetGroupsResults = new


-----Original Message-----
From: Hans Zandbelt

Sent: Monday, March 01, 2010 1:05 PM
To: Chris Hyzer

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 and restarted tomcat, but the behaviour
did not change.

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



> 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


Archive powered by MHonArc 2.6.16.

Top of Page