MUC Visible Account Rename and Echo

This may be a new bug report either for Spark or maybe it should be for Openfire, I did search to check if this has been reported before but did not find a similar report, if one exists sorry if I missed an earlier report of this problem.

In our department we use multi user chat room (with a password) as a way to communicate because we are in different office locations, some of us connect via a personal VPN to the Openfire server (a VPN that is sometimes unstable due to whatever ADSL connection is available).

When the VPN goes down for a short period Spark looses connection to the multi user chat room. When the VPN comes back up and Spark reconnects a number of strange problems can be seen. Openfire server is version 3.7.0 and Spark client is 2.6.3 instal4j 600.

  1. A dialogue box opens saying wrong password for the chat room, however selecting Ok the the chat room appears to connect successfully.

  2. If your your openfire user name is for example JoeBloggs when the chat room reconnects your visible user name will become JoeBloggs4, if the VPN goes down and up again the user name will sometimes increment again, e.g. from JoeBloggs4 to JoeBloggs5.

  3. When the user name goes from JoeBloggs to JoeBloggs4 (or some other number at the end), when you enter some new chat text, it will appear twice in the chat room conversation (almost like an echo), one chat item from JoeBloggs then another from JoeBloggs4.

  4. On other occasions when this VPN up down sequence happens when you enter some new chat text it is not visible in the chat room conversation. However your chat text does make it to the chat room and is visible after logout and login back in.

Log out of Spark or the chat room and log back in appears to correct the problem.

After posting this problem report the latest version from http://bamboo.igniterealtime.org/browse/SPARK-INSTALL4J-609/artifact was downloaded and installed. Strangely the problem does not happen today following installation of this 609 version; the OpenFire server was not rebooted since the problem was last seen to happen. Users in our company have experienced the reported problem for some long time and it will be interesting to see if the problem will reappear or if one of the recent Spark code updates has actually been the solution.