Ghost user - unable to disconnect

[lomriilod]

Hi,

I know, it sounds like the same issue like the other posting - but its not.

Every once in a while we have Users which we can not disconnect. Neither a Serverside Java extension disconnectUser nor the attempt to disconnect them from the admin pannel helps.

As far as I have heard from our admins, these users are also not disconnected by maxclientdrop messages, because the server keeps sending messages. After 4 stucked useres the server becomes huge performance problems.
Also the useres are always stucked in a limbo room.
We are running version 1.6.3 and I found one message which I hope you can relate to that issue. Sadly I am not sure, because I don't have the names of the users that were stucked.

00:16:40.555 - [ INFO ] > User: XXX is already logged in Zone: XXXXXXX
Old user object found
Old User ID: 1561
Old User IP: XX.XXX.XXX.XXX
[UsersById] query: it.gotoandplay.smartfoxserver.data.User@126012a
[Clients] query: true
[UsersByChannel] query: null
[ChannelQueues] query: []

User was found in 1 room(s) ::
XXXX

Do you have an idea what could cause this problem?

One more thing: We are (maybe mis-) using the user.setMarkedForRemoval() function to mark useres for deletion. Cound this be a problem?

Thanks

Dirk

[Lapo]

Yes, please avoid that method. It's not intended to be used by the extension developer. (that's why it doesn't provide any docs)

[lomriilod]

Ok, we will do that.

Is the described problem (ghost users) a possible result of the use of that methode?

Dirk

[lomriilod]

Hi,

we have changed the code but still have problems with users we can not disconnect. The only way to remove them is by restarting the server.

...any idea? any more infos I can give you?

Dirk

[Lapo]

During the server activity it is normal to have ghost connections. These pending connections will usually exist for a certain amount of time and then they will be dropped.

Part of them are evicted by SFS itself after the MaxIdle timeout, part of them will hang in there until the underlying TCP socket times out.

Are you sure that the connections you are seeing are always the same? The fact that you have some ghost connections is not bad per se.
Are they growing day by day?
Do you see a large disparity between the number of connected clients and the number of connected sockets in the Admin Tool?

Additionally if you use the latest SFS 1.6.3 you have a couple more options to use:

MaxSocketIdleTime, allows to specify how long a socket connection can be idle before the server disposes it.
We recommend to configure this setting to a low value, like 60-120 seconds.

If you have problems with the "Username already taken" error (which may happen if a user tries to reconnect after a "bad" disconnection)
you can use the forceLogin option added to the login() method in the server side API.
This will force the old connection to close.

Hope it helps

[Lapo]

One last note. Recently we had a customer who seemed to have an incredible amount of ghost connections problems.
After a close inspection to their client side logic we discovered that their application was continually moving users from a Zone to another by disconnecting and reconnecting immediately instead of using a more graceful logOut call and waiting the related onLogOut event.

If this is also happening in your logic, make sure to avoid forcing a disconnection manually and then immediately reconnect.

[lomriilod]

This could be an issue.
We needed the forceLogout option prior to version 1.6.3. Thats what we did to achiev this:

Code: Select all

// log out already logged in user
SocketChannel existingUser = zone.getChannelFromName(nick);
if (existingUser != null) helper.disconnectUser(helper.getUserByChannel(existingUser));				
try
{
	newUser = helper.canLogin(nick, pass, chan, zoneName);

Does this macht the problem you are describing?

Dirk

[Lapo]

No it doesn't match. But with 1.6.3 you can avoid that and use the forceLogin option