Skip navigation
All Places > Ignite Realtime Blog > Author: Gaston Dombiak

Ignite Realtime Blog

15 Posts authored by: Gaston Dombiak Champion

We are happy to announce that the clustering plugin is now available as an open source plugin. The clustering plugin adds support for running multiple redundant Openfire servers together in a cluster.  By running Openfire in a cluster, you can distribute the load amongst a number of servers, as well as having some form of redundancy in the event that one of your servers dies.


By making this functionality open source we now made 100% of the old Enterprise plugin open source. The reason why the clustering plugin came last is that it relies on Oracle Coherence, that is a commercial product, so to make it open source was a little tricky. At the end what we did was to open source our implemented functionality but to use this plugin you will need to get a valid Oracle Coherence license. The readme file explains the steps to follow to install this plugin. Moreover, it also explains how to setup your environment if you plan to develop new versions of the plugin.


Have fun,


  -- Gato

Picture 5.png


Should I say more? I will create another blog post with detailed information when we push out the final release. Stay tuned.


  -- Gato

Whack 1.0 has been released. Whack is our Open Source XMPP (Jabber) component library for XMPP components. External components are processes that run outside of the Openfire's process but can connect to the server to register new XMPP service. Whack is an implementation of XEP-0114: Jabber Component Protocol.


Unlike the other igniterealtime products, Whack followed a different evolution path. We started coding Whack around November 2004 and after a few months it was operational. Openfire and Whack share the same component's API so around 2005 we were able to run Fastpath as an internal component (i.e. running in the Openfire's process) or just move it as an external component using Whack. It was impressive seeing the same code running as internal and external. Since then Whack continued to evolve but always at a very slow pace. Whack was always stable in each step but it was just not ready for prime time. We wanted to keep adding more things to it to reach a 1.0 release. Since our collaboration software Clearspace uses Whack to integrate with Openfire we needed to push the boundaries of Whack once again and I'm happy to say that we now reached the 1.0 release. And that is why we decided to make a public release in 2008 after 4 years of continuous but slow growth.


A few months ago we also released a new product called SparkWeb. SparkWeb is our Open Source web-based IM client. SparkWeb is based on XIFF just like Spark is based on Smack. Today we updated the products page to list SparkWeb as an official product. Welcome SparkWeb! The family has grown a little bit now.


You can get Whack from here. Questions could be posted to the Whack forum.


SparkWeb can be downloaded from here. If you want to build from the source code you can read the Getting and Building SparkWeb document.

The Fastpath product allows a company to provide support through the web. Users can use their own XMPP client or the provided web client to initiate a chat request. The request will be routed to the proper queue and agents will be offered the chance to answer the request.


Today we made the source code of the web client part of Fastpath available and a new version was released with the change in the license. You can download the new version from the plugins page.


Use the following SVN access to get the source code of the web client:


svn co webchat


The web chat client relies on the workgroup API that has not been moved to the open source repository yet. That is our last task in this long process of making Fastpath open source.




  -- Gato

It took us some time but we finally made it. The Enterprise Edition plugin has been broken into smaller open source plugins as mentioned in the Turning Openfire Enterprise into an open source product blog post.


The new plugins can be found here:


With these new plugins the total number of official open source plugins is now 17. If we add the clustering plugin that is commercial and the 3 beta plugins that includes the popular Red5 plugin the total number of plugins comes up to 21. Finally, more plugins can be found in the Non-Jive Openfire Plugins document.




The Openfire Team

We're in the process of making the Openfire Enterprise module Open Source (see Matt's blog). The Enterprise module provided several areas of functionality that were available as a single plugin. A quick list:


Reporting - a dashboard with statistics about server load, user sessions, chats, groupchats, etc. and support for executing reports.

Chat archiving - support for tracking conversations taking place on the server. Both one-to-one and groupchat conversations can be archived.

SparkWeb client - the web-based version of the successful Spark client.

Clustering - support for running several machines hosting the same domain. Thus adding fail-over and better scalability of the server.

Client control - controls whether certain features are available or not in the Spark client (e.g. file transfer, broadcast, groupchat, etc.). Moreover, it is also possible to specify which clients can connect to the server, push new versions of the Spark client and populate rosters with groupchat bookmarks.

