Hi,
I have jabbed installed on Ubuntu. And implemented Chat feature in IOS application. I have mySQL configured. A shared roster is created with all users added to it. Everything was working smoothly unless we migrated actual production users data (about 7000) users in database. From there one, no user is able to login. Basically, authentication is success, but immediately connection is disconnecting. Logs are as
CRASH REPORT Process <0.27200.1> with 0 neighbours exited with reason: {process_limit,{max_queue,1513}} in p1_fsm:terminate/8 line 755
2016-01-30 11:38:19.534 [error] <0.353.0> Supervisor ejabberd_c2s_sup had child undefined started with {ejabberd_c2s,start_link,undefined} at <0.27200.1> exit with reason {process_limit,{max_queue,1513}} in context child_terminated
Is there any thing i can configure for this to work? Do i have to use different edition of jabbed installation for such large user base?
Snehal wrote: Do i have to
Do i have to use different edition of jabbed installation for such large user base?
There isn't any limit in ejabberd, only the system limits.
Also 7000 registered accounts is a "small" server.
A shared roster is created with all users added to it. Everything was working smoothly unless we migrated actual production users data (about 7000) users in database.
CRASH REPORT Process <0.27200.1> with 0 neighbours exited with reason: {process_limit,{max_queue,1513}} in p1_fsm:terminate/8 line 755
2016-01-30 11:38:19.534 [error] <0.353.0> Supervisor ejabberd_c2s_sup had child undefined started with {ejabberd_c2s,start_link,undefined} at <0.27200.1> exit with reason {process_limit,{max_queue,1513}} in context child_terminated
You have 7.000 registered accounts, and a shared roster group with all them. This means that, each time a user logins, ejabberd sends him 7.000 roster items. I guess those users are not human, because a human can't handle such numbers. And looking at your log, ejabberd is having problems sending so much items in a single stanza, to a single user. I also imagine the clients will have problems handling the roster if they receive it.
Is there any thing i can configure for this to work?
None of them is equivalent to what you want to have now, but maybe one of them is good enough for your definitive requirement:
- Instead of @all@, use @online@
- Split your user base in several splitted vhosts, for example 7 vhosts of 1000 users each, then use @all@ inside each one.
- Instead of shared roster groups, use a MUC room. I am almost sure a MUC room with 7000 occupants will have the same problem, but in case you want to try it...
- Instead of a room with 7.000 occupants, create 70 rooms with 100 occupants each one. This will surely work, both for ejabberd and for your clients. But I guess this will not help you in your problem.
- If you just want users to be able to send messages to all other users, use mod_announce instead.