During about one year and a half, our Wildfire 2.4.4 run fine, but in the last weeks several connection errors began to occur. The number of sessions had grow up until 995 (we are a big company) and then stopped. I think that the maximum number of allowed sessions has been reached. Am I right? We are migrating to Openfire 3.3.3. With this new product will be possible a greater number of sessions? With the Openfire Enterprise Edition this problem would be solved?
The server platform is a Linux Red Hat Enterprise Edition, the DB is Postgresql and the users come from MS AD via LDAP.
Thanks to everyone,
Wildfire 2.4.4 should be able to handle 1000 concurrent users. However, I would recommend upgrading to the latest Openfire version since many many many bug fixes has been solved since 2.4.4. Openfire 3.3.3 has scaled to 150,000 concurrent users in our local tests (btw, we ran out of users so the test stopped). Openfire Enterprise 3.4.0 (to be released in a week approximately) will include clustering support that will let you run the server in several machines so that the service will still be available even after a machine went down. Clustering will also let you scale to much bigger number of concurrent users.
Thanks a lot, Gato. We will proceed the upgrade to Openfire 3.3.3. One question more: we must change the jabber domain, so we think it’s easier to make a new installation and to migrate some tables from wildfire DB to openfire DB, specially the jiveroster, changing the jabber domain, of course. Is this approach a good one?
if you can get the User Import-/Export plugin for Wildfire 2.4.4 it may be an option to use it for the user migration.
The wiki http://wiki.igniterealtime.org/display/WILDFIRE/Home contains three update guides, so it shouldn’t be too hard to follow them.
About 6 months ago, I have upgraded the Openfire to release 3.3.3 and changed the jabber domain name. Due to some problems with AD, the number of users has decreased, but now this problem is solved and the original trouble has appeared again: the service runs very well, but the maximum number of connections to the server is 940. After that, a “jabber id or password error” is delivered to any user trying a new connection.
I thought to install the Enterprise plugin, but none of its features suggested to solve this problem. The question is: how can an Openfire server support more than 1000 connections? I’m sure it’s possible to achieve this goal, but maybe there are some commercial constraints. We would like to continue using Openfire, even paying licences. What do we must to do about?
You may need to increase the amount of memory allocated to openfire. the enterprise plugin is not the anser as it is not even used anymore. the server should support several thousand users.
the other issue is that AD can only handle 1000 request at a time by default. Refer to this site: http://support.microsoft.com/kb/315071
Are you talking about the “Java Memory” percent bar in the Server Configuration Interface? Is it the “java -Xmx256M” parameter? I do not have much practice in Linux…
Thanks a lot.
I’m sure the problem does not come from the AD. So, the java memory is the suspect. From the Openfire configuration interface, the Java Memory size when the maximum connections number is reached (940) is 70% of 963.00 MB. I have looked for the memory parameters at Openfire launching, but i didn’t find any (see attached file). May be the jetty-6.1 uses the default configurations from Linux. The server has Red Hat Enterprise installed and its RAM has 4GB. What the best way? To configure the java memory at the Openfire? To change the memory defaults of Linux? What to you think?
Thanks a lot,
the JVM itself decides how much memory it can use (http://java.sun.com/javase/6/docs/technotes/guides/vm/gc-ergonomics.html --> “Smaller of 1/4th of the physical memory or 1GB”).
So if you want to increase the memory available for Openfire you may want to add “-Xms512m -Xmx1500m” or something like this to the start script.
I have updated the Openfire version to 3.5.2, then the java memory monitoring has changed. It increases and decreases following the number of connections. It’s not linear, but quite reasonable, never higher then 40%. Good, but the problem remains: after 930 connections, the users, including the Console Admin, receive back an “invalid user or password” message. Last week, a new update to 3.6.0: the problem still remains.
Now, it seens that problem is not due to java memory, so let’s see the other suspect, the LDAP. I think that AD’s parameter MaxPageSize defines the amount of users listed at “Users/Groups” tab, not the amount of connections. There is an open thread about this subject in this forum. None other parameter suggests to be responsable for this (see attached file). When the problem occurs, the Warning Log registers a “PLAIN authentication failure” (see attached file). What exactly does it mean? There is no register about this event in the Error Log. About one hour later, when the users went to lunch, the same user (AdminIM) got a connection, as he does every day.
So, when the amount of connections get close to one thousand, the AD do not authenticate new users due to a “PLAIN authentication failure”. Why and what must done to solve this situation?
Thanks a lot for any help,
Depends on the Linux configuration. Finally we have solved the problem: the Linux parameter “ulimit” was changed from “1024” to “65535” in the files /etc/security/limits.conf and /etc/profile. After that, we had almost 1,200 simultaneous sessions supported by our Openfire 3.6.0, using 42% of java memory. I hope this information will be helpful to someone else.
Thanks to everyone that had helped me.