DWR

Reverse Ajax streaming fails with Tomcat Async support on Firefox and fails in general on Internet Explorer 8

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: 3.0.RC2, 3.0
  • Fix Version/s: None
  • Component/s: None
  • Documentation Required:
    No
  • Description:
    Hide
    First i compiled the latest DWR from svn including the Clock Demo.
    Then i deployed it on the latest Tomcat 6.0.24 and tested the Demo with two configurations.

    1. tomcat default connector and dwr default servlet
    2. tomcat with "org.apache.coyote.http11.Http11NioProtocol" Connector and dwr Tomcat.DwrCometSupport Servlet.

    Results:

    Config 1 on Firefox : works as expected
    Config 1 on IE8 : Clock update every 60 seconds (when the long-poll restarts)

    Config 2 on Firefox : works sometimes, but often crashes with one of these messages (pasted from firebug):
    Reverse Ajax poll failed (retries=0). Trying again in 2s: dwr.engine.missingData : No data received from server
    Reverse Ajax poll failed (retries=0). Trying again in 2s: TypeError : contentType is null
    Reverse Ajax poll failed (retries=2). Trying again in 10s: dwr.engine.incompleteReply : Incomplete reply from server

    Config2 on IE8 : does not work at all.


    Second Test:
    I took the DWR3 RC1 Download with the Clock Demo from the page and made the same four tests.
    All of them seemed to work!
    Show
    First i compiled the latest DWR from svn including the Clock Demo. Then i deployed it on the latest Tomcat 6.0.24 and tested the Demo with two configurations. 1. tomcat default connector and dwr default servlet 2. tomcat with "org.apache.coyote.http11.Http11NioProtocol" Connector and dwr Tomcat.DwrCometSupport Servlet. Results: Config 1 on Firefox : works as expected Config 1 on IE8 : Clock update every 60 seconds (when the long-poll restarts) Config 2 on Firefox : works sometimes, but often crashes with one of these messages (pasted from firebug): Reverse Ajax poll failed (retries=0). Trying again in 2s: dwr.engine.missingData : No data received from server Reverse Ajax poll failed (retries=0). Trying again in 2s: TypeError : contentType is null Reverse Ajax poll failed (retries=2). Trying again in 10s: dwr.engine.incompleteReply : Incomplete reply from server Config2 on IE8 : does not work at all. Second Test: I took the DWR3 RC1 Download with the Clock Demo from the page and made the same four tests. All of them seemed to work!

Issue Links

Dependency
 
Relationship
 

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Mike Wilson added a comment - 12/Jun/10 12:18 AM

I'll look into this at the same time as the servlet 3 stuff during the coming weeks.

Show
Mike Wilson added a comment - 12/Jun/10 12:18 AM I'll look into this at the same time as the servlet 3 stuff during the coming weeks.
Hide
Permalink
Mike Wilson added a comment - 04/Jul/10 2:47 PM

Ok, so I've looked through most aspects of the "config 1" bug with IE8. The checkin that made IE8 update only every 60 secs was:
engine.js SVN rev 2747
David: you made this update and you mention several bugs that were fixed in this checkin. Could you recollect what was the particular problems with IE8 so I don't "unfix" the other bugs now?

Show
Mike Wilson added a comment - 04/Jul/10 2:47 PM Ok, so I've looked through most aspects of the "config 1" bug with IE8. The checkin that made IE8 update only every 60 secs was: engine.js SVN rev 2747 David: you made this update and you mention several bugs that were fixed in this checkin. Could you recollect what was the particular problems with IE8 so I don't "unfix" the other bugs now?
Hide
Permalink
Mike Wilson added a comment - 04/Jul/10 3:49 PM

Sorry, forgot to mention that I'm talking about the addition of an IE8 branch in:
if (batch.isPoll && dwr.engine.isIE < 8) { batch.map.partialResponse = dwr.engine._partialResponseNo; } else if (batch.isPoll && dwr.engine.isIE >= 8) { batch.map.partialResponse = dwr.engine._partialResponseFlush; }

Show
Mike Wilson added a comment - 04/Jul/10 3:49 PM Sorry, forgot to mention that I'm talking about the addition of an IE8 branch in: if (batch.isPoll && dwr.engine.isIE < 8) { batch.map.partialResponse = dwr.engine._partialResponseNo; } else if (batch.isPoll && dwr.engine.isIE >= 8) { batch.map.partialResponse = dwr.engine._partialResponseFlush; }
Hide
Permalink
Mike Wilson added a comment - 04/Jul/10 3:51 PM

