Project

General

Profile

Messages to Smack clients are duplicated with Stream Management

Natale Vinto
Added over 3 years ago

Hello,

I've a strange issue that I'm trying to figure out either in stable than development Tigase version: messages sent to Smack 4.1 Android clients are duplicated while ones to XMPPFramework iOS clients are not.

I'm using on both Mobile platforms stream management with stream resumption enabled, and this issue comes only on Smack clients when a user login twice without stream resumption in about 10 minutes from latest message (I guess TCP keep-alive is involved in this estimated average time)

The issue comes both on latest Tigase stable build 7.0.2 than a development 7.1.0-SNAPSHOT-b3891/84db83a3 I'm using for another issue

I've atteched two files that show that both xmpp libraries do the same thing:

1: use compression

2: use tls

3: use stream management

4: connect announcing presence

5: disconnect annoucing presence unavailable

the message sent is sent from Tigase admin user on default virtualhost, to an user on another virtualhost that has LIST policy: domain.tld;sub.domain.tld

<message id="69xbq-10" type="normal" to="kingrichard@sub.domain.tld/Smack" from="admin@domain.tld/Resource"><subject>Test</subject><body>test 1</body>..other xeps here..<amp xmlns="http://jabber.org/protocol/amp"><rule action="error" condition="expire-at" value="2015-07-24T17:01:37Z"/><rule action="error" condition="match-resource" value="other"/></amp>

both error or drop action are used in tests

<rule action="drop" condition="expire-at" value="2015-07-24T17:01:37Z"/><rule action="drop" condition="match-resource" value="other"/>

but the result is the same by the client side, messages arrive and they seems always in RAM.

I've also attached a log from Tigase side, this is what I see in Tigase logs as soon a duplicated message comes again to the mobile client. It looks like a STREAM_CLOSED event comes and trigger the resending, also this error appear:

<iq type="error" id="7ckgD-74" xmlns="jabber:client" from="kingrichard@sub.domain.tld/Smack"><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"><jid>kingrichard@sub.domain.tld/Smack</jid></bind><error type="wait" code="404"><recipient-unavailable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></iq>

while client is connected indeed. It looks like the previous stream management session was not properly closed and new one didn't invalidated the old one that trigger somehow the message resend.

The strange thing is that on XMPPFramework this doesn't happens and a I see from Tigase logs I've attached only STREAM_CLOSED_UPDATE

I see another 404 but this maybe because the sender weren't available anymore

What do you think about this issue? Could really be a Smack-related issue or a misconfiguration by Tigase side that somehow works with XMPPFramework?

I really don't understand why the message keeps in RAM after is sent instead.

Thanks

Natale

android_xmpp.txt (4.94 KB) android_xmpp.txt Smack 4.1 stream initialization, connection and disconnection
ios_xmpp.txt (3.48 KB) ios_xmpp.txt XMPPFramework 3.6.4 stream initialization, connection and disconnection
android_error.txt.zip (6.55 KB) android_error.txt.zip Tigase log for Smack 4.1 containg STREAM_CLOSED event that trigger the re-sending of the message
ios_error.txt (2.8 KB) ios_error.txt Tigase log for XMPPFramework 3.6.4
android_xmpp.txt (4.94 KB) android_xmpp.txt Smack 4.1 stream initialization, connection and disconnection

Replies (3)

Added by Natale Vinto over 3 years ago

the correct android debug xml log is the last one attached

Added by Wojciech Kapcia TigaseTeam over 3 years ago

It's look like it may be a Smack related problem, vide: https://projects.tigase.org/boards/4/topics/5434

Added by Natale Vinto over 3 years ago

Hi Wojciech,

I could then fix this issue acking immediately received stanza by Smack API

http://igniterealtime.org/builds/smack/docs/latest/javadoc/org/jivesoftware/smack/tcp/XMPPTCPConnection.html#sendSmAcknowledgement()

thus Tigase knows soon that Message is arrived and if connection drops out

while standard SM timeouts don't trigger, the server doesn't send messages

anytime.

I had also to manage stanza acking immediately after stream management

resumption

Thanks

Sent from my Mobile, sorry if any typo.

Natale

    (1-3/3)