Zombie remote users in MUC

Openfire Openfire Support
#1

Greetings,

I’'ve run into an issue with OpenFire 3.2.2 installed on 2 servers. User A on server A connect to MUC server B. Works great. Then for whatever reason (local network errors perhaps), user A is booted from server A and server A logs:

2007.04.10 16:51:47 EXCEPTION

java.net.SocketTimeoutException: Read timed out

this stops the client connection on server A for user A, but the user A is still shown in the MUC room on server B. The only thing we can do is give the user A a swift kick on the MUC server B

Looking at the changelog, this perhaps is a new issue? If not, we will be happy to see it fixed when we upgrade to 3.3.0

Thanks!

daryl

#2

Hey daryl,

Presence management when doing server-2-server is tricky. The main reason is that losing the s2s connection between 2 servers does not mean that the user is offline. You can send a mesage to the remote user and the servers will recreate the s2s connection. In the XMPP list it has recently been discussed this problem and will eventually come up with some recommendations. Once they reach that point we can improve presence management with remote users.

Having said that, in MUC you can specify the idle timeout before kicking users. In the admin console look into Group Chat --> Other Settings. This is not a perfect solution but at least it will kick users that are dandling around.

Regards,

– Gato

#3

Hi Gato,

Thanks for the help. Perhaps I was not clear. s2s is fine. the c2s is failing on Server A and the presense is never bubbled up to Muc Server B. Or perhaps I am confused by what you are saying?

thanks,

daryl

#4

Whoa, turning on the boot idle users was not good! I just booted a large number of legitimate users.

daryl

#5

.

#6

Hey Daryl,

I think we are talking about the same issue. Lets say that userA that is connected to serverA joined a room in serverB. If connection of userA to serverA is lost then serverA should tell serverB that userA is offline. However, if serverA fails to detect that userA is disconnected then serverA will fail to tell serverB that userA is offline. Wildfire 3.2.2 uses a default idle timeout of 30 minutes. So after 30 minutes the server should realize that userA is offline and tell serverB that userA is offline now. Is this not working for you? Do you see any error in the log files?

Regarding the kicking of idle room occupants, are you using the default 30 minutes? Were the kicked occupants idle when they were kicked out?

Regards,

– Gato

#7

Hi Gato,

Thanks for the continued help!

So after 30 minutes the server should realize that userA is offline and tell serverB that userA is offline now. Is this

not working for you? Do you see any error in the log files?

It doesn’‘t. Since UserA relizes they have been disconnected and reconnects to ServerA. When they then try to join ServerB, they aren’'t allowed, since the handle is in use. I have to manually kick the user to free up the handle.

Regarding the kicking of idle room occupants, are you using the default 30 minutes?

yeah, but I misread what that was. Our users will ‘‘hang out’’ in the rooms 24x7. I only want to kick remote users that are no longer online

this serverA machine may just have something else wrong with it. We are seeings lots of logs like this:

2007.04.11 14:26:16 EXCEPTION

java.net.SocketTimeoutException: Read timed out

at java.net.SocketInputStream.socketRead0(Native Method)

at java.net.SocketInputStream.read(Unknown Source)

at com.sun.net.ssl.internal.ssl.InputRecord.readFully(Unknown Source)

at com.sun.net.ssl.internal.ssl.InputRecord.read(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(Unknown Source)

at com.sun.net.ssl.internal.ssl.AppInputStream.read(Unknown Source)

at org.mortbay.io.ByteArrayBuffer.readFrom(ByteArrayBuffer.java:168)

at org.mortbay.io.bio.StreamEndPoint.fill(StreamEndPoint.java:99)

at org.mortbay.jetty.bio.SocketConnector$Connection.fill(SocketConnector.java:190)

at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:277)

at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:203)

at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)

at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:217)

at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)

2007.04.11 14:26:16 EOF

We are looking to upgrade both A and B to Openfire 3.3.0 and will see what happens then.

thanks!

daryl

#8

Hi,

Unfortunately, we are continuing to this problem. Our current “solution” is to have a bot that is in the roster of all users on ServerB. When a user on ServerB is disconnected, the bot then kicks that user from all chatrooms they are logged into on ServerA.

I see how this is a difficult issue to account for, but perhaps this logic could be used.

There is activity in serverB MUC room, this message is sent to a user on server A. Server A notes that this user is offline and since the chat type is groupchat, it sends back to server B to disconnect user from chatroom?

I could be wrong, but I think it sort of worked this way back in the old days when we ran jabberd2. Zombie users would get kicked during the next chatroom activity and the server realized the user was not online.

Thanks for the continued help and great product!

daryl

#9

Hey daryl,

Are you using Openfire 3.3.1? Since we are using that version we are no longer seeing the phantom users problem. Let me know if that is not your case.

– Gato

#10

Hi Gato,

Your support on this forum is very much appreciated.

We are at 3.3.1 on server B, 3.2.2 on server A… I’'ll see if I can get the server A folks to upgrade Knowing that it may fix this issue is encouraging!

thanks!

daryl

#11

Hi Gato,

We are seeing this frequently with Openfire 3.3.1 on both servers Anyway to debug it?

daryl

#12

What do you see in the room occupants page in the admin console? I’'m interested in JIDs, roles and affiliations.

Thanks,

– Gato

#13

Hi Gato,

Thanks for the continued help. The admin console shows the zombie user:

nwsbmx5@remotejabberserver/Home nwsbmx5 participant none

I may just be wasting your time with a limitation of the MUC JEP? Is the client responsible for removing the presence from the remote server room? This happens when the remote server has a network error or some sort and the client port connection is lost. User is bounced from the server and that’'s not communicated up to the MUC server. Should I ask the jabber/XMPP folks about this?

thanks!

daryl

#14

My problem solved as:

Code:

sendAuthentication_result()

{

if (authenticated)

{

loggedIn = true;

  • // you have to do this here, after each login success, explicitly!!!

send( new Presence( null, null, Presence.AVAILABLE_TYPE ) );*

}

}

Without sending out the extra presence, some version of the server doesn’'t think you are online in all modules.

*good luck

#15

hi joey_mw,

Thanks for the suggestion, but all of my clients are running Pidgin or some other GUI client.

This continues to be a rather big problem for us

Any further thoughts?

thanks,

daryl

#16

bump

Perhaps this is just something I need to squawk at the Jabber XEP folks about?

We are running Openfire 3.4.4 on both servers and continue to see this quite a bit.

thanks,

daryl

#17

Hi Daniel,

I noticed that a fix went in for Openfire 3.6.0 yesterday:

http://www.igniterealtime.org/issues/browse/JM-1359

This fix kicks a user out of a MUC if the same user attempts to enter the room with the same handle again. This sounds exciting as I hope it fixes this situation.

Any comments on if you think it will fix it?

thanks,

daryl