David just replied by email:
I remember this coming out of a recommendation from someone on the mailing list: https://dwr.dev.java.net/servlets/ReadMsg?listName=users&msgNo=17076

Show
Mike Wilson added a comment - 04/Jul/10 3:51 PM David just replied by email: I remember this coming out of a recommendation from someone on the mailing list: https://dwr.dev.java.net/servlets/ReadMsg?listName=users&msgNo=17076
Hide
Permalink
Mike Wilson added a comment - 04/Jul/10 3:52 PM

Thanks David. This makes me think I still haven't covered all the important code as I thought mode Flush or No shouldn't make a difference in this case... hmmm. Maybe I spoke to soon about the cause of the problems - I'll look a bit more at this.

Show
Mike Wilson added a comment - 04/Jul/10 3:52 PM Thanks David. This makes me think I still haven't covered all the important code as I thought mode Flush or No shouldn't make a difference in this case... hmmm. Maybe I spoke to soon about the cause of the problems - I'll look a bit more at this.
Hide
Permalink
Mike Wilson added a comment - 06/Jul/10 3:25 PM

I have now verified (by running tests on SVN 2746 and 2747) that it was the changes in the SVN 2747 checkin that are causing the bugs, both (1) the pauses in IE8 and (2) FF "dying" after a while.

The first problem is the IE8 branching mentioned above that was changed because of IE8 problems reported on the mailing list. I can't reproduce that user's problems so I think either IE8 has changed since then, or that user had done some other local changes. The suggested changes definitely didn't work.

The second problem is due to the changes to Reverse Ajax retry policy, and effectively causes a timing bug that sometimes start several paralell polls, consuming the available connections.

Show
Mike Wilson added a comment - 06/Jul/10 3:25 PM I have now verified (by running tests on SVN 2746 and 2747) that it was the changes in the SVN 2747 checkin that are causing the bugs, both (1) the pauses in IE8 and (2) FF "dying" after a while. The first problem is the IE8 branching mentioned above that was changed because of IE8 problems reported on the mailing list. I can't reproduce that user's problems so I think either IE8 has changed since then, or that user had done some other local changes. The suggested changes definitely didn't work. The second problem is due to the changes to Reverse Ajax retry policy, and effectively causes a timing bug that sometimes start several paralell polls, consuming the available connections.
Hide
Permalink
Mike Wilson added a comment - 06/Jul/10 3:33 PM

I have checked in a fix for (1) by reverting to the SVN 2746 code for xhr.send.

Show
Mike Wilson added a comment - 06/Jul/10 3:33 PM I have checked in a fix for (1) by reverting to the SVN 2746 code for xhr.send.
Hide
Permalink
Mike Wilson added a comment - 06/Jul/10 3:42 PM

I have started looking at (2) and the changes relating to DWR-363 that is part of the SVN 2747 checkin.
David: I see in the ticket that you are questioning how to do the Reverse Ajax error handling. What did you settle on in the end? (so I know the plan when reading the code)

Show
Mike Wilson added a comment - 06/Jul/10 3:42 PM I have started looking at (2) and the changes relating to DWR-363 that is part of the SVN 2747 checkin. David: I see in the ticket that you are questioning how to do the Reverse Ajax error handling. What did you settle on in the end? (so I know the plan when reading the code)
Hide
Permalink
David Marginian added a comment - 06/Jul/10 4:15 PM

I believe the error handler will be called, I am just not sure it provides much utility as the retry policy is quite extensive and the handler may not be called for a long time.

Show
David Marginian added a comment - 06/Jul/10 4:15 PM I believe the error handler will be called, I am just not sure it provides much utility as the retry policy is quite extensive and the handler may not be called for a long time.
Hide
Permalink
Mike Wilson added a comment - 07/Jul/10 11:43 AM

In offline communication we decided that David will look into the poll timing bug. I will continue to look at "Config 2" (the Tomcat sleeper) and we will close this ticket when both problems are solved.

Show
Mike Wilson added a comment - 07/Jul/10 11:43 AM In offline communication we decided that David will look into the poll timing bug. I will continue to look at "Config 2" (the Tomcat sleeper) and we will close this ticket when both problems are solved.
Hide
Permalink
Mike Wilson added a comment - 07/Jul/10 11:48 AM

