On 25 Oct 2010, at 10:44, Ross Gardler wrote: > 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).
DWR is the component Wookie uses to implement Comet (reverse Ajax). It maps Java APIs to JavaScript that is injected in the widget. Node.js is a server that uses the Chrome JavaScript engine to compile and run server-side JavaScript applications using a novel event-driven IO model. Its really fast, but quite low-level. Its also very new (I think it started in February) and has few production deployments yet. However it does look very promising. Interesting blog posts from Plurk who used it for their Comet service: http://amix.dk/blog/post/19577#Is-node-js-best-for-Comet http://amix.dk/blog/post/19490 > 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? I have a few concerns: 1. We may simply have an issue with our configuration of DWR or Jetty, and we may be able bump the speed up to a more satisfactory level without major changes 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. >>
smime.p7s
Description: S/MIME cryptographic signature
