Bug 836372

Description of problem:
We already have the class AvailabilityCollectorRunnable that plugins can utilize to perform availability checks asynchronously. One example of where this is used is in the jboss-as-5 plugin in the ApplicationServerComponent class. There is discussion about doing something similar for metrics collections. There are a couple problems though. First, every plugin component that wants to perform these operations asynchronously have to duplicate logic similar to what is found in ApplicationServerComponent. Secondly, we do not want plugin components dealing with or managing threads. That is a responsibility that should be managed by the container just as it is with a servlet or EJB container.

The functionality provided by AvailabilityCollectorRunnable should be handled by the plugin container (PC). Plugin components should have to do nothing more than notify the PC that they want availability checks and/or metrics collections to be done asynchronously. A plugin component's implementation should not have to change based on whether availability checks or metrics collections are done synchronously or asynchronously.

There was a suggestion that we might have something like the following in the plugin descriptor,

<metric property="foo" ... asyncCollection="true" />

Note the addition of the asyncCollection attribute. I think that there are a couple problems with this approach. First, this isn't applicable to availability. There is no corresponding <availability> element to which we would add the attribute. We could add it, but I think it just adds clutter to the descriptor. The second problem is that the asyncCollection attribute is specified on a per-metric basis. This may cause some confusion and lead to some unnecessary complexity. The PC batches metrics together as much as possible during a collection. It is a little unclear what should happen when a collection occurs for metrics where some are marked as async and some as sync.

I think a cleaner and more concise solution is to introduce an @Async annotation. The annotation could be added to the getAvailability and getValues methods to notify the PC that availability checks and metrics collections should be done asynchronously. The PC is then free to implement the thread pooling, scheduling, etc. however it sees fit.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info: