Finally got back to looking at this and the issue seems to have resolved itself.

The project is now running Unity 5.6.1p4 with the version 1.7.2 of the SmartFox2X dll, so presumably one of those upgrades fixed things (still running with ThreadSafeMode disabled).

Thanks Lapo,

I'm not able to reproduce a crash in your test project, but calling InitUDP() is definitely the catalyst for a 100% crash issue in my full project.

I'll continue to build up your test project / simplify my project until I find a solution and let you know if I do.

The one major ...

I've running into an issue with my unity app where on all Andriod devices if the UDP connection fails to establish the app crashes. The last log statement is from somewhere internal to the smartfox.dll, although I don't see anything in the crash stacks to indicate the origin of the failed static ...

Fair enough.

In your scenario though if 12 users (or whatever the configured max extension thread pool size is) are all waiting on a DB operation you have the same issue but the entire game freezes, so I would discourage that kind of design in the first place.

Either way a request numbering system ...

Okay, so requests are queued in the order they are received?

In that case the reason my original example is executing in a different order is because:


Thread A grabs a command
Asks for the lock on the user object
Thread B grabs a command
Asks for the lock on the user object
Thread B ...

Good point, for this contrived example a combination request makes sense. And in my real use case the client game play changed to injected a user step between the commands, creating the needed delay.

However, I feel there's still the potential for unexpected consequences with the current behaviour ...

I believe this is a current SFS limitation, but let me know if that assumption is incorrect.

Here's the situation I'm trying to resolve:


public class Handler1 extends BaseClientRequestHandler {
@Override
public void handleClientRequest(User user, ISFSObject params) {
synchronized (user ...

I'm running into the same situation of needing to track seemingly redundant data.

I have a custom command for player positional updates which modifies the MMOApi user position and then is broadcast to all clients within the AOI. When another user enters the AOI the PROXIMITY_LIST_UPDATE event on ...

Everything is looking good far, I'll let you know if any issues arise.

Alternatively it looks like if I disable ThreadSafeMode, wrap all events from the SmartFox class, and put the processed events back onto the main unity thread (after I've extracted the relevant user data myself) everything behaves as I'd expect (matching .NET/Mono).

I know disabling thread safe ...

Thanks Lapo,

That's what I expected was causing the behaviour.

I guess I'll have to rethink my approach here, originally I was consolidating the network events as you suggest, however the client triggers logic on the state transitions, so it's imperative that they receive both network events. For ...

Certainly, the relevant server side code looks like this:


UserVariable propertiesVariable = new SFSUserVariable("con_prop", "{\"actionCount\":0}");
SmartFoxServer.getInstance().getAPIManager().getSFSApi().setUserVariables(user, Arrays.asList(propertiesVariable));
...
List<UserVariable> vars = new ...

I've come across a situation with appears to be a race condition in the SFS2X client.

Setup:

smartFox.AddLogListener(LogLevel.INFO, onInfoMessage);
smartFox.AddEventListener(SFSEvent.USER_VARIABLES_UPDATE, onUserVariableUpdate);

private void onInfoMessage(Sfs2X.Core.BaseEvent evt)
{
string ...