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: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
