Code calls failure_detector::is_alive on all cpus, so we start
failure_detector on all cpus. However, the internal data of failure_detector
is modified on cpu zero and it is not replicated to non-zero cpus.
This is fine since the user of failure_detector (the gossiper) accesses
it on cpu0 only.
_token_metadata is needed by replication strategy code on all cpus.
Changes to _token_metadata are done on cpu 0. Replicate it to all cpus.
We may copy only if _token_metadata actually changes. As a starter, we
always copy in gossip modification callbacks.
We do not care about the order of the tokens.
Also, in token_metadata, we use unordered_set for tokens as well, e.g.
update_normal_tokens. Unify the usage.
Switch to schema_result::value_type instead of the open-coded std::pair
so that the actual types are defined in one place.
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
This series adds the implementation for teh Failure detector API.
After this patch the following APIs will be supported:
/failure_detector/endpoints
/failure_detector/count/endpoint/up
/failure_detector/count/endpoint/down
/failure_detector/phi
POST:/failure_detector/phi
/failure_detector/simple_states
/failure_detector/endpoints/states
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
When using swagger definition file, returning a map, needs to be in a
key, value list. To handle this common case in the API, a helper
function was added that gets an unorder_map and return a vector of key,
value mapping.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
The failure detector runs on CPU 0, for external usage, this is an
implementation detail which is unrelevant.
This adds a wrapper functions for the functions that are defined in
FailureDetectorMBean which would map the request to the correct CPU.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
When the container_to_vec helper function has a string that contains
space, a boost exection is thrown.
This fixes it by using std::string for the conversion that the boost
recognize as a string type.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
The current 4K write buffer is ridiculously small and forces Urchin to
issue small I/O batches. Increase the buffer size to 64K.
Before:
Results:
op rate : 27265
partition rate : 27265
row rate : 27265
latency mean : 1.2
latency median : 0.9
latency 95th percentile : 2.4
latency 99th percentile : 10.6
latency 99.9th percentile : 14.3
latency max : 44.7
Total operation time : 00:00:30
END
After:
Results:
op rate : 35365
partition rate : 35365
row rate : 35365
latency mean : 0.9
latency median : 0.8
latency 95th percentile : 1.8
latency 99th percentile : 8.8
latency 99.9th percentile : 21.8
latency max : 272.2
Total operation time : 00:00:34
END
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Keys that are in "entries_only_on_right" need to be looked up from
"after". Fixes a regression introduced in commit 5418e32
("map_difference: Simplify difference value").
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Adapt for_all_partitions() to use futures instead of iterators,
as that will be the interface to sstables. We drop use of nway_merger as
that is not able to use futures and instead open-code the heap
functionality.
* Forward commitlog replay_position to column_family.memtable, updating
highest RP if needed
* When flushing memtable, signal back to commitlog that RP has been dealt with
to potentially remove finished segment(s)
Note: since memtable flushing right now is _not_ explicitly ordered,
this does not actually work, since we need to guarantee ordering with
regards to RP. I.e. if we flush N blocks, we must guarantee that:
a.) We report "flushed RP" in RP order
b.) For a given RP1, all RP* lower than RP1 must also have been flushed.
(The latter means that it is fine to say, flush X tables at the same time, as long as we report a single RP that is the highest, and no lower RP:s exist in non-flushed tables)
I am however letting someone else deal with ensuring MT->sstable flush order.
Signed-off-by: Calle Wilund <calle@cloudius-systems.com>
