What are particular settings of your installation? ie. how long it is allowed to wait for XMPP client to resume? Do you have any custom code?

I'm asking about that because Tigase Message Archiving Component contains code for possible duplicate message detection if the message is redelivered and this solution works quite well for us on many installations.

One of the possible issues may be:

• too big allowed resumption time
• message without the id attribute (if available duplicated detection works far better)
• XMPP client waits too long before acknowledging delivered messages
• time drift between XMPP servers withing the cluster or between XMPP servers and the database server

init.properties

config-type=--gen-config-def
--admins=admin@ip
--virt-hosts =ip
--debug = server

--comp-name-1=http
--comp-class-1=tigase.http.HttpMessageReceiver
http/http/ports[i]=8096
http/setup/admin-credentials=admin:abcd1234

--comp-name-2 = muc 
--comp-class-2 = tigase.muc.MUCComponent 
muc/default_room_config/muc#roomconfig_persistentroom=true


--comp-name-3 = pubsub 
--comp-class-3 = tigase.pubsub.PubSubComponent 

--comp-name-4=message-archive
--comp-class-4=tigase.archive.MessageArchiveComponent
 
sess-man/plugins-conf/message-archive-xep-0136/default-store-method=message
sess-man/plugins-conf/message-archive-xep-0136/required-store-method=body
sess-man/plugins-conf/auto-authorize=true

--sm-plugins=+message-archive-xep-0136,+jabber:iq:auth,+urn:ietf:params:xml:ns:xmpp-sasl,+urn:ietf:params:xml:ns:xmpp-bind,+urn:ietf:params:xml:ns:xmpp-session,-jabber:iq:register,+jabber:iq:roster,+presence,+jabber:iq:privacy,+jabber:iq:version,+http://jabber.org/protocol/stats,+starttls,+msgoffline,+vcard-temp,+http://jabber.org/protocol/commands,+jabber:iq:private,+urn:xmpp:ping,+basic-filter,+domain-filter,+pep,+zlib

sess-man/plugins-conf/message-archive-xep-0136/component-jid=message-archive@test
message-archive/archive-repo-uri=jdbc:mysql://127.0.0.1/tigasedb?user=tigase&password=123456&useUnicode=true&autoReconnect=true

sess-man/plugins-conf/amp/store-limit[L]=1000
amp/store-limit[L]=1000
sess-man/plugins-conf/amp/user-store-limit-enable[B]=true
amp/user-store-limit-enable[B]=true

--user-db=mysql
--user-db-uri=jdbc:mysql://127.0.0.1/tigasedb?user=tigase&password=123456&useUnicode=true&autoReconnect=true

## The following configuration does not work
#c2s/watchdog_timeout[L]=3000                    
#c2s/watchdog_delay[L]=1500
#c2s/packet-delivery-retry-count[I]=3       

The client is the BOSH protocol:

connection = new Strophe.Connection(BOSH_SERVICE, {keepalive: true});
connection.connect(jid, password, onConnect);

The XMPP server version is 7.1.4 , the server and database server are on the same machine. No cluster is deployed. I don't have any custom code. If the client network is normal, the messages sent and received are normal. If client the network is unstable, there is a problem of duplicate receipt of messages.

Thanks

In this case usage of BOSH and not delivery messages by BOSH is actually root cause of this issue. If the message is not delivered to the recipient by BOSH component it sends it back for redelivery so in fact, Tigase XMPP Server is processing this message twice and that is causing duplication of messages.

Do you have any requirement to use BOSH for connecting to Tigase XMPP Server? I'm asking as WebSocket based connections are a lot faster, are using fewer resources and more reliable when StreamManagement is enabled on them. (and thanks to StreamManagement, message duplication is not happening due to different processing flow which cannot be applied to BOSH based connections).

I changed the connection.

connection = new Strophe.Connection('ws://ip:5290', {keepalive: true});

Message duplication did not occur.

But another problem arises :

After A user's network is unstable and the connection drops, the message sent by B will not be saved as an offline message (msg_history did not insert data, Tig_ma_msgs table holds two record , the sending record of B and the receiving record of A ). When A reconnects, there is no new message to remind. Then , when querying the history record of A user, there is the sending message record of B user.

I hope the solution is that after A user's network is unstable and the connection drops, the message sent by B is saved as an offline record, and when user A reconnects, he receives an offline message reminder. When getting the history message of A, there is the message record sent by user B.

Thinks.