I have managed to create a room and join it, apparently successfully. I can see the outgoing message sending presence for my user to that room and I can see that the user is listed as an occupant when the room is viewed via the admin console. However, I never receive any presence event from the server so I never get a ROOM_JOIN event letting me know that the server has acknowledged me entering the room.
The room is not being created dynamically because I have disabled the ability of users to create rooms on the fly. I created the room through the admin console and I have all three boxes checked (moderator, member, visitor) in the section about broadcasting presence. Is there some other requirement for me to be an acknowledgement from the server to my joining the room?
I can’‘t be sure if this is an OpenFire issue or something wrong with either the XIFF API or my usage of it so I’‘m posting here first. Once I’‘m convinced it is not a XIFF problem (assuming it isn’'t fixed by then), I will post to one or more of the other forums. Thanks for any suggestions.
I have discovered, I believe, the source of the problem … but I’'m not sure the consequences of it.
It seems if I am disconnected (e.g. I just close the browser in which my chat client is running) from the server without ever officially leaving the room, the chat server still shows me as being in the room … and if I re-enter the room after re-launching the chat client, I get no presence event, no room join event, and no subject change event (presumably because the server believes I was already in the room).
This seems to me a problem since I cannot ever guarantee that every client will have an opportunity to leave the room before disconnecting from the server. What if the network just goes down temporarily? Shouldn’'t the server detect when the connection has been dropped and automatically remove the user from any rooms they were in?
As things stand right now, if I get disconnected abnormally, any attempt to reconnect doesn’‘t work right because I don’'t get all the events I expect to get after I am logged in. Has anyone else dealt with this problem already? Am I missing something?
I have discovered after further investigation that things are indeed as I described.
If the client is abnormally disconnected, the server seems to detect the disconnect because the user session is terminated on the server (I was able to observe this through the admin console). However, if the user is in a room at the time and never issued a leave request, then that user continues to show up as being in the room even though they are not even logged in any more!
Interestingly, if I reconnect and reenter the room using the Spark client, Spark seems to choose a new nickname for the user … e.g. if bill is already in the room, then Spark uses bill2 and you then see both bill and bill2 in the room (even though both are really the same user and the first bill is no longer logged in). What is worse is if I use XIFF to connect and I use the same nickname (because I don’‘t know it is still in use), the server just does not let me enter the room … shouldn’‘t I get a nickconflict event in this case? Honestly, I don’‘t even like that option because I don’'t want to use a different nickname … what I really want is for the old (stale) user to be removed from the room so I can reenter using the nickname I chose.
Has no one else ever encountered this? Any comments or suggestions? Please?
I have discovered that if I can arrange to have a leave room message sent to the server right before I send it a join room message, it fixes the problem. That is, the leave message removes the old ‘‘stale’’ user and then the same user can enter the room once again. However, the current XIFF API only sends the leave room message if the user is active in the room … and the active flag is maintained on the client side. This means that if the client abnormally exits such that the client-side state is lost, the leave room message won’'t be sent even if you call the Room.leave() method. I had to remove the check
if ( isActive() ) {
}
from the leave method to ensure that a message is sent each time leave() is called regardless of whether the client believes the user is in the room or not. It seems to work.
However, even though the server doesn’‘t seem to mind getting a leave message when the user isn’'t actually in the room, it makes me a little nervous since this still seems like a bit of a hack. I have another forum entry going regarding what I think is the best solution … to have the server remove the user from the room automatically as part of cleaning up the session on a disconnect. However, it seems to me that there are a couple of ways to improve on the XIFF API as well.
Add an optional parameter (default to false) to leave() which forces the presence message to be sent whether or not the client thinks the user is in the room. I plan to make that change myself.
Have the isActive() method determine whether the user is active in the room by querying the server rather than maintaining this information on the client where it will be lost if the client abnormally exits. I need to research the appropriate message for making this query, but I am fairly certain it is possible.
I’m glad to have seen your post. I had the same problem when the user is disconnected abnormaly. And thanks to your hack, I fixed it for the users who have an account. Did you manage to find a “better” solution, I mean, less like a hack…
It would be better, as you say, that the server updates the room status when a user is disconnected.
I still have a problem for the users who login anonymously.
When I connect to a room anonymously, with a nickname like “nick”. If I close my browser and try to reconnect with the same nickname, I can’t!! I receive nothing. At the beginning, I supposed that I would receive the “nickConflict” event, but it is not fired as I don’t receive any “presence” event…
I’ve downloaded the latest Openfire code from their repository and built it, and it seems to fix this issue. However, when you start a session, and start another one after that (without closing the first session), the server is unable to route the error message (nickname conflict) back to the application.
The server debug logs show this:
2007.10.24 19:45:07 Failed to route packet to JID: cf5ea3b2@mark-pc/cf5ea3b2 packet:
Kind of talking to myself here, but I found out the problem by debugging the openfire code: I had to set the Roster presence of the client to make sure it was “routable” from openfire.