After users log off the sessions are not always closing. Messages are being lost as they are sent to sessions that are no longer in use. Before restart off the server, one user had 5 sessions listed. Ghost session will be show in the list of session in the admin page but will be counted. If you get a user info from the client buddy list, it will list the ghost sessions attached to the user. A user logged on and off while another logged in use watched, user that logged was shown as still logged in.
After users log off the sessions are not always closing. Messages are being lost as they are sent to sessions that are no longer in use. Before restart off the server, one user had 5 sessions listed. Ghost session will be show in the list of session in the admin page but will be counted. If you get a user info from the client buddy list, it will list the ghost sessions attached to the user. A user logged on and off while another logged in use watched, user that logged was shown as still logged in.
Openfire - 3.9.3
RedHat 5
I too am seeing this same hung session problem.
Not too long ago I upgraded to Openfire 3.9.3.
The server is running CentOS 5.10
Does anyone know why this problem reared its head with 3.9.3?
I’ve had an identical configuration for a few years since this server has been in production.
I’m going to give Wael’s suggestion to set idle time [0] [1].
Currently my xmpp.client.idle value is -1 (seemingly the default since I’ve documented my tweaks)
For now I’ve chosen 5 minutes (5601000 = 300000ms)
Most of my users are using Pidgin, so I’ll just have to trust it sends them out every 120 seconds since pings don’t appear [2] to be configurable.
To be correct, it is not that memory leak is introducing this, but probably memory leak occurs because of these left over ghost sessions stacking on the server.
Christian has also noticed that specifying a resource in Pidgin manually helps with that issue. Pidgin is generating a random string for a resource if it is not set by the user on every login. That’s why these stale sessions are not being kicked out by the resource policy, i think. Of course this doesn’t explain why stale sessions are still living on the server and why server is sending messages to them.
downgradeing to 3.9.1 solves this problem as it seems to be related to some memoryleaks introduced in 3.9.2.
Christian, thanks for posting a link to that thread.
One of my users connects to our Openfire server via a VPN (which my monitoring system indicates has been stable), but that person had over 100 ghost sessions over a four day period (I upgraded to 3.9.3 on Friday, June 20th).
I just rolled back to 3.9.1 and will continue to monitor the situation (though I didn’t have or notice ghost sessions for the months I ran 3.9.1).
Is there an official Openfire downgrade guide?
98% of my users connect with Pidgin on Windows and a few run Pidgin on Linux
The problem first became apparent to me when I hovered over an away user and their status message was a long list of messages with different session IDs. ******
Then upon further inspection, I found a large number of “Local Closed” sessions for users via the webui.
***I’d like to thank the Openfire team and contributors for their fine software. Bugs are to be expected and are just a brief bump in the road. ***
There isn’t. Though there are usually not many complex changes to the API’s or database structure, but one will have to create a guide for every version downgrade (and test it). So it is always a try and test path. 3.9.3->3.9.1 worked, but i’m not sure it will work for other versions.
There isn’t. Though there are usually not many complex changes to the API’s or database structure, but one will have to create a guide for every version downgrade (and test it). So it is always a try and test path. 3.9.3->3.9.1 worked, but i’m not sure it will work for other versions.
Gotcha.
That makes sense, I wasn’t sure if downgrade steps were more-or-less the same between versions so that boiler plate procedures could be posted.
Though this is the first time I’ve had to downgrade Openfire and I’ve been using it for around three years. So other than now, I’ve not had a use for downgrading.
In my case … (after backing up db and binaries) I removed 3.9.3, then installed 3.9.1 and found I had a blank config. From there I rsynced my backup from my previous 3.9.1 install and got things operational again. If there’s a better way or something I overlooked in my downgrade process, please point it out. Thanks.
It depends on platform and type of setup being used. On Windows (my test machine) i’m just uninstalling the current and installing the older one (constantly playing with nightlies, going back ,etc.). And usually i don’t have to do anything else. On linux i use tar.gz version, so i just backup database (i use embedded one), conf and also /resources/security which holds SSL certificates, then delete all, unzip the version i need and copy from backup what i need.
It depends on platform and type of setup being used. On Windows (my test machine) i’m just uninstalling the current and installing the older one (constantly playing with nightlies, going back ,etc.). And usually i don’t have to do anything else. On linux i use tar.gz version, so i just backup database (i use embedded one), conf and also /resources/security which holds SSL certificates, then delete all, unzip the version i need and copy from backup what i need.
Ah, I’m using the RPM package on CentOS Linux using MySQL database.
For what’s its worth, I am having difficulty reproducing this with Pidgin on 3.10.0 development/nightly build. I’ll try some more things to check further.