From Glauber:
"Here are some fixes for the sstables write path. The code is made
simpler by mainly:
- taking advantage of the fact that we don't have to chain futures
that will do nothing more than write a value to the output stream.
The compiler will do that for us if we use the recursive template
interface,
- moving most of the composite logic to sstable/key.cc.
The last one has the interesting side effect of making the code correct.
A nice bonus."
The column_name can be comprised of more than one element. This will
be the case for collections, that will embed part of the collection
data in the column name.
While doing this, we also take advantage of the infrastructure we have
added to composite. We are duplicating this logic unnecessarily, which
is prone to bugs. Those bugs are not just theoretical in this case: the
static prefix is not "followed by a null composite, i.e. three null bytes."
as the code implies.
The static prefix is created by appending one empty element for each element in
the clustering key, and will only be three null bytes in the case where the
clustering key has one element.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
The column_name can be comprised of more than one element. This will
be the case for collections, that will embed part of the collection
data in the column name.
While doing this, we also take advantage of the infrastructure we have
added to composite. We are duplicating this logic unnecessarily, which
is prone to bugs. Those bugs are not just theoretical in this case: we
are not writing the final marker for empty composite keys.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Encapsulating it into a composite class is a more natural way to handle this,
and will allow for extending that class later.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Make sure keyspace exists for all test cases, not just ones that call
the create_table() helper.
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
This implement the gossipier API. All actions perform on the local
gossiper.
The following functionality is supported:
/gossiper/downtime/{addr}
/gossiper/generation_number/{addr}
/gossiper/assassinate/{addr}
The following are extened API beyond the MBean definition:
/gossiper/endpoint/down
/gossiper/endpoint/live
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
The current gossiper implementation runs the gossiper on CPU 0, this is
irelevent to user of the gossiper, that may want to inquire it.
This adds a globally available API for get_unreachable_members,
get_live_members, get_endpoint_downtime, get_current_generation_number,
unsafe_assassinate_endpoint and assassinate_endpoint that returns a
future and perform on the correct CPU.
The target user is the API that would use this function to expose the
gossiper.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
Before sealing an sstable, here's what we have to do, filter-wise:
1) determine wether or not we should have a filter file. We won't write
one, if our fp_chance is 1.0,
2) add each index key to the filter,
3) and write the actual filter.
This patch implements those steps.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Store a lw_shared_ptr<keyspace_metadata> in struct keyspace so callers
in migration manager, for example, can look it up.
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
While trying to write code to populate the system table's data, I found out
that currently, there is no publicly exported way for an entity outside the
sstable to find out which are the keys available in the index.
Without the full list of keys, it is very hard to make the kind of
"read-everything" queries we will need for that to work.
Although I haven't checked the internals fully, Origin seems to do that through
token-based range searches, where you can specify start and end tokens and
return everything in the middle (this is how the WHERE clauses are
implemented).
I am proposing in this patchset a subscription interface that will allow us
to extract data from the sstables in this fashion.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
The current code for position determination works well if we are in the
last summary group. For the ones in the middle, it won't.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
The readability improvements alone justify it, but on top of that, I would like
to reuse this one.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
It would be helpful to sometimes avoid passing a key parameter from the
consumer, since we not always know what to expect. In those situations, we can
easily construct it from the data we see in consume_row_start.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
This is my turn to make the same mistake as Nadav recently made: I have
written down the expected position from the test output itself, instead
of checking the file.
A position of 0x400c0000000000 is obviously ridiculous. The file itself is not
that big. My recent patch to fix the summary broke the test, and so we need to
fix it.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Since that whole entries array is memory mapped, we should not call
read_integer - which will byteswap it.
We should instead just fetch the position directly.
This was not spotted before because our test sstables tend to be relatively
small.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Currently if you run more than one instance on the same machine, they
all bind to the same local address and port (we enable an option that
makes this non error) and cql/thrift requests are distributed randomly
among them.
Some urchin parameters has default value of localhost and need to be
resolved into IP address. Add stub resolver that do just that: if it
sees "localhost" string it translates it to a loopback address,
otherwise assume that string is IP address already.
