wbtiger
/
foundationdb
mirror of https://github.com/apple/foundationdb.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
foundationdb/fdbclient/ClientWorkerInterface.h

87 lines
2.3 KiB
C
Raw Normal View History

Initial repository commit
2017-05-26 04:48:44 +08:00
/*
* ClientWorkerInterface.h
*
* This source file is part of the FoundationDB open source project
*
* Copyright 2013-2018 Apple Inc. and the FoundationDB project authors
remove trailing whitespace from our copyright headers ; fixed formatting of python setup.py
2018-02-22 02:25:11 +08:00
*
Initial repository commit
2017-05-26 04:48:44 +08:00
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
remove trailing whitespace from our copyright headers ; fixed formatting of python setup.py
2018-02-22 02:25:11 +08:00
*
Initial repository commit
2017-05-26 04:48:44 +08:00
* http://www.apache.org/licenses/LICENSE-2.0
remove trailing whitespace from our copyright headers ; fixed formatting of python setup.py
2018-02-22 02:25:11 +08:00
*
Initial repository commit
2017-05-26 04:48:44 +08:00
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
#ifndef FDBCLIENT_CLIENTWORKERINTERFACE_H
#define FDBCLIENT_CLIENTWORKERINTERFACE_H
#pragma once
Adjust all includes to be relative to the root. Remove the use of relative paths. A header at foo/bar.h could be included by files under foo/ with "bar.h", but would be included everywhere else as "foo/bar.h". Adjust so that every include references such a header with the latter form. Signed-off-by: Robert Escriva <rescriva@dropbox.com>
2018-10-20 01:30:13 +08:00
#include "fdbclient/FDBTypes.h"
Initial repository commit
2017-05-26 04:48:44 +08:00
#include "fdbrpc/FailureMonitor.h"
Adjust all includes to be relative to the root. Remove the use of relative paths. A header at foo/bar.h could be included by files under foo/ with "bar.h", but would be included everywhere else as "foo/bar.h". Adjust so that every include references such a header with the latter form. Signed-off-by: Robert Escriva <rescriva@dropbox.com>
2018-10-20 01:30:13 +08:00
#include "fdbclient/Status.h"
#include "fdbclient/ClientDBInfo.h"
Initial repository commit
2017-05-26 04:48:44 +08:00
Move cpuProfilerRequest from WorkerInterface to ClientWorkerInterface. A way to access this stream is required if we wish to be able to toggle profiling from fdbcli. There's two ways to do this: 1. Use `monitorLeader()` to get a `ClusterControllerFullInterface`, and use `getWorkers` from there to get a list of `WorkerInterface`s, from which we can access cpuProfilerRequest. 2. Move cpuProfilerRequest to ClientWorkerInterface and use the existing code in the client that can fetch a list of all `ClientWorkerInterface`s. The split between WorkerInterface and ClientWorkerInterface appears to be what a client might have a need to call versus what is fdbserver-internal (and thus no client should even want to call). Thus, it seems to make more sense to acknowledge that profiling is useful to be able to toggle from a client, and go with option (2).
2017-07-13 15:27:56 +08:00
// Streams from WorkerInterface that are safe and useful to call from a client.
// A ClientWorkerInterface is embedded as the first element of a WorkerInterface.
Initial repository commit
2017-05-26 04:48:44 +08:00
struct ClientWorkerInterface {
RequestStream< struct RebootRequest > reboot;
Add toggleable profiling support to fdbserver+fdbcli. This adds the fdbcli commands: * profile list -- Lists all workers in a way that doesn't fill `kill`'s list. * profile flow run -- Allows starting flow profiling on a set of hosts for a specified interval. And threads through all the support for enabling and disabling profiling as an RPC.
2017-10-12 05:13:16 +08:00
RequestStream< struct ProfilerRequest > profiler;
Move cpuProfilerRequest from WorkerInterface to ClientWorkerInterface. A way to access this stream is required if we wish to be able to toggle profiling from fdbcli. There's two ways to do this: 1. Use `monitorLeader()` to get a `ClusterControllerFullInterface`, and use `getWorkers` from there to get a list of `WorkerInterface`s, from which we can access cpuProfilerRequest. 2. Move cpuProfilerRequest to ClientWorkerInterface and use the existing code in the client that can fetch a list of all `ClientWorkerInterface`s. The split between WorkerInterface and ClientWorkerInterface appears to be what a client might have a need to call versus what is fdbserver-internal (and thus no client should even want to call). Thus, it seems to make more sense to acknowledge that profiling is useful to be able to toggle from a client, and go with option (2).
2017-07-13 15:27:56 +08:00
Initial repository commit
2017-05-26 04:48:44 +08:00
bool operator == (ClientWorkerInterface const& r) const { return id() == r.id(); }
bool operator != (ClientWorkerInterface const& r) const { return id() != r.id(); }
UID id() const { return reboot.getEndpoint().token; }
Change Endpoint::address(NetworkAddress) to vector<NetworkAddress> Extend `Endpoint` class to take multiple NetworkAddresses instead of just one. Hence, to talk to an endpoint instead of one IP:PORT, we'll have multiple IP:PORT pairs. This patch simply adds the field and makes changes to compile the codebase. The first element of of `address` field is used everywhere. Hence the way we talk to remains same with this patch. NOTE: Directly accessing the first memeber of Endpoint::address is unsafe as Endpoint() doesn't enforces non-empty address list. However, since the correctness test pass for now and are anyway replacing all those unsafe accesses with ones considering the whole vector, this patch ignores to access them in safe way.
2018-10-25 05:59:50 +08:00
NetworkAddress address() const { return reboot.getEndpoint().address[0]; }
Initial repository commit
2017-05-26 04:48:44 +08:00
template <class Ar>
void serialize( Ar& ar ) {
Add toggleable profiling support to fdbserver+fdbcli. This adds the fdbcli commands: * profile list -- Lists all workers in a way that doesn't fill `kill`'s list. * profile flow run -- Allows starting flow profiling on a set of hosts for a specified interval. And threads through all the support for enabling and disabling profiling as an RPC.
2017-10-12 05:13:16 +08:00
ar & reboot & profiler;
Initial repository commit
2017-05-26 04:48:44 +08:00
}
};
struct RebootRequest {
bool deleteData;
bool checkData;
Move cpuProfilerRequest from WorkerInterface to ClientWorkerInterface. A way to access this stream is required if we wish to be able to toggle profiling from fdbcli. There's two ways to do this: 1. Use `monitorLeader()` to get a `ClusterControllerFullInterface`, and use `getWorkers` from there to get a list of `WorkerInterface`s, from which we can access cpuProfilerRequest. 2. Move cpuProfilerRequest to ClientWorkerInterface and use the existing code in the client that can fetch a list of all `ClientWorkerInterface`s. The split between WorkerInterface and ClientWorkerInterface appears to be what a client might have a need to call versus what is fdbserver-internal (and thus no client should even want to call). Thus, it seems to make more sense to acknowledge that profiling is useful to be able to toggle from a client, and go with option (2).
2017-07-13 15:27:56 +08:00
Add toggleable profiling support to fdbserver+fdbcli. This adds the fdbcli commands: * profile list -- Lists all workers in a way that doesn't fill `kill`'s list. * profile flow run -- Allows starting flow profiling on a set of hosts for a specified interval. And threads through all the support for enabling and disabling profiling as an RPC.
2017-10-12 05:13:16 +08:00
explicit RebootRequest(bool deleteData = false, bool checkData = false) : deleteData(deleteData), checkData(checkData) {}
Move cpuProfilerRequest from WorkerInterface to ClientWorkerInterface. A way to access this stream is required if we wish to be able to toggle profiling from fdbcli. There's two ways to do this: 1. Use `monitorLeader()` to get a `ClusterControllerFullInterface`, and use `getWorkers` from there to get a list of `WorkerInterface`s, from which we can access cpuProfilerRequest. 2. Move cpuProfilerRequest to ClientWorkerInterface and use the existing code in the client that can fetch a list of all `ClientWorkerInterface`s. The split between WorkerInterface and ClientWorkerInterface appears to be what a client might have a need to call versus what is fdbserver-internal (and thus no client should even want to call). Thus, it seems to make more sense to acknowledge that profiling is useful to be able to toggle from a client, and go with option (2).
2017-07-13 15:27:56 +08:00
Initial repository commit
2017-05-26 04:48:44 +08:00
template <class Ar>
void serialize(Ar& ar) {
ar & deleteData & checkData;
}
};
Move cpuProfilerRequest from WorkerInterface to ClientWorkerInterface. A way to access this stream is required if we wish to be able to toggle profiling from fdbcli. There's two ways to do this: 1. Use `monitorLeader()` to get a `ClusterControllerFullInterface`, and use `getWorkers` from there to get a list of `WorkerInterface`s, from which we can access cpuProfilerRequest. 2. Move cpuProfilerRequest to ClientWorkerInterface and use the existing code in the client that can fetch a list of all `ClientWorkerInterface`s. The split between WorkerInterface and ClientWorkerInterface appears to be what a client might have a need to call versus what is fdbserver-internal (and thus no client should even want to call). Thus, it seems to make more sense to acknowledge that profiling is useful to be able to toggle from a client, and go with option (2).
2017-07-13 15:27:56 +08:00
struct ProfilerRequest {
ReplyPromise<Void> reply;
Add toggleable profiling support to fdbserver+fdbcli. This adds the fdbcli commands: * profile list -- Lists all workers in a way that doesn't fill `kill`'s list. * profile flow run -- Allows starting flow profiling on a set of hosts for a specified interval. And threads through all the support for enabling and disabling profiling as an RPC.
2017-10-12 05:13:16 +08:00
enum class Type : std::int8_t {
GPROF = 1,
FLOW = 2
};
enum class Action : std::int8_t {
DISABLE = 0,
ENABLE = 1,
RUN = 2
};
Type type;
Action action;
int duration;
Move cpuProfilerRequest from WorkerInterface to ClientWorkerInterface. A way to access this stream is required if we wish to be able to toggle profiling from fdbcli. There's two ways to do this: 1. Use `monitorLeader()` to get a `ClusterControllerFullInterface`, and use `getWorkers` from there to get a list of `WorkerInterface`s, from which we can access cpuProfilerRequest. 2. Move cpuProfilerRequest to ClientWorkerInterface and use the existing code in the client that can fetch a list of all `ClientWorkerInterface`s. The split between WorkerInterface and ClientWorkerInterface appears to be what a client might have a need to call versus what is fdbserver-internal (and thus no client should even want to call). Thus, it seems to make more sense to acknowledge that profiling is useful to be able to toggle from a client, and go with option (2).
2017-07-13 15:27:56 +08:00
Standalone<StringRef> outputFile;
template<class Ar>
void serialize( Ar& ar ) {
Add toggleable profiling support to fdbserver+fdbcli. This adds the fdbcli commands: * profile list -- Lists all workers in a way that doesn't fill `kill`'s list. * profile flow run -- Allows starting flow profiling on a set of hosts for a specified interval. And threads through all the support for enabling and disabling profiling as an RPC.
2017-10-12 05:13:16 +08:00
ar & reply & type & action & duration & outputFile;
Move cpuProfilerRequest from WorkerInterface to ClientWorkerInterface. A way to access this stream is required if we wish to be able to toggle profiling from fdbcli. There's two ways to do this: 1. Use `monitorLeader()` to get a `ClusterControllerFullInterface`, and use `getWorkers` from there to get a list of `WorkerInterface`s, from which we can access cpuProfilerRequest. 2. Move cpuProfilerRequest to ClientWorkerInterface and use the existing code in the client that can fetch a list of all `ClientWorkerInterface`s. The split between WorkerInterface and ClientWorkerInterface appears to be what a client might have a need to call versus what is fdbserver-internal (and thus no client should even want to call). Thus, it seems to make more sense to acknowledge that profiling is useful to be able to toggle from a client, and go with option (2).
2017-07-13 15:27:56 +08:00
}
};
Fix a massive amount of valgrind errors and make them easier to debug in the future. std::is_pod<> being less restrictive than is_binary_serializable<> meant that structs that both were POD and had a serialize method defined would be binary serialized instead of using the defined serialize(). This means that it would also serialize any padding that the struct contained, which would cause mass waves of valgrind failures from uninitialized memory. Included in this change is additional uses of valgrind client requests so that attempts to send uninitialized memory are reported at the sending site, versus as part of checksum calculation in sending the packet.
2017-10-28 07:54:44 +08:00
BINARY_SERIALIZABLE( ProfilerRequest::Type );
BINARY_SERIALIZABLE( ProfilerRequest::Action );
Move cpuProfilerRequest from WorkerInterface to ClientWorkerInterface. A way to access this stream is required if we wish to be able to toggle profiling from fdbcli. There's two ways to do this: 1. Use `monitorLeader()` to get a `ClusterControllerFullInterface`, and use `getWorkers` from there to get a list of `WorkerInterface`s, from which we can access cpuProfilerRequest. 2. Move cpuProfilerRequest to ClientWorkerInterface and use the existing code in the client that can fetch a list of all `ClientWorkerInterface`s. The split between WorkerInterface and ClientWorkerInterface appears to be what a client might have a need to call versus what is fdbserver-internal (and thus no client should even want to call). Thus, it seems to make more sense to acknowledge that profiling is useful to be able to toggle from a client, and go with option (2).
2017-07-13 15:27:56 +08:00
#endif