[
https://bro-tracker.atlassian.net/browse/BIT-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19910#comment-19910
]
Jon Siwek commented on BIT-1319:
--------------------------------
{quote}
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}
Yes, should be possible to give these operations high priority when talking to
a data store clone.
Another problem at the moment is that queries against a clone store will wait
to be processed until the clone has performed an initial synchronization with
the master store. Without doing that wait, it seems prone to a lot of bad
results at startup. But it also means if you do a synchronous query and a
corresponding master store just doesn't exist yet, you can still end up
blocking for an indeterminate amount of time, possibly indefinitely. What
should be the behavior/solution here?
* don't distinguish high priority queries from low-priority queries, but change
blocking query API to require timeout parameters
* distinguish high-priority queries and they are still held up by the
wait-for-initial-sync, but all methods in the blocking query API require a
timeout parameter (this may make synchronous queries less affected by overload,
but then maybe it opens up some starvation possibilities if one sends
high-priority queries too often)
* high-priority (synchronous) queries bypass the wait-for-initial-sync, but
low-priority (asynchronous) queries do not
* all queries bypass the wait-for-initial-sync, but updates/modifications wait
for master to become available instead of just dropping them
* get rid of wait-for-initial-sync behavior entirely
The first option seems to have fewest drawbacks and may be least complex to
implement. And you'd get a less cumbersome API in Bro for synchronous queries:
you don't have to use a when statement, but do need to specify the maximum time
you want to allow the call to block.
> 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
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
