I’'ve got a presence problem that is driving me nuts…
Sometimes when my client logs in I don’'t get the presence packets (Usually after I have been logged out for a time). I have seen this talked about on the forums…
What I’'ve done is made a timer reload the roster 7500 milliseconds after the connection is made. I still never get the presence packets then. If I log out, and then re-login, the packets come in fine.
Do you guys have any idea why this would be happening?
Just out of curiousity, what server are you using?
What I suspect is you are receiving the roster ok, but your presence updates are beating the roster so the presence is getting dropped. Reloading the roster won’‘t help. However, you should be able to send presence-unavailable, then presence available to trigger another presence probe (updating all your roster entries). To confirm, try to run your client with debugging on and look at the XML being sent. If you see presence getting to you before your roster arrives, that’'s the essential problem.
One thing you may want to try is to create the connection, getRoster(), then send new Presence(Presenge.Type.UNAVAILABLE), and follow that with new Presence(Presence.Type.AVAILABLE) and let us know what the results are.
Ok, your method works - but it seems like there should be a better way?
What I have done for now is edit the smack code and take the part out where it sends the AVAILABLE presence in login, and then I am just sending the presence after I get my roster and everything.
Is it my implementation that is causing a problem (am I doing it wrong somehow), or is this a problem with smack itself?
Glad it now works. Source access is nice isn’'t it.
Looking at the code, I’‘d suspect it’‘s a bug in Smack (I’‘d code the way you’‘re doing it but I know Matt was doing things the current way because of some other issues so I’‘m not sure what the ‘‘best’’ solution is). I’‘m a bit suspicious though since it’'s not been hitting other people (we are using Smack extensively in internal projects and it works fine). Are you on a particularly fast or slow (or otherwise unusual) connection?
I’‘ve also ‘‘robustified’’ Messenger’‘s behavior with regards to presence and roster. Since we develop Smack against Messenger it could be a Jabberd vs. Messenger difference (we’'re always interested in learning about those differences).
Hopefully Matt will read this tomorrow and be able to shed more light on why presence-available is being sent before roster-get. If there is no particular reason, I’'ll file an issue to swap the calls which should solve the problem.
I have the presence packet catcher almost working perfectly. I still have one quirky problem though…
When I send someone a subscribed packet (they have already sent me a subscribed packet and I can see their online status), they suddenly appear as though they went offline. They reappear if I sign off and then back on. How can I fix this?
When I send someone a subscribed packet (they have
already sent me a subscribed packet and I can see
their online status), they suddenly appear as though
they went offline. They reappear if I sign off and
then back on. How can I fix this?
Can you turn on Smack debug and see what’‘s coming through on the stream? If you can provide some details on that, I should be figure out if it’'s a Smack logic problem or something else.
If the packets are as shown, then the roster is not getting the presence updates after it creates the ‘‘both’’ subscription roster item. But it is getting them earlier and ‘‘forgetting’’ about them as it’'s state changes.
Matt, are the old roster list items essentially being replaced with new ones rather than updating (and hence losing the old presence)? Looks like presences need to be cached (or roster item presences preserved) because jabberd isn’‘t pushing presence out when roster items change. Messenger is very paranoid about always sending presence again when rosters change so testing Smack against Messenger wouldn’'t run into this problem.