@tigase team: Let me know what other info you need to be able to debug this issue.

I can confirm this happens to me too, but I'm currently unable to provide logs. Specifically, Tigase re-saves the message appending more and more elements to it. I'll try to "frame the moment" and get back to you.

Ok I think I know what is causing this (or a similar bug maybe?). Steps to reproduce:

1. bob@server.org/work sends a message to alice@server.og/home which is offline (goes to offline storage)

2. alice@server.org connects with another resource

3. alice@server.org/newresource gets the message from bob, but receiving it with to="alice@server.org" (bare JID)

4. the message is probably also queued with the origin full JID, because it gets stored to offline storage again

5. message is delivered to "newresource" everytime and stored again until the old resource ("home") gets back

I suggest that a message delivered to an offline full JID either:

• is stored to offline storage with the bare JID

• is delivered only to the intended bare JID

Andrzej, please take a look at it as soon as you can.

I tried to replicate this issue using newst version from master branch, but I was not able to replicate this issue.

Message was sent to offline store only once and when it was retrieved to deliver to user it was removed from offline storage.

I would suggest to check logs for any possible exceptions which may be related to this issue as this may give us some hints about cause of this issue (ie. permissions to database tables might not allow Tigase to remove records).

Another reason for this might be that XMPP client which receives message once it connects is using XEP-0198 Stream Management and is not acking that it received this message - this would lead to sending this message to offline store once again - but behavior of Tigase XMPP Server would be correct in this case as Stream Managements needs to send messages which are not acked to offline storage.

Other reason could be some custom code which could create a loop.

To continue this investigation I would need:

• to know whether it was in clustered environment or in single instance (if in cluster mode then how many cluster nodes where connected)

• copy of Tigase XMPP Server configuration file etc/init.properties so I could check what is enabled and how it should work in this case.

• logs with entries from time when this occured issue occurred

Also I would like to know what was load on server on which this occurred? Was it rather big or on this server there was a lot of presence packets to process at the time when this issue occurred.

I think that this may be caused by patch from #2561 if it was applied, was it?

Hi, I'll upgrade to latest version and try reproduce it myself. For now I've solved the most important issue which causes the delay element to be added over and over by using a workaround:

https://github.com/kontalk/tigase-server/blob/master/src/main/java/tigase/xmpp/impl/OfflineMessages.java#L296

Don't care about the wrong comment; what I did here is check if the delay element was already added and, if not, add it.

Closing as there was no feedback, so I assume the problem was not replicated.