Fastpath - provides rich web-based click-to-chat functionality with support for requests to the best available operator in queues. It's ideal for web-based realtime helpdesks.


Turning a commercial product into an open source product implies more effort that one would initially estimate. Therefore, we are going to break this process in two stages. During the first stage we will offer several plugins that will include the features listed above (with the exception of clustering). Our clustering solution relies on a commercial product and will not be made Open Source. The output of the first phase will be:


  • Reporting and Chat transcripts plugin - this plugin will include the reporting and chat transcript functionalities

  • SparkWeb - SparkWeb will be available as a separate project and not as an Openfire plugin

  • Client Control plugin - the ability to manage clients will be available as an Openfire plugin

  • Fastpath plugin - the Fastpath application will be composed of an Openfire plugin and the WebChat plugin. The webchat.war plugin can be deployed to Openfire as a plugin or can be deployed to your application server (e.g. Tomcat) of choice.


The second stage of this process will include:


  • Reporting and chat archiving - This functionality was available as a plugin in stage one. For stage two we will evaluate making it part of the server itself.


Stage one is planned for April 27th, 2008. That means that two weeks from now we will have most of the functionality included in the enterprise edition available as open source plugins. No clear date has been assigned to stage two but it should take place a few months after stage one.

The next major release of Openfire is going to be 3.5.0 and it will be released on March 6th. Daniel and I are very happy with this new release since it has lots of new features and improvements. Today I will explain how you can be connected but invisible to all or some users. This has been a very popular request in Openfire and in XMPP in general.



A few XMPP extensions were created for invisibility using different strategies (and may be goals). Some of them focused only in blocking your presence to other users while others were blocking incoming/outgoing presences, messages and IQ stanzas. But they have something in common that jeopardized their success. In a nutshell, they not only required server side changes but also client side changes thus making it hard for a user to find a server and a client that supports them.


As of Openfire 3.5.0 there is a very easy way to be invisible and at the same time be able to maintain a one-to-one chat, a group chat or appear visible to the users of your choice or gateways of your choice. The best part of it is that we are not relying on any XMPP extension but just using the XMPP RFC core.


Usually XMPP clients follow these steps while logging in:

  1. Connect to the XMPP server

  2. Secure the connection with TLS

  3. Authenticate with the server using SASL

  4. Send available presence to the server indicating that the client is now publicly available (e.g. <presence><priority>1</priority></presence>)

  5. Request their roster


The forth step is actually optional so if clients do not send an available presence then they will be connected to the server but will not appear available/online to other users. Unavailable users cannot get messages from other users unless they made available to them.


When the user decides to appear as online to someone in particular he can send an available presence to that user (e.g.

). Being available to a user means that the user will see you online and you can now chat with that user.


Users that are publicly unavailable can also join a room and have a groupchat. However, if the room is not anonymous (i.e. real JIDs are sent to room occupants) then the other users will know that you are connected and chatting. But probably you won't care about that unless you wanted to chat without anyone knowing that you are you.


Currently our Spark and Sparkweb clients are not able to join in invisible mode but implementing invisibility this way should be a lot less work for clients than implementing some XMPP extension.

As of December 2007, we have jumped onto the release train process and have been releasing a new version of Openfire every 3 weeks. Many important features have been added and several issues were fixed. Here are some relevant new features that were added:


  • Certificates created and signed by CA can be imported from the admin console

  • Added support for XEP-0115: Entity Capabilities

  • Avatars may now be updated when using LDAP

  • Improved connection pool recovery logic by switching to proxool

  • Created Email Listener plugin


For the first and second quarters of 2008 we decided to focus on features that are going to be useful for enterprises, but not restricted to the enterprise product.  Example of these features are:


Use TLS and SASL when connecting external components

A new extension named XEP-0225: Component Connections was created for this feature that we think it's going to be useful for companies with very strong security requirements. This feature will not only require some changes to Openfire but also to our Whack library. Whack is our external components open source library that we never pushed publicly in the community but we do support and use internally.


Let external components connect to the same Openfire instance and register for the same domain

