Shard transport options for DSE Search communications

The netty non-blocking communications layer was the previous default. After the upgrade to 5.0, all nodes switch to use internode messaging options.

A custom, TCP-based communications layer for Solr was the default type in DataStax Enterprise and provided an alternative to the slower more resource intensive HTTP-based, Tomcat-backed interface.

The netty communications layer improves DSE Search inter-node communications in several ways:

  • Lowers latency
  • Reduces resource consumption
  • Increases throughput even while handling thousands of concurrent requests
  • Provides nonblocking I/O processing

To avoid distributed deadlock during queries, do not use the HTTP-based communications. DataStax recommends using Inter-node messaging.

The TCP-based communications layer for DSE Search supports client-to-node and node-to-node encryption using SSL, but does not support Kerberos.

Configure shard_transport_options in the dse.yaml file, select TCP-based (netty) communication and configure shard options.
Note: Shard transport options work only in datacenters where the replication factor is not equal to the number of nodes. You can verify or change the replication factor of the keyspace.

DataStax Enterprise 5.0 implements an internode messaging system that provides the same benefits of the shard transport, but is widely used by all DataStax Enterprise components. For upgrade impact, see Upgrading DataStax Enterprise.

The location of the dse.yaml file depends on the type of installation:
Installer-Services /etc/dse/dse.yaml
Package installations /etc/dse/dse.yaml
Installer-No Services install_location/resources/dse/conf/dse.yaml
Tarball installations install_location/resources/dse/conf/dse.yaml