I’‘m running Wildfire 2.5.1 and Spark 1.1.3 (on the majority of my clients). I’'m noticing that my contact roster is not updating properly. If I quit Spark and wait a few seonds then reload it; i see more people online. Is this a known bug?
I’‘ve just upgraded to 2.6.2 and Spark 1.1.4 and I’'m still seeing the roster problem.
Anyone else seeing this? Any temporary fixes?
I still have to hve my clients shut down their messenger clients & restart them to get a current contact roster.
Is anyone else experiencing this? I’‘m not using LDAP. I’'m using Wildfire 2.6.2 and MySQL 5.0 on Windows2000 SP4 w/ Sygate Personal Firewall Pro.
I seem to recall this happening with me as well. I’'ve not had a problem using Pandion instead (which also has a smaller memory footprint than Spark).
I didn’'t think it was client related… Hmmm
I have people using eXodus & Psi who are seeing the same thing. I’'ll have to double check with them again & verify it is (or is not occuring) with them.
Best I can remember, I think I saw it when I upgraded from Jive Messenger 2.3.1 to 2.5.1. (Not saying thats the definitave time, but thats when I can recall seeing it).
I just noticed this problem myself. I just enabled LDAP groups last week and created the shared rosters from the LDAP groups. When I log in, Ill see all the people that were on before me. People that come on after me do not show up. I log out and immediately log back in and everyone is there.
Running 2.6.2 and Spark 1.1.4
That’‘s whats got me wondering. I saw a post related to no updates when using LDAP, but I’'m not using LDAP.
Any status on this? Anyone else seeing it?
I just connected this morning & I’'m still seeing the problem.
I think i’'m having the same issues. We use Exodus, and you connect and it shows all users offline, then about 15 min. later you start seeing who is actually online. We are NOT useing LDAP either. Running it on Windows 2003 Server/MSSQL platform w/ Wildfire 2.6.2
I’'m wondering if I should try going to a different IM server because I have never been able to get Jive or Wildfire to run stable.
I had very little trouble with Jive/Wildfire. This is the only time.
As I said before, I didn’'t see this problem when I was running JiveMessenger 2.3.x. I only saw this when I upgraded to 2.5.1 and later.
The only thing I can’‘t tell is if it’‘s MySQL related. My original server was running MS SQL 7.0, but I couldn’‘t manage the system via the GUI. I’'d have to go into the database itself to make changes.
I’‘m seeing this same problem as well. It doesn’‘t seem to matter what the client is - I’‘ve tried with Psi, Pandion, and even meebo and they all have the same issue - status changes for your contacts frequently don’'t show up on the roster until you sign out and back in again.
Maybe its related: i have the Problem if i am connected with 2 resources. Only the high prio res gets the online/offline/away notifications. i dont think thats the way it should be.
I’'ll try to verify the 2 resource thing - I am frequently logged on from more than one place.
I made sure I was only logged in from one client, and it’‘s still doing the same thing. I’'m not getting updates when people sign in or out, but if I log out and back in, their status shows correctly.
I think I found my problem… The routing table is case-sensitive. So if somehow you have Me@mydomain.com on your roster, and I log in as email@example.com, I don’‘t get presence updates because the call to routingTable.getRoutes() in Roster.broadcastPresence() doesn’'t return any sessions.
I don’‘t think that’'s my problem. All users are set to auto login & none of them change how they enter their names.
I’‘ve been using JiveMessenger/Wildfire faithfully for around a year & just recently switched to Spark for my clients & this is the first “show stopper” issue I’'ve experienced.
I don’‘t allow changing names either, but when you log in it looks like the server forces the login name to lower case. It doesn’‘t sound like it’‘s the same problem, but it’'s worth double-checking the jiveRoster table to make sure that everything in the jid column is lower case as well.
It appears to be a problem with the way groups are being shared.