I've just used the Jetty Restlet extension, which I believe uses Jetty 6.1. I'm not sure about the internals of the NIO mappings though. The new Grizzly server in 1.1 may be more appropriate for NIO.
Truthfully I've only used InputRepresentation connected to a stream that is reading/writing to our MogileFS storage system. We can pump out a couple hundred MB/s per instance with just that. In any case Restlet itself is rather neutral in its scalability offerings. Certainly using NIO will help if you can wrap your code to use it. Proper HTTP caching and server statelessness will give you a lot in itself. .. Adam On Thu, Mar 6, 2008 at 8:53 AM, Jon Blower <[EMAIL PROTECTED]> wrote: > Thanks Adam, > > Do you need to use a particular version of Jetty to support NIO? I'm > hazy on Jetty details, but do I understand correctly that if you use > NIO then you won't use Jetty's servlet framework but you'll access > Jetty at a lower level? > > Good news that you've achieved good scalability. Did you try both > ChannelRepresentation and InputRepresentation and if so did you notice > a difference? > > Cheers, Jon > > > > On Thu, Mar 6, 2008 at 4:27 PM, Adam Rosien <[EMAIL PROTECTED]> wrote: > > At Sharpcast we use Restlet+Jetty as a front-end for our storage > > platform and found it to be quite scalable. The basic technique is to > > wrap your generated data into a Representation (for example, as a > > ChannelRepresentation for NIO or InputRepresentation for an > > InputStream) and return it from your getRepresentation(Variant) method > > of your Resource (the method is called represent(Variant) in 1.1). > > Restlet and Jetty will handle the threading issues which you can tune > > separately. > > > > .. Adam > > > > > > > > On Thu, Mar 6, 2008 at 7:14 AM, Jon Blower <[EMAIL PROTECTED]> wrote: > > > Dear all, > > > > > > We have an existing RESTful web application that involves clients > > > downloading multiple streams of data simultaneously. Our current > > > implementation is based on servlets and we are experiencing > > > scalability problems with the number of threads involved in serving > > > multiple large data streams simultaneously. I recently came across > > > Restlet and was attracted by the potential to use NIO under the hood > > > to enable more scalable large file transfers. > > > > > > In our case we are not necessarily serving large files that already > > > exist on disk: we are essentially creating the files ourselves on the > > > fly (so they are of unknown length when the file transfer starts). I > > > was wondering if anyone could offer advice on how to support the > > > serving of such data streams through Restlet in a scalable manner > > > (ideally without creating a new thread on the server for each file > > > transfer)? > > > > > > Thanks in advance, > > > Jon > > > > -- > -------------------------------------------------------------- > Dr Jon Blower Tel: +44 118 378 5213 (direct line) > Technical Director Tel: +44 118 378 8741 (ESSC) > Reading e-Science Centre Fax: +44 118 378 6413 > ESSC Email: [EMAIL PROTECTED] > University of Reading > 3 Earley Gate > Reading RG6 6AL, UK > -------------------------------------------------------------- >
