And the resend_on_timeout sends messages that were acknowledged too and that too it keeps resending those same messages again and again everytime the resend timeout expires even though I've already received it. With session management enabled and resend_on_timeout set to true it does prevent dead messages but order of the message flow is disrupted.I do understand the benefit of stream management but it brings up this inevitable issue of dead messages as stated above. This is the ideal behaviour we all expect. Where if a client disconnects, the server doesn't wait for any timeout and notices a client going offline and any messages sent is stored in the offline storage. Disabling stream management works as expected.So, if Client A comes back online, it won't receive any messages that were sent to it when it disconnected. During this phase, any messages sent by Client B will be lost, meaning it's not stored in mod_offline which can be referred to as dead messages. Let's say Client A 's network suddenly goes offline, due to the timeout, Client A will still appear as online to the server until the timer runs out. This happens when a client suddenly disconnects.Īssume Client A and Client B are in a 1:1 conversation. PS:- Earlier I had referred issue #3086 and configured eJabberd with the recommended configuration for mod_stream_mgmt and mod_mam Reconnect the app to server - Only the message2 is received.Ĭan anyone help me with the message drop issue. Send message2 - this gets inserted to spool table.Wait of the user session to become offline.Check the user presence in server is online.I am able to consistently reproduce this issue using the following steps: I am stll relying on spool for offline message retrieval. Previously (in eJabberd 20.04), this issue was not observed. I have upgraded recently from ejabberd 21.12. Once the user presence is removed from server, the messages received thereafter starts geting saved to spool table in DB and the user gets those messages on reconnect. If the user session is resumed within this window of resume_timeout, all offline messages are received by the user. During this period, any messages sent to the user is never gets stored to spool table. When the mobile app client (SMACK 4.4.5) goes offline, the user session remains in the server for 5 mins (resume_timeout). I still don't know why this error message is not written in the log by default but at least I have a way to debug it now, and my current issue seems to be related to the absence of erlang-p1-pkix.Access_max_user_messages: max_user_offline_messages In call from ejabberd_config:load_file/1 (src/ejabberd_config.erl, line 568) In call from ejabberd_config:validate/1 (src/ejabberd_config.erl, line 535) In call from ejabberd_config:validators/1 (src/ejabberd_config.erl, line 328) In call from lists:foldl/3 (lists.erl, line 1263) In call from ejabberd_config:'-validators/1-fun-0-'/3 (src/ejabberd_config.erl, line 330) In call from ejabberd_config:validators/2 (src/ejabberd_config.erl, line 469) In function ejabberd_options:options/0 (src/ejabberd_options.erl, line 483) ** exception error: undefined function pkix:get_cafile/0 If you are not running any third-party code, please report the bug with ejabberd configuration file attached and the following stacktrace included: This is most likely due to faulty/incompatible validator in third-party code. "/.well-known/acme-challenge": ejabberd_acmeĪccess_max_user_messages: max_user_offline_messagesĠ3:38:40.999 Failed to start ejabberd application: Exception occurred during configuration processing. error.log to 100Ġ3:38:39.859 Changed loghwm of ejabberd.log to 100Ġ3:38:40.778 Loading configuration from ejabberd.ymlĠ3:38:40.881 Changed loglevel of ejabberd.log to debugĠ3:38:40.960 Transformed configuration: # erl +K true -pa /usr/lib/ejabberd-19.09.1/ebin -pa /usr/lib/erlang/*/ebin -snaĮshell V10.0 (abort with ejabberd:start().Ġ3:38:39.844 Changed loghwm of.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |