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:tal.li...@threecrickets.com] Envoyé : jeudi 20 mai 2010 11:00 À : discuss@restlet.tigris.org 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
