Jump to: navigation, search

Optional: Deploy RabbitMQ for quick widget updates


Genesys Pulse supports quick updates for CurrentStatus and ExtendedCurrentState statistics only to prevent a high performance load this causes on Stat Server and Genesys Pulse.

You are responsible to validate that your environment can handle the load in production caused by quick updates.

Use RabbitMQ for quick widget Updates.

  1. To use RabbitMQ to work with Genesys Pulse, use the following software versions:
    • RabbitMQ server version 3.3.5.
    • Use identical versions of Erlang on all hosts running RabbitMQ:
      • Windows, use Erlang version OTP 17.3
      • Linux, use the latest Erlang version available (R14B-04 or newer)
    • Tip
      We specify the lowest acceptable version here, but any later versions should work unless their RNs specify that there are some backward compatibility changes. If you are using RabbitMQ 3.7.5 or newer, please make sure the RabbitMQ server's option channel_max is set to 0.
  2. Determine whether to use RabbitMQ with Genesys Pulse using Cluster or Single-Node configurations. Genesys Pulse supports using these configurations only for use with RabbitMQ.
    • Cluster configuration—Use at least the same number of RabbitMQ instances as the number of Genesys Pulse Collector applications. RabbitMQ can run on any host: either the one where Genesys Pulse runs or any other host accessible over reliable network.

      The default configuration should be one RabbitMQ instance running on every host where Genesys Pulse Collector runs. For example, Primary host (host1) and Backup host (host2).

    • Single node configuration—This simple configuration uses a single RabbitMQ instance running either on a host with Genesys Pulse Collector or any other host accessible over reliable network.

      Note: If this RabbitMQ instance fails or the whole host fails, quick widget Updates stop working. If you choose this configuration, you still need to go through all steps to deploy RabbitMQ unless clearly stated otherwise. The host with RabbitMQ is called host1 in the remainder of this deployment.

  3. On every host, install Erlang:
    • On Windows Server:
      1. Download Erlang OTP 17.3 Windows installer. For Windows x64, use the 64-bit version.
      2. Run installer.
      3. Go through the installation wizard and install Erlang.
    • On Linux, as the root user, run the following commands:
      1. To enable EPEL:

        wget http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

        rpm -ivh epel-release-6-8.noarch.rpm

      2. To install Erlang:

        yum install erlang

  4. On every host, install and configure RabbitMQ:
    1. Download and install RabbitMQ:
      • On Windows Server:
        1. Download RabbitMQ installer
        2. Run the installer.
        3. Go through the installation wizard and install RabbitMQ.
      • On Linux, as the root user, issue the following commands:
        1. Download RabbitMQ package:

          wget https://www.rabbitmq.com/releases/rabbitmq-server/v3.3.5/rabbitmq-server-3.3.5-1.noarch.rpm

        2. Import RabbitMQ key:

          rpm --import http://www.rabbitmq.com/rabbitmq-signing-key-public.asc

        3. Install RabbitMQ server:

          yum install rabbitmq-server-3.3.5-1.noarch.rpm

    2. On every host, first start RabbitMQ server to generate Erlang cookie file.
      • On Windows, start RabbitMQ service. If it is already started proceed to the next step.
      • On Linux, from the command line as the root user:

        1. Run: service rabbitmq-server start

        2. If you want RabbitMQ to start automatically when system boots, run:

          chkconfig rabbitmq-server on


        To run the rabbitmqctl tool that is installed as a part of RabbitMQ server.

        • On Linux, run it as root right after installing the server.
        • On Windows, navigate to ${RabbitMQ installation directory}\rabbitmq_server-3.3.5\sbin directory and run rabbitmqctl from there.
        When the entire cluster is brought down, the last node to go down must be the first node to be brought online. If this doesn't happen, the nodes will wait 30 seconds for the last disc node to come back online, and fail afterwards. -rabbitmq.com

        When node fails due to the above limitation RabbitMQ's startup_log contains message like this:

        Error description:

    3. (Cluster configuration only) Reset RabbitMQ on every RabbitMQ host using the following commands:

      rabbitmqctl stop_app

      rabbitmqctl reset

    4. (Cluster configuration only) Stop RabbitMQ server on every host. You must stop RabbitMQ on both servers before starting any one of them. On both hosts, do the following:
      • On Windows, stop RabbitMQ service.
      • On Linux, as the root user, run:

        service rabbitmq-server stop

    5. (Cluster configuration only) Copy Erlang cookie from one host to all others. These files must be identical on all hosts that form RabbitMQ cluster.
      • On Windows: Copy to both C:\Users\<user account under which Erlang runs>\.erlang.cookie and C:\Windows\.erlang.cookie
      • On Linux: Copy to /var/lib/rabbitmq/.erlang.cookie
    6. (Cluster configuration only) Configure RabbitMQ cluster consisting of several RabbtMQ instances running on host1, host2, ..., hostn.
      1. Create the rabbitmq.config file on all of those hosts:
        • On Windows, in %APPDATA%\RabbitMQ\.
        • On Linux, in /etc/rabbitmq.

        This how configuration might look for a 2-node cluster:

            {cluster_nodes, {['rabbit@host1', 'rabbit@host2'], disc}}

        Change host1 and host2 with the names of your hosts.

        Hostnames are case sensitive. You must use uppercase characters for Windows hosts and lowercase characters for Linux hosts.
      2. On Windows only: In ${RabbitMQ installation directory}\rabbitmq_server-3.3.5\sbin run the following command: rabbitmq-service.bat install
    7. (Cluster configuration only) Start RabbitMQ server on all hosts.
      • On Windows, start RabbitMQ service.
      • On Linux, as the root user run:

        service rabbitmq-server start

    8. (Cluster configuration only) Confirm that RabbitMQ instances have formed a cluster. Run:

      rabbitmqctl cluster_status

      The output should contain the following line for the cluster consisting of two nodes:


    9. Create a vhost with a name '/pulse' for Genesys Pulse. If you create a vhost with a different name, you must specify it in Genesys Pulse Collector configuration options. On any of the hosts run the following command:

      rabbitmqctl add_vhost /pulse

    10. Create a user for Genesys Pulse with name 'pulse' and password 'pulse'. If you create a user with a different name and password, you must specify them in Genesys Pulse Collector configuration options. On any of the hosts run the following command:

      rabbitmqctl add_user pulse pulse

    11. Grant user access to vhost. Here is how to grant user 'pulse' access to vhost '/pulse' with permissions to create exchanges with names starting with 'pulse'. On any of the hosts run the following command:

      rabbitmqctl set_permissions -p /pulse pulse "^pulse.*" ".*" ".*"

  5. To configure Genesys Pulse Collector to work with RabbitMQ you need to have transport-rabbitmq section configured in options of Genesys Pulse Collector application object. Add or update configuration options in the [transport-rabbitmq] section.
  6. Restart Genesys Pulse Collector and Genesys Pulse to apply changes.

