Uploaded image for project: 'Openfire'
  1. Openfire
  2. OF-341

Openfire shouldn't close idle client connections unconditionally.



    • Type: New Feature
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 3.6.4
    • Fix Version/s: None
    • Component/s: Connection Manager, Core
    • Labels:


      Openfire will remove client connections after a configurable amount of time has passed, in which no network IO has occurred. This is intended to remove dead clients. Clients can prevent being disconnected by sending data, such as whitespace characters.

      There is no such requirement in the XMPP specifications. XMPP entities should be allowed to remain idle for whatever amount of time they like.

      Instead, Openfire should probe connections, to see if they are alive. XMPP Ping requests can be send to the remote entity, for example. The entity should either respond with an error or result - any of these will cause the idle count to be reset, preventing the connection from being closed. If entities do not respond (and do not send whitespace pings) their connection can be considered stale.

      Related discussion in the JDev MUC on 1/29/2010 (timestamps are CET):

      (10:49:28 PM) MattJ: and the idleness issue is simply... after 6 minutes of sending nothing, clients get disconnected
      (10:49:51 PM) MattJ: Obviously it might be desirable to disconnect dead clients, but using XMPP ping to look for them first would probably be better
      (10:50:26 PM) MattJ: Don't worry, Pidgin/Adium (used to|does) the same
      (10:50:43 PM) guus: regarding idleness: Openfire expects clients to send whitespace pings at the very least.
      (10:50:53 PM) MattJ: Ok, well I think that's wrong
      (10:51:04 PM) MattJ: Nothing in the spec requires sending whitespace
      (10:51:13 PM) dwd: guus, No, clients can (and should) remain silent unless they have things to send.
      (10:51:15 PM) guus: doing a ping makes sense
      (10:51:44 PM) guus: I'll have a look, see how hard it'd be to put that in




            • Assignee:
              guus Guus der Kinderen
              guus Guus der Kinderen
            • Votes:
              2 Vote for this issue
              10 Start watching this issue


              • Created: