[Bro-Dev] help Reading the backtrace

[Aashish Sharma]

> https://www.bro.org/sphinx/scripts/base/init-bare.bro.html?highlight=expire#id-table_expire_delay).

This is very helpful. 

I have been testing out table_expire_delay but somehow wasn't looking at table_incremental_step I'll test out a million expires while teaking table_incremental_step to see what the limits are here.

Still, to clearify, there might be a possibility that because at present table_incremental_step=5000, somehow expiring >> 5000 entries continiously every moment might cause cause Queue to deadlock resulting in BRO to stop packets processing ?

Aashish 



On Thu, Jan 19, 2017 at 10:55:45AM +0100, Jan Grashöfer wrote:
> > But I also wonder what you are doing that is triggering Dictionary9NextEntryERP7HashKeyRP10IterCookiei
> > 
> > which would be
> > 
> > void* Dictionary::NextEntry(HashKey*& h, IterCookie*& cookie, int return_hash) const
> > 
> > Tables should be fine, but I wonder what you're doing that is triggering so much iteration.
> 
> If I am not mistaken, tables are basically dictionaries (with the
> exception of subnet-indexed tables). The iterations should be related to
> how expiration works: As soon as the timer fires, the table is looped
> looking for expired entries. To prevent blocking in case of too many
> expired entries that have to be handled, only
> <table_incremental_step>-number of entries are processed, following a
> delay of <table_expire_delay>. Adjusting this parameters might help (see
> https://www.bro.org/sphinx/scripts/base/init-bare.bro.html?highlight=expire#id-table_expire_delay).
> 
> Jan