If a user tries to configure a non-existant logger, he gets an obscure error
message:
$ scylla --logger-log-level nonexistant=info
Exiting on unhandled exception of type 'std::out_of_range': _Map_base::at
With this patch,
$ scylla --logger-log-level nonexistant=info
Exiting on unhandled exception of type 'std::runtime_error':
Unknown logger 'nonexistant'. Use --help-loggers to list available loggers.
Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
If someone uses "--logger-log-level" with an unknown log level, e.g.,
"--logger-log-level repair=hello", the exception currently reported to the
user is:
bad lexical cast: source type value could not be interpreted as target
In a long command line, the user has no idea where this exception is coming
from. This patches catches this exception, and instead reports a runtime_error
with the text:
Unknown log level 'hello'
Which hopefully should be much more user friendly.
Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
In preparation for adding listener state to migration manager, use
sharded<> for migration manager.
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Calling the logger 'main' may cause confusion to external readers not familiar
with the source code, since there is nothing 'main' about this logger in
particular - that is just the file name.
It is then called the start up log.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
The same way we create a directory for the sstables, we should do it for the
commitlog.
If you, like me, have been using the --datadir directive, the fact that we
don't do it would have slipped away: when using --datadir, both the commitlog
and sstables will be put in this same root.
However, when using the system defaults from the configuration file, this won't
be true.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Our main has a "on_terminate()" to make sure it exits when there is an
exception during initialization, instead of hanging. But it's in the
wrong place - it needs to be on the outer future.
Before this patch, an error parsing the command line will result in
a "WARNING: exceptional future ignored ..." and a hang, instead of a
"Exiting on unhandled exception..." and an exit as we get after this
patch.
Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
This patch introduce init.cc file which hosts all the initialization
code. The benefits are 1) we can share initialization code with tests
code. 2) all the service startup dependency / order code is in one
single place instead of everywhere.
We must wait for the system tables to be loaded on all shards before
populating the other keyspaces, or we might miss some keyspaces or column
families. This is hinted at by the fact that we use storage_proxy, which
isn't usable until the system keyspace is ready.
Credit to Tomek for identifying the problem and the fix.
All sharded services "should" define a stop method. Calling them is also
a good practice.
Blindly calling it at exit is wrong, but it is less wrong than not calling
it at all, and makes it now equally as wrong as any of the other services.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
All sharded services "should" define a stop method. Calling them is also
a good practice.
Blindly calling it at exit is wrong, but it is less wrong than not calling
it at all, and makes it now equally as wrong as any of the other services.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
The functionality is similar to RuntimeMBean.getUptime() that's needed
in schema pulling logic.
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Make storage proxy a singleton and add helpers to look up a reference.
This makes it easier to convert code from Origin in areas such as
storage service.
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
"This series adds the storage proxy metrics API. The definition are based on the
StorageProxyMetrics definition. This series also adds stats object to the
storage_proxy a getter function for it and an implementation based on it, but
it is currently does not adds the code to manipulate the counters."
The API needs to call the storage_proxy, for that a reference to the
distribute storage_proxy is added to the context and is set in main.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
Right now when we initiate the database, we exist with just an exception if the
data directory does not exist. That does not tell much to the user about what
is going on.
It would be nice to at the very least catch the exception and turn it into a
user friendly message. But we can obviously do much better and create the
directory.
If we fail, then we can capture and tell the user why.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
We won't create our own versions of database and query_proxy, so we need
some setup to be done. The current code will capture those variables and
setup the structure used to conduct the queries. Later on, it will also
carry on the database's basic setup.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
The messaging service is initialized very early, before we have the
proxy or query processor initialized. It is mostly fine, except for
the fact that the messaging service also finishes the initialization
of the storage service. That part will issue queries agains the system
tables, (as soon as we support them), and need to happen later.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
In order for us to call some function from db::legacy_schema_tables, we need
a working storage proxy. We will use those functions in order to leverage the
work done in keyspace / table creation from mutations
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Soon I will introduce some changes that make init_from_data_directory dependent
on a working storage proxy.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
This patch adds support to the Swagger-UI. It does so by adding
reference to the Swagger-UI target directory, after applying this patch
/ui/ will display the Swagger-UI page with the available APIs.
From the Swagger-UI page it is possible to run the different APIs.
The target directory of the ui can be override from the command line.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
Snitch class semantics defined to be per-Node. To make it so we
introduce here a static member in an i_endpoint_snitch class that
has to contain the pointer to the relevant snitch class instance.
Since the snitch contents are not always pure const it has to be per
shard, therefore we'll make it a "distributed". All the I/O is going
to take place on a single shard and if there are changes - they are going
to be propagated to the rest of the shards.
The application is responsible to initialize this distributed<shnitch>
before it's used for the first time.
This patch effectively reverts most of the "locator: futurize
snitch creation" a2594015f9 patch - the part that modifies the
code that was creating the snitch instance. Since snitch is
created explicitly by the application and all the rest of the code
simply assumes that the above global is initialized we won't need
all those changes any more and the code will get back to be nice and simple
as it was before the patch above.
So, to summarize, this patch does the following:
- Reverts the changes introduced by a2594015f9 related to the fact that
every time a replication strategy was created there should have been created
a snitch that would have been stored in this strategy object. More specifically,
methods like keyspace::create_replication_strategy() do not return a future<>
any more and this allows to simplify the code that calls it significantly.
- Introduce the global distributed<snitch_ptr> object:
- It belongs to the i_endpoint_snitch class.
- There has been added a corresponding interface to access both global and
shard-local instances.
- locator::abstract_replication_strategy::create_replication_strategy() does
not accept snitch_ptr&& - it'll get and pass the corresponding shard-local
instance of the snitch to the replication strategy's constructor by itself.
- Adjusted the existing snitch infrastructure to the new semantics:
- Modified the create_snitch() to create and start all per-shard snitch
instances and update the global variable.
- Introduced a static i_endpoint_snitch::stop_snitch() function that properly
stops the global distributed snitch.
- Added the code to the gossiping_property_file_snitch that distributes the
changed data to all per-shard snitch objects.
- Made all existing snitches classes properly maintain their state in order
to be able to shut down cleanly.
- Patched both urchin and cql_query_test to initialize a snitch instance before
all other services.
Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
New in v6:
- Rebased to the current master.
- Extended a commit message a little - the summary.
New in v5:
- database::create_keyspace(): added a missing _keyspaces.emplace()
New in v4:
- Kept the database::create_keyspace() to return future<> by Glauber's request
and added a description to this method that needs to be changed when Glauber
adds his bits that require this interface.
Moved setting of configuration variables after the configuration file
has been read.
Updated the code parsing seeds to comply with configuration file format
- seeds: <ip1>,<ip2>,<ip3>
Signed-off-by: Shlomi Livne <shlomi@cloudius-systems.com>
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.
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.
The API needs the database distribute object to get information from it.
This adds a database reference the API context so it would be
available in the API.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
