vanitasvitae/Smack
1
0
Fork 0
mirror of https://github.com/vanitasvitae/Smack.git synced 2024-11-22 20:12:07 +01:00
Code Issues Releases Wiki Activity

[muc] Do not invoke userHasLeft() on nickname change

Browse source 
When the incoming unavailable presence is signalling a nickname
change (303), then do not invoke userHasLeft(), because the user
actually does not leave but instead just changes its nickname.

Note that this would also have had fixed SMACK-942, as it would
resolve the deadlock. However, using a dedicated lock for
changeNickname() still seems sensible, and if its just to avoid a bit
of lock contention.

What this also fixes is that a MultiUserChat does no longer invoke its
listener-based callbacks after a nickname change, as previously, after
a nickname change, the userHasLeft() would have been invoked, which
tears down the listeners. This issue was found with
MultiUserChatOccupantIntegrationTest.mucChangeNicknameInformationTest().
This commit is contained in:
Florian Schmaus 2024-05-20 21:45:47 +02:00
parent c34c9bdb62
commit 9447030cd4
1 changed files with 4 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
smack-extensions/src/main/java/org/jivesoftware/smackx/muc/MultiUserChat.java
View file

@ -258,13 +258,14 @@ public class MultiUserChat {
break; break;
case unavailable: case unavailable:
occupantsMap.remove(from); occupantsMap.remove(from);
if (mucUser != null && mucUser.hasStatus()) { Set<Status> status = mucUser.getStatus();
if (isUserStatusModification) { if (mucUser != null && !status.isEmpty()) {
if (isUserStatusModification && !status.contains(MUCUser.Status.NEW_NICKNAME_303)) {
userHasLeft(); userHasLeft();
} }
// Fire events according to the received presence code // Fire events according to the received presence code
checkPresenceCode( checkPresenceCode(
mucUser.getStatus(), status,
isUserStatusModification, isUserStatusModification,
mucUser, mucUser,
from); from);