Michael Penick

<p>We are pleased to announce the 2.1 GA release of the C/C++ driver for Apache Cassandra and DataStax Enterprise. The features of this release and the&nbsp;<a href="https://www.datastax.com/dev/blog/datastax-c-driver-2-1-beta-released">beta</a>&nbsp;complete all the necessary functionality to take full advantage of Apache Cassandra 2.1 and DataStax Enterprise 4.7. In addition to the features included in the beta release, the 2.1 GA adds support for client-side timestamps and the full range of stream IDs. This release also brings support for retry polices, idle connection heartbeats, the API now exposes the raw paging state token, the ability to disable schema metadata and several internal improvements.</p>

<h2>What’s new</h2>

<h3>Client-side timestamps</h3>

<p>Apache Cassandra uses timestamps to serialize write operations. That is, values with a more current timestamp are considered to be the most up-to-date version of that information. Previous versions of the C/C++ driver only allowed timestamps to be assigned server-side by Cassandra. This is not always ideal for all applications. This release of the driver allows timestamps to be generated client-side and it is enabled by either setting a global timestamp generator or assigning a specific timestamp to a statement or batch. By default, the driver uses a server-side timestamp generator and behaves the same as previous versions of the driver. The GA driver also includes a monotonic timestamp generator which assigns microsecond granular timestamps client-side and is useful for applications that plan to make rapid mutations from a single driver instance. In that case, it can prevent writes from a single driver instance from being reordered.</p>

<h4>Using the monotonic timestamp generator</h4>

<p><code>CassTimestampGen* timestamp_gen = cass_timestamp_gen_monotonic_new();</code></p>

<p>&nbsp;</p>

<p><code>cass_cluster_set_timestamp_gen(cluster, timestamp_gen);<br />
<br />
/* ... */<br />
<br />
/* Connect sessions */<br />
<br />
/* Timestamp generators must be freed */<br />
cass_timestamp_gen_free(timestamp_gen);</code></p>

<p>Timestamps can also be assigned to individual&nbsp;<code>CassStatement</code>&nbsp;or&nbsp;<code>CassBatch</code>.</p>

<p><strong>Assigning a client-side timestamp to a statement</strong></p>

<p><code>CassStatement* statement = cass_statement_new(</code><code>"INSERT INTO * ..."</code><code>, 2);<br />
<br />
/* Add a timestamp to a statement */<br />
cass_statement_set_timestamp(statement, 123456789);<br />
<br />
/* ... */</code></p>

<h4><br />
Assigning a client-side timestamp to a batch</h4>

<p><code>/* Add a timestamp to a batch */<br />
<br />
CassBatch* batch = cass_batch_new(CASS_BATCH_TYPE_LOGGED);<br />
<br />
/* Add a timestamp to the batch */<br />
cass_batch_set_timestamp(batch, 123456789);<br />
<br />
/* Add statements to the batch*/<br />
<br />
/* ... */</code></p>

<h3>Retry policies</h3>

<p>The use of retry policies allows C/C++ driver to automatically handle server-side failures when Cassandra is unable to fulfill the consistency requirements of a request. The default retry policy will only retry a request when it will preseve the original consistency level and when it is likely to succeed (there are enough replicas). The default retry policy can be overridden globally by using&nbsp;<code>cass_cluster_set_retry_policy()</code>&nbsp;or it can be set per&nbsp;<code>CassStatement</code>&nbsp;or&nbsp;<code>CassBatch</code>.</p>

<h4>Changing the default policy to the downgrading consistency policy</h4>

<p><code>CassRetryPolicy* downgrading_policy = cass_retry_policy_downgrading_consistency_new();<br />
<br />
cass_cluster_set_retry_policy(cluster, downgrading_policy);<br />
<br />
/* ... */<br />
<br />
/* Retry policies must be freed */<br />
cass_retry_policy_free(downgrading_policy);</code></p>

<p><br />
The driver also provides a fall-through policy that always returns an error and a logging policy which can be used in conjunction with other policies to log their retry decisions.</p>

<p><strong>Chaining the downgrading policy to the logging policy</strong></p>

<p><code>CassRetryPolicy* downgrading_policy = cass_retry_policy_downgrading_consistency_new();<br />
<br />
CassRetryPolicy* logging_policy = cass_retry_policy_logging_new(downgrading_policy)<br />
<br />
cass_cluster_set_retry_policy(cluster, logging_policy);<br />
<br />
/* ... */<br />
<br />
/* Retry policies must be freed */<br />
cass_retry_policy_free(downgrading_policy);<br />
cass_retry_policy_free(logging_policy);</code></p>

<p>&nbsp;</p>

<h3>Direct access to the paging state token</h3>

