659f373ad1bb096582e95df2f24ab4bdaae101f7 — Stephen Paul Weber 1 year, 8 months ago 664b2f5
Don't churn IO on persisting roster

Especially during start up, syncRoster can get called a *lot*.  We already avoid
doing them in parallel, but they can happen one right after the other, locking
up the DB and churning IO.

Now, after we persist the roster, wait for 500ms before giving the next persist
a chance to run.  That way, other stuff has 500ms to get work done and we lose
very little DB consistency in the case of a failure.
1 files changed, 5 insertions(+), 2 deletions(-)

M src/main/java/eu/siacs/conversations/services/XmppConnectionService.java
M src/main/java/eu/siacs/conversations/services/XmppConnectionService.java => src/main/java/eu/siacs/conversations/services/XmppConnectionService.java +5 -2
@@ 2041,8 2041,11 @@ public class XmppConnectionService extends Service {

    public void syncRoster(final Account account) {
        mRosterSyncTaskManager.execute(account, () -> databaseBackend.writeRoster(account.getRoster()));
        mRosterSyncTaskManager.execute(account, () -> {
            try { Thread.sleep(500); } catch (InterruptedException e) { }

    public List<Conversation> getConversations() {