Scott, I've not run this experimental code, however, I am following your work. It sounds really interesting. I confess to not knowing much about either DWR or node.js (other than the latter is attracting lots of attention).
What strikes me from your comments on thus work is that it seems to be z no-brained. But since you've opted to go with RTC on this I'm wondering what the potential drawback is. Why not just commit it? What is your primary concern? 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? 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. 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. >
