Florian Schmaus 9447030cd4 [muc] Do not invoke userHasLeft() on nickname change ... 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().		2024-05-20 21:45:47 +02:00
..
src	[muc] Do not invoke userHasLeft() on nickname change	2024-05-20 21:45:47 +02:00
build.gradle	[gradle] Do not use deprecated 'compile' directive	2021-04-14 20:30:51 +02:00