Hi Andrei On 21/11/13 12:08, Andrei Shakirin wrote:
I thought more about Dan's suggestion to consider suspending the threads should the rate exceed the limit, I have to admit it is tempting to try to do that :-), especially given that we can have a thread suspended and resumed in CXF literally with the few lines of code, we can def prototype something simple enough,Hi Sergei,-----Original Message----- From: Sergey Beryozkin [mailto:[email protected]] Sent: Donnerstag, 21. November 2013 11:35 To: [email protected] Subject: Re: Any existing implemention on limiting calling frequencies by client or by IP Hi Dan On 20/11/13 15:54, Daniel Kulp wrote:On Nov 19, 2013, at 10:20 PM, Jason Wang <[email protected]>wrote:Hi all, I would like to limit the frequencies our APIs can be called. Given that they will be public APIs. The limit will most likely be done on IP addresses. Is there existing mechanism in CXF for this? Otherwise I will create my own interceptor to do it.Currently, no. I had some similar discussions about this with some folks lastweek related more about throttling per endpoint instead of per IP. However, many of the thoughts are the same. Kind of came up with this list of thoughts to think about:1) What should happen if more than the needed requests come in? Shouldthey be queued and processed later? Should a fault be thrown? Should some number be queued and then a fault thrown beyond that? Lots of possible config options here.May be we can ship a couple of basic interceptors which would return 503 if the rate exceeds. One pair of interceptors would go to the core and would simply check how many concurrent requests are under way, another pair will go to the http module and it will rate the individual client IP addresses, the ideas you suggested below can further be explored to support more advanced optionsYep, I find that this option is a nice first step for CXF throttling. As Dan said, I see more sophisticated implementation (with queuing) is more mediation as middleware task. I would also provide the possibility to activate these interceptors through WS-Policy assertion with corresponded parameters.
Thanks Sergey
Regards, Andrei.Thanks, Sergey2) If you want to do this at an endpoint level via an executor, the CXFschemas do have an "executor" element for the jaxws:endpoint element that can be used to set a specific executor. There are a couple of "Executor" things that can provide limits that may be able to plug right in here. That said, I'd discourage this. When using an executor, when a request comes in on a Jetty (or other transport thread), we have to place the request on the executor and then block the transport thread until the request finishes. Thus, it ties up two threads and jetty cannot process more while it's waiting. That said, there is definitely a possible enhancement here. If using a transport that supports the CXF continuations, we COULD start a continuation prior to flipping to the executor. Something to think about a bit more.3) Possibly the more "correct" answer to this is that this is amediation/Camel feature, not a service feature. CXF is about creating/exposing services. Placing quality of services requirements around that service is a mediation thing. That could be considered Camel's job. This could be a from("jetty://....").throttle(...).to("cxf:...") type thing. Not sure if the Camel throttling has support for per-ip throttling or not. Would need to investigate more.4) You likely could implement this as a set of CXF interceptors that coulduse the Continuations to "pause" the request for a few milliseconds or similar if the load is too high. Would require some extra coding. Contributions back could be welcome.5) Jetty (and likely Tomcat and others) do have some throttling control builtin at the servlet engine level. You may want to investigate that. Additionally, if you run your web service behind an Apache proxy, I believe the mod_proxy stuff in Apache has some settings for this.Anyway, lots of thoughts, but haven't had time to really look into any ofthem yet.
