Thanks! It does appear that

dnguyen580 — Thu, 15 Jun 2017 13:45:09 +0000

Thanks! It does appear that max_fsm_queue does affect this process limit. Now my new question is what is that actual limit? I am assuming it is largely (entirely?) dependent on hardware and resources? Or is it like the JVM heap size from ages ago... that if you get over a certain size, it's unusable because a garbage collector is continuously running.

There isn't any imposed limit

badlop — Wed, 14 Jun 2017 07:57:26 +0000

There isn't any imposed limit in shared roster, it's just the limits in other places what applies. In this case there is a process limit called max_queue that gets reached I din't see in ejabberd documentation how it can be changed, but it may be related to max_fsm_queue, search that in the ejabberd Documentation: https://docs.ejabberd.im/admin/configuration/

Instead of manually adding users one by one, you can try the @all@ thing, but there isn't guarantee it will work with so many users, anyway. You could add a vhost per organization, then set a shared roster group @all@ in each one, and another group in each vhost for the supervisor user, see examples 2 and 3 in https://www.ejabberd.im/shared-roster-all

ejabberd - Comments for "ejabberd community version and large number of users in shared roster groups"

Thanks! It does appear that

There isn't any imposed limit