powered by Jive Software

Openfire Component Session Times out at 6 minutes


#1

I have a component session that times out at the 6 minute mark of no activity.

Is there an Openfire setting that I can change to extend this timeout or is there a suggested line of code that I can put into the component as a ‘keep alive’?

version Openfire 4.2.3

debug message

  • Firing a SESSION_IDLE event for session 14
  • ConnectionHandler: Closing connection that has been idle

#2

Is this a component based on our Whack library?

From the top of my head, I’d expect a couple of mechanisms to prevent this from happening:

  • white-space pings that are sent at a regular interval from Whack to Openfire (although I’m not 100% sure this is implemented in Whack
  • A XEP-0199: XMPP Ping sent by Openfire to the component, before it disconnects it. Even if the component does not support XEP-0199, it’s expected to return an error, which is a sign of life. This mechanism is used to determine if client sessions are still active, and might also be applicable to external components - but again, I’m not sure.
  • finally, you can override the default idle timeout by setting xmpp.component.idle - use a value of 0 (zero) to disable the functionality, but be aware that this can introduce problems when your component did indeed die unexpectedly, and the session had to be cleaned up.

#3

I am not a developer, just the end user, so don’t have all the technical answers, but will answer what I can : )

No - it it not based on Whack. It is a 3rd party (not mine) that I can manipulate a bit, but not much, and I don’t think it is coded to reply to any idle session queries, so I guess the XMPP server would have no reason not to time it out.

  • I did not want to override the default idle in case it created a false positive or other issues as you mentioned.

We did get it to work as needed from the ‘keep alive’ point of view.

The component sends a ping request to the XMPP server at X interval (under 6 minutes) with some non-exsistent endpoints such as:

  • XMPP SENDING: “<” iq from=‘component@example.weather.com/conference@example.weather.com’ id=‘component’ to=‘conference.example.weather.com’ type=‘get’></iq “>”
    and it works.
    The XMPP server logs it with “unable to create socket” warnings and “unable to create session” info, but it has the desired effect of keeping the connection active.

So, it works - not the cleanest via the logs or in getting valid responses - but ‘yay’ as far as functionality.


#4

Ah, you’re on the right track with sending that ping request. Note that the component itself is a valid endpoint, as is the XMPP server / XMPP domain. On top of that, you can send an XMPP-valid “ping”, by adding one extra element, that can be hard-coded.

Combining all this, you can make your solution more robust (and pollute the error logs less), by making your component send this request, instead of what you’re doing now, periodically.

<iq from='example.weather.com' to='weather.com' id='s2c1' type='get'>
  <ping xmlns='urn:xmpp:ping'/>
</iq>

No need to worry about the newlines or whitespace - that’s just added for clarity. For bonus points, make sure that the value of the ‘id’ attribute is different every time. Some increment or random will do.