In order to provide redundancy in external components we should let them connect to the same Openfire instance. Openfire will then use round robin to distribute the requests to the connected external components. Therefore, only external components that are stateless can use this feature unless they are stateful and communicate amongst themselves, perhaps in a cluster environment. Similar to the previous feature this feature will imply a change on Openfire and also to the Whack library.


Add auditing support to the admin console

Many people have requested this feature and it was decided to implement it for Openfire 3.5.0. When running standalone the auditing information will be stored in the database of Openfire but when running integrated with Clearspace then the auditing information will be stored in Clearspace which acts as the main repository.


Database optimizations

In the past we focused on optimizing the Java code when under heavy load and now it's time to focus on the database specially when dealing with large sets of data. This work should help users log in faster, retrieve their rosters and perform any frequent operation quicker. Overall we know that Openfire has great performance but doing an in-depth review is never a bad idea. 


Release a new version of XIFF

While working on SparkWeb, our web version of the popular Spark client, we ended up doing lots of nice improvements to the XIFF library. Having tested those changes for a while we now feel confident to push out there a new release of XIFF. Meanwhile, every week we have been updating our SparkWeb instance that is publicly available. Feel free to use it and give us your feedback.


Other things that have been brewing in our heads but are still not planned for the immediate future are:



If you are interested in seeing some other feature that has not been planned please speak up and leave us a comment. We will create a Jira issue, if one does not exist, so people can vote. Highly voted issues are taken in consideration when building the roadmap of the products. The current roadmap can be found here.




  -- Gato

Many years ago when I started adding certificates management to Openfire I couldn't stop thinking how complex the certificate management topic was. Moreover, I thought that the lack of information regarding certificates management was on purpose as a way to keep them "secure".


Even though I do not consider myself an expert in security and certificates in particular, I think I finally understood the different ways certificates can be created, signed by Certificate Authorities (CA) and finally be imported into your application. Basically there are two ways for this to be achieved and fortunately the XMPP Federation through its CA services supports both of them.


Create your certificate and ask a CA to sign it


In this case you will create a certificate from the admin console of Openfire and then ask Openfire to create a Certificate Signing Request (CSR) that is sent to the CA. The Certificate Authorities (CA) usually has a web site that you can use to paste the CSR. If you are using the XMPP Federation services, choose the menu option Server Certificate (Without CSR generation). After the CA verified the certificate data and the data of the certificate issuer you will get a signed certificate that you will need to import into Openfire from the admin console.




The CA creates a certificate for you and signs it


In this case almost the entire process happens in the CA web site and administrators will need to import the signed certificated into Openfire. If you are using the XMPP Federation services, choose the menu option Server Certificate (With CSR generation) and then provide a pass phrase to create the certificate and its private key. After the data was validated you will receive a signed certificate. The last step to import the new certificate into Openfire is to paste the pass phrase, private key and signed certificate in the import certificate page in Openfire and voila.




As of Openfire 3.4.2 you will be able to choose the certificate management option that best fits you and follow the entire process from the admin console. You will be able to say bye bye to the cumbersome command line tools. If you are using Openfire 3.4.1 or older then only the first option is supported.

Gaston Dombiak

Openfire Unleashed

Posted by Gaston Dombiak Champion Oct 31, 2007

Openfire is the award-winning instant messaging server known for its simplicity, elegance, performance and extensibility. With each new major release, scalability has been improved; however, being able to scale a lot without redundancy or high availability poses a risk to every connected user if the single server goes down.


After many months of work that risk is now part of the history. Openfire Enterprise 3.4.0 provides support for clustering. Clustering will let you run Openfire on several machines serving the same XMPP domain. Clustering can be enabled with just one click from the admin console. Machines running Openfire Enterprise will automatically meet between them to form a cluster. With clustering you not only get high availability but also improved scalability. In our internal load tests, we got more than half a million concurrent connections sending lots of packets in a cluster of just 2 nodes.


Another nice addition to Openfire Enterprise is SparkWeb. Users can now connect to the server and chat from your website. Read the SparkWeb: Next Generation blog post for more information.


On the open source side we also have excellent news. More than 30 new features and more than 30 bugs were fixed. Personal Eventing via Pubsub was added so you can now publish your geo-location, music you are listening to and let subscribers be alerted.  From the admin console you can manage users roster. Moreover, it is now possible to retrieve photos from LDAP and use them as users avatars. The complete set of changes can be found here.


