How to distinguish multiple StreamBase configurations running on a single node

How to distinguish multiple StreamBase configurations running on a single node

book

Article ID: KB0081190

calendar_today

Updated On:

Products Versions
TIBCO Streaming 10

Description

I have two separate StreamBase applications to run in one node so that they run at the same time, but also need to be configured and managed separately.

How can I identify which configuration belongs with which application fragment when they are together in the same Application Archive?

Issue/Introduction

Configuration example

Resolution

Use the "associatedWithEngines" setting as described in to documentation here:
  TIBCO StreamBase Documentation > Configuration Guide > StreamBase HOCON Configuration > StreamBase Engine Configuration
and here:
  Distributed Transactional Memory, Administration, "Java engine configuration objects"
  http://devzone.tibco.com/sites/streambase/latest/sb/sb-product/documentation/adminguide/ch04s02.html

Running two StreamBase engines in the same node places a constraint on the configuration of all fragments. All the config file "name" values must be unique across all fragments or there will be a name collision resulting in a validation error whent he node is installed. All opened TCP server ports must be different or there will be a port collision when the node is started.

By default a fragment configuration is associated with all engines, which is the problem here.

The solution is to use the "associatedWithEngines" property in each configuration file that allows it.

Configuration Example

Here is a working configuration example for two SB fragments combined into a single Application Archive and run on a single node.

The two projects are built using:
  SBEngineOne>mvn -DskipTests clean install
  SBEngineTwo>mvn -DskipTests clean install
and combined into the Application archive which depends on them using:
  SBEngines>mvn -DskipTests clean package

The "SBEngineOne" project has engineOne.conf:
name = "engineOne"
type = "com.tibco.ep.streambase.configuration.sbengine"
version = "1.0.0"

configuration = {
	StreamBaseEngine = {
		associatedWithEngines = [ "default-engine-for-com.support.SBEngineOne" ]
		jvmArgs = [
			"-Xmx3g"
			"-Xms3g"
			"-XX:+UseG1GC"
			"-XX:MaxGCPauseMillis=500"
			"-XX:ConcGCThreads=1"
		]	
	}
}

The "SBEngineTwo" project has engineTwo.conf:
name = "engineTwo"
type = "com.tibco.ep.streambase.configuration.sbengine"
version = "1.0.0"

configuration = {
	StreamBaseEngine = {
		associatedWithEngines = [ "default-engine-for-com.support.SBEngineTwo" ]
		jvmArgs = [
			"-Xmx12g"
			"-Xms12g"
			"-XX:+UseG1GC"
			"-XX:MaxGCPauseMillis=500"
			"-XX:ConcGCThreads=1"
		]	
	}
}

The filenames, "name" property, and "associatedWithEngines" property uniquely distinguish these configurations.

The name of an engine is the concatenation of "default-engine-for-", the package name, and the engine "name".

The server ports are changed similarly in the ClientAPIListener configuration.

The "clientForEngineOne.conf" :
name = "clientForEngineOne"
type = "com.tibco.ep.streambase.configuration.sbclientapilistener"
version = "1.0.0"

configuration = {
	ClientAPIListener = {
		associatedWithEngines = ["default-engine-for-com.support.SBEngineOne"]
		apiListenerAddress = {
			portNumber = 10010
		}
	}
}

The "clientForEngineTwo.conf":
name = "clientForEngineTwo"
type = "com.tibco.ep.streambase.configuration.sbclientapilistener"
version = "1.0.0"

configuration = {
	ClientAPIListener = {
		associatedWithEngines = ["default-engine-for-com.support.SBEngineTwo"]
		apiListenerAddress = {
			portNumber = 10011
		}
	}
}

One remaining consideration is parameterization using substitution variables. When parameters are used, the substitution variables need to be different and unique across all fragments. This means that you cannot have a single substitution variable named SB_PORT and qualify the name to only affect a single fragment. Make the simple names of the substitutions different, such as A_SB_PORT and B_SB_PORT. That way they can be distinguished on the command-line in the 'epadmin install node' command.

Deployment and execution will look something like this:
tmp>epadmin serviceprefix=false install node nodename=twoserver.test application=..\SBEngines\target\SBEngines-0.0.1-SNAPSHOT-ep-application.zip
        Installing node
...
                Deploying application
                        Engine default-engine-for-com.support.SBEngineOne
                        Engine default-engine-for-com.support.SBEngineTwo
...
                Service name is twoserver.test
        Node installed

tmp>epadmin serviceprefix=false servicename=twoserver.test start node
        Starting node
                Engine application::default-engine-for-com.support.SBEngineOne started
                Engine application::default-engine-for-com.support.SBEngineTwo started
...
        Node started

tmp>epadmin serviceprefix=false servicename=twoserver.test display stream
Engine = default-engine-for-com.support.SBEngineTwo
Path = default.OutputStream
Type = output
Enqueue = false
Dequeue = true
Total Tuples = 128
Schema = (time timestamp, msg string)

Engine = default-engine-for-com.support.SBEngineOne
Path = default.OutputStream
Type = output
Enqueue = false
Dequeue = true
Total Tuples = 128
Schema = (time timestamp, msg string)