Hi all, The Jetty connector is the most robust one for now. I would recommend it for production and scalability purpose. The Jetty connector itself can be configured in different NIO/BIO modes. See this page for details: http://www.restlet.org/documentation/1.1/connectors#jetty
Concerning the Jetty-Restlet mapping, it doesn't include the Jetty Servlet container layer but rely on the lower level Jetty Handler interface. As this interface reuses the Servlet request/response artifacts, we do communicate via BIO streams with it. The new Grizzly connector is the only one to support NIO from the Representation to the socket. Our initial tests showed that it is extremely fast when doing direct file to socket transfers (without going through the JVM). With Grizzly, the Representation.write(WritableByteChannel writableChannel) method is called in the end with the SocketChannel as parameter. Note that we still do chunked encoding by going through a BIO 'tunnel'. Best regards, Jerome > -----Message d'origine----- > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De > la part de Adam Rosien > Envoyé : jeudi 6 mars 2008 19:28 > À : discuss@restlet.tigris.org > Objet : Re: Streaming multiple large data files through Restlet > > 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 > > -------------------------------------------------------------- > >
