Tigase XMPP Server Board

Installation and maintenance: How to config to supports large connections in a room.

Wed, 12/14/2016 - 20:02

I use Tsung to do the stress test on Tigase 7.0.4.

From the tsung report, I see the Users-maximum_simultaneous high value is just 800.
Is it means that the Tigase just supports concurrent 800 connections?

The tigase configuration is below:
The etc/init.properties has

--new-connections-throttling=5222:2000

The etc/tigase.conf has

JAVA_OPTIONS="${GC} ${EX} ${ENC} ${DRV} ${JMX_REMOTE_IP} -server -Xms16384M -Xmx16384M "

The tsung scripts as below.
I want to simulate the scene: 30000 connections join in one room with rate 100/sec and send out group chat message.

<?xml version="1.0"?><tsung loglevel="notice" version="1.0"> <clients> <client host="localhost" use_controller_vm="true" maxusers="100000"/> </clients> <servers> <server host="im.swift.com" port="5222" type="tcp"/> </servers> <load> <arrivalphase phase="1" duration="50" unit="minute"> <users maxnumber="30000" interarrival="0.01" unit="second"/> </arrivalphase> </load> <options> <option type="ts_jabber" name="global_number" value="30000"/> <option type="ts_jabber" name="userid_max" value="30000"/> <option type="ts_jabber" name="domain" value="im.swift.com"/> <option type="ts_jabber" name="username" value="test_"/> <option type="ts_jabber" name="passwd" value="test_"/> <option type="ts_jabber" name="muc_service" value="muc.im.swift.com"/> </options> <sessions> <session bidi="true" probability="100" name="jabber-muc" type="ts_jabber"> <request> <jabber type="connect" ack="no_ack"/> </request> <thinktime value="5"/> <transaction name="authenticate"> <request> <jabber type="auth_get" ack="local"/> </request> <request> <jabber type="auth_set_plain" ack="local"/> </request> </transaction> <request> <jabber type="presence:initial" ack="no_ack"/> </request> <thinktime value="2"/> <transaction name="roster"> <request> <jabber type="iq:roster:get" ack="local"/></request> </transaction> <thinktime value="10"/> <setdynvars sourcetype="random_string" length="15"> <var name="nick1"/> </setdynvars> <request subst="true"> <jabber type="muc:join" ack="local" room="room-1" nick="%%_nick1%%_pfm"/> </request> <thinktime value="5"/> <for from="1" to="10" var="i"> <transaction name="online_chat"> <request subst="true"> <jabber type="muc:chat" ack="no_ack" size="16" room="room-1"/> </request> </transaction> </for> <thinktime value="600"/> <transaction name="close"> <request> <jabber type="close" ack="no_ack"/> </request> </transaction> </session> </sessions> </tsung>
Categories: Tigase Forums

API and development: RE: Roster Management

Wed, 12/14/2016 - 17:46

Thank you for your help.

The second solution may not be appropriate for me.

As far as I know, adhoc commands can be use in two cases:
1. Invoked over HTTP REST API. Usually for web client;
2. Accessed via XMPP connection;
Which applies to a plguin in Tigase XMPP Server? Would you please show me the documents about it? Having not found the exact official information.

Thanks again. Best regards.

Categories: Tigase Forums

API and development: RE: Roster Management

Wed, 12/14/2016 - 04:06

If you already consider usage of adhoc commands, you should look at user-roster-management adhoc command which is part of Tigase XMPP Server. It allows Tigase XMPP Server administrators to modify rosters of other users of a server.

Another solution is to connect XMPP client to the same JID which is used in "machine" (you can connect many clients using same BareJID) and process with roster manipulation in this XMPP client - this way roster for XMPP connection from "machine" will be updated as well.

Categories: Tigase Forums

API and development: RE: How can I configure, in order to allow the strophejs through the WSS con...

Wed, 12/14/2016 - 04:03

Is this CA added to list of accepted CA issuers in a browser? If not this will not work as well, as your certificate signed with custom CA will still be invalid for a web browser.

Categories: Tigase Forums

API and development: RE: How can I configure, in order to allow the strophejs through the WSS con...

Wed, 12/14/2016 - 04:00

I use a self signed certificate, I put the root certificate (CA) as default.pem, and then signed a client.pem with the root default.pem, but still not

Categories: Tigase Forums

API and development: RE: How can I configure, in order to allow the strophejs through the WSS con...

