forums.smartfoxserver.com

Posted: **07 Jul 2011, 17:30**

One think: can the problem be because of lack of memory?

Posted: **08 Jul 2011, 06:22**

I am sorry, I fogot to say: In flash-client I am display amount of online users (get this value from your SmartFox class). Usual, this value are correct - about 200-300 online users. But if I my flash client will work a long period of time (3-5 hours, or night) this value may become about 500-700 online users, but it's not correct (real online users may be about 200-300). This functional only in your code. Have you any ideas? I think, it's may be coonected with out issue.

Posted: **08 Jul 2011, 06:58**

One other thing I've noticed is that this gets worse over time.

Here's how it looks after a week of sfs2x uptime:

Notice the huge spike of dropped packets during user drops. This server is on Amazon EC2 so I'm pretty sure they don't have a network bottleneck. Changing to more powerful instances doesn't help.

However, this is the dropped packets over a week:

Once I restart the server, it goes back to normal, but once more the dropped packets build up over time. I'm pretty sure there's no memory leak or anything. RAM usage is the same over time. The server processor is perfectly fine.

What me and regulxenao have in common is that we're both using Facebook and the AS3 client.

I don't know if this is happening to my iPhone users. When a user disconnects, I'd like to print out which client the user is connected through (iphone or AS3). How can I do that? I can't find it in the docs.

Does this help narrow things at all?

Posted: **08 Jul 2011, 07:05**

Additional information: we use Amazon EC2 too.

Posted: **08 Jul 2011, 08:14**

One think: can the problem be because of lack of memory?

Maybe. Or lack of CPU too. They are basically two sides of the same coin.
When you are low on memory the GC works hard taking more CPU and making the JVM lag.

Lack of CPU, on the other hand, can be caused by the GC or something else. Even by another process (i.e. web server or db server) running on the same machine.

You should monitor your server with the tools provided by Amazon and make sure that you're not running low on resources.

About dropped packets:
You said it's about 1% ... so there's nothing to worry about. That's more than normal, unless you start dropping >15-20% or more.

I don't know if this is happening to my iPhone users. When a user disconnects, I'd like to print out which client the user is connected through (iphone or AS3). How can I do that? I can't find it in the docs.

We don't have that information available for all clients.
You should add it from your client at login time. When you send the credentials you can add custom data. Use it to store on the server side the client type

Posted: **22 Jul 2011, 01:22**

I had this same problem today... not sure what exactly happened but here is the info I do have...

I am running SmartFoxServer 2X (2.0.0-RC2a)
I am just running in a development environment, i think there was 2-3 users connected when the problem happened...

First I got this...........

Code: Select all

21 Jul 2011 18:29:14,146 INFO  [SocketReader] bitswarm.core.SocketAcceptor     - Session created: { Id: 131, Type: DEFAULT, Logged: No, IP: 192.168.1.1:57763 } on Server port: 9933 <---> 57763
21 Jul 2011 18:29:14,147 INFO  [com.smartfoxserver.v2.controllers.SystemController-2] v2.controllers.SystemController     - {IN}: Handshake
21 Jul 2011 18:29:14,197 WARN  [com.smartfoxserver.v2.controllers.SystemController-2] v2.controllers.SystemController     - 
java.lang.NullPointerException
	com.smartfoxserver.bitswarm.sessions.DefaultReconnectionManager.reconnectSession(DefaultReconnectionManager.java:153)
	com.smartfoxserver.bitswarm.sessions.DefaultSessionManager.reconnectSession(DefaultSessionManager.java:376)
	com.smartfoxserver.v2.controllers.system.Handshake.execute(Handshake.java:68)
	com.smartfoxserver.v2.controllers.SystemController.processRequest(SystemController.java:127)
	com.smartfoxserver.bitswarm.controllers.AbstractController.run(AbstractController.java:96)
	java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
	java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	java.lang.Thread.run(Unknown Source)

followed by:

Code: Select all

