updating a MUC name right after I’ve creating it doesn’t work, even if I try many times.
I’m updating the name using:
val muc = mucManager.getMultiUserChat(roomJid)
val form = muc.configurationForm.fillableForm
form.setAnswer("muc#roomconfig_roomname", title)
...
muc.sendConfigurationForm(form)
No exception is thrown.
The problem seems to be that the getRoomInfo method (I’m using it to retrieve the MUC info, such as its title) of the MultiUserChatManager always returns the previous (and old) MUC name.
If I try renaming a MUC after a logout/ login everything works correctly. Should I call some specific method to “refresh” the subscribed MUCs?
If you look at the implementation of MultiUserChatManager.getRoomInfo(Jid) you see that it essentially just a wrapper around a service discovery request. However, this request may used cached information.
I suggest you
attach a breakpoint at the method and see where the DiscoverInfo is obtained
set SmackConfiguration.DEBUG to true, to look at the actual stanzas that go over the wire
See also
That would be a little bit besides the point of using a library. That said, could be that caps caching is involved here, but the cache should update eventually.
A full XMPP trace starting from the point where you change the MUC name and ending after you call MultiUserChatManager.getRoomInfo(Jid) would provide valueable insight.
Thank you for your help.
I also thought something about the cache, that could explain why a logout/ login solves everything for an already created MUC.
Another strange thing is that if I create a MUC and try to rename it, I cannot see the name update, but all the other users inside the MUC can see it instantly. It doesn’t work only for the user who tried the update.
Below you can find the trace printed.
user1 is the creator of the MUC and the one who’s trying to update the MUC name
user2 is the only other user in the MUC
user1 tried renaming the MUC from mucTest1 to mucTest2
Then I will check if there’s a way to update the ServiceDiscoveryManager. Thanks for the hint. @Flow do you have any suggestion? Maybe something I can test or a workaround.
Thanks
It is possible that the xmpp trace is incomplete, at leat there are no disco#info related stanzas exchanged, nor the presence update of the MUC due its name change.
Furthermore, I can not reproduce this on Smack’s master using the following integration test:
in your test, you’re using a method that is not released yet (mucAsSeenByOne.getConfigFormManager().setRoomName(newRoomName)) .
Could you please rewrite your integration test using the same methods that I’m using (the snippet I shared in the first message)?
Under the hood everything seems to be the same, but the fillableForm used could be the problem.
Just be 100% sure, this is how I create a new MUC:
fun createMUC(title: String, vararg users: String): String? {
return try {
val roomName = generateRoomName()
val bareJid = roomName.plus("@").plus(settings.mucDomain)
val roomJid = JidCreate.entityBareFrom(bareJid)
if (mucSubManager.subscribeToMuc(settings.entityBareJid, roomJid, getNickname().toString()).result) {
val muc = mucManager.getMultiUserChat(roomJid)
val confBuilder = muc.getEnterConfigurationBuilder(getNickname())!!
.requestNoHistory()
if (!muc.isJoined) {
try {
muc.join(confBuilder.build())
} catch (e: Exception) { }
}
muc.grantModerator(getNickname())
val info = setRoomInfo(roomJid, title)
if (info) {
inviteUsers(roomJid, *users)
bareJid
} else null
} else null
} catch (e: Exception) {
null
}
}
setRoomInfo is the method I shared in the first message