I am developing a chrome extension to which I was pushing notifications so far successfully from my server. However, the notifications suddenly stopped working. I can see that my POST to https://www.googleapis.com/gcm_for_chrome/v1/messages is answered with a 204 so its not my server code.
I am sure I have not hit the 10k per day limit because I would be seeing a completely different code otherwise.
I have a few questions:
Is there a rate limit that I may be hitting?
Is it possible that I have spammed the google server too much and am being blocked?
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
Problem
Sometimes important HTTP POST requests sent with AJAX got duplicated so several entries of the same data got created in the production database, that is of course not supposed by users.
What is important is that users have a poor internet connection and this request is taking a long time (9-20 seconds). We can't reduce this time because it is the requirements of business logic.
Requests are sent with http, not https.
Details
We have Apache/2.4.18 (Ubuntu) with PHP module loaded and two frontends: one for desktop (AngularJS) and one for mobile (React) devices. AngularJS is sending requests with the $http service, and React is using whatwg-fetch (tried whatwg-fetch-timeout also).
We know from Apache access.log and PHP logs that the same request is coming from the client several times and PHP processes them without the errors. But! These requests have response with 200 status code, %b > 0, and %O = 0, that means request is aborted before a response is sent (Apache logging format docs).
Reproduce
So we tried to reproduce and the same happens sometimes. The following case is just a reproduced case, but this happens on mobile devices (iPhones and Android phones) with different browsers installed. Also, we have repeated it in the Firefox under Windows.
Environment: Windows; both Chrome and Firefox; React frontend version; no proxy used.
That's what we found out: Google Chrome identifies the request as "Stalled", but is internally trying to send the request multiple times (and it is received and processed on the server actually), because it got the network error (ERR_CONNECTION_CLOSED). Only when the browser succeeded to fetch the response, it stops sending the repeating requests.
Gathered info
URL_REQUEST event log from chrome://net-internals/help.html#events (headers are also available there)
Google Chrome dev tools request screenshots:
Headers tab
Timeline tab
I personally can't reproduce this even once and I suppose a good internet connection is a reason for this.
I have googled a lot and even found some similar Chromium bugs, but nothing exactly about this problem.
Thank you in advance for any useful information.
I am also not pretty sure which tags should I set for this question, so if I should add or remove some, please tell me.
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!
I had successfully implemented push notifications for the developer certificate but cannot seem to get it work for an ad hoc test with a friend. I did the same process for creating the push notification keys/certificates except now I chose "Production Push SSL Certificate" instead of "Development Push SSL Certificate". I believe that this is correct since I could not find any tutorials around that showed how to do it for production... all of them were for development.
This quick process can be found from ray wenderlich blog here: http://www.raywenderlich.com/3443/apple-push-notification-services-tutorial-part-12
This is my guess where things might have gone wrong because maybe there is a different way to do Production Push. I left my php code the same on my server as I had it before for Development Push (copied over the new ck.pem). Is this alright or do I need to make changes? I can post the code if someone thinks it is the code but as I said.. the php server code worked before.
Can someone please help me out? Thanks in advance!
I CANNOT ANSWER MY QUESTION BECAUSE I DO NOT HAVE ENOUGH REP. THE CORRECT ANSWER IS HERE
for my development I had:
gateway.push.apple.com:2195
but for production it needs to be:
gateway.apple.com:2195
Hope this helps someone in the future.
[Edited]
You can also try to check your token are correctly set, your devices are allowed to receive notifications.
If you have made many tests, you may also have been temporarily banned from APNS server, you mustn't make too many calls to the APNS server in a small time range.
Please also note that there may be some delays from the time you send the notification to the APNS server, and the time the APNS server sends it to your device.
LAst bu not least, make sure your devices have a correct Internet / SSL free access some proxies or firewalls may block notifications
Are you getting the devices token dynamically? Because when the app is in ad-hoc distribution it is generating a different device token for push notifications form when it is in debug (a.k.a developer) mode