Change caching strategy for shared groups


Many users are complaining that changes to LDAP groups are not being reflected in rosters quickly enough. There are two layers to this:

The roster code retrieves group information by calling GroupManagergetGroups(User). At the moment, there is no caching in this method although it should be added. The entire roster is then cached, included shared group information.

Because of the roster caching logic in place, it makes it very frustrating for people to see group changes take effect. First, because they'll only see changes when logging out and then back in. Second, because the roster is cached, it can take 6 hours to see changes. People generally resort to just shutting down the server.

The first step could be to change how roster caching works. I'd like to see if we could cache the db roster data but then dynamically build out the shared roster information. I'm not sure how expensive the shared roster group calculations are, which would dictate the feasability of this. Assuming it's not too expensive, if the shared group data was dynamic, then it would be GroupManager.getGroups(User) caching that would dictate how quickly changes in the back-end groups were reflected in rosters.

Second, we should try to figure out if it's possible to push roster changes to a user. An idea: have a flag in the roster code that says whether to check for roster changes on a periodic basis. Any time an external group system is used, the flag would get set by that provider. So, every X hours that a user is logged in, recalculate the shared group portion of their roster. If it's changed, send those changes to them dynamically. This would mean that if someone changes a group in LDAP, after X hours everyone from that group that continues to be logged in will see that change.




September 26, 2008, 4:27 AM

To answer Brians question about not having to restart the server, there is a work around. You can force a refresh of the cache in question by using the "Cache Summary" page in "Server Manager". Check the box for the "Roster" cache and flush it. Unfortunately it does not update clients that are already logged on, but next time they logout and back in, the new users will appear in their roster. Without having to restart the server. (wonder if I can script this from the command line somehow??? any ideas??)

Even with this workaround, I too would like to see a real time, or near real time, update happen with LDAP Group additions/deletions. Our LDAP directory is on the small side so I'm not too concerned with occasional refreshes. Maybe the timing of the automatic refresh could be Admin configurable. That way some admins could schedule a refresh overnight if needed and other could go more frequently.

Big bonus points for pushing any changes out to existing logged in accounts.


James Braid
July 9, 2012, 10:12 PM

Are there any updates on this issue? Is it actively being worked on?

Tom Evans
January 2, 2013, 8:20 PM

FYI - Some of the concerns noted here are group caching issues that are similar to those reported as OF-278. We are working on improving the Groups implementation, although some of the roster management concerns will have to be handled separately. Feedback is welcome from anyone following this ticket.

Daryl Herzmann
February 13, 2014, 9:54 PM

Is this issue still happening on a current release (3.9.1)?

Daryl Herzmann
October 30, 2015, 11:42 PM

Assigning to Tom to see what his current thoughts are on this matter.






Expected Effort


Ignite Forum URL



Affects versions