[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [rap-dev] Feedback and questions from EclipseCon 2007 about RAP
- From: "Jochen Krause" <jkrause@xxxxxxxxxxxxxx>
- Date: Tue, 13 Mar 2007 22:18:53 +0100
- Delivered-to: email@example.com
- Thread-index: AcdhXNxmrkBdUSd+TYWo6H1rgGWLUwESGZgg
- Thread-topic: [rap-dev] Feedback and questions from EclipseCon 2007 about RAP
Thanks for asking those questions. We are still overwhelmed
by the positive feedback we received at EclipseCon ...
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.
- 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.
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.
- 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
BTW: What is the behaviour of the eRCP project, which
should have the same issue?
answer as above. eSWT uses the SWT namespace for implementing a
strict subset of SWT, not sure about eRCP.
- 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
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
- 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
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.
if you plan to build a community portal with 100 000 concurrent users you
should probably look for a different technology
- 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)
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
- 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
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
mentioned that you had a real good short tutorial about RAP at EclipseCon too,
with lack of time. Congrats.