[Bro-Dev] Configurable &write_expire interval
jan.grashoefer at gmail.com
Fri Jun 10 16:28:16 PDT 2016
> For all of my needs above has worked fairly well. including using exp_val= 0 secs as default.
> Based on the value of item in the table, I could return a variable time back from the expire function thus either keeping it longer or expiring it.
Trying this, I ran into an issue with &write_expire:
1) I set &write_expire=0 min
2) In the first call of the expire_func I return a delay, e.g. 10 min
3) After e.g. 5 min there is a write, the timer is set back to 0 min
(instead of 10 min) and the item immediately expires.
>From my understanding, this is a result of how the delay is implemented.
As far as I understand the code, a delay is realized by setting the time
of the last access so that the next expiration occurs exactly after the
given delay. The expiration value isn't touched. As a consequence,
accessing the item within the delay time window will reset the
expiration to its original value. To be clear: I think that's perfectly
fine and works how I would expect it to work. It just prevents the
0-expire workaround for read/write_expire.
>>> used inside the table implementation. The drawback would be that there
>>> is no fixed value for serialization (I am not sure about the effects
> Sorry, I don't quite seem to understand this drawback.
That's an implementation detail again. The expression given with the
expire attribute is evaluated and stored when the table value is
created. Thus using a const and doing a later redef doesn't lead to the
intended behavior. Meanwhile I realized that the expire_func expression
is also serialized. I assume this would be an option for the expire
value, too. However, I could miss something.
More information about the bro-dev