21 Jul 2011 18:29:33,367 WARN  [com.smartfoxserver.v2.controllers.ExtensionController-3] v2.controllers.ExtensionController     - 
com.smartfoxserver.v2.exceptions.SFSExtensionException: Extension Request refused. Sender is not a User: { Id: 131, Type: DEFAULT, Logged: No, IP: 192.168.1.1:57763 }
	com.smartfoxserver.v2.controllers.ExtensionController.processRequest(ExtensionController.java:65)
	com.smartfoxserver.bitswarm.controllers.AbstractController.run(AbstractController.java:96)
	java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
	java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	java.lang.Thread.run(Unknown Source)

21 Jul 2011 18:30:43,700 WARN  [com.smartfoxserver.v2.controllers.ExtensionController-3] v2.controllers.ExtensionController     - 
com.smartfoxserver.v2.exceptions.SFSExtensionException: Extension Request refused. Sender is not a User: { Id: 131, Type: DEFAULT, Logged: No, IP: 192.168.1.1:57763 }
	com.smartfoxserver.v2.controllers.ExtensionController.processRequest(ExtensionController.java:65)
	com.smartfoxserver.bitswarm.controllers.AbstractController.run(AbstractController.java:96)
	java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
	java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	java.lang.Thread.run(Unknown Source)

21 Jul 2011 18:31:54,105 WARN  [com.smartfoxserver.v2.controllers.ExtensionController-4] v2.controllers.ExtensionController     - 
com.smartfoxserver.v2.exceptions.SFSExtensionException: Extension Request refused. Sender is not a User: { Id: 131, Type: DEFAULT, Logged: No, IP: 192.168.1.1:57763 }
	com.smartfoxserver.v2.controllers.ExtensionController.processRequest(ExtensionController.java:65)
	com.smartfoxserver.bitswarm.controllers.AbstractController.run(AbstractController.java:96)
	java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
	java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	java.lang.Thread.run(Unknown Source)

21 Jul 2011 18:33:04,309 WARN  [com.smartfoxserver.v2.controllers.ExtensionController-1] v2.controllers.ExtensionController     - 
com.smartfoxserver.v2.exceptions.SFSExtensionException: Extension Request refused. Sender is not a User: { Id: 131, Type: DEFAULT, Logged: No, IP: 192.168.1.1:57763 }
	com.smartfoxserver.v2.controllers.ExtensionController.processRequest(ExtensionController.java:65)
	com.smartfoxserver.bitswarm.controllers.AbstractController.run(AbstractController.java:96)
	java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
	java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	java.lang.Thread.run(Unknown Source)

I got probably 20-30 of those ExtensionController messages...

I know I'm not running the latest version, but it sounds like the problem the others are having. Hopefully we can get this fixed.

Posted: **25 Jul 2011, 08:10**

As you can see there has been a loss of connection from one of the users, so, not being a User anymore he cannot send an extension request.

You must pay attention to the fact that, if you activate the reconnection system, you have to listen for events and make your GUI react to it.
Otherwise you will be able to operate (i.e. send requests) while the client is not connected, which will cause more problems.

As soon as you are notified of a reconnection attempt (see docs for the details) you should freeze the GUI and then unlock it as soon as the User is back in the server.

Posted: **04 Aug 2011, 17:31**

Lapo wrote:As you can see there has been a loss of connection from one of the users, so, not being a User anymore he cannot send an extension request.

You must pay attention to the fact that, if you activate the reconnection system, you have to listen for events and make your GUI react to it.
Otherwise you will be able to operate (i.e. send requests) while the client is not connected, which will cause more problems.

As soon as you are notified of a reconnection attempt (see docs for the details) you should freeze the GUI and then unlock it as soon as the User is back in the server.

but look at my first code block in the previous post, the user did re-connect.

Posted: **05 Aug 2011, 08:13**

I don't see that in the stack traces.
Please also upgrade to RC3

Posted: **19 Aug 2011, 09:29**

Lapo wrote:Assumptions at point 2 and 3 are not correct.

2) The AdminTool does not receive the same traffic that the other clients do so its not the same thing.

3) Of course... only a full blackout of the network would cause everyone to disconnect. Normally these kind of problems happen for a minority of the users, when bandwidth congestion occurs

we are also facing this problem, is this issue is fixed?