powered by Jive Software

Overcoming chat sync issues with concurrent XMPP sessions


I switched from the Google-hosted Gtalk service to Openfire in hopes I could overcome the problems described here: http://tinyurl.com/powzq8f

Server: I installed Openfire 3.8.2 on Ubuntu 12.04.3 LTS. Openfire is configured to use MySQL. The server hardware has 16GB RAM, 64 bit Intel i7-3770K CPU @ 3.50GHz. There is very little running on this box just yet with Openfire and MySQL databases being the primary applications. Outside of Openfire, there are a handful of small MySQL tables. Under Openfire->Server Settings->Client Connections I have selected “Do not disconnect clients that are idle” and “Send an XMPP Ping request to idle clients.”

Clients: I asked a friend of mine to help me test Openfire with a few different XMPP clients, including Spark 2.6.3. The tests were done on a Mac running OS X 10.9 (Mavericks) and two Win 7 PC’s. The resource was set to be different on each one, and only two user names were created in Openfire. All are wired connections, no WiFi. The testing was rigorous and idle times were minimal. These are always-on PCs and never sleep or hibernate. All sockets between Openfire and the clients are over the LAN; no inbound WAN connections. Only text chat messages were exchanged; no file transfers.

I was very surprised to experience during Openfire testing the same issue described at the URL above, and this was with only TWO active users. For the last few hours of testing, we used only the Spark client.

Is there some Openfire setting I can change to make the concurrent sessions more robust? Syncing of the chat sessions was very intermittent.

Is there some setting in Spark that could be adjusted as well?

What you are seeing is one of the two accepted behaviours according to the spec. To enable the other (which is what you want), read this thread.

Hi @rcollier, thanks for getting back to me. Sorry for the stupid question but what exactly are the “two accepted behaviours”? I’ve read the link to the thread you included but I’m quite confused as it seems to me like there’s only the one behaviour I’m asking about – I just want messages to reliably appear on all connected clients. Can you clarify?

The default behaviour is what you are seeing now. The server will only deliver the message to a single client with the highest priority. If there are multiple with the same highest priority, then the server determines which one to send it to, which I would guess is the last one to connect.

The other behaviour (which you want) requires the setting of the property defined in that thread so the message is delivered to all cllients with the same highest priority. If they are different prioirities, then only the highest one will get the message.