Isolating Nodes

Often times there is a need to isolate one or more nodes to handle special event processing. For example, a situation may call for a server tier dedicated to integration and/or batch processing. With some simple extensions and a couple configuration changes, this can be accomplished.

This guide will step through the changes required to allow a separate node to be setup with the primary intent of processing integration events.

Establishing a new EventWorkerType

Broadleaf is delivered with three possible EventWorkerTypes that represent a typical deployment:

The first step will be to add a new EventWorkerType that will represent the new type of node that is being setup.

Create new EventWorkerType

A new EventWorerType can be added by creating a new class and adding to the list of existing EventWorkerTypes. For this example, we will call the worker "INTEGRATION".

public class IntegrationEventWorkerType {
    public static final EventWorkerType INTEGRATION = new EventWorkerType("INTEGRATION", "Integration");
}

Next, register this new class with Spring by adding a bean definition. This would likely be added to the applicationContext.xml in the core project:

<bean class="com.mycompany.service.type.IntegrationEventWorkerType" />

Allow Assignment of new EventWorkerType to a node

On startup, each node registers itself in the BLC_NODE_REGISTRATION table which includes establishing which WorkerType the node represents. With the INTEGRATION EventWorkerType, the new integration nodes will need to register their type.

To do this, the DatabaseSystemEventNodeImpl class will be extended with the capability to force set the EventWorkerType based on a Java startup parameter:

public class MyDatabaseSystemEventNodeImpl extends DatabaseSystemEventNodeImpl {
    @Override
    public synchronized EventWorkerType determineHostWorkerType() {
        if (eventWorkerType == null) {
            //If we have a forced nodeWorkerType, use it
            String systemWorkerType = System.getProperty("nodeWorkerType");
            if (systemWorkerType != null && EventWorkerType.getInstance(systemWorkerType) != null) { 
                eventWorkerType = EventWorkerType.getInstance(systemWorkerType);
            } else {
                eventWorkerType = super.determineHostWorkerType();
            }
        }
        return eventWorkerType;
    }
}

This extension checks for an optional Java startup parameter called nodeWorkerType. If set, the passed in worker type is used (assuming it is a valid EventWorkerType type). If it is not set, the default behavior is used (e.g. SITE or ADMIN node). The following Java startup parameter would set the node to "INTEGRATION".

-DnodeWorkerType=INTEGRATION

Prevent new nodes from becoming the Master Node

By default, any node can become the Master Node (see Key Concepts). For this setup, the assumption is that the new Integration nodes would not be allowed to become Master Nodes. This is an easy configuration that can be accomplished by setting the following Java startup parameters on these Integration nodes:

-Dmaster.node.job.management.enabled=false
-Dmaster.deploy.node.enabled=false

Finally, send Integration events using the new EventWorkerType

Any events that should be consumed by the new Integration node(s) would need to use the new EventWorkerType when defining the event:

    SystemEvent event = new SystemEventImpl();

    event.setType("MY_EVENT_TYPE");
    event.setScopeType(EventScopeType.VM);
    //send to only INTEGRATION nodes
    event.setWorkerType(IntegrationEventWorkerType.INTEGRATION);
    event.setEnabled(true);
    ...