Hi there, Thanks for the interesting questions. Replies inline:
> Hello. Would you please explain me or point to a guide how to > use an advantage of NIO with Restlet. Currently the Restlet API has provisions for the NIO in the org.restlet.resource.Representation class and subclasses. The release 1.0 of Restlet doesn't fully leverage this NIO methods. We only have support for Jetty 6.1 with has an NIO NB mode usable. However, there is active work going on for Restlet 1.1 in the form two connectors based on Grizzly NIO framework, one HTTP client and one HTTP server. See details at: http://restlet.tigris.org/issues/show_bug.cgi?id=16 We are also considering adding MINA based HTTP connectors ASAP. See details at: http://restlet.tigris.org/issues/show_bug.cgi?id=292 > I have digged the following information only. > If we 're going to use an NIO processing of the web client > request/response we > need to use: > 1) the Reactor pattern, mainly to deal with the great number > of connections ( > so using Readiness selection, the transformation of > connection/request to event > and placing event in a queue, using a high-performance > bounded thread pool to > transmit an event to user-level code to process). This part > could be named as > asynchronized topic of NIO Web Server. We also have a short term plan to make the Restlet Request/Response API fully asynchronous. This should be easy to do due without breaking existing apps: http://restlet.tigris.org/issues/show_bug.cgi?id=143 > 2) the non-blocking IO, just to not suspend any thread from > thread pool if an > blocking of processing occurs while an read/write to client socket. > > The both features need to be realized by front-end server. > Restlet is the > framework that placed behind it, so it needs to provide > 1) a special thread pools / resources pool to efficiently > works with user-level > code processing an request / response event queue. Right, this is the responsibility of Server connectors in the Restlet architecture. > 2) may be an extension to expose an underlying server API > if one would use > some special direct tricks / features. Could you clarify this point? > 3) a set of function that could be worked in non blocking > manner with underlying non blocking server api. Could you clarify this point too? > We're free use Restlet either standalone (direct call to > org.restlet.Component#start()), or in Servlet Container. > > You're proposing the following connectors: > 1) AsyncWeb (based on MINA general nio server) > 2) Jetty (own development of nio) > 3) Simple > 4) Grizzly (java5ee nio http server implementation and > there exists an prototype of grizzly front-ending of jetty) There is also a working standalone Grizzly HTTP server connector in SVN trunk that will ship with Restlet 1.1! > 5) Plan to work with custom reimplementation of MINA-based > nio http server, more > integrated with the restlet than what you have got with > AsyncWeb one, right? Exactly. > So the actual ext connectors propose for end-users 1) ability > to exploit Reactor > pattern realized by these servers. 2) hook to the concrete > implementation server > API. Am I right that you share some resources (pools) with > the underlied server > resources? If yes, then concrete ext-connectors serve this > performance issue as well. There are actually two types of connectors, some that have there own Request/Response API that we convert to the Restlet API (Jetty, AsyncWeb, Simple) and some that directly use the Restlet API (in SVN trunk only: built-in BIO StreamServer and NIO NB Grizzly server). > The concrete non blocking support is given with the help of > 2 methods (read > from ReadableByteChannel, write to WritableByteCHannel) of > org.restlet.data.Representation class. True. > So if we're going to use an NIO advantage we need to switch > on an Reactor > support from the server (HttpServerHelper type = 1), and use > the above methods > to transfer information in both side. Do we need to care on > smth else on the > restler level? We also need to ensure that all the Representation subclasses properly behave when used via the NIO methods (FileRepresentation for example) and that conversion from BIO to NIO works too. Most of the code is done already. There is opportunity to help here by testing, providing test cases and contributing patches. > What does the class JettyCall stand for? It is a lower-level class wrapping both a request and a response. It is a subclass of HttpServerCall which can be converted to higher level o.r.d.Request/Response instances. It enables a lot of code sharing all connectors. > What do we actually need to do to start application with nio > support? Just > having an restlet, noelios, ext deployed with appl as > servlet to container? For Jetty, you can configure which type of Jetty connector to use. See Javadocs of com/noelios/restlet/ext/jetty/HttpServerHelper for details. See also: http://www.restlet.org/documentation/1.0/connectors#jetty > Doesn't the working in servlet container break an NIO > support? It doesn't break it, but the NIO support doesn't go from the socket to the Representation class, it stop at the Servlet API level, the rest is in BIO mode. So far, only the Grizzly HTTP server has full end-to-end NIO support with Restlet. > Is it possible to > start the restlet in standalone mode with nio support? What's > the preferable way > standalone or container-based ( means, if the standalone is > allowed, could we > expect that standalone mode would propose an little servlet > functionality so > show greater performance) Yes, it is possible. The best performance should be with Jetty connector. The Grizzly connector in trunk has the potential to provide significantly better perf but hasn't been benchmarked yet. It doesn't support persistent connections yet, which may impact its perf. > Thanks and sorry for the lack of knowledge in area. You're welcome, and honestly you seem to be very knowledgable already!! Best regards, Jerome
