Otherwise, if the server crash (not properly stopped), all recent
messages are lost. In this case, it is better to at least keep
the outdated ones (and miss the new ones that were not saved to DB).
ejabberdctl moderate_room_history now do a multicast to
moderate the room history on all nodes on the cluster
(as the room might be replicated on different nodes).
If the mod_muc configuration says that rooms are
persistent by default, store the room to disc once
it is created, as there are use cases where there are
no further config after room creation, and so
the write to disc was never triggered.
Sending one large chunk of data with tls:send eats lots of
CPU power and blocks whole Erlang emulator. This is caused by the
fact that encrypted output is read from memory BIO in 1k chunks.
Memory BIO, after reading data, shifts the remaining part.
If large chunks of data (few MB) is sent and then read in 1k
chunks, then a _lot_ of shifting is performed eating CPU.
The solution is to simply allocate binary of the needed size
(amount of data in memory BIO can be retrieved with
BIO_ctrl_pending) and then issue only one read that reads the
whole data.
Ejabberd can be configured to store recent history of MUCs
to DB before shutdown. On restart, those messages are
retrieved from storage.
To enable it, set {persist_history, true} in mod_muc configuration,
ej:
{mod_muc, [
%%{host, "conference.@HOST@"},
{access, muc},
{access_create, muc_create},
{access_persistent, muc_create},
{access_admin, muc_admin},
{persist_history, true}
]},
Messages are only stored on server shutdown, not on the fly.
$ejabberdctl stop
or
init:stop()
inside a debug console works.
Note: Only rooms configured as "persistent" will save messages
(as other rooms doesn't survive server restart anyway).
Limitations: There is no option to store messages on mnesia, you *must*
use a ODBC database. Only tested with mysql.
Check odbc/mysql.sql for the definition of the table "room_history",
the one needed for this.
