Hi James,
James Tran wrote:
> Hi,
>
> Attached is an implementation of a pipeline (which extends
> LinkedListPipeline) that allows for the suspension of SelectionKey(s) in
> order to provide request throttling while still accepting new client
> connections and/or requests. This custom pipeline is being used in the
> the HTTP/SOAP Binding Component (http-bc) in the Open JBI Components
> project. This email is to request that such an implementation can be
> reworked so that a "pluggable" extension can be provided in Grizzly to
> allow for a general purpose request throttling feature.
Thanks! This looks promising :-)
>
> The following is some thoughts on what the extension should provide:
>
> 1. Grizzly should allow registering of some callback so that the
> implementation can decide whether to continue with request processing
> or suspend the request.
> - For HTTP, Grizzly should pass to the callback handler, at minimal,
> the URL context.
> - The callback handler will return some indication (boolean?) whether
> to proceed with processing or not.
+1
>
> 2. Grizzly should allow resuming of requests -
> 1) One option is for Grizzly to expose some interface that the
> component can call to resume requests for a specific resource. Here the
> component will make calls to grizzly.
+1
> 2) The other option is to allow for registration of a callback which
> can be used to determine whether suspended requests can be resumed
> (i.e., how many requests can be resumed for a particular
> resource). Here grizzly will need to poll.
+1
>
> 3. Grizzly should expose an interface to allow canceling of any
> suspended requests targeted for a particular resource.
> This is needed when the target resource is removed (e.g., http soap
> bc endpoint is "deactivated" or web service endpoint is removed).
+1
>
> 4. One other thing I haven't really had time to think out is what
> happens when suspended requests get suspended for a very long time...
> Should there be a way to handle these types of requests in a special
> way?
We can re-use what Grizzly Comet is doing, which is to use a secondary
Selector that act like a timer. When he connection is suspended for a
long time/delay, the Selector wakes up and close it (in Comet it gives
back the control to the CometHandler, so the application can do
something before closing it). The second Selector is also useful to
intercept when the remote client decide to close its connection.
I will add/rework your code and put it in
grizzly/trunk/contribs/grizzy10/throttle. Since it's with Grizzly 1.0, I
will make it also work with the current release, which is 1.7.1.
Feel free to send some improvement/patches :-) :-)
Thanks!
-- Jeanfrancois
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net