If you read BZ 536173, you can get a sense of the problem that needs to be solved.
Typically, availability checks are very fast (sub-second). However, the plugin container puts a time limit on how long it will wait for a plugin's resource component to return availability status from calls to AvailabilityFacet#getAvailability(). This time limit is typically on the order of several seconds (5s at the time of this writing). The purpose of this time limit is to avoid having a rogue or misbehaving plugin from causing delays in availability reporting for the rest of the resources being managed within the system.
The Asynchronous Availability Collector provides an implementation to help resource components that can't guarantee how fast its availability checks will be. Some managed resources simply can't respond to avaiability checks fast enough. In this case, this class will provide an asynchronous method that will collect availability without a timeout being involved (in other words, availability will be retrieved by waiting as long as it takes). In order to tell the plugin container what the managed resource's current availability is, the Asynchronous Availability Collector will provide a fast method to return the last known availability of the resource. In other words, it will be able to return the last know availability that was last retrieved by the asynchronous task - this retrieval of the last known availability will be very fast.
The class that plugin developers need to know about is AvailabilityCollectorRunnable. You integrate this class into your ResourceComponent implementation in order to be able to perform availabilty checks asynchronously. This is how you do it: