Zombie users in groups

Help / Discuss
1

I have just noticed that the number of users in our XWikiAllGroup (6246) differs from the total list of objects in XWikiAllUserGroup (6319) with 73 entries. After some research, I see that the group itself still contains the objects of a lot of previously deleted members. Hence the discrepancy. Now the question: is this a problem that I need to take care of?

I assume that the members are linked to the group via the documents name. So that actually means with the name of the user as this way oidc creates the users profile. In other words: if we had an admin named ā€˜Jane Doeā€™ for a short time, but she left the company (and we deleted the user) and a new person with the name ā€˜Jane Doeā€™ arrives a little later, this person is immediately an admin.

Am I right?
Simpel

1 Like
2

While we use xwiki (~3 years) I think I deleted about 2.000 users. So in general I think deleting a user will remove itā€™s object from groups too.

How is the deleting process working? Can I as the deleter behave in a way interrupting those process?

3

Hm, we have an issue. Today I deleted 37 accounts. 36 stayed as zombies and were not removed from the XWikiAllGroup. This time I had all tabs opended until the job really showed ā€œdoneā€. (For an unknown reason this takes a long time.) I think I deleted these accounts one by one (including opening the account page in a single tab) with about 10 seconds delay between. (And the job done every time took longer than 10 seconds.)

What is your experience deleting accounts: how long will it take until the job is ā€œdoneā€? (Have in mind that we have about 6.500 users in the XWikiAllGroup.)

4

Which version of XWiki are you using ? The speed to modify very big groups was improved recently by XWIKI-22613, XWIKI-22573 and XWIKI-22782 (so basically need XWiki 17.1+ to have them all, or 16.10.4+ with the workaround configuration explained in XWIKI-22613).

5

Itā€™s a pity that we are currently using XWiki 15.10.13. I try to push updating to Intermediate Long Term Support.

6

XWIKI-22573 is included in 15.10.13 and the workaround explained in Loading... (stop storing diffs in the history table) should work just fine in 15.10.3 too, and itā€™s by far the main performance penalty.

But anyway, I do recommend moving to a supported LTS branch, indeed.

7

Setting xwiki.store.rcs.nodesPerFull property to 1 in xwiki.cfg will affect all xwiki documents right?

We do have more then 10.000 articles and the real time editor is doing a lots of saving currently. So Iā€™m not sure if this fits our needs.

So I think I will deal with those zombies manually until we are updated.

8

Yes. But thatā€™s basically exactly what is done in more recent versions of XWiki (the default just changed to 1). The only difference (which can also be applied by hand) is that, in the case of MySQL/MariaDB, we also switched the table which is storing the document history to Compressed row format (ALTER TABLE xwikircs ROW_FORMAT=Compressed).

9

Ok, that info makes a difference for us.

When I look into our xwiki.cfg I donā€™t find the key xwiki.store.rcs.nodesPerFull. Can you provide me an actual excerpt of this region so we can fill this is?

10

Yes, it always been more of an internal configuration.

Iā€™m not entirely sure what you mean, you just need xwiki.store.rcs.nodesPerFull=1.

11

xwiki.cfg normally has a lot of useful comments around the entries. I just wanted to participate of those original comment. (But this will at least happen when I update the wiki later and the config is merged I guess.)

12

This option is still very much internal. We did not dare removing it entirely just yet, but we would really prefer users not to touch this behavior, and eventually entirely remove the concept of diff in the history so that we can simplify a lot the code and fully rely on that to improve other aspects (mainly around the performances of loading a specific version).