You can download Openfire from here. Openfire Enterprise can be downloaded from here.




Openfire Team

During the last few years we have been listening to the community and our Openfire Enterprise customers. You all had the same question: "When will Openfire support clustering"?


I'm happy to report that Openfire 3.4.0 Beta now has support for clustering. Clustering will let you run several machines serving the same domain thus allowing you to scale your services and at the same time providing continuous service even if one machine goes down. Today we are officially starting the beta process that will last until October 31st.


Unlike other Ignite beta programs, this beta comes with benefits and important discounts for those of you that help us test the server. We had to rewrite big portions of the server, and we would like to get many people testing the server to ensure a better product. We thought these incentives might help us recruit more beta testers.


You should know that we have initially tested the server internally and even deployed it to our public servers, so this beta may be more stable than some other beta products.


People interested in participating in the beta program can read this welcome document to learn more about the benefits and discounts you can get by participating.  You can find all of the information (download links, documentation, instructions, and more) in the new Openfire 3.4.0 Beta space in the Ignite Community.


Smack uses an XML Pull Parser (XPP) to parse XMPP stanzas and build custom Packet objects. Wildfire represents XMPP stanzas as DOM objects wrapped by Packet objects. Each approach has its own pros and cons. Moreover, in Wildfire we can use different parsers to generate DOM objects.


For Wildfire 3.2 we needed to change the way we were parsing XML to work with the new, more scalable, networking layer built using MINA. We wanted to keep building DOM objects wrapped by Packet objects so our parsers were still useful. However, we needed a way to parse stanzas received in an asynchronous way. We ended up reusing a contribution made by a community member. We know that it is a custom solution that we might need to replace at some point since the parsing is not 100% efficient and some cases may potentially break the parser as was seen in Wildfire 3.2.1.


Anyway, while doing some heavy load testing on Wildfire and measuring performance we noticed that the parser we were using to generate DOM objects was becoming a serious bottleneck. At that point we were using a SAX parser (SAXReader) so we decided to try with other parsers and compare results. The other parser that we had in Wildfire was XMPPPacketReader that uses an XML Pull Parser (XPP).  To my surprise the performance improvement was substantial with the new parser: around 30% faster with the XPP parser compared to the SAX parser.


Architecturally it is obvious that an XPP parser will be much faster than a SAX parser, but since both parsers were being used to create DOM objects I initially thought  it wouldn't make much of a difference which one was used since building DOM objects was the expensive operation. Well, I was simply flat wrong and I learned it the hard way. I'm happy, though, that we found this bottleneck during our performance tests prior to release. It is yet another proof of how important it is to include QA as part of your development cycle.


How does building software for an open source community compare to the commercial world? It has been three years since I started working on an open source project. Before this exciting work I spent ten years building commercial software and I can tell you that the differences are really big both on the final product and the way the product is being built.


Here at Jive we are very focused on solving business problems rather than building cool technical solutions just because they help increase our ego. A consequence of this philosophy is that the community feedback is key to building a successful solution. This is one of the reasons I would like to thank you all for helping us build Wildfire into the product that it is now: a successful product that is growing and becoming more popular with each new revision.


Now back to the initial question. Is it really that different to build open source software compared to commercial software? As I said the answer is yes and let me give you a concrete example:


There was a time when Wildfire didn't have support for SASL and I have to say that I had no idea about SASL. Fortunately, there was a community member that provided the first implementation and that was a great opportunity to review his work to ensure quality standards and at the same time learn about the subject. Moreover, a few month later we heard that other community members were adding Single-Sign-On and also GSSAPI as SASLextensions. I said: Wow, this is great. The community keeps providing some cool new features that are much needed and I'm not an expert on this area.


It was clear to me that having a big community was much more powerful than just having several developers and a few product users. Another way to understand the difference is to split the question in two areas: 1) product quality, and, 2) product development and support.


Product Quality


