Openfire 3.4.1 taking > 4 minutes to start

Openfire Openfire Support
1

We have an openfire 3.4.1 installation on a Linux x86_64 RedHat Enterprise system, with very little activity on it (nearly no users), and start / restart takes more than 4 minutes before the server is actually available. From debug.log after I do a /etc/init.d/openfire start:

2008.01.07 14:45:25 stopped {}
2008.01.07 14:45:25 stopped {}
2008.01.07 14:45:25 stopped {}
2008.01.07 14:45:25 stopped {}
2008.01.07 14:45:25 Unregistering component for domain: test
2008.01.07 14:45:25 Unregistering component for domain: test
2008.01.07 14:45:25 Component unregistered for domain: test
2008.01.07 14:45:25 Component unregistered for domain: test
2008.01.07 14:45:25 Unregistering component for domain: search
2008.01.07 14:45:25 Component unregistered for domain: search
2008.01.07 14:48:57 Flash cross domain is listening on null on port 5229
2008.01.07 14:49:07 Loading plugin admin
2008.01.07 14:49:08 Logging to {} via {}
2008.01.07 14:49:08 jetty-6

Note that there is a gap of more than 4 minutes before the ‘Flash cross domain is listening on null on port 5229’ line.

Any suggestions on what is wrong?

TTimo

2

bump

I don’t need the Flash cross domain service. So if there’s any chance this is causing the startup delay, how can I turn it off?

3

Hi Timo,

could you create some stack traces (kill -3 openfire-pid) during restart, especially when Openfire hangs for four minutes? They will be written to stdout.log or nohup.out and should contain the blocking threads.

Can you read from /dev/random without problems or does it block sometimes? This could delay the SSL initialization.

LG

4

I was going to post that I’m not getting a backtrace, but I think I do. Only it gets printed to nohup.log after the waiting period.

5

Attached is the backtrace I obtain after the timeout if I issue a kill -3

6

bump

This is becoming more and more of a problem, as most our services go over the xmpp layer now so whenever we need to restart we get 4 minutes of downtime when it should only be a few seconds.

7

Hi,

take a look at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6483406 - you need to allow traffic on your loopback interface which seems to be blocked. Disabling IPv6 within Java is also a good idea unless you use it.

LG

8

That fixed it!

thank you

9

JDK 1.7 has better IPv6 support than its predecessors. Anyone having problems may want to check it out. https://jdk7.dev.java.net/