powered by Jive Software

Spark Group Chat created duplicate users


#1

Update: Complete uninstalled and deleted the Spark files in users Appdata before reinstalling to fix the issue, however that hasn’t fixed the issue. I no longer see a account with a duplicate nickname but I also don’t see all occupants in the room that they are not already there. However the number in the room doesn’t not increase as it did before.

We have an issue where members of a Spark group chat can not join and get a No response from server error or get throw in a group chat with no one in it. I believe the issue is for some odd reason spark is creating duplicate users in the group, example: username2, and won’t allow them to join. However, I have not been able to any errors on the computer or server said saying something went wrong.


#2

Sounds like a bug fixed in 2.8.3 https://issues.igniterealtime.org/browse/SPARK-1854


#3

Installed the 2.8.3 version of the Spark client on the issue computer and it still persists.


#4

I would try to update more PCs, as every older Spark version connecting to group chat can create such issues. Also, you have updated the first message and i’m now not sure what exactly your issue is right now. If you can update a few more computers and then try to connect to some room only with updated computers, do you still see the issue? Then describe it with as many details as possible (step by step).


#5

Sorry about the confusion.
Issue was that there was 1 group chat that some of the members would have issues joining and get the “No response from server”. Not all members and same members can join other groups with no issues.
Also it didn’t which computer they would use, it would stop them from joining.
Looking at the group from the Admin side, I notice that the user would already but with a different nickname.
Have attempt to update/uninstall and reinstall the client to attempt to fix the issue, but it never would work.
Uninstalled the client again and deleted all the spark roaming data for all users in hopes that would fix the issue.
Reinstalled the client and a user now joins the group with no issues. I still have a user having that same issue even though they connect on 2 computers that have gone through this process.


#6

What are you using as a server? Openfire? Which version? Have you tried restarting it or maybe deleting such room and creating fresh one (unless you want to preserve the history)?


#7

Openfire 4.2.3 and this room is only a few weeks old. I recreated the room the last time this was happening.


#8

You may also try recreating the user. I have no other ideas.


#9

We use ldap to add users from an Active Directory. So unsure how it will behave if I do that.


#10

I think the issue is the room reports 3 members are in the room but no name appears in the occupant list so I think it may see those users in the room and will not allow them to rejoin or something.


#11

There also was this issue https://issues.igniterealtime.org/browse/SPARK-1576 So maybe your other users are on older version. But it would only affect them.


#12

Ok i will go through and make the needed changes, though the users having issues I just update the client on their machines to 2.8.3.


#13

Ended up destroying the room and rebuilding it. Still unsure how the ghost users were made but all members of the room should now be using the 2.8.3 version of the client.
Attempted to removed the 3 unknown users from the room via ‘Idle User Setting’, but this never worked. It didn’t work because while the room said there were 3 people in the room the Service didn’t see any user in the room.


#14

I have the exact problem with our environment, and have written about it at least 3 other times. We’ve had this problem for years, and we are now on Openfire 4.2.3. User are on Spark 2.6.3 - 2.8.3. I have not had all the clients updated to the newest version of Spark, but I’ve had affected users do so, and it does not resolve the issue.

I have spent many hours today, in the database, looking for nicknames, or thinking their must be a MUC table showing a list of nicknames. I find no way of seeing or kicking the ghost users. (I did just find out that when using the Pidgin client, one can see the various nicks, even the “ghost” ones.

I suspect there is something wonky happening when one of these affected users’ client tries to connect to the server. The server thinks the client connects, but the client doesn’t so tries again, making a “user1”, “user2”, etc. I watched 3 different users today, when starting their Spark client, enter the room, then enter as user2, then user3, all the way to user9 before it stopped. The user did not exit the room at any point.

Like @miguel.arambula says though, those nicks are not visible even from the admin console, and the occupant count in that room is more than what a user will see in their client. For instance, I have a room right now where the occupant count is 47, but I can only see 20 in my client.

The only fix I’ve found is to destroy/recreate the room, but it’s not a lasting fix. The same users will eventually have the issue again.


#15

I also tried using the “kick idle accounts” setting in the admin console, and it ended up only kicking accounts unaffected by this problem. It did not do anything to the ghost accounts. I could still see them from the pidgin client.


#16

This kind of issue is hard to investigate, especially via forums. It can be Openfire issue after all, but as i can’t even reproduce it, it is hard to tell. So i can only guess and suggest. Updating all clients to the latest version. Maybe older clients are not affected themselves, but affect newer clients. Checking Spark and Openfire logs when it happens for any clues. If possible giving the affected user other client to use for a while (Pidgin, etc.). Recreating rooms (after all clients are updated) to eliminate possibility that the room itself is bugged. Trying to change room settings (maybe some setting causes this).


#17

Agreed. It is difficult to troubleshoot. I have been unable to make this scenario happen, but know it will happen again. I have found no helpful logs so far though. Maybe I’ve been looking in the wrong place. Where do you suggest I look? Our users are split between Windows and Mac, with just a couple Linux users. Due to security restrictions, all Windows users are only allowed to use Spark. Mac users mainly use Adium, while a few might use Spark. I don’t believe I’ve heard of any Mac/Spark users being affected by this.


#18

Do all your rooms run on the same service. That is what I thought the issue was at first it appeared to work for the first set of users having issues when i divided up the rooms across different services. However, it happen again but to a different set of users so I rebuilt the room again and haven’t had the issue since. Another thought, when you have user sign into spark do they sometimes have it where the Contact list pulls up blank and there login name shows up instead of their display name?


#19

Openfire logs are in /openfire/logs. Spark logs on Windows are in C:\Users\User\AppData\Roaming\Spark\logs\ There are a bunch of files, look through all of them and select events that correlate with the time of your issue.


#20

If by “service”, you mean conference service, then yes, all of our rooms are on the same service, but we really only have between 10 and 15 rooms in use at any one time. Before I rebuilt this server on new hardware, new operating system, new Openfire install, we had hundreds of rooms, still only using the one conference service. The old server had been in use since Openfire was still Wildfire. When I shut it down, I think it was version 3.5. We experienced this issue at least from the early version 3 days. We thought maybe there was some database corruption through the different updates/upgrades, thus the reason for the brand new server.

As for the list being blank, yes, we’ve been seeing this, but it seems to just take some time for the client to get all the information from the server, and the list eventually populates. The same behavior is seen for the conference service list, and the rooms list.

I’m not sure about the login name vs the display name.