powered by Jive Software

Question about professional using of OpenFire

Hello,

We (german company) plan to develop an XMPP server. Of course we have evaluated the exititing XMPP solutions and we have stumbled upon 2 of them:

  • OpenFire

  • Ejabberd
    Since we are a Java company, we want to try OpenFire, but we have some question regarding it:

  • Does it support clustering very well? ( that is without too much hassle )

  • How many concurent users does it support? ( we expect a maximum of 10 milion or even more )

  • Where can we go for commercial support, since at some point we may need it ( there are 2 links of the site, but doesn’t hurt asking)

  • Is it actively developed, that are the XEP implemented at a decent rate time, or we end users must implement them if we really need them?

Rehards and sorry If a question sounded maybe silly, we don’t have experience with XMPP world yet,

Ryu

Can’t answer everything. But a few things:

This site is very old and many parts of it are outdated (the only useful thing is the forums and some documentation), but i’m being said that it is too hard to change. So i won’t hope that those professional support links are still valid. Especially for such a scope (10 millions users). Won’t hurt to ask of course.

The new clustering solution was introduced quite recently, but it is constantly in fixing/updating process, not sure if it is ready for big scale deployment http://community.igniterealtime.org/blogs/ignite/2012/09/23/introducing-hazelcas t-a-new-way-to-cluster-openfire

Can’t say how many users Openfire can take. Have heard about thousands or tens of thousands users, but never about millions. Probably with a proper hardware (lots, i mean looots of RAM for Java) and using connection managers… well, i don’t want to guess. As it uses Java it may be hard to use much RAM with JVM, but maybe i’m wrong. You are a Java company, you should know.

Openfire development is not very active and only a few volunteers are usually pushing it forward (and various one time contributors). Releases are not very often, it took a year and a half between 3.7.1 and 3.8.0 releases. ejabberd releases are not very often too (maybe a few per year) and i haven’t used their forums, but at least they have a dedicated commercial support site http://www.process-one.net/en/ejabberd/

Hello wroot and thank you for detailed reply,

Yes, we took in consideration Erlang pretty serious too, but we must provide an explanation to management why a “Java company” chooses anything elese .

I would be glad if you could provide some information, regarding OpenFire, related to

  • push server plugin
  • web socket plugin
  • bosh plugin
  • tools for performance/load testing

Also, as I understood, the Connection Manager module is not required anymore in OpenFire 3.8.1?

To be honest, our decision will be impacted by you, because you’re on the few resources regarding OpenFire

Regards,

Ryu

Well, i’m not an expert, so it will be tough to have just me for information Maybe some one will chip in into this discussion. Or not. Not many active expert users in the forums either.

By Push you mean PubSub? If not, then i don’t know. If you mean PubSub, then there is a support for this in the server, but i can’t say of what completeness (by the XEP standards).

websocket/bosh - i’m not using this, but there are Bosh settings in Admin Console and i personally was able to connect with bosh client (Chrome chat extension) and many years ago with SparkWeb using sockets i think. SparkWeb is not developed anymore. I have also tried websockets in that chrom extension, but that didn’t work for me, so i’m not sure is it working or not. Dele Olajide is an expert in this area. You can read his blogposts @http://community.igniterealtime.org/people/dele?view=blogposts

There are no official performance/load testing tools for Openfire. Everyone is using what they find fitting. Can’t advise anything. Not much load testing need for my 220 users

I think connection manager is still needed in some cases. This is a standalone Openfire version working as connection aggregator and serving them in one connection to the main server (so the main server doesn’t have to deal with huge number of connections).