Okay everyone, I'm struggling with the same problem right now...
My company uses primarily AJAX instead of form submits (does that make anyone cringe?) to pass data to our server. We have some client side error/field checking going on, but then we also have potential database issues, so we AJAX submit our data, try to do *whatever* with it, and if we get any exceptions, they are passed back into the window which is eagerly waiting for a response. If its a good response, we close the window. If a bad response, we display an error message in a status area. For awhile now, but more frequently as of late it seems, we've had an issue where the users have clicked 'Save' and it seems to hang in certain parts of our application. When we send the data, we lock the button so they get a javascript alert to ask them to please wait while its saving. However, minutes go by with no response, so the button remains locked, and they have to close out and come back to enter data again (and may very well have the same problem).
We have a few different means of performing our AJX submits.. some of our code is using prototype.js's Ajax.Request object, and others are using a GET or POST method in an AJAXapi javascript object an old co-worker wrote. That was the first place I went to debug this problem, and sure enough, we were only handling a few expected response codes. So we then found out we were getting the 12030 error, and in some cases 12029 (I believe). The users seem to be experiencing the trouble only during POST submits (but the places we ARE using GET should really be POSTs). I tried to modify the javascript to resend the request up to three times behind the scenes, hoping that the retry would work (since the error was sporadic).. problem is I can't test these changes easily myself, I have YET to replicate the problem on our system, or over VPN or on one of their terminal servers. So I have to rely on the reports of annoyed customers!
My changes did not work, so I have fallen back on throwing an error, which releases that save buttons lock, and lets them try to resend it themselves. They seem to have luck with this, and can pretty consistently (I was led to believe) save the 2nd try.
I don't know what their IE security settings are, but shouldn't the error be consistent if thats a factor? Also, I think we have customers with the problem running both IE6 and IE7. Many of our customers do NOT seem to have this issue, but I'm not sure if that has anything to do with what parts of our application they are using, or volumn of users, network configuration, yaddy yadda..
Heres the AJAXapi we use:
function AJAX(url, responseHandle) {
this.url = url;
var req = init();
var isPost = false;
var params = '';
this.responseHandle = responseHandle;
req.onreadystatechange = processRequest;
function init() {
if (window.XMLHttpRequest) {
return new XMLHttpRequest();
} else if (window.ActiveXObject) {
isIE = true;
return new ActiveXObject("Microsoft.XMLHTTP");
}
}
function processRequest () {
if (req.readyState == 4) {
if (req.status == 200) {
if(responseHandle)
eval(responseHandle + "(req.responseXML)");
else
postProcess(req.responseXML);
} else if (req.status == 400) {
if(responseHandle)
eval(responseHandle + "(req.responseXML)");
else
postProcessError(req.getResponseHeader("SQL-Error"));
} else if (req.status == 501) {
if(responseHandle)
eval(responseHandle + "(req.responseXML)");
else
postProcessMessage(req.getResponseHeader("GEN-Message"));
} else {
req = null;
req = init();
req.onreadystatechange = processRequest;
if(isPost)
this.sendpost(params);
else
this.send();
}
}
}
this.send = function() {
isPost = false;
req.open("GET", url, true);
req.send(null);
}
this.sendpost = function( parameters ) {
isPost = true;
params = parameters;
req.open( "POST", url, true );
req.setRequestHeader( "Content-type","application/x-www-form-urlencoded" );
req.setRequestHeader( "Content-length", parameters.length );
req.setRequestHeader( "Connection", "close" );
req.send( parameters );
}
}
Now we just send the processError() anytime we get a status we didn't expect. I actually had to rewrite some of these changes from memory but I think this is how it was trying to work.. although I'm wondering if saving the POST parameters was written like that.. at one customer they are able to save a second time and its fine (I don't know what is done any differently in clicking Save again and what I tried here), they are the ones that saw the 12030 error. Now I'm hearing that this ISNT working for the other customer, where we saw 12029 (or maybe 12031, i think its the CONNECTION_FAILED one).. So I wonder if theyre timing out somewhere or just flat out not getting a response..
Here's a sample of how we're sending data with the sendpost(params) method:
var AJAX = null;
var saving = false;
function save() { // this is a bogus function i just removed alot of extraneous code
saving = true;
var varURL = '<%=pusgActionURL%>/SaveController' // fake controller name
var varParams = 'action=<%= prsgAction %>&clientID=<%= prsgClientId %>'; // there would be alot more data here
ajax = new AJAX(varURL);
ajax.sendpost(varParams);
}
function postProcess(response) {
if (window.opener && !window.opener.closed)
window.opener.refreshGrid();
window.close();
ajax = null;
saving = false; //the flag that locked the save button
}
function postProcessError(error) {
document.getElementById('feedback').style.color = red;
document.getElementById('feedback').innerHTML = "ERROR: " + error;
ajax = null;
saving = false; //the flag that locked the save button
}
Any help would be greatly appreciated.. we need a quick fix on this api if we can now, and then maybe change our method in the long run.. Thanks in advance for any responses
