It *should* use Comet as the wave.js file calls:
dwr.engine.setActiveReverseAjax(true);
... which should tell DWR to use Comet rather than polling.
Plus DWR is configured in web.xml with:
<init-param>
<param-name>activeReverseAjaxEnabled</param-name>
<param-value>true</param-value>
</init-param>
For me, Reverse-Ajax is one thing, the communication mode is another.
DWR is configured for Reverse-Ajax - clear to me. But, my widgets
definitely are polling to receive updates from Wookie (and I haven't
touched the significant parts in web.xml, so I just use it as delivered
with Wookie). If I open Firebug I clearly see the polling requests.
Every interval [WOOKIE]/wookie/dwr/call/plainpoll/ReverseAjax.dwr is
called to see if there are new updates.
In my web.xml there are also the lines
<init-param>
<param-name>org.directwebremoting.extend.ServerLoadMonitor</param-name>
<param-value>org.directwebremoting.impl.PollingServerLoadMonitor</param-value>
</init-param>
which are telling DWR to use polling instead of, e.g. a long-held HTTP
response (aka Comet).
If I delete those lines Comet style is used and the communication is
really fast (to me as fast as Node.js in you video). Again checking with
Firebug I can see that now an HTTP response is held open. All this is
described in the URL you mentioned below (see Polling Mode section):
More info at: http://directwebremoting.org/dwr/reverse-ajax/configuration.html
I have set an interval of 2.5 sec for polling by inserting the following
lines:
<init-param>
<param-name>disconnectedTime</param-name>
<param-value>2500</param-value>
</init-param>
Default poll rate is 5 sec.
2. Running an additional two services is a pain, and shouldn't be done unless
it really is strictly necessary. For example, with the code I've developed you
end up running:
- Node.js
- Redis
- Jetty
- Derby
... with relational data stored in Derby and tuples stored in Redis. Its
certainly a more complex deployment than we have at present.
3. Integrating participants is less trivial than state data, and would not
necessarily have any performance benefit
4. The benefits may be entirely due to websockets vs comet, in which case a
websockets implementation in DWR would be the easiest path. However, I haven't
seen a lot of discussion of websockets on the DWR lists.
Alternatively, Jetty has WebSockets support as of V7.0.1. However, I'm not
aware of any implementation for Tomcat.
Note I'm not suggesting we commit the code now, so close to a release, but
perhaps immediately after the release?
With respect to performance issues, maybe we should make it a priority to do
some profiling for the next release?
Agreed, I'd be wary of jumping to conclusions until we've identified where
performance issues occur.
If we do add profiling we could do the node.js in a branch and compare results
before merge. That might help us see where poor Wookie performance is being
masked by improved node.js performance.
Sounds good to me.
Sent from my mobile device.
On 25 Oct 2010, at 09:07, "Scott Wilson (JIRA)"<[email protected]> wrote:
[
https://issues.apache.org/jira/browse/WOOKIE-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12924490#action_12924490
]
Scott Wilson commented on WOOKIE-155:
-------------------------------------
I built the experimental functionality into a "NodeWave" feature that can be
used instead of the existing DWR-based feature and tried it out with some widgets. I'm
not surprised that using Node.js+Redis+WebSockets was very, very fast (duh!) but am a bit
concerned that DWR+Comet is surprisingly slow.
I wonder which part of Wookie might have a performance issue? It could be any
one of Comet/DWR, Jetty, the Wookie server code itself, JPA or Derby.
Experimental setup for shared data using websockets, node.js and redis
----------------------------------------------------------------------
Key: WOOKIE-155
URL: https://issues.apache.org/jira/browse/WOOKIE-155
Project: Wookie
Issue Type: Improvement
Components: Server
Reporter: Scott Wilson
Priority: Minor
Attachments: chat_dwr_vid.swf, chat_node_vid.swf, wavenoderedis.zip
This is an experimental setup that simulates replacing the DWR-based
functionality of Wookie's Wave API implementation with one using Node.js,
WebSockets, and Redis. The key motivation behind this experiment is to see how
much more responsive Wookie shared state widgets can be using a fast Websockets
implementation instead of Comet on a typical Java server stack.
To try it out, you need to install Node.js and the SocketIO websockets
implementation. You also need to run a Redis server. This file contains the
server-side logic.
To run the example:
1. Start your redis server on the default port using:
./redis-server
2. In the folder you unzipped the code into, type:
node server.js
3. In your browser (Safari and Chrome work well) open each of the testx.html files. Test
and Test2 share the same SharedDataKey whereas Test3.html does not. Type in key:value
pairs in the text boxes to send deltas to the wave state, and see them updated in other
"widget instances".
Note the example is incomplete as it only handles state, not viewer or
participants
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
