BZ 783603 - async measurement collection - can someone peer review and/or test?

John Sanda jsanda at redhat.com
Mon Mar 4 14:51:34 UTC 2013


comments/questions below…

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

> On Tue, Feb 26, 2013 at 4:39 PM, John Sanda <jsanda at 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 at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/rhq-devel/attachments/20130304/0b3265f1/attachment-0001.html>


More information about the rhq-devel mailing list