comments/questions below…

On Mar 1, 2013, at 2:46 PM, Elias Ross <genman@noderunner.net> wrote:

On Tue, Feb 26, 2013 at 4:39 PM, John Sanda <jsanda@redhat.com> wrote:
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.

Here's kind of what I've come up with with a design:

1) Use annotation to mark any Facet method called by
ResourceContainer. The annotation is roughly like so:

   @Asynchronous(frequency=5,timeout=5,units=MINUTES)

This annotation is to be detected by ResourceContainer.

2) Change ResourceContainer to set the granularity of measurement
collections to be (multiples of) frequency. Basically if measurements
are collected every 8 minutes, then instead collect every 5, if 22
minutes, every 20 etc.

Not sure I follow this example. Can you clarify?

   public void setMeasurementSchedule(Set<MeasurementScheduleRequest>
measurementSchedule) {

4) Change ResourceContainer.invoke to check for cached results. The
results are cached based on the method and arguments. If they are <
frequency, then return them. Periodically flush out old results to
prevent memory leaks.

What if any impact does this have on the existing priority-based scheduling that is used to determine what schedules are ready for collection?

How/when do we determine if cached results are stale?

Add a callback to ComponentInvocationThread once the availability or
measurements are obtained. The callback will set the cached results.

5) Change cancelation to happen asynchronously. Right now the call is:

               return future.get(this.timeout, TimeUnit.MILLISECONDS);
           } catch (java.util.concurrent.TimeoutException e) {
               future.cancel(true);

will be changed in the async case to return the cached results, and
there will be no use for 'future'. A separate cancelation call will be
scheduled to run. I kind of like this implementation:
http://docs.jboss.org/netty/3.2/api/org/jboss/netty/util/HashedWheelTimer.html

I wonder if Guava's listenable futures (https://code.google.com/p/guava-libraries/wiki/ListenableFutureExplained) might be another option here.
...

Thoughts? I think it's pretty straightforward.
_______________________________________________
rhq-devel mailing list
rhq-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel