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 09:58:56 GMT
Hi Vassil,
Sorry, it was not clear to me that  real time is a key differentiator for
ESME, and it's already build around it.
I'm just saying, that you shouldn't expect that this scales easily to
thousands of users( maybe it doesn't need to) without special Web container
support. That might not even be a problem AFAIK besides Jetty, Tomcat has it
and Glassfish 3 probably has it as well.

>From the REST API point of view I don't think there's much to do, other than
appending something to the URL that indicates that connection needs to be
 kept open for COMET style communication.

One point that the REST API probably needs to support is a way for not
always connected clients to "sync" only new messages.

Googles gdata does this with etags:,
which make sense to me, at least at a first glance.


On Wed, Nov 4, 2009 at 10:05 AM, Vassil Dichev <> wrote:

> > 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.
> I've also said before that pagination is great to have, but "real time
> messages, such as in a chat" are not a goal, they exist in ESME right
> now, and ESME design revolves around that.
> > 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.
> True. That's one excuse we don't have that many tests. I'd like to
> think it's the major one, but unfortunately it's not.

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