Server appears to drop client session (sends 'unavailable')


Openfire appears to be terminating sessions that are not expected to be terminated. The associated client receives an unavailable session from its own full JID. This leads the client to believe that it's disconnected.

Problems seem to have started with the introduction of Stream Management () and appears to affect clients that support that feature only (Conversations, Dino).




Geofferey Eakins
September 24, 2018, 2:21 AM

I too experience client disconnections when the idle disconnect policy is enabled on 4.2.3 no matter the value. It seems OpenFire is not getting a reply from client(s) causing it to unnecessarily  terminate the connection. When that happens Conversations client will no longer recieve messages even tho it thinks it's connected. A double whammy. Stream manament is broken as well. I tested stream manangement by switching connections right before sending message to user in simulated condition.  After switching messages are never received. These issues did not exist in 4.2.1. I reverted back to 4.2.1 and everything went back to normal. Clients do not get disconnected and stream management seems to function properly .

July 26, 2018, 3:23 AM

I think in last sentence you meant "not to be disconnected". If there is no ping, Openfire shouldn't disconnect anything.

Guus der Kinderen
July 25, 2018, 10:11 PM

The issue appears to be triggered by a periodic check that Openfire performs on idle connections. On such connections, an XMPP ping is sent. These requests placed directly on the connection, instead of being routed through the Openfire LocalSession. This causes the Stream Management implementation to miss them, which leads to the sync issues and disconnects.

With this knowledge, I can easily reproduce the problem by setting the maximum allowed client idle time to a low value using the xmpp.client.idle property (say 5000ms), and write a simple client that sends data at a larger interval (say, a message every 10 seconds).

To alleviate the problem, the idle check can be disabled by setting the property to false. Note that this might cause idle clients to_not_ be disconnected. (edited, thanks wroot).

Rob Purcell
April 16, 2018, 9:46 PM

This issue effects the recently released Windows version 1.0.1 of Gajim which supports stream management, causing frequent disconnects. Changing did not help, but setting to 'false" resolved the disconnect issue.

April 7, 2018, 12:44 AM

Maybe that's a workaround:


Don't use * 'false'* 

rather * '0'*

The default value of *requestFrequency* is '5'

You can leave * 'true'* 

So far this works for me.

Your pinned fields
Click on the next to a field label to start pinning.


Dave Cridland


Guus der Kinderen