mirror of https://github.com/grpc/grpc.git
Muxi Yan
8 years ago
commit
43944082da
785 changed files with 48723 additions and 14048 deletions
@ -0,0 +1,121 @@ |
||||
# `epoll`-based pollset implementation in gRPC |
||||
|
||||
Sree Kuchibhotla (sreek@) [May - 2016] |
||||
(Design input from Craig Tiller and David Klempner) |
||||
|
||||
> Status: As of June 2016, this change is implemented and merged. |
||||
|
||||
> * The bulk of the functionality is in: [ev_poll_linux.c](https://github.com/grpc/grpc/blob/master/src/core/lib/iomgr/ev_epoll_linux.c) |
||||
> * Pull request: https://github.com/grpc/grpc/pull/6803 |
||||
|
||||
## 1. Introduction |
||||
The document talks about the proposed changes to `epoll`-based implementation of pollsets in gRPC. Section-2 gives an overview of the current implementation, Section-3 talks about the problems in the current implementation and finally Section-4 talks about the proposed changes. |
||||
|
||||
## 2. Current `epoll`-based implementation in gRPC |
||||
|
||||
 |
||||
|
||||
**Figure 1: Current implementation** |
||||
|
||||
A gRPC client or a server can have more than one completion queue. Each completion queue creates a pollset. |
||||
|
||||
The gRPC core library does not create any threads[^1] on its own and relies on the application using the gRPC core library to provide the threads. A thread starts to poll for events by calling the gRPC core surface APIs `grpc_completion_queue_next()` or `grpc_completion_queue_pluck()`. More than one thread can call `grpc_completion_queue_next()`on the same completion queue[^2]. |
||||
|
||||
A file descriptor can be in more than one completion queue. There are examples in the next section that show how this can happen. |
||||
|
||||
When an event of interest happens in a pollset, multiple threads are woken up and there are no guarantees on which thread actually ends up performing the work i.e executing the callbacks associated with that event. The thread that performs the work finally queues a completion event `grpc_cq_completion` on the appropriate completion queue and "kicks" (i.e wakes ups) the thread that is actually interested in that event (which can be itself - in which case there is no thread hop) |
||||
|
||||
For example, in **Figure 1**, if `fd1` becomes readable, any one of the threads i.e *Threads 1* to *Threads K* or *Thread P*, might be woken up. Let's say *Thread P* was calling a `grpc_completion_queue_pluck()` and was actually interested in the event on `fd1` but *Thread 1* woke up. In this case, *Thread 1* executes the callbacks and finally kicks *Thread P* by signalling `event_fd_P`. *Thread P* wakes up, realizes that there is a new completion event for it and returns from `grpc_completion_queue_pluck()` to its caller. |
||||
|
||||
## 3. Issues in the current architecture |
||||
|
||||
### _Thundering Herds_ |
||||
|
||||
If multiple threads concurrently call `epoll_wait()`, we are guaranteed that only one thread is woken up if one of the `fds` in the set becomes readable/writable. However, in our current implementation, the threads do not directly call a blocking `epoll_wait()`[^3]. Instead, they call `poll()` on the set containing `[event_fd`[^4]`, epoll_fd]`. **(see Figure 1)** |
||||
|
||||
Considering the fact that an `fd` can be in multiple `pollsets` and that each `pollset` might have multiple poller threads, it means that whenever an `fd` becomes readable/writable, all the threads in all the `pollsets` (in which that `fd` is present) are woken up. |
||||
|
||||
The performance impact of this would be more conspicuous on the server side. Here are a two examples of thundering herds on the server side. |
||||
|
||||
Example 1: Listening fds on server |
||||
|
||||
* A gRPC server can have multiple server completion queues (i.e completion queues which are used to listen for incoming channels). |
||||
* A gRPC server can also listen on more than one TCP-port. |
||||
* A listening socket is created for each port the gRPC server would be listening on. |
||||
* Every listening socket's fd is added to all the server completion queues' pollsets. (Currently we do not do any sharding of the listening fds across these pollsets). |
||||
|
||||
This means that for every incoming new channel, all the threads waiting on all the pollsets are woken up. |
||||
|
||||
Example 2: New Incoming-channel fds on server |
||||
|
||||
* Currently, every new incoming channel's `fd` (i.e the socket `fd` that is returned by doing an `accept()` on the new incoming channel) is added to all the server completion queues' pollsets [^5]). |
||||
* Clearly, this would also cause all thundering herd problem for every read onthat fd |
||||
|
||||
There are other scenarios especially on the client side where an fd can end up being on multiple pollsets which would cause thundering herds on the clients. |
||||
|
||||
|
||||
## 4. Proposed changes to the current `epoll`-based polling implementation: |
||||
|
||||
The main idea in this proposal is to group 'related' `fds` into a single epoll-based set. This would ensure that only one thread wakes up in case of an event on one of the `fds` in the epoll set. |
||||
|
||||
To accomplish this, we introduce a new abstraction called `polling_island` which will have an epoll set underneath (See **Figure 2** below). A `polling_island` contains the following: |
||||
|
||||
* `epoll_fd`: The file descriptor of the underlying epoll set |
||||
* `fd_set`: The set of 'fds' in the pollset island i.e in the epoll set (The pollset island merging operation described later requires the list of fds in the pollset island and currently there is no API available to enumerate all the fds in an epoll set) |
||||
* `event_fd`: A level triggered _event fd_ that is used to wake up all the threads waiting on this epoll set (Note: This `event_fd` is added to the underlying epoll set during pollset island creation. This is useful in the pollset island merging operation described later) |
||||
* `merged_to`: The polling island into which this one merged. See section 4.2 (case 2) for more details on this. Also note that if `merged_to` is set, all the other fields in this polling island are not used anymore |
||||
|
||||
In this new model, only one thread wakes up whenever an event of interest happens in an epoll set. |
||||
|
||||
 |
