Hi there,
Now the issue JM-379 was postponed to 2.5.1, and seems that it’'s not going to be solved in a short time (though a lot of votes).
I have just tried some changes with the class RosterManager like this:
public Roster getRoster(String username) throws UserNotFoundException {
// Original code
if (rosterCache == null) {
rosterCache = CacheManager.getCache(“username2roster”);
}
if (rosterCache == null) {
throw new UserNotFoundException(“Could not load caches”);
}
// Build a new roster beforehand
Roster newRoster = new Roster(username);
if (newRoster == null) {
throw new UserNotFoundException(username);
}
Roster roster = (Roster) rosterCache.get(username);
// If there is no cached roster or it’'s changed, commit the new one.
// Probably the equal function has to be overrided.
if ((roster == null) || (!roster.equals(newRoster))) {
rosterCache.put(username, newRoster);
}
else newRoster = roster;
return newRoster;
}
/code
Of course this is not a performance-oriented solution, and I tend to leave the actual work done by re-organizing how a roster be calculated.
Meanwhile, may I point out that LDAP group looking up procedure also takes up huge amount of time when the sharing policy is changed through the admin console. Seems that every[/i] group’‘s every[/i] member had the roster recalculated, so practically many users may have their rosters rebuilt more than once. Can we reduce it to, to the least extent, rebuild everybody’'s roster once?