Offline message lost in group chat push (#1370)

Unknown opened 5 years ago

Edition tigase：8.0.0 muc:3.0.0 mongodb:2.0.0 Steps to reproduce the behavior: 1.Send tout

<presence to='af24de38bbc94160a9684aa15e42666d@muc.sm91.mjt.net/100161' from='100161@sm91.mjt.net/nisc_pc' xmlns='jabber:client'><priority>0</priority><x xmlns='http://jabber.org/protocol/muc'><history seconds='371'/></x><c xmlns='http://jabber.org/protocol/caps' hash='sha-1' node='http://camaya.net/gloox' ver='OFXvsrS7Y4jwIKmoMw9iwPn7Q6U='/></presence>

2.E.g.: find out 500 historical records 3.The server push part sends the following XML information

 <presence type='unavailable' to='100161@sm91.mjt.net/nisc_pc' from='af24de38bbc94160a9684aa15e42666d@muc.sm91.mjt.net/a2' xmlns='jabber:client'>
 <x xmlns='http://jabber.org/protocol/muc#user'>
  <item nick='a2' affiliation='none' jid='100162@sm91.mjt.net/nisc_voip' role='none'/>
 </x>
</presence>

4.Later historical news will be pushed. 5.What's the reason for sending the XML above。 type='unavailable'

Unknown commented 5 years ago

I had the same problem

Unknown commented 5 years ago

When retrieving larger history from the database it's quite likely that you've triggered Tigase throttling mechanism, which disconnect the user. Please see cm-traffic-throttling for more details.

If you want to disable it you can use following configuration:

'cm-traffic-throttling' = 'xmpp:0:0:disc,bin:0:0:disc'

Unknown commented 5 years ago

Set up

'cm-traffic-throttling' = 'xmpp:0:0:disc,bin:0:0:disc'

There will still be 300 group chat history records, but the client can only receive about 200. What's the reason for this ？ Historical messages in the middle will be lost.

Unknown commented 5 years ago

What's the reason for this ？

Please provide more information:

what is being lost exacly?
Are you still being disconnected?
What are the error messages that your client receives (XML stanzas)?
If this is MUC history - have you tried changing muc room configuration regarding history length?
Check server logs for more details/information about processing.

Unknown commented 5 years ago

MUC history length set to 1000.

Tigase mongodb version 3.0.0 In the gethistorymessages method of mongohistoryprovider class, the number of group chat history results obtained from the database is 500, but the client can only receive about 400 group chat histories, and the history of group chat that will be lost is about 100.

After the client receives the following XML, there will be no group chat history message. When will the server send the following XML to the client?

<presence xmlns="jabber:client" type="unavailable" from="347f84d9555f407a9a3071261f59d51f@muc.hnmjt.mjt.net/100165" to="100163@hnmjt.mjt.net/nisc_voip"><x xmlns="http://jabber.org/protocol/muc#user"><item role="none" nick="100165" affiliation="member"></item></x></presence>

What do the following server logs mean? What is the cause?

2019-12-04 22:20:43.495 [in_0-message-router]  MessageRouter.processPacket()       FINEST:   1. Packet will be processed by: sess-man@localhost, from=sess-man@localhost, to=sess-man@localhost, DATA=<message xmlns="jabber:client" type="error" id="6eeba009eeb14fe0b90a1d96fc1df7b8" from="100160@hnmjt.mjt.net/nisc_voip" to="72c6317a7ae64978b58601384711d7a7@muc.hnmjt.mjt.net/100165"><body>CData size: 306</body><delay xmlns="urn:xmpp:delay" from="72c6317a7ae64978b58601384711d7a7@muc.hnmjt.mjt.net" stamp="2019-12-04T14:11:58.027Z"/><error type="wait" code="404"><recipient-unavailable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/><text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" xml:lang="en">CData size: 37</text></error></message>, SIZE=848, XMLNS=jabber:client, PRIORITY=NORMAL, PERMISSION=NONE, TYPE=error

Unknown commented 5 years ago

<presence xmlns="jabber:client" type="unavailable"…

This one means that client left the room (or was removed)

The log entry indicates, that there were some messages pending to be delivered, but the user was not connected.

It looks like that for some reason your client still lost connection, but without more information it's hard to investigate it.

Are you sure you completely disabled throttling? Would you mind sharing your etc/config.tdsl and etc/config-dump.properties configuration files?

You should review your logs for any signs of user being disconnected (search the logs for all entries with 72c6317a7ae64978b58601384711d7a7@muc.hnmjt.mjt.net/100165)

Unknown commented 5 years ago

I want to know when the server will disconnect the user. I want to ask which class is disconnected from the user.

Here is my configuration.

etc/config-dump.properties

etc/config.tdsl:

c2s_port=5222
s2s_port=5269
'config-type' = 'default'
debug = [ 'server' ]
'vhost-anonymous-enabled' = false
'default-virtual-host'=hnmjt.mjt.net
bosh_connections_5280_type = refuse
ws2s_connections_5290_type = refuse
c2s_connections_5223_type = refuse
s2s_connections_5269_type = refuse
'watchdog-timeout' = 15000
'watchdog-delay' = 30000
c2s_MaxInactiveTime=800000
'cm-traffic-throttling' = 'xmpp:0:0:disc,bin:0:0:disc'
'cm-ht-traffic-throttling' = 'xmpp:0:0:disc,bin:0:0:disc'
'elements-number-limit' = 10000
'max-queue-size' = 1024
dataSource {
    default () {
        uri = 'mongodb://127.0.0.1:27017/tigase'
    }
}
userRepository {
    default () {
        cls = 'tigase.mongodb.MongoRepository'
    }
}
authRepository {
    default () {
        cls = 'tigase.mongodb.MongoRepository'
    }
}
amp {
    'amp-repo-class' = 'tigase.mongodb.MongoMsgRepository'
    'amp-repo-uri' = 'mongodb://127.0.0.1:27017/tigase'
}
c2s {
    seeOtherHost {}
    'urn:xmpp:sm:3' () {
        'resumption-timeout' = 60
    }
}
muc (class: tigase.muc.MUCComponent) {
    'history-db' = 'tigase.mongodb.muc.MongoHistoryProvider'
    'history-db-uri' = 'mongodb://127.0.0.1:27017/tigase'
}
s2s {
     seeOtherHost {}
    'urn:xmpp:sm:3' () {                                    
        'resumption-timeout' = 60                           
    } 
}
'sess-man' () {
    amp {
        'amp-repo-class' = 'tigase.mongodb.MongoMsgRepository'
        'amp-repo-uri' = 'mongodb://127.0.0.1:27017/tigase'
    }
    'jabber:iq:register' () {                                     
    }
    'shiku-auto-reply' (class: tigase.olym.OlymAutoReplyPlugin) {}
    starttls (active: true) {}
    'urn:ietf:params:xml:ns:xmpp-sasl' {
        'callbackhandler-SCRAM-SHA-1' = 'tigase.auth.impl.ScramCallbackHandler'
    }
}

Unknown commented 5 years ago

Your configuration looks OK, but as I said before:

It looks like that for some reason your client still lost connection, but without more information it's hard to investigate it.

There are a couple of things that could trigger disconnection and investigating the logs would be the best starting point. You could also try increasing elements-number-limit if you are (for some reason) sending large stanzas.

Unknown commented 5 years ago

change max-queue-size=4096 resolved

	Unknown opened 5 years ago Edition tigase：8.0.0 muc:3.0.0 mongodb:2.0.0 Steps to reproduce the behavior: 1.Send tout `<presence to='af24de38bbc94160a9684aa15e42666d@muc.sm91.mjt.net/100161' from='100161@sm91.mjt.net/nisc_pc' xmlns='jabber:client'><priority>0</priority><x xmlns='http://jabber.org/protocol/muc'><history seconds='371'/></x><c xmlns='http://jabber.org/protocol/caps' hash='sha-1' node='http://camaya.net/gloox' ver='OFXvsrS7Y4jwIKmoMw9iwPn7Q6U='/></presence>` 2.E.g.: find out 500 historical records 3.The server push part sends the following XML information `<presence type='unavailable' to='100161@sm91.mjt.net/nisc_pc' from='af24de38bbc94160a9684aa15e42666d@muc.sm91.mjt.net/a2' xmlns='jabber:client'> <x xmlns='http://jabber.org/protocol/muc#user'> <item nick='a2' affiliation='none' jid='100162@sm91.mjt.net/nisc_voip' role='none'/> </x> </presence>` 4.Later historical news will be pushed. 5.What's the reason for sending the XML above。 type='unavailable'
	Unknown commented 5 years ago I had the same problem
	Unknown commented 5 years ago When retrieving larger history from the database it's quite likely that you've triggered Tigase throttling mechanism, which disconnect the user. Please see cm-traffic-throttling for more details. If you want to disable it you can use following configuration: `'cm-traffic-throttling' = 'xmpp:0:0:disc,bin:0:0:disc'`
	Unknown commented 5 years ago Set up 'cm-traffic-throttling' = 'xmpp:0:0:disc,bin:0:0:disc' There will still be 300 group chat history records, but the client can only receive about 200. What's the reason for this ？ Historical messages in the middle will be lost.
	Unknown commented 5 years ago What's the reason for this ？ Please provide more information: what is being lost exacly? Are you still being disconnected? What are the error messages that your client receives (XML stanzas)? If this is MUC history - have you tried changing muc room configuration regarding history length? Check server logs for more details/information about processing.
	Unknown commented 5 years ago MUC history length set to 1000. Tigase mongodb version 3.0.0 In the gethistorymessages method of mongohistoryprovider class, the number of group chat history results obtained from the database is 500, but the client can only receive about 400 group chat histories, and the history of group chat that will be lost is about 100. After the client receives the following XML, there will be no group chat history message. When will the server send the following XML to the client? `<presence xmlns="jabber:client" type="unavailable" from="347f84d9555f407a9a3071261f59d51f@muc.hnmjt.mjt.net/100165" to="100163@hnmjt.mjt.net/nisc_voip"><x xmlns="http://jabber.org/protocol/muc#user"><item role="none" nick="100165" affiliation="member"></item></x></presence>` What do the following server logs mean? What is the cause? 2019-12-04 22:20:43.495 [in_0-message-router] MessageRouter.processPacket() FINEST: 1. Packet will be processed by: sess-man@localhost, from=sess-man@localhost, to=sess-man@localhost, DATA=<message xmlns="jabber:client" type="error" id="6eeba009eeb14fe0b90a1d96fc1df7b8" from="100160@hnmjt.mjt.net/nisc_voip" to="72c6317a7ae64978b58601384711d7a7@muc.hnmjt.mjt.net/100165"><body>CData size: 306</body><delay xmlns="urn:xmpp:delay" from="72c6317a7ae64978b58601384711d7a7@muc.hnmjt.mjt.net" stamp="2019-12-04T14:11:58.027Z"/><error type="wait" code="404"><recipient-unavailable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/><text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" xml:lang="en">CData size: 37</text></error></message>, SIZE=848, XMLNS=jabber:client, PRIORITY=NORMAL, PERMISSION=NONE, TYPE=error
	Unknown commented 5 years ago `<presence xmlns="jabber:client" type="unavailable"…` This one means that client left the room (or was removed) The log entry indicates, that there were some messages pending to be delivered, but the user was not connected. It looks like that for some reason your client still lost connection, but without more information it's hard to investigate it. Are you sure you completely disabled throttling? Would you mind sharing your `etc/config.tdsl` and `etc/config-dump.properties` configuration files? You should review your logs for any signs of user being disconnected (search the logs for all entries with `72c6317a7ae64978b58601384711d7a7@muc.hnmjt.mjt.net/100165`)
	Unknown commented 5 years ago I want to know when the server will disconnect the user. I want to ask which class is disconnected from the user. Here is my configuration. etc/config-dump.properties `etc/config.tdsl`: c2s_port=5222 s2s_port=5269 'config-type' = 'default' debug = [ 'server' ] 'vhost-anonymous-enabled' = false 'default-virtual-host'=hnmjt.mjt.net bosh_connections_5280_type = refuse ws2s_connections_5290_type = refuse c2s_connections_5223_type = refuse s2s_connections_5269_type = refuse 'watchdog-timeout' = 15000 'watchdog-delay' = 30000 c2s_MaxInactiveTime=800000 'cm-traffic-throttling' = 'xmpp:0:0:disc,bin:0:0:disc' 'cm-ht-traffic-throttling' = 'xmpp:0:0:disc,bin:0:0:disc' 'elements-number-limit' = 10000 'max-queue-size' = 1024 dataSource { default () { uri = 'mongodb://127.0.0.1:27017/tigase' } } userRepository { default () { cls = 'tigase.mongodb.MongoRepository' } } authRepository { default () { cls = 'tigase.mongodb.MongoRepository' } } amp { 'amp-repo-class' = 'tigase.mongodb.MongoMsgRepository' 'amp-repo-uri' = 'mongodb://127.0.0.1:27017/tigase' } c2s { seeOtherHost {} 'urn:xmpp:sm:3' () { 'resumption-timeout' = 60 } } muc (class: tigase.muc.MUCComponent) { 'history-db' = 'tigase.mongodb.muc.MongoHistoryProvider' 'history-db-uri' = 'mongodb://127.0.0.1:27017/tigase' } s2s { seeOtherHost {} 'urn:xmpp:sm:3' () { 'resumption-timeout' = 60 } } 'sess-man' () { amp { 'amp-repo-class' = 'tigase.mongodb.MongoMsgRepository' 'amp-repo-uri' = 'mongodb://127.0.0.1:27017/tigase' } 'jabber:iq:register' () { } 'shiku-auto-reply' (class: tigase.olym.OlymAutoReplyPlugin) {} starttls (active: true) {} 'urn:ietf:params:xml:ns:xmpp-sasl' { 'callbackhandler-SCRAM-SHA-1' = 'tigase.auth.impl.ScramCallbackHandler' } }
	Unknown commented 5 years ago Your configuration looks OK, but as I said before: It looks like that for some reason your client still lost connection, but without more information it's hard to investigate it. There are a couple of things that could trigger disconnection and investigating the logs would be the best starting point. You could also try increasing `elements-number-limit` if you are (for some reason) sending large stanzas.
	Unknown commented 5 years ago change max-queue-size=4096 resolved