How to configure unicast discovery for the BE Legacy ActiveSpaces Cluster Provider

Products	Versions
TIBCO BusinessEvents Enterprise Edition	5.6 and later

Description

In some cases, IT policies and deployment practices do not allow for multicast discovery protocols. This article discusses the basic steps needed to configure unicast tcp discovery as an alternative to multicast pgm.

Issue/Introduction

Outlines the steps needed to configure unicast discovery for the BE Legacy Activespaces Cluster Provider, in cases where multicast discovery is not allowed.

Environment

All Supported Platforms

Resolution

First, disable the default discovery-url and listen-url values set at the CDD cluster level by setting these properties to an empty value:

<object-management>
        <cache-manager>
            <type>AS2x</type>
            <class/>
            <properties>
                ...
                <property name="discovery-url" value=""/>
                <property name="listen-url" value=""/>
                ...

Next, choose a discovery port for the primary processing unit (PU), which will run at all times to allow other PUs to discover and join the cluster. Typically, the primary PU will be the first Cache PU that is started. For example, select port 50000 (which is the default that will be attempted if not explicitly set otherwise). Specify this as the discovery port for any additional processing units that might join the cluster. This can be set in the project's CDD under the cluster-level properties:

<property-group>
        <property-group comment="" name="auth">
            <property name="be.mm.auth.type" value="file"/>
            <property name="be.mm.auth.file.location" value="/opt/tibco/be/6.1/mm/config/users.pwd"/>
            <property name="java.security.auth.login.config" value="/opt/tibco/be/6.1/mm/config/jaas-config.config"/>
        </property-group>
        <property name="be.engine.cluster.as.discover.url" value="tcp://<DNS or IP of primary PU>:50000"/>
    </property-group>

Then separately, set the listen-url at the Processing-Unit level in your CDD. For the primary Cache processing unit, the listen-url should be the same as the discovery-url. But for all additional processing units that will need to join the cluster, a different (unique) listen-url should be specified. For example, in the primary Cache processing unit CDD options, set:

<processing-unit id="cache">
            <agents>
                <agent>
                    <ref>cache-class</ref>
                    <key/>
                    <priority/>
                </agent>
            </agents>
            <logs>logConfig</logs>
            <hot-deploy>false</hot-deploy>
            <cache-storage-enabled>true</cache-storage-enabled>
            <db-concepts>false</db-concepts>
            <property-group>
                <property name="be.engine.cluster.as.listen.url" value="tcp://<DNS or IP of primary PU>:50000"/>
                <property name="be.engine.cluster.as.security.mode.role" value="controller"/>
            </property-group>
        </processing-unit>

Then in a secondary Inference processing unit, configure a different listen-url (e.g. 50001):

<processing-unit id="default">
            <agents>
                <agent>
                    <ref>inference-class</ref>
                    <key/>
                    <priority/>
                </agent>
            </agents>
            <logs>logConfig</logs>
            <hot-deploy>false</hot-deploy>
            <cache-storage-enabled>false</cache-storage-enabled>
            <db-concepts>false</db-concepts>
            <property-group>
                <property name="be.engine.cluster.as.listen.url" value="tcp://<DNS or IP of secondary PU>:50001"/>
                <property name="be.engine.cluster.as.security.mode.role" value="requestor"/>
            </property-group>
        </processing-unit>

Repeat this procedure for any new Processing Unit configurations in your CDD.

Welcome to "KB Articles"