[kea-dev] Another hook suggestion: configurable periodic timers

[Marcin Siodelski]

Nicolas,

IIRC, when the list of libraries has changed (e.g. library added or
removed), all libraries are unloaded. If you don't change the list of
libraries, the server's reconfiguration (with SIGHUP) should not unload.

Marcin

On 11/24/14 18:32, Chaigneau, Nicolas wrote:
> Hello,
> 
> 
> The primary use case I see is to generate statistics at regular time intervals (such as: monitoring of pools usage, packets received and sent...).
> The hook would not need contextual data (other than the timer id), as it would use memory objects updated by the hook library when handling other events (such as "pkt4_receive").
> 
> A CRON task cannot do this, since it cannot access the in-memory objects maintained by the hook library.
> 
> 
> Apart from at server shutdown, and when processing a reload command, are there other situations where the library unloading can happen ?
> 
> 
> 
> Regards,
> Nicolas.
> 
> 
>> Hi Nicolas,
>>
>> Can you please describe some of the use cases you have in mind here?
>>
>> Typically, hooks require access to the contextual data. For example, a pkt4_receive hook requires pkt4 object be passed to it by the server.
>> Depending on the purpose, the "timer hook" could also require access to some data contexts (e.g. a hook which offers periodic statistics gathering needs to access some statistical data counters) but the type of the contextual data can't be known upfront when implementing a hook and this seems to limit the usability of such a hooks to only those situations when the context is not needed or when the library maintains its own context. Then, when the library is unloaded the context is lost.
>>
>> If the "timer hook" is meant to just perform some periodic operations which don't depend on any data contexts it is worth to consider whether the same can be achieved with a cron job?
>>
>> I don't want it to sound that I am not opposed to this idea. I try to understand the use cases so as we rather provide some generic mechanism, rather than something of a limited usability.
>>
>> Marcin
>>
>> On 11/19/14 17:50, Chaigneau, Nicolas wrote:
>>> Hello again,
>>>
>>>
>>>
>>> Another need I have is to perform periodic actions within a hook library.
>>>
>>> A hacky way to do so is, for instance, on a trigger "pkt4_receive":
>>> Check if it's time to perform the periodic action, then rearm the timer afterwards (ie, set the future timestamp at which the action should be handled again).
>>> The drawback is that it depends on traffic being sent to the server. And it's not a terribly clean way to handle this...
>>>
>>> (Still, it works. So the following proposal is not of high priority or 
>>> anything; I'm just opening the discussion.)
>>>
>>> I think of the following:
>>>
>>>
>>> Allow to define in configuration a list of timers, each of which would be composed of a period and identifier.
>>> For instance, with a timer of 5 min and one of 1H:
>>>
>>> 	"periodic-timers": [
>>> 		{
>>> 			"id": "timer-monitor"
>>> 			"period": 300,
>>> 		},
>>> 		{
>>> 			"id": "timer-1H"
>>> 			"period": 3600,
>>> 		}
>>> 	]
>>>
>>> Kea would trigger a new hook "periodic timer" each time the period of one of the timers is reached.
>>> The hook library would receive both "id" and "period" arguments, which would allow to decide what to do (or do nothing).
>>>
>>>
>>>
>>> (apologies for overloading the mailing list; this will be my last one 
>>> for today, I promise !)
>>>
>>>
>>> Regards,
>>> Nicolas.
>>>
> This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
>