SO this doesn't (at the moment) seem to be related to table expiration. My table is maintained on manager and expire_func only runs on manager.
But, I see 'a' worker stall with 99-100% CPU for a good while while all other workers go down to 5-6% CPU. conn.log continues to grow though GDB points to : Get() in install/bro-2.5/src/threading/Queue.h : template<typename T> inline T Queue<T>::Get() { safe_lock(&mutex[read_ptr]); int old_read_ptr = read_ptr; if ( messages[read_ptr].empty() && ! ((reader && reader->Killed()) || (writer && writer->Killed())) ) { struct timespec ts; ts.tv_sec = time(0) + 5; ts.tv_nsec = 0; -----> pthread_cond_timedwait(&has_data[read_ptr], &mutex[read_ptr], &ts); On a side note, Well, why is this on bro-dev ? Not entirely sure. :) I think eventually this might go into what my script is messing up and whats a better way to script the code, I suppose. Aashish On Thu, Jan 19, 2017 at 09:55:40AM -0800, Robin Sommer wrote: > > > On Thu, Jan 19, 2017 at 09:44 -0800, you wrote: > > > 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 ? > > It shouldn't deadlock. What I can see happening, depending on load and > these parameters, is Bro spending most of its time going through the > table to expire entries and only getting to few packets in between (so > not complete stop of processing, but not getting much done either) > > Robin > > -- > Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev