We're updating the issue view to help you get more done. 

Roster Group Sharing Degraded

Description

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

 

Environment

None

Acceptance Test - Entry

None

Activity

Show:
Dele Olajide
October 30, 2019, 8:28 AM
Edited

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.

Dele Olajide
October 30, 2019, 9:20 AM
Edited

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.

Dele Olajide
October 30, 2019, 12:35 PM
Edited

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.

Guus der Kinderen
October 30, 2019, 1:06 PM

Thanks Dele. With your commit being rolled back, does Roster Versioning () still work?

Dele Olajide
October 30, 2019, 1:35 PM

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* 

Assignee

Dele Olajide

Reporter

speedy

Labels

None

Expected Effort

None

Fix versions

Affects versions

Priority

Major
Configure