Hi all - another quandary:
Most of our users are using Pidgin, which works very well - however, maybe 1 in 5 users has the following issue: when they change their status (away, etc.), the result doesn’‘t immediately show up in Pidgin. The other 4 users’’ status updates are immediately visible by all - however, we’'d like to have that 5th user in the fold.
Is there a setting somewhere for how often a user status check is done? Or could this be some other symptom? We grab our user info from an LDAP directory, but given that some users update immediately and others do not, I can’‘t imagine that’'s the problem.
Thanks again for all of your assistance.
A little update on my part - looks like user presence and status both update immediately in the Openfire admin console, but the clients (Pidgin, etc.) are slow to respond. The first inclination should be to update clients where people are having a problem, but that doesn’'t seem to be the whole issue … still searching for a parameter for client updating, etc.
AFAIK the XMPP protocol makes no provision for delayed presence updates. The client of the user who changes status send the update immediately to the server and the server immediately relays it to all subscribers. If you observe delays, they should be network related.
I don’‘t see how that’‘s possible - several users have this working fine, and they lie on the same subnet as users who do not have it working. As I said before, the Openfire console is showing immediate status changes in the roster - it’'s the client-side programs that are sporadic.
Very well, but no XMPP-compliant client or server should have any parameter that delays presence notifications. The client of the user who changes status will push this to the server immediately and the Openfire server will push this to all subscribers immediately. There are no provisions for an artificial delay, so you will not find any parameters to influence it.
That makes sense.
Next step was to turn on Pidgin’‘s debugging output and see what happened when “working” users changed states and when “non-working” users changed states. Seems the “working” users’’ clients send some XML string that looks like this:
jabber: Recv (ssl)(239):
The “non-working” users never send that presence-update notification … not sure what that means, but it’'s a route to follow.
Another update, for anyone - past or future - who might want to follow this twisted story.
So, I got clients’’ notifications to work … sort of. It involved deleting the users that were placed in the Openfire group by LDAP, re-creating them, re-requesting authentication from them (remember, using Pidgin), and then restarting Pidgin.
However, that defeats the whole purpose of auto-population - I don’'t want our employees to have to manually add every new employee; that should be taken care of by AD.
This leads me to believe that while everything is great on the server, the users in the Openfire group aren’‘t all correctly XMPP-authenticated to see the other users online, doing status changes, etc. This doesn’'t explain why SOME of us can see some others of us … once again, this is very sporadic, and therefore difficult to pin down to one problem.
I’'ll keep updating - since this is such a big issue and so many people are interested in it, it may be worthwhile for someone to figure all this out, too. As always, and advice/opinions along the way is greatly appreciated.
New update - a complete restart of the Openfire server made users start appearing in other users’’ Jabber buddy lists - thought the problem was solved. However, this morning, several users signed on, and while Openfire registered them as being online, Pidgin/Trillian/etc. did not on several clients.
This makes me think that somehow, Openfire is screwing up XMPP authorization - I imagine that without correct authorization, XMPP will not allow users to see other users. No understanding of why some users can get online, update status, etc., but I imagine that Openfire dealing with Jabber authorization is at the heart of it.
Arggh, this is frustrating.