powered by Jive Software

Slow first login after openfire service restart

Hello, I’m finding that anytime that the openfire service is restarted it takes a long time (2+ min) for the user to login the first time. It appears that after ANYONE loggs in, it still takes longer to login for the other users (30 sec or so). After a user has logged in, if they log out and back in they get in wquickly (inside 5 sec or so) unless the services is stopped, then were back to the initial behavior again. I would llike to avoid this behavior. Doesnt seem to matter what client I use (Spark, Pandion, Pidgin). Using OpenFire 3.6.4.

The only thing I can think of is that due to our AD structure, I cannot point the Base DN at an isolated place, it basically just has top point at the root of the domain (then filters off non-openfire users based on a group membership. I’m hoping that isnt the problem, as I have no control over that, we cannot move our user accounts to a more consolidated OU. There is significant amount of text in the Openfire Server console, but nothing that looks too bad to me, though I admittedly have some trouble reading that into anything meaningful to me. the servers resources during this time all look ok, nothing pegging or even close.

Searching the forums hasnt proven too much for me yet, any thoughts?


to see why it takes two minutes you may want to take javacores every 20 seconds, maybe a thread is blocking.

Openfire uses a database cache. You could delete it after the first login to see whether this changes something.

As it is open source you could get the current trunk which supports log4j and add some log statements to see where it takes long.

The JVM does need to compile the code, you could start Openfire with “-Xcomp -Xbatch”. The startup itself should be a little bit slower but I wonder whether you does notice a difference. in any case you should not use these settings for production as this produces compiled code without optimization.


Could you give me a pointer or 2 on how to accomplish getting the javacore? I inhereited this and it really isn’t up my alley - I know right next to nothing about java.

I’ll try th ecache bit later today toverify how that behaves.

Hi David,

on Linux a simple “kill -3 Openfire-Pid” does write a javacore. On Windows it may get tricky as soon as Openfire runs as a service. You may need to stop the service and start it with the start icon (I hope that it’s still there). The JDK does contain “jstack.exe” which allows to create javacore files.

See also http://www.igniterealtime.org/community/docs/DOC-1033


Found that there were some user objects that delayed re-logins abit, so I cleared those up. Also found though that if I cleared all the caches from the admin console that it went back to taking 2.5 min to login the first user again, so something with the caching seems to be what is delaying the initial login. Is there any way to have it retain the caching when the service has been stopped or restarted? That would probably be good enough. Any other thoughts?

Hi David,

you could enable the database query stats (http://example.com:9090/server-db-stats.jsp) to see whether the JDBC queries takes so long.

Openfire uses it own caches so it is not possible to dump the caches to disk and read them during startup, unless you write a lot of code.

Maybe you can write a plugin which fetches some users and rosters during startup, this should fill the cache and allow a faster startup.