You're right that this is an area currently getting a lot of study. I don't know that Restlet currently has anything that doesn't rely on one thread per client connection. HttpClient 3.x doesn't offer any value adds there, and the basic java.net client is intentionally quite unsophisticated.
For GWT integration purposes, I'm researching good ways of supporting asynchronous client responses in the XmlHttpRequest style, using callbacks, which is tangentially of interest to the client scalability problem. A client (e.g. HttpCore 4.0) using something like the reactor pattern with thread pools would notionally open NIO channels for each outgoing connection, then have a pool of worker threads interacting with the channels to dispatch stages in response handling; at least the last of these -- representing response completion -- would land in Restlet high-level code, but likely in a different thread from the code that initialized the request. The current general idea is to expand the API with something like this: Future<?> handle(Request request, Response response, ResponseCallback callback); where the ResponseCallback object is invoked at least at response completion -- perhaps incrementally as stages of the response are delivered, or when there is new data to read, etc. To my mind this is the most open question in the design at present, and maybe one that can be pushed off till later. The critical path for my present problem involves a callback: (1) in a different thread (2) when the response is completely ready to be processed. Thus, for my project, the callback is called exactly once, representing failure or completion, following the usual GWT idiom. As it turns out, this is not especially difficult to achieve. (Well, sort of. It will work, but not be correct or reliable, unless Request and Response and the objects reachable therefrom are thread-safe. Which is more challenging.) But I think to meet the objectives that people have asked to support the Comet style (long lived request/response cycles) or to incorporate what John Fallows advanced here: http://www.mail-archive.com/discuss@restlet.tigris.org/msg03374.html -- the callback may need to be something that happens 1..n times, triggered incrementally as more response data becomes available. I haven't really thought about that dimension too much yet. Sorry if that's too much detail. The net takeaway is, if we can land a reasonably well thought out callback approach in Restlet 1.2, the project will be in very good shape to take advantage of a lot of interestingly multithreaded I/O architectures. Until then, there is still an inherent presumption that handle(request,response) happens in a single thread. Still, even thus limited, Restlet has great scalability properties, and I recommend using it anyway. It would be very cool if you could share more information about your use case and contribute to or help test some of the work on asynchronous callbacks. It's not a small undertaking. - Rob On 2/17/08, Aaron Crow <[EMAIL PROTECTED]> wrote: > > Is there a simple way for Restlet client code to handle multiple > simultaneous connections in a highly scalable fashion? What I mean is, > when > my Restlet code turns around to become a client, I need it to actually > make > a handful of requests, each to a different server. For scalability > purposes, > I'd like to be able to do this w/o the overhead of a separate Thread for > every request. Is there a "best practice" for this? >
