Spark 2.6.0 BETA Releases!

It’s good news (if) the reconnection logic is now fixed.

My main issue with Spark (even with the new beta) is the connection code; on a slower (i.e. non LAN) connection, after logging in Spark regularly ‘forgets’ to do stuff. i.e. sometimes I don’t get gateways shown, other times my avatar is missing.

It sounds trivial, but it means it can take 2-3 times to login correctly and have everything working.

DeeJay wrote:

on a slower (i.e. non LAN) connection, after logging in Spark regularly ‘forgets’ to do stuff. i.e. sometimes I don’t get gateways shown, other times my avatar is missing.

I would say this is not a connection issue. Spark behaves sluggish and loads stuff differently on system with different resources. SPARK-378

I’ve tried this with 4 different machines, all high spec (min 2Ghz, 1GB RAM) - 2 windows XP, 1 RHEL and 1 Mac OS x 10.5.3.

All work fine from the office but not from home over ADSL.

D

I agree with this assessment, as I’ve had issues even on a 2.33GHz dual-core machine with 4GB of RAM.

The only thing i can think of really is that Spark is attempting to do everything at once or the Openfire server is slow at responding or Spark is getting a lot of packet loss over the connection.

“Spark is attempting to do everything at once”

I think the same thing.

My company uses Openfire and we do not believe that the server is slow to respond especially since this is only an issue with the spark client being slow on the initial login and this has been an issue with spark all along no matter what version…

In one of my previous posts here I asked if there was any plans to make a spark client that would work well with low end systems.(adobe air spark client etc)

I did not clarify what i meant by low end systems but what I meant by low end is anything with less than a 2GHZ CPU and 512GB of RAM.

I personally use spark on My Core 2 Quad 2.5Ghz with 2GB of RAM running Windows XP and have the same issues with spark slowness upon login and this has been an issue on any system really so it seems to be a problem in the spark client. so…basically in my opinion it does not seem to matter if you have a decent system with a decent ammount of RAM because spark continues to be slow no matter what you have.

I really would like to see some serious performance improvements to spark and one of those would be to improve the process of loading the contact list and initalizing the various plugins upon login. I strongly believe that should be the area for spark DEV to focus most attention.

I can remember spark releases from over a year ago that I only upgraded to becuase there were changes listed that mentioned performance improvements.

Performance improvements is all i really look forward to in any new version of spark.

I dont really want everyone to think that I am just blasting spark because in reality i do like the spark client and it has some great features that other XMPP/Jabber clients do not but I think that as long as performance is an issue I am forced to jumb back and forth between Pidgin and spark on the occasions when instant messaging is a must. I also usually am able to connect using Pidgin if spark is to fail for whatever reason so I believe this is a spark client performance issue and not a server performance issue.

Well, the only way really to solve this is to add a delay, the problem here is that, loading everything at once comes down to how fast the CPU can process the information vs adding delay which would slow the process down by spacing out each item.

Essentially there has to be a compromise somewhere between the user and the system.

For me, consistency and reliability are far more important than peformance. Logging in multiple times until the logon sequence happens to occur in the correct order and speed isn’t great.

I don’t pretend to understand the process, but I don’t really know why it’s performing badly at the moment.

Could you explain (in simple terms for us slow-un’s) what the problem is? i.e. when I’m missing a couple of gateways, how does that happen? You’d think the clent would have a buffer from the server so it doesn’t really matter how quickly it can process messages, unless that buffer overflows?

Darren

Actually I can help explain this, and winsrev, this may help you too.

The problem lies in the way the gateway support is implemented as a plugin. It’s a plugin that is … “internal to Spark” (in other words it’s nothing you install yourself or can uninstall), but it’s still treated as a plugin. So part of what the plugin does is, as you are logging in, it listens for transports returned from the standard disco inquiries. Kind of a “oh hey! check it out! aim is in there!” and so it presents the aim icon and does it’s handywork to log you in or not log you in.

So what happens? Well, the timing issue comes in where you are logging in and the disco request comes and goes and the plugin hasn’t actually loaded yet. So it’s never active to “hear” the transports.

I thought I fixed most of that crap though so I’m a little surprised to hear you are still seeing it. (I must say I haven’t seen it happen in a long time) I had made it not only listen, but do it’s own query. If that’s not working then I’m not entirely sure what’s going on. Unless of course I -meant- to do that and didn’t end up doing it. =/

IMO the plugins ought to be loaded before anything else is done at Spark startup. But there are timing issues associated with that as well. For example, a plugin may expect the contact window to already be drawn so it can do stuff with it. So loading them up front doesn’t work.

That sounds plausible - but I don’t understand how it would mess up other things such as not showing your avatar or display name?

It doesn’t, that sounds like a separate issue. Jadestorm: Can’t we just make them external plugins then? I mean, if that helps or not or load the plugins after Spark has finished “connecting”?

jadestorm wrote:

I thought I fixed most of that crap though so I’m a little surprised to hear you are still seeing it. (I must say I haven’t seen it happen in a long time)

I dont remember seeing this at work. But at home i often restart my test server, relogin with Spark and sometimes it starts to behave like that, doesnt load something or cant connect to gateways. In such case i have to completely shutdown Openfire, exit Windows Lanucher, exit Spark and start Server and Spark again.

Speaking about SPARK-1022, i dont get systray icon in Windows with latest trunk version (built it right now). And it has affected my normal Spark installation as it has changed something in my profile after launching svn version.

Hmm, i see, i’ll look into this asap.

I have fixed that by deleting /plugins folder content in my profile and launching normal Spark. And now svn version shows systray icon too. Svn version creates /idlelinux and idlelinux.jar in /plugins. This is on Windows XP.

It seems that the windows version is trying to load the Linux plugin, which doesn’t make sense. I’ll properly fix this by making sure that plugin isn’t loaded on a Windows machine.

It’s the opposite. In theory it would be better for the plugin to be run right at the start so it can be ready to listen for everything that’s coming in. Either way, there’s definitely some issues with the handling.

This has been in Beta for over two months. When will it be gold?

To quote WinSrev “Whe it’s done”.

I’m not sure spark will ever be done

Ex: 100% CPU usage at times and it runs on java which is pretty much a dead language.

Use Pidgin it works much better

http://pidgin.im