modules/core/plugin-container/src/main/java/org/rhq/core/pc/inventory/AvailabilityExecutor.java
| 9 +++++++++
1 file changed, 9 insertions(+)
New commits:
commit b72461c76f2b7d951e72c001b6dfde68bc31afdb
Author: Lukas Krejci <lkrejci(a)redhat.com>
Date: Mon Aug 26 16:54:43 2013 +0200
Added a note to AvailablityExecutor.lock field.
I think it should be removed because it creates a false sense of
thread-safety of avail collection.
diff --git
a/modules/core/plugin-container/src/main/java/org/rhq/core/pc/inventory/AvailabilityExecutor.java
b/modules/core/plugin-container/src/main/java/org/rhq/core/pc/inventory/AvailabilityExecutor.java
index b318c04..c28975e 100644
---
a/modules/core/plugin-container/src/main/java/org/rhq/core/pc/inventory/AvailabilityExecutor.java
+++
b/modules/core/plugin-container/src/main/java/org/rhq/core/pc/inventory/AvailabilityExecutor.java
@@ -83,7 +83,16 @@ public class AvailabilityExecutor implements Runnable,
Callable<AvailabilityRepo
protected final InventoryManager inventoryManager;
private AtomicBoolean sendChangesOnlyReport;
+
+ // NOTE: this is probably useless. The concurrency of the availability checks is
mainly guarded by the size of the
+ // availabilityThreadPoolExecutor in InventoryManager. While this lock object would
prevent multiple avail checks
+ // from running concurrently even if the size of the above executor was more than 1
(which it isn't), the problem
+ // we'd then face would be that we use multiple instances of AvailabilityExecutor
in InventoryManager:
+ // availabilityExecutor field but also local instances in
executeAvailabilityScanImmediately() and
+ // getCurrentAvailability(). This means that the only thing preventing from the
multiple availability checks
+ // happening concurrently is the size of the thread pool and this object serves
little purpose in that regard.
private final Object lock = new Object();
+
private int scanHistorySize = 1;
private LinkedList<Scan> scanHistory = new LinkedList<Scan>();
Show replies by date