powered by Jive Software

Users remain in MUC?

Hi,

We are using JM 2.3.0 beta 1. Our company actively using only MUC service. There is about 20 rooms and about 300 concurent users. It appears that some users is staying in the MUC room after disconnection from server. It looks like a bug. The only way to clear them is to restart MUC service.

Thanks,

Tim

In addition server store offline messeges for this users. So we have a lot of trash in database.

This issue appears when client incorrectly closing connection to the server. Server closes client session, but don’'t kick user from MUC room.

This is a bug. It appears when client send available presence directly to MUC room and not send global available presence to server. When connection is closed, server think that client is unavailable and do not enter to the if statement in SessionManager.java:1220. So, session is closing and user is remaining available in MUC room.

May be this issue is already fixed? If no, I can try to fix it. Please, let me know.

I fixed the problem. I am novice in Java and in JiveMessenger, please review changes I made.

Index: SessionManager.java

===================================================================

— SessionManager.java (revision 3094)

+++ SessionManager.java (working copy)

@@ -1279,7 +1279,17 @@

try {

ClientSession session = (ClientSession)handback;

try {

  •                if (session.getPresence().isAvailable()) {
    
  •                // Send an unavailable presence to the user''s subscribers
    
  •                 // If presence already sent it will be ignored.
    
  •                // Note: This gives us a chance to send an unavailable presence to the
    
  •                // entities that the user sent directed presences
    
  •                Presence presence = new Presence();
    
  •                presence.setType(Presence.Type.unavailable);
    
  •                presence.setFrom(session.getAddress());
    
  •                presenceHandler.process(presence);
    

+/*----


ORIGINAL CODE

  •                      if (session.getPresence().isAvailable()) {
    

// Send an unavailable presence to the user’'s subscribers

// Note: This gives us a chance to send an unavailable presence to the

// entities that the user sent directed presences

@@ -1288,6 +1298,7 @@

presence.setFrom(session.getAddress());

presenceHandler.process(presence);

}

±—


ORIGINAL CODE*/

}

finally {

// Remove the session

Index: handler/PresenceUpdateHandler.java

===================================================================

— handler/PresenceUpdateHandler.java (revision 3094)

+++ handler/PresenceUpdateHandler.java (working copy)

@@ -100,7 +100,14 @@

presenceManager.userAvailable(presence);

}

else if (Presence.Type.unavailable == type) {

  •             // Check if session is already unavailable
    
  •            if (session != null && session.getPresence().isAvailable())
    
  •                 broadcastUpdate(presence.createCopy());
    

+/*----


ORIGINAL CODE

broadcastUpdate(presence.createCopy());

±—


ORIGINAL CODE */

broadcastUnavailableForDirectedPresences(presence);

if (session != null) {

session.setPresence(presence);

I also experienced this. I’'m using Jive Messenger 2.2.0 (release version).

Hi,

I’'ve tested this issue in JM 2.3.0 release. Bug is still here.

Bug is not fixed. My changes do not resolve problem.

It seems, I’'m talking to myself

My changes resolve problem in this case, but this is not only way to get this bug.

Hm, really strange that noone of devs has replied to this yet. Dont give up Sometimes it’'s a good chance to make them look into your problem is to go to Live Chat that takes place every Wednesday Or you can PM Gato or Matt.

Hey Tim,

Sorry for not getting back to you before (we were really busy getting JM, Smack, Spark, Asterisk-IM out). The reason why you are having this problem is explained in this url=http://www.jivesoftware.org/community/thread.jspa?messageID=107264&#107264other thread[/url]. Anyway, I created the issue JM-466 and fixed this problem from happening even though users that never sent an available presence will not be able to completly join a room.

Regards,

– Gato

Thanks Gato,

I’‘ve tested your fix in artificial test. It seems it is working fine. I’'ll keep this topic up to date if there is any problems in real work.

Regards,

Tim

Hi,

fix is resolving just a part of problem. We still have ghosts in MUC rooms. We believe, that it can fixed.

Thanks,

Tim

Hey Tim,

We are now implementing JM-486 that may also be related to this problem.

Regards,

– Gato

The problem is still not fixed.

Hey devs,

Could you perform some actions, to resolve this problem. We need to restart server every day to kick ghosts.

Regards,

Tim

Hi Timur,

I guess the heartbeats from server probably may solve problem, but this is not wired in official release.

So, the next feature can help you to decrease time for your server to realize ghosts presence:

you need wildfire 2.4.0+, then configure server’‘s property “xmpp.client.idle” to 2 minutes, also you need to configure your client’'s heartbeating to a bit smaller value, f.e. 1 minute

At this case the ghosts will be eliminated around 2 minutes

Thanks, I’'ll try it.

I tested version 2.4.2 and bug is still here.

Hey guys,

I was able to reproduce this problem and as Timur just said the socket idle timeout is not going to fix this problem. In fact, there are no sessions present in the session page so something else is going on.

Will update this thread with any news I might have.

Thanks,

– Gato

Thanks to all. Looks like the problem is resolved in WildFire 2.4.4.