powered by Jive Software

Openfire Randomly Drops Clients

Hello,

I came across a strange issue involving random disconnections. We currently have Openfire 4.6.1 installed on a Windows 2019 Server with the clients running Spark 2.9.4 on Windows 10 Pro. There are only 6 users in a small office. It is an AD environment and Openfire is configured to use LDAPS and an embedded database.

The problem is that clients seem to get disconnected at random times. Sometimes 3 clients get disconnected one after the other while the others remain connected. At other times, all 6 can get disconnected within a few seconds of the other. This occurs once in a couple of weeks or days.

It actually started in previous versions of the server and client. But upgrading to the latest versions did not seem to help and the issue still exists. After a client is forcibly disconnected from the server, the Spark client is no longer running on those computers and Spark has to be re-started to re-connect. I tried setting the client idle timeout (xmpp.client.idle) as well as disabling stream management (stream.management.active) but those settings did not make any difference.

The client log files show no entries for these disconnects. The server log entries are as follows for each client that is dropped:

2021.01.11 11:06:05 org.jivesoftware.openfire.archive.ArchiveIndexer[MUCSEARCH] - Updating (not creating) an index since 'EPOCH'. This is suspicious, as it suggests that an existing, but empty index is being operated on. If the index is non-empty, index duplication might occur.
2021.01.11 11:11:05 org.jivesoftware.openfire.archive.ArchiveIndexer[MUCSEARCH] - Updating (not creating) an index since 'EPOCH'. This is suspicious, as it suggests that an existing, but empty index is being operated on. If the index is non-empty, index duplication might occur.
2021.01.11 11:16:05 org.jivesoftware.openfire.archive.ArchiveIndexer[MUCSEARCH] - Updating (not creating) an index since 'EPOCH'. This is suspicious, as it suggests that an existing, but empty index is being operated on. If the index is non-empty, index duplication might occur.
2021.01.11 11:17:21 org.jivesoftware.openfire.nio.ConnectionHandler - Closing connection due to exception in session: (0x00000004: nio socket, server, /192.168.0.101:51469 => /192.168.0.10:5222)
java.io.IOException: An existing connection was forcibly closed by the remote host
	at sun.nio.ch.SocketDispatcher.read0(Native Method) ~[?:1.8.0_271]
	at sun.nio.ch.SocketDispatcher.read(Unknown Source) ~[?:1.8.0_271]
	at sun.nio.ch.IOUtil.readIntoNativeBuffer(Unknown Source) ~[?:1.8.0_271]
	at sun.nio.ch.IOUtil.read(Unknown Source) ~[?:1.8.0_271]
	at sun.nio.ch.SocketChannelImpl.read(Unknown Source) ~[?:1.8.0_271]
	at org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:378) ~[mina-core-2.1.3.jar:?]
	at org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:47) ~[mina-core-2.1.3.jar:?]
	at org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:519) ~[mina-core-2.1.3.jar:?]
	at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$1200(AbstractPollingIoProcessor.java:68) ~[mina-core-2.1.3.jar:?]
	at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1222) ~[mina-core-2.1.3.jar:?]
	at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1211) ~[mina-core-2.1.3.jar:?]
	at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:683) ~[mina-core-2.1.3.jar:?]
	at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64) ~[mina-core-2.1.3.jar:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) ~[?:1.8.0_271]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) ~[?:1.8.0_271]
	at java.lang.Thread.run(Unknown Source) [?:1.8.0_271]

See the attached warn.log file where these strange errors are recorded. I’m not certain what those MUCSEARCH errors mean or whether they even relate to this issue, but we don’t use conference rooms or Multi-User Chat rooms at all.

warn.log (625.1 KB)

I would appreciate any help that anyone can offer. Thank you so much!

Nobody?

Hi! I also encountered such a problem, but after upgrading to openfire 4.5.4, the problem disappeared.

Thanks for your reply. But we’re already running the latest Openfire 4.6.1 with stream management disabled and continue to have the same problems. I don’t think we had the problem with version 4.5.0. It only started after upgrading to 4.5.1 and continued with 4.5.4 and 4.6.1.

What’s really strange is that it doesn’t simply disconnect the clients - each client’s spark process in memory is terminated and has to be restarted so it can reconnect to the Openfire server.

If it continues or gets worse, I may end up doing a fresh installation of 4.6.1 and manually entering all my settings. Of course, I was trying to put this off as long as possible.

Guus, if you’re also reading this… any ideas what may be going on???