Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rap-dev] Feedback and questions from EclipseCon 2007 about RAP
Hi Jochen,
 
many thanks for your detailled answers. Your answers are now available to community at all.
 
I am looking forward about future development of RAP. Cool approach.
 
Bye, Jochen

 
On 3/13/07, Jochen Krause <jkrause@xxxxxxxxxxxxxx > wrote:
Hi Jochen,
 
Thanks for asking those questions. We are still overwhelmed by the positive feedback we received at EclipseCon ...

From: rap-dev-bounces@xxxxxxxxxxx [mailto: rap-dev-bounces@xxxxxxxxxxx] On Behalf Of Jochen Hiller
Sent: Thursday, March 08, 2007 9:36 AM
To: rap-dev@xxxxxxxxxxx
Subject: [rap-dev] Feedback and questions from EclipseCon 2007 about RAP

 
Hi RAP folks,

there have been at EclipseCon two short tutorials about Server-Side Eclipse. The second one also covered the Rich AJAX Platform (RAP).

The participants have been quite interested about the RAP stuff. They raised up some interesting questions, which I would like to post to RAP mailing list, as they could be of interest for more developers.
  1. Why do you not try to achieve binary compatibility between the RWT and the SWT API? The namespace could be the same, but the implementation deployed in RAP specific bundles instead.  
We had a discussion about that topic at EclipseCon with Steve and we might be moving to the org.eclipse.swt namespace - but this is not yet finally decided. We will keep you posted on this.  

 
  1. Why did you choose for extension points of RAP workbench , views, ... a different namespace than in Eclipse Workbench? If you try to migrate from an RCP to an RAP application, this may result in a relevant amount of refactoring work.
    BTW: What is the behaviour of the eRCP project, which should have the same issue? 
Same answer as above. eSWT uses the SWT namespace for implementing a strict subset of SWT, not sure about eRCP. 

 
  1. Which kind of Eclipse theme will be used for rendering? Is there a way how additional themes (e.g. contributed ones) could be added?  
Theming support (Presentations API) is not yet implemented, but we are aware of the fact that this is an important topic. Everybody keeps asking about this and most people do not feel comfortable with a "windows" theme for a web application. The qooxdoo library offers a single configuration for influencing the theme ( DefaultAppearanceTheme.js in RWT), but as theming can have an impact on the size of the client area it is not trivial to implement. WorkbenchWindowAdvisor customizations are possible.
W e would welcome if someone came up with a none windows like DefaultAppearanceTheme and provide that to RAP (and qooxdoo). We are happy to engage in a discussion about this.
 
  1. Do you have yet experiences with scalability? Especially considering memory consumption (workbench per session) and workload for server side rendering. There have been concerns about scalability discussed during tutorial.   
We have a lot of experience with that topic from more than 5 years of W4T. Here are some first stress test results. We stress tested a simple workbench with a couple of views and tables. With 500 concurrent users accessing the application every 5 seconds we had average response times (in a gigabit lan) of 17 ms. The VM was configured with 500 MB of heap, but only used an average of 120 MB maxing at 180 MB. We still had an average response time below 30 ms in a scenario with 1000 concurrent users accessing every 5 seconds. Hardware was a standard Intel Core 2 Duo (TM) based system.
 
But if you plan to build a community portal with 100 000 concurrent users you should probably look for a different technology ;-) 
 
  1. A RAP application must be AFAI understand always be session sticky (e.g. assigned by a load balancer). As the workbench state will be stored within HttpSession, I assume the size of the session has a relevant size. This makes session clustering (when hosted in an external application server) probably inefficient.   
 You are right about the sticky sessions. The size of the session will vary with the complexity of the UI (example above was less then 200 KB), and we can not offer session clustering as this requires serializable objects. Having said all this, it is from our experience often a much bigger problem to cope with the business logic layer if you have a large number of concurrent users. In the example above, if you have anything serious going on in the business layer, it will hardly be responding reasonably with a load of 1000 users accessing every 5 seconds on this kind of hardware. And you can scale RAP very easily horizontally with standard apache and tomcat installations - only without failover support.
 
  1. Again about clustering: Do you have any experiences using RAP with session clustering hosted with the servlet bridge? Simon Kaegi mentioned at EclipseCon, that classes and libraries required for session replication have to be made available primarily at bridge, and made public to available to OSGi runtime platform. May be very complex, as RAP will store workbench state in session, which could lead to references to some (log) of RAP classes.   
Clustering is not available. If someone is seriously interested in clustering and willing to invest time -  just wave your arms.

Thanks in advance for any help, Jochen

PS: Participants mentioned that you had a real good short tutorial about RAP at EclipseCon too, with lack of time. Congrats.   
 
Thanks,
 
Jochen 

_______________________________________________
rap-dev mailing list
rap-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rap-dev


Back to the top