Thanks for the detailed response! RFE: "Expose server instrumentation" http://restlet.tigris.org/issues/show_bug.cgi?id=1117
So, I guess only the internal connector will support true asynchronous handling now for 2.0. The comparison charts talk about the internal connector being suitable for development. But, what's your opinion about production environments? It seems to be much improved since the early days of Restlet. If asynchronicity is a required feature, I do not have another choice for 2.0. Or, perhaps we should consider asynchronicity as a "preview" feature in 2.0, and wait until 2.1 for leveraging it? I think it was wise of you not to add SSL support. It's definitely a pain to write, and there are simple solutions. (I recommend using Perlbal as your load balancer, and handling SSL there.) Have you considered, though, using code from Grizzly for SSL? -Tal On 05/21/2010 03:53 AM, Jerome Louvel wrote: > Hi Tal, > > 1. This is a good point that needs to be explored. The current path we are > following is to deal with high-load directly inside the internal connector, > for example to stop accepting new connections at IO level if we are > overloaded, or giving a priority of responses sending over new requests > handling. > > You might prefer to deal with that inside resources, which could make > perfect sense. We should explore this during the 2.1 development cycle. Feel > free to enter a RFE in the tracker. > > 2. There is a TaskService associated to your application that you could > leverage. It separates threads usage from tasks to process (such as > committing responses). > > Your point about instrumentation is valid though, we need to work on that. > Creating a RFE would be a good step forward. > > 3. abort() should now work with other connectors AFAIK (check the changes > log). Regarding provisional responses and commit(), I think this will have > to wait for 2.1. > > 4. The internal connector is described here: > http://wiki.restlet.org/developers/172-restlet/354-restlet.html > > We are working on the NIO enhancements to it and hope to have this ready for > 2.0 in order to have a scalable/asynchronous/lightweight connector. It uses > a configurable thread pool, but HTTPS is not planned for 2.0 at all (too > much work). > > We also have this page describing the various connectors available: > http://wiki.restlet.org/docs_2.0/13-restlet/27-restlet/325-restlet/37-restle > t.html > > This should be improved I guess with addition details/criterias. We did > cover those details in the "Restlet in Action" book (early access). > > 5. Currently, we call this default connector the "internal" connector. I'm > not sure about having a code name for it at this point... I'd prefer people > to think about it as a natural part of the Restlet engine. > > Best regards, > Jerome Louvel > -- > Restlet ~ Founder and Technical Lead ~ http://www.restlet.org > Noelios Technologies ~ http://www.noelios.com > > > > > -----Message d'origine----- > De : Tal Liron [mailto:[email protected]] > Envoyé : jeudi 20 mai 2010 11:00 > À : [email protected] > Objet : Status of Asynchronous Support > > Thought I've followed what I could of the progress on asynchronous > support, I have a few interdependent questions and suggestions. > > 1. On the one hand, I really like how simple asynchronicity is handled. > I can defer my response to later (from another thread). But, Restlet > provides no tools to help me decide if I should defer or not. What I > would want to know is -- Am I under load right now, meaning high > concurrency? Should I yield so that other requests can have a chance to > get in? > > 2. A related question: If I do defer, I do not necessarily want to > decide on my own when to finish the response. I might want to wait until > there is a free thread that can take me. It would be great if there were > 1) a callback for this, or 2) a way for me to "signal" that I'm ready to > respond, as soon as the server is free. Or, at the very least a way to > poll the server load. > > (To summarize these two issues: the Restlet server is very opaque right > now. For truly scalable applications (cloud, cloud, cloud) we need > realtime information from it so that the application can react dynamically.) > > 3. I know that the "default" connector supports commit/abort, but what > about Grizzly, Jetty and Netty? If they don't support it yet, is support > being planned for 2.0? This will strongly affect my deployment strategies. > > 4. Assuming only the "default" connector is asynchronous, could you > provide more details about it? Until now, frankly, I've ignored it as > something that just works and isn't fit for production. It seems like > this connector is very capable by now, but I know nothing about how it's > implemented. NIO? Thread pools? SSL? I think it would be very good if > there were a wiki page with an in-depth comparison of the various > available connectors, what features they provide and implementation > details -- both of the servers themselves, and of the features the > Restlet adapters leverages (or not). As it stands, it's hard for a > deployer to make an informed decision on which connector to use. > > (For the record -- I think benchmarks are quite useless for this > comparison. Performance != scalability, and in any case benchmarks are > highly contextual. It's very easy to switch connectors in Restlet and > for people to do their own benchmarks.) > > 5. Might I suggest giving the "default" connector a name? It seems to be > a nice little engine of its own. If we're going to start comparing it to > the others as a viable alternative, it might be easier to name it. My > only name suggestion is Thier Engine, short for Thierry, and reminds me > of "tier." :) > > -Tal > > ------------------------------------------------------ > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=26112 > 18 > > ------------------------------------------------------ > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2611691 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2612116
