Tigase Presence Issue

John Catron
Added about 5 years ago

Hello we are on Tigase 5.2 Final release.

We are having an issue where our logs are being flooded with the following:

2014-03-03 16:14:32.511 [out_70-cl-comp]   SessionManager.getXMPPResourceConnection()  INFO: Message without TO attribute set, don't know what to do wih this: from=null, to=null, DATA=<presence xmlns="jabber:client" from=""><show>chat</show><status>Available</status><priority>1</priority></presence>, SIZE=156, XMLNS=jabber:client, PRIORITY=PRESENCE, PERMISSION=NONE, TYPE=null

We get these a ton in the logs but when we look up the RFC presence packets are meant to not have a 'to' attribute:

the initial presence stanza (1) MUST possess no 'to' address (signalling that it is meant to be broadcasted by the server on behalf of the client)

After sending initial presence, the user MAY update its presence information for broadcasting at any time during its session by sending a presence stanza with no 'to' address and either no 'type' attribute or a 'type' attribute with a value of "unavailable". ( RFC 3921 5.1.1,5.1.2)

What can we do to get rid of this in our logs? Is there something wrong with our presence packet that we aren't understanding or ???

Replies (10)

Added by Wojciech Kapcia TigaseTeam about 5 years ago

You are correct - when sending initial presence to attribute is not needed (btw. RFC1921 was made obsolete by RFC1621). Could you share your configuration files? Could you share full logs?

It seems you are using clustering and this particular entry comes from thread processing packets in clustering component.

Added by Sean Drummond about 5 years ago

I have attached our configuration and two samples of the INFO messages we are receiving. I get two entries on each clustered server each time a user logs in or changes their status.


Added by Artur Hefczyc TigaseTeam about 5 years ago

Tigase processes packets without "to" attribute correctly. The log message attached means that there is a packet sent from a user's client for which there is no user session associated anymore. This usually happens in 2 situations:

  1. Mass users disconnect

  2. System overload

In both cases a long queue of packets waiting for processing is forming, especially presence packet. So, what happens, is a packet is waiting in a queue, in the mean time the connection is closed for some reason and user's session is destroyed. But after that, the presence packet arrives and the Tigase cannot process it, so it is dropped. But this is completely normal and correct. As presence packets are stored in separate queues with the lowest processing priority, it may happen they are processed with a significant delay.

You should check whether this happens at mass user disconnection only (after a load test is over for example?) or this is a production system that is overloaded.

I suggest you remove this line from config file:

--sm-threads-pool = custom:300

unless you have a very good reason to put it there. This impacts your server performance and is only required in very rare cases.

Line is not necessary in this version of the Tigase XMPP Server and I suggest to remove it:


Added by John Catron about 5 years ago

We have tried removing both of those values to no avail.

We also haven't noticed any mass disconnects or system overload. In fact we usually only have 10 or so people online when testing this presence issue and we receive it on every login and every presence update. It seems to be limited to WebSockets thus far. When we connect over 5222 with an external client we don't get those messages. Is it possible there is an issue with WebSocket parsing OR there is something we need to do differently on the front-end to handle WebSocket presence that we aren't doing?


Added by Artur Hefczyc TigaseTeam about 5 years ago

What kind of software do you use for Websockets on the client side? The thing is that websockets support is quite new in Tigase, based on some unfinished specs, so it is very likely not everything works as expected. We were only able to test websockets in the Tigase server against our own JaXMPP client library and that works fine.

However, XSF just released a new XEP for websockets which is totally incompatible with our implementation, so we plan to redo the work on web sockets.

Therefore, your input and problems you report about websockets are very valuable to us as it can help us improve it and correct any problems it may have.

Added by Parth Jagodara about 5 years ago

We are primarily using firefox and chrome for websocket connections. We use a javascript client side library called JSJAC. Here is the source code:

Another similar issue we are having is We are not sure if the root cause is the same or not. But we have had these issues using websocket with latest version of tigase.


Added by Artur Hefczyc TigaseTeam about 5 years ago

After closely inspecting the log entry you provided, it looks like I may know what the problem is here. Apparently your client sets from attribute in packets is sends out. We have just found a few weeks ago a bug in the clustering which prevented such packets from being processed correctly in some cases. As very few clients set from attribute in packets we did not notice this problem before.

There is one more thing which confuses me a bit. You say they your logs are flooded with entries like you gave us above but also that you have about 10 users on the installation. This concerns me, how 10 users can flood the server with packets/log entries like this.

In any way Wojciech will back online in a few hours and he will follow up on this and he will be able to confirm whether the problem is related to from attribute processing in the cluster mode and if yes, how to obtain a code with a fix.

Added by John Catron about 5 years ago

Ah I see the confusion. The other post where we mention having 10 users was in one of our test environments. It has the same setup but a significantly smaller userbase. Our real installation currently has ~100 and will have several thousands whenever we feel it is ready for production.

So 'Flooding the logs' was a bit of an exaggeration but it was represented as being able to flood because once we have thousands that will be virtually the only log entry since there are 2, per server, per user, per status change :/

@Wojciech let me know if you think it is the From attribute we can attempt to un-set that and see if that alleviates our problem.

Added by John Catron about 5 years ago

Hey Artur just wanted to give you an update on this one we removed the from attribute on our presence packets and that did indeed fix the log messages. Wanted to thank you very much for the help on that we were very worried about receiving 2 of those log entries per server per status change. Now it appears they are gone so we are able to continue on without worry on this particular issue. Thanks for the help!


Added by Artur Hefczyc TigaseTeam about 5 years ago

Thank you for checking this. Unfortunately Wojciech was busy for last few days, hence delays with responding to the topic. I am glad you confirmed that this is related to the "from" address, as we have already encountered the problem and it is most likely fixed. Wojciech will provide you details on how to get the fix if it is ready yet.