with your 2.8.3 clients, its possible the upgrade didn’t overwrite all the files. on a workstation that is experiencing the issue, please try the following
uninstall spark
delete %appdata%\spark
check for c:\program files x86\spark - if folder is there, delete it
Deleting he registry keys won’t do much. I have no experience with that ‘Kerio-Connect-Server’. Maybe this is something on the server side. Sure, there were lots of changes in Spark for 2.8 (underlying main Smack library has been updated to the latest one, which means a few years of changes in it). But it works with Openfire and some other xmpp servers. You can check the logs in Spark (and maybe there are logs on that server). Well, you always have an option to run 2.7 (latest version was 2.7.7).
The error is right on target, but i don’t know what can be done here. I would say this is caused by a change in Smack library, not Spark itself. But we can’t go back to older version of Smack. It is also harder to debug as we don’t have access to Kerio server. Yeah, you can get a tral version, but that would be a bit too much (for me at least) to install it and trying to debug why it doesn’t work with Spark 2.8. Maybe you can contact Kerio support on this (of course if Spark is in the supported clients list). You can also try enabling Spark debugger in Advanced settings and check what packets Spark is sending and receiving. You can post them here, though it might not be helpful either.
sure it’s too much trouble to install a demo-version. It’s even not sure, you can’t reproduce the problem, for example it’s an particularity in our user-group (avatar-photo or else). I also think, the output of sending and receiving data could provide any enlightment. I’ll make such recordings on monday at work.
I’ll get to contact Kerio-Technologies too, but I would like to confine the problem.
I know what developer say, when two parts of software from different companies don’t harmonize: Every group says, that the faults are in the responsibility of the other part
wroot wrote:
> XMPPError: feature-not-implemented - cancel
I would say that Kerio doesn’t support some modern functions and Smack library can’t talk to it.
Or kerio uses a legit XMPP-specification-part, that spark (resp. smack) don’t support or has a buggy implementation
It can be Smack of course, but i doubt it, as current Spark works with at least two servers (Openfire,ejabberd). Smack is in fairly active development. Have you tried with other clients? Gajim, Psi, maybe even Conversations on Android.
We can try summoning @Flow (maintainer of Smack) here to ask what
today I made some experiments with spark-versions 2.7.7 and 2.8.3.
I think, the postet error not necessarily has to do with the effect of the empty collegues-list. Even 2.7.7 throws errors like this:
Mär 06, 2017 4:07:37 PM org.jivesoftware.spark.util.log.Log error
SCHWERWIEGEND: Unable to contact shared group info.
feature-not-implemented(501) Feature not supported yet.
at org.jivesoftware.smackx.SharedGroupManager.getSharedGroups(SharedGroupManager.j ava:68)
at org.jivesoftware.spark.ui.ContactList$25.run(ContactList.java:1806)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
without any observable malfunction
As suggested I have also recorded the received/sent raw-packets from the smack-debug-windows.
I recordet the first few seconds with the old 2.7.7 and with the 2.8.3. spark-version.
In both received-Data I can see the XLM-Data of the collegues, but in 2.7.7 the list in spark is empty.
Maybe still a problem of spark and not of the underlying Smack library?
I don’t see in this forum any possibility to upload files, so I put the raw-data here for you to download
(email-addresses are obfuscated to prevent abuse).
Maybe someone can help by analysing the raw-packets(?).
5.1.0 is 6 years old. That might be the cause of those errors in 2.7.7 also.
in received group packets i only see one difference: in Kerio it sends subscription tag before the name. In Openfire name goes first and then subscription type is closing the tag. This is probably not important. I can’t spot any glaring difference between received packets comparing to Openfire.
thanks for your first assessement-results. At least that’s a starting point!
I’m not familiar with java-coding, but isn’t it possible for the developer to debug the code with the given raw-packets, resp. to see whether the order of subscription tag and name makes a matter?
THX,
Budgie
PS.: Ahh, now I see: By switching editor to extended-mode, it’s possible to attach files. It seems as I was blind yesterday
I think it should be possible for a developer (and xmpp expert) to find out the cause. Of course, better when having a real server to connect and debug. But i’m not a developer. And Spark lacks at least one (yeah, a few folks help from time to time, but they are to busy to drive Spark forward all the time).
do you sleeping actually sometimes? You answeres coming - regardless of the day-time of- always quite soon
Setting up a real server is much more trouble and maybe it just take a look at the XML-Data to recognize the problem.
And ‘to drive Spark forward’ could mean too, that it works with as many servers as possible to get a wide distribution and popularity.
Assuming Kerio in fact is not compliant to XMPP-standards. Regardless of this presumption, spark 2.7.7 with old smack library
shows a acceptable functionality.
If actual spark/smack does not, this is maybe no error in the software itself, but at least shows that the new implentation has
less fault tolerance then before.
If your developers are interested and have an idea of solving the problem, I would offer to make tests with debug-versions on
our system, so that they don’t have to put on an own system with kerio.
cu,
Budgie
And yes, and I’m conscious, that you are ‘known to remember EVERYTHING and shamelessly remind me about promises I made’
We might be in the same timezone. I’m from Europe. And i WILL go to sleep and won’t be able to reply in a few next hours
I understand what you are saying and i would love for software to always stay backwards compatible, but this is usually not the case (even in the commercial software world). 2.8 broke many things and 2.9 might break a few more. Even when we updated Java for 2.7.6, Spark stopped working for some users and it was just a simple minor version update. We could’ve used same old version of Smack, but this would stop evolution of Spark and would not allow to add cool new features like Message Carbons, Message Archive Management (hopefully someday).
I see you have found out that i’m the project lead for Spark Or as they say a “poor man’s choice” as i’m not a developer and i just filled the gap as nobody was willing to take it. I’m afraid you won’t get attention from anyone here with enough experience to do a thorough testing.
Well, you can try it with a few other clients, like Gajim, Pidgin, to see if they behave correctly. You can also try Spark’s 2.8.0 and later versions to see if it actually started with 2.8.0 or maybe later (Releases · igniterealtime/Spark · GitHub ).
in most cases it is IMHO possible to ensure a largely backwards compatibility. Particularly dealing with protocolls is very importend to pay attention to.
The classic protocolls i.e. http, smtp, ftp … are age-old, expanded with extended versions, but actual software still works with this fossils.
Only in a few cases backwards compatibility is really not possible without inhibiting the progress.
The point is, that many developer can’t be bothered with such stuff, it’s to inconvenient.
Here in this case I don’t even think, this is a real backwards compatibility problem. I guess it’s only a minor detail in spark-client. The transportet packets from smack-layer seems to be kosher, there is noch significant differences between 2.7.7 an 2.8.3. … it must be only a small thing … casting error or else.
Yes, we tested a few other IM-clients, some workes, some don’t. But they don’t meet our requirements. Sparc hit most the requirements.
And in new sparc there is a further feature implemented we are interested in. A pity.
Get a raw XMPP trace. You will likely find that the server is responding with not-implemented to the request. Then ask the server vendor why the service replies with not-implemented to that particular request. The answer will possibly be that that (the version of that) feature is not implemented.
