[Bro-Dev] [JIRA] (BIT-1319) topic/jsiwek/broker

[Robin Sommer (JIRA)]

    [ https://bro-tracker.atlassian.net/browse/BIT-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19909#comment-19909 ] 

Robin Sommer commented on BIT-1319:
-----------------------------------

{quote}
$ clang --version
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
{quote}


Doh, Apple! I didn't expect them to change the format of the version string. I take it back.

{quote}
Don't think it would be hard to change it to Store::create_clone(“name”, peer) in order to require the master counterpart be located on the given peer, but maybe that just gives another chance for programmer-error to slip in by specifying the wrong peer/endpoint?
{quote}


Don't have a good handle on the programming/usage  aspects of this yet (obviously). That said, my gut feeling would be that identifying a store by peer/name tuple is less confiusing/error-prone that just name. But whatever you prefer, might be something to see over time.

{quote}
Blocking versions can be added, but some caution is still probably needed when using them because even though it goes to the local cache, queries are still processed via a queue of all other data store operations and I don't think there's a good way to tell what the current load is. So I think you could unknowingly block for longer than you'd want if the store is severely overloaded.
{quote}

Yeah, I was afraid that that's the answer. :-)

I'm torn. On the one hand, "when" is the right answer here. On the other hand, I see Broker being used for lots of smaller tasks as well, including, say, just keeping some local state persistently. Forcing the async interface on usages where performance is unlikely to matter much at all, looks a bit painful from a usability perspective. 

Question: could we skip the queue of operations for sync operations? We'd tell people: "look, you can use this, but you might get inconsistent results in exchange for a less cumbersome interface". My guess is that often, it'll be good enough. So the sync store operations would always go directly to the local cache.

{quote}
 e.g. broker vectors don't necessarily contain homogenous data types.
{quote}

Maybe eventually we can provide some convenience functions for turning common types into corresponding Bro values. But that's another thing to collect some experience with first.

> topic/jsiwek/broker
> -------------------
>
>                 Key: BIT-1319
>                 URL: https://bro-tracker.atlassian.net/browse/BIT-1319
>             Project: Bro Issue Tracker
>          Issue Type: New Feature
>          Components: Bro
>            Reporter: Jon Siwek
>            Assignee: Jon Siwek
>             Fix For: 2.4
>
>
> The "topic/jsiwek/broker" branch is in the bro and cmake repos to add the initial support for Broker.
> Notes/Disclaimers/Caveats:
> - Bro has a --enable-broker configure flag.
> - requires actor-framework "develop" branch.  When version 0.13 is out, I will put that as a requirement in the README and have CMake check for that.
> - no C bindings yet
> - no Python bindings yet
> - other than checking compilation that the new unit tests pass on Linux/FreeBSD/Mac, I've not done must extensive of testing, profiling, optimization etc.



--
This message was sent by Atlassian JIRA
(v6.4-OD-15-055#64014)