Class ClientOptions (2.28.0)

Applications typically configure the client class using:

auto client =
  bigtable::Client(bigtable::ClientOptions().SetCredentials(...));

Configure the client to connect to the Cloud Bigtable service, using the default options.

Environment Variables

If the BIGTABLE_EMULATOR_HOST environment variable is set, the default configuration changes in important ways:

• The credentials are initialized to grpc::InsecureCredentials().
• Any client created with these objects will connect to the endpoint (typically just a host:port string) set in the environment variable.

This makes it easy to test applications using the Cloud Bigtable Emulator.

See Also

The Google Cloud Platform introduction to application default credentials

See Also

grpc::GoogleDefaultCredentials in the grpc documentation

See Also

The documentation for the Cloud Bigtable Emulator.

Expected options are any of the types in the following option lists.

• google::cloud::CommonOptionList
• google::cloud::GrpcOptionList
• google::cloud::bigtable::ClientOptionList

This constructor always connects to the production instance of Cloud Bigtable, and can be used when the application default credentials are not configured in the environment where the application is running.

gRPC typically opens a single connection for each destination. To improve performance, the Cloud Bigtable C++ client can open multiple connections to a given destination, but these connections are shared by all threads in the application. Sometimes the application may want even more segregation, for example, the application may want to use a different pool for high-priority requests vs. lower priority ones. Using different names creates segregated pools.

Specifying 0 for size will set the size of the connection pool to default.

Please see the docs for grpc::ChannelArguments::SetCompressionAlgorithm() on https://grpc.io/grpc/cpp/classgrpc_1_1_channel_arguments.html for more details.

For example:

bigtable::ClientOptions::SetGrpclbFallbackTimeout(
    std::chrono::milliseconds(5000))
bigtable::ClientOptions::SetGrpclbFallbackTimeout(
    std::chrono::seconds(5))

See Also

std::chrono::duration<> for more details. Please see the docs for grpc::ChannelArguments::SetGrpclbFallbackTimeout() on https://grpc.io/grpc/cpp/classgrpc_1_1_channel_arguments.html for more details.

Please see the docs for grpc::ChannelArguments::SetUserAgentPrefix() on https://grpc.io/grpc/cpp/classgrpc_1_1_channel_arguments.html for more details.

Please see the docs for grpc::ChannelArguments::SetResourceQuota() on https://grpc.io/grpc/cpp/classgrpc_1_1_channel_arguments.html for more details.

-1 means unlimited.

Please see the docs for grpc::ChannelArguments::SetMaxReceiveMessageSize() on https://grpc.io/grpc/cpp/classgrpc_1_1_channel_arguments.html for more details.

-1 means unlimited.

Please see the docs for grpc::ChannelArguments::SetMaxSendMessageSize() on https://grpc.io/grpc/cpp/classgrpc_1_1_channel_arguments.html for more details.

Please see the docs for grpc::ChannelArguments::SetLoadBalancingPolicyName() on https://grpc.io/grpc/cpp/classgrpc_1_1_channel_arguments.html for more details.

Please see the docs for grpc::ChannelArguments::SetServiceConfigJSON() on https://grpc.io/grpc/cpp/classgrpc_1_1_channel_arguments.html for more details.

Please see the docs for grpc::ChannelArguments::SetSslTargetNameOverride() on https://grpc.io/grpc/cpp/classgrpc_1_1_channel_arguments.html for more details.

The C++ clients can log interesting events to help library and application developers troubleshoot problems. This flag returns true if tracing should be enabled by clients configured with this option.

This is necessary to avoid all connections simultaneously expiring and causing latency spikes.

If needed it changes max_conn_refresh_period() to preserve the invariant:

assert(min_conn_refresh_period() <= max_conn_refresh_period())

The library will wait at least this long before attempting any refresh operation.

If needed it changes max_conn_refresh_period() to preserve the invariant:

assert(min_conn_refresh_period() <= max_conn_refresh_period())

Connections need to perform background work on behalf of the application. Normally they just create a background thread and a CompletionQueue for this work, but the application may need more fine-grained control of their threads. In this case the application can provide the CompletionQueue and it assumes responsibility for creating one or more threads blocked on CompletionQueue::Run().