I'm getting this quite often. I have a loop on the server which sends messages to clients, and when some unknown situation arises, every time a message is sent to the client this turns up as a popup from Flash. Which basically locks up the browser since the popups appear several timesa second.
Obviously I've done something wrong, but surely it's not great for SF to behave like this when it receives some bad xml? Is there any common cause for this, like setting something to null, or is it a general "something's wrong" error? Also, should it really be telling us the path where Lapo does his development work.
TypeError: Error #1088: The markup in the document following the root element must be well-formed.
at it.gotoandplay.smartfoxserver::SmartFoxClient/xmlReceived()[/Users/Lapo/Documents/Flex Builder 2/SmartFoxClient_AS3/src/it/gotoandplay/smartfoxserver/SmartFoxClient.as:320]
at it.gotoandplay.smartfoxserver::SmartFoxClient/handleMessage()[/Users/Lapo/Documents/Flex Builder 2/SmartFoxClient_AS3/src/it/gotoandplay/smartfoxserver/SmartFoxClient.as:1418]
at it.gotoandplay.smartfoxserver::SmartFoxClient/handleSocketData()[/Users/Lapo/Documents/Flex Builder 2/SmartFoxClient_AS3/src/it/gotoandplay/smartfoxserver/SmartFoxClient.as:1401]
at flash.events::EventDispatcher/dispatchEventFunction()
at flash.events::EventDispatcher/dispatchEvent()
at it.gotoandplay.smartfoxserver.handlers::ExtHandler/handleMessage()[/Users/Lapo/Documents/Flex Builder 2/SmartFoxClient_AS3/src/it/gotoandplay/smartfoxserver/handlers/ExtHandler.as:41]
at it.gotoandplay.smartfoxserver::SmartFoxClient/xmlReceived()[/Users/Lapo/Documents/Flex Builder 2/SmartFoxClient_AS3/src/it/gotoandplay/smartfoxserver/SmartFoxClient.as:327]
at it.gotoandplay.smartfoxserver::SmartFoxClient/handleMessage()[/Users/Lapo/Documents/Flex Builder 2/SmartFoxClient_AS3/src/it/gotoandplay/smartfoxserver/SmartFoxClient.as:1418]
at it.gotoandplay.smartfoxserver::SmartFoxClient/handleSocketData()[/Users/Lapo/Documents/Flex Builder 2/SmartFoxClient_AS3/src/it/gotoandplay/smartfoxserver/SmartFoxClient.as:1401]
What is this error and why is it allowed?
This has been happening every now and then on our servers too.
When looking at the client logs I can see that uCount updates seem to rise in size all the time and there is some kind of problem with SFS not cleaning up the buffer before sending next message but sends multiple messages concatenated with previous message prepended to new one.
We are still using 1.5.9c
When looking at the client logs I can see that uCount updates seem to rise in size all the time and there is some kind of problem with SFS not cleaning up the buffer before sending next message but sends multiple messages concatenated with previous message prepended to new one.
We are still using 1.5.9c
Ah we found it i think.
We are refreshing the room list when returning from game because our roomlists do not seem to update while in-game.
If you refresh room list, you lose current users in the room because current user list is sent with joinOK.
Now if some user leaves room, Syshandler will break down in line 351 because user doesn't exist and after that the buffer is not cleared and all hell breaks lose.
We are refreshing the room list when returning from game because our roomlists do not seem to update while in-game.
If you refresh room list, you lose current users in the room because current user list is sent with joinOK.
Now if some user leaves room, Syshandler will break down in line 351 because user doesn't exist and after that the buffer is not cleared and all hell breaks lose.
You replied a couple of second before my last response 
This is correct.
The sequence should be this:
1 -> you are still in game room
2 -> user clicks "LEAVE GAME"
3 -> you call getRoomList()
4 -> handle the event and finally connect back to, say, the Lobby
Do you mean that the problem arises when a user in the current game room leaves while you are between point 3 and 4?
If you refresh room list, you lose current users in the room because current user list is sent with joinOK.
This is correct.
The sequence should be this:
1 -> you are still in game room
2 -> user clicks "LEAVE GAME"
3 -> you call getRoomList()
4 -> handle the event and finally connect back to, say, the Lobby
Do you mean that the problem arises when a user in the current game room leaves while you are between point 3 and 4?
Ok, I see that you have been thinking of alternate approach for returning from game room back to lobby.
Our client first joins to lobby and then refreshes the whole room list, because of original design issues.
However, because this doesn't of course work, we just patched the client api so that it copies the users from active room before reseting the list
Also we added try catch around handleMessage(byteBuffer.toString()) in SmartFoxClient#handleSocketData to prevent total break down of message handling if other similar errors appear (NPE etc).
I have to say that working with SFS has been interesting experience and looking forwards to it regardless of the rough patches here and there (like no support for 3rd party user data connectivity / custom uid factories, although we did it anyways
)
Our client first joins to lobby and then refreshes the whole room list, because of original design issues.
However, because this doesn't of course work, we just patched the client api so that it copies the users from active room before reseting the list
Also we added try catch around handleMessage(byteBuffer.toString()) in SmartFoxClient#handleSocketData to prevent total break down of message handling if other similar errors appear (NPE etc).
I have to say that working with SFS has been interesting experience and looking forwards to it regardless of the rough patches here and there (like no support for 3rd party user data connectivity / custom uid factories, although we did it anyways
)Ok, I see that you have been thinking of alternate approach for returning from game room back to lobby.
Not very alternative, actually. This is the way it is handled in all our game examples since SFS exists
Also we added try catch around handleMessage(byteBuffer.toString()) in SmartFoxClient#handleSocketData to prevent total break down of message handling if other similar errors appear (NPE etc).
We are not aware of any problems with that part of the code and it sounds strange that an NPE could be thrown at that point.
no support for 3rd party user data connectivity
What does it mean?
custom uid factories
The way the server handles the UIDs is not replaceable and it was not designed to be replaced. However the client and server framework allow to add your own ID management system if you need something more sophisticated or if you need to link with an external webapp/database etc...
Well, our flash based games are only small part of the site and all authentication and user data actually is contained at external databases with XML-RPC based service that provides user names, avatar images, available micropayment products etc based on php session ids.
This means that because sfs login is made with username and not custom uid (we know, we could login with session and set actual username etc as user variables and fix everything in client but then chat would be cumbersome, nice idea though), we are forced to make SFS ID <-> Our ID mappings and also SFS Nickname <-> SFS UID mappings in some cases. (Although we login using the user name, we cannot logout user with its usern ame and there is no way to search for sfs uid based on username by default).
This login/logout synchronization nastiness usually starts happening when user reloads the client multiple times / logs with two different browsers / using different php sessions and proper 3rd party logout is still in progress (we do not log users out of sfs until we get proper logout from 3rd party server which happens asynchronously) etc etc.
We also develop everything with java based extensions and our extension code already is over 10k lines of java with multithreaded xml-rpc action buffers to handle userbases over 10k users with only 100 connections to xml server and other nice and fun stuff to debug
btw, getting bit offtopic right
This means that because sfs login is made with username and not custom uid (we know, we could login with session and set actual username etc as user variables and fix everything in client but then chat would be cumbersome, nice idea though), we are forced to make SFS ID <-> Our ID mappings and also SFS Nickname <-> SFS UID mappings in some cases. (Although we login using the user name, we cannot logout user with its usern ame and there is no way to search for sfs uid based on username by default).
This login/logout synchronization nastiness usually starts happening when user reloads the client multiple times / logs with two different browsers / using different php sessions and proper 3rd party logout is still in progress (we do not log users out of sfs until we get proper logout from 3rd party server which happens asynchronously) etc etc.
We also develop everything with java based extensions and our extension code already is over 10k lines of java with multithreaded xml-rpc action buffers to handle userbases over 10k users with only 100 connections to xml server and other nice and fun stuff to debug
btw, getting bit offtopic right
Return to “SmartFoxServer 1.x Discussions and Help”
Who is online
Users browsing this forum: No registered users and 44 guests