I run into request timeout on a page that emit simple queries to database on Heroku using Flask, only on the first access of that page after a period of inactivity. I have looked into similar questions asked, but i don't think they fits my case.
To clarify and give the context to this problem further:
Only after refreshing, accessing that page does not cause request timeout.
However, the problem only reappears after a long pause of inactivity on the website.
I traced the error with printing statement in the code. The timeout seems to be when at the end of one page redirecting to another. All the code runs properly, including the query to the database, until it hits return redirect.
For example, the actual error is on the path specified as this new page redirected.
at=error code=H12 desc="Request timeout" method=GET path=/resultSearch host=nutrientdata.herokuapp.com fwd="216.165.95.73" dyno=web.1 connect=1ms service=30001ms status=503 bytes=0
To support the point that the code inside is not the problem: I traced database performance on new relic, but the query emitted on this page takes very short amount of time.
I tried replicating the situation on local host but it does not give me any error. However, indeed, redirecting to the page first time on local host takes longer time than the subsequent redirecting to the same page (only after a period of inactivity)
I tried pinging the app using new relic - however i'm not pinging that particular page, but the first page of the app.
I tried to fix this by, instead of redirecting to another page, just rendering one (temporary) page before allowing other redirecting. It turns out that the problem now is shifted to new page. In other words, request timeout is now on another redirecting. All of these, again, happen during the first access to the app after a period of inactivity.
I think what I'm looking for is why does redirecting for the first time after a long period of inactivity takes longer than another. And how should i fix it to solve this request timeout.
Any help on this would be much appreciated. Thank you!
You said the problem is present even in your local devserver so it's not Heroku related.
Normally this type of problems are due to database's transparent caching.
Trace, in your local devserver, the queries you're making to the db in the slowest scenario (that is that new page you're accessing after the redirect).
Probably there's an index to make/improve.
Related
When I make a XmlHttpRequest (via jQuery's $.ajax) to a particular URL, my Chrome consistently hangs every time with a status on the request of 'Pending'.
After that Chrome must be closed ie. forcibly from Task Manager, and it exhibits general signs of mayhem such as the Cookies and Scripts tabs being empty when they were full of normal looking data immediately prior.
This is odd because (a) my coworkers, running a seemingly identical everything, have no such problems; (b) I have been using Chrome to run this code (our company's JavaScript app) for many months and this just started happening for no apparent reason.
I checked out the Apache logs, they appear to be processing the request normally and to completion, but Chrome never sees the reply, apparently.
A couple of other clarifications: prior to the failure, the same Chrome and Apache return a truckload of JS and image files normally, eg., things seem to be fine right up until they aren't. The request is not particularly large (a few hundred bytes in and out) or complex in any obvious way.
If anybody can give me some hints of where to look, I'd be grateful!
I'm experiencing similar behavior with slightly different symptoms. My ajax requests work fine, every second request up to 6 requests, then they all start failing (same url as when working, same payload, etc), but in my case they're not even hitting the server, just stuck in "Pending" in Inspector.
I dont have an answer for you, but to help debug, have you tried chromes net-internals?
Point your browser at:
chrome://net-internals/#sockets
and/or
chrome://net-internals/#events
I see my requests in #sockets go into "active", but never come back, and in #events I can see that the request stalls after the HOST_RESOLVER_IMPL_REQUEST stage.
I'm thinking it could be a resource issue caused by not properly ending the request, but thats just pure speculation.
I have a strange problem with using ajax post requests. I use the request to run an ImageMagick process directly on the command line by using php function exec(). The process takes about a minute, and then responds with some variables. This is working fine, except from one problem. During the execution time I cannot excess other parts of the website that are installed on the same webserver (as if the server is unreachable). When the process finishes, everything works fine again.
I first thought this to be due to an overloaded server. However, when you access the website via another browser, there are no problems, even during the execution time of the process in the other browser. So it looks like the problems has something to do with browsers blocking other requests during the post request.
Could anyone help me out here? What could be the root problem?
Found the solution! Thanks from the help by kukipei By adding session_write_close(); to the file of the ajax request (after is has read the userid and token), the session file is no longer locked, and all pages are accessible again. Problem was that the session was locked during the whole execution time of the process, which was not necessary, since I only needed the session to read the userid and token. So before calling the ImageMagick operation, I now add session_write_close()
I'm trying to implement a chat app that uses long polling to get messages from a remote (cross domain) server.
Is there any way to do this with a XDomainRequest? It seems my connections always get terminated after a random amount of seconds/miliseconds (usually about 1-3 secs) instead of waiting for the server to respond.
The IE dev toools thell me that the request has been "aborted" with no data received.
Is the XDomainRequest just not fit for long polling or am I missing something here?
Had this problem too, as a race condition, using the jQuery iecors library. The IE network console showed the request as "abort" despite Fiddler showing a 200 response.
After a few stubborn rounds of googling, I came across this link which recommends filling out all the callback handlers. I suspect that onProgress was only being called, and failing, when the request was slowed by a heavy page, leading to my race behavior.
IE9 XDomainRequest issued requests may abort if all event handlers not specified
For jquery.iecors.js, it was missing the onprogress handler, in addition to a few variable name typos. Adding this line seems to fix it.
xdr.onprogress = function () {};
For me the issue dealt with multiple query functions running as a single batch function using XDomainRequests. WebTools showed all requests to the remote server would abort but the last. Running with alert(query) before each query worked. So I ended up moving my XDR invocation (e.g. new window.XDomainRequest) inside the loop so a new instance would be created for each query to the remote server. Each result is inserted into an different input box via getElementById(id).value. With a delay timer added I can see it runs sequentially filling in each value now with no issues. Without delay it is virtually instantaneous.
I am currently working on a Django development. There is a problem, which isn't a true problem but very annoying. Often, when I try to debug my Django app by putting down some break points, I get this error at the server end:
error: [Errno 32] Broken pipe
After reading this other post, Django + WebKit = Broken pipe, I have learned that this has nothing to do with the server but the client browser used. Basically, what happened is that the browser has a http request timeout. If it doesn't receive a response within the timeout, it will close down the connection with the server.
I find this timeout isn't really needed, indeed causing headache, during debugging. Is there any way I can lift this timeout or increase it for my browser (Chrome)? Or maybe a substitute browser that doesn't have this constraint?
Note: Although I am using Django and have mentioned about it, this isn't a Django-related question. It's more like a question on how to make my debugging process more effective.
I prefer using linux/unix curl command for debugging web applications. It's good approach, especially if you want to focus on some specific request, for example: POST does not work fine for some set of parameters, or cookies are not set as expected.
Of course it may take some time at the beginning to find out how to use it, but then, you will have a total control about every single piece of request: timeouts, cookies, headers and so on. It's very helpful, because you can be sure that what you wanted to send is actually sent (no additional data is added by the web browser).
There are plenty of examples of similar problems littered around the web but none of their solutions seem to fix this particular variation. Any suggestions would be appreciated.
Usually this problem occurs because a rogue link is causing a request for a resources like a favicon or css file to hit the dispatcher more than once, thus causing multiple dispatch processes and therefore multiple rows in your database.
I have checked that all the links on this very simple example page do actually resolve to the resource to which they point.
The session handler is setup as follows:
Zend_Db_Table_Abstract::setDefaultAdapter($db);
Zend_Session::setSaveHandler(new
Zend_Session_SaveHandler_DbTable($config->session->toArray()));
The db logging is setup as follows:
$writer = new Zend_Log_Writer_Db($db, $config->log->tableName,
$config->log->columnMap->toArray());
$logger = new Zend_Log($writer);
Both objects are correctly setup and can read and write to and from the database. Only everything happens twice. If I put a test log message anywhere in the application it is written into the database twice. If I increment three variables with every call to the index action - one stored in the session, one passed around via a Zend_Registry object and another local to the indexAction - only the session variable is incremented by 2. The Apache access log shows the correct amount of requests being fired from the page load and all have good response codes of either 200 or 304 (unchanged).
I have tried disabling all head links.
I have tried disabling the layout entirely.
I have localised everything to the dispatcher and exited before dispatch is run.
In all cases the extra write/increment takes place.
Any thoughts?
Thanks in advance for any help.
I seem to have found and fixed the issue. Chrome (and possibly all Webkit browsers) issues an additional HEAD request on top of the GET which means the application is hit twice and anything session based will be triggered as a result of both requests. My temporary solution is to put the following code near the start of my index.php file.
if ("HEAD" == $_SERVER['REQUEST_METHOD']) {
exit;
}
I hope that helps anyone with the same issue.
Google Chrome always asks for the favicon.ico by making annoying requests to the server. Take care about this in Chrome.
For more information:
http://framework.zend.com/issues/browse/ZF-11502?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#issue-tabs
Thanks to the Sebastian Galenski contribution.