Re: [rap-dev] RAP & CometD for real time web (Ralf Sternberg)

[Ralf Sternberg <rsternberg@xxxxxxxxxxxxxxxxx>]

Hi Simone, Michele,

thanks for your explanations. It's an interesting topic. I'm not sure
if the performance improvement has such a big impact for RAP - the
benchmarks you referred to consider a server load orders of magnitude
higher than what a typical RAP server deals with. However, combining
the RAP protocol with CometD would probably open up interesting
possibilities for applications.

As I see it, RAP cannot build directly on Bayeux/CometD, as it is
designed to work in many different environments and does not depend
specifically on Jetty. But a CometD bridge could well be implemented
as a plug-in that applications can use to take advantage of CometD's
extra features.

There is some preparation required to open up the framework for such
alternative transport implementations. We'll discuss that direction in
our planning for RAP 2.2.

Best regards,
Ralf


On Wed, May 22, 2013 at 2:27 PM, Simone Bordet <simone.bordet@xxxxxxxxx> wrote:
> Ralf,
>
> On Tue, May 21, 2013 at 10:47 PM, Ralf Sternberg
> <rsternberg@xxxxxxxxxxxxxxxxx> 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