Out of a sudden I realized that the Ajax requests that I make synchronously work no more and the only thing left for me is to close the browser tab as it hangs forever. The problem is not with a particular request but with all synchronous Ajax requests in my web application. If I turn them to async:true, then the problem gets solved. After some digging I found out that Kaspersky antivirus was blocking them. All the computers that I test the application on use Kaspersky for "virus-fighting" purposes. I tried with all major browsers and all present the same problem. Now a few things to note:
I didn't use to have this problem just a couple hours ago.
The application server also has Kaspersky running but AJAX sync request work normally(which makes me come to a conclusion that the problem is with the response)
I've put another simple test application with AJAX sync request and they work normally
Other antivirus programs don't cause such a problem.
So do you have any ideas what the problem might be? Is it something that I need to ask in Kaspersky forum?
Related
I have done something silly and written a script for a website that does an ajax check every 2 seconds. In this case its using wordpress and its admin-ajax.php file every 2 seconds. This essentially burned up all the CPU power of the server, and made every site on the server run really slowly.
After a lot of detective work, i finally found the script and stopped it, so that it doesn't happen on new loads of that website. But looking at my apache log, i can see that it is still running in one browser somewhere.
Is there a way for me to stop that browser from requesting that ajax-call, or perhaps block it from my server? Or will I just have to wait until that browser is being refreshed or closed?
Try to use netstat or something similar through ssh to detect the IP and port of the unknown browser. Also you should try to reboot the server so it may will loose connection.
PS: It's pretty hard to give a clue or answer in the right direction without having any logs or evidence to ensure you answer to this question correctly.
Sometimes, perhaps once every few hundred AJAX requests and/or where AJAX requests are executing in quick succession, I've seen a request hang for up to several minutes before it completes. The weird thing is that the request completes successfully AND neither my machine or the server are really doing anything either (e.g. CPU and other resources are not spiking during the "hang").
I've noticed this issue with various web services too, so it isn't just my own website. It also isn't database related as it has happened on non-database sites. It also only seems to show up in non-localhost environments.
When I personally use AJAX, I am also using jQuery, so this might also be a jQuery issue. I also mostly use Firefox, so I don't know if this is just a Firefox issue or if it is an issue any browser could have. I've run into the issue on multiple computers in multiple locations.
If you have run into this issue before and "fixed" it, I would appreciate the solution you came up with.
Use a HTTP debugger like Firebug or Fiddler to track the AJAX requests to see how much time it takes (possible timeout issue due to server setting?) & what HTTP response status code it returns when it fails. Use the HTTP response status code to troubleshoot the issue.
I have a web app idea which will require AJAX requests to function. Its crucial that AJAX requests are running as long as the user is on the site.
My question is, if the user left the site up (my ajax requests will be running) for say 4/5 hours, will these AJAX requests still run, my concerns are screen dimming, screensavers, computer sleep states. Will all or none of these affect the performance of my web app?
Unfortunately, it's very client dependent. For example, mobile devices may stop processing JS when going into a sleep state (e.g., to save battery life). However, on an image rotator application I wrote some time ago, which sent regular requests to the server to retrieve images (there was good reason not to cache them, I swear), accessed primarily by non-mobile clients, I observed that requests continued for hours, even days. While I can't know if the client machine ever entered a sleep state, I'm pretty confident it did.
Long story short - I think you can't be sure, but for some target audiences, you can be reasonably sure. I would recommend investigating your audience.
If in your site users require to login simple keep a session time out option to lets say 15 mins. That means after 15 mins of idle time the session will be destroyed and the ajax requests automatically truncated.
If you do not have login this becomes difficult but still can be achieved via ip tracking or similar mechanisms but these will never be as full proof as the first one.
I must agree with Sean in that it it's very client side orientated. If the client stays active, be it through human interaction our not, then the AJAX should keep going.
Does anyone know why a synchronous ajax call would fail and give the following error on Safari on an iPad, but the same code works fine on all other platforms and browsers I've tested so far?
NETWORK_ERR: XMLHttpRequest Exception 101: A network error occurred in synchronous requests.
That error suggests that I'm attempting a cross-domain request, but I'm not; the requested URL is on the same host, and in fact it's a relative URL. Even in trivial tests, this fails on the iPad (and works on all other platforms and browsers, including Safari), so I'm confident I've ruled out any possibility of a time out.
Also, the same request, if made asynchronously, works perfectly on the iPad; it's only synchronous requests that give the 101 exception. It's driving me crazy!
One more bit of detail: this only happens on my production server. The synchronous ajax call actually works fine on my development server. Both servers require the same client certificate... so I don't think there's any difference there. I can't think of any difference between the two servers that could have an effect here.
Any insight into this problem would be greatly appreciated. Thanks!
It turns out the key difference between our development and production systems is the certificate requirement.
The issue turns out to be a problem with the way XMLHttpRequest.send() on the iPad version of Safari processes a synchronous request on a domain that is certificate-protected. I can't explain the internals of the method, but somehow it has a problem and throws the 101 exception, believing it--apparently--to be a cross-domain request. Again, the same request made asynchronously on the same certificate-protected server works just fine. Frustrating case, and one with no solution!
I'm trying to create a small and basic "ajax" based multiplayer game. Coordinates of objects are being given by a PHP "handler". This handler.php file is being polled every 200MS, by using ajax.
Since there is no need to poll when nothing happens, I wonder, is there something that could do the same thing without frequent polling? Eg. Comet, though I heard that you need to configure server side applications for Comet. It's a shared webserver, so I can't do that.
Maybe prevent the handler.php file from even returning a response if nothing has to be changed at the client, is that possible? Then again you'd still have the client uselessly asking for a response even though something hasn't changed yet. Basically, it should only use bandwidth and sever resources if something needs to be told to the client, eg. the change of an object's coordinates.
Comet is generally used for this kind of thing, and it can be a fragile setup as it's not a particularly common technology so it can be easy not to "get it right." That said, there are more resources available now than when I last tried it ~2 years ago.
I don't think you can do what you're thinking and have handler.php simply not return anything and stop execution: The web server will keep the connection open and prevent any further polling until handler.php does something (terminates or provides output). When it does, you're still handling a response.
You can try a long polling technique, where your AJAX allows a very large timeout (e.g. 30 seconds), and handler.php spins without responding until it has something to report, then returns. (You'll want to make sure the spinning is not resource-intensive). If handler.php "expires" and nothing happens, have it exit and let AJAX poll again. Since it only happens every 30 seconds, it will be a huge improvement over ~5 times a second. That would keep your polling to a minimum.
But that's the sort of thing Comet is designed for.
As Ajax only offers you a client server request model (normally termed pull, rather than push), the only way to get data from the server is via requests. However a common technique to get around this is for the server to only respond when it has new data. So the client makes a request, the server hangs on to that request until something happens and then replies. This gets around the need for frequent polling even when the data hasn't changed as you only need the client send a new request after it gets a response.
Since you are using PHP, one simple method might be to have the PHP code call the sleep command for 200ms at a time between checks for data changes and then return the data to the client when it does change.
EDIT: I would also recommend having a timeout on the request. So if nothing happens for say 2 seconds, a "no change" message is sent back. That way the client knows the server is still alive and processing its request.
Since this is tagged “html5”: HTML5 has <eventsource> and WebSocket, but the implementation side is still in the future tense in practice.
Opera implemented an old version of <eventsource> called <event-source>.
Here's a solution - use a SaaS comet provider, such as WebSync On-Demand. No server resources to worry about, shared hosting or not, since it's all offloaded, and you can push out the information as needed.
Since it's SaaS, it'll work with any server language. For PHP, there's already a publisher written and ready to go.
The server must take part in this. Check with the hosting provider what modules are available. Or try to convince them to support Comet.
Maybe you should consider a small Virtual Private Server (VPS) for this.
One thing to add on the long polling suggestions: If you're on a shared server, this solution will have limited scalability, as each active long poll will keep a connection (and a server-side process to service that connection) active. Your provider most likely has limits (either policy-defined or de facto) on the number of connections you can have open at a time, so you'll hit a wall if you have more sessions/windows than that playing concurrently.