Hi Aashish, > 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. Best regards, Jan _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
