Openfire (master)

• 

  daryl herzmann <akrherz@iastate.edu> 29 Jun 2018 91b1dd5816cd399a278e5cf554c54624d1950973

  Merge pull request #1100 from guusdk/OF-1433_reflect-presence-updates
  OF-1433 / OF-454: Reflect presence updates
• 

  Guus der Kinderen 29 Jun 2018 ac11cbae07a3b796b02adcd7dbda2896318051ed m

  OF-1433: Method name should reflect its implementation.

  • src/java/org/jivesoftware/openfire/SessionManager.java (version ac11cbae07a3b796b02adcd7dbda2896318051ed)
  • src/java/org/jivesoftware/openfire/roster/Roster.java (version ac11cbae07a3b796b02adcd7dbda2896318051ed)
• 

  Guus der Kinderen 29 Jun 2018 c63e7ce6cc640facf7c0707302eec6220fd2854d m

  OF-1433: First record, then process presence updates.
  I don't think the fix for OF-454 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.

  • src/java/org/jivesoftware/openfire/handler/PresenceUpdateHandler.java (version c63e7ce6cc640facf7c0707302eec6220fd2854d)