Server appears to drop client session (sends 'unavailable')
Description
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).
Environment
Activity
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 .
I think in last sentence you meant "not to be disconnected". If there is no ping, Openfire shouldn't disconnect anything.
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 xmpp.client.idle.ping property to false. Note that this might cause idle clients to_not_ be disconnected. (edited, thanks wroot).
This issue effects the recently released Windows version 1.0.1 of Gajim which supports stream management, causing frequent disconnects. Changing stream.management.requestFrequency did not help, but setting stream.management.active to 'false" resolved the disconnect issue.
Maybe that's a workaround:
Don't use *stream.management.active 'false'*
rather *stream.management.requestFrequency '0'*
The default value of *requestFrequency* is '5'
You can leave *stream.management.active 'true'*
So far this works for me.