Will wait for your feedback. Meantime, if you care to share your feedback on using other XMPP clients (i.e. Pidgin), did you notice any issue or anything unexpected?
Yes, it seems that only the Spark clients were dropped while the Pidgin clients were left alone.
Another thing I noticed while testing:
- I re-enabled Stream Management on the Openfire server (v4.6.2)
- Restarted the Openfire service
- Restarted the Spark clients (v2.9.4)
When I go to “Client Sessions”, Stream Management shows as being “Disabled” on each Spark client. However, on the Pidgin clients, it shows correctly as being enabled. Has SM been permanently disabled on these versions?
Oh, I wasn’t aware of that. Hopefully, it will get fixed someday. Thanks for the update.
It seems the problem actually related to Spark.
Just for curiosity, anyone facing the same issue with Spark but using different version of OF (not 4.6.1 or 4.6.2) ?
Coz, I want to make sure the issue can be fixed from client end (i.e. Spark) Or it still needs some adjustment from server (OF).
Hey!
I’m using Openfire 4.5.4 and 200 Spark 2.9.4 users.
There are no problems, some users have uptime for a month or more.
Not necessarily. It is actually a problem when Spark is running in an environment that uses that particular enterprise AV solution. So the AV seems to kill Spark for some reason (heuristic scanning?), but leaves Pidgin alone. The solution could be to simply add Spark to the exclusion list of apps to ignore.
1 Like
If you bothered to read the previous posts, you would have noticed that the problem is triggered when the enterprise AV detects the Spark process in memory. So it won’t happen in everyone’s environment, including yours it seems.
just add to the whitelist of your antvirus
Of course, that is the obvious solution. I will do so after testing is completed in a week or so.
We have had Spark Whitelisted in Symantec Enterprise and still have the issue. We are still waiting for Spark client updates to fix the Stream Management issue. We, sadly, may have to look at alternatives to Openfire and Spark.
1)Please try add folder %PROGRAMFILES(x86)%\Spark and if you use x86 Windows %PROGRAMFILES%\Spark in WhiteList your Symantec Enterprise.
2)Please try to install Openfire 4.5.4 on top of your Openfire 4.6.1 or do clean install.
Last week we attempted to specify the paths C:\Program Files (x86)\Spark\ and C:\Program Files\Spark\ in our Symantec. Still at issue.
Also on Jan 24 Michael42 commented “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.” I agree with him we saw this in differing versions of Openfire and seems to come back to an issue with Spark. Other clients do not seem to have a disconnect issue.
then maybe you should try Openfire 4.4.4. I’ve been using it for a long time.
Michael said it works ok for him after disabling Advanced Anti-Exploit module in BitDefender AV. So it is not related to Openfire version.
I’m glad to hear this, I once created a ticket in Kaspersky, but they could not help me find the cause of the problem.
This is correct. I don’t think the versions of Spark or Openfire had anything to do with the drops. It was just a coincidence that no drops occurred while running earlier versions at the same point in time that Bitdefender did not yet implement this new “feature” of killing processes. Here is the specific setting that I had to disable:
UPDATE 3/15/21:
So after much testing, I concluded that it was indeed Bitdefender’s newly introduced “Advanced Anti-Exploit” module that was causing all the client disconnections. Merely disabling the module had no effect - I had to actually remove the module from every workstation. Just the very presence of that module on a workstation, even when disabled, would still cause the drops.
Thank you everyone for your input and efforts especially, Guus, Wroot and Speedy!
Mods: Please move this post to the Spark Support forum. It turns out that Openfire had nothing to do with this issue after all. I renamed the title accordingly.
2 Likes
Thanks for your diligence on this, @Michael42! It is likely that the cause would have gone undetected without your tenacity.
Have you been in contact with Bitdefender about this? I’d love to know if there’s any way that we can prevent this from occurring.
I’m opening a support ticket with them tomorrow and will update you once a solution is found. Thanks Guus!
Update:
Their tech support department is working on tweaking their heuristic scanner so it will avoid killing the Spark process. In the meantime, I just had to add Spark to the scan exclusion list. I will continue to monitor the situation in case the problem crops up in the future.
3 Likes