All great ideas guys. Should I raise an enhancement request? I can easily do one for my own usage. But to make it generic enough for everyone, there needs to be something to store the ip, attempts record. I am using ehcache at the moment. If I expose a setter for cache provider the same way hibernate does, will it be a solution for general CXF users?
Cheers, On Fri, Nov 22, 2013 at 1:08 AM, Andrei Shakirin <[email protected]>wrote: > 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 last > > week 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? Should > > they 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 options > > Yep, 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. > > Regards, > Andrei. > > > Thanks, Sergey > > > > > 2) If you want to do this at an endpoint level via an executor, the CXF > > schemas 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 a > > mediation/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 > could > > use 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 built > > in 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 > of > > them yet. > > > >