I should also mention that with a quick-and-dirty fix for the timing bug I've had IE6/7/8, Firefox, Safari, Chrome and Opera successfully run the Clock demo overnight in streaming mode (IE auto-switching to early-close of course due to browser limitations).

Show
Mike Wilson added a comment - 07/Jul/10 11:48 AM I should also mention that with a quick-and-dirty fix for the timing bug I've had IE6/7/8, Firefox, Safari, Chrome and Opera successfully run the Clock demo overnight in streaming mode (IE auto-switching to early-close of course due to browser limitations).
Hide
Permalink
David Marginian added a comment - 11/Aug/10 8:16 PM

Mike, I was in the Jetty code last night (making some fixes for Jeff on the mailing list). Anyway I took another look at the Tomcat Sleeper and noticed the issue. When resuming we were not calling close on the CometEvent.

Chris, can you grab the latest and help us test this? All of your issues should have been addressed.

Show
David Marginian added a comment - 11/Aug/10 8:16 PM Mike, I was in the Jetty code last night (making some fixes for Jeff on the mailing list). Anyway I took another look at the Tomcat Sleeper and noticed the issue. When resuming we were not calling close on the CometEvent. Chris, can you grab the latest and help us test this? All of your issues should have been addressed.
Hide
Permalink
David Marginian added a comment - 12/Aug/10 8:44 PM

Ok, I lied . We still have an issue with comet processor (number 2). I will continue to look into it.

Show
David Marginian added a comment - 12/Aug/10 8:44 PM Ok, I lied . We still have an issue with comet processor (number 2). I will continue to look into it.
Hide
Permalink
A J Sudharshan added a comment - 18/Jan/12 11:15 PM

Regarding the Second Test mentioned here, that is, DWR3RC1 + config2 (tomcat with "org.apache.coyote.http11.Http11NioProtocol" Connector and dwr Tomcat.DwrCometSupport Servlet.)

I tried to download DWR3RC1 from below links and non of the dwr.jar had the servlet class "org.directwebremoting.server.tomcat.DwrCometProcessor"

Download URL :
http://java.net/downloads/dwr/Version%203.0%20M1%20RC1/
http://java.net/downloads/dwr/Version%203.0%20M1/

Please let me know if I need to download the DWR3RC1 from elsewhere or am I missing something.

Show
A J Sudharshan added a comment - 18/Jan/12 11:15 PM Regarding the Second Test mentioned here, that is, DWR3RC1 + config2 (tomcat with "org.apache.coyote.http11.Http11NioProtocol" Connector and dwr Tomcat.DwrCometSupport Servlet.) I tried to download DWR3RC1 from below links and non of the dwr.jar had the servlet class "org.directwebremoting.server.tomcat.DwrCometProcessor" Download URL : http://java.net/downloads/dwr/Version%203.0%20M1%20RC1/ http://java.net/downloads/dwr/Version%203.0%20M1/ Please let me know if I need to download the DWR3RC1 from elsewhere or am I missing something.
Hide
Permalink
Mike Wilson added a comment - 19/Jan/12 1:07 AM

The version you're mentioning (3.0 M1 RC1) is quite old and the DwrCometProcessor hadn't been added yet. I recommend that you get the latest version from our download page (3.0.RC2) instead, see http://directwebremoting.org/dwr/downloads/index.html.

Show
Mike Wilson added a comment - 19/Jan/12 1:07 AM The version you're mentioning (3.0 M1 RC1) is quite old and the DwrCometProcessor hadn't been added yet. I recommend that you get the latest version from our download page (3.0.RC2) instead, see http://directwebremoting.org/dwr/downloads/index.html.
Hide
Permalink
David Marginian added a comment - 22/Nov/12 9:21 AM

I think we should be looking at implementing Servlet 3.0 async processing instead of trying to implement container specific APIs.

Show
David Marginian added a comment - 22/Nov/12 9:21 AM I think we should be looking at implementing Servlet 3.0 async processing instead of trying to implement container specific APIs.
Hide
Permalink
David Marginian added a comment - 22/Nov/12 9:42 AM

Please see DWR-590.

Show
David Marginian added a comment - 22/Nov/12 9:42 AM Please see DWR-590.

People

Dates

  • Created:
    07/Jun/10 1:45 PM
    Updated:
    22/Nov/12 9:42 AM
    Resolved:
    22/Nov/12 9:42 AM
Atlassian JIRA (v4.1.2#531) | Report a problem | Request a feature | Contact administrators
Powered by a free Atlassian JIRA open source license for DWR. Try JIRA - bug tracking software for your team.