Issue Details (XML | Word | Printable)

Key: DWR-191
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Joe Walker
Reporter: Ron Bernard
Votes: 0
Watchers: 1
Operations

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

CLONE -Reverse Ajax fails in IE when no output for over 60 seconds

Created: 08/Feb/08 01:18 AM   Updated: 29/Feb/08 10:29 AM   Resolved: 08/Feb/08 08:42 AM
Component/s: core
Affects Version/s: None
Fix Version/s: 2.0.3


 Description  « Hide
I have been trying to get DWR working with our application for over a week now and have reached a dead end. If I use DWR in Full Streaming Mode, the output to the browser is delayed by up to 60 seconds. If I use DWR in Early Closing Mode, I can control the output delay, but if there is no output to the browser for longer than 60 seconds, I get a NullPointerException after which no outputs ever go through. After adding some debug code in the DWR source I printed the following stack trace:
 
org.directwebremoting.util.CommonsLoggingOutput warn
WARNING: Error: java.lang.NullPointerException
 at org.directwebremoting.dwrp.OutputAlarm.cancel(OutputAlarm.java:68)
 at org.directwebremoting.dwrp.PollHandler$1.run(PollHandler.java:185)
 at org.directwebremoting.dwrp.ThreadWaitSleeper.goToSleep(ThreadWaitSleeper.java:43)
 at org.directwebremoting.dwrp.PollHandler.handle(PollHandler.java:207)
 at org.directwebremoting.servlet.UrlProcessor.handle(UrlProcessor.java:101)
 at org.directwebremoting.servlet.DwrServlet.doPost(DwrServlet.java:146)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.directwebremoting.faces.FacesExtensionFilter.doFilter(FacesExtensionFilter.java:79)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
 at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
 at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
 at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584)
 at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
 at java.lang.Thread.run(Unknown Source)
 
None of the examples provided deal with this issue as they are all invoked by the web browser, with the exception of the Clock demo. However, the clock demo sends an output to the browser every second, thus it never encounters the error. Once I adjusted the clock output to once every 90 seconds, for example, the same error occurred. This leads me to believe that the only way to prevent the error from occurring is to send something to the browser every few seconds. But I was under the impression that DWR in Early Closing Mode would close the connection, then request for it to be re-opened, so it would take care of everything behind the scenes.
 
Our application is using Tomcat 6 with JSF and Spring, which the examples do not cover, so there is a possibility I did not configure things correctly. If you would be kind to help, I would be happy to send any of the source code for you to review. I thank you for your patience in advance.

Sort Order: Ascending order - Click to sort in descending order
Ron Bernard added a comment - 08/Feb/08 01:30 AM
We have very similar issue. DWR does not seem to be reestablishing the HTTP connection after it is closing it. Are there any fixes for this on the horizon?