Ajax sometimes stops executing

[CeyloR]

Hello everyone,

I have a problem with my Ajax page.

I'm jusing prototype-1.4.0.js as framework.

I have a function to populate three listboxes. The items in the
listboxes are from a MYSQL database and are related. The items are
requested by a php page.

Most of the time everything works fine, but sometimes I end u with only
one or two listboxes.


I can't figure out what's going wrong here. I've tested in Firefox and
Internet Explorer, both the same problem.

Does anyone know why my code sometimes stops executing?
Could it be that i made too many requests in a short time so the next
request can't execute because the current has't finished?

Hope anyone has an idea of what's going wrong.

Greetings

CeyloR

 

[Jake Barnes]

I use DOM manipulation as opposed to AJAX to do the calls to my
back-end, but they too can timeout or otherwise fail to complete.

So what I do is that each time I make a request I stick an object
in an array that contains the time that the request is being launched,
and enough information to re-issues the request and track te number of
attempts.

I have a setInterval function that periodically scans the array
and re-issues the requests that have gone stale.

The handlers that return a successful result confirm same
by removing themselves from the que.

Awesome idea. Do you have any example code of that?

 

[Laurent Bugnion]

Hi,

Hello everyone,

I have a problem with my Ajax page.

I'm jusing prototype-1.4.0.js as framework.

I never used that and probably never will, given the bad reputation that
it has. That said, AJAX is very robust. We make building management
systems (I work at Siemens), and our last product is a web application
which we successfully let run during days, typically up to 2 weeks or
more. During this time, the application polls through web services every
30 seconds. We even tested scenarios where it polled every 5 seconds. It
simply works. That said, I built a security mechanism, which is very
simple: At the very least, if something goes wrong (no server found,
timeout, etc...), the callback method will be called with an error. In
that case, it's easy enough to call the same service again, and then
another time before giving up. With this mechanism, we reduced the
number of "crashes" to almost nothing. Of course, it's almost impossible
to know what prototype does in its insides...

For the record, the application could run even longer if we didn't have
memory problems in IE. Even though we solved most of them in
collaboration with Microsoft (including "security" patches for IE 6 ;-)
there is still one last memory leak which cannot be solved. That's why
we recommend restarting the web browser (not the server!!) every two
weeks or so.

HTH,
Laurent

 

[Ian Collins]

Hi,



I never used that and probably never will, given the bad reputation that
it has. That said, AJAX is very robust. We make building management
systems (I work at Siemens), and our last product is a web application
which we successfully let run during days, typically up to 2 weeks or
more. During this time, the application polls through web services every
30 seconds. We even tested scenarios where it polled every 5 seconds. It
simply works. That said, I built a security mechanism, which is very
simple: At the very least, if something goes wrong (no server found,
timeout, etc...), the callback method will be called with an error. In
that case, it's easy enough to call the same service again, and then
another time before giving up. With this mechanism, we reduced the
number of "crashes" to almost nothing. Of course, it's almost impossible
to know what prototype does in its insides...

For the record, the application could run even longer if we didn't have
memory problems in IE. Even though we solved most of them in
collaboration with Microsoft (including "security" patches for IE 6 ;-)
there is still one last memory leak which cannot be solved. That's why
we recommend restarting the web browser (not the server!!) every two
weeks or so.

Why not use another browser?

 

[Laurent Bugnion]

Hi,

Why not use another browser?

Our marketing requirements are for IE only for the moment. That said,
apart from a few minor layout problems, our application is fully
compatible (though not as thoroughly tested) with Firefox too.

Laurent

 

[Jake Barnes]

Of course, it's almost impossible
to know what prototype does in its insides...

That's an odd thing to say. It is completely open-source and it is
quite small - just 48k. You can read over all the code in an afternoon.
You can use JsUnit to do some unit tests with it and figure out how it
works in less than 2 days.

 

[Laurent Bugnion]

Hi,

That's an odd thing to say. It is completely open-source and it is
quite small - just 48k. You can read over all the code in an afternoon.
You can use JsUnit to do some unit tests with it and figure out how it
works in less than 2 days.

Sorry, I expressed myself wrongly. What I actually meant is "Of course I
have no idea what prototype does in its insides". Since it appears to
break, my guess is that it doesn't do proper error handling but I didn't
check.

HTH,
Laurent

 

[Xionon]

I'm jusing prototype-1.4.0.js as framework.

Have you tried set the onFailure method for your Ajax.Request options
object? You may be able to pinpoint exactly what the problem is using
this. You could use the XMLHttpRequest object's 'status' property to
figure out if the server scripts were timing out, or giving you 404's,
or what. Or you could just set the onFailure method to try again with
a new request.

E.g.,
<script>
function doRequest(url, myPostOptions)
{
var myAjax = new Ajax.Request(
url,
{
method: 'post',
postBody: myPostOptions,
onSuccess: mySuccessMethod, //Only runs on successful calls
onFailure: myFailureMethod, //Only runs on failed calls
onComplete: myCompleteMethod //Runs for every call
});
}
function myFailureMethod (obj)
{
//do something with obj...
alert(obj['status']);
}
function mySuccessMethod(obj)
{
//do something with obj
}
function myCompleteMethod(obj)
{
//do something with obj
}
</script>