Rejoined an empty room with EmptyRoomTtl = 0
Hi Photon folks,
I am working on an application where we are using Photon Rooms with EmptyRoomTtl set to 0. However, I was investigating a bug and noticed we have a (rare) scenario where all users leave a room, and a subsequent JoinOrCreateRoom with the same name is joining the same room instance that was left empty, reinstantiating some PhotonViews.
I'm wondering if our code is holding references to PhotonViews in that room, but looking at the documentation, the room is considered empty when all users leave, not when all content is removed. Is there another explanation that could cause an empty room to stick around?
Interestingly enough, I'm looking through the Photon code and I don't see EmptyRoomTtl used anywhere, and it's probably worth mentioning that we're using CleanupCacheOnLeave = false in order to keep a user's content around after they exit.
Also worth noting it appears from the logs that the user joined and was not deemed master client, although there were no other users, which makes me think someone failed to leave the room when disconnecting. I see that our code doesn't check the return value of PhotonNetwork.LeaveRoom. What are the reasons PhotonPeer.SendOperation(OperationCode.Leave, opParameters, SendOptions.SendReliable) would fail? If that was our issue, what do we do in this case? Simply retry?
Thanks!
I am working on an application where we are using Photon Rooms with EmptyRoomTtl set to 0. However, I was investigating a bug and noticed we have a (rare) scenario where all users leave a room, and a subsequent JoinOrCreateRoom with the same name is joining the same room instance that was left empty, reinstantiating some PhotonViews.
I'm wondering if our code is holding references to PhotonViews in that room, but looking at the documentation, the room is considered empty when all users leave, not when all content is removed. Is there another explanation that could cause an empty room to stick around?
Interestingly enough, I'm looking through the Photon code and I don't see EmptyRoomTtl used anywhere, and it's probably worth mentioning that we're using CleanupCacheOnLeave = false in order to keep a user's content around after they exit.
Also worth noting it appears from the logs that the user joined and was not deemed master client, although there were no other users, which makes me think someone failed to leave the room when disconnecting. I see that our code doesn't check the return value of PhotonNetwork.LeaveRoom. What are the reasons PhotonPeer.SendOperation(OperationCode.Leave, opParameters, SendOptions.SendReliable) would fail? If that was our issue, what do we do in this case? Simply retry?
Thanks!
0
Answers
-
Hi @midrangemonroe,
Thank you for choosing Photon and for your report!
The server could still consider the room as non empty if one of the clients still not considered disconnected.
You could make sure if you wait for 10 seconds at least and no client is joined + get the room via AppStats or LobbyStats OR if you also join the lobby (if default type) and the room shows 0 players.
If it's still the case please send an email to developer@photonengine.com with the AppId, AppVersion, PUN version + lobby name/type + room name.Also worth noting it appears from the logs that the user joined and was not deemed master clientWhat are the reasons PhotonPeer.SendOperation(OperationCode.Leave, opParameters, SendOptions.SendReliable) would fail? If that was our issue, what do we do in this case? Simply retry?0 -
Thanks for the response, JohnTube! Much appreciated.
Looking closer at our logs, I'm finding, interestingly, that both participants gracefully exited the room. They each received callbacks for OnLeftRoom and OnConnectedToMaster. Considering this, it seems like the server should have been fully aware of their disconnects. Again, I'm hesitant to suggest it, but is it possible Photon failed to clean up one of the users when they left, thereby keeping the room around during the 10-second activity timeout? We also have PlayerTtl set to 0, so that shouldn't cause any lingering lifetimes.0 -
I see, then I invite you to send that email to developer@photonengine.com with all the details (the AppId, AppVersion, PUN version + lobby name/type + room name, etc.).
Link to this forum discussion etc.
also @chvetsov may have more info on this as he's our most experienced senior server developer.0 -
Sounds great. Will do. Thanks for the help!0
-
hi, @midrangemonroe
glad to see person that is not afraid of server logs and code
our peers logs about disconnection using DEBUG log level. so, if you set debug logging you have to see whether peer was disconnected as you expect or not. this may explain a lot.
assuming you are using sdk4 please take a look at HiveHostGame.ProcessBeforeCloseGame and next to it. you will understand better how EmptyRoomLiveTime works
best,
ilya0 -
Hi @midrangemonroe,
I was thinking you are connecting to Photon Cloud right? and not a self-hosted Photon Server.0 -
Hi!
We are experiencing a similar if not the exact same issue.
Was there anything that came out of this?
-Pieter0 -
Hi @PieterAlbers,
Are you using Photon Cloud or self-hosted Photon Server?
I think this issue is still there, so you might want to look into managed server logs if you use self-hosted Photon Server or send us all details if you use Photon Cloud.0 -
Hi Sorry for the delay. We using Photon Cloud - but in the meantime I think our issue might be somewhere else. I suspect that our issue is related with players being removed from the game when they are out of focus (WebGL running in background 1 update per second). I suspect he OnLobbyJoined and subsequent OnRoomLIstUpdated is missed on the clients end when in background thus showing old rooms from the cache. At least that's my theory for now.0