Core+ C++ Client

The Deephaven Core+ C++ client allows you to create and connect to Persistent Queries using the Community Core engine in the Deephaven Enterprise system. This page provides an overview of how to use the C++ client.

Create a SessionManager

A SessionManager object allows the client to keep connections to a Deephaven Enterprise Controller and Authentication services. First, we need to create a SessionManager object, which will create the connections and keep them alive for as long as the SessionManager object is valid (not destroyed).

Note

The code block above connects to a Deephaven server at port 8000. Use port 8000 for servers with an Envoy service and port 8123 for servers without an Envoy service.

The SessionManager::FromUrl factory method takes two arguments.

  1. A descriptive name that will be used on the server and client sides to log information about operations performed by this client.
  2. A URL pointing to a file in JSON format containing information about connectivity parameters for the Deephaven installation. Such a file is provided by a Deephaven installation under iris/connection.json.

The descriptive name can, in principle, be any string of our choosing. However, it is important to select a value that allows us to distinguish our client in logs. It makes sense to include the process and/or thread ID where the client was created; the function GetTidAsString() is provided for that purpose.

Note

The client implementation will append information about the host where this client is running, so there is no need to include that in the provided descriptive_name.

Three network connections are made in the order indicated below during the creation of the SessionManager object.

  1. The connection.json file is downloaded from the provided URL. This is a temporary connection that only lives until we get the file.
  2. A connection is made to the Deephaven Enterprise Authentication service.
  3. A connection is made to the Deephaven Enterprise Controller service.

The connections to Authentication and Controller are made based on the information downloaded from connection.json. These two connections are maintained as long as the SessionManager object is valid.

All these operations must succeed for SessionManager to be properly initialized, or an error results. When experiencing connectivity issues, or if the information contained in the connection.json file downloaded is wrong, you may see an error similar to:

Note

See the appendix at the end of this document for more information about Deephaven client connectivity and some tools to debug network issues.

More information about Core+ clients and their connectivity can be found in the Core+ Clients section of our Communications Protocols documentation.

Authenticate

Once a SessionManager is created, we need to authenticate it. We have two options: password authentication (providing a user and password) or private key authentication (providing a private key file).

Note

The operate_as argument for the PasswordAuthentication method is only interesting to system administrators; under normal circumstances, you would pass this argument as the same value provided for user.

An authenticated SessionManager connects to the PQ controller, which then creates a new connection to an existing Persistent Query (PQ) or a new PQ. In either case, the result of a connection is a DndClient object.

The DndClient object can get results from the PQ.

Connect to an existing Persistent Query

To connect to an existing PQ, we need to know either the string name or the numeric serial of the PQ we want to connect to.

Create a new temporary Persistent Query and connect to it

To create a temporary PQ, we first need to create a PQ configuration. We can use a PqConfigBuilder object for that. The config object comes with predefined defaults for most parameters. Consult the class documentation for PqConfigBuilder for the different options. At a minimum, we have to set the desired heap size for our worker in gigabytes.

Once we have a PqConfigBuilder ready with our options, we can call its Build method to obtain the configuration, and pass it to the AddQueryAndConnect method of our SessionManager.

Send a query to a DndClient and get the result

To interact with the tables in a PQ from the client, we first need to create a DndTableHandleManager object from the DndClient.

With a DndTableHandleManager on hand, we can run a script on the server (PQ). In the example below, we create a table on the server (PQ) and then fetch that table on the client using a TableHandle object.

A TableHandle object can perform additional operations on the table from the client side. In our example, we print the table to standard output.

Note

The code given to DndTableHandleManager::RunScript should match the script language configured for the PQ when it was created. For the case where a new PQ is being created, the PqConfigBuilder::SetScriptLanguage method can be used to set the script language of the new PQ. This method accepts either "groovy" or "python" as a string argument.

Close DndClient and SessionManager objects

When DndClient and SessionManager objects are destroyed, they are automatically closed. This closes network connections and releases all server-side resources associated with these objects. You can call the Close method before the object is destroyed to force it to close right away.

Caution

Once the Close method is called on either of these objects, any subsequent operation results in an error.

Ensuring these objects are closed promptly supports the best utilization of system resources.

Appendix

Test scripts

When the generated build bundle is deployed, code examples can be found in $PREFIX/src/iris/DhcInDhe/cpp-client/examples, where $PREFIX is the --prefix path passed into the build script. The examples are already built as binaries that can be run.

The quickest way to verify that the installation is working properly is the tiny_session_manager example. It takes a URL pointing to a Deephaven connection.json file. When run, it prompts for a username/password. If the connection and credentials are correct, it prints Session manager services authenticated:

Connectivity and tools to debug network issues

Deephaven clients use gRPC, an open-source RPC framework from Google, to implement communications with Deephaven servers. Part of the nature of how gRPC works implies treating network errors as potentially transient: network failures are based on a timeout model. This implies that the wrong host address or a server that is down does not immediately cause a connection attempt to fail; instead, gRPC keeps trying to connect, in the assumption that a new host name registration may appear or a server may restart and make the expected port available.

Eventually, if the network issue is not resolved before a timeout window expires, the connection attempt is considered failed, and an error results.

Important

The default timeout used by Deephaven in its clients is 2 minutes.

Network connectivity issues may appear opaque due to the two-minute timeout. However, treating network connectivity issues always as potentially transient failures is very useful in terms of making clients and servers resilient. It does, however, result in some opaqueness for users: the client may look like it just 'sits there' for two minutes before raising an error.

Tip

Setting the GRPC_VERBOSITY environment variable before starting a client program can help debug network and connectivity issues. The possible values are info and debug (debug provides more details while being more noisy/chatty).

Setting GRPC_VERBOSITY logs details of gRPC connection establishment, including SSL authentication and certificate validation to standard out.