Hi recently after some update users can not connect to server (sfs.connect failed) after 5-10 users connect, login and play around 15-45 minutes. After sometimes pass users can connect again.
What we can think are:
1. Sfs refused user connection when the server is in high load
2. Some process (bugs) in room/zone ext cause the sfs not detectable by the client. Is this possible?
Possible no.1, we have checked in dashboard+ task manager no high load at all, both cpu+mem all below 30%
Possible no.2, we using Timeunit.miilisecond.sleep in room extension is this the culprit causing others clients failed when trying to connect, error in client said "can not find wss://...
What make us really confused are this issue did not occur in staging environment.
Can not find the server wss://
Re: Can not find the server wss://
Hi,
I've already replied to your private message. There's no need to double post.
For the sake of other people reading:
Yes, this is definitely a bad idea. You should never block a thread with a call to Thread.sleep. If you need to delay the execution of some action you just need to use the Task Scheduler:
https://smartfoxserver.com/blog/how-to- ... extension/
Blocking threads on the other hand is a recipe for performance issues.
Cheers
I've already replied to your private message. There's no need to double post.
For the sake of other people reading:
Possible no.2, we using Timeunit.miilisecond.sleep in room extension is this the culprit causing others clients failed when trying to connect, error in client said "can not find wss://...
Yes, this is definitely a bad idea. You should never block a thread with a call to Thread.sleep. If you need to delay the execution of some action you just need to use the Task Scheduler:
https://smartfoxserver.com/blog/how-to- ... extension/
Blocking threads on the other hand is a recipe for performance issues.
Cheers
Re: Can not find the server wss://
thank for the replay.
we will change the sleep into schedule.
Any example to set log http traifc more detail not just 400, if we understand correctly the flow are:
1. Client send sfs connect --> BlueBox webServer (F12 check browser console)
2. BlueBoxWebServer --> Smartfoxserver zone extension.Login (logged in localhost_access log file)
3. Smartfoxserver zone extension.Login --> Custom login (logged in smartfox log file)
we found the issue in no.2 the data never send or take very long +/-30 sec to flow into no.3, when >30 sec the client got the error "can not find wss://..
edit: btw the connect & login in zone extension while sleep cmd in room extension, aren't they in different process/thread so if room sleep blocking the thread shouldn't it have no effect with the Zone process like user connect+login ?
we will change the sleep into schedule.
Any example to set log http traifc more detail not just 400, if we understand correctly the flow are:
1. Client send sfs connect --> BlueBox webServer (F12 check browser console)
2. BlueBoxWebServer --> Smartfoxserver zone extension.Login (logged in localhost_access log file)
3. Smartfoxserver zone extension.Login --> Custom login (logged in smartfox log file)
we found the issue in no.2 the data never send or take very long +/-30 sec to flow into no.3, when >30 sec the client got the error "can not find wss://..
edit: btw the connect & login in zone extension while sleep cmd in room extension, aren't they in different process/thread so if room sleep blocking the thread shouldn't it have no effect with the Zone process like user connect+login ?
Re: Can not find the server wss://
I would recommend to first fix the Thread.sleep() issue by removing all instances of this call.
Once this is done see how it runs and if there are still issues let us know.
Both Zone and Room Extension requests are executed by the same Thread Pool. Room Extension requests that call Thread.sleep will hold on those threads not allowing them to return in the Thread Pool. This in turn can exhaust the Thread Pool if the sleep takes too long and there are many concurrent sleeping threads.
There's a bit of confusion here.
The webserver (Tomcat) provides several services:
1- BlueBox connections, for clients failing to use regular sockets. If the client can't use sockets the connection will switch to a HTTP tunnel
2- Websocket. Which is entirely different from the above. This is a persistent connection, not an HTTP tunnel.
When using Websocket connections the BlueBox is never used. This is because Websocket is already part of the HTTP protocol and as such, if the client fails to connect, there is no backup solution.
In other words the BlueBox (http tunnel) is a backup solution only for standard TCP socket connections. It does not apply to Websocket connections.
Cheers
Once this is done see how it runs and if there are still issues let us know.
edit: btw the connect & login in zone extension while sleep cmd in room extension, aren't they in different process/thread so if room sleep blocking the thread shouldn't it have no effect with the Zone process like user connect+login ?
Both Zone and Room Extension requests are executed by the same Thread Pool. Room Extension requests that call Thread.sleep will hold on those threads not allowing them to return in the Thread Pool. This in turn can exhaust the Thread Pool if the sleep takes too long and there are many concurrent sleeping threads.
1. Client send sfs connect --> BlueBox webServer (F12 check browser console)
2. BlueBoxWebServer --> Smartfoxserver zone extension.Login (logged in localhost_access log file)
3. Smartfoxserver zone extension.Login --> Custom login (logged in smartfox log file)
There's a bit of confusion here.
The webserver (Tomcat) provides several services:
1- BlueBox connections, for clients failing to use regular sockets. If the client can't use sockets the connection will switch to a HTTP tunnel
2- Websocket. Which is entirely different from the above. This is a persistent connection, not an HTTP tunnel.
When using Websocket connections the BlueBox is never used. This is because Websocket is already part of the HTTP protocol and as such, if the client fails to connect, there is no backup solution.
In other words the BlueBox (http tunnel) is a backup solution only for standard TCP socket connections. It does not apply to Websocket connections.
Cheers
Re: Can not find the server wss://
thank for your replay Lapo.
After discus with the whole team we decide to downgrade to 2.14 and the issue gone, we're still wait for further result. The server is behind firewall so we use bluebox, there must me some configurations are miss/need to be update in latter version that we miss.
after made some changes about sleep and do more testing with 2.18 (latest patch) we will upgrade again.
Many Thanks
After discus with the whole team we decide to downgrade to 2.14 and the issue gone, we're still wait for further result. The server is behind firewall so we use bluebox, there must me some configurations are miss/need to be update in latter version that we miss.
after made some changes about sleep and do more testing with 2.18 (latest patch) we will upgrade again.
Many Thanks
Re: Can not find the server wss://
The server is behind firewall so we use bluebox,
You said in the title that you're using wss://, so Websocket. If that is the case, then the BlueBox is never used.
Please check what I wrote in my earlier post ... BlueBox is the backup connection option, only for TCP socket clients.
Sorry to be pedantic, but if we use the wrong terminology we'll have a harder time understanding each other
If you're using Websocket over SSL (wss) then the server-side firewall must be open for port 8443, and clients will use that port to connect. (Unless, of course, you have customized the port number. But I assume you're using the default)
Cheers
Who is online
Users browsing this forum: No registered users and 96 guests