Using the RESP protocol endpoint with Data Grid


Red Hat Data Grid 8.5

Use the Data Grid RESP endpoint to interact with remote caches

Red Hat Customer Content Services

Abstract

The RESP endpoint allows Redis clients to connect to one or more Data Grid backed RESP servers and perform cache operations.

Red Hat Data Grid

Data Grid is a high-performance, distributed in-memory data store.

Schemaless data structure
Flexibility to store different objects as key-value pairs.
Grid-based data storage
Designed to distribute and replicate data across clusters.
Elastic scaling
Dynamically adjust the number of nodes to meet demand without service disruption.
Data interoperability
Store, retrieve, and query data in the grid from different endpoints.

Data Grid documentation

Documentation for Data Grid is available on the Red Hat customer portal.

Data Grid downloads

Access the Data Grid Software Downloads on the Red Hat customer portal.

Note

You must have a Red Hat account to access and download Data Grid software.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.

1. Data Grid RESP endpoint

The RESP endpoint is enabled by default on the single-port endpoint. Redis client connections will automatically be detected and routed to the internal connector. The RESP endpoint works with:

  • Standalone Data Grid Server deployments, exactly like standalone Redis, where each server instance runs independently of each other.
  • Clustered Data Grid Server deployments, where server instances replicate or distribute data between each other. Clustered deployments provides clients with failover capabilities.

Prerequisites

  • Install Data Grid Server.

Procedure

  1. Create a user

Verification

When you start Data Grid Server check for the following log message:

[org.infinispan.SERVER] ISPN080018: Started connector Resp (internal)

You can now connect to the RESP endpoint with a Redis client. For example, with the Redis CLI you can do the following to add an entry to the cache:

redis-cli -p 11222 --user username --pass password
127.0.0.1:11222> SET k v
OK
127.0.0.1:11222> GET k
"v"
127.0.0.1:11222> quit

1.1. Configuring caches for the RESP endpoint

The RESP endpoint automatically configures and starts a respCache cache. This cache has the following configuration:

  • local-cache or distributed-cache depending on the Data Grid Server clustering mode.
  • application/octet-stream encoding for both keys and values.
  • RESPHashFunctionPartitioner hash partitioner, which supports the CRC16 hashing used by Redis clients
Explicit configuration for cache

It is possible to supply a custom configuration for the cache, as long as it does not violate the requirements of the RESP connector, in which case the server will raise an exception and will not start. Main constraints are:

  • hash partitioning function must be org.infinispan.distribution.ch.impl.RESPHashFunctionPartitioner.
  • key encoding must be application/octet-stream.

Example of explicit cache configuration follows.

XML

<distributed-cache name="respCache" aliases="0" owners="2"
                   key-partitioner="org.infinispan.distribution.ch.impl.RESPHashFunctionPartitioner"
                   mode="SYNC" remote-timeout="17500" statistics="true">
	<encoding media-type="application/octet-stream"/>
</distributed-cache>

JSON

{
   "respCache": {
     "distributed-cache": {
       "aliases": ["0"],
       "owners": "2",
       "key-partitioner": "org.infinispan.distribution.ch.impl.RESPHashFunctionPartitioner",
       "mode": "SYNC",
       "statistics": true,
       "encoding": {
         "media-type": "application/octet-stream"
       }
     }
   }
 }

YAML

respCache:
  distributedCache:
    aliases:
      - "0"
    owners: "2"
    keyPartitioner: "org.infinispan.distribution.ch.impl.RESPHashFunctionPartitioner"
    mode: "SYNC"
    statistics: "true"
    encoding:
      mediaType: "application/octet-stream"

Tip

Configure your cache value encoding with Protobuf encoding if you want to view cache entries in the Data Grid Console (value media-type="application/x-protostream").

Explicit RESP endpoint configuration

If the implicit configuration used by the single-port endpoint does not fit your needs, explicit configuration is available.

XML

<endpoints>
  <endpoint socket-binding="default" security-realm="default">
    <resp-connector cache="mycache" />
    <hotrod-connector />
    <rest-connector/>
  </endpoint>
</endpoints>

JSON

{
  "server": {
    "endpoints": {
      "endpoint": {
        "socket-binding": "default",
        "security-realm": "default",
        "resp-connector": {
          "cache": "mycache"
        },
        "hotrod-connector": {},
        "rest-connector": {}
      }
    }
  }
}

YAML

server:
  endpoints:
    endpoint:
      socketBinding: "default"
      securityRealm: "default"
      respConnector:
        cache: "mycache"
      hotrodConnector: ~
      restConnector: ~

2. Mapping caches to Redis logical databases

Use the cache aliases configuration attributes to map caches to Redis logical databases. The default respCache is mapped to logical database 0.

Tip

Data Grid can use multiple logical databases even in clustered mode, as opposed to Redis which only supports database 0 when using Redis Cluster.

3. Redis commands

The Data Grid RESP endpoint implements the following Redis commands:

Legal Notice

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.