I am using ejabberd version 17.03 and I want to add a large number of users to a shared roster group so basically a user for a large organization can view online users across that organization only. I am encountering problems when trying to login and retrieve a shared roster with ~1000 users in it.
20:54:19.038 [info] (<0.515.0>) Accepted connection 172.18.0.1:43340 -> 172.18.0.3:5280
20:54:19.039 [info] started: {fast_tls,{tlssock,#Port<0.22241>,#Port<0.22242>}}
20:54:19.060 [info] (<0.516.0>) Accepted connection 172.18.0.1:43342 -> 172.18.0.3:5280
20:54:19.062 [info] started: {fast_tls,{tlssock,#Port<0.22243>,#Port<0.22244>}}
20:54:19.138 [info] (websocket|<0.518.0>) Accepted c2s SCRAM-SHA-1 authentication for test1@localhost by sql backend from 172.18.0.1
20:54:19.165 [info] (websocket|<0.518.0>) Opened c2s session for test1@localhost/c00eda5c-c92d-ed17-1152-f66530519832
20:54:19.321 [warning] Module 'mod_carboncopy' doesn't support database 'sql' defined in option 'default_db', using 'mnesia' as fallback
20:54:19.362 [info] (websocket|<0.518.0>) Closing c2s session for duc1@localhost/c00eda5c-c92d-ed17-1152-f66530519832: internal server error
20:54:19.379 [error] CRASH REPORT Process <0.519.0> with 0 neighbours exited with reason: {process_limit,{max_queue,1002}} in p1_server:terminate/7 line 864
20:54:19.381 [error] Supervisor ejabberd_c2s_sup had child undefined started with {ejabberd_c2s,start_link,undefined} at <0.519.0> exit with reason {process_limit,{max_queue,1002}} in context child_terminated
The last line is the error indicating some process_limit has been reached.
Is there a documented limit to the size of shared roster groups? And, is there a way to configure this?
What issues should come up when using shared roster groups with a large number of entries in them?
Basically, I'd like to do something like maintaining shared roster groups for many organizations where a user from an organization logs in and can view online/offline users across a single organization. I'd also like to be able to set up these organizations dynamically, so using virtual hosts and the @online@ with a shared group wouldn't apply from my understanding of virtual hosts.
There was a similar post here:
https://www.ejabberd.im/forum/25344/ejabberd-disconnecting-immediately-a...
Thank you for the insight!
There isn't any imposed limit
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
Thanks! It does appear that
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.