In the app I work on, we have an "export from highrise" feature that produces a .csv file.
Sometimes (depending on the things we need exported) the request takes a long time (7-10 minutes). Everything work fine (as far as I can tell) server side but my client's browser (he tried safari, chrome and firefox) doesn't get a response. Aka the browser just stays there with the loading animation indefinitely (well we gave up after 45 minutes).
On my machine everything works fine on all browsers. Based on the logs I have/put in place, everything goes as plan, the task ends the output is sent, but he gets no response.
Any idea is welcome, I have no idea where to look next.
EDIT: I did what #ceejayoz suggested but the problem persists, the browser doesn't receive a response, it just sits there waiting even though the file is generated correctly.
I'd have the export generate server-side, and have the user-facing page refresh or check via AJAX every 15-30 seconds to see if the export is complete. Once completed, redirect them to the file.
Related
I am implementing single page application(SPA) using of Angular Js, MongoDb. And I am using rest call with promises. Rest call working fine in Chrome, Mozila browser which is using for development. But rest call is not working in IE-11. It is giving me 500 Internal Server Error.
I am not able to find out line of rest call. Because it is not showing line number. But I can share sample code of rest call.
Rh.all('apicall').get('dbname/_aggrs/'+ ar_dep +'?avars=' + query).then(function (d) {
console.log("response data");
});
Above call is not printing console. Because It is breaking in IE-11, But these rest call working fine in other browser.
If I putt direct path not with variable then it is working in IE-11.
Working Rest Call below
Rh.all('apicall').get('dbname').then(function (d) {
console.log("response data");
});
NETWORK in Console(IE-11)
IN CHROME
I am updating my question. Because I found some difference parsing url, Because of restheart.
IN CHROME:
Rh.all('apicall').get('dbname/_aggrs/'+ ar_dep +'?avars=' + query)
After parsing
localhost:8080/apicall/dbname/_aggrs/rout?avars={%22routes%22:%22US%22}
In query object I have routes:us. So in chrome it parsing %22--%22 place of " ".
IN IE-11
Rh.all('apicall').get('dbname/_aggrs/'+ ar_dep +'?avars=' + query)
After parsing
localhost:8080/apicall/dbname/_aggrs/rout?avars={"routes":"US"}
In IE-11, It is not parsing double qoutes to %22 %22. It is parsing same as string.
A 500 error is always related to the server. The symptoms may only occur with a specific browser, but it is the server that is failing; the request that is being sent to the server is causing the server-side code to fail in some way.
Error 500 on its own is too generic; without knowing more details about the error, it is always very hard to diagnose, and frankly I won't be able to give you a definitive answer here.
At your end, you should rule out the obvious, and check your browser settings in IE. Specifically, any settings that might cause it to fail to communicate properly with the server. For example, make sure that cookies are enabled and are working properly.
But the first thing you should do is discuss with the vendor or developers of the API because they will have access to the server error logs, and they will want to know about it if their code is throwing a 500 error.
However, if you do want to investigate at your end, the fact that it is specific to one browser is a clue. If the other browsers are working, then what this tells us is that this one browser (IE11) is sending the request with something about it that is different to the other browsers, and it is that something that is triggering the server-side code to fail. This gives us something to work with in the investigation.
So the first thing to do is to examine the request in all browsers. Use the F12 dev tools in Chrome, Firefox and IE, and get to the point where you've made the same call in all three of them, and it works in FF and Chrome but not in IE11.
In the dev tools, you should now be able to examine the request details for all three. Compare them.
Start by looking at the request data -- ie the actual query string that was sent. If there are differences, consider whether any of these differences may be responsible for the error. Something may stand out obviously; eg if IE has truncated a variable or something like that. If this solves the problem, then great.
If it doesn't help, then you need to look in more detail. Maybe there are some differences but they don't look like they should break anything? Modern browser dev tools allow you to edit and re-send a request, so try editing the request in Chrome or Firefox's dev tools, and make the parameters the same as the ones from IE that failed. Now try re-sending that request. If you're lucky, this will cause the request to fail in the other browser, which will allow you to show that a specific set of data is the problem (rather than a specific browser). You mentioned that it's a third party API, so you'll then need to discuss with the API vendor to find out why that query breaks their API.
If you still haven't found the problem at this point, and you're sending identical queries in both browsers, and you're logged in as the same user, then the next step is to look at the request headers.
There is one request header that will definitely be different: the User Agent string. But there may be others too. Again, try re-sending request that works in Chrome, but with headers from the failing request in IE (including the UA string). Does the request now fail in Chrome? If so, narrow down which headers are different that make it fail.
Again, if this allows you to find a specific set of request data and headers that causes the problem, then you will need to discuss with the API vendor.
If all of this doesn't help, then try looking at the cookies. You already checked that cookies are working, so this seems like a long shot now, but again compare the cookies between browsers, and see if there's anything obviously different about them.
I hope the above is enough to help you diagnose the issue.
I am able to get Selenium driving Starting ChromeDriver 2.23.409699 via browsermob-proxy-2.1.2 and can access the HAR data however the timings seem strange particularly with SSL sites.
For example the first fetch is made to the website itself, which as per the timings takes:
# 512ms from start the first request goes out to page:
Connect: 1,306ms
SSL: 1,293ms
Send: 1ms
Wait: 16ms
Receive: 6ms
Then # 576ms (64ms after page) a second request to referenced style sheet goes out:
However as far as i can tell, the timings overlap in that request #2 goes out whilst the page is still waiting to connect (SSL and connection). Graphing it below shows them overlapping.
Any ideas what i am doing wrong or misunderstanding?
To summarize your data:
you start the capture
there is one request at 512ms to the main HTML page
there is another request at 576 ms to the stylesheet. This happens before the first request has finished
It is unlikely that a SSL handshake takes a whole 1293 ms. http://www.semicomplete.com/blog/geekery/ssl-latency.html lists times from 68ms to 408 ms for the complete transaction, including handshake. The same for retrieving https://www.mozilla.org/en-US/about/:
As a guess, Google did something clever with Chrome again.
It starts the TCP+SSL handshake,
then starts downloading the main HTML.
At the same time the HTML arrives, it is parsed, and
as soon as a stylesheet reference is encountered, this is downloaded as well (before the end of the HTML transfer).
These need to happen in separate threads for this optimization to work, but it could well reduce web download time (which seems to be one of Chrome's main aims).
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 am working on a large website built over Croogo in CakePHP. Today, without any warning, the following started to happen: if making a few consecutive HTTP request, the site remains in loading mode, inside the browser. Any attempt to access any other URL from the same domain results in the same result.
The interesting part, now: if I delete the "CAKEPHP" cookie and then try reloading it, everything works fine, until it freezes again.
Notes:
this is happening client side. The site is responding in other clients
PHP goes to use 30% of the processor power for a very short time just before the site becomes unresponsive
This is application related - I've tested it on three different configurations and all acted the same
I've commented the code I was writing before this happened and still no change
An Apache restart also makes the website responsive in the web browser
There are absolutely no slow queries. The largest time recorded for a series of queries is 134 ms. Also PHP mostly only parses data, with no demanding operations
This is happening equally in scripts with only one query and one variable showing and scripts that are parsing large data sets
This was solved by telling CakePHP to store sessions into database instead of "php".