||||
|
||||
**Figure 2: Proposed changes** |
||||
|
||||
### 4.1 Relation between `fd`, `pollset` and `polling_island:` |
||||
|
||||
* An `fd` may belong to multiple `pollsets` but belongs to exactly one `polling_island` |
||||
* A `pollset` belongs to exactly one `polling_island` |
||||
* An `fd` and the `pollset(s`) it belongs to, have same `polling_island` |
||||
|
||||
### 4.2 Algorithm to add an `fd` to a `pollset` |
||||
|
||||
There are two cases to check here: |
||||
|
||||
* **Case 1:** Both `fd` and `pollset` already belong to the same `polling_island` |
||||
* This is straightforward and nothing really needs to be done here |
||||
* **Case 2:** The `fd `and `pollset` point to different `polling_islands`: In this case we _merge_ both the polling islands i.e: |
||||
* Add all the `fds` from the smaller `polling_island `to the larger `polling_island` and update the `merged_to` pointer on the smaller island to point to the larger island. |
||||
* Wake up all the threads waiting on the smaller `polling_island`'s `epoll_fd` (by signalling the `event_fd` on that island) and make them now wait on the larger `polling_island`'s `epoll_fd` |
||||
* Update `fd` and `pollset` to now point to the larger `polling_island` |
||||
|
||||
### 4.3 Directed wakeups: |
||||
|
||||
The new implementation, just like the current implementation, does not provide us any guarantees that the thread that is woken up is the thread that is actually interested in the event. So the thread that woke up executes the callbacks and finally has to 'kick' the appropriate polling thread interested in the event. |
||||
|
||||
In the current implementation, every polling thread also had a `event_fd` on which it was listening to and hence waking it up was as simple as signalling that `event_fd`. However, using an `event_fd` also meant that every thread has to use a `poll()` (on `event_fd` and `epoll_fd`) instead of doing an `epoll_wait()` and this resulted in the thundering herd problems described above. |
||||
|
||||
The proposal here is to use signals and kicking a thread would just be sending a signal to that thread. Unfortunately there are only a few signals available on posix systems and most of them have pre-determined behavior leaving only a few signals `SIGUSR1`, `SIGUSR2` and `SIGRTx (SIGRTMIN to SIGRTMAX)` for custom use. |
||||
|
||||
The calling application might have registered other signal handlers for these signals. `We will provide a new API where the applications can "give a signal number" to gRPC library to use for this purpose. |
||||
|
||||
``` |
||||
void grpc_use_signal(int signal_num) |
||||
``` |
||||
|
||||
If the calling application does not provide a signal number, then the gRPC library will relegate to using a model similar to the current implementation (where every thread does a blocking `poll()` on its `wakeup_fd` and the `epoll_fd`). The function` psi_wait() `in figure 2 implements this logic. |
||||
|
||||
**>> **(**NOTE**: Or alternatively, we can implement a turnstile polling (i.e having only one thread calling `epoll_wait()` on the epoll set at any time - which all other threads call poll on their `wakeup_fds`) |
||||
in case of not getting a signal number from the applications. |
||||
|
||||
|
||||
## Notes |
||||
|
||||
[^1]: Only exception is in case of name-resolution |
||||
|
||||
[^2]: However, a `grpc_completion_queue_next()` and `grpc_completion_queue_pluck()` must not be called in parallel on the same completion queue |
||||
|
||||
[^3]: The threads first do a blocking` poll()` with `[wakeup_fd, epoll_fd]`. If the `poll()` returns due to an event of interest in the epoll set, they then call a non-blocking i.e a zero-timeout `epoll_wait()` on the `epoll_fd` |
||||
|
||||
[^4]: `event_fd` is the linux platform specific implementation of `grpc_wakeup_fd`. A `wakeup_fd` is used to wake up polling threads typically when the event for which the polling thread is waiting is already completed by some other thread. It is also used to wake up the polling threads in case of shutdowns or to re-evaluate the poller's interest in the fds to poll (the last scenario is only in case of `poll`-based (not `epoll`-based) implementation of `pollsets`). |
||||
|
||||
[^5]: See more details about the issue here https://github.com/grpc/grpc/issues/5470 and for a proposed fix here: https://github.com/grpc/grpc/pull/6149 |
||||
|
After Width: | Height: | Size: 52 KiB |
|
After Width: | Height: | Size: 44 KiB |
|
After Width: | Height: | Size: 62 KiB |
@ -0,0 +1,92 @@ |
||||
# Stress Test framework for gRPC |
||||
|
||||
(Sree Kuchibhotla - sreek@) |
||||
|
||||
> Status: This is implemented. More details at [README.md](https://github.com/grpc/grpc/blob/master/tools/run_tests/stress_test/README.md) |
||||
|
||||
|
||||
**I. GOALS** |
||||
|
||||
1) Build a stress test suite for gRPC: |
||||
|
||||
* Build a stress test suite that can Identify bugs by testing the system (gRPC server/client) under extreme conditions: |
||||
* High load |
||||
* High concurrency |
||||
* Limited resources |
||||
* Intermittent failures |
||||
* Should be integrated with Jenkins CI |
||||
|
||||
2) Make it generic enough (i.e build a generic test framework) that can be used for: |
||||
|
||||
* Executing M instances of a client against N instances of a server with an arbitrarily defined connection matrix |
||||
* Execute heterogenous test configurations - for example: Java stress test clients against C++ servers or Node clients against Python servers or TSAN C++ clients vs ASAN C++ Servers etc. |
||||
* Easy and Flexible enough that Devs can use it to recreate complex test scenarios |
||||
|
||||
The implementation effort is divided into two parts: |
||||
|
||||
* Building a "Stress Test Framework" to run the stress test suites- More details in **Section II** (The idea is that the Stress Test framework is generic enough that it would be easier to modify it to run other suites like interop-tests or custom test scenarios) |
||||
* Building a 'Stress test suite' - More details in **section III** |
||||
|
||||
**Terminology:** |
||||
|
||||
GCE - Google compute engine |
||||
GKE - Google Container engine |
||||
Kubernetes - Google's open source service scheduler / orchestrator. |
||||
|
||||
**Note:** The terms GKE and Kubernetes are used interchangeably in this document |
||||
|
||||
# II. STRESS TEST FRAMEWORK |
||||
|
||||
(The details of each step are explained below)) |
||||
 |
||||
**Figure 1** |
||||
|
||||
### Step 1 Read the test config, generate base docker images |
||||
|
||||
**_Test Config:_** The test configuration contains the following information: |
||||
|
||||
* _GKE info:_ GKE project and cluster info |
||||
* _Docker images:_ Instructions to build docker images |
||||
* _Client templates:_ One or more client templates each containing the following information: |
||||
* Which docker image to use |
||||
* Path to the client program to launch (within the docker image) |
||||
* Parameters to the client program |
||||
* _Server templates:_ Similar to Client templates - except that these are for servers |
||||
* Test matrix containing the following: |
||||
* _Server groups:_ One or more groups of servers containing the following info for each group |
||||
* Which server template to use |
||||
* How many instances to launch |
||||
* _Client groups:_ One or more groups of clients containing the following (for each group): |
||||
* Which client template to use |
||||
* How many instances to launch |
||||
* Which server group to talk to (all clients in this group will talk to all servers in the server group) |
||||
|
||||
The first step is to read the test config and build the docker images |
||||
|
||||
**_Stress server docker image:_** The following are the main files in the server docker images |
||||
|
||||
* _Interop_server:_ The server program |
||||
* `run_server.py`: This is a python script which is the entry point of the docker image (i.e this is the script that is called when the docker image is run in GKE). This script launches the interop server and also updates the status in BigQuery. If the interop_server fails for whatever reason, the script launch_server.py logs that status in BigQuery |
||||
|
||||
**_Stress client docker image:_** |
||||
|
||||
* Stress client: The stress test client. In addition to talking to the interop_server, the stress client also exports metrics (which can be queried by the metrics_client described below) |
||||
* Metrics client: Metrics client connects to the stress_client to get the current qps metrics. |
||||
* `run_client.py`: This is a python script which is the entry point of the docker image (i.e this is the script that is called when the docker image is run in GKE). This script launches the stress client and also updates the status in BigQuery. The script then periodically launches metrics client to query the qps from the stress client and then uploads the qps to BigQuery. |
||||
|
||||
### Step 2) Upload the docker images to GKE |
||||
The docker images are uploaded to the GKE registry |
||||
|
||||
### Step 3) Launch the tests in GKE |
||||
The test driver reads the test matrix (described in step 1) and creates the necessary server and client pods in GKE. |
||||
|
||||
### Step 4) Tests are run in GKE |
||||
GKE starts running the tests by calling the entry points in *each* docker image (i.e `run_server.py` or `run_client.py` depending on whcih docker image it is) |
||||
|
||||
### Step 5) Upload the status to GKE and Monitor the status in GKE |
||||
* 5.1 The tests periodically update their status in BigQuery |
||||
* 5.2 The test driver periodically checks the status in Bigquery to see if any tests failed. If any tests failed, the driver immediately stops the tests. If not, the driver continues to run the tests for a configurable amount of time. |
||||
|
||||
### Step 6) Create a summary report |
||||
The test driver creates a final summary report containing details about any test failures and information about how to connect the failed pods in GKE for debugging. |
||||
|
||||
@ -0,0 +1,70 @@ |
||||
/*
|
||||
* |
||||
* Copyright 2016, Google Inc. |
||||
* All rights reserved. |
||||
* |
||||
* Redistribution and use in source and binary forms, with or without |
||||
* modification, are permitted provided that the following conditions are |
||||
* met: |
||||
* |
||||
* * Redistributions of source code must retain the above copyright |
||||
* notice, this list of conditions and the following disclaimer. |
||||
* * Redistributions in binary form must reproduce the above |
||||
* copyright notice, this list of conditions and the following disclaimer |
||||
* in the documentation and/or other materials provided with the |
||||
* distribution. |
||||
* * Neither the name of Google Inc. nor the names of its |
||||
* contributors may be used to endorse or promote products derived from |
||||
* this software without specific prior written permission. |
||||
* |
||||
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS |
||||
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT |
||||
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR |
||||
* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT |
||||
* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, |
||||
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT |
||||
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, |
||||
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY |
||||
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT |
||||
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE |
||||
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. |
||||
* |
||||
*/ |
||||
|
||||
#ifndef GRPCXX_RESOURCE_QUOTA_H |
||||
#define GRPCXX_RESOURCE_QUOTA_H |
||||
|
||||
struct grpc_resource_quota; |
||||
|
||||
#include <grpc++/impl/codegen/config.h> |
||||
|
||||
namespace grpc { |
||||
|
||||
/// ResourceQuota represents a bound on memory usage by the gRPC library.
|
||||
/// A ResourceQuota can be attached to a server (via ServerBuilder), or a client
|
||||
/// channel (via ChannelArguments). gRPC will attempt to keep memory used by
|
||||
/// all attached entities below the ResourceQuota bound.
|
||||
class ResourceQuota GRPC_FINAL { |
||||
public: |
||||
explicit ResourceQuota(const grpc::string& name); |
||||
ResourceQuota(); |
||||
~ResourceQuota(); |
||||
|
||||
/// Resize this ResourceQuota to a new size. If new_size is smaller than the
|
||||
/// current size of the pool, memory usage will be monotonically decreased
|
||||
/// until it falls under new_size. No time bound is given for this to occur
|
||||
/// however.
|
||||
ResourceQuota& Resize(size_t new_size); |
||||
|
||||
grpc_resource_quota* c_resource_quota() const { return impl_; } |
||||
|
||||
private: |
||||
ResourceQuota(const ResourceQuota& rhs); |
||||
ResourceQuota& operator=(const ResourceQuota& rhs); |
||||
|
||||
grpc_resource_quota* const impl_; |
||||
}; |
||||
|
||||
} // namespace grpc
|
||||
|
||||
#endif // GRPCXX_RESOURCE_QUOTA_H
|
||||
@ -0,0 +1,67 @@ |
||||
/*
|
||||
* |
||||
* Copyright 2016, Google Inc. |
||||
* All rights reserved. |
||||
* |
||||
* Redistribution and use in source and binary forms, with or without |
||||
* modification, are permitted provided that the following conditions are |
||||
* met: |
||||
* |
||||
* * Redistributions of source code must retain the above copyright |
||||
* notice, this list of conditions and the following disclaimer. |
||||
* * Redistributions in binary form must reproduce the above |
||||
* copyright notice, this list of conditions and the following disclaimer |
||||
* in the documentation and/or other materials provided with the |
||||
* distribution. |
||||
* * Neither the name of Google Inc. nor the names of its |
||||
* contributors may be used to endorse or promote products derived from |
||||
* this software without specific prior written permission. |
||||
* |
||||
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS |
||||
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT |
||||
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR |
||||
* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT |
||||
* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, |
||||
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT |
||||
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, |
||||
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY |
||||
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT |
||||
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE |
||||
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. |
||||
* |
||||
*/ |
||||
|
||||
#ifndef GRPCXX_TEST_SERVER_CONTEXT_TEST_SPOUSE_H |
||||
#define GRPCXX_TEST_SERVER_CONTEXT_TEST_SPOUSE_H |
||||
|
||||
#include <map> |
||||
|
||||
#include <grpc++/server_context.h> |
||||
|
||||
namespace grpc { |
||||
namespace testing { |
||||
|
||||
// A test-only class to access private members and methods of ServerContext.
|
||||
class ServerContextTestSpouse { |
||||
public: |
||||
explicit ServerContextTestSpouse(ServerContext* ctx) : ctx_(ctx) {} |
||||
|
||||
// Inject client metadata to the ServerContext for the test. The test spouse
|
||||
// must be alive when ServerContext::client_metadata is called.
|
||||
void AddClientMetadata(const grpc::string& key, const grpc::string& value); |
||||
std::multimap<grpc::string, grpc::string> GetInitialMetadata() const { |
||||
return ctx_->initial_metadata_; |
||||
} |
||||
std::multimap<grpc::string, grpc::string> GetTrailingMetadata() const { |
||||
return ctx_->trailing_metadata_; |
||||
} |
||||
|
||||
private: |
||||
ServerContext* ctx_; // not owned
|
||||
std::multimap<grpc::string, grpc::string> client_metadata_storage_; |
||||
}; |
||||
|
||||
} // namespace testing
|
||||
} // namespace grpc
|
||||
|
||||
#endif // GRPCXX_TEST_SERVER_CONTEXT_TEST_SPOUSE_H
|
||||
@ -1,94 +0,0 @@ |
||||
//
|
||||
// Copyright 2015, Google Inc.
|
||||
// All rights reserved.
|
||||
//
|
||||
// Redistribution and use in source and binary forms, with or without
|
||||
// modification, are permitted provided that the following conditions are
|
||||
// met:
|
||||
//
|
||||
// * Redistributions of source code must retain the above copyright
|
||||
// notice, this list of conditions and the following disclaimer.
|
||||
// * Redistributions in binary form must reproduce the above
|
||||
// copyright notice, this list of conditions and the following disclaimer
|
||||
// in the documentation and/or other materials provided with the
|
||||
// distribution.
|
||||
// * Neither the name of Google Inc. nor the names of its
|
||||
// contributors may be used to endorse or promote products derived from
|
||||
// this software without specific prior written permission.
|
||||
//
|
||||
// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
||||
// "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
||||
// LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
|
||||
// A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
|
||||
// OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
||||
// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
|
||||
// LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
||||
// DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
||||
// THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
||||
// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
|
||||
// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
||||
//
|
||||
|
||||
#include "src/core/ext/client_config/resolver_result.h" |
||||
|
||||
#include <string.h> |
||||
|
||||
#include <grpc/support/alloc.h> |
||||
#include <grpc/support/string_util.h> |
||||
|
||||
#include "src/core/lib/channel/channel_args.h" |
||||
|
||||
struct grpc_resolver_result { |
||||
gpr_refcount refs; |
||||
char* server_name; |
||||
grpc_lb_addresses* addresses; |
||||
char* lb_policy_name; |
||||
grpc_channel_args* lb_policy_args; |
||||
}; |
||||
|
||||
grpc_resolver_result* grpc_resolver_result_create( |
||||
const char* server_name, grpc_lb_addresses* addresses, |
||||
const char* lb_policy_name, grpc_channel_args* lb_policy_args) { |
||||
grpc_resolver_result* result = gpr_malloc(sizeof(*result)); |
||||
memset(result, 0, sizeof(*result)); |
||||
gpr_ref_init(&result->refs, 1); |
||||
result->server_name = gpr_strdup(server_name); |
||||
result->addresses = addresses; |
||||
result->lb_policy_name = gpr_strdup(lb_policy_name); |
||||
result->lb_policy_args = lb_policy_args; |
||||
return result; |
||||
} |
||||
|
||||
void grpc_resolver_result_ref(grpc_resolver_result* result) { |
||||
gpr_ref(&result->refs); |
||||
} |
||||
|
||||
void grpc_resolver_result_unref(grpc_exec_ctx* exec_ctx, |
||||
grpc_resolver_result* result) { |
||||
if (gpr_unref(&result->refs)) { |
||||
gpr_free(result->server_name); |
||||
grpc_lb_addresses_destroy(result->addresses, NULL /* user_data_destroy */); |
||||
gpr_free(result->lb_policy_name); |
||||
grpc_channel_args_destroy(result->lb_policy_args); |
||||
gpr_free(result); |
||||
} |
||||
} |
||||
|
||||
const char* grpc_resolver_result_get_server_name(grpc_resolver_result* result) { |
||||
return result->server_name; |
||||
} |
||||
|
||||
grpc_lb_addresses* grpc_resolver_result_get_addresses( |
||||
grpc_resolver_result* result) { |
||||
return result->addresses; |
||||
} |
||||
|
||||
const char* grpc_resolver_result_get_lb_policy_name( |
||||
grpc_resolver_result* result) { |
||||
return result->lb_policy_name; |
||||
} |
||||
|
||||
grpc_channel_args* grpc_resolver_result_get_lb_policy_args( |
||||
grpc_resolver_result* result) { |
||||
return result->lb_policy_args; |
||||
} |
||||
@ -1,74 +0,0 @@ |
||||
//
|
||||
// Copyright 2015, Google Inc.
|
||||
// All rights reserved.
|
||||
//
|
||||
// Redistribution and use in source and binary forms, with or without
|
||||
// modification, are permitted provided that the following conditions are
|
||||
// met:
|
||||
//
|
||||
// * Redistributions of source code must retain the above copyright
|
||||
// notice, this list of conditions and the following disclaimer.
|
||||
// * Redistributions in binary form must reproduce the above
|
||||
// copyright notice, this list of conditions and the following disclaimer
|
||||
// in the documentation and/or other materials provided with the
|
||||
// distribution.
|
||||
// * Neither the name of Google Inc. nor the names of its
|
||||
// contributors may be used to endorse or promote products derived from
|
||||
// this software without specific prior written permission.
|
||||
//
|
||||
// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
||||
// "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
||||
// LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
|
||||
// A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
|
||||
// OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
||||
// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
|
||||
// LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
||||
// DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
||||
// THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
||||
// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
|
||||
// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
||||
//
|
||||
|
||||
#ifndef GRPC_CORE_EXT_CLIENT_CONFIG_RESOLVER_RESULT_H |
||||
#define GRPC_CORE_EXT_CLIENT_CONFIG_RESOLVER_RESULT_H |
||||
|
||||
#include "src/core/ext/client_config/lb_policy_factory.h" |
||||
#include "src/core/lib/iomgr/resolve_address.h" |
||||
|
||||
// TODO(roth, ctiller): In the long term, we are considering replacing
|
||||
// the resolver_result data structure with grpc_channel_args. The idea is
|
||||
// that the resolver will return a set of channel args that contains the
|
||||
// information that is currently in the resolver_result struct. For
|
||||
// example, there will be specific args indicating the set of addresses
|
||||
// and the name of the LB policy to instantiate. Note that if we did
|
||||
// this, we would probably want to change the data structure of
|
||||
// grpc_channel_args such to a hash table or AVL or some other data
|
||||
// structure that does not require linear search to find keys.
|
||||
|
||||
/// Results reported from a grpc_resolver.
|
||||
typedef struct grpc_resolver_result grpc_resolver_result; |
||||
|
||||
/// Takes ownership of \a addresses and \a lb_policy_args.
|
||||
grpc_resolver_result* grpc_resolver_result_create( |
||||
const char* server_name, grpc_lb_addresses* addresses, |
||||
const char* lb_policy_name, grpc_channel_args* lb_policy_args); |
||||
void grpc_resolver_result_ref(grpc_resolver_result* result); |
||||
void grpc_resolver_result_unref(grpc_exec_ctx* exec_ctx, |
||||
grpc_resolver_result* result); |
||||
|
||||
/// Caller does NOT take ownership of result.
|
||||
const char* grpc_resolver_result_get_server_name(grpc_resolver_result* result); |
||||
|
||||
/// Caller does NOT take ownership of result.
|
||||
grpc_lb_addresses* grpc_resolver_result_get_addresses( |
||||
grpc_resolver_result* result); |
||||
|
||||
/// Caller does NOT take ownership of result.
|
||||
const char* grpc_resolver_result_get_lb_policy_name( |
||||
grpc_resolver_result* result); |
||||
|
||||
/// Caller does NOT take ownership of result.
|
||||
grpc_channel_args* grpc_resolver_result_get_lb_policy_args( |
||||
grpc_resolver_result* result); |
||||
|
||||
#endif /* GRPC_CORE_EXT_CLIENT_CONFIG_RESOLVER_RESULT_H */ |
||||
File diff suppressed because it is too large
Load Diff
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in new issue