Such an aspect should be part of the https://svn.jboss.org/repos/jbossas/projects/aop/trunk/aspects/ project. The org.jboss.aspects.concurrent package contains some Semaphore aspects, but I am not sure what they do
The org.jboss.aspects.concurrent Semaphore aspect does what I had in mind.
I would also like a way to share the Semaphore instances (used internally by the Semaphore aspect) between multiple components. For example, I might want immutable application components to share a named Semaphore that has 64 permits and mutable components to share a named Semaphore that has 8 permits.
Sound like a good enhancement?
I looked at the existing semaphore support and I think my needs are already covered.
I should be able to have a SemaphoreAspect or SemaphoreMethodAspect instance throttle several different components in the application by changing the "scope".
Yes, if I understand you correctly. Are you talking about the scope when you declare the aspect? Although, this scope is quite course-grained.
PER_VM - all share the same semaphore
PER_CLASS - all instances of a class share the same semaphore
PER_INSTANCE - each instance has the same semaphore
It might be worth allowing for an extra attribute on the annotations to declare a "group" or something to choose the semaphores?
Yes, I meant the scope when you declare the aspect.
Yes, a group or "named semaphore" attribute would be ideal.
I'm thinking that we need a way to configure the "named semaphore" but I'm not sure what that should look like. The configuration would specify the number of Semaphore permits and the name.
Would this work? Have a SemaphoreAspectFactory instance for each named semaphore definition and create the semaphoreAspect from the factory.
<aspect name="ThrottleReadMostlyAspect" factory="org.jboss.aspects.concurrent.SemaphoreAspectFactory" scope="PER_JVM"> <attribute name="permits">48</attribute> </aspect>
It could, but you then need to specify every single pointcut manually, i.e. you would not be able to use the annotations in the bindings
The Semaphore aspect could perhaps be configured with the list of group names and number of permits per group. Then when encountering a annotated joinpoint, get the group id from the annotation and use the correct semaphore for that.
The aspect could be configured via an attribute, or by using XMLLoadable. One problem with this though is that you would have to redeploy the whole aspect to be able to reconfigure it.
I'm tempted to have a standalone module manage the named semaphores (perhaps called SemaphoreManager). The SemaphoreManager api methods could be used for reconfiguration (JMX aspect could expose them in the JMX console.)
The api should allow:
* List all named semaphores (show name, total permit count + current available permits)
* Increase number of permits for a named semaphore
* Decrease number of permits for a named semaphore
I'm still trying to understand how all of this AOP stuff works together. I see that the SemaphoreAspect is loosely coupled with the underlying semaphore instance via the SemaphoredObject class. Should we have a SemaphoreFactory class that can return a SemaphoredObject implementation that is based on a named semaphore? I suppose that the SemaphoreFactory could also return a SemaphoredObject based on an anonymous semaphore as well.
The SemaphoreFactory factory would depend on the SemaphoreManager for resolving the semaphore instances.
Make any sense?
On a different node, I can build trunk with "mvn install" command. I would like to run the testsuite but "mvn test" doesn't seem to do much. How can I run the unit tests?
AOP is not yet fully mavenised, so use ant for now.
It looks like it is using the SemaphoredObjectMixin to install the semaphore. In the tutorial that comes with the dist there is a tutorial example about mixins and introductions. Instead of using mixins, you could also use a per_instance scoped aspect.
There don't actually seem to be any tests for this...