GridGain Developers Hub

C++ Client

GridGain 9 clients connect to the cluster via a standard socket connection. Unlike GridGain 2.x, there is no separate Thin and Thick clients in GridGain 9. All clients are 'thin'.

Clients do not become a part of the cluster topology, never hold any data, and are not used as a destination for compute calculations.

Supported Platforms

The C++ client is distributed as a pre-built binary for the following platforms:

  • Linux x86-64,

  • Windows using MSVC toolchain versions 2017, 2019 and 2022

Getting Started

Installation

Download the client and unpack it. Then, add it to your project.

Client Connector Configuration

Client connection parameters are controlled by the client connector configuration. By default, GridGain accepts client connections on port 10800. You can change the configuration for the node by using the CLI tool at any time.

Here is how the client connector configuration looks like in the JSON format.

"ignite" : {
  "clientConnector" : {
    "port" : 10800,
    "idleTimeoutMillis" :3000,
    "sendServerExceptionStackTraceToClient" : true,
    "ssl" : {
      "enabled" : true,
      "clientAuth" : "require",
      "keyStore" : {
        "path" : "KEYSTORE_PATH",
        "password" : "SSL_STORE_PASS"
      },
      "trustStore" : {
        "path" : "TRUSTSTORE_PATH",
        "password" : "SSL_STORE_PASS"
      },
    },
  },
}

The table below covers the configuration for client connector:

Property Default Description

connectTimeoutMillis

5000

Connection attempt timeout, in milliseconds.

idleTimeoutMillis

0

How long the client can be idle before the connection is dropped, in milliseconds. By default, there is no limit.

metricsEnabled

false

Defines if client metrics are collected.

port

10800

The port the client connector will be listening to.

sendServerExceptionStackTraceToClient

false

Defines if cluster exceptions are sent to the client.

ssl.ciphers

The cipher used for SSL communication.

ssl.clientAuth

Type of client authentication used by clients. For more information, see SSL/TLS.

ssl.enabled

Defines if SSL is enabled.

ssl.keyStore.password

SSL keystore password.

ssl.keyStore.path

Path to the SSL keystore.

ssl.keyStore.type

PKCS12

The type of SSL keystore used.

ssl.trustStore.password

SSL keystore password.

ssl.trustStore.path

Path to the SSL keystore.

ssl.trustStore.type

PKCS12

The type of SSL keystore used.

Here is how you can change the parameters:

node config update clientConnector.port=10469

Connecting to Cluster

To initialize a client, use the IgniteClient class, and provide it with the configuration:

using namespace ignite;

ignite_client_configuration cfg{"127.0.0.1"};
auto client = ignite_client::start(cfg, std::chrono::seconds(5));

Using Dependency Injection

GridGain client provides support for using Dependency Injection when initializing a client instance.

This approach can be used to simplify initializing the client in DI containers:

  • Register the IgniteClientGroup in your DI container:

    builder.Services.AddSingleton<IgniteClientGroup>(_ => new IgniteClientGroup(
    new IgniteClientGroupConfiguration
    {
        Size = 3,
        ClientConfiguration = new("localhost"),
    }));

  • Use an instance of the group you created in your methods:

    public async Task<IActionResult> Index([FromServices] IgniteClientGroup igniteGroup)
{
    IIgnite ignite = await igniteGroup.GetIgniteAsync();
    var tables = await ignite.Tables.GetTablesAsync();
    return Ok(tables);
}

Authentication

To pass authentication information, pass it to IgniteClient builder:

User Object Serialization

GridGain supports mapping user objects to table tuples. This ensures that objects created in any programming language can be used for key-value operations directly.

Limitations

There are limitations to user types that can be used for such a mapping. Some limitations are common, and others are platform-specific due to the programming language used.

  • Only flat field structure is supported, meaning no nesting user objects. This is because Ignite tables, and therefore tuples have flat structure themselves;

  • Fields should be mapped to Ignite types;

  • All fields in user type should either be mapped to Table column or explicitly excluded;

  • All columns from Table should be mapped to some field in the user type;

  • C++ only: User has to provide marshalling functions explicitly as there is no reflection to generate them based on user type structure.

Usage Examples

struct account {
  account() = default;
  account(std::int64_t id) : id(id) {}
  account(std::int64_t id, std::int64_t balance) : id(id), balance(balance) {}

  std::int64_t id{0};
  std::int64_t balance{0};
};

namespace ignite {

  template<>
  ignite_tuple convert_to_tuple(account &&value) {
    ignite_tuple tuple;

    tuple.set("id", value.id);
    tuple.set("balance", value.balance);

    return tuple;
  }

  template<>
  account convert_from_tuple(ignite_tuple&& value) {
    account res;

    res.id = value.get<std::int64_t>("id");

    // Sometimes only key columns are returned, i.e. "id",
    // so we have to check whether there are any other columns.
    if (value.column_count() > 1)
      res.balance = value.get<std::int64_t>("balance");

    return res;
  }

} // namespace ignite

