hi Ralf, I'd like to stress this point: *> I don't know much about RAP, but the kind of communication seems very > much client -> server -> client oriented. > CometD supports this case but also others (client -> server -> > broadcast to many clients), and of course also server -> client.*
*server-->client * This is the key for financial applications, ticking market data is what all City types want. And CometD does that very well, especially through WebSockets. Michele :) On 22 May 2013 14:27, Simone Bordet <[email protected]> wrote: > Ralf, > > On Tue, May 21, 2013 at 10:47 PM, Ralf Sternberg > <[email protected]> wrote: > > Hi Michele, Simone, > > > > could you explain how CometD could improve the performance in RAP? > > With CometD we have experienced that a big part of the overhead is the > HTTP protocol itself. > Long polling techniques scale up to a certain point. > Look at the benchmark results we obtained: > http://webtide.intalio.com/2011/09/cometd-2-4-0-websocket-benchmarks/ > The only difference was using WebSocket instead of HTTP. > > > What are the preconditions for employing CometD? For example, can > > CometD work with an existing servlet, or would it require that we use > > a servlet that comes with CometD? > > You will have to deploy the CometD servlet instead of your current RAP > servlet that manages the RAP Protocol. > > I think the change could be quite simple for you: you can keep your > RAP Protocol as it is, only it will be carried by CometD's Bayeux > protocol. > Now, it is true that wrapping RAP messages inside Bayeux messages is > an overhead, but you get WebSocket for free :) > Our experience however, was that JSON parsing was never an bottleneck, > so parsing a couple more fields should be irrelevant. > > All the rest of the RAP message processing could be the same. > I am imagining that now you have something like: > > JS (client) -- RAPMessage --> RAPServlet --> RAPService > > With CometD you will have: > > JS (client) -- BayeuxMessage(RAPMessage) --> CometDServlet --> RAPService > > I never tried to expose the CometD servlet via OSGi, but I know people > have done that, so it's not a problem. > > I don't know much about RAP, but the kind of communication seems very > much client -> server -> client oriented. > CometD supports this case but also others (client -> server -> > broadcast to many clients), and of course also server -> client. > > CometD offers you APIs for authentication & authorization, > disconnection detection, message batching, page reload, JSON library > pluggability, Spring integration, multiple sessions handling (two tabs > with same application), lazy messages (non-urgent messages delivered > on first occasion), server-to-client message acknowledgement, > automatic disconnection of inactive clients, a scalability clustering > solution to scale on multiple nodes called Oort, and much more, with > rich documentation and tutorials at http://docs.cometd.org. > > Note that CometD is a project based on Jetty, which also is under the > Eclipse umbrella (http://eclipse.org/jetty). > > Let me know if you have more questions (not subscribed to rap-dev). > > Thanks ! > > -- > Simone Bordet > http://bordet.blogspot.com > --- > Finally, no matter how good the architecture and design are, > to deliver bug-free software with optimal performance and reliability, > the implementation technique must be flawless. Victoria Livschitz >
_______________________________________________ rap-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/rap-dev
