[
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)
_______________________________________________
bro-dev mailing list
[email protected]
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
