What steps will reproduce the problem?
1. Create a session and bind to resource 'foo'
2. Join a muc at room@conference.server.tld
3. Create another session and bind to resource 'foo'. (Ignoring the old one. I do this by killing the program that hosts the old session.)
4. Join a muc at room@conference.server.tld
What is the expected output? What do you see instead?
After joining the muc at step (2) I receive a bunch of presences. From other participants as well as one for myself.
After joining the muc at step (4) I only receive a presence for myself. The server thinks I'm in the muc (I can send and even receive messages). I just don't know who else is in the room.
What version of the product are you using? On what operating system?
0.10 trunk frmo March 3rd.
Please provide any additional information below.
It doesn't seem to matter whether the muc is hosted on the same server or on a different one.
I have mod_throttle_presence enabled but it doesn't seem to matter whether I'm active or inactive.
After the initial self presence I receive other join/leaves in this room just fine.
Daniel Gultsch
on
Disabling mod_throttle_presence did not help.
I'm seeing this behaviour even for conferences that are hosted on non-prosody servers.
However I'm not seeing this behaviour when repeating those steps with an ejabberd account.
Daniel Gultsch
on
Maybe when destroying a session it doesn't send an unavailable presence to the muc service. Thus the muc service still thinks the user is in the room and treats the new presence as an update and not as a join.
Zash
on
Thanks for the report. This seems to happen when a smacks-hibernating session is replaced by a new connection.
According to hg bisect, the first bad revision is:
http://hg.prosody.im/0.9/rev/56e65b1e54e8
Changes
owner Zash
tags Status-Accepted
Zash
on
Removing the (unusable) connection reference makes session:close() do nothing:
http://hg.prosody.im/0.9/file/0.9.10/plugins/mod_c2s.lua#l128
including *not* destroying the session, which in turn means no unavailable presence is sent.
Still, this would only happen when mod_smacks is enabled.
What steps will reproduce the problem? 1. Create a session and bind to resource 'foo' 2. Join a muc at room@conference.server.tld 3. Create another session and bind to resource 'foo'. (Ignoring the old one. I do this by killing the program that hosts the old session.) 4. Join a muc at room@conference.server.tld What is the expected output? What do you see instead? After joining the muc at step (2) I receive a bunch of presences. From other participants as well as one for myself. After joining the muc at step (4) I only receive a presence for myself. The server thinks I'm in the muc (I can send and even receive messages). I just don't know who else is in the room. What version of the product are you using? On what operating system? 0.10 trunk frmo March 3rd. Please provide any additional information below. It doesn't seem to matter whether the muc is hosted on the same server or on a different one. I have mod_throttle_presence enabled but it doesn't seem to matter whether I'm active or inactive. After the initial self presence I receive other join/leaves in this room just fine.
Disabling mod_throttle_presence did not help. I'm seeing this behaviour even for conferences that are hosted on non-prosody servers. However I'm not seeing this behaviour when repeating those steps with an ejabberd account.
Maybe when destroying a session it doesn't send an unavailable presence to the muc service. Thus the muc service still thinks the user is in the room and treats the new presence as an update and not as a join.
Thanks for the report. This seems to happen when a smacks-hibernating session is replaced by a new connection. According to hg bisect, the first bad revision is: http://hg.prosody.im/0.9/rev/56e65b1e54e8
ChangesRemoving the (unusable) connection reference makes session:close() do nothing: http://hg.prosody.im/0.9/file/0.9.10/plugins/mod_c2s.lua#l128 including *not* destroying the session, which in turn means no unavailable presence is sent. Still, this would only happen when mod_smacks is enabled.
ChangesFixed closing of sessions without a connection in http://hg.prosody.im/0.9/rev/de76ded98b84
ChangesNo presences from other participants in a muc room after replacing a sessionDisconnected sessions can't be closed