Open Realtime
Ignite Realtime is the community site for the users and developers of open source Real Time Communications projects like Openfire, Smack, Spark, and Pàdé. Your involvement is helping to change the open RTC landscape.
The Ignite Realtime community is pleased to announce the release of Openfire 5.1.1, a maintenance update to our open-source XMPP real-time communication server!
Following last month’s 5.1.0 feature release, we’ve been gathering feedback and tracking down the issues that inevitably surface once a bigger release meets the real world. Openfire 5.1.1 is the result: a focused round of bug fixes and improvements, with a particular emphasis on PubSub correctness and connection handling.
A good chunk of this release tidies up PubSub behaviour. We fixed excessive memory consumption caused by a bloated ofPubsubSubscription table (OF-3306), alongside various smaller issues related to pub/sub functionality.
Connection handling gets some attention too. We resolved a nasty case where IQBindHandler could busy-wait up to 20 seconds on a resource conflict, causing thread starvation and misbehaving (OF-3319), fixed a NullPointerException in outbound S2S DirectTLS connections (OF-3332), and a number of other networking-related issues.
Certificate SANs now encode IP addresses correctly as iPAddress rather than dNSName (OF-3324), which should fix an issue that popped up under certain network configurations with recent versions of the Conversations client.
We also cleaned up a couple of migration-related issues carried over from 5.1.0’s database work, such as XML properties failing to save during PBKDF2 migration (OF-3305). This should guard against accidental loss of the encryption keys, preventing installations that become effectively unusable when migration happens while the file system is in a faulty state.
The full changelog has all the details, with 24 items resolved in total.
You can obtain Openfire 5.1.1 for your platform from its download page. The sha256sum values for the release artifacts are:
dc887032619b7ecf66cc8c17dc5cedc13c2479525cd93b41e5d999e4ec942adf openfire-5.1.1-1.noarch.rpm
4f6c5ccfe44fdd494760ae5a6f00f971ea000ec6c69e1481d3546bed994598e2 openfire_5.1.1_all.deb
17eafa2641a5cbe226328d54e115fd1780a90d6fedb6d63d8bcea048f91f23ab openfire_5_1_1.dmg
68b69309f22435e4996b18b21a451d8c3b98a543aa8680436694bf4a235b8299 openfire_5_1_1.exe
d930be11c93c995ee0a045118d0539629bd27d983ad99e6f174ded6453612a0d openfire_5_1_1.tar.gz
b55659388274deedde92813ed830e1060c89b48fc3d61e6227c153bd4d96b57e openfire_5_1_1_x64.exe
9faa8900c8aa56822deb83c82339842794b6e2e58be61ca08dbdf948ee931cd6 openfire_5_1_1.zip
Many of the issues fixed in this release were reported by our community members, and several of those were instrumental in finding and fixing bugs and applying improvements. We greatly appreciate everyone’s feedback! We’d love to hear from you! Please join our community forum or group chat and let us know what you think!
For other release announcements and news follow us on Mastodon or X
The Ignite Realtime community is pleased to announce the release of Openfire 5.1.0, the latest version of our open-source XMPP real-time communication server!
Since the 5.0.0 release, now over 11 months ago, we’ve kept the 5.0.x branch stable and maintained, but have also been working on the next set of bigger changes. With this release, those have (finally - sorry for the wait!) been made available. If you’ve been following along in the chat or forums you might have seen pieces of it being put together: the channel binding work, the DNS improvements, the new database experiments have been in the works for quite some time, and have seen quite some discussion and collaboration. Let me give you an overview of what is included with the 5.1.0 release.
The biggest theme is security. With generous support from NLnet Foundation 
we’ve implemented SASL channel binding (OF-2694, OF-2879), which ties authentication to the underlying TLS connection and closes the door on a class of man-in-the-middle attack that has been observed against real XMPP servers in the wild. While we were in that part of the codebase, we also audited the encryption utilities, and found a few things worth fixing. A hardcoded AES initialisation vector (OF-3074), a single-round unsalted SHA-1 used for Blowfish key derivation (OF-3075), CBC-mode padding that was susceptible to oracle attacks (OF-3077), and timing side-channels in SCRAM-SHA-1 authentication (OF-3257, OF-3258). None of these were discovered under active exploitation, but they’re the kind of thing that shouldn’t be there, and now they’re not. We’ve also tightened up certificate identity handling (OF-3122), SASL mechanism enforcement (OF-3273), and login throttling (OF-3262), and added proper support for trusted reverse proxy configuration (OF-3260, OF-3261).
There’s also a performance fix that deserves a mention. Community members reported this issue in the PubSub functionality: after investigation, we found a method in the persistence code doing a full linear scan of every node in memory for each row it processed from the database (OF-3196). That’s O(n²), which is fine at small scale and quietly catastrophic at large scale. On a deployment with around 600,000 pubsub nodes it was causing startup times of over two hours. The fix was not much more than a one-line change. If you’ve ever accepted a very long Openfire startup as just a fact of life, this release is for you. Alongside that, blocking operations have been moved off Netty’s event loop threads (OF-3176) to improve responsiveness under load, and we’ve upgraded to Netty 4.2 (OF-2957).
5.1.0 also brings some ecosystem-related updates to Openfire. Java 25 is supported (OF-3210), and three new databases join the supported lineup:
- MariaDB (OF-3239), which many operators have been running as a MySQL stand-in for years anyway;
- Firebird (OF-3237), for the on-premise environments where it’s been quietly doing the job for a long time; and
- CockroachDB (OF-3238), for distributed and cloud-native deployments.
Support for these has not landed in most plugins yet, but we’ll work on that in the coming time. In the mean time, please try them out, and tell us what you think!
On the protocol side, Openfire now handles XEP-0398 (avatar synchronisation between XEP-0084 and vCard-based avatars, OF-2034), and provides a proper API for Service Discovery Extensions (OF-3188) so plugins no longer need to intercept IQ stanzas to enrich discovery responses. For operators, there’s a new diagnostics page for failed S2S connections (OF-3037), a UI for managing DNS overrides (OF-3244), configurable rate limiting for incoming connections (OF-3170), and a Docker healthcheck (OF-3184).
The bug fix list is long, but a few stand out: orphaned S2S routes that caused silent packet loss (OF-3193, OF-3201); encrypted properties being silently stored in plaintext after XML-to-database migration (OF-3296); plugin reload failures on Windows (OF-3208); and chatroom subjects not being delivered on join in certain conditions (OF-3131).
The full changelog lists 121 items resolved!
You can obtain Openfire 5.1.0 for your platform from its download page. The sha256sum values for the release artefacts are:
0686b30d4fb5e6f7c43bff7071ac425e45a19bbd528e301df065ef8d60355ef5 openfire-5.1.0-1.noarch.rpm
90b21993ba65d98357154183fd12e938547e68cbc59301f69b8506f483580269 openfire_5.1.0_all.deb
5fff05c4a689ae3431d5578f594e37cf7a68a2c0f36380b76d132d79217913c0 openfire_5_1_0.dmg
f72d766957eb09bedcbe8a5f64c38db85684af62bf5282534a162385f7b449ed openfire_5_1_0.exe
0cc848b56339f07fdcbcbb92dea73a35c00661576d68f1908640ecf7c3b6febc openfire_5_1_0.tar.gz
a830b0451770d6c8f8db81b3584299f54c48ca8c6d4bf42671325fef0b74c878 openfire_5_1_0_x64.exe
8b3f30505b3996b4b8261a99710ac2387131dac9b5a75fbbf65e9e3419aa22f5 openfire_5_1_0.zip
We’d love to hear from you! Please join our community forum or group chat and let us know what you think!
For other release announcements and news follow us on Mastodon or X
As we’re preparing the upcoming Openfire 5.1.0 release, I’ve been spending a lot of time looking at parts of the codebase that have been around for a long time.
Some of them date back to assumptions that were perfectly reasonable when Java 5 was current, IPv6 was still considered “future tech”, Docker didn’t exist yet, and “cloud-native” wasn’t a phrase anyone but meteorologists used.
Yet somehow, Openfire deployments that started in those days are still running today.
That got me wondering:
What’s the oldest Openfire deployment that you still run?
Not necessarily the oldest version (although I’d love to hear that too), but the oldest continuously running installation, the oldest surviving user database, or perhaps the weirdest setup that somehow still works despite years of upgrades, migrations and changing infrastructure.
I suspect there are Openfire instances out there that have survived datacenter migrations, moved from physical hardware to virtual machines to containers, switched databases more than once, and outlived several generations of administrators. Some probably still contain configuration decisions that nobody fully understands anymore. Is anyone still running Wildfire? Jive Messenger?
Honestly, I love those stories from the trenches. The odd workarounds, the “temporary” fixes that became permanent infrastructure, the upgrade that everyone expected to fail but somehow didn’t, or the deployment that quietly kept running for a decade without anyone thinking much about it.
One of the things I appreciate most about infrastructure software is that success often becomes invisible. If a messaging server quietly keeps working for ten years, nobody talks about it. But that kind of stability is actually a huge achievement (both for the software and for the people operating it). I think that’s something we, as a community, can be genuinely proud of.
For Openfire 5.1.0, we’ve been modernizing quite a few internals:
- support for Java 25
- upgrades to Netty 4.2 and various database drivers
- improvements around reverse proxies and DNS handling
- clustering improvements
- security hardening
- performance fixes for larger deployments.
While doing that work, we constantly try to balance modernization with compatibility for long-running installations. That balancing act becomes much easier when we understand how people actually deploy and operate Openfire in the real world, which, apart from simply wanting to hear your stories, is another reason for me to ask this question.
So: I’d love to hear your stories! How old is your deployment? What version did you start with? What infrastructure changes has it survived over the years? Are there plugins or integrations you absolutely depend on? What operational lessons have you learned?
And perhaps most importantly: what surprised you most about running Openfire long-term?
I’m hoping this thread becomes a collection of deployment stories, operational lessons, and perhaps a bit of Openfire history.
Looking forward to hearing your stories!
We’d love to hear from you! Please join our community forum or group chat and let us know what you think!
For other release announcements and news follow us on Mastodon or X
The Ignite Realtime community is pleased to announce a new release of Openfire, version 5.0.5. The full changelog has more details with the highlights being bug fixes and bundled library updates whilst we continue to work on an upcoming 5.1.0 feature release.
You can obtain the new version of Openfire for your platform from its download page. The sha256sum values for the release artifacts are:
4ba9b6476efefc54378c0fd4a2a402177fd94bc11512354db887eb446f37f211 openfire-5.0.5-1.noarch.rpm
3a870ef09415f3bf2eac315ac826b59997eba6bcc38a1eb3740856ff16ffc11c openfire_5.0.5_all.deb
94d3a8a159a68fdff17394c415d3ce1feb557fb8ef0618a883180f668a359cc2 openfire_5_0_5.dmg
bbc4c1147ff1a4d8740a5e12929e650dc04e3c7a6c765ff13855da48c16f980a openfire_5_0_5.exe
50028a20587ea9d6b5bcc8260ca626e022d223b39748ffe7b9851d9b344dba6b openfire_5_0_5.tar.gz
649f3b14a5403275780a2344b2d575f163a2e182eefa9c4978bd325cbf7486d5 openfire_5_0_5_x64.exe
49edd9873a84d2f6b19c24d360ac964ea9180753f6dff4355d75be3943e20817 openfire_5_0_5.zip
For those of you that enjoy metrics, here’s an accounting of 5.0.4 release artifact downloads.
| Name | OS | Downloads |
|---|---|---|
| openfire_5_0_4_x64.exe | Windows 64bit Launcher | 7,156 |
| openfire_5_0_4.exe | Windows 32bit Launcher | 4,963 |
| openfire_5.0.4_all.deb | Linux Deb | 4,455 |
| openfire_5_0_4.zip | Zip binary | 4,013 |
| openfire_5_0_4.tar.gz | Tar.gz binary | 3,526 |
| openfire-5.0.4-1.noarch.rpm | Linux RPM | 3,232 |
| openfire_5_0_4.dmg | Mac | 2,768 |
| Total | – | 30,113 |
We’d love to hear from you! Please join our community forum or group chat and let us know what you think!
For other release announcements and news follow us on Mastodon or X
I have recently started experimenting with adding support for three additional databases in Openfire: MariaDB, Firebird and CockroachDB.
This work is still exploratory. Before committing to this direction, I would like to get a better understanding of whether this is actually valuable to the Openfire community.
I have prepared initial pull requests for each database:
- MariaDB: https://github.com/igniterealtime/Openfire/pull/3240 (OF-3239 in our issue tracker)
- Firebird: https://github.com/igniterealtime/Openfire/pull/3241 (OF-3237 in our issue tracker)
- CockroachDB: https://github.com/igniterealtime/Openfire/pull/3243 (OF-3238 in our issue tracker)
These are not production-ready, but intended to validate feasibility and surface any obvious issues.
Why these databases?
MariaDB is widely used as a drop-in replacement for MySQL. Although Openfire supports MySQL, MariaDB is not explicitly treated as a first-class option. Given how often it is used in practice, formal support could provide more confidence for administrators.
Firebird represents a more niche but still relevant ecosystem. It is commonly found in long-lived, on-premise systems where changing the database is not realistic. Supporting it could make Openfire easier to adopt in those environments.
CockroachDB targets modern, distributed deployments. With its PostgreSQL compatibility and focus on resilience and scalability, it could make Openfire more attractive for cloud-native and multi-region setups.
Trade-offs
Supporting additional databases comes with a cost: more code paths, more testing, and more long-term maintenance. The key question is whether the added flexibility justifies that complexity.
Feedback wanted
Before taking this further, I would really appreciate feedback from the community:
Are you using (or considering) MariaDB, Firebird or CockroachDB with Openfire? Would official support influence your deployment decisions? Do you see this as valuable, or as unnecessary complexity?
Please share your thoughts on the pull requests or through the usual community channels!
For other release announcements and news follow us on Mastodon or X
Ricardo in "
Bill Roland in "
Guus der Kinderen in "
rahulchavan1 in "
Jajo in "