http://www.igniterealtime.org/builds/openfire/dailybuilds/openfire_2015-04-24.de b
Of course that assumes your on *nix/
Thanks. Doesnāt look like there are any RPMs. I do I just replace everything but the config file?
And if you do intend to use that version, it does not play well with large avatars if you have AD integration on. Youāll see it in the log reports, do yourself a favour, get them to chop their heads off and take a new picture for the avatar. Should make it low density then
then you need two things
the tar.gz
and big boy pants
pchetcuti(at)agentanywhere.ca
If you need a hand.
On Ubuntu, we have Alien that converts rpm to deb, donāt have same there? Perhaps it converts the other way as well?
beta RPM Ignite Realtime: Download Landing
Thanks, Daryl
I tried the beta and that didnāt work. CPU still goes nuts. Has anyone tried a fresh install?
At one point I had tried a fresh install and also experienced the problem (though I hadnāt disabled IPv6). I think other people had the same experience.
fyi, Iāve been running 3.10 since the release date without issue.
fresh install
2008r2 with mssql express
java 1.7u79
with 3.10 beta, I also saw 100% cpu, but that doesnāt seem to be the case in my environment anymore. I wonder if this is a linux only issue now.
We were consistently reproducing this issue on Linux (this ignite Openfire server) during the development process. All of my current systems are on Linux and not seeing this issue. We had hoped the troubles were behind us!
Looking at NioSocketAcceptor (#281) I wonder whether the NIO problem was ever fixed. The code contains no timeout value so the default timeout 0 is used. And this is the timeout value which could cause the epoll loop:
protected int select() throws Exception {
return selector.select();
}
As the MINA source is included in Openfire I hope that the same code as in NioSocketConnector (#290) can be used: return this.selector.select(timeout);
Do also Windows users see this problem or is it a problem of the Linux VM implementation?
Windows here. We upgraded from 3.9.3 to 3.10.0 and within a couple hours we started getting pegged CPUs. It keeps happening every couple hours and we have to manually kill the Openfire process and restart the service. Itās getting old quick.
Windows 2008 R2 Standard
Openfire 3.10.0
Java 1.7.0_76
We are not using AD auth.
I have added the system property ājava.net.preferIPv4Stackā with the value ātrueā without joy.
Our experience was the same as Cryptic ITās. We ended up reverting back to 3.9.3, which remains stable.
Windows 2008 R2 Standard
Openfire 3.10.0 (upgrade from 3.9.3)
Java is not separately installed on the server, using Java packaged with Openfire
We are using AD auth
I also tried the java.net.preferIPv4Stack option and it didnāt resolve the problem.
how many users, and are you guys running any plugins?
We have around 100 total users, with 40-50 max online at a time. Many never log in. The only plugins we are running is Jappix for Openfire (0.0.0.6) and Search (1.6.0). It is possible search was updated as part of the 3.10.0 upgrade, I didnāt look and am back on 3.9.3 now.
775 users. Probably a couple hundred on at a time.
Plugins:
Broadcast : Broadcasts messages to users. 1.9.0 Jive Software
Presence Service: Exposes presence information through HTTP. 1.6.0 Jive Software
Search: Provides support for Jabber Search (XEP-0055) 1.6.0 Ryan Graham
For me, I test it on our little family server before going production at work which is a few 100 users.
Spiking for me with 8 users. No plugins. Pretty vanilla - not even doing any LDAP tie-in, just the local database.
In case it helps any, Iām running 3.10.0 on Windows Server 2012R2 with no CPU spike issues. I am using Java 1.8.0_45 64 bit (using instructions I found on this site for using 64 bit Java instead of 32, I have no idea why thatās not the default in the Windows builds in 2015 but thatās another topic). AD integrated. My clients are all connecting with the latest stable build of Jitsi.
Funny that you mention Jitsi. With the OpenFire 3.9.3 release we saw a huge spike in memory usage on the server and our Mac clients running iChat/Messages saw huge spikes in local CPU usage. With OF 3.10 it just seems like CPU in the only issue. Weāre running CentOS 5.11 32 bit.