Roadblocks Towards company wide acceptance (Wildfire 2.5.0 and Spark 1.1.1)

I’‘m eager to take the evaluation of Wildfire+Spark as the internal IM of choise for my client even further, but there are issues currently hindering me from doing that. I’‘m referring just as much to Wildfire as to Spark. I don’'t know which one to blame most

(note: we’'re dependant on authentication, shared rosters and vcards all[/i] being provided from LDAP/AD)

Reliable presence:[/b]

I’‘m not sure whether this is because of the client(-s) or the server, but often auto-away’'d contacts seem to flap between away/available.

Also associated to presence - I’'ve seen people go online but their presence is not pushed to other users already online. (The new user on the other hand can see everyone else). Very demotivating for my test users

Reliable file transfers:[/b]

I’‘ve seen other people requesting a feature to disable file transfers. This is no problem for us - because since upgrading from 2.4.4 to 2.5.0 file transfers Spark->Spark won’‘t work at all[/i]! We need[/i] reliable transfers accross firewalls - it’'s even more grave a show-stopper than the “online but not present” problem.

No-quirks UTF-8 support:[/b]

Stuff like http://www.jivesoftware.org/community/message.jspa?messageID=113735 is just so 90’'s[/i].


Which are your[/i] “stoppers”?

have you looked at your error logs on Wildfire? Maybe turn on Debugging for the file transfer. 2.5.0 introduced a Proxy 65 file transfer system on the server side. This may be what is causing your problem depending on our the security settings are on your server. My recommendation would be for you to turn off the file transfer on the server. This might re-enable P2P file transfer.

As for the presence stuff, I dont thinkg I have seen what you are describing but I will look into it. I just upgraded my teams internal IM server to support our group chats an we have not seen this yet. Maybe the auto away settings on the spark client is set too high.

Reliable file transfers:[/b]

I’'ve seen other people requesting a feature to

disable file transfers. This is no problem for us -

because since upgrading from 2.4.4 to 2.5.0 file

transfers Spark->Spark won’'t work at all[/i]! We

need[/i] reliable transfers accross firewalls -

it’'s even more grave a show-stopper than the "online

but not present" problem.

Could you elaborate more on the issues that you are seeing with file transfer? We made quite a few changes to both how spark and wildfire handle transfers.

I just realized another point, which has already been discussed in the Spark forum:

No company-wide popups WHATSOEVER:[/b]

I’‘m getting quite a few complaints because of this! It apparently wasn’'t fixed in 1.1.1, so

each time I need to trim some value in wildfire.xml and restart, ALL my clients have to

acknowledge thay by clicking a button argh

/i

I’‘ve been able to perform some further research into the matter of filetransfers - it seems as if the problem only occurs when sending a file between JID’'s on the SAME server … with or without the bytestream proxy enabled.

Failure:[/b]

C1@S1 -> S1 -> C2@S1

Success:[/b]

C1@S1 -> S1 -> S2 -> C2@S2

C2@S2 -> S2 -> S1 -> C1@S1

I’'ve tested with several combinations of Spark, Pandion and Miranda.

Wildfire is explicitly listening on just one[/i] public IP address. Perhaps there’'s some 127.0.0.1 assumptions in the server code?

Sent:[/u]

Received:[/u]

As for error logs: nothing[/i] is logged in any of the logfiles when the transfer is attempted (and fails).

Pandion is returning this error as it doesn’'t currently support the newer File Transfer protocols, which both Spark and Wildfire use. Have you attempted transfering Spark to Spark and if that is failing could you forward the corresponding packet exchange?

Thanks,

Alex

Sorry, I don’'t recall if I ever were available to test Spark-Spark. Everyone seemed to hate that Spark did not support drag-n-drop filetransfers (drag to contact in roster as well as drag to current conversation window).

Regarding Reliable presence[/b], here’'s an example of what has happend a couple of times:

I just received an instant message to my Pandion from another Pandion user on my server. Apparently the first time he ever came online he sent me a message, but his presence was not pushed to my client, so it looked as if I was chatting with an offline user!

However if I signed out and signed in again, his presence was correctly displayed.

I can not tell if this is a fault in Pandion or Wildfire, but recent reports like http://www.jivesoftware.org/issues/browse/JM-557 makes me very uncertain. Are there still other similar bugs around LDAP and groups?

I had the same EXTREMELY unreliable presence problem with a variety of users running Exodus, Pandion, Trillian and Spark. The only thing that “fixed” this for me was ditching Pandion altogether and reloading the server, i.e. reinstalling. This started for me with a certain segment of my users, but seemed to spread (almost virally) to the rest. There were times when I was on and the support engineer that sat next to me was on (I was using Spark and he was using Trillian) and we couldn’'t see each other! After I migrated the Pandion users to Exodus and Spark it cleared up a little bit, but only after a full reinstall of Wildfire did it clear up completely.

I’'m using Wildfire 2.5.0 using LDAP with manually added shared groups, using the JRE that came packaged with the RPM on Red Hat 9 using the embedded db.

Anyway, that’'s what worked for me.

Why do you, sys admin, let users running several clients from the begining? Is it hard for you for supoorting all clients?

Regards,

Win, IT, SJ

Only in the respect that I can’'t always remember who has what client.

But the main reason I used many at first was to find out what worked best and gain user feedback as to what worked, what didn’‘t and why. As we’‘re pushing towards our big rollout, we’‘ll be using two clients: Exodus and Spark. We’‘re using Exodus on the PCs that have resource limitations and Spark on the ones that don’‘t as some of our client PCs run with as little RAM as possible due to budget constraints. Trust me, if it was up to me, I’‘d only use one client (I’'m fairly enamored with Spark), but with my current situation, I needed to provide a lighter option.

My two cents on the client :). Spark DOES support drag and drop onto contact items and chat windows to initiate file transfers. Just wanted to clarify.

Cheers,

Derek