Wildfire has an incredibly large community behind it and we can safely assert that, due to statistics reasons, the more people use a product the more chances a product has for maturing and becoming a solid solution. The number of downloads we are registering is immense and the number of problems we are receiving is proportionally inverse. Of course, this was not the way things used to be. I think that the key to becoming a mature product, in our case, was being strict in running automated or manual test cases before delivery code to the community. In addition, the number of setups that are out there helps ensure that someone has to have already used the software the same way someone else is doing it. In summary, the bigger the community the more chances a product has for becoming a solid product. Let's leave the analysis of the reasons why our community grew out the way it has grown for another post.


Product Development


Supporting an open source community is radically different from supporting commercial companies. The first thing that an open source product has to build, besides the product itself, is a community. For that it is key to have a good site that allows community members to meet up, collaborate, share experiences, problems, etc.. The second challenge is to organize your time so that you can keep thinking and implementing new product features or bug reports and answer questions posted in the forums. While building commercial solutions there is naturally a bigger distance between developers and end users and usually customer support handles customer requests. In open source products, the developer is much closer to the end users so it is always a challenge to focus on work and the community at the same time. I can tell you that this is a very hard challenge but it pays off at the end.


Wildfire 3.2.2 is out now and  I guess that this long post is just a way to thank you all for building Wildfire the product that we are all proud of.


The parody movie This is Spinal Tap includes a hilarious scene where the members  of the "loudest band in the world" point out that their amplifiers can actually be turned up to eleven. I was reminded of the scene as we've been doing scalability testing on the next version of Wildfire. It turns out we had little idea of how far we could push the limits -- we keep cranking the "scaling knob" louder and Wildfire just keeps scaling. 


So far we've hit 33k concurrent users with a single connection manager, running on a (old) Sun 280R server. CPU usage in the connection manager and core Wildfire server both hovered around 7% each. Those numbers are a pretty huge improvement over the previous version of Wildfire, which was barely able to hit 7500 concurrent users with maxed out CPU and memory usage. We're also only part way through the optimization process. The goal for the 3.2 release is to demonstrate 100k concurrent users on a single domain.


How did we get here? In Wildfire 3.2 we decided to replace our networking layer with Apache MINA, giving us support for asynchronous I/O and a foundation for better scaling. For testing, we created a Wildfire plugin that generates users, populates rosters and creates vCards. The rosters are populated with 20 to 30 contacts each. We've been using the load testing tool Tsung. Tsung is a master-slave tool, and for our tests we are using four slaves.


As we've tested ever higher scalability numbers, we've made lots of core code improvements along the way. For full details, see my forum post. The goal for this week is to reach 50K concurrent users. But based on our experiences over the past couple of weeks, that might not be much of a challenge at all.


Every time I've had to deal with SSL/TLS certificate handling in Java it's been hugely frustrating and time consuming. There's a lack of good information and examples published, and getting anything done requires using multiple libraries (the built-in JCE in some cases, Bouncy Castle in others, etc). That's resulted in a functional but not very easy to use certificate handling feature in Wildfire. The numerous threads in the Wildfire forum posted by users trying to create and import certificates proved to me that we had more work to do on this feature.


A guiding philosophy for Wildfire is ease of use and and certificate management should follow that same spirit. The current certificate management tools in Wildfire are anything but easy to use. The command line keytool application is used to manage the Wildfire certificate store to create certificates, generate signing requests and import signed certificates. Just to make things a little more difficult, the XMPP specification states that a particular extension should be included in certificates to specify the domain of the XMPP server. It's not possible to configure and set that extension using keytool, so the previous workaround was to use OpenSSL to create certificates. That's a major pain given that OpenSSL and keytool use different formats, which requires an extra format conversation step. No wonder users are having so many problems! Wildfire 3.2 does away with all this complexity by turning the painful process into a few clicks in a web-based interface.


The Jabber Software Foundation (JSF) has also been working to make the certificate process easier by becoming an Intermediate Certification Authority for the XMPP network. It will soon be easier (and cheaper) to obtain a signed certificate that provides much better security than a self-signed certificate. I'm happy to announce that Wildfire 3.2 will fully support certificates created by the JSF ICA.


I was hoping to show some screenshots of the new certificate handling pages in Wildfire, but they haven't gotten the Vanderzanden touch yet to make them pretty. However, the 3.2 release gets closer every week, so look for the feature soon.


Filter Blog

By date: By tag: