Contact usRequest a demo

Configuring conversation session migration in on-premises cluster deployments

If you’re running an Unblu cluster and terminate a pod running the Collaboration Server, Unblu migrates any conversations still taking place on the pod to another Collaboration Server pod.

Usually migration is seamless, and the participants in a conversation aren’t even aware that it took place. Sometimes, Unblu can’t migrate a conversation seamlessly:

  • Audio and video calls as well as collaboration layers are only available in the pod’s memory space and aren’t persisted anywhere. When Kubernetes terminates the pod they’re running on, the calls and collaboration layers stop, too.

The Collaboration Server shutdown process is divided into two phases:

  1. The graceful shutdown phase, during which tasks have the possibility to finish what they’re doing.

  2. The termination phase, or the actual shutdown phase, when any remaining tasks are terminated.

You can configure these phases to make the shutdown process as smooth as possible for conversations that can’t be migrated seamlessly.

Graceful shutdown phase

In the graceful shutdown phase, the Collaboration Server pod first stops accepting new connections. Running tasks then execute their graceful shutdown logic in parallel.

  • For ongoing conversations that can’t be migrated seamlessly, Unblu displays a banner in the Agent Desk, warning agents of an imminent shutdown. Agents thus have the opportunity to end any calls or collaboration layers that are in progress.

    The message is displayed if the pod running the Collaboration Server is to be shut down. It also appears if the pod running the Rendering Service used in the collaboration layer of the conversation is to be terminated.

    If the agent clicks the Update now button on the banner, Unblu immediately terminates the call or co-browsing session.

Configuring the graceful shutdown phase

There are a number of configuration properties to configure the graceful shutdown phase:

  • The maximum duration of the grace period is defined in the configuration property com.unblu.platform.server.core.internal.GracefulShutdownManager.gracefulShutdownTimeoutSeconds. The graceful shutdown phase ends sooner if all tasks complete their graceful shutdown in less time.

    Any tasks still executing their graceful shutdown logic at the end of the graceful shutdown period are aborted, and Unblu moves on to the termination phase.

    Ensure that the value you set here is no larger than the value of terminationGracePeriodSeconds in the pod’s YAML specification.

  • When you’re troubleshooting an issue, it can be useful to ensure that the graceful shutdown phase lasts a minimum time. To do so, set com.unblu.platform.server.core.ShutdownWait.gracefulShutdownDelaySeconds to the minimum time you want the grace period to last.

    The value must be smaller than that of the grace period’s maximum duration.

  • You can specify how long before the end of the grace period Unblu should display the banner in the Agent Desk with the configuration properties com.unblu.conversation.shutdown.countdownThreshold.

  • The banner displayed in the Agent Desk uses the following text properties:

    • com.unblu.conversation.shutdown.bannerTitle

    • com.unblu.conversation.shutdown.bannerBody

    • com.unblu.conversation.shutdown.bannerActionUpdateNow

    • com.unblu.conversation.shutdown.severalAffectedCollaborations

    • com.unblu.conversation.shutdown.affectedCall

  • The system messages displayed in the chat UI during the grace period are:

    • com.unblu.conversation.message.imminentShutdownRecordingTitle

    • com.unblu.conversation.message.imminentShutdownCollaborationServer

    • com.unblu.conversation.message.imminentShutdownRenderingService

    You can set who sees the system messages in the configuration property com.unblu.conversation.message.allowSeeGeneralSystemMessagesForImminentShutdown.

Termination phase

In the termination phase, all tasks are executed in sequence, not in parallel. There’s no maximum duration for the termination phase. The timeout is enforced by an external system such as the K8s cluster.

At the end of the termination phase, the Collaboration Server has stopped, and the pod is ready to be removed from the cluster.

Configuring the termination phase

There aren’t as many configuration options for the termination phase: