I also upgraded from 3.9.1 to 3.9.3 and ran into the similar problems people have been having. I have had none of the reported problems with LDAP, groups and memory leaks as other users reported until going to 3.9.3. I have my OpenFire server connected to my Active Directory using LDAP connection in the server console. My OpenFire server is running on Cent OS 6.5 with the most recent general release kernel - 2.6.32-431.17.1.el6.x86_64 #1 SMP.
OF Groups Missing in IM Client: I created object groups in AD specifically for the OpenFire server and linked my various staff and departments into those groups. Before 3.9.3 I had no problem with groups being pulled in from AD and disappearing in the IM client. Renaming the groups with removing spaces and special characters has so far worked but is a terrible solution to this problem.
Users Appearing Offline: I also experienced the issue with users appearing offline even though they weren’t though their session was still active on the server. Expanding the vcard, username2roster and even the java memory size and caches all seemed to help but I still think there is an underlining problem.
Java Memory Leak: Also as I stated before I’m experiencing the memory leak now. I’m running the current java Cent OS 6.5 general release version 1.7.0_55, OpenJDK Runtime Environment (rhel-2.4.7.1.el6_5-x86_64 u55-b13), OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode). I changed my sysconfig file to point to the /etc/alternative/java link instead of using the OpenFire built in, However I’m still getting a constant memory growth in my OF admin console where the memory keeps growing from roughly 40 MB to 120-130 MB out of 592 MB total. Granted I’m not maxing out my java memory buffer but it’s not normal behavior.
Granted this is a post that applies to several existing posts but I felt it might be better to group them up into one.
I’m curious to see if there were code changes or additions that might have caused Openfire to consume more resources than in previous versions.
So far over the weekend, my server has been stable since I made the adjustments above. The only thing consistent is the constant increasing of Java memory to roughly about 120-150mb then back down to 40mb. It just keeps cycling. Thanks for posting the bug reports wroot. I’ll keep reporting anything new as it appears for me.
I’m on linux, with Oracle’s 1.7.0_51 Java. No LDAP.
Cycling is indeed normal. This is how JVM’s garbage collector works. In my case it runs ok now using 200-400 MB of 700 max, for two weeks now i think. On 3.9.3 it jumped to 700 in a few days.
Btw. What clients do you use. Spark 2.6.3 maybe? I saw another post with similar issue (offline users). And it seems using latest Spark builds helped. I’m using latest Spark builds for almost a year now. So, maybe that’s why i didn’t see this issue.
By default AD will only allow 1000 results per query…so you may want to look into that as a possible issue? Also, what virtual nic driver are you using with vmware? Whats your patch version of vmware? There is a bug that will cause the server to drop packets if your using the intel e1000 nic. and a few kb on dropped packets caused by traffic burst. If you are using the e1000, try using vmxnic3.
Just to chime in on the OF-814 discussion (as what I’m seeing since the upgrade to 3.9.3 doesn’t exactly match what others have been saying, or I’ve just dug a little bit deeper):-
OF (deployed from .deb) is running on Ubuntu 12.04 LTS 32-bit Server (current updates), DB is Percona MySQL 5.5, LDAP auth to Windows 2003 SBS AD, XMPP groups and users in a single OU, all servers on a single LAN and all clients Pidgin (various, but mostly 2.10.X).
Some of my users are seeing other users as “Not authorized”, and if I check the user rosters, all the shared groups have disappeared (other than the groups the users are members of). Appears to be losing the shared group info on a daily basis for some users, where for others it remains “normal”. Disabling and re-creating the shared groups gets things back as I would expect, and I’ve today built an extra “All Users” group to see if that tricks OF into not deleting the other shared groups.
Otherwise, not noticed a memory leak (not that I was looking for one), nor any other issues in 3.9.3.