I developed a blazor server app which works fine on a desktop, and now i test her on the mobile platforms.
I met problem with the signalR connection when i put the browser in the background.
When i go back, if its enough fast, i have the message
"Attempting to reconnect to the server" x/8, and after it reconnect after maybe 15 seconds (which is too much), and if its like 5 minutes later im totally disconnected and i have to relaunch the app.
i found some documentation about that but nothing consistent. Because of blazor, the client configuration and event (in js) seem different than the classic signalr client, and for the server im beeing lost between the different timeout.
I try find a way to configure both server and client to manage a "sleeping" connection (ok if im disconnect after 20 minutes but i want at least be able to reconnect until 20 minutes of inactivity), but its really hard to test because im unable tu reproduce this behavior in development in my laptop.
I see some solution on internet who suggested make document.location.reload()
Blazor.defaultReconnectionHandler._reconnectCallback = function(d) {
document.location.reload();
}
But its not a solution for me as i don't want to lost everything in session.
thanks for your suggestion and help !
for those stuck into this same kind of problems, i was able to manage this by play with the signalr options described here : https://learn.microsoft.com/en-us/aspnet/core/blazor/fundamentals/signalr?view=aspnetcore-5.0&pivots=server
actually it was not really a mobile problems because i had the same kind of behavior by putting a laptop on sleep more than 3 minutes.
The 3 minutes expiration period was coming from this parameter
DisconnectedCircuitRetentionPeriod 3 minutes Maximum amount of time a disconnected circuit is held in memory before being torn down.
i just increase the time of this parameter and when the mobile/laptop go out of sleep it able to reconnect.
the blazor documentation is not really clear about that
Related
We're facing an issue with handling unexpected behaviours when performing xmlHttpRequests on Android devices using React-Native. We've experienced behaviour where the app becomes unavailable to complete API calls, even though the device is connected to the internet perfectly well (browser can access non-cached sites just fine). The only way to resolve this issue for our users has been to completely restart the app.
To understand the issue and its severity, we wrapped all our API calls to a timer function in production and sent reports to Sentry whenever a request took longer than 30 seconds to finish. Now we've been receiving these kind of reports in the hundreds per day with the duration sometimes being in the hours or even days.
First, instead of using whatwg-fetch, we moved to using axios so that we can manually set the timeout of each request, but this ended up not helping at all.
Second, we dove deeper into understanding how React-Native actually implements timing out XHR requests on Android, and found that it uses OkHttp3 under the hood. OkHttp has a default value for connect, read and write timeouts and react-native allows developers to change the value of connect timeout here. However, OkHttp also has a method for setting a call timeout (everything from connect to reading the response body), but this has a default value of 0 (no timeout) and React-Native doesn't allow users to change that. More on okhttp timeouts here
My question is whether this can be the cause of our worries and whether it should be reported to React-Native as a bug. Lets assume the following case:
app makes an API call to a resource
okhttp is able to connect to the resource within specified timeout limit (default 10s)
okhttp is able to write the request body to the server within timeout limit (10s)
server processes request but for some reason it fails to start sending a response to the client. I guess there could be many reasons for this like server being disconnected, server crashing or server simply losing the connection to the client without the client noticing it. As there is no timeout here, okhttp will happily wait for days on end for the server to start responding to the request.
Am I missing something here or misunderstanding how timeouts work in okhttp? Is there another, perhaps better solution than implementing the ability for developers to set callTimeout on API calls performed on android? And also, isn't it a bit stupid that developers cant set their own write and read timeouts? Cant this lead to unexpected behaviour when you want to send large amounts of data in either direction on a slow connection? 10s is quite long, but perhaps not long enough for all use-cases.
Thanks for your help in advance!
Since updating the system to version 10.0, my service has been experiencing connection issues while playing a track. I have not done any changes recently server side (however I don't want to rule out that I'm doing something wrong).
Here's what happens:
Hit Play
Track starts playing
After about 1 min to 1.30 min, I get the message in the controller: "Unable to play [track name] - the connection to [service] was lost.
After another few seconds the service skips to the next songs.
A few things to note:
I have received complaints about this issue from a few customers, only after the latest update, so I don't believe these are intermittent WiFi issues.
I have tested with serving the streaming files locally from my laptop and it works fine.
Based on all of this, I believe there is an issue in the connection between the Sonos player and the streaming server (or CDN). I'm out of ideas though, on what I should be looking for. Requests, headers etc. look fine to me.
Is there any other way to troubleshoot or see what is actually happening when the Sonos player "looses connection to the service"?
Thanks much
Condition:
1. Two users use Chrome (latest version) on Mac
2. One-to-one video conference
Problem - sometimes (~ ones in 5-6 calls) video window shows the error - The video stream failed to connect. Please notify the site owner. It can be on the beggining, or after several minutes spent on call.
Where can be the issue?
If any addition info needed i will provide in the post.
Thanks
If I understand correctly, one in 5-6 calls results in "Video stream failed to connect error". This is most likely a firewall or router configuration issue.
If you are video chatting with different people and you are sometimes getting a "video stream failed to connect error", the person you are chatting with probably has a firewall or configuration issue.
If you are testing with yourself and sometimes getting that error, you might have firewall or configuration issues.
To verify that you firewall is configured correctly, try running this diagnostic tool.
If you would like to see when your users are experiencing this error and would like to educate them on the diagnostic tool or what the possible causes are, you can listen to exception events (#1013 in your case)
Disclaimer: I work at TokBox.
Good Luck!
Whew...ok, been wrestling with this for a while and I can't figure out what is going on.
I am new to Azure caching, but at this point I have read a good bit and I think I have it setup right, but something is obviously wrong so what do I know?
Ok, so first I setup a dedicated caching web worker role using this fine tutorial: http://berniecook.wordpress.com/2013/01/27/distributed-caching-in-azure-cache-worker-role/
I have an ASP.net MVC 4 website that is supposed to be using it.
I have my solution set to multiple starting projects with my cloud caching project set to start first, but no matter what I do, I get the "role discovery data is unavailable".
Sometimes in my output log I get that the Role Environment failed to initialize, but not very often. Most of the time the output log says that is succeeds. Regardless of that, I still get the error above.
I was thinking that maybe the issue was because I was running on local azure storage and compute emulators, so I reconfigured and published the Cloud Service to Azure to see if that helped.
It didn't...
The fun part is that there have been exactly 2 times when it suddenly worked (both when I was working locally). 2 times about of about 100. I didn't do anything different...just ran the debugger and poof, it all worked. This at least lends a bit of credit that it is actually setup correctly.
Needless to say, this is putting a huge damper on my productivity so any advice would be appreciated.
Update
Ok, I have figured out a workaround of sorts...I have learned that the reason that it consistently failed was because the development web server was holding onto a file which prevented the caching server to launch correctly.
The workaround is to stop the web server each and every time I want to recompile and run the code. This is obviously not ideal, so any ways to make this more reliable would be appreciated.
Thanks,
David
I don't know if this helps but I find that if I don't shut down the both the storage and compute emulator, I get weird errors, so after doing an F5 and closing the browser down, I manually shut down both emulators
This is been making my programming really frustrating lately.
I´m in Argentina right now connecting to a U.S. server via SSH. Understandably, the pings are a bit higher here (around 200ms on average) so when I SSH into the server there is a slightly noticeable lag between each keystroke. This is fine and easy enough to work with.
What isn´t easy to work with is that about every 5 minutes or so, SSH will completely hang and take about 3-5 minutes to return back a prompt. I know the server is not bogged down because I can easily open several new connections while I´m waiting for one to return (in fact this is the only way I´ve been able to work). And when SSH finally comes back I can see it has actually been working away in the background (large file downloads was a good way to test this) but it just hasn´t been updating my screen.
Does anyone have an idea what might be causing this?
Few other facts: the server is Ubuntu and I'm connecting with Mac OS X. I have keepalive turned on in the SSH settings. It is most likely to hang when I hold down a key (for example a left or right arrow to scroll) which sends a lot of keys quickly. In fact I can reliably reproduce the hang by logging in and holding down any key like "a" - it never makes it past a full line of "a"'s before hanging. This just started when I connected internationally for the first time so I´m assuming it has something to do with that (latency?) but can´t say for sure.
Odd. I can't help you with your problem but I have a tip to make it less annoying: Use screen(1). This will keep your shell on the other end alive and you can continue whatever you were doing after reconnecting.
If you only need to run a command on the other side, I suggest to pass the command as an option to ssh (it will connect, run the command, display the result and disconnect).
I think it was some problem with the ISP down here in argentina. When I switched to another wireless network with another ISP it started working. They are probably playing some port throttling games or who knows what.
Try adjusting your TCP window size.
I'm used to ssh over high latency links - 600ms. It is slow but I rarely had any problems. To start with - open another terminal window, ping your server and watch the connection. Tell us what you see.
Try sshing in with a few verbose flags (ssh -vv[vv] somehost) and seeing if there's anything indicative printed around the time it hangs.
Well, I am now connected to a different wireless network and the problem seems to have disappeared. I can't say for sure what exactly was causing it (and I don't have login access to the wireless router) but this seems to suggest it was something on the router, and not the server or client computer.
Both the old router and the new router were Linksys WRT54G's so I'm not sure what the problem was. Hope it helps someone!
I was having a similar problem with 'cat' and even 'ls -l' causing ssh to hang (on Ubuntu). Adjusting MTU size to 1400 fixed it for me.