powered by Jive Software

Openfire 3.9.1 has been released

Yesterday’s release of Openfire 3.9.0 had some problems with packaging of the release. Bouncycastle signed jar files were getting packed, which then caused problems when Openfire attempted to load them. We have hopefully fixed this issue and cleaned up a few other details and are proud to announce a 3.9.1 release!

Openfire is a real time collaboration (RTC) server licensed under the Open Source Apache license. It uses the only widely adopted open protocol for instant messaging, XMPP (also called Jabber). Openfire is incredibly easy to setup and administer, but offers rock-solid security and performance.

The download page offers these files and here are their md5sums for your comparison.



Please report any issues to us in the forums. We are always looking for developers to help improve Openfire, so please let us know if interested!


Wow, that was fast! Good job on the speedy work/release!



Please, upgrade Spark.

Version 2.6.3 is a pretty old and have bugs a lot.

Improvements in spark would be incredible!!!1

Just upgreaded - everything it’s ok

Agreed with Jacques

I would also like to ask if there are plans to improve / upgrade Spark …

Spark is constantly in development. Actually this week an important changes was done, that now Spark requires Java 7 and doen’t use Java 6 if you have one on the system. Which eliminates some Java 6 related bugs (focus steal, etc.). Also this week i reviewed 4 additional patches and they are waiting for commitment to the source. A few months ago many memory leaks were fixed. But, there are no final release yet, because we don’t have active project lead or many active developers for Spark. We can probably release 2.7.0 final in this state with some issues still open, but i’m not sure we should. It will be released someday i hope, but for now i’m fine using the latest nightly builds, like this one http://bamboo.igniterealtime.org/browse/SPARK-INSTALL4J-642/artifact/JOB1/Instal l4j/

Wroot , thanks for the info .
I’ll check this new version you said .
But I’d like to see improvements in spark the best type SSO implementations , or optimize memory consumption of it . May consume more than 1 gb of ram …

I am very happy to know that version 2.7.0 is about to leave …

Best regards

I think we’ll push hard to get Spark 2.7.0 out after the git transition. New development process, and a new release to boot!

Afterwards, I do not think we’ll wait so long inbetween Spark releases. As it is, 2.7.0 is going to be a HUGE release with a huge number of improvements over vanilla 2.6.3. The changelog is going to be interesting

This really is amazing!
Congratulations to the whole team!
If you need someone for testing or reviews, I can help.

A great way to help if you’re not able to code, would be to download and use the nightly builds. The more people who use it, the easier it will be to discover problems that may botch a release. Just keep in mind that the nightly builds aren’t an “official” release and may change.

This is completely offtopic here, but i have looked through the list of changes and open tickets for 2.7.0. Some issues are still significant (i think some users will be “surprised” to find out that voice chat is not working completely in 2.7.0 and we will have to warn users about such problems in the blog post, but still there will be lots of complaints about various things after the release…). Also some tickets are still “in progress” (in reality most of them abandoned) and not sure who and when will complete them. Nightly build works fine for my needs, but probably not for everyone.

Btw, there is no improvement on SSO i think, unless unintentional And nobody is working on that. As about memory. As i said, there were some memory leaks fixes not so long ago, and Smack is updated a few times since 2.6.3, which also should be less memory hungry. But it is still Java, so it won’t ever be light on memory.

people tend to fix the things that bother them the most

Great work on the update.

Somehow wrecked my Openfire install so installed it again, but now on a Solaris 11 system.

Works like a charm! Thank you!

Hello, i have java version “1.6.0_24” on my linux server. Is needed to upgrade it too? Updating to openfire 3.9.1 was good, updated and java memory increase in openfire file.

Edit: later i saw, was upgraded in .install4j folder. So, openfire use that one insead of system one?

Wow, this is probably 3-4 years old java… Definitely try to upgrade to the latest Java 7 (if you can use Java 7). I can’t say it will use less memory, though, but should have less bugs (in Java). You can check what Java version is in use on the home page of Admin Console.

Thanks for reply, now it is

Java Version:
1.7.0_51 Oracle Corporation – Java HotSpot™ Server VM

updated jdk and jre, to be sure

nice work. glad to see openfire is still alive and kicking.

Hi, Folks! There’s some trouble with SSO on 3.9.1. I’ve upgraded my install AD+Win2k8R2+OpenFire 3.8.2 (SSO Working) to 3.9.1 and noone from nowhere can connect using SSO.

I’ve rolled back to 3.8.2 and everything continues to work perfectly.

Fix it, please! =)

If some debug needed, I can get DC + OpenFire + some user PCs to virtual sandbox, and gather whatever you need.

Im having the same issue after upgrading from 3.8.2 to 3.9.1 We are not using the bundled java since this is on a 64 bit machine. So JAVA_HOME is set in the /etc/sysconfig/openfire folder.

Error in when attempting to view a group is


Problem accessing /group-edit.jsp. Reason:


Caused by:

java.lang.NoSuchMethodError: org.jivesoftware.openfire.group.Group.getProperties()Ljava/util/Map;

The Java version is:

./java -version

java version “1.7.0_45”

Java™ SE Runtime Environment (build 1.7.0_45-b18)

Java HotSpot™ 64-Bit Server VM (build 24.45-b08, mixed mode)

I tried switching to the bundled java which did not fix the problem.

Issues since upgrade

  • Editing/viewing group detail ( 500 error above)
  • SSL communication to a Atlassian Crowd server is sporaddic.
  • hazzelcast clustering is no longer working. Timming out on the heart beats. We are not using UDP.

I gave the error logs to one of our java developer teams and reported “Seems like a really complex error. One of them that keeps occurring is related to timestamp. That is due to parallel processing.”

What do you guys need to investigate further? I can give logs, etc.

The app servers are both running on a vmware 5.5 enterprise cluster.