I am using RightJS which is very similar to jQuery on a webapp. I have setup a periodic event that is supposed to send a request to the server and update an element on the page with the result every second. The code looks like this.
var update_temp = function (){
$('current_temp').load("/api/temp");
}
update_temp.periodical(1000);
This code seems to work fine for a while but randomly it will stop working and the element stops being updated. I put a breakpoint in the javascript code in the browser at the line $('current_temp').load("/api/temp"); and the breakpoint does continue to get hit every second. However, for some reason the browser doesn't seem to be issuing the request to the server. In the Chrome developer tools there is a 'Network' tab that lets you see requests that are being made. I see no more requests happening.
Could this be a cacheing problem? Or could it be that one of the requests never returned so the browser stops issuing requests to that url?
If I type the .../api/temp directly into the browser address bar and hit refresh it returns the temperature just fine every time.
Any suggestions?
I would try the caching problem. Try to add a timestamp after each request .. i. e. something like this:
var update_temp = function (){
$('current_temp').load("/api/temp?killcache=" + (new Date()).getTime());
}
update_temp.periodical(1000);
Related
So I have a quite expensive and complex PHP process which makes its execution long lasting, lets call it function "expensive_process()".
I have an interface which through a press of a button calls an ajax request to a PHP script which in turn initiates "expensive_process()". Here's the javascript code:
$('#run_expensive_process_button').click( function(){
var url = "initiate_expensive_process.php";
$.ajax({
url: url
});
});
And initiate_expensive_process.php code:
<?php
session_start();
run_expensive_process();
?>
Simple and trivial. Now the issue with this is that while expensive_process() is running, the browser is losing the ability to navigate the domain. If I refresh the browser window it hangs indefinitely while the process last. If I redirect to a different url under the same domain, same thing. This happens in all browsers. However, if I relaunch the browser (close and open a new window, not a tab), navigation works normally, even though expensive_process() is still running.
I've inspected network traffic, and the HTTP request to initiate_expensive_process.php doesn't get a response while expensive_process() is running, but I'm assuming this shouldn't be locking the browser given the asynchronous nature of the request..
One more thing, which I believe is relevant. This situation is happening on a replica server. On my local machine, where I run WAMP and the same source code, this is not happening, i.e., while expensive_process() is running, I'm still able to navigate the hosting domain without having to relaunch the browser. This seems to be an indication of a server configuration problem of some sort, but I'm not sure I can rule out other possible reasons.
Anyone know what might be causing this or what can be done to figure out the source of the problem?
Thanks
Most likely the other PHP scripts also session variables. Only one script process can access a session at a time; if a second script tries to access the session while the first script is still running, it will be blocked until the first script finishes.
The first script can unlock the session by calling session_write_close() when it's done using the session. See If call PHP page via ajax that takes a while to run/return (and it sets session variables), will a 2nd ajax call see those session changes? for more details about how you can construct the script.
I wonder whether it might be due to ajax. The javascript is being executed client-side.
Maybe you might consider a stringified JSON call instead of ajax?
I have javascript page that calling another page.
when the second page is called, I send request data to sql server to see how many
time the second page is called.
But always see that just once.
I've added dynamic querystring to prevent cache from browser
this is my code:
for(i=1;i<=30;i++)
{
var q="eeee?id=" + i;
window.location=q;
}
But alwayes see these 2 records in database instead of 31 records:
javacall ==> first page that has java call function
eeee?id=30
why page is called in 30th call and not from 1 to 30, for example:
javacall
eeee?id=1
.
.
.
eeee?id=30
The browser doesn't check to see if location has changed until the JavaScript has stopped running (it is too busy running the JavaScript until then).
When the loop gets to the end, it will be set to the last value. At the point, the browser registers that it has changed and loads the new URL.
If that wasn't the case, then the first change to it would cause the browser to leave the current page… which will destroy the execution environment the script was running it, abort the script and cause the subsequent URLs to not be requested.
If you want to make multiple HTTP requests from JavaScript, then use Ajax. You'd normally do this through the XMLHttpRequest object.
This is a bizarre problem - I have a very simple app that makes an AJAX call to a flask endpoint every 15 seconds and returns a number, which changes pretty frequently (inbox count). Then it's just a jquery selector to update the div with this data.
When I first put this thing together a few months ago there was no issues, I kind of forgot about it until recently when I made a few small changes. Now for some reason the page will load initially with the correct count, but when the AJAX call is made, it doesn't update in Chrome, but does in Safari (haven't tested other browsers yet). It use to work fine in both. I'm pretty confident this has nothing to do with the change I made as it was pretty trivial and it certainly wouldn't only impact one browser.
I can see the call being made to the endpoint in the network section of dev tools for both browsers, and it is returning the data is it should, it's just that the data never changes in Chrome. It's as if chrome is caching that value or something, so it does the AJAX call but ignores the new value and just uses what it had several iterations ago.
If i hit the AJAX endpoint directly in the browser, it works as it should. Its only the AJAX call within Chrome that keeps the "stale" data.
Any ideas what would cause this?
EDIT: Code Below
function outer(){
var play_count=0
function updateRefunds() {
$.getJSON('/countdown', function (data) {
if(data.refunds==0){
$('#canvas').show()
$('#refunds').hide()
if (play_count==0){
$('#katy')[0].play()
play_count++
}
}
$('#refunds').text(data.refunds);
});
}
return updateRefunds
}
var savestate=outer()
setInterval('savestate()', 15000);//every 15 sec
I've been working on an automatic log-out functionality for my web page. As a part of that, I implemented the window.location.reload(true) in 3 different places in my code. Two of them are automatic, one is attached to a link. The link always works, but the automatic ones don't always work, and I don't understand why.
For the automatic logouts, one set by a debouncer:
var userActionTimeout = debounce(function(e) {
console.log("inaction timeout, reloading page");
window.location.reload(true);
},15000;);
$(document.body).on('mousemove keydown click scroll',userActionTimeout);
Which theoretically should reload the page after a certain amount of inactivity.
The other two uses happen after certain types of AJAX data submission (e.g. blatantly wrong data sent that could only happen if the client was modified) trigger a log out. Of course, any further AJAX submissions are ignored by the server, and the next page the server will serve the client is a login page. In the event this happened inadvertently, AJAX sends the client an error message that includes the following:
refresh to continue session
I also implemented a timeout that also happens if this link is served, which happens after the AJAX response is received:
if (typeof response._forceRefresh !== 'undefined' && response._forceRefresh) {
console.log('reload firing');
/*
some code to insert the link into a spotlight here
*/
setTimeout(function(){console.log('reloading in 3s...');},7000);
setTimeout(function(){
console.log('reloading...');
window.location.reload(true);
},10000);
}
However the issue I'm having is this: Most of the time, the debounce page reload works (tested in firefox & chrome), however occasionally it doesn't. The link always works, but the AJAX response reload is about 50/50. I know it receives the response from the server since the link shows up, but quite often it doesn't actually automatically reload the page.
What is going on?
When ever I get inconsistency on a web page, it usually involves caching that I didn't realize was happening. If you haven't already, look through your project with that in mind and see if there is an effected location that you can force it not to cache a page.
Another idea might be to try using the meta refresh element. There is another thread where this is suggested: auto logout idle timeout using jquery php
I'm implementing Comet using the script tag long polling technique, based on this page. Following on from my previous question, I've got it all working, except for one annoyance, which only happens in Firefox.
On the initial page load my Comet client JavaScript sends two requests to the Comet server (in the form of dynamically generated <script> tags that are appended to the DOM):
get_messages - this is ongoing poll for messages from the application.
initialise - this is a once-off request at startup.
These two happen at the same time - that is, the <script> tags for both of them exist in the DOM at the same. (I can see them in the Firebug DOM inspector.) The server immediately sends some script as a response to the initialise request, but it doesn't send anything for the get_messages request until there's actually a message, which may take a while.
In Firefox 3.5 the script returned in the <script> tag for the initialise request does not get executed until the other <script> tag (for get_messages) also loads! In Chrome 3 and IE 8 this works fine - the script is executed as soon as it's received.
Why does Firefox do this and how do I fix it? I suppose I could try to work around it on the server by sending a dummy "message" at the same time as the initialise response, but that's quite a hack. I'd like to understand and fix this properly, if possible.
Seems to me to be a question of load order. Firefox always ensures that requests queued up execute in the order in which they were requested. IE does NOT ensure this (not sure about Chrome).
Regardless, if you shouldn't be calling get_messages until after the initialize code, you would want to trigger that request in the callback from your initialize function anyway. You'd want to do this no matter what, because other browsers may be inconsistent as well. IE6 for sure doesn't work the same way as other browsers regarding load order - it won't continue loading the DOM until the long-poll request completes, so you'd be stuck waiting around for your long poll interval just to see the main DOM load.
You can check out the source for our javascript client if you want details, we ran into similar issues when building our ASP.NET comet server, WebSync. The source can be viewed here:
http://sync.frozenmountain.com/client.ashx?debug=true
Do a search for "ie6" to see some of the workarounds.
I'm not sure why this is occurring, but perhaps a simple workaround would be to only add the get_messages <script> tag once the initialise request has completed. (I presume you have some callback that processes the response from the initialise request.)