Scott Marlow wrote:
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.
Sounds cool to me.
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.
I don't see how a request going through a Valve can be "already
throttled", as requests are supposed to go through a valve only once.
Can you give an example ? (maybe multiple valves in a row like what is
suggested below ?) Valves only accept the concrete Request class, no
wrapping allowed.
Marker attributes are already being used elsewhere, so it's ok.
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.
Yes, I think such a common valve is the way to go, similar to the
RequestFilterValve.
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?
Yes.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
