Openfire has support for XEP-0198: Stream Management. This feature allows for stanza acknowledgement and session resumption (for example, after a network interruption).
Various people, including client devs, have reported issues with stream resumption in Openfire 4.8.0. The reports are not describing a very specific reproducible scenario, other than when a stream is resumed (eg when hopping to/from WiFi), things go wrong in various shapes and forms.
A good way to reproduce one (of many) issues is to log into a server using the Conversations client on an Android phone, then enable airplane mode for a few seconds. Inconsistent behavior typically follows.
This is not to say that the Conversations client is an integral part to this problem: it’s just my client of choice when reproducing this issue.
A possible work-around for this issue is to disable Stream Management completely. This can be achieved by configuring the property stream.management.active to have the value false
Much of the root cause for this is a side-effect of switching from Apache Mina to Netty ( ). Netty’s connection closure is asynchronous. This causes Openfire’s connection-close listeners to be still firing, when (or after) stream management has re-attached. As a result, (some of) the connection-close listeners operate on the newly attached connection, possibly breaking it in one of various ways.
Guus der Kinderen February 29, 2024 at 10:08 AM
A secondary issue is that after a successful resume, the resumed session itself is no longer resumable.
Openfire has support for XEP-0198: Stream Management. This feature allows for stanza acknowledgement and session resumption (for example, after a network interruption).
Various people, including client devs, have reported issues with stream resumption in Openfire 4.8.0. The reports are not describing a very specific reproducible scenario, other than when a stream is resumed (eg when hopping to/from WiFi), things go wrong in various shapes and forms.
A good way to reproduce one (of many) issues is to log into a server using the Conversations client on an Android phone, then enable airplane mode for a few seconds. Inconsistent behavior typically follows.
This is not to say that the Conversations client is an integral part to this problem: it’s just my client of choice when reproducing this issue.
A possible work-around for this issue is to disable Stream Management completely. This can be achieved by configuring the property
stream.management.activeto have the valuefalse