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

Elias Ross genman at noderunner.net
Mon Mar 4 17:32:00 UTC 2013


> On Mar 1, 2013, at 2:46 PM, Elias Ross <genman at noderunner.net> wrote:
>
>
> 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.
>

On Mon, Mar 4, 2013 at 6:51 AM, John Sanda <jsanda at redhat.com> wrote:

>
> Not sure I follow this example. Can you clarify?

If you have a measurement that takes nearly 5 minutes to gather, then
naturally you would set the schedule frequency to 5 minutes. But if
there are measurement schedules, one every 3 minutes (which is set to
5), and one set to 8 minutes, then you'll end up making overlapping
calls to MeasurementFacet; like at minute 5, minute 8, minute 10,
minute 15, minute 16, etc.

The point is to prevent two separate threads from calling into MeasurementFacet.

Regarding what Lukas Krejci said, we want to minimize potential
threading issues and this is just one I want to avoid.

It's also a restriction for efficiency's sake. If the measurements are
being gathered take time to gather, it is probably more efficient to
gather more measurements at the same point in time.

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

Aside from effectively changing the schedule periods, not much. Note
though that the first time measurements are gathered, it is basically
just going to store the results in a cache, not actually report them.

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

The results would be tagged with a timestamp. They could either be
evicted periodically (in a separate thread), or by checking expiration
when the results are accessed. I would probably just do an eviction
anytime the cache is accessed just to be safe.

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

I was thinking about adding a callback initially. It would make things
more elegant in terms of threading, but there would need to be some
significant rewrites of the code to make it work. For example, after
obtaining an availability report, there are many many steps that would
need to be taken in this callback to do the same work that's already
done. Sending the report to the server is one thing, but there's a lot
of other stuff regarding setting state.

The changes I'm suggesting would be mostly limited to
ResourceContainer and thus fairly low risk.

Note that @Asynchronous will only be supported for availability and
measurement facets. Possibly other ones could be supported too, but I
don't know.

One area I'm concerned with is shutdown. All the asynchronous calls
will need to be canceled and wait()ed on until shutdown is called for
a component. I think is done more or less in the synchronous case. But
anyway, that's not really a major concern since shutdown is primarily
about ending the process's life.


More information about the rhq-devel mailing list