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