Bug #296

DeviceBuilderThread delayed retry broken

Added by Philipp Buluschek over 3 years ago. Updated over 3 years ago.

Status:New Start date:02/04/2015
Priority:Normal Due date:
Assignee:- % Done:

0%

Category:- Spent time: -
Target version:-
Has a patch:No Has license agreement signed:No

Description

In DeviceBuilderThread, when several attempts at contacting a device fail, the next retry should be postponed some time (30 secs).

A map holds these devices in the meantime, including (supposedly) the timestamp of the last attempt Map<ZigBeeDeviceReference, Long> delayedReattempts.

Later, to check whether to do redo an attempt, a comparison is done with the current time (where device is an Entry of the Map above)

if ((device.getValue() + delay) >= System.currentTimeMillis()) {
  ... 

But, the timestamp in the Map.Entry is not initialized to the current time when the last attempt was made:

...
else{
  logger.debug("Too many attempts failed, device {}:{} adding delayed of {} ms", new Object[]{node, ep, delay});
  failedDevice.remove(last);
  delayedReattempts.put(last, delay);
}

but to delay which is always 30000. This should supposedly read:
...
else{
  logger.debug("Too many attempts failed, device {}:{} adding delayed of {} ms", new Object[]{node, ep, delay});
  failedDevice.remove(last);
  delayedReattempts.put(last, System.currentTimeMillis());
}

History

#1 Updated by Philipp Buluschek over 3 years ago

After a bit more investigation, it seems the whole retry mechanism in DeviceBuilderThread is broken (see also bug #297).

For example: Things are put into the Map failedAttempts but never read or removed from it.
In case of a successful construction, the device is not removed from failedDevice.

Also available in: Atom PDF