You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Scott Marlow <sc...@gmail.com> on 2007/03/06 15:29:33 UTC
Two questions about SemaphoreValve support for filtering (bug # 41679)
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Two questions about SemaphoreValve support for filtering (bug
# 41679)
Posted by Scott Marlow <sc...@gmail.com>.
Remy Maucherat wrote:
> Scott Marlow wrote:
>> I didn't want a single request to consume Semaphore permits from more
>> than one SemaphoreValve.
>
> I'm not sure about that, since for example the last valve could be
> more restrictive than the first one, etc. It seems more logical to me
> to consume one permit from each valve since I understand the
> SemaphoreValve in terms of restricting something (most likely there
> should be an option for this on the valve, however, so a
> SemaphoreValve relaxing concurrency constraints could be configured as
> in your example).
>
Good point, I updated the bug report to reflect the requirement to have
an option for this. I think both modes will be useful for different cases.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Two questions about SemaphoreValve support for filtering (bug
# 41679)
Posted by Remy Maucherat <re...@apache.org>.
Scott Marlow wrote:
> I didn't want a single request to consume Semaphore permits from more
> than one SemaphoreValve.
I'm not sure about that, since for example the last valve could be more
restrictive than the first one, etc. It seems more logical to me to
consume one permit from each valve since I understand the SemaphoreValve
in terms of restricting something (most likely there should be an option
for this on the valve, however, so a SemaphoreValve relaxing concurrency
constraints could be configured as in your example).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Two questions about SemaphoreValve support for filtering (bug
# 41679)
Posted by Scott Marlow <sc...@gmail.com>.
> 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.
Yes, multiple valves in a row is what I am suggesting. One example
could be:
<!-- Allow up to 32 users to concurrently run a "lightweight"
request at a time.
Additional "lightweight" user requests are queued until
one of the running 32 user
requests completes. This SemaphoreValve instance is
evaluated first.
-->
<Valve className="org.apache.catalina.valves.SemaphoreValve"
fairness="true"
concurrency="32"
parameterName="componentType"
parameterValue=".*LightWeight.*"
/>
<!-- Allow an unlimited number of requests for static resources.
Concurrency=0 means that no throttling is performed.
This SemaphoreValve is evaluated second, if a previous
SemaphoreValve filter matched already,
then this SemaphoreValve is not processed.
-->
<Valve className="org.apache.catalina.valves.SemaphoreValve"
fairness="true"
concurrency="0"
filter=".*\.gif,.*\.js,.*\.jpg,.*\.htm,.*\.html,.*\.txt,.*\.vm,.*\.css,.*\.cur"
/>
<!-- "Catch all throttle" that will allow up to 9 users to
concurrently run other
requests at a time (assumed to be the "HeavyWeight"
requests. Additional user requests are queued until one of the
running 9 user requests completes.
This SemaphoreValve is evaluated third, if a previous
SemaphoreValve filter matched already,
then this SemaphoreValve is not processed.
-->
<Valve className="org.apache.catalina.valves.SemaphoreValve"
fairness="true"
concurrency="9"
filter=".*" />
/>
I didn't want a single request to consume Semaphore permits from more
than one SemaphoreValve.
Thanks,
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Two questions about SemaphoreValve support for filtering (bug
# 41679)
Posted by Remy Maucherat <re...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org