Openfire shouldn't close idle client connections unconditionally.

Description

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

Environment

None

Activity

Show:
Guus der Kinderen
October 22, 2015, 3:22 PM

What remains to be done here is update the Connection Manager - but that codebase is so behind in a lot of places, that keeping this issue open just for that is no longer relevant.

Daryl Herzmann
October 22, 2015, 1:32 PM

Hi Guus, Is this issue still valid?

Daryl Herzmann
February 14, 2014, 9:52 PM

Anybody comment on this ticket's status for the current release? Is the update to the connection manager all that is awaiting before resolution?

Guus der Kinderen
February 6, 2013, 7:57 PM

Removing the 'fix version' for all unresolved issues that were scheduled for version 7.8.2. We're releasing this version today - the remaining issues should be rescheduled later.

Guenther Niess
February 2, 2010, 3:38 AM

I just see now that the connection manager is also branched for the new beta version, should this feature be also included there?

Fixed

Assignee

Guus der Kinderen

Reporter

Guus der Kinderen