Use C++11's std::declval<T>() instead of my ad-hoc scary-looking
idiom *(T*)nullptr.
Both techniques produce an object of type T which is only useful for
unevaluated contexts, only inspecting an object's type and not is value.
For example, in decltype() expressions.
Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Amazing how many errors a short of piece of code can have, without the
compiler complaining at all. The magic of templates :-)
Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Some methods in storage_service.cc want to return an
unordered_set<query::range<dht::token>>. This patch adds the missing
hash function for a query::range<T> to make it usable as a hash-table key.
The hash function we used is a trivial linear combination of the range's
start and end hash function - the same function used by Cassandra's
AbstractBounds.hashCode() so it is probably "good enough".
Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
"The series adds a histogram obect similiar to the yammer histogram and a
latency helper object to calculate latency. It then adds histogram to the
storage_proxy and set it in the code and the API for the write path."
Dependencies between static variables don't work if they're in different
translation units.
I see in gossiper's constructor, QUARANTINE_DELAY is still 0.
Make it a function. It is nicer to make it inline, but I don't want to
pull storage_service.hh into gossiper.hh.
From Avi:
Add pretty-print support for sstring, uuid; add commands to query
where database objects, keyspace objects, and column_family objects are
located.
This adds the implementation to the histogram for the storage proxy.
After this patch the following url will be available:
/storage_proxy/metrics/read/latency/histogram
/storage_proxy/metrics/range/latency/histogram
/storage_proxy/metrics/write/latency/histogram
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
This adds the read, write and range histograms to the storage_proxy
It adds the following commands:
get_read_metrics_latency_histogram
get_range_metrics_latency_histogram
get_write_metrics_latency_histogram
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
This patch generalizd the sum helper function to accept any field as
long as it support the + operator and that it can be parrsed as json.
It adds a sum function to sum histograms it does so by:
adding the totatl, adding the sum, set the min and max
setting the avrage and variance and combining the samples.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
The utils file will hold general modules, that need to be used by
multiple modules.
As a start, it holds the histogram definition.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
This patch set the write timmers: histogram, timeout and unavailable.
For the histogram a latency is needed. For that the latency object is
used.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
The storage proxy needs to collect statistics about read, write and
range. For that the ihistogram object was added to its stats object.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
The latency object is used to simplify calculating latencies. It uses a
start and stop time_point so the latency can be queried multiple time.
The start need to be done explicitely and not in the constructor to
allow reuse of the object.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
The histogram object is equivalent to the Histogram used in Origin. It
collect multiple values about the data:
Count, Min, Max, Sum, variance and the sum of square that are used for
std calculation.
It also contain a sample of the last n elements, that are stored in a
circular buffer.
The histogram is used by the API to report histogram statistics.
As the API does not support unsigned integer, the count is signed.
Typically the base type of the histogram is int64_t, so ihistogram was
defined as such.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
"range::is_wrap_around() will not work with current ring_position, because it
relies on total ordering. Same for range::contains(). Currently ring_position
is weakly ordered. This series fixes this problem by making ring_position
totally ordered.
Another problem fixed by this series is handling of wrap-around ranges. In
Origin, ]x; x] is treated as a wrap around range covering whole ring."
"This is the work required to support the clustering order statement.
There is no work needed from the sstables side, because it should just
write whatever we are given by the memtable layer, in the order established
by the memtable layer.
So the work is basically done in the types-level, to support "reversed types",
one concept from Origin we were missing"
If we revert the type of the clustering key, which is what would happen if we
defined the table as with clustering order by (cl desc), we expect the
clustering keys to be in descending order on disk.
There is no work needed for sstables for that to happen. But we should still
verify that this is indeed the case.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
We have the information that they should be reverted, but we are not yet
reverting them. Go ahead and do it
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
First of all, we should abide by our convention of prepending member names with
a '_'. (That is the underline character, it just looks like a face)
But more importantly, because we will be searching its contents frequently, a
helper function is provided.
Note that obviously a hash is better suited for this: but because we do need to
keep the fields in order they are inserted, a vector really is the best choice
for that.
A table is not expected to have a lot of clustering keys. So this search should
be cheap. If it turns out to be a problem, we can adjust later.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
reversed types can be byte_comparable, but in this case we should
invert the order of the comparation.
One alternative here, of course, would be to just declare all reversed types
non-byte comparable. That would definitely be safer, but at the expense of
always having more expensive comparisons for inverted orders.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
A reversed type has an underlying type to which it is equal in every aspect.
Except that it will compare differently: it compares in the reverse order
of its base type.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Actually we should rethrow exceptions because they are needed for
keep_doing() to finish. Otherwise, the future _compaction_done
will never be resolved.
This reverts commit 89698b0d1c.
In Origin, dht.Range() with equal values is considered a full wrap
around. Make our range<> recognize this.
So we have:
]x; x] - wrap around, full ring
[x; x[ - wrap around, full ring
]x; x[ - wrap around, excluding x
[x; x] - not wrap around, only x included
It should be moved to i_partitioner.hh, but to do that range<> has to
be first moved out of query-request.hh to break cyclic dependency.
I didn't want to cause conflicts with in-flight patches to range<>.
range::is_wrap_around() and range::contains() rely on total ordering
on values to work properly. Current ring_position_comparator was only
imposing a weak ordering (token positions equal to all key positions
with that token).
range::before() and range::after() can't work for weak ordering. If
the bound is exclusive, we don't know if user-provided token position
is inside or outside.
Also, is_wrap_around() can't properly detect wrap around in all
cases. Consider this case:
(1) ]A; B]
(2) [A; B]
For A = (tok1) and B = (tok1, key1), (1) is a wrap around and (2) is
not. Without total ordering between A and B, range::is_wrap_around() can't
tell that.
I think the simplest soution is to define a total ordering on
ring_position by making token positions positioned either before or
after all keys with that token.
