I understand and appreciate that you followed what was done for availability. I think
annotations make sense here. The plugin descriptor provides meta data that tell us about
the resource types that the plugin manages. That meta data is also stored and used on the
server and exposed to the user in various forms. The annotations you describe in contrast
are purely an implementation detail of the resource component. There is no need/reason for
the server to know about it.
I am actually not so keen on separate thread pools. Each subsystem in the PC maintains its
own separate thread pool which is not very efficient, but that is an orthogonal concern
from your patch.
On Feb 26, 2013, at 7:03 PM, Elias Ross <genman(a)noderunner.net> wrote:
I came up with the patch and I do think the container should handle
this. Still, I saw how availability was being handled and went that
way.
I had a couple of suggestions in the Bugzilla for a container
solution. One would be to include annotations, but then again RHQ
bases things off of rhq-plugins.xml instead.
The gist is annotating your class like so:
public class SlowAvailResourceComponent ... {
@Asynchronous(frequency=5,timeout=5,units=MINUTES)
public AvailabilityType getAvailability() { ... }
@Asynchronous(frequency=10,timeout=5) // MINUTES default
public void getValues(...) {
}
I'm not sure what the internal implementation would look like.
At the very least, the container would limit the frequency of calls as
described. It would also do the following:
1) Verify that frequency < timeout. Otherwise, the number of calls
could increase without bound.
2) For availability, use a separate thread pool. Store the results in
memory and return them when asked.
3) For measurements, for all measurements scheduled in the frequency
period, ensure that only one call is made to getValues.
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel