|
I am also seeing the new javascript errors in IE7 and the latency, i.e. 60s polling period for the ReverseAjax.dwr POST to the server. I have cleared my cache and am still seeing the problems.
CPU utilization with IE 7 is also still apparent. Again, the browser's spinner just keeps going and the CPU utilization slowly climbs as each reverseAjax request is made. I am not sure if this is related, I have not investigated further; however, I have other JavaScripts that are now failing where they were not previously. I'll need to track this down to see what the problem might be here. As I capture more information I'll post that information as well. Here is where I found the JavaScript was failing using the Microsoft Script Debugger:
Line 940 of engine.js is where the problem is occurring. The line number is a rough guess from the JavaScript error window. /** @private This is a hack to make the contexct be this window */ dwr.engine._eval = function(script) { if (script == null) return null; if (script == "") { dwr.engine._debug("Warning: blank script", true); return null; } // dwr.engine._debug("Exec: [" + script + "]", true); return eval(script); <----------------------------------------------------------------------------- IE is complaining this is an error. }; Sorry for any typos etc. with this function eyeballing from a windows machine running IE. I'll try and capture the value of script and see where there might be a problem. Clearing the cache and reducing the web.xml does not solve the problem. My error is similar to Thomas' on line 940. Here is the error from inside the script that is "eval"ed:
"dwr" is undefined in line 4, char 1 "dwr" is undefined in line 13, char 1 This is one part of the problem. The other is i still don't get notifications faster than 60 seconds.... I'd like to explore what app-server you are using. IIRC, you mentioned tomcat previously. Are you fronting it with Apache? and if so are you using mod_jk? and what versions are you using?
It sounds like something is preventing the browser going into chunked mode which is a low level issue. Might there be other issues like virus scanners that break javascript? You could also try the attached jar file. It contains the old verbose way of flushing IE7 which might stop the IE7 script errors. If the jar file does not get to you then you could try downloading it from nabble. It's also worth trying the polling case with the following init-param: <init-param> <param-name>org.directwebremoting.extend.ServerLoadMonitor</param-name> <param-value>org.directwebremoting.impl.PollingServerLoadMonitor </param-value> </init-param> I've tried it with both Tomcat 5.5.23 and Tomcat 6.0.10 - with and without APR native libraries which I thought would maybe have an impact on the chunked mode.
I use Tomcat directly w/o Apache. Using "polling only" does not make a difference other than the more frequent errors since it connects every 5 seconds instead of 60 (my timeToNextPoll setting). What *did* make a difference was your attached JAR. IE7 seems to behave with it and I see no JS errors. I can't confirm yet any differences with the 60sec only updates with comet at the moment, but i'll be able to later today. Was any of this suppose to fix that? Does your IE7 work fine w/o the JAR? I am using Sun Java System Application Server and have the same problem. I also am using the attached jar file with no IE errors. That's the good news. The bad news is the system is still in a limbo state where it the timeout is around 60s. No change there.
Let me know what else I could do to help test if you have any ideas. Fix for incorrect promote to parent code which should reduce IE7 errors and appears to fix CPU use increase too
|
|||||||||||||||||||||||||||||||||||||
Also clear your IE7 cache - I think there could be some caching issues.
Thanks.