powered by Jive Software

Dozens of Openfire instances!

Whenever i start Openfire 3.5.2, it launches ~35 instances. This happens even after a reinstall (by which i mean “using the same database with a freshly un-tarred openfire directory”). I have no idea how to begin debugging this. Any advice on how to proceed?

Both strace and jconsole show what i’d expect. The only thing in my error.log is this set of (seemingly tangential) SSL errors:

2009.05.13 01:55:06 [org.jivesoftware.openfire.net.SSLConfig.<clinit>(SSLConfig.java:104)] SSLConfig startup problem.
  storeType: [jks]
  keyStoreLocation: [/srv/openfire/resources/security/keystore]
  keypass: [********]
  s2sTrustStoreLocation: [/srv/openfire/resources/security/truststore]
  s2sTrustpass: [********] 2009.05.13 01:55:07 [org.jivesoftware.openfire.container.AdminConsolePlugin.startup(AdminConsolePlugin.java:121)]
java.io.IOException
        at org.jivesoftware.openfire.net.SSLConfig.getKeyStore(SSLConfig.java:267)
        at org.jivesoftware.openfire.container.AdminConsolePlugin.startup(AdminConsolePlugin.java:96)
        at org.jivesoftware.openfire.container.AdminConsolePlugin.initializePlugin(AdminConsolePlugin.java:170)
        at org.jivesoftware.openfire.container.PluginManager.loadPlugin(PluginManager.java:448)
        at org.jivesoftware.openfire.container.PluginManager.access$300(PluginManager.java:47)
        at org.jivesoftware.openfire.container.PluginManager$PluginMonitor.run(PluginManager.java:1014)
        ...
2009.05.13 01:55:08 [org.jivesoftware.openfire.http.HttpBindManager.createSSLConnector(HttpBindManager.java:158)] Error creating SSL connector for Http bind
java.io.IOException
        at org.jivesoftware.openfire.net.SSLConfig.getKeyStore(SSLConfig.java:267)
        at org.jivesoftware.openfire.http.HttpBindManager.createSSLConnector(HttpBindManager.java:134)
        at org.jivesoftware.openfire.http.HttpBindManager.configureHttpBindServer(HttpBindManager.java:258)
        at org.jivesoftware.openfire.http.HttpBindManager.start(HttpBindManager.java:90)
        at org.jivesoftware.openfire.spi.ConnectionManagerImpl.startHTTPBindListeners(ConnectionManagerImpl.java:523)
        at org.jivesoftware.openfire.spi.ConnectionManagerImpl.startListeners(ConnectionManagerImpl.java:136)
        at org.jivesoftware.openfire.spi.ConnectionManagerImpl.access$000(ConnectionManagerImpl.java:54)
        at org.jivesoftware.openfire.spi.ConnectionManagerImpl$1.pluginsMonitored(ConnectionManagerImpl.java:108)
        at org.jivesoftware.openfire.container.PluginManager.firePluginsMonitored(PluginManager.java:533)
        at org.jivesoftware.openfire.container.PluginManager.access$800(PluginManager.java:47)
        at org.jivesoftware.openfire.container.PluginManager$PluginMonitor.run(PluginManager.java:1024)
        ...

How do you start Openfire? Linux OS?

Right, that would help. :slight_smile:

I’m running Debian GNU/Linux, but i’m not using the Openfire .deb package. Here’s what i’m doing:

# tar zxf openfire_3_5_2.tar.gz
# cd openfire/bin
# ./openfire start

Openfire is running on a remote machine, so i tunnel port 9090 to my local machine. Then i connect to localhost:9090 with a web browser and configure Openfire to use my existing MySQL database (which is on the remote machine with Openfire).

Where do you see those 35 instances? I’ve just looked at my top and it shows one java process, but htop shows ~16 of them. I’m not really familiar with those tools, but I think these are java threads of one process and not a separate instances. Anyway it is working fine for years so i dont even bother to look at the processes

Btw, why dont you use 3.6.4 version?

Where do you see those 35 instances?

They show up in ps:

# ps aux | grep openfire | wc -l
85

So it’s currently at 85 separate processes. Once the process count gets up around 80, Openfire becomes unresponsive (ie, clients can’t log in).

Btw, why dont you use 3.6.4 version?

Oh man, don’t get me started. :slight_smile: That’s beyond my control.

But FWIW, i installed v3.6.4 on the same machine, and it had the same problem. Also, i’m running v3.5.2 on three other servers without any problems. It looks like my server is misconfigured in some way (an inherited mess), so maybe i should just rebuild it and call it a day. But i was hoping to track down the cause of the problem.

Oh man, don’t get me started. :slight_smile: That’s beyond my control.

I see. But you can suggest those who are in control to upgrade as older version has a few severe security issues. Not telling the new won’t have any

It looks like your starting script is somehow looping. But that would be hard to track via forums, i think.

Maybe its related to http://www.igniterealtime.org/community/thread/38412 but in Eclipse you normally don’t use any startscript and therefore maybe its another problem.

Oh man, don’t get me started. :slight_smile: That’s beyond my control.

I see. But you can suggest those who are in control to upgrade as older version has a few severe security issues.

Believe me, i’ve tried. I even pointed out the major security-related bugfixes from the changelogs. The web development team refuses to change their code to work with the new Openfire MySQL schema (which uses ‘of’ prefixes in place of ‘jive’ prefixes in a bunch of the table names). This change occurred between 3.5.2 and 3.6.0. I told them i could fix that with a one-line sed script, but they still refused.

It looks like your starting script is somehow looping. But that would be hard to track via forums, i think.

I’m skeptical, since the number of Openfire processes actually grows long after the startup script has terminated.

But i think you’re right that this will be hard to troubleshoot via a forum. Oh well, i thought i’d ask on the chance that someone else had seen similar behavior before. I’ll just rebuild that machine and reinstall Openfire.

Thanks for the help, wroot.

Hi,

you could try to use another java version or kernel version. With old linux systems there was a 1:1 mapping of java to posix threads, so after starting a java application one would see a lot of processes. Anyhow a “ps -ef” will show you that the PPID (parent pid) of all pids is the same except for the main thread which has another PPID.

LG