Hi,
is it possible (like authentication) to get muc-room information from an existing database?
I get the userdata from mysql database with the external php auth script. Now i need to get muc-rooms and the allowed users for that room out of the same database. Is this possible?
Looking for ejabberd docs?
To access the most up-to-date ejabberd documentation, please visit docs.ejabberd.im »
Chatrooms (muc) from external Database possible?
Submitted by gunnicom on Mon, 2006-12-18 16:50
mod_muc_odbc
This will require commiting a new module to the codebase, possibly called mod_muc_odbc. This module does not exist right now, so the answer to your question is "no". It's a desired feature. I'm putting some work into it myself.
Is mod_muc_odbc implemented?
It has been a year since last post, what's the current progress? Is mod_muc_odbc implemented?
Maybe mod_muc_admin
It has been a year since last post, what's the current progress? Is mod_muc_odbc implemented?
Only mod_muc is available, which stores room information in the internal Mnesia database. If your interested in ODBC storage is to allow you to modify/read room information, maybe is useful to you. It provides commands that you can call in the shell ejabberdctl, or using XML-RPC, or using HTTP REST calls.
MUC is so memory consuming
My actual interest in mod_muc_odbc is because MUC is so memory consuming. We use ejabberd as the backend of a multi-user online game, which to date creates 300,000 users in ejabberd's database, with each user owning a persistent chat room. The concurrent online users are about 3000+.
The memory used by ejabberd can increase to more than 10G in a few hours after restart. Now I delete muc_room.DCD and muc_room.DCL, which in effect deletes all the persistent rooms I guess, things seem to be better.
I wonder (1) if storing muc in MySQL would be less memory consuming, (2) how ejabberd uses those memory, the size of muc_room.DCD and muc_room.DCL is only about 200M in total; even mnesia stores them in memory, it wouldn't need so huge menory.
version of ejabberd: 2.0.5, OS: CentOS
Let's make some numbers
(2) how ejabberd uses those memory, the size of muc_room.DCD and muc_room.DCL is only about 200M in total; even mnesia stores them in memory, it wouldn't need so huge menory.
Each alive room is represented in ejabberd as a process which keeps track of its configuration, presence, message history, ... Additionally, some information is stored in the database persistently.
I've made some quick numbers. When a room is created and a user joins, the process of the room has a heap_size of 2600 words:
2600 words * 32 bits/word * 1/8 byte/bits = 10.400 bytes = 10 KB
If you create one room per registered account: 300000 rooms * 10 KB = 3000000 KB = 3000 MB = 3 GB
If you configure the rooms to be persistent, etc, the consumption per room increases. If you use a 64 bit machine, the memory consumpion doubles.
I wonder (1) if storing muc in MySQL would be less memory consuming,
As you can see, it wouldn't.
each user owning a persistent chat room
Consider your design: you create a Multi User Chat room for each account that was registered, even if it wasn't used in several days, even if it is only used for 1 hour each day, even if the room has only 1 occupant ever.
A hard choice
Thanks for the informative reply.
I didn't know each room is a process, no matter there are occupants or not. So, my initial design was a bad one.
To be more specific, the scenario is as follow: each player in our game owns a "shop", which enable the owner to decorate the shop and his/her friends to visit the shop exchange goods there. I want the presence of a player in a shop and the interaction within to be exchanged by MUC. If the chat rooms are not persistent, virtually a room will be created and destroyed every time a player visit a shop, which is very frequent. There would be a lot of communication between clients and the server. If chat rooms are persistent, since the ratios of concurrent users/registered users is less than 1/100, more than 99% of chat rooms would be idle while taking up memory. That's a hard choice, any suggestions? Or maybe we should not use ejabberd in this way?
Sweep Rooms
My application does a similar thing with conference rooms. I have deployed the mod_muc_admin module which provides a function to delete unused rooms. I run this once an hour. This keeps the memory under control and prevents a room creation rate that exceeds ejabberd's resources.