Hi All, hoping someone might have some tips or can point me in the right direction. We’ve used OpenFire + Spark internally since the pandemic started, for the most part it’s worked great and been a lifesaver. Currently we are on OpenFire 4.6.3 and all clients are Spark 2.8.3 and everything works fine. The issue is if I upgrade any client to Spark 2.9.4 they are able to log in fine, the company user lists loads for them and they also appear in everyone else’s list. The issue comes when a conversation is attempted, and it depends on who initiates it:
If the user on Spark 2.8.3 initiates the private message to the Spark 2.9.4 user they will receive it and they can reply back and both sides will see it. All is normal.
If the user on Spark 2.9.4 initiates the private message to the Spark 2.8.3 user they get an error message in the window that says “An error has been detected: jid-malformed”, but then the message does appear to send on the next line. The user on Spark 2.8.3 never receives the message or has any indication that it was sent.
Again, we are rock solid with all clients on 2.8.3 but I would like to be able to test and upgrade to 2.9.4 to take advantage of the new Client Control plugin. The issue is we are many hundreds of employees scattered across 4 physical sites in different time zones so the chances of us upgrading everyone to 2.9.4 in one shot is nil, we would need to be able to function in a mixed Spark 2.8.3/2.9.4 environment for a short time as we upgrade users.
I have two servers Openfire 4.5.4 and Openfire 4.6.3. I tried both Spark 2.8.3 and Spark 2.9.4 and I saw the text.I just like you used Spark 2.8.3 and gradually installed Spark 2.9.4 everywhere and I did not have such a bug.
Before installing Spark 2.9.4, I deleted all files from the % Appdata%\Spark folder, except chat history.
Do you tried deleting all files from% Appdata%\Spark before installing Spark 2.9.4?
Is it working when you use Spark 2.9.4 on both ends? As you mentioned that you have different sites, it might be helpful to do tests with multiple conditions: site1 - site2 mixed or both same version, site1 - site1, etc. Maybe this way you will see a pattern when it happens.
Do you use your XMPP domain name to login to Spark 2.9.4?
Thanks for the replies. I just tested Spark 2.9.4 <–> 2.9.4 and the messages are not received. The only scenario where 2.9.4 works is if a 2.8.3 user initiates the conversation, in that case everything works. One other thing I noticed is that when signed in on 2.9.4 the status bubble colors (green/yellow/red) work normally in the company list, but then when you open a window to initiate a private conversation the bubble next to the user’s name is greyed out instead of green. (See uploaded screenshots, the first one shows me signed in on 2.9.4 and messaging with 2.9.4 and 2.8.3 on separate VMs at the same time, you can see the difference in bubbles there.)
As far as sites, this is all happening within the same datacenter at our primary location. Our OpenFire server is there and 95% of our Spark happens there, users in the remote sites are on Terminal Server sessions with their local timezones defined, but on hardware in our primary datacenter.
We have our OpenFire server integrated with AD using LDAP and we sign in with our full company email addresses which follow the format below.
Do you have the option to install Openfire 4.5.4? You can install it on top of the current Openfire 4.6.3, but do not forget to make a backup or snapshot. Alternatively, install a new 4.5.4 server and try connecting Spark to it.
Also, check the logs of 2.9.4 client when it fails to send the message.
Error Logs:
C:\Users\User\AppData\Roaming\Spark\logs
There is a bunch of files, look through all of them and select events that correlate with the time of your issue.
Yes, it’s a VM so I can take a snapshot and then roll it back. I will need to do this at off-hours, I’ll get it scheduled and done in the next few days and then I’ll reply back on this thread. Thanks.
Hi drichardson,
I had something similar happen, but I think without the exact error messages you have. It turned out to be an old meet.jar plugin on the client side. Do you have meetings/pade installed also ?
