Openfire doesn't ACK the sent presence stanza to the user


When sending presences the server must send back the presence to the JID, see

Most of the servers are also keeping the initial ID (like M-Link, ejabberd, Prosody) then the client can handle properly the response.





Guus der Kinderen
August 29, 2019, 12:07 PM

The fix that was applied earlier improved the reflection of initial presence, but introduced the original problem when reflecting offline presence.

This is being logged on debug:

October 30, 2018, 8:26 PM

I mean (from the clients perspective), this is what I observed:

Send <presence/>
Receive nothing
Send <presence/>
Receive <presence/>

Daryl Herzmann
October 30, 2018, 8:06 PM

Thanks, but what do you mean by 'A second presence stanza is received.' ?

October 30, 2018, 7:49 PM

I can reproduce this running openfire_2018-10-30.tar.gz by:

Send <presence/>
Expect <presence/> but don't receive it

A second presence stanza is received.

test case for the scansion test runner

Guus der Kinderen
June 29, 2018, 11:50 AM

I don't think the fix for ever completely worked. It is based on a presence broadcast that sends a presence update to all subscribed entities, as well as all resources of the same user that are available.

The problem lies in the fact that the presence update was 'recorded' in the client session only after this broadcast was done. When iterating over all client session to find resources that are available, the session from where the update originated, is still reporting the previous presence state (in case of a new session: unavailable).

To me, re-ordering events seem logical, and desirable for other reasons. It makes sense to first store the presence update in the client session, and only then broadcast the update.

With this fix, the test mentioned above now produces:




Guus der Kinderen


Timothée Jaussoin