powered by Jive Software

Session are not closing

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

1 Like

Which chat client is being used? What are your server session idle settings configured as?

I also have this problem with android. I solved it but my solution make clients reconnecting like a hell specially on 3G.

I changed openfire settings to disconnect idle user (10 seconds). and I set the ping interval on client (5 seconds).

Also (a)smack is not closing the session if the connection closed by openfire so I need to clean up the connection and start a new connection.

Mixture of Windows - pidgin and Linux

Disconnect clients after they have been idle for 15 seconds.

Send an XMPP Ping request to idle clients.

Only way to close the ghost sessions is to restart the openfire service

jhemrick6909 wrote:

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.

[0] https://community.igniterealtime.org/docs/DOC-1061

[1] https://community.igniterealtime.org/docs/DOC-2053

[2] https://developer.pidgin.im/ticket/9234

please take a look here:

downgradeing to 3.9.1 solves this problem as it seems to be related to some memoryleaks introduced in 3.9.2.

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.

Filed as OF-829

Christian Michallek wrote:

please take a look here:

https://community.igniterealtime.org/thread/52828?tstart=0

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. ***

Downgradeing is not an option, I will lose the emoticon module in my app.

Michael Bear wrote:

Is there an official Openfire downgrade guide?

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.

wroot wrote:

Michael Bear wrote:

Is there an official Openfire downgrade guide?

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.

wroot wrote:

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.

Thanks for sharing your process.

restarting openfire once a day should get rid of all ghosts sessions and should keep them at a low level.

Its ugly, but it seems the only workaround so far.

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.

Of the two users that this problem initially showed up on… they’re both running:

Client: Pidgin 2.10.9 (libpurple 2.10.9)

Pidgin 2.10.9 is the latest stable version for Windows per http://pidgin.im/.

I have clients from 2.10.2 to 2.10.9 affected by this problem.

Important thing to note, it only happens on clients without an Ressource set and let pidgin autogenerate the ID.

With my limited knowledge it looks like this:

  • Pidgin reconnects and detects that the ressource is still in use.

  • for some unkown reason instead of trying again with the same ressource it generates a new RessourceID

  • openfire does not close the old session and it will stay online indefinitely, even if the client disconnects for hours

  • this session is only visible in the admin console, as long as one client is really connnected

  • for other clients, these users appear connected

  • doing an info lookup on these users reveals all ghost sessions and shows no client connected to these

If you set a RessourceID manually, this problem does not occur and pidgin/openfire works normal.

Daryl meant Openfire version. He is testing on nightly build of 3.10.0 which has some updated components (Jetty).

Ah, this is very helpful and am attempting to test this as well.