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.
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.
I've got a SpringMVC application that is randomly not returning a response to AJAX requests. Or rather, it would appear that it is not returning the response.
In my Network graph (Chrome or Firefox), I see a GET request being made, and I see the full stack trace on the server side which is handling/responding to the request. However, the browser never seems to receive a response to the request as the GET method never completes.
I am completely clueless as to how/where to start tracking this down.
I am running on Tomcat 7.0.42 and using AngularJS on the front side. I have my firewall completely stopped, so I do not believe that it is related to blocked ports/communications.
Where/how can I validate that a response is being committed? Furthermore, how can I isolate where this disconnection is occurring and why the browser isn't receiving any response? I cannot seem to replicate this behaviour when I issue manual requests via Postman.
I am doing the dev work on OSX v10.7.5.
Wow. After several hours of trying to dig around and find the solution, I installed Wireshark and decided to look at actual packets. Turns out I was getting double requests for a single get, but to 2 different ports. After further inspection (checking to see what was listening on the port), I noticed that it was the Sophos Anti-Virus that was seemingly intercepting the request and not responding.
I'm still not sure quite how the AV intercepts the requests before passing them along, nor how it decides to abort a response, but turning off has made a world of difference.
Hopefully this learning experience will help someone else if they get stuck with something similar.
SpringMVC is pretty rock solid and the only thing I can imagine is that your handler is not returning a response under certain instances. Look in your code for conditionals or exception handlers that don't return a proper response.
My Google App Engine app, which uses the Channel API works well some of the time. Intermittently, though, the js code connecting to the channel generates an error. In socket.onError, the error code is set to 400 and the description is set to an empty string. I have checked that the token being used to connect is valid. I also tried recreating the channel in socket.onError, by first calling socket.close() but that does not seem to work. Often there is a series of failures before a success. The client js is running on Safari on iOS. Any ideas on how to fix or work around the problem will be welcome. Right now, my best workaround is to keep trying till I succeed, increasing the interval between attempts on each failure. The server side presence API does not help, since the 'connected' hook is not called reliably.
It is known issue http://code.google.com/p/googleappengine/issues/detail?id=4940 and it was accepted. As you see the status of issue is not fixed. Feel free to star it.
I know double posting is bad (issue starred & comment posted)... but I suspect this thread might get more attention than the issue comments ^^
As far as we are concerned, it's at the very least a documentation issue:
https://developers.google.com/appengine/docs/java/channel/javascript still
states " An onerror call is always followed by an onclose call and the channel object will have to be recreated after this event"
It is only true for, as far as we have guessed, error codes 400 and 401 (which are strings, not numbers, btw, so beware of === in the js code).
It is untrue for other error codes (we have logged at least the -1 code).
There should be a documentation covering all error codes and their (expected) management.
Atm, we have a "channel manager" that reuses the same channel token when code is not 400 or 401, and that makes sure onclose is called once and once only per Socket.
Before that, we were trying to close properly, and reopen (new underlying Socket) with a shiny brand new token: usually we got an error 400 followed by an error -1.
FUI we first detected this behavior on iOS, quite recently (regression ftw? Before that iOS was dandy). Reopening the socket after a code -1 is not a panacea: sometimes it will succeed (onopen properly called), and then fail silently (no message received, no onerror called).
Generally, we also noticed more consistent behavior on desktop browsers than mobile ones, across all user agents and platforms (more on that: yay! Other issues incoming! Especially android...)
OK, this post might have been useful after all. Thx!
[EDIT: corrected a mistake... we don't reuse the channel object nor the socket object, only the token]
I contacted Google support about this issue.
When a error 400 happens it's because a timeout (one minute it seems) happened. This timeout generates a disconnection (url disconnected is called and you should remove the client id of the database).
Then, a new channel must be created with a new client id.
But it is not enough. We have to use this jquery command line : $('#wcs-iframe').remove();
Just inside the js onerror function and before to try to recreate the channel.
I was modifying a WCF service to increase the timeout for a Silverlight client. Before modifying the timeouts I'm seeing CommunicationObjectAborted exception (The HTTP request to [URL] was aborted). At first I only modified the web.coffig of the WCF and it had no effect. I then followed this post (http://blog.ecofic.com/?p=379) and edited ServiceReferences.ClientConfig as well. Now I'm seeing a No endpoint exception. The exception was not thrown immediately after the client connects to WCF, but after about 1 minute after it connected to WCF. I suspect it has something to do with the timeouts?
I set open, close, send and receive timeouts to 5 minutes in both config files.
Any idea? Thanks!
As Richard pointed out, sendTimeout only be needed to set on the client (your Windows Phone app in this case). Double check the ServiceReferences.clientConfig as manually added value might get overwritten by Visual Studio.
Also you can check this post for using Fiddler on Windows Phone (emulator).
You should use Fiddler to analyse the requests performed by your application. This way, you will be able to know what happen when the request is sent, where exactly it is sent (if it is sent), and the response code from the server.
Obtaining these informations is the first step on the way to troubleshoot your issue.
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