Wed, 12/14/2016 - 03:44
Your configuration related to WebSocket and SSL is correct. In logs it is visible that incoming WSS connection was:
  • accepted by server
  • SSL was started
  • connection was stopped (most likely by client)

There is no clear indication that something is wrong on Tigase XMPP Server side, but as you mentioned use of strohpejs, I assume that you are using web browser to establish connection to Tigase XMPP Server using WSS. In this case it is a little tricky as you need to have a valid SSL certificate issued for domain in your WSS URL - (in this case it is hostname). And this certificate needs to be installed in Tigase XMPP Server as a "default" SSL certificate or SSL certificate for domain matching passed hostname. In other case web browsers silently drop insecure WSS connections without any meaningful errors.

Categories: Tigase Forums

API and development: How can I configure, in order to allow the strophejs through the WSS connect...

Wed, 12/14/2016 - 03:27

Hello!
I use the strohpejs, ws://hostname:5290 through the tigase-v7.1.0 can be connected to the normal, but I can not be replaced by wss://hostname:5291, and my configuration is as follows:

ws2s/connections/ports[i]=5290,5291
ws2s/connections/5291/socket=ssl
ws2s/connections/5291/type=accept

the log is as follows:

...
2016-12-14 19:04:26.148 [scheduler_pool-5-thread-1-c2s] ConnectionManager$1.run() FINE: Reconnecting service for component: c2s, to remote host: localhost on port: 5222
2016-12-14 19:04:26.149 [scheduler_pool-5-thread-1-c2s] ConnectionManager$1.run() FINE: Reconnecting service for component: c2s, to remote host: localhost on port: 5223
2016-12-14 19:04:26.151 [scheduler_pool-4-thread-1-bosh] ConnectionManager$1.run() FINE: Reconnecting service for component: bosh, to remote host: localhost on port: 5280
2016-12-14 19:04:26.151 [scheduler_pool-15-thread-1-ws2s] ConnectionManager$1.run() FINE: Reconnecting service for component: ws2s, to remote host: localhost on port: 5291
2016-12-14 19:04:26.151 [scheduler_pool-15-thread-2-ws2s] ConnectionManager$1.run() FINE: Reconnecting service for component: ws2s, to remote host: localhost on port: 5290
2016-12-14 19:04:26.199 [scheduler_pool-11-thread-1-s2s] ConnectionManager$1.run() FINE: Reconnecting service for component: s2s, to remote host: localhost on port: 5269
2016-12-14 19:04:26.755 [ConnectionOpenThread] ConnectionManager$ConnectionListenerImpl.accept() FINEST: Accept called for service: null@null, port_props: {type=accept, socket=ssl, ifc=[Ljava.lang.String;@3aacf32a, remote-host=localhost, required=false, port-no=5291}
2016-12-14 19:04:26.852 [ConnectionOpenThread] TLSWrapper.<clinit>() CONFIG: Supported protocols: ()SSLv2Hello,()SSLv3,()TLSv1,()TLSv1.1,()TLSv1.2
2016-12-14 19:04:26.855 [ConnectionOpenThread] TLSWrapper.<clinit>() CONFIG: Supported ciphers: ()TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,()TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,()TLS_RSA_WITH_AES_128_CBC_SHA256,()TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,()TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,()TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,()TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,()TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,()TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,()TLS_RSA_WITH_AES_128_CBC_SHA,()TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,()TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,()TLS_DHE_RSA_WITH_AES_128_CBC_SHA,()TLS_DHE_DSS_WITH_AES_128_CBC_SHA,()TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,()TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,()TLS_RSA_WITH_AES_128_GCM_SHA256,()TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,()TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,()TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,()TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,()TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,()TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,()SSL_RSA_WITH_3DES_EDE_CBC_SHA,()TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,()TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,()SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,()SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,(+)TLS_EMPTY_RENEGOTIATION_INFO_SCSV,()TLS_DH_anon_WITH_AES_128_GCM_SHA256,()TLS_DH_anon_WITH_AES_128_CBC_SHA256,()TLS_ECDH_anon_WITH_AES_128_CBC_SHA,()TLS_DH_anon_WITH_AES_128_CBC_SHA,()TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA,()SSL_DH_anon_WITH_3DES_EDE_CBC_SHA,()SSL_RSA_WITH_DES_CBC_SHA,()SSL_DHE_RSA_WITH_DES_CBC_SHA,()SSL_DHE_DSS_WITH_DES_CBC_SHA,()SSL_DH_anon_WITH_DES_CBC_SHA,()SSL_RSA_EXPORT_WITH_DES40_CBC_SHA,()SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA,()SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA,()SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA,()TLS_RSA_WITH_NULL_SHA256,()TLS_ECDHE_ECDSA_WITH_NULL_SHA,()TLS_ECDHE_RSA_WITH_NULL_SHA,()SSL_RSA_WITH_NULL_SHA,()TLS_ECDH_ECDSA_WITH_NULL_SHA,()TLS_ECDH_RSA_WITH_NULL_SHA,()TLS_ECDH_anon_WITH_NULL_SHA,()SSL_RSA_WITH_NULL_MD5,()TLS_KRB5_WITH_3DES_EDE_CBC_SHA,()TLS_KRB5_WITH_3DES_EDE_CBC_MD5,()TLS_KRB5_WITH_DES_CBC_SHA,()TLS_KRB5_WITH_DES_CBC_MD5,()TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA,(-)TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
2016-12-14 19:04:26.855 [ConnectionOpenThread] TLSWrapper.<clinit>() CONFIG: Hardened mode is disabled
2016-12-14 19:04:26.855 [ConnectionOpenThread] TLSWrapper.<clinit>() CONFIG: Enabled protocols: default
2016-12-14 19:04:26.855 [ConnectionOpenThread] TLSWrapper.<clinit>() CONFIG: Enabled ciphers: default
2016-12-14 19:04:26.857 [ConnectionOpenThread] ConnectionManager.serviceStarted() FINER: ws2s Connection started: null, type: accept, Socket: TLS: nullSocket[addr=/192.168.2.58,port=51771,localport=5291], jid: null
2016-12-14 19:04:26.870 [ConnectionOpenThread] SocketThread.<clinit>() WARNING: 17 socketReadThreads started.
2016-12-14 19:04:26.881 [ConnectionOpenThread] SocketThread.<clinit>() WARNING: 17 socketWriteThreads started.
2016-12-14 19:04:26.885 [pool-16-thread-1] IOUtil.<clinit>() CONFIG: using direct byte buffers with size 8,192 per buffer
2016-12-14 19:04:26.927 [pool-16-thread-2] ClientConnectionManager.sendTlsHandshakeCompletedToSessionManager() FINEST: Handshake complete. No session-id. Command not sent.
2016-12-14 19:04:26.931 [pool-16-thread-3] ConnectionManager.serviceStopped() FINER: ws2s Connection stopped: ws2s@zxh/192.168.2.58_5291_192.168.2.58_51771, type: accept, Socket: TLS: ws2s@zxh/192.168.2.58_5291_192.168.2.58_51771 Socket[unconnected], jid: null
2016-12-14 19:04:26.931 [pool-16-thread-3] ClientConnectionManager.xmppStreamClosed() FINER: Stream closed: ws2s@zxh/192.168.2.58_5291_192.168.2.58_51771
2016-12-14 19:16:51.530 [ConnectionOpenThread] ConnectionManager$ConnectionListenerImpl.accept() FINEST: Accept called for service: null@null, port_props: {type=accept, socket=ssl, ifc=[Ljava.lang.String;@3aacf32a, remote-host=localhost, required=false, port-no=5291}
2016-12-14 19:16:51.533 [ConnectionOpenThread] ConnectionManager.serviceStarted() FINER: ws2s Connection started: null, type: accept, Socket: TLS: nullSocket[addr=/192.168.2.58,port=52710,localport=5291], jid: null
2016-12-14 19:16:51.568 [pool-16-thread-5] ClientConnectionManager.sendTlsHandshakeCompletedToSessionManager() FINEST: Handshake complete. No session-id. Command not sent.
2016-12-14 19:16:51.576 [pool-16-thread-6] ConnectionManager.serviceStopped() FINER: ws2s Connection stopped: ws2s@zxh/192.168.2.58_5291_192.168.2.58_52710, type: accept, Socket: TLS: ws2s@zxh/192.168.2.58_5291_192.168.2.58_52710 Socket[unconnected], jid: null
2016-12-14 19:16:51.576 [pool-16-thread-6] ClientConnectionManager.xmppStreamClosed() FINER: Stream closed: ws2s@zxh/192.168.2.58_5291_192.168.2.58_52710
...

Categories: Tigase Forums

API and development: RE: Message goes to offline storage before being delivered

Sat, 12/10/2016 - 10:34

The sleep I put into OfflineMessages.process right before results.addAll seems to be avoiding message loss. I'll keep you posted if it happens again. In the meanwhile I'll send you the patch for the StampComparator.

Categories: Tigase Forums

API and development: RE: Message goes to offline storage before being delivered

Sat, 12/10/2016 - 09:39

I found the source of the wrong delivery issue. It's caused by OfflineMessages.StampComparator. It's ignoring urn:xmpp:delay element. I'll send a patch to you via issue tracking later.

In the meanwhile I'm doing some more tests with that code fixed to see if messages disappear again. But I doubt it is related to the wrong order issue per se. I'll keep you posted.

Categories: Tigase Forums

API and development: RE: Message goes to offline storage before being delivered

Sat, 12/10/2016 - 08:58

I'm doing some hacks on Tigase code... if I add a piece of code like this just before queueing messages from storage:

if (session.getPresence() == null || session.getPriority() <= 0) { try { Thread.sleep(500); } catch (InterruptedException ignored) { } }

I made the recipient client ignore SM ack and disconnect abruptly so those messages would always fail and go back to storage.
With my patch, messages are always delivered, but sometimes the first one (the one that previously "skipped" the connection) is delivered last in the sequence. However, when that happens, the first message will remain the last, because message timestamps have changed and reset to that delivery time. And this ends up in storage, so at next connection order will be 2, 3, 1.
A few more tries and message 2 disappears.
More tries will show messages 1 and 3 being delivered at apparently random order each time.

I'm going to analyze this more thoroghly, but if you have any hint or pointers please share them.

Categories: Tigase Forums

API and development: RE: Message goes to offline storage before being delivered

Sat, 12/10/2016 - 07:33

Sorry, got the wrong logs. I've edited my post with the correct findings.

Categories: Tigase Forums

API and development: Message goes to offline storage before being delivered

Sat, 12/10/2016 - 07:16

Hello,
I occasionally bump into this strange issue while connecting with a client and getting stored messages from the OfflineMessages plugin:

2016-12-10 13:56:20.909 [in_0-sess-man] SessionManager.walk() FINEST: XMPPProcessorIfc: Message (message)Request: from=sess-man@notebook.casaricci.it, to=sess-man@notebook.casaricci.it, DATA=<message id="KQsQ1zfYMmnj2O8na9J9cxXLepQxM3" xmlns="jabber:client" to="d96b6d3ba60e3714e98a094990bb6275e83ab46b@prime.kontalk.net" type="chat" from="4bdd4f929f3a1062253e4e496bafba0bdfb5db75@prime.kontalk.net/aa3bb802b8c777f6"><body>1</body><active xmlns="http://jabber.org/protocol/chatstates"/><request xmlns="urn:xmpp:receipts"/><delay xmlns="urn:xmpp:delay" stamp="2016-12-10T12:56:11.038Z" from="prime.kontalk.net">Offline Storage - notebook.casaricci.it</delay></message>, SIZE=476, XMLNS=jabber:client, PRIORITY=NORMAL, PERMISSION=AUTH, TYPE=chat, conn: XMPPResourceConnection=[user_jid=d96b6d3ba60e3714e98a094990bb6275e83ab46b@prime.kontalk.net/6b8a44278cd80d72, packets=11, connectioId=c2s@notebook.casaricci.it/127.0.0.1_5222_127.0.0.1_41278, domain=prime.kontalk.net, authState=AUTHORIZED, isAnon=false, isTmp=false, parentSession hash=164113115, parentSession liveTime=207] 2016-12-10 13:56:20.909 [in_0-sess-man] OfflineMessages.savePacketForOffLineUser() FINEST: Storing packet for offline user: from=sess-man@notebook.casaricci.it, to=sess-man@notebook.casaricci.it, DATA=<message id="KQsQ1zfYMmnj2O8na9J9cxXLepQxM3" xmlns="jabber:client" to="d96b6d3ba60e3714e98a094990bb6275e83ab46b@prime.kontalk.net" type="chat" from="4bdd4f929f3a1062253e4e496bafba0bdfb5db75@prime.kontalk.net/aa3bb802b8c777f6"><body>1</body><active xmlns="http://jabber.org/protocol/chatstates"/><request xmlns="urn:xmpp:receipts"/><delay xmlns="urn:xmpp:delay" stamp="2016-12-10T12:56:11.038Z" from="prime.kontalk.net">Offline Storage - notebook.casaricci.it</delay></message>, SIZE=476, XMLNS=jabber:client, PRIORITY=NORMAL, PERMISSION=AUTH, TYPE=chat 2016-12-10 13:56:20.910 [message Queue Worker 0] Message.process() FINEST: Processing packet: from=sess-man@notebook.casaricci.it, to=sess-man@notebook.casaricci.it, DATA=<message id="KQsQ1zfYMmnj2O8na9J9cxXLepQxM3" xmlns="jabber:client" to="d96b6d3ba60e3714e98a094990bb6275e83ab46b@prime.kontalk.net" type="chat" from="4bdd4f929f3a1062253e4e496bafba0bdfb5db75@prime.kontalk.net/aa3bb802b8c777f6"><body>1</body><active xmlns="http://jabber.org/protocol/chatstates"/><request xmlns="urn:xmpp:receipts"/><delay xmlns="urn:xmpp:delay" stamp="2016-12-10T12:56:11.038Z" from="prime.kontalk.net">Offline Storage - notebook.casaricci.it</delay></message>, SIZE=476, XMLNS=jabber:client, PRIORITY=NORMAL, PERMISSION=AUTH, TYPE=chat, for session: XMPPResourceConnection=[user_jid=d96b6d3ba60e3714e98a094990bb6275e83ab46b@prime.kontalk.net/6b8a44278cd80d72, packets=11, connectioId=c2s@notebook.casaricci.it/127.0.0.1_5222_127.0.0.1_41278, domain=prime.kontalk.net, authState=AUTHORIZED, isAnon=false, isTmp=false, parentSession hash=164113115, parentSession liveTime=208] 2016-12-10 13:56:20.910 [message Queue Worker 0] Message.process() FINEST: Message to this user, packet: from=sess-man@notebook.casaricci.it, to=sess-man@notebook.casaricci.it, DATA=<message id="KQsQ1zfYMmnj2O8na9J9cxXLepQxM3" xmlns="jabber:client" to="d96b6d3ba60e3714e98a094990bb6275e83ab46b@prime.kontalk.net" type="chat" from="4bdd4f929f3a1062253e4e496bafba0bdfb5db75@prime.kontalk.net/aa3bb802b8c777f6"><body>1</body><active xmlns="http://jabber.org/protocol/chatstates"/><request xmlns="urn:xmpp:receipts"/><delay xmlns="urn:xmpp:delay" stamp="2016-12-10T12:56:11.038Z" from="prime.kontalk.net">Offline Storage - notebook.casaricci.it</delay></message>, SIZE=476, XMLNS=jabber:client, PRIORITY=NORMAL, PERMISSION=AUTH, TYPE=chat, for session: XMPPResourceConnection=[user_jid=d96b6d3ba60e3714e98a094990bb6275e83ab46b@prime.kontalk.net/6b8a44278cd80d72, packets=11, connectioId=c2s@notebook.casaricci.it/127.0.0.1_5222_127.0.0.1_41278, domain=prime.kontalk.net, authState=AUTHORIZED, isAnon=false, isTmp=false, parentSession hash=164113115, parentSession liveTime=208] 2016-12-10 13:56:20.910 [message Queue Worker 0] Message.getConnectionsForMessageDelivery() FINEST: Out of: 1 total connections, only: 0 have non-negative priority

The message just "skips" this connection and goes to offline storage. It will be delivered on the next connection. This results in wrong delivery order (in a block of three messages, for example, only the second and the third initially went through).

I can't reproduce it constantly, it happens once in a while, so I couldn't find the cause. I noticed this:

2016-12-10 13:56:20.910 [message Queue Worker 0] Message.getConnectionsForMessageDelivery() FINEST: Out of: 1 total connections, only: 0 have non-negative priority

So I asked myself: has the client already sent its initial presence? Yes it did, a few milliseconds before:

2016-12-10 13:56:20.891 [in_21-sess-man] SessionManager.processPacket() FINEST: Received packet: from=c2s@notebook.casaricci.it/127.0.0.1_5222_127.0.0.1_41278, to=sess-man@notebook.casaricci.it, DATA=<presence id="0I70q-73" xmlns="jabber:client"><c xmlns="http://jabber.org/protocol/caps" hash="sha-1" ver="none" node="http://www.kontalk.org/"/></presence>, SIZE=156, XMLNS=jabber:client, PRIORITY=PRESENCE, PERMISSION=NONE, TYPE=null

Is it possible that 19 ms aren't enough for Message.getConnectionsForMessageDelivery() to rely on the latest presence information? Isn't it strange that Message.process comes after OfflineMessages.postProcess anyway?

Just out of clarity, a few more milliseconds later, after processing some more requests from the client (mainly service discovery and roster presence) the other two messages from storage are delivered:

2016-12-10 13:56:20.931 [in_0-sess-man] SessionManager.processPacket() FINEST: Received packet: from=sess-man@notebook.casaricci.it, to=null, DATA=<message id="8Z0lZWy15aC732vryKPPsoS38ROQ1f" xmlns="jabber:client" to="d96b6d3ba60e3714e98a094990bb6275e83ab46b@prime.kontalk.net" type="chat" from="4bdd4f929f3a1062253e4e496bafba0bdfb5db75@prime.kontalk.net/aa3bb802b8c777f6"><body>2</body><active xmlns="http://jabber.org/protocol/chatstates"/><request xmlns="urn:xmpp:receipts"/><delay xmlns="urn:xmpp:delay" stamp="2016-12-10T12:56:12.238Z" from="prime.kontalk.net">CData size: 39</delay></message>, SIZE=476, XMLNS=jabber:client, PRIORITY=NORMAL, PERMISSION=AUTH, TYPE=chat ... 2016-12-10 13:56:20.933 [in_0-sess-man] SessionManager.processPacket() FINEST: Received packet: from=sess-man@notebook.casaricci.it, to=null, DATA=<message id="VXZ0mcZKUtlIA55khlSQo79rH5u7NU" xmlns="jabber:client" to="d96b6d3ba60e3714e98a094990bb6275e83ab46b@prime.kontalk.net" type="chat" from="4bdd4f929f3a1062253e4e496bafba0bdfb5db75@prime.kontalk.net/aa3bb802b8c777f6"><body>3</body><active xmlns="http://jabber.org/protocol/chatstates"/><request xmlns="urn:xmpp:receipts"/><delay xmlns="urn:xmpp:delay" stamp="2016-12-10T12:56:13.582Z" from="prime.kontalk.net">CData size: 39</delay></message>, SIZE=476, XMLNS=jabber:client, PRIORITY=NORMAL, PERMISSION=AUTH, TYPE=chat

I'm using the latest release branch (but it's been happening for months now).

Thanks for your help

Categories: Tigase Forums

API and development: RE: Roster Management

Fri, 12/09/2016 - 18:17

Glad to receive your reply.

Oh, it's bad news. The case is B is a machine which has an xmpp account, C is B's administrator, and C wants to share B to A. So that A can also contact with B. You know, as a machine like B, it's complicated for it to go through the process of subscription in xmpp.

There is another way after searching the topics. Maybe i could use admin ad-hoc command to sync the modification between in cache and db. Is it possible?

Or other ways in your opinion?

Thanks very much.

Categories: Tigase Forums

API and development: RE: Roster Management

Fri, 12/09/2016 - 11:58

This is intentional and limitation of plugin API - from one user session it's not possible to access other user data. What is exactly the use case here? Why do you want to control subscription with unrelated JID (user C)? Maybe there is other way to achieve your end result?

Categories: Tigase Forums

API and development: RE: Roster Management

Fri, 12/09/2016 - 02:43

Well, I found you mentioned in this topic(https://projects.tigase.org/boards/4/topics/6971), using tigase.xmpp.impl.Presence.getRosterUtil(). We could only get the session owner's roster. How about others' roster? Thanks.

Categories: Tigase Forums

Installation and maintenance: Where can I get the project source file : tigase-server-7.1.0

Wed, 12/07/2016 - 04:38

I want to get the project source file : tigase-server-7.1.0,but I can't find the url.

Where can I get the source file?
Thanks very much!

Categories: Tigase Forums

API and development: Roster Management

Tue, 12/06/2016 - 03:31

Hi,
Thank you for your time. I want to make A and B to be friends(subs=both in tig_pairs) when tigase receiving a message from C. I think I could modify A and B's rosters in db directly and then notify them. But how could I get A'roster in a class (implements XMPPProcessorIfc)'s process? Or anything help will be appriciated.

Categories: Tigase Forums

API and development: RE: [ASK] Client Library For Swift

Mon, 12/05/2016 - 19:26

Can't wait ..
Thank you

Categories: Tigase Forums

Pages

Get in touch

We provide software products, consulting and custom development services

Tigase, Inc.
100 Pine Street, Suite 1250
San Francisco, CA 94111, USA
Phone: (415) 315 9771

Follow us on:

Twitter

Back to Top