powered by Jive Software

Newer Spark-Versions don't work right

Hi - we use Spark since some years on work. Up to Spark Version 2.7.6 all worked fine, but all newer versions sucks in our network.

The Problem is that the list of the collegues are empty, when a client has a newer version then 2.7.6

The actuel 2.8.3. even show this effect. Users that have 2.7.3 installed see the collegues with newer client and also can

send messages to this collegues. The collegues with newer clients even can answere to this messages, but they can not

start a conversation with the ‘invisible’ users

We run Spark on Windows 10 and use Kerio-Connect-Server (Version 9.2.1).

Something changed in Spark from version 2.7.6 on that cause the effect and I have no clue what this could be or

what to do to avoid the discribed problem. Have somone a hint, what to do?

TIA

Budgie

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

reinstall spark

Hi speedy, thx for your quick response! I can try out tomorrow at work.

Nevertheless I made some experiments with de-/re-installing and installing in a new folder with no success.

Indeed I’ve not deleted anything in registry. Ok, I will try out this too und tell you if any difference occures.

THX,

Budgie

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).

C:\Users\User\AppData\Roaming\Spark\logs

2.7.7 Ignite Realtime: Download Landing

Labas wroot,
as predicted the fresh installation, even on a virgin machine, makes no difference in behavior of Spark-client

Taking your advice I’ve looked in log-file and there is noticed a serious error:

Mär 03, 2017 1:08:01 PM org.jivesoftware.spark.util.log.Log error
SCHWERWIEGEND: Unable to contact shared group info.
org.jivesoftware.smack.XMPPException$XMPPErrorException: XMPPError: feature-not-implemented - cancel

  • at org.jivesoftware.smack.XMPPException$XMPPErrorException.ifHasErrorThenThrow(XMP PException.java:135)*
  • at org.jivesoftware.smack.PacketCollector.nextResultOrThrow(PacketCollector.java:2 32)*
  • at org.jivesoftware.smack.PacketCollector.nextResultOrThrow(PacketCollector.java:2 13)*
  • at org.jivesoftware.smackx.sharedgroups.SharedGroupManager.getSharedGroups(SharedG roupManager.java:53)*
  • at org.jivesoftware.spark.ui.ContactList.lambda$initialize$13(ContactList.java:175 2)*
  • 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)*

I don’t know whether this might be helpful (?). Could be, that the output of debug-window, when you start spark in debugging-mode

is more purposeful?

Kerio-Connect (http://www.kerio.com/products/kerio-connect/server) has included a xmpp-part and worked fine with spark version 2.7x and below.

Since we does’nt changed anything in Kerio-configuration, the reson of the issue must be a specific change in 2.8.x-version.

TIA,

Budgie

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.

XMPPError: feature-not-implemented - cancel

I would say that Kerio doesn’t support some modern functions and Smack library can’t talk to it.

Hi wroot,

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

So far for now,

cu & nice weekend,

Budgie

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

Unable to contact shared group info.

org.jivesoftware.smack.XMPPException$XMPPErrorException: XMPPError: feature-not-implemented - cancel

might mean.

It’s an XMPP protocol error reply send by whoever the initial request was sent to.

Hi wroot and @Flow,

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(?).

TIA.

Budgie

I’m not that good in reading those packets. What i see is that Kerio is actually a rebranded Tigase server:

=“Tigase ver. 5.1.0-SNAPSHOT build ${buildNumber} (${timestamp})”/>

current Tigase version is 7.1.0.

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.

Btw, you can attach files here by switching to advances editor in the corner.

Hi wroot,

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 :sunglasses:

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).

Hi wroot,

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 ).

Hi wroot,

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.

cu,

Budgie



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.

Hallo Flow,

thank you for reponding and sorry for my very late answere :frowning:

Unfortunately I got ill and afterwards I had other urgend matters to do.

Flow schrieb:

Get a raw XMPP trace.[…]

Sounds like a hopeful attempt, but what do you exactly mean by ‘a raw XMPP trace’?

Do you mean those data I’ve posted before on 06.03.2017 in this forum? (here)

If this not the data you mean, who can I produce such a trace?

Otherwise if you mean a trace like this, where can I find that the server is responding with not-implemented to the request,

resp. which request this should be, so I can ask the server vendor?

TIA,

Budgie