Although I doubt that it relates to the issue at hand, each of these log messages are all relate to pretty much the same thing: Your Openfire (which is running the XMPP domain “OpenFireServer”), is trying, and failing, to create a connection to another server (might be yours, might be someone else’s, might not exist at all) that is running the XMPP domain “Domain”.
A common cause for your Openfire to try and connect to another server is to allow users from both networks to talk to each-other. Assuming that your username is “gretchen” (which would make your JID “gretchen@OpenFireServer”), it is very possible that you want to chat with your friend named “oliver” that’s on another XMPP network, named “Domain” (Oliver’s JID would be “oliver@Domain”). You could have done so by adding “oliver@Domain” to your contact list, after which your domain will attempt to make contact with Oliver’s domain. These attempts are what we see failing in the log file that you provided.
Note that it is possible that you tried to add a contact to your contact list, but used an incorrect JID to do so. For instance, Oliver could have an account on the same XMPP domain as yours (eg: “oliver@OpenFireServer”), but you accidentally used “oliver@Domain” instead. Even if the XMPP domain “Domain” does not exist, or is currently not reachable, your domain will attempt to contact it.
The names of both XMPP domains are suspicious: “OpenFireServer” and “Domain” look odd. Did you search/replace these values before you posted the log files here? If not, your setup might need to be looked at - although you can probably make things work with these names, odd values like this can lead to confusion, and thus, problems.
I was somewhat able to reproduce the problem. Spark is very extensible in nature. All kinds of plugins can add functionality. I’ve found that Spark would stop processing messages completely, if one of the ‘add-ons’ would throw an unexpected problem. I’ve addressed this issue here: https://issues.igniterealtime.org/browse/SPARK-1798 and provided a fix here: SPARK-1798: Gracefully handle exceptions from event listeners. by guusdk · Pull Request #215 · igniterealtime/Spark · Gi…
With the fix for this issue, the root cause of the problem won’t be fixed (I don’t know what it is), but the effect would now be isolated to that ‘add-on’. It would no longer prevent further processing of the message.
There’s a good chance that this will ‘fix’ your problem (not being able to see an incoming message). As a side-effect, the root cause should now be logged in the error logs of Spark. That will allow us to address that too.
I did a search and replace to replace the name of the server that Open Fire is installed on to OpenFireServer, but Domain is just how it is in the logs. We have only one domain and our openfire server shouldn’t be trying to contact another server or domain. I’ll have to look into that to figure out what is going on.
I’ve got the latest build installed now. Here are the raw packets received from a message that again didn’t show in my chat window, but did make my chat window pop up and flash. The second message that she sent me, that you see at the end, did appear in the chat window:
Bah, I had hoped that your problem would have been resolved with the new build. Apparently not.
This new build did improve logging. Does this version write anything related to this issue in the Spark log files?
One last thing that you could try is to start Spark from the command line / dosshell. There’s a chance that an error is printed to the console, instead of the error log. Perhaps that could give us a new insights.
I was hoping this would fix it too! But I suppose having the problem happen fairly consistently to me, and not very often to any of my users, is the best possible troubleshooting scenario.
Nothing relevant in the spark log files. I’ll give running spark from the command line a shot.
I’m running out of ideas, sadly. As long as there’s no way for me to reproduce this problem, it’s going to be hard to debug it.
You could try switching off plugins that you might have installed, toggle some settings, see if that makes a difference. Perhaps you’re lucky and find a cause that way. If your users don’t have this problem, then what’s different between your client and theirs?
No, I’d be surprised if it’s anything outside of Spark. Your client receives the message, it ‘simply’ does not display it. Spark has plugins of its own - I was referring to those.
Harhg. Would you be able to hook on a Java debugger and see what’s going on? I’m at a point where I don’t know what to recommend other than have an on-site Java developer debug your client…
Have you tried installing Spark on another computer, and log in with your credentials there - see if you can replicate it as consistently? Straws…
In any case, it’s around midnight here - I’m turning in. Hopefully, the morning comes with new insights…