Until now, when stopping the ejabberd container, Erlang is not gracefully
closed, Mnesia is not properly closed... exit code is 137.
With this change, when the container is stopped, Erlang receives the
SIGTERM signal, shutsdown, Mnesia database is properly closed, ...
and exit code is 0.
The old version was:
rebar 3.15.2
and it couldn't work with Erlang/OTP 25
This new version is
rebar 3.18.0
compiled from tag 3.18.0 from
https://github.com/erlang/rebar3
using erlang:22-slim docker image
To compile ejabberd using rebar3 and ancient Erlang 19.3-21.3,
you need a rebar3 binary compiled with an old Erlang.
If your operating system doesn't provide one, you can download
the old one included in ejabberd 21.12, available at:
https://github.com/processone/ejabberd/raw/21.12/rebar3
The old version was:
rebar 2.6.4 17 20170823_084242 git 2.6.4-27-g8076675-dirty
and it couldn't work with Erlang/OTP 25
This new version is
rebar 2.6.4 22 20220426_202500 git 2.6.4-39-gb6d3094
compiled from master branch from
https://github.com/rebar/rebar
using erlang:22-slim docker image
To compile ejabberd using rebar and ancient Erlang 19.3-21.3,
you need a rebar binary compiled with an old Erlang.
If your operating system doesn't provide one, you can download
the old one included in ejabberd 21.12, available at:
https://github.com/processone/ejabberd/raw/21.12/rebar
Don't forget the push session ID if the client resumes a stream
management session. This makes sure no push notifications are generated
for a connected client with a resumed stream management session.
Thanks to Thilo Molitor for spotting the issue.
The fact that mod_push uses a timestamp as a push session ID is just an
implementation detail. Rename things accordingly to avoid confusion.
However, stick to "timestamp" in the storage modules, as it corresponds
to the database column names/types, there.
Fix the problem that no push notifications were triggered in the case
where all of the following conditions applied:
- The XEP-0198 session has been resumed at least once.
- The XEP-0198 session is pending (i.e., the client is disconnected).
- The message wasn't stored in the user's MAM archive (e.g., because it
was of type "groupchat").
The problem was introduced in cd336369a5.
Many thanks to Friedrich Altheide for reporting the issue and to Thilo
Molitor for his help with tracking it down.
