Re: [jetty-users] Vert.x-like functionality in Jetty?

[Jesse McConnell <jesse.mcconnell@xxxxxxxxx>]

Not to mention two of the systems you call out in your signature, Solr
and Hdfs, use jetty (solr as part of a distro I think and hdfs as the
http server used to serve ranges of files around down in its guts)

google app engine and gwt uses jetty under the covers as well...

but your on a jetty mailing list so...you will get responses biased
towards jetty :)

jesse

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx


On Thu, May 24, 2012 at 5:04 PM, Coda Hale <coda.hale@xxxxxxxxx> wrote:
> Jetty's SelectChannelConnector can manage ~200K connected clients
> fairly easily. You can use Jetty's continuations API (or the
> equivalent in Servlet 3.0 w/ Jetty 8+) to allow idle connections to be
> parked efficiently.
>
> This is what CometD does, and it's currently handling ~100K connected
> clients in production at Yammer.
>
> (It's also worth noting that even a thread-per-connection model on a
> modern Linux system with a large heap can handle hundreds of thousands
> of concurrent connections. It's less memory efficient, but it's still
> very doable.)
>
> On Thu, May 24, 2012 at 2:32 PM, Otis Gospodnetic
> <otis_gospodnetic@xxxxxxxxx> wrote:
>> Thanks Simone,
>>
>> I think Vert.x has more than just a spike of tweets, though :)
>>
>> What I'm after is something that can handle a high number of concurrent connections from an HTTP client (e.g. Apache HttpClient) to an HTTP server (Jetty?).  You can see in my sig why I'm interested in this....
>>
>> Thanks,
>> Otis
>> ----
>> Performance Monitoring for Solr / ElasticSearch / HBase - http://sematext.com/spm
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: Simone Bordet <sbordet@xxxxxxxxxxx>
>>> To: Otis Gospodnetic <otis_gospodnetic@xxxxxxxxx>; JETTY user mailing list <jetty-users@xxxxxxxxxxx>
>>> Cc:
>>> Sent: Thursday, May 24, 2012 5:16 PM
>>> Subject: Re: [jetty-users] Vert.x-like functionality in Jetty?
>>>
>>> Hi,
>>>
>>> On Thu, May 24, 2012 at 8:59 PM, Otis Gospodnetic
>>> <otis_gospodnetic@xxxxxxxxx> wrote:
>>>>  Hi,
>>>>
>>>>  Are you saying CometD provides the same scalability and concurrency Vert.x
>>>>  claims to provide?
>>>
>>> Look carefully at the Vert.x benchmark: they open 6 (six) connections
>>> and pipeline on each 2000 requests.
>>> How realistic is such traffic ?
>>>
>>> I am sure Vert.x 1.0 is a fine framework and all that, but I'd like to
>>> see a more realistic benchmark before expressing an opinion.
>>> That is what we tried to achieve with the CometD benchmark, which
>>> implements a chat application, with 1k, 5k 10k up to 200k connected
>>> users to a single server and different message rates.
>>>
>>>>  If CometD provides (and has been providing for years) the high scalability
>>>>  and concurrency support, what's all Vert.x all about?
>>>
>>> Ask them :)
>>> To me, it's about diversity.
>>> Why there exist more than one servlet container ?
>>>
>>>>  Is it the case that
>>>>  while CometD may provide the same stuff Vert.x does, CometD is not widely
>>>>  known or is at least not as popular? (if so, that can be critical for its
>>>>  future)
>>>
>>> Not sure what Vert.x provides yet (have not looked in details), but
>>> CometD provides authentication hooks, fine-grained access control,
>>> message acknowledgment and guaranteed server-to-client message
>>> delivery on short network failures, a fully extensible framework,
>>> transport independence and fallback, automatic reconnections, and I
>>> can continue for a while.
>>>
>>> I heard about Vert.x one month or less ago, actually, so I personally
>>> do not classify it as "popular" just because it had a spike in tweets.
>>>
>>> Evaluate both frameworks and choose the one that fits your case better.
>>>
>>> You have not said what is it in Vert.x that appeals you. It's just the
>>> benchmark result ?
>>>
>>> Simon
>>> --
>>> http://cometd.org
>>> http://intalio.com
>>> 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
>>>
>> _______________________________________________
>> jetty-users mailing list
>> jetty-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
>
>
> --
> Coda Hale
> http://codahale.com
> _______________________________________________
> jetty-users mailing list
> jetty-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-users