Class AuthenticationKeyDataListener
java.lang.Object
org.opendaylight.lispflowmapping.southbound.lisp.AuthenticationKeyDataListener
- All Implemented Interfaces:
EventListener
,org.opendaylight.mdsal.binding.api.ClusteredDataTreeChangeListener<AuthenticationKey>
,org.opendaylight.mdsal.binding.api.DataTreeChangeListener<AuthenticationKey>
public class AuthenticationKeyDataListener
extends Object
implements org.opendaylight.mdsal.binding.api.ClusteredDataTreeChangeListener<AuthenticationKey>
DataListener for all AuthenticationKey modification events.
-
Constructor Summary
ConstructorsConstructorDescriptionAuthenticationKeyDataListener
(org.opendaylight.mdsal.binding.api.DataBroker broker, AuthKeyDb akdb) -
Method Summary
Modifier and TypeMethodDescriptionboolean
authKeysForEidsUnchanged
(Map<EidLispAddressKey, EidLispAddress> eids, long timeout) We maintain a HashMap with the update times of AuthenticationKey objects in the updatedEntries field.void
void
onDataTreeChanged
(Collection<org.opendaylight.mdsal.binding.api.DataTreeModification<AuthenticationKey>> changes) Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
Methods inherited from interface org.opendaylight.mdsal.binding.api.DataTreeChangeListener
onInitialData
-
Constructor Details
-
AuthenticationKeyDataListener
public AuthenticationKeyDataListener(org.opendaylight.mdsal.binding.api.DataBroker broker, AuthKeyDb akdb)
-
-
Method Details
-
closeDataChangeListener
public void closeDataChangeListener() -
onDataTreeChanged
public void onDataTreeChanged(Collection<org.opendaylight.mdsal.binding.api.DataTreeModification<AuthenticationKey>> changes) - Specified by:
onDataTreeChanged
in interfaceorg.opendaylight.mdsal.binding.api.DataTreeChangeListener<AuthenticationKey>
-
authKeysForEidsUnchanged
We maintain a HashMap with the update times of AuthenticationKey objects in the updatedEntries field. We keep entries in the HashMap for the Map-Register cache timeout interval, and lazy remove them afterwards. As a result the same EID will be considered updated during that interval, even on subsequent queries. This is necessary because more than one xTR may register the same EID, and to avoid complexity we don't store origin information. The performance trade-off is not significant, because during a typical cache timeout the same xTR will send only a few registration packets (2 for the default value of 90s, when UDP Map-Registers are sent at 1 minute intervals).- Parameters:
eids
- List of EIDs to checktimeout
- MapRegister cache timeout value- Returns:
- false if any of the EIDs in the eids list was updated in the last timout period, true otherwise
-