Error in getApi().getUserById(userId) during user login

[GrinReaper]

We're using the following code to retrieve the user object of a logged-in player

Code: Select all

Integer userId = userMap.get(playerId);
User user = null;
if(userId !=null && userId != -1){
   user = getApi().getUserById(userId);
   if(user != null)
      getApi().joinRoom(user, getParentRoom(), null, true, null, true, true);
}

userMap maps our assigned player IDs to the SFS ID assigned to the User object of the player. And it is updated whenever a player logs in to the application with the new SFS ID that is generated on login.

We've noticed that this code breaks when the player whose userId is being processed is also simultaneously logging into SFS. This has happened everytime. And upon debugging, it seems like it's breaking at getApi().getUserById(userId) but we cannot be sure since the method does not throw any Exception while the rest of the code is within a try-catch block so, any exception thrown by the rest of the code would have been caught.

So, can getApi().getUserById(userId) break if the user is also concurrently logging into SFS?

[Lapo]

Hi,
getUserById() returns a User object if the provided id exists. Otherwise it will return null.
There are no exceptions thrown because you can only have two different results. Either the object or a null, indicating the user does not exist.

What is not clear to me is how your userMap works.
Does it contain custom IDs that are generated by you? If so they won't work with the getUserById() method because every user object already has its own auto-generated userID.

Additionally it seems redundant to generate another user ID, when the server is already doing it for you.

Can you clarify?

[GrinReaper]

What is not clear to me is how your userMap works.
Does it contain custom IDs that are generated by you? If so they won't work with the getUserById() method because every user object already has its own auto-generated userID.

Yes, I understand that. We're passing userId which is the SFS generated IDs. playerId is our custom generated ID.

Additionally it seems redundant to generate another user ID, when the server is already doing it for you.

Can you clarify?

The ID we've generated is a permanent ID assigned to the player when he registers to our application. We're using this so that we can track a player over multiple logins for which SFS IDs are not helpful since they change on every login. So, we needed a permanent ID to assign a player for our application.

There are no exceptions thrown because you can only have two different results. Either the object or a null, indicating the user does not exist.

If that is so, then the user should either join the room (or throw SFSJoinRoomException) or the code should move on to executing the next statement. But in this case, neither of the two happen and the code simply terminates.

[Lapo]

The ID we've generated is a permanent ID assigned to the player when he registers to our application. We're using this so that we can track a player over multiple logins for which SFS IDs are not helpful since they change on every login. So, we needed a permanent ID to assign a player for our application.

You can do that, but you will have manage it yourself in your server side code.
I suppose the userMap you have mentioned earlier is the map the indexes the users via the static ID you have created.

I don't see any problem in doing this provided you don't mix the IDs. In other words get API's getUserById() will not work with your custom UserIDs.

There are no exceptions thrown because you can only have two different results. Either the object or a null, indicating the user does not exist.

If that is so, then the user should either join the room (or throw SFSJoinRoomException) or the code should move on to executing the next statement. But in this case, neither of the two happen and the code simply terminates.

I think you need to better debug your server side code, the behavior you're describing makes little sense and suggests that something else is going on.

Are you maybe running that code in a Scheduled task? Runnables executed by the Scheduler need to explicitly catch Exceptions or they will be swallowed by the running thread.

Let us know.

[GrinReaper]

I think you need to better debug your server side code, the behavior you're describing makes little sense and suggests that something else is going on.

We've added traces before and after the code block, and in the case that I've mentioned the traces after the code block don't get output in the logs. We're unable to replicate this in our test environment due to the timing involved but it has occurred a few times in the production where we have a lot of users so that there is a significant probability of the condition occurring.

Are you maybe running that code in a Scheduled task? Runnables executed by the Scheduler need to explicitly catch Exceptions or they will be swallowed by the running thread.

The code is not running in a Scheduled Task directly, but instead in a method that is called by a Scheduled task. And I don't understand what do you mean by the Exceptions being swallowed by the running thread.

[Lapo]

The code is not running in a Scheduled Task directly, but instead in a method that is called by a Scheduled task. And I don't understand what do you mean by the Exceptions being swallowed by the running thread.

This could be the problem.Scheduled tasks must explicitly capture Exceptions in the run() method.

Make sure to check this example:
http://smartfoxserver.com/blog/how-to-s ... extension/

cheers

[GrinReaper]

We'll try that and deploy it to production. Hopefully, the next time the issue occurs, we'll be able to catch the Exception and take appropriate action to correct the issue.

Thank you