Openfire 3.3.0 Presence and status problem

I’'m running openfire 3.3 on Suse EL 10.

Using LDAP for users and groups.

My groups are all shared for all users its a fairly basic setup only about 45 users of which 12/13 are logged in at the moment.

The problem is status and presence information is not being updated on all the clients, if a user logs out I see them go on the sessions page on the web console, but the client shows them as online.

This seems to be only some users, for example one user see’‘s my status change, but I don’'t see hers changem, yet with another user our statuses are fine.

I have had a user i’'m having problems with log back into thenold Wildfire 3.2 server and his presence is fine.

Logging out and logging back on updates the roster to be right for that instant but then it doesnt change to show changes as people go online/away etc.

Clients are Spark with a few different versions.

Any ideas, this is really frustrating.

Message was edited by: Jarlrmai

Message was edited by: Jarlrmai

Okay no replys.

I figured out it was the LDAP groups causing the issue for whatever reason.

I commented out the LDAP group provider so I can use my own groups, set them up enabled roster sharing etc.

All worked fine

Now, my groups have vanished.

When I log in all my contacts are listed in an “Unfiled” group.

When I connected to Admin Console no groups are shown.

How do I get my groups back?

I have been having the exact same problem for a long time (http://www.igniterealtime.org/forum/thread.jspa?threadID=24541&tstart=0) , and I just tried 3.3.2 hoping it was fixed - and it is still not. So its back to 3.0.1 for me.

Can anyone at jive give us a pointer?

For reference here is the openfire.xml file i just tried (this is with some of the elements mentioned by other users added)…

i’'m having similar problems, i have openfire talking to my LDAP server, the users seem to auth fine but some are only talking one way, some say pending, some showing offline even though they are on. is this what your getting?

I have found that status errors can be caused by users that have created local groups that have the same name as published server groups. The 2 groups merge and the users duplicate and cause status errors. Remove the duplicate local groups and the proble goes away.

“i’'m having similar problems, i have openfire talking to my LDAP server, the users seem to auth fine but some are only talking one way, some say pending, some showing offline even though they are on. is this what your getting?”

Yep, that sounds like it. Quick test to verify…

If User A sees User B as offline but in fact User B IS online and User A logs out then back in, do they now see User B as online?

It seems that the openfire server never sends presence updates for online users to other users that are subscribed to said user, however if you logout/in the client will request status of everyone in its roster and openfire will reply with that.

Oh, and none of my users have created any personal groups in their roster in addition to what I push from the server so there are no clashes with group names.

I’'m right there with you - Openfire shows status & presence just fine, but the thick clients (Pidgin/Trillian/Adium/etc.) are spotty.

It’‘s almost like the people who authored the thick clients didn’'t adhere very well to the Jabber/XMPP specs …

Actually, if you use a client that has an XML console (like psi) you will see that the presence updates are never sent to the client from the server as it should be - the fault is the server, not the clients.

Ahh, I see - I initially mistook that debug info for client issues … strange! Well, at least if it’‘s in the server, it’‘s presumably something we can correct. I’‘m going to run Openfire’'s debug window for a while and see if I spot anything unusual.

bachya: what are you using for your LDAP back-end? Since this seems to revolve around using LDAP, and groups. From some of the other posts I have seen people with this issue they where using an openldap based back-end (as am I) so I’'m wondering if that is the final common linking element to the bug. Since if AD people had the problem there would be a much larger vocal group…at least I would assume.

Jive: any chance we could get this in the issue tracker like I have been asking for a while? The issue keeps coming up and it just falls off the forum forgotten about. It sure doesn’'t reassure me if I where to purchase the enterprise license of openfire and had a problem that I could get it resolved since I would not be spending more than $2,500 on the license to get anything above forums-only support.

rparrish: Sadly, we are using AD - however, I may have made SOME progress: I was naming the shared LDAP group a name that was already in use for a lot of legacy ICQ accounts some people use … I read somewhere that duplicate group names can cause such errors. I renamed it to something unique, and it LOOKS like it’‘s working. Of course, it’'s done that before, and I doubt such a simple item would be the WHOLE problem …

just to add to the discussion, we are using AD for LDAP and all the presence\status stuff has been working fine (we’'ve tested on Pandion, Spark, PSI, and Adium (sp?)). We did run into issues early when we tested it without using the group part (so we had to request “friendship” etc). Doing it this way did cause some presence issues. Once we had everyone delete their local contacts completely and then “turned on” the group rosters (with very unique group names to avoid the duplicates issue) users just showed up as contacts automatically if they were in a common group. From there on, the status\presence has worked quite well.

Thanks for your post, scarr - I came in this morning and found that the group for Openfire only had 4 contacts (in Pidgin) - however, 8 we logged into Openfire. Upon deleting that group and restarting the account, all the contacts showed up … however, this still seems sporadic - I’'ll have to keep an eye on it. Perhaps all the restarts and config changes require a full deletion of the group before Openfire can populate the rosters correctly.

SUCCESS, my friends! (I think) I may have a solution for you - another admin here suggested that caching might be an issue - tried clearing all the caches in Openfire, and bingo: my Pidgin roster updated to reflect what Openfire was telling me. Sweet!

In doing some further research, we stumbled across this page: http://wiki.igniterealtime.org/display/WILDFIRE/HowtoconfigureWildfire%27scaches - the Roster, Group, and Group Users caches were what I looked at - I’‘ve set them to 0 for the moment, so I’'ll have to check back with you to see if that fixes things.

SIDENOTE: Openfire caches things for a default of 6 hours (who picked THAT arbitrary amount??) - I’‘m guessing this was done to handle high loads of users (if you’‘re constantly getting updates for 200+ users, you’‘re probably going to run your server into the ground). Our company handles around 14 or so users, so taking the caching way down probably isn’'t a big deal. Use your own discretion when it comes to your situation.