esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Kohler <>
Subject Re: Patch submitted, working towards API design
Date Wed, 04 Nov 2009 08:43:26 GMT
Hi Vasil,
Yes. Scala Actors can certainly abstract away the implementation details,
but I assume it would still rely on the Servlet API. The features
for efficiently supporting Comet are coming with version 3.0, and that is
not yet implemented in most J2EE containers. Abstracting away whether the
client needs to do polling or uses Comet could probably be done, but would
require the use of a client library. I guess that is currently not in the

I understand that it would be nice to show  Scala advantages, but if real
time messages, such as in a chat are not the first goal, I would rather
concentrate on supporting pagination. Just my humble opinion of course.

Oh and BTW properly (performance) testing Comet based applications turned
out to be an up hill battle. I'm still convinced that I can deliver
something, but it will take more time. The issue is that "standard" load
testing tools such as Loadrunner or JMeter are based on the assumption that
you just want to replay short HTTP requests. That approach doesn't really
work with Comet based apps because they hold a connection open.


On Wed, Nov 4, 2009 at 8:28 AM, Vassil Dichev <> wrote:

> > - "Streaming" as far as I understand is about "push" functionality.
> > I would not go as far as to say "polling is bad". Since twitter is not
> real
> > time ESME would maybe not need to be real time as well. This means one
> could
> > poll infrequently (every few minutes?) using conditional GET's, which
> would
> > not be that inefficient. Comet has the disadvantage that without special
> > server support (available in Jetty, but not in Netweaver CE for example)
>  it
> > causes a lot of threads to be created on the server, which is also not
> > really efficient.
> Just wanted to comment on threading- the advantage of using Scala is
> that the actor model is not necessarily associated with one thread per
> request. When using "react", there doesn't have to be a thread backing
> each actor. Also, using Lift's CometActor is a nice abstraction which
> I can imagine could even transparently implement HTML 5 WebSockets one
> day without significant changes to the client code.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message