Openfire

Shouldn't clients be able to recognize roster changes when they are just pushed out to them as regular roster items. When several clients are connected with different resources on the same node aren't roster updates pushed out this way?

> Shouldn't clients be able to recognize roster changes when they are just pushed out to them as
> regular roster items. When several clients are connected with different resources on the same
> node aren't roster updates pushed out this way?

Yep, that's correct. It's not the actual pushing that's hard. It's figuring out when to do the pushing. Basically, we need to re-calculate someone's roster in order to figure out if there are changes, which is what the X hours calculations are about above.

What could be implemented is:

1. When the user logs in, you can send send the cached roster
2. Push a LoginRosterRebuildTask in a blocking priority queue
3. Have a scheduled thread pool executor which runs the pushed rebuild tasks with certain frequency as to not overload the db server
3.1. when a task runs, it rebuilds the roster and compares it with the cached roster
3.2. if changes were detected - push them to the user
3.3. push a RefreshRosterRebuildTask to the queue
4. When the user logs out, remove the corresponding RefreshRosterRebuildTask from the queue

We may bootstrap user*name*s from LDAP and store them in the DB (If we go for space-optimization we can just store username and status), as well as storing a group-user mapping and group sharing mapping, making 3 tables in total. We can then bump out rosters by (dynamic?) DB queries.

If we queue the roster recalculation schedule user by user, the connection setup delay can be an issue, so I'd prefer unified synchronization, by gathering all online users and get their rosters when time has come. Moreover, batch-processing grouped users can also speed up the process.

Seems I am getting past caching but if we just dynamically build up changes for the cached, it may cause hinderance...

I see this issue has the most votes of any open high priority (critical) issue in the Jira DB, and it has been there since 2005. Forgotten but not gone?Since the squeaky wheel sometimes gets the grease, I just want to say that the priority is accurate. Anyone integrated with LDAP would like to at least be able to push a button when LDAP properties change (users are added/changed/deleted, groups are added/changed/deleted). I personally don't require anything fancy. Even if it were an API call that would be fired by me to tell the server to please go refresh its list of users, groups, rosters, etc. My server is not busy with lots of messages, but I do need rosters to be correct. Anything short of restarting the server would be a huge improvement. Please advise if/when this issue will be addressed, thanks.

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.

Thanks
-S