[Bro-Dev] libbroker status/plans

[Siwek, Jon]

> On Oct 23, 2014, at 11:04 AM, Seth Hall <seth at icir.org> wrote:
> 
> On Oct 23, 2014, at 11:41 AM, Siwek, Jon <jsiwek at illinois.edu> wrote:
> 
>> it may just push the overload problem to the sender(s) and begs the question of what they do if they can’t artificially slow down?
> 
> With regards to logging, I think this is one area where you can cheat a bit and just push back at scriptland to give script developers a chance to know if a logging queue is getting backed up.  There are a number of ways we could deal with overload situations there.

Yeah, leaving things up to application may be reasonable here.  For most of the messaging patterns in Broker, I expect it to be lightweight to hand off pending messages from Broker’s queues to the application, so essentially the application is already going to be left to manage its own resources.  For Bro that could mean tying in to the script-layer like you suggested and shuffle around or even disable some logging/events (on either sender or receiver side).  We could probably already be doing something like that in Bro without Broker, so maybe that is a hint that it may not need to be addressed directly in the library.

- Jon