When sharing large roster groups with all members, performance is degraded.
4.0 branch was used a the baseline. Sharing was very fast
4.1 introduce some delays, but minimal
4.2 branch it took minutes to complete
4.3 branch it takes tens of minutes.
4.4 branch remains unchanged and takes tens of minutes
Another issue identified, (even with version 4.0.0 code) is that the enabling/disabling of roster sharing runs much faster than 4.4.x code only when there are no logged in users. As soon as one or more users are logged in, the process blocks until the client has processed all the broadcast-ed roster update stanzas.
I suspect a background thread may be needed.
I have made the roster updating run in an asynchronous ExecutorService thread and that makes a difference. The admin web page is no more blocking and the roster update broadcast runs happily in the background. A new benefit is that the roster broadcast can be interrupted by a new counter action.
For example, enable a shared roster group and then disable after a few seconds will cause Spark to start adding the new contacts and then immediately proceed to remove them. Previously, this was not possible as the the process was blocked and disabling could not happen until all contacts were added to the shared roster.
I have traced back to the issue and commit (https://github.com/igniterealtime/Openfire/commit/fa6beb91495fbd720f179a9f022d1e68def9f46f#diff-0e66a0b9337e0e1dbe65be0eb9114799) that introduced the use of getRoster to replace the original code accessing the cache directly. For more details, see the GitHub discussion
It all started as an implementation of roster versioning in issue OF-210, but other things were added like the use of getRoster to replace accessing the roster cache directly.
Thanks Dele. With your commit being rolled back, does Roster Versioning () still work?
As far as I can tell, it should still work. The changes are explained above are specific code reverts for the roster cache handling and wrong use of the *UserNotFoundException*