Issue Details (XML | Word | Printable)

Key: DWR-63
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Joe Walker
Reporter: Matan
Votes: 1
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
DWR

Comet notifications only once every 60 seconds in RC4 + IE7 JS errors during ReverseAjax

Created: 11/Apr/07 04:10 PM   Updated: 29/Feb/08 10:29 AM   Resolved: 17/Apr/07 04:52 PM
Component/s: core
Affects Version/s: 2.0.rc4
Fix Version/s: 2.0.rc5

File Attachments: 1. Java Archive File dwr.jar (466 kB)



 Description  « Hide
I just dropped in the new RC4 instead of RC3 which worked fine other than the reverse ajax only notifying every 60 seconds (see http://getahead.org/bugs/browse/DWR-54). The new version does NOT solve the problem of reverse ajax only notifying every 60 seconds... for both FF2 and IE7.

In addition now IE7 throws JS errors whenever it renews the ReverseAjax connection - which is every 60 seconds or every time it tries to do the Polling Only.

Here is the web.xml config for reference:

    <servlet>
        <servlet-name>dwr-invoker</servlet-name>
        <servlet-class>org.directwebremoting.servlet.DwrServlet</servlet-class>
        <init-param>
            <param-name>debug</param-name>
            <param-value>false</param-value>
        </init-param>
        <init-param>
            <param-name>crossDomainSessionSecurity</param-name>
            <param-value>true</param-value>
        </init-param>
        <!-- default script timeout (milliseconds) -->
        <init-param>
            <param-name>scriptSessionTimeout</param-name>
            <param-value>1800000</param-value>
        </init-param>
        <!-- What is the maximum number of calls that can be done in a single batch -->
        <init-param>
            <param-name>maxCallCount</param-name>
            <param-value>20</param-value>
        </init-param>
        <!-- Set to true to enable polling and comet. This can increase the load on your server although DWR does have mechanisms to prevent server overload. -->
        <init-param>
            <param-name>activeReverseAjaxEnabled</param-name>
            <param-value>true</param-value>
        </init-param>
        <!-- include querystrings in reverse ajax page uniqueness -->
        <init-param>
            <param-name>normalizeIncludesQueryString</param-name>
            <param-value>true</param-value>
        </init-param>
        <!-- What is the maximium number of threads we keep waiting. We reduce the time within poll to reduce the load. -->
        <init-param>
            <param-name>maxWaitingThreads</param-name>
            <param-value>20</param-value>
        </init-param>
        <!-- What is the maximum number of hits we should get per second. We increase the poll time to compensate and reduce the load. -->
        <init-param>
            <param-name>maxPollHitsPerSecond</param-name>
            <param-value>40</param-value>
        </init-param>
        <!-- How long are we telling users to wait before they come back next (in milliseconds) -->
        <init-param>
            <param-name>timeToNextPoll</param-name>
            <param-value>5000</param-value>
        </init-param>
        <!-- The max time we wait before opening a stream to reply (in milliseconds) -->
        <init-param>
            <param-name>preStreamWaitTime</param-name>
            <param-value>29000</param-value>
        </init-param>
        <!-- The max time we wait after opening a stream before we reply (in milliseconds). -->
        <init-param>
            <param-name>postStreamWaitTime</param-name>
            <param-value>1000</param-value>
        </init-param>
        <load-on-startup>3</load-on-startup>
    </servlet>


Sort Order: Ascending order - Click to sort in descending order
Joe Walker added a comment - 11/Apr/07 04:39 PM
You're really got a christmas tree set of init-params. Before I look at this please remove everything except the ones you really need, which is probably just activeReverseAjaxEnabled=true.
Also clear your IE7 cache - I think there could be some caching issues.
Thanks.

Thomas S. Pangborn added a comment - 11/Apr/07 07:03 PM
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.

Thomas S. Pangborn added a comment - 11/Apr/07 08:07 PM
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.

   

Matan added a comment - 11/Apr/07 09:03 PM
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....

Joe Walker added a comment - 12/Apr/07 10:55 AM
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>

Matan added a comment - 12/Apr/07 11:21 AM
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?




Matan added a comment - 12/Apr/07 11:29 AM
I forgot to mention that I disabled my anti-virus/anti-spyware on my firewall software and it also made no difference.

Thomas S. Pangborn added a comment - 12/Apr/07 11:36 AM
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.

Joe Walker added a comment - 12/Apr/07 02:38 PM
Fix for incorrect promote to parent code which should reduce IE7 errors and appears to fix CPU use increase too