Hi folks, this message is filling up my logs on my production server and I am having a tough time figuring out why.
Class: bluebox.v3.BlueBox
Message: Invalid request, session expired. Message: { ssid: eadeccab136309a4d4e8ba9a5d2dfba2, cmd: data, data: 56 bytes�}
(Screenshot admin log attached)
I am running 2.9.2 on a Amazon EC2 Linux Instance.
Clients connected are Web AS3 Flash clients
I have anywhere from 1-2k CCU and no other error messages or warnings.
It's not that it's breaking our server, but it's certainly spooling out very large log files.
Your help is appreciated!
LOG: bluebox.v3.BlueBox: Invalid request, session expired.
-
- Posts: 3
- Joined: 08 Oct 2014, 20:33
LOG: bluebox.v3.BlueBox: Invalid request, session expired.
- Attachments
-
- logFile.jpg
- Log Screenshot
- (232.57 KiB) Not downloaded yet
Re: LOG: bluebox.v3.BlueBox: Invalid request, session expire
Hi,
the message usually indicates that a client is either no longer connected or its session is not recognized.
From what I can see in the screenshot the requests are all sent by the same client (same session id) and they are sent at a very high rate (some arrived in the same millisecond).
Does your application send very fast messages? Is it like a real time game?
If not this would raise a red flag, as it may look as a hacking attempt.
Let us know.
Cheers
the message usually indicates that a client is either no longer connected or its session is not recognized.
From what I can see in the screenshot the requests are all sent by the same client (same session id) and they are sent at a very high rate (some arrived in the same millisecond).
Does your application send very fast messages? Is it like a real time game?
If not this would raise a red flag, as it may look as a hacking attempt.
Let us know.
Cheers
-
- Posts: 3
- Joined: 08 Oct 2014, 20:33
Re: LOG: bluebox.v3.BlueBox: Invalid request, session expire
Hi Lapo, thank you for getting back so fast.
Yes the server sends messages at a high rate at 10 per second to each client connected in a game room. I am also receiving messages at 10 per second from clients to the server. I mused our code off of the space race example, so it's a similar structure.
So yes, it appears that connected clients are creating these warnings at a high rate.
Another clue is that this has shown itself to happen even when the server is empty while I was running the 2.9.0 version. It would happen every couple seconds after a fresh restart. After patching to 2.9.2 I can't be certain this is still happening - but due to the 2.9.2 bluebox fixes mentioned, i figured updating would solve the issue - at least partially.
The first time I started noticing this happening was in mid development after updating my remote extension during development, while on 2.9.0. But the problem seem to persist into 2.9.2.
Could it be something code based?
Thanks for your input.
EDIT: Updated information about versions.
Yes the server sends messages at a high rate at 10 per second to each client connected in a game room. I am also receiving messages at 10 per second from clients to the server. I mused our code off of the space race example, so it's a similar structure.
So yes, it appears that connected clients are creating these warnings at a high rate.
Another clue is that this has shown itself to happen even when the server is empty while I was running the 2.9.0 version. It would happen every couple seconds after a fresh restart. After patching to 2.9.2 I can't be certain this is still happening - but due to the 2.9.2 bluebox fixes mentioned, i figured updating would solve the issue - at least partially.
The first time I started noticing this happening was in mid development after updating my remote extension during development, while on 2.9.0. But the problem seem to persist into 2.9.2.
Could it be something code based?
Thanks for your input.
EDIT: Updated information about versions.
-
- Posts: 3
- Joined: 08 Oct 2014, 20:33
Re: LOG: bluebox.v3.BlueBox: Invalid request, session expire
Lapo - Attached is a log 5 minutes after opening the gates into the server (ERROR mode only). I was watching the logs and it seems that it leads more evidence to your suggestion. It appears a user would generate a string of these, then get disconnected. Then another user, and another. This was generated after the server populated up to about 1200 or so CCU.
- Attachments
-
- SFS2X_RuntimeLog_backup_20150228_210735.zip
- (20 KiB) Downloaded 268 times
Re: LOG: bluebox.v3.BlueBox: Invalid request, session expire
Of those 1200 CCU how many are connected via BlueBox? You can check this in the AdminTool's Dashboard, bottom right corner, there's a table with all the connection stats.
It tells you how many clients are connected via socket, how many via HTTP.
I would expect the vast majority of those 1200 CCU to be connected via socket. (at least 90% socket)
The rate of the messages in your log file is pretty high, almost 8-9 msg/second. It correlates with the message rate you're using in your application. At that rate a portion of the HTTP-based clients will certainly fail to keep up, because HTTP is much slower.
Leaving aside the hacking hypothesis there could be two other options:
1) The client is not handling the disconnection event properly and keeps sending requests after having been disconnected.
2) There is a temporary "grey-area" between the server side and client side disconnection in which the client still doesn't know about the lost connection and keeps sending data. Given the high rate of messages and the slowness of HTTP this is a possibility.
hope it helps
It tells you how many clients are connected via socket, how many via HTTP.
I would expect the vast majority of those 1200 CCU to be connected via socket. (at least 90% socket)
The rate of the messages in your log file is pretty high, almost 8-9 msg/second. It correlates with the message rate you're using in your application. At that rate a portion of the HTTP-based clients will certainly fail to keep up, because HTTP is much slower.
Leaving aside the hacking hypothesis there could be two other options:
1) The client is not handling the disconnection event properly and keeps sending requests after having been disconnected.
2) There is a temporary "grey-area" between the server side and client side disconnection in which the client still doesn't know about the lost connection and keeps sending data. Given the high rate of messages and the slowness of HTTP this is a possibility.
hope it helps
Who is online
Users browsing this forum: No registered users and 64 guests