Some spark users not getting private messages until they log out/in

Spark Spark Support
1

Hello all. I’m new to OpenFire/Spark so I’ll probably ask quite a few questions so I appreciate everyone’s patience.

Setup:
OpenFire 4.2.2 running on Windows 2012R2.
Spark client 2.8.3 running on Windows 7

I have a user who says that he sends private messages to users and sometimes those users don’t get the message until the user logs out and back in to Spark.

I’ve been able to look in the chat archive in the admin console BEFORE he has the person log out and it looks like the message is getting sent. It doesn’t happen all the time so I can’t recreate the issue on demand.

The resource usage (CPU/RAM/Network) on the OpenFire server itself aren’t even close to being maxed out when this happens.

I have no idea where to go on this so any suggestions would be much appreciated!

2

What do you mean by private message? Is it regular one on one messages or private messages in group chat? Which party has to relogin, sending one or receiving?

3

Thanks for the reply wroot.

It’s a regular one on one message and its the receiving party that has to log out and back in.

4

When the other person logs out and in again, does the message pop as a new one or is it already in the history as an already received? You could also try checking Spark logs on these receiving PCs. Maybe also Openfire logs.

5

wroot,

First off, thanks for the assistance.

That’s a good question. I’ll have to take a look at that.

As for the logs, 3 questions…

  1. Which OpenFire log would I be looking at?
  2. Where is the log? (again, I’m new to OpenFire so thanks for humoring me)
  3. What would I be looking for in this log?

Kind Regards

6

Openfire log would be in its installation folder, logs folder, all.log file.
Spark user’s log is in C:\Users\User\AppData\Roaming\Spark\logs
I don’t know what to look for either. So every bit of logs could be posted here. Spark produces lots of separate log files (warn, error), look through them all. Maybe just copy errors corresponding with the issue’s time.

7

Thanks,

I’ve asked the sending party to contact me once the issue occurs again so that logs can be grabbed.

8

wroot,

In looking through the Openfire ‘All’ log a little deeper I have found messages like the following: (where the IP seems to belong to a Spark client)

2018.03.26 12:18:20 WARN [socket_c2s-thread-78]: org.jivesoftware.openfire.nio.ConnectionHandler - Closing connection due to exception in session: (0x0000107B: nio socket, server, /10.20.1.136:56674 => 0.0.0.0/0.0.0.0:5222)
java.io.IOException: An existing connection was forcibly closed by the remote host
at sun.nio.ch.SocketDispatcher.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(Unknown Source)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(Unknown Source)
at sun.nio.ch.IOUtil.read(Unknown Source)
at sun.nio.ch.SocketChannelImpl.read(Unknown Source)
at org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:273)
at org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:44)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:690)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:664)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:653)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(AbstractPollingIoProcessor.java:67)
at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1124)
at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Is this the Spark client terminating connection?

9

I’m not so good at understanding Java exceptions. Looks like it. Like the server has terminated the connection. But that would result in a reconnect, not in messages being not delivered. Still wonder what exactly happens on the receiving end.