[id='enabling-resp-endpoint_{context}']
= {brandname} 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 {brandname} Server deployments, exactly like standalone Redis, where each server instance runs independently of each other.
* Clustered {brandname} Server deployments, where server instances replicate or distribute data between each other. Clustered deployments provides clients with failover capabilities.

.Prerequisites

* Install {brandname} Server.

.Procedure

. link:{server_docs}#creating-users_server-getting-started[Create a user]

.Verification

When you start {brandname} Server check for the following log message:

[source,options="nowrap"]
----
[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:

[source,options="nowrap"]
----
redis-cli -p 11222 --user username --pass password
----

[source,options="nowrap"]
----
127.0.0.1:11222> SET k v
OK
127.0.0.1:11222> GET k
"v"
127.0.0.1:11222> quit
----

== 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 {brandname} Server clustering mode.
* `application/octet-stream` encoding for both keys and values.
* `RESPHashFunctionPartitioner` hash partitioner, which supports the CRC16 hashing used by Redis clients

[discrete]
=== 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
[source,xml,options="nowrap",subs=attributes+,role="primary"]
----
include::xml/resp_cache.xml[]
----

.JSON
[source,json,options="nowrap",subs=attributes+,role="secondary"]
----
include::json/resp_cache.json[]
----

.YAML
[source,yaml,options="nowrap",subs=attributes+,role="secondary"]
----
include::yaml/resp_cache.yaml[]
----

[TIP]
====
Configure your cache value encoding with Protobuf encoding if you want to view cache entries in the {brandname} Console (`value media-type="application/x-protostream"`).
====

[discrete]
=== Explicit RESP endpoint configuration

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

.XML
[source,xml,options="nowrap",subs=attributes+,role="primary"]
----
include::xml/resp_connector.xml[]
----

.JSON
[source,json,options="nowrap",subs=attributes+,role="secondary"]
----
include::json/resp_connector.json[]
----

.YAML
[source,yaml,options="nowrap",subs=attributes+,role="secondary"]
----
include::yaml/resp_connector.yaml[]
----

[discrete]
=== Clustered configuration

{brandname} is a horizontally scalable Resp-compatible server with high availability capabilities.
{brandname} provides clustering mechanisms with automatic failover detection and membership discovery by default.
Topology changes are handled automatically, and adding or removing nodes to the cluster is a streamlined process that automatically redistributes entries between nodes without downtime.
The cluster is homogeneous, where nodes are the primary and the backup owners of entries, guaranteeing that entries are available even in case of server failures.

Backed by a consistent hash, compatible with the hash-slot algorithm in Resp clients, entries are distributed across cluster members.
{brandname} automatically redirects requests to the proper entry owner.
As a result, hash tags in keys and the `-MOVED` error response for requests are not required even for multi-key operations accessing keys with different owners.

[TIP]
====
{brandname} allows multiple logical databases with the SELECT command in clustering mode.
====