RabbitMQ memory and disc usage

RabbitMQ instances should not store any Genesys Pulse application data on disc, so the disc usage is insignificant unless the message queue for any of the Genesys Pulse applications grows too large. To ensure that the message queue does not grow too big in some exceptional cases there is a limit on queue length in Genesys Pulse, which is controlled by option max-queue-length in section transport-rabbitmq of Genesys Pulse Collector application options.

Use the value of this option to estimate possible RabbitMQ memory usage. To roughly estimate upper limit of possible memory usage use this formula:

<Max memory usage> = <RabbitMQ idle memory usage> + 3 * ( max-queue-length * <Average size of a delta snapshot> * 4 )

For example, for an average change in message size of 10KB, RabbitMQ idle memory usage of 100MB, and max-queue-length of 1000, we obtain 220MB of memory usage.

If Genesys Pulse and Genesys Pulse Collector are installed on the same host, instead of RabbitMQ you can use embedded Aeron transport by specifying options in the transport-aeron section of your Genesys Pulse Collector application. Note: For the successful usage of the embedded Aeron transport you do not need to implement Advanced Alerting services.
Starting with release 9.0.001, Genesys Pulse and Genesys Pulse Collector support Aeron transport configured on Windows.
This page was last edited on February 6, 2020, at 20:56.
blog comments powered by Disqus