<p>Previously, the C/C++ driver handled paging transparently by managing the paging state internally. It is now possible to access this paging state token using&nbsp;<code>cass_result_paging_state_token()</code>&nbsp;and add it to a&nbsp;<code>CassStatement</code>&nbsp;using&nbsp;<code>cass_statement_set_paging_state_token()</code>. This allows client applications to store this token for later use. The paging state should&nbsp;<strong>not</strong>&nbsp;be exposed to or come from untrusted environments.</p>

<h3>Idle connection heartbeats</h3>

<p>All the DataStax drivers use connection pooling to help reduce query latency by always having connections ready to handle requests. The problem is that in many networking setups intermediate network devices such as routers and switches can disconnect connections that have been idle for too long. To prevent this from happening the driver can now send a lightweight heartbeat request periodically. By default, the driver sends a heartbeat every 30 seconds, but this can be configured or disabled:</p>

<p><code>/* Change the heartbeat interval to 1 minute *<br />
cass_cluster_set_connection_heartbeat_interval(cluster, 60);<br />
<br />
/* Disable heartbeat requests */<br />
cass_cluster_set_connection_heartbeat_interval(cluster, 0);</code></p>

<p>Ability to disable schema metadataHeartbeats can also be used to detect unresponsive connections. A connection is determined to be unresponsive if it is without a successful heartbeat for the idle timeout period. The idle timeout period is the amount of time a connection is allowed to be without a successful heartbeat before being terminated and scheduled for reconnection. This timeout can be change from its default setting of 60 seconds:</p>

<p><code>/* Change the idle timeout to 2 minute */<br />
cass_cluster_set_connection_idle_timeout(cluster, 120);</code></p>

<p><strong>Ability to disable schema metadata</strong><br />
Schema metadata is kept up-to-date by the driver for use by client applications, either directly, or in the 2.1 release it can be used to construct complex data types such as UDTs, tuples and collections. It is also used by the token aware policy to determine the replication strategy of keyspaces. However, some applications might wish to eliminate this overhead. It is now possible to prevent the driver from retrieving and maintaining the schema metadata. This can be used to improve startup performance in applications with short-lived sessions or applications where schema metadata isn't used.</p>

<p><code>/* Disable schema metdata */<br />
cass_cluster_set_use_schema(cluster, cass_false);</code></p>

<h3><code>TCP_NODELAY</code>&nbsp;default</h3>

<p>The driver now enables&nbsp;<code>TCP_NODELAY</code>&nbsp;by default because, internally, the driver already buffers writes to connections and disabling&nbsp;<code>TCP_NODELAY</code>&nbsp;(enabling Nagle's algorithm) either has no effect or can add unnecessary delay.</p>

<h3>Internal improvements</h3>

<p>This release also includes the following internal improvements:</p>

<ul>
	<li>Timeouts that happen during connection or start up will no longer disconnect an entire connection pool. Instead the driver attempts to reconnect only the connections that experienced the timeouts.</li>
	<li>Connections can now use the full 32,767 stream IDs allowed by the CQL Native Protocol Version 3 (vs the 127 stream IDs available in version 1 and 2) . This allows for bigger write batches and allows the driver to handle the same throughput with less connections.</li>
</ul>

<h2>Looking forward</h2>

<p>This release brings with it full support for Apache Cassandra 2.1 along with many other great features. In next release we will be focusing our efforts on supporting Apache Cassandra 2.2 and 3.0. Let us know what you think about the 2.1 GA release. Your feedback is important to us and it influences what features we prioritize. To provide feedback use the following:</p>

<ul>
	<li>Mailing List:&nbsp;<a href="https://groups.google.com/a/lists.datastax.com/forum/#!forum/cpp-driver-user">https://groups.google.com/a/lists.datastax.com/forum/#!forum/cpp-driver-user</a></li>
	<li>IRC: #datastax-drivers on irc.freenode.net</li>
	<li>Review and contribute source code:&nbsp;<a href="https://github.com/datastax/cpp-driver">https://github.com/datastax/cpp-driver</a></li>
	<li>Report issues on JIRA:&nbsp;<a href="https://datastax-oss.atlassian.net/browse/CPP">https://datastax-oss.atlassian.net/browse/CPP</a></li>
</ul>


Build and scale cloud native apps

Discover the benefits of DBaaS and why your apps deserve an upgrade.

Learn about NoSQL Databases

Learn about NoSQL databases with Apache Cassandra and Astra DB.

2022 Recap: A Year for Customers, Community, and Real-Time Data

Highlights from 2022 and a glimpse into the year ahead.

ViewingCompany

DataStax C/C++ Driver: 2.1 GA released!

Sign up for our Developer Newsletter