[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-3721) Seam Remoting Callback not set before server response comes back

Not that I don't trust Yahoo, but I haven't seen this technique used by another library besides them (e.g. Prototype, GWT). Can you confirm that this technique works flawlessly > in regards to concurrency (with multiple concurrent requests being processed), on all major browsers?

Seam Remoting Callback not set before server response comes back ---------------------------------------------------------------- Key: JBSEAM-3721 URL: https://jira.jboss.org/jira/browse/JBSEAM-3721 Project: Seam Issue Type: Bug Components: Remoting Affects Versions: 2.1.0.GA, 2.1.0.SP1 Environment: XP SP3, VMWARE 3.5i ESX, 2GB RAM, DualCore AMD 3800+ Reporter: Paul Chan Assignee: Shane Bryzak Attachments: remote.js.diff, remote.js.diff Original Issue =========== I tracked the issue down to one line of javascript code in remote.js req.onreadystatechange = function() {}; The following thread discusses the problem is with an old version of the JScript.dll 5.6.0.8820 which is the same version I've got on a laptop here. http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/69... One solution is to upgrade JScript.dll to 5.6.0.8831 http://www.microsoft.com/technet/security/bulletin/ms06-023.mspx Or we can do what they did in GWT which is to move the req.onreadystatechange out of the scope of the current function window.setTimeout(function() { req.onreadystatechange = function() {}; }, 0 ); Problem found with the above fix ============================ I have found a bug in this fix. If the server response comes back before the "window.setTimeout(xxx,0) expires, it will drop it. From reading the javascript specs, the minimum timeout value is actually around 25ms. Anything smaller than that, it gets rounded up. Also, using timer to set response callback are inherently flawed IMO. There's always going to be some sort of race condition. This problem seems to happen on internet explorer, and safari. Firebox doesn't seem to have a problem with it though. I discovered this problem when I set a break point on the incoming request processing code on the server. If the breakpoint is inserted, everything is good. But when I removed the breakpoint, the problem appears again.