SQL API

GridGain 9 is focused on SQL, and SQL API is the primary way to work with the data. You can read more about supported SQL statements in the SQL Reference section. Here is how you can send SQL requests:

result_set result = client.get_sql().execute(nullptr, {"select name from tbl where id = ?"}, {std::int64_t{42});
std::vector<ignite_tuple> page = result_set.current_page();
ignite_tuple& row = page.front();

SQL Scripts

The default API executes SQL statements one at a time. If you want to execute large SQL statements, pass them to the executeScript() method. These statements will be executed in order.

std::string script = ""
	+ "CREATE TABLE IF NOT EXISTS Person (id int primary key, city_id int, name varchar, age int, company varchar);"
	+ "INSERT INTO Person (1,3, 'John', 43, 'Sample')";

client.get_sql().execute_script(script);

Transactions

All table operations in GridGain 9 are transactional. You can provide an explicit transaction as a first argument of any Table and SQL API call. If you do not provide an explicit transaction, an implicit one will be created for every call.

Here is how you can provide a transaction explicitly:

auto accounts = table.get_key_value_view<account, account>();

account init_value(42, 16'000);
accounts.put(nullptr, {42}, init_value);

auto tx = client.get_transactions().begin();

std::optional<account> res_account = accounts.get(&tx, {42});
res_account->balance += 500;
accounts.put(&tx, {42}, res_account);

assert(accounts.get(&tx, {42})->balance == 16'500);

tx.rollback();

assert(accounts.get(&tx, {42})->balance == 16'000);

Table API

To execute table operations on a specific table, you need to get a specific view of the table and use one of its methods. You can only create new tables by using SQL API.

When working with tables, you can use built-in Tuple type, which is a set of key-value pairs underneath, or map the data to your own types for a strongly-typed access. Here is how you can work with tables:

Getting a Table Instance

First, get an instance of the table. To obtain an instance of table, use the IgniteTables.table(String) method. You can also use IgniteTables.tables() method to list all existing tables.

using namespace ignite;

auto table_api = client.get_tables();
std::vector<table> existing_tables = table_api.get_tables();
table first_table = existing_tables.front();

std::optional<table> my_table = table_api.get_table("MY_TABLE);

Basic Table Operations

Once you’ve got a table you need to get a specific view to choose how you want to operate table records.

Tuple Record View

A tuple record view. It can be used to operate table tuples directly.

record_view<ignite_tuple> view = table.get_record_binary_view();

ignite_tuple record{
  {"id", 42},
  {"name", "John Doe"}
};

view.upsert(nullptr, record);
std::optional<ignite_tuple> res_record = view.get(nullptr, {"id", 42});

assert(res_record.has_value());
assert(res_record->column_count() == 2);
assert(res_record->get<std::int64_t>("id") == 42);
assert(res_record->get<std::string>("name") == "John Doe");

Record View

A record view mapped to a user type. It can be used to operate table using user objects which are mapped to table tuples.

record_view<person> view = table.get_record_view<person>();

person record(42, "John Doe");

view.upsert(nullptr, record);
std::optional<person> res_record = view.get(nullptr, person{42});

assert(res.has_value());
assert(res->id == 42);
assert(res->name == "John Doe");

Key-Value Tuple View

A tuple key-value view. It can be used to operate table using key and value tuples separately.

key_value_view<ignite_tuple, ignite_tuple> kv_view = table.get_key_value_binary_view();

ignite_tuple key_tuple{{"id", 42}};
ignite_tuple val_tuple{{"name", "John Doe"}};

kv_view.put(nullptr, key_tuple, val_tuple);
std::optional<ignite_tuple> res_tuple = kv_view.get(nullptr, key_tuple);

assert(res_tuple.has_value());
assert(res_tuple->column_count() == 2);
assert(res_tuple->get<std::int64_t>("id") == 42);
assert(res_tuple->get<std::string>("name") == "John Doe");

Key-Value View

A key-value view with user objects. It can be used to operate table using key and value user objects mapped to table tuples.

key_value_view<person, person> kv_view = table.get_key_value_view<person, person>();

kv_view.put(nullptr, {42}, {"John Doe"});
std::optional<person> res = kv_view.get(nullptr, {42});

assert(res.has_value());
assert(res->id == 42);
assert(res->name == "John Doe");

© 2025 GridGain Systems, Inc. All Rights Reserved. Privacy Policy | Legal Notices. GridGain® is a registered trademark of GridGain Systems, Inc.
Apache, Apache Ignite, the Apache feather and the Apache Ignite logo are either registered trademarks or trademarks of The Apache Software Foundation.

Last updated on Oct 23, 2025