Reverse Ajax works 2 basic modes, Active and Passive. Active Reverse Ajax can be broken down into 3 modes:
This page describes these modes, when they make sense, and how to configure them. This documentation is valid for DWR version 2.0 (and above). Reverse Ajax is not available for DWR 1.x.
This is the default mode when Active Reverse Ajax is turned on. It has the fastest response characteristics because it closes connections only once every 60 seconds or so to check that the browser is still active. It is configured simply by telling the server to allow Active Reverse Ajax using a WEB-INF/web.xml init-param inside your DwrServlet:
<servlet>
<servlet-name>dwr-invoker</servlet-name>
<servlet-class>org.directwebremoting.servlet.DwrServlet</servlet-class>
<init-param>
<param-name>activeReverseAjaxEnabled</param-name>
<param-value>true</param-value>
</init-param>
</servlet>
You also need to request Active Reverse Ajax from a web page:
dwr.engine.setActiveReverseAjax(true);
With a large number of connections held open, it is possible to thread starve an application server. Several web servers have a special mode to allow users to drop threads. DWR makes use of this functionality in Jetty with version 2.0, from version 3.0 we expect to expand this to include GlassFish and Tomcat. DWR also attempts to protect all servers by dynamically reducing the connected time and increasing the disconnected time if the server load gets too high.
The problem with full streaming is that it requires HTTP chunked mode which sometimes fails with network proxies, mod_jk, and other network scanners. If you try full streaming and find that messages are only getting through every 60 seconds, this could be why. DWR version 2.0.3 and before used this as the default. From version 2.0.4 the default is to use Early Closing Mode.
To enable Full Streaming Mode in DWR from version 2.0.4 onwards, use the following init-param:
<init-param> <param-name>maxWaitAfterWrite</param-name> <param-value>-1</param-value> </init-param>
DWR has special support for the Comet features in Jetty and Tomcat. The Jetty support is automatic, no special configuration is needed. For Tomcat you need to regester a special version of the DwrServlet as follows:
<servlet> <servlet-name>dwr-invoker</servlet-name> <servlet-class>org.directwebremoting.server.tomcat.DwrCometProcessor</servlet-class> ... </servlet>
In Early Closing Mode, DWR holds connection open as it did in Full Streaming Mode, however it only holds the connection open for 60 seconds if there is no output to the browser. Once output occurs, DWR pauses for some configurable time before closing the connection, forcing proxies to pass any messages on. To use Early Closing Mode in DWR 2.0.4 and onwards, no configuration is needed. For 2.0.3 and before, you need an init-param to configure the delay between first output and connection close.
<init-param> <param-name>maxWaitAfterWrite</param-name> <param-value>500</param-value> </init-param>
In this case DWR will keep the connection open for an additional 500 milliseconds after the first output in case there is additional output, before forcing a flush by closing the connection and requesting it to be re-opened.
The default is -1, which means keep the connection open for a maximum of 60 seconds as described in Full Streaming Mode.
The downside of Early Closing Mode is that for applications with a high rate of output, it can cause a large hit count. This can be countered by increasing the pause by setting maxWaitAfterWrite=1000 or similar.
In applications with a large number of connected browsers that are simultaneously sent a message they are likely to all try to reconnect at the same time. If you are affected by this type of problem, then you should consider investigating Full Streaming Mode.
A future version of DWR might attempt to automatically detect buggy proxies.
If it is deemed unwise to hold connections open at all then DWR can use polling mode. In addition to the activeReverseAjaxEnabled=true init-param you should specify the PollingServerLoadMonitor as follows:
<init-param> <param-name>org.directwebremoting.extend.ServerLoadMonitor</param-name> <param-value>org.directwebremoting.impl.PollingServerLoadMonitor</param-value> </init-param>
In polling mode the default poll rate is every 5 seconds. This can be customized using the following:
<init-param> <param-name>disconnectedTime</param-name> <param-value>60000</param-value> </init-param>
The example above will poll only once every 60 seconds (60,000 milliseconds). For many applications a response time of 60 seconds will be enough, and will allow a web server to handle a very large number of clients.
There is a bug, fixed in DWR 2.0.2 where this parameter is badly mis-spelt. If you are using a version of DWR before 2.0.2 then you should use timeToNextPoll in place of disconnectedTime. The old spelling is deprecated rather than removed, however it will be removed in future releases.
Passive Mode is the default if none of the options above are enabled. In passive mode, browsers do not make any extra connections to the web server. DWR queues data at the server in order to pass it on to clients. This transfer method is also known as the piggyback technique.
Passive Mode is the least responsive, however it does not place any extra load on the web-server.