Don't write MAM messages into an Mnesia archive if the size of the table
comes close to the 2 GB limit for tables with disc-only copies. That
way, the table is at least not corrupted when the limit is reached.
Let mod_mam_mnesia use transactions when storing or deleting messages.
If old messages of a user are to be removed, delete the user's archive
and rewrite it from scratch, as that seems to be much faster than
removing individual records with delete_object/1.
Closes#1065.
If the new "queue_pep" option is enabled and the client is inactive, PEP
notifications are throttled in a similar way to presence stanzas and
chat states. Only the most recent notification of a given node and
payload type will be queued from a given contact.
Let mod_client_state handle the queueing of stanzas, not just their
classification. This simplifies the ejabberd_c2s code and gives
(custom) CSI modules more flexibility.
Let the main mod_http_upload process look at the size of an HTTP upload
rather than performing this check in the ejabberd_http handler. This
way, the upload slot won't be invalidated if the size of the uploaded
file doesn't match the size requested for the slot. The PUT request is
still rejected, but the client now has a chance to retry the upload.
When stanzas are bounced from the stream management queue (because the
session timed out or was closed for some other reason), use a different
error message so that this situation can be distinguished from other
cases.
We no longer rely on getting unique values from clock source, so we need
to handle cope with systems which does not have a microsecond resolution
on system clock (such as MS Windows)
As per XEP-0016 and XEP-0191, return a service-unavailable error when an
incoming last activity query was blocked by a privacy list (just as we
do for other IQ requests).
If an incoming message sent to an unavailable resource has an unknown
type, handle it like messages of type "normal" (as mandated by RFC 6121,
section 5.2.2). The same is already done for messages of unknown type
sent to the bare JID of an offline user.
Don't bounce an error when a message of type "headline" is sent to an
unavailable resource. This is consistent with how headline messages
sent to the bare JID of an offline user are dropped, and it avoids a
presence leak.
As per XEP-0016 and XEP-0191, return a service-unavailable error when an
incoming message sent to an offline user was blocked by a privacy list.
The same is done for a message sent to an online user, so this avoids a
presence leak.
