Jump to: navigation, search

DMS Scalability

Digital Messaging Server allows a scalable functional mode which can be used when a flow of inbound messages from a media channel exceeds the processing capacity of a standalone DMS. The scalable functional mode is implemented by running multiple DMS instances. The DMS instances that participate in the scalable cluster of DMS’s share the load of processing messages between them.

Implementation

The scalable functional mode uses the Redis server as a central data exchange element for the DMS instances of the DMS cluster. Redis server version 6.2 and Redisson (Redis client) are used in the implementation.

Two types of DMS instances participate in the processing of messages:

  • Dispatcher (DMS-d)
  • Workers (DMS-w1, DMS-w2, et al.)

All DMS instances involved in one scalable cluster are restricted to handle one media channel.
DMS Scalability

Functions of DMS-d

  • DMS-d gets the authorization token like the base DMS.
  • DMS-d fetches a batch of messages from Hub/Hub++ periodically and processes them.
  • DMS-d puts the newly fetched messages into Redis DB.
  • DMS-d confirms to Hub/Hub++ about the previously fetched messages after it saved them in Redis.
  • DMS-d analyzes the number of sessions assigned to each of the DMS-w instance in Redis and assesses their current loads.
  • DMS-d decides which DMS-w instance receives new messages and the number of new messages that do not belong to the current chat sessions.
  • DMS-d analyzes the active chat sessions in Redis and decides where to pass the messages which belong to the existing active chat sessions.
  • DMS-d detects which DMS-w stopped updating its state in the Redis DB to rebalance the load between active DMS-w's.
  • DMS-d, having found DMS-w's that stopped updating its state, decides which chat sessions from the Redis DB must be restored to other DMS-w instances and which messages must be re-sent to the newly created chat sessions.

Functions of DMS-w

  • DMS-w gets the authorization token from Hub / Hub++ directly.
  • DMS-w updates its state in the Redis DB regularly to let DMS-d know that it is running and processing the messages received with the previous batch. DMS-w reads messages (in batches) from Redis directly.
  • DMS-w reads the assigned messages from Redis directly and creates chat sessions.
  • DMS-w updates the messages in Redis with the global chat session IDs and its own name.
  • DMS-w also reads new messages for the already existing chat sessions from Redis and then marks them as processed in Redis so that if the session needs to be restored in another DMS-w, DMS-d decides about which messages would require re-sending.
  • DMS-w sends outbound messages to Hub/Hub++ directly.
Important
The current implementation of DMS High Availability works without any additional changes and each DMS-w relies on its backup to restore those established chat sessions in redundant Chat Servers.

Configuration

The following options can be used to configure DMS scalability:

  • The server-mode option indicates the mode of operation for DMS.
  • The redis-client-config option specifies the file name of the Redis client configuration (.yaml file).

(Optional) Genesys Hub Plug-in for Workspace Desktop Edition configuration

You can specify multiple DMS servers to be used for DMS scalability. If the DMS app name is not specified in the following option, DMS app name from user data of a parent interaction is used.


Configure the following options in the WDE application for the corresponding media channels:

Section Channel Value Changes take effect Type
facebooksession.appname Channel name for Facebook DMS app name. Multiple servers can be specified by using comma. Immediately String
applebcsession.appname Channel name for Apple Business Chat DMS app name. Multiple servers can be specified by using comma. Immediately String
whatsappsession.appname Channel name for WhatsApp DMS app name. Multiple servers can be specified by using comma. Immediately String

Redisson client configuration

Genesys recommends that you use a secured connection with the Redis server. To ensure the secured connection, the Redisson client configuration must specify the address of the Redis server in the form of rediss: . Refer to the example for a sample address.

Additionally, you must describe the JKS key store (parameter sslTruststore) with the CA certificate which is used to verify the Redis server's certificate. Example: 

singleServerConfig:
 idleConnectionTimeout: 10000
 connectTimeout: 10000
 timeout: 3000
 retryAttempts: 3
 retryInterval: 1500
 password: "password"
 subscriptionsPerConnection: 5
 clientName: "DMS"
 sslEnableEndpointIdentification: true
 sslProvider: "JDK"
 # sslTruststore: "file:///C:/Redis_TLS/RedisCA_Test.keystore"
 pingConnectionInterval: 30000
 keepAlive: false
 tcpNoDelay: false
 address: "redis://127.0.0.1:6379"
 # address: "rediss://wsl-win10desktop:6379"
 subscriptionConnectionMinimumIdleSize: 1
 subscriptionConnectionPoolSize: 5
 connectionMinimumIdleSize: 5
 connectionPoolSize: 10
 database: 0
 dnsMonitoringInterval: 5000
threads: 16
nettyThreads: 32
#codec: !<org.redisson.client.codec.JsonJacksonCodec> {}
referenceEnabled: true
transportMode: "NIO"
lockWatchdogTimeout: 30000
reliableTopicWatchdogTimeout: 600000
keepPubSubOrder: true
useScriptCache: false
minCleanUpDelay: 5
maxCleanUpDelay: 1800
cleanUpKeysAmount: 100
nettyHook: !<org.redisson.client.DefaultNettyHook> {}
useThreadClassLoader: true
addressResolverGroupFactory: !<org.redisson.connection.DnsAddressResolverGroupFactory> {}

JVM parameters for DMS-d

-Dgenesys.mcr.stdserverex.apptype=CFGSocialMS
-Dgenesys.mcr.stdserverex.espserver=false
-Dgenesys.mcr.stdserverex.itxrequired=false
-Dgenesys.mcr.stdserverex.scsrequired=true
-Dgenesys.mcr.stdserverex.chatrequired=false
-Dgenesys.mcr.stdserverex.ucsrequired=false
-Dgenesys.mcr.stdserverex.ucsclusterrequired=false
-Dgenesys.mcr.stdserverex.espserver.multipleespports=false
-Dgenesys.mcr.stdserverex.lmsfile=dmserver.lms
-Dgenesys.mcr.stdserverex.infoproviderservice=com.genesyslab.mcr.smserver.OwnInfoProvider
-Dgenesys.mcr.stdserverex.flexchatprotocol=true

JVM parameters for DMS-w

-Dgenesys.mcr.stdserverex.apptype=CFGSocialMS
-Dgenesys.mcr.stdserverex.espserver=true
-Dgenesys.mcr.stdserverex.itxrequired=true
-Dgenesys.mcr.stdserverex.scsrequired=true
-Dgenesys.mcr.stdserverex.chatrequired=true
-Dgenesys.mcr.stdserverex.ucsrequired=true
-Dgenesys.mcr.stdserverex.ucsclusterrequired=false
-Dgenesys.mcr.stdserverex.espserver.multipleespports=false
-Dgenesys.mcr.stdserverex.lmsfile=dmserver.lms
-Dgenesys.mcr.stdserverex.infoproviderservice=com.genesyslab.mcr.smserver.OwnInfoProvider
-Dgenesys.mcr.stdserverex.flexchatprotocol=true

Configuration layer connections

You must ensure the following connections in CME configuration:

DMS instance Connects to
DMS-d Solution Control Server

Message Server, if required

DMS-w Chat Servers

Contact Server or cluster
Interaction Server
Solution Control Server
Message Server, if required

Comments or questions about this documentation? Contact us for support!