On Tue, Dec 2, 2014 at 4:08 PM, Christopher Schultz < ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Chris, > > On 12/2/14 4:28 PM, Chris Gamache wrote: > > Anyone ever suggested? No idea. But I'd be glad to riff on the > > subject in case it shakes some discussion loose. > > > > I haven't seen a filter like that, but I'm sure you could work it > > out. If I were implementing it I would use a Valve... Valves are > > easy to write- just extend org.apache.catalina.valves.ValveBase and > > wire it into your xml configurations. You could probably be more > > sophisticated in your throttling, letting certain IPs or requests > > through while tarpitting others. > > I think a Valve is more appropriate than a Filter, if only because it > can be installed "earlier" in the pipeline. > > > A number of considerations; these off the top of my head-- > > > > You'd have to be okay with holding the request thread open and > > making it sleep. > > If this weren't done in a Valve, but deeper in the core, Tomcat could > even put the request on hold and free the thread to do other things. > This happens with the NIO connectors when the request is still being > sent by the client: the thread isn't tied-up waiting on IO. > > > I guess you could serve a 503 if it were overloaded. > > I guess the question is whether this is a "throttle" intended to just > smooth-out data-mass|request-counts for a particular client[1] or to > avoid being overwhelmed by requests. 503 is better for avoiding an > overload, but can't work well for more traditional "throttling". > > I was thinking about a DOS situation in which I would want to restrict the number of requests submitted in a given amount of time. Or for situations where what the user submits is harmless, they just might want to submit it 10,000 times every 10 seconds. Or for situations where you may want to restrict your client from abusing your free web service, limiting them to 1,000 requests per day. The hard part is deciding whether to throttle specific users or an aggregate consumption of a service. > > Consider your memory usage. I've read horror stories about GC > > pauses wreaking havoc. If you have a farm of tomcats that would be > > participating you'd need to work out a way for them to communicate > > with one another for global counter stats. > > +1 > > [1] Identifying clients is always problematic. Yes. > Proxies (AOL) and other > things can make it look like a huge number of distinct users are > coming from a single IP, effectively treating them as a single user > for the purposes of throttling (if you use IP-based client > identification). This is like 16-bit Microsoft Windows programs > sharing a single time-slice per unit time while 32-bit applications > get a full slice for each application: bad for business (if business > is getting attention from the server!). > >
