Running a react app in dev mode on localhost:3000 is stalled out with the initial loading network calls not responding.
To my knowledge, I didn't change anything between when the app was working and now. I've tried resetting to a previous git commit during which I know the project was working but the behavior is the same.
I've tried building the project and navigating to the built project
I don't even know where to look to troubleshoot this problem.
First of all, as Icepickle pointed out, this is fine. It's less than 1/500 of a second... it's nothing. :)
If you are still curious, you can have a look at these terms their explanations from the Google Network Analysis Reference. Here is some related info:
Queueing. The browser queues requests when:
There are higher priority requests.
There are already six TCP connections open for this origin, which is the limit. Applies to HTTP/1.0 and HTTP/1.1 only.
The browser is briefly allocating space in the disk cache
Stalled. The request could be stalled for any of the reasons described in Queueing.
Related
Facing the below issue continuously with one POST request which is triggered from Google Cloud Task. The node application is deployed on Google App Engine. tried even increasing the instances but no luck.
Process terminated because the request deadline was exceeded. Please ensure that your HTTP server is listening for requests on 0.0.0.0 and on the port defined by the PORT environment variable. (Error code 123)
Any help would be useful. Thanks in advance
I have run into this issue in the past. The question, as posted, doesn't have enough information to narrow down the issue, but here are a few things you can try:
Increase memory size: It's possible that your instances are running out of memory and failing to start. Try increasing memory size of the instance to see if that helps.
Billing: Make sure all of your billing information is up to date and the issue isn't related to cost.
Warmups: Do you have a warmup, liveness check, or readiness check turned on? If so, make sure they are working properly.
Add Logging: The request has no logs displayed. You should try adding logging.info(...) statements in your code to see how far it gets before failing.
The OPTION/POST Request is failing inconsistently with a console Error as err_timed_out. We get the issue inconsistently, it's only observed sometimes. Otherwise the request gets proper response from the back end. When it's timing out, the request doesn't even reach the server.
I have done some research on the stuff and found that due to maximum 6 connections to a resource restrictions it may wait for getting a connection released. But, I don't see any other requests pending ,all the other requests were completed.
In the timeline I can always see that it stalled for 20.00 seconds. Most of the time the time is same. But, it only shows that its been stalled for some time nothing else in the timeline.
The status of the request shows failed ERR_Connection_Timed_Out. Please help.
The Network Timing
Console Error
I've seen this issue when I use an authenticated proxy server and usually a refresh of the page fixes it.
Are you using an authenticated proxy server where you are seeing this behavior? Have you tried on a pc with direct access (i.e. without proxy) to the Internet?
I've got the same problem when I choose another ISP. I thought I would have only to put my new ID and password, but it wasn't the case.
I have an ADSL modem with a dry loop.
All others services were fine (DNS resolution, IP telephony, FTP, etc).
I did a lot of tests (disable firewall, try some others navigator, try under Linux, modem default factory, etc) none of those tests were successful.
To resolve the problem ERR_TIMED_OUT, I had to adjust the MTU and MRU values. I put 1458 rather than 1492, which is the default value.
It works for me. Maybe some ISPs use different values. Good luck.
I have a fairly big application which went over a major overhaul.
The newer version uses lot of JSONP calls and I notice 500 server errors. Nothing is logged in the logs section to determine the error cause. It happens on JS, png and even jersey (servlets) too.
Searching SO and groups suggested that these errors are common during deployment. But it happens even after hours after deployment.
BTW, the application has become slightly bigger and it even causes deadline exception while starting few instances in few rare cases. Sometimes, it starts & serves within 6-10secs. Sometimes it goes to more than 75secs thereby causing a timeout for the similar request. I see the same behavior for warmup requests too. Nothing custom is loaded during app warmup.
I feel like you should be seeing the errors in your logs. Are you exceeding quotas or having deadline errors? Perhaps you have an error in your error handler like your file cannot be found, or the path to the error handler overlaps with another static file route?
To troubleshoot, I would implement custom error pages so you could determine the actual error code. I'm assuming Python since you never specified what language you are using. Add the following to your app.yaml and create static html pages that will give the recipient some idea of what's going on and then report back with your findings:
error_handlers:
- file: default_error.html
- error_code: over_quota
file: over_quota.html
- error_code: dos_api_denial
file: dos_api_denial.html
- error_code: timeout
file: timeout.html
If you already have custom error handlers, can you provide some of your app.yaml so we can help you?
Some 500s are not logged in your application logs. They are failures at the front-end of GAE. If, for some reason, you have a spike in requests and new instances of your application cannot be started fast enough to serve those requests, your client may see 500s even though those 500s do not appear in your application's logs. GAE team is working to provide visibility into those front-end logs.
I just saw this myself... I was researching some logs of visitors who only loaded half of the graphics files on a page. I tried clicking on the same link on a blog that they did to get to our site. In my case, I saw a 500 error in the chrome browser developer console for a js file. Yet when I looked at the GAE logs it said it served the file correctly with a 200 status. That js file loads other images which were not. In my case, it was an https request.
It is really important for us to know our customer experience (obviously). I wanted to let you know that this problem is still occurring. Just having it show up in the logs would be great, even attach a warm-up error to it or something so we know it is an unavoidable artefact of a complex server system (totally understandable). I just need to know if I should be adding instances or something else. This error did not wait for 60 seconds, maybe 5 to 10 seconds. It is like the round trip for SSL handshaking failed in the middle but the logs showed it as success.
So can I increase any timeout for the handshake or is that done on the browser side?
I've recently started having coldstarts on nearly every call to my appengine app. Initially I thought this was an issue with Cloud Endpoints, however now I believe it is an appengine issue, or something else in my code.
This started on my most recent deployment. I'm at a loss right now as to what is going on. It has made my app useless. I have tried 1.7.4 and 1.7.5 and both have this problem.
The requests work other than being extremely slow! Any help would be greatly appreciated, as I can not continue with 10-15 request times!
Update: By looking at my running instances I see NO instances running even after making a request. Previously instances would remain running after requests were made. It appears when a request is made an instance is spun up, serves the request, and then dies. There are no errors in my logs. No changes have been made to my app settings or billing. This app does have billing enabled.
Update 2: I have adjusted my idle instance settings(which up to this point have worked and have been left untouched). I set to a min of 1 and max of 2. The instances are staying alive and serving requests as normal. Previously it was set to automatic-1. Not sure what is going on here, perhaps Google adjusting the request scheduler or something. Not COOL!
I have found an open issue on code.google.com. Apparently this is a real appengine issue that is effecting some, if not all apps at the moment. I do not have a solution at this time other than setting the idle minimum instances to 1 (or greater). Even doing this, the new dynamic instances that are spun up die almost immediately after serving a request. Just waiting on a fix from google at this point.
http://code.google.com/p/googleappengine/issues/detail?id=8844
I've got a Silverlight application that makes a cross-domain request. The clientaccesspolicy.xml file exists on the server I am making a request to and is correctly configured.
I know that it is correctly configured because when I use the application to make a request from my machine I receive a response with no problem.
When a second individual on a corporate network about 300 miles away tries to use the same application, launched from the same URL, to make the same request, he instead gets a security exception.
Here's the odd part. I requested that he download Fiddler so that I could see the request and it's response, and thereby gain some insight into the problem, but when he runs the app with Fiddler open, the request succeeds.
This happens in both Chrome and IE. With Fiddler everything is fine. Without it, it doesn't work.
We've tried clearing his history, deleting the Silverlight app from the cache, everything I can think of.
The request is being made to a private network (which he is on), I make the request through a VPN connection to that network (in case for some reason that matters).
Any thoughts as to what's causing this bizarre problem?
Despite the fact the Fiddler "fixes" the issue it would still be worth while getting this second individual to save a .saz file from fiddler for the successfull set of sessions and then for you to compare them with a successfull set you have from your own machine.
An analysis of the differences may reveal a potential cause when fiddler is not in place.
Another approach would be to use a network protocol anaylser such as Wireshark. The elimination of the proxy that Fiddler represents may be enough to expose the problem, of course such tool is much more technical.
This post is simply to catalog the solution for future users. Thanks to everyone who helped.
The actual problem turned out to be (just as EricLaw -MSFT- suggested) that the client's machine was zoning the request URL as Intranet and the Silverlight application as Internet, and I am not permitted to make requests across zones.
EricLaw's direct responses may be viewed in the comments under the original question.
The URL below (provided by Eric) contains information regarding the denial of cross-zone request, as well as solutions.
msdn.microsoft.com/en-us/library/bb250483(VS.85).aspx