For Bug # 41679, I attached the current code changes that I am using to
apply SemaphoreValve to different parts of my application based on url
filtering or header field value. Certain "resource expensive" parts of
the application are allowed a smaller number of users to access
concurrently than other parts of the application. I think that this
will be useful to other applications as well.
I have two questions about finishing the patch that is attached to bug
41679.
1. I currently detect if a request has already been throttled by
testing if an attribute named "_SemaphoreValve_throttled_" is in the
request. If not, evaluate if the SemaphoreValve should be applied. If
yes, add an attribute named "_SemaphoreValve_throttled_" to the request
so that we don't apply further SemaphoreValve instances to the request.
Is this technique of injecting a magic attribute in the request too
intrusive? Another option would be to change all Valves to not expect a
certain concrete implementation of Request so that we could use a
RequestWrapper instead that implements a SemaphoreValveMarkerInterface
to signal that a request has already been throttled.
2. It might be useful to have a common Valve subclass that helps with
the url filter matching. Should I work on that as part of this bug? Or
is it better to keep this change simple and isolated to the
SemaphoreValve? The filtering support could be refactored later to a
common subclass.
I assume that if several SemaphoreValve instances are specified in
conf/server.xml, that they are executed in the order that they appear.
This appears to be the behavior in Tomcat 5.x + 5.5.x. Is this a valid
assumption to add to the doc?
Thanks,
Scott Marlow